I’ve been experimenting with creating my own Fluxbox “styles” (desktop themes) lately, and this provides me with an excuse to launch a new regular feature here at E7P: My Eee Desktop. Every month around this time, I’ll try and post a screenshot of how the desktop on my 701 looks—I do tend to ‘tinker’ around with how it looks, so hopefully there will be the odd change or two to show off!

I actually have two Fluxbox themes I’ve been working on, but will save one for next month (for reasons which should become clearer then). In the meantime, then, here is My Eee Desktop for November 2009:

Eee 701 desktop, showing 'IT Crowd' Fluxbox theme

This is showing my own “IT Crowd” theme, for which I used a deliberately chunky system font (note the menu, toolbar and window title bar), in keeping with the “IT geek ” theme of the show.

The system stats in the top-left of the desktop, are displayed via conky. The version of the app in the Xandros/Eee repositories is positively prehistoric (1.4.4, dating from November 2006!), so I may end up compiling my own executable of the latest version, if I find myself with nothing else to do sometime…

The top-right “stack” is a collection of “dockapps”, displaying in the Fluxbox “slit”. From the top down, they are:

• wmbubble – monitors CPU activity and memory usage levels
• wmnd – network activity monitor
• wmwave – wireless network stats display
• wmifinfo – shows various stats regarding current network connection(s)
• wmweather+ – weather applet, including satellite photo (not shown)
• wmfishtime – animated analogue clock and calendar

I’ll post another screenshot of my desktop next month. In the meantime, if you’d like further information on how this was set up, configured, etc., please let me know via the comments box below.

Zakładam, że masz zainstalowany sam system bazowy i nie korzystałeś jak do tej pory z innego menedżera okien, a więc nie masz zainstalowanego xorga. Jeśli jest inaczej, to możesz pominąć jego instalację.

Instalacja tego co konieczne, a bynajmniej przydatne

Wpierw instalujemy xorga:
# aptitude install xterm xserver-xorg xfonts-base xbase-clients

Teraz czas na fluxboxa:
# aptitude install fluxbox

Będziemy potrzebowali jeszcze menedżera logowania, ja polecam nodm:
# aptitude install nodm

Aby nodm uruchamiał się automatycznie należy nieco edytować jego plik konfiguracyjny /etc/default/nodm. Interesują nas linie:

NODM_ENABLED=false
NODM_USER=root

zamieniamy je na:

NODM_ENABLED=true
NODM_USER=trym

Oczywiście nic nie stoi na przeszkodzie aby zainstalować np. kdm, gdm, xdm, etc…

Teraz już możemy śmiało wykonać polecenie:
$ startx

No i jesteśmy w naszych okienkach (tzw. xach). Widok, który ujrzymy wygląda jak na zrzucie poniżej.

Niektórzy użytkownicy mogą być nieco zaskoczeni faktem, iż nie mamy ustawionego tła pulpitu (tapety) czy żadnych ikon. Na pociesznie jednak dodam, że w tym cały urok Fluxboxa. Konfigurujemy go wedle własnego uznania – nic nie jest z góry narzucane.

Dla wygody zainstalujemy sobie jeszcze menedżer plików i motyw ikon:
aptitude install pcmanfm lxappearance

Lxappearance jest w tym wypadku może nie niezbędny, ale wskazany. Uruchamiamy go i wybieramy motyw. Dzięki temu unikniemy komunikatu o błędzie przy uruchamianiu pcmanfm. Pamiętamy, iż należy motyw ustawić zarówno dla zwykłego użytkownika jak i root — poprzez uruchomienie programu z poziomu obydwu użytkowników.

Ustawienie tła pulpitu

Instalujemy aplikację feh:
# aptitude install feh

Tworzymy plik, który będzie odpowiadał nam za uruchamianie pewnych programów przy starcie i nadajemy odpowiednie uprawnienia:
$ touch /home/trym/.fluxbox/autostart
$ chmod +x /home/trym/.fluxbox/autostart

w nowo utworzonym pliku wpisujemy:

#!/bin/bash
fbsetbg -f /home/trym/download/tapety/aktualna_tap.jpg &

/home/trym/download/tapety/aktualna_tap.jpg – jest to ścieżka do pliku tła. Ponadto pamiętamy o znaku & na końcu wiersza.

W pliku /home/trym/.fluxbox/init odnajdujemy linię:

session.screen0.rootCommand:

i zamieniamy na:

session.screen0.rootCommand: /home/trym/.fluxbox/autostart

Restartujemy Fluxboxa (PPM -> Restart) i już mamy wybraną tapetę w trybie pełnoekranowym.

Ikony na pulpicie

Instalacja:
# aptitude install idesk

Tworzymy odpowiednie foldery i plik:
$ mkdir /home/trym/.idekstop
$ mkdir /home/trym/.idesktop/icons
$ vim /home/trym/.ideskrc

Utworzony plik wypełniamy treścią:

table Config
FontName: sans
FontSize: 8
FontColor: #aeb3bf
Locked: false
Transparency: 0
HighContrast: true
Shadow: true
ShadowColor: #000000
ShadowX: 1
ShadowY: 2
Bold: false
ClickDelay: 300
IconSnap: true
SnapWidth: 10
SnapHeight: 10
SnapOrigin: BottomRight
SnapShadow: true
SnapShadowTrans: 200
CaptionOnHover: false
end
table Actions
Lock: control right doubleClk
Reload: middle doubleClk
Drag: left hold
EndDrag: left singleClk
Execute[0]: left singleClk
Execute[1]: right singleClk
end

Umieszczamy interesującą nas ikonę z rozszerzeniem .png, .jpg lub .gif w katalogu /home/trym/.idesktop/icons. Dla tego przykładu niech zawiera ona nazwę home.png. Jeśli chcesz skorzystać z ikon typowych dla zainstalowanych programów to zajrzyj do katalogu /usr/share/applications, bardzo prawdopodobne, że znajdziesz tam właściwą ikonę.

Dla każdej ikony tworzymy odpowiedni plik konfiguracyjny:
$ vim /home/trym/.idesktop/home.lnk

Uzupełniamy:

table Icon
Caption: trym
Command: pcmanfm /home/trym
Icon: /home/trym/.idesktop/icons/home.png
Width: 48
Height: 48
X: 39
Y: 9
end

Na koniec dopisujemy do autostartu ideska, wydając polecenie:
$ echo 'idesk &'>>/home/trym/.fluxbox/autostart

Wygodne wyłączanie komputera

Instalujemy kolejne pakiety:
# aptitude install sudo gtkdialog

Następnie edytujemy plik /etc/sudoers/ wydając polecenie:
# visudo

I dopisujemy na końcu pliku:

User_Alias USERS=trym
Cmnd_Alias SHUTDOWN=/sbin/shutdown
Cmnd_Alias HALT=/sbin/halt
Cmnd_Alias REBOOT=/sbin/reboot

USERS ALL=NOPASSWD:SHUTDOWN
USERS ALL=NOPASSWD:HALT
USERS ALL=NOPASSWD:REBOOT

Tworzymy katalog, pobieramy odpowiedni plik:
$ mkdir ~/download
$ cd ~/download
$ wget http://hag-linux.eu.org/deb/pool/main/h/hag-exit-fluxbox/hag-exit-fluxbox_0.3-1_all.deb

Instalujemy pobrany pakiet:
# dpkg -i hag-exit-fluxbox_0.3-1_all.deb

Tworzymy ikonę zgodnie z opisem wyżej (Ikony na pulpicie) jako polecenie podając:

hag-exit-fluxbox

Po wywołaniu aktywatora (ikony) ukaże nam się taki widok:

Niektóre opcje mogą być niedostępne. Na przykład aby móc hibernować peceta zainstalujmy pakiet hibernate.

Ustawienie godziny i trybu wyświetlania zegara

Tryb wyświetlania 12h lub 24h ustawimy najeżdżając na zegar kursorem, klikając prawym przyciskiem myszy i wybierając odpowiednią opcję. Podobnie sprawa wygląda z tym jak szczegółowy czas chcemy by był pokazywany (HH:MM czy może HH:MM:SS).

Jeśli chodzi o ustawienie godziny to należy wydać odpowiednią komendę z konsoli, przykładowo:
# date -s 23:05

Skrót “pokaż pulpit”

Odczytujemy kombinację klawiszy za pomocą np. xbindkeys -k, gdzie otrzymamy przykładowo:

“(Scheme function)”
m:0×80 + c:40
Mod5 + d

Nas interesuje jedynie zapis Mod5 + d i należy go zapamiętać.

Edytujemy plik:
$ vim /home/trym/.fluxbox/keys

wpisując do niego (na końcu) między innymi wcześniej zapamiętany ciąg:

Mod5 d :ShowDesktop

Restart Fluxboxa i od tej pory pod kombinacją klawiszy prawy_Alt + d (lub inną, którą podaliśmy) mamy funkcję wyświetlającą “czysty” pulpit.

Aby odczytać klawisze posłużymy się programem xbindkeys:

$ xbindkeys -k

Po ukazaniu się okienka w lewym górnym rogu wciskamy interesującą nas kombinację klawiszy, np. prawy Alt + d.

Przykład tego co może nam zwrócić xbindkeys:

“(Scheme function)”
m:0×80 + c:40
Mod5 + d

Edytujemy plik ~/.fluxbox/keys odpowiadający za skróty klawiszowe w naszym środowisku. Teraz wystarczy tylko dopisać na jego końcu:

Mod5 d :ShowDesktop

Restartujemy Fluxboxa i skrót już działa.

O fluxbox é um gerenciador de janelas e acho que a principal vantagem dele é a sua leveza. O seu aspecto inicial “choca” usuários novos por ser bem diferente de ambientes como Gnome e KDE.

Andando aí pela net encontrei uma página bem instrutiva, ela explica a instalação e uso do fluxbox desde o início, passando por definição de wallpaper, ícones no desktop, desklets, gerenciador de arquivos, etc.

Quer ter uma idéia de como o fluxbox pode ficar?
Screenshots !!!

Estou recomendando os links pois o artigo está bem completo e abrange muita coisa.

Obs.: os posts são divididos em 8 partes, leiam o primeiro e no fim do post tem os outros links nos tópicos relacionados.

http://linuxnanet.com/2008/09/fluxbox-parte-1-um-window-manager-leve.html

As some of you may know, a few weeks ago I posted about my efforts to revive aging laptop hardware. While there is still a bit of work to be done, the bulk of the project is complete, and the rest is simply detail work and optimization for our particular work environment.

For those of you who don’t recall the specifics, I have been dealing with two older Gateway 1.3 GHz Pentium M laptops with 256 MB of RAM and Intel Centrino (TM) mobile technology. They’re each about 6 years old, due for replacement, and not worth further investment of money into things like more memory. (In my work environment, once a machine goes out of warranty, there is great reluctance to invest more money in that machine, they prefer purchase of a new one instead.) That Centrino technology would prove to be something of a thorn in my side, and had a direct influence on some of the decisions I made.

Fortunately, from the end-user side the requirements are fairly straight-forward. The one proprietary application we require is java-based and while it’s a memory hog, I have not encountered any compatibility issues. Additionally, we require a web browser (ideally Firefox, another memory hog) and OpenOffice.org. The biggest challenge was finding an environment which required minimal training. Most of those who will use the laptops are casual Windows users who have had little or no previous experience in a Linux environment, and I wanted to make the transition as painless as possible. Unfortunately, this meant that a certain amount of bloat and eye candy was unavoidable, if only even to make a lean and mean X environment (like Fluxbox) a little softer around the edges. In short, I had to find a way to make the kernel and windowing environment as thin as possible in order to allocate as many system resources as possible to the required applications, but at the same time, I had to make the interface at least somewhat familiar.

Distro Decisions

I received a lot of feedback regarding good, thin distros that would serve my purposes well. I gave several of them a try, and many of the others I researched on Distro Watch. There were numerous viable options there. From a performance perspective, I was very impressed with Damn Small Linux (a.k.a. “DSL”), but the wireless card driver situation was not good: they didn’t support the card natively, recommending NDISwrapper as the best solution. Ugh.

As mentioned previously, my experience with Debian was sorely disappointing, again because of the wireless card issue. After the failures of Debian and DSL, I started digging deeper before testing any more distros, because the wireless card issue (and the ease of dealing with it) was a deal-breaker. While I could certainly take the distro I want and roll my own kernel, I didn’t want to have to deal with that. As a result, I started looking much more closely at Ubuntu and its derivatives, since I had already confirmed that they had built the necessary wireless drivers into the kernel (test laptop 1 was working fine with Xubuntu and Fluxbox.)

At the end of the day, I had to make the call among vanilla Ubuntu, Xubuntu, Linux Mint and wattOS. I really, really liked what the wattOS team was doing, but there were some elements that weren’t quite ready for prime time. It really looks like a solid project, but it was also obviously still in beta (a status which hasn’t changed recently), so I (reluctantly) crossed them off the list. I can deal with lack of polish, but there were still some bugs on the installation and administrative sides (I can’t remember what they are offhand, but I remember they were somewhat annoying.) Nevertheless, if anyone is in a similar situation, do give them a look. I think they’re on to something. My ultimate decision was for Mint, on the strength of its organization and the fact that it includes some really nifty extra tools (MintUpdate and MintBackup, for instance.) I also took the plunge and replaced Slackware 12.2 with Mint on my desktop computer. I don’t regard Mint as a “compromise” in any way, and fears that it might be a bit too robust for the laptop have not come true, so far.

Next Page: Becoming environmentally-friendly

Becoming environmentally-friendly

The other side of the equation for this project was the overall desktop environment. Right away I knew that Gnome and KDE were far too heavy for these machines. Previous experimentation with Xfce had demonstrated that, while lighter than the 2 full-featured environments, it was still not really a “lightweight” environment. Gnome was tolerable, Xfce was merely okay, and the other machine running Fluxbox was downright snappy. (As an aside, for comparative purposes, Windows XP Pro was extremely sluggish.) Between the Fluxbox and Damn Small Linux experiments, I had a pretty good idea just how far these laptops could be optimized for speed, and Xfce was well underperforming the other lightweight environments.

I dabbled with some of the other suggested lightweight environments as well: IceWM, JWM and WindowMaker, to name a few, but ultimately went with WattOS’s playbook and settled on LXDE. It’s not quite as responsive as Fluxbox or IceWM, but it clearly outperforms XFCE, and it provides a somewhat more comfortable interface for the inexperienced user. Getting the desktop icons working right takes a little bit of configuration, but it’s actually not too bad.

The last step was to give the intern both laptops and tell her to do her work as normal on them. I asked her to provide feedback on which setup she preferred, as well as providing feedback on things she’d like to see or shortcomings she found in the way things were set up. So far, she hasn’t asked for any improvements, but she was pretty clear in indicating her preference for the Mint/LXDE setup over the Xubuntu/Fluxbox setup, even though the Fluxbox solution was the more responsive one. Usability does matter a good deal, and the intern seemed pretty satisfied with the performance of the LXDE machine.

Final thoughts

I’m reasonably certain I haven’t finished the laptop project entirely, although there’s a good chance that when I revisit it, I will have the benefit of newer and more powerful hardware. I saw a lot of really good stuff out there that would generally have been appropriate for this sort of project: CrunchBang, Puppy Linux, DSL and wattOS all have a lot to offer. For me, the devil was that wireless card. Had the laptop been equipped with something more “open”, I would have had a broader range of distros available, and would likely have ended up running DSL, so rather than looking all over for which distros and variants would cover that card, I simply narrowed my search to Ubuntu and derivatives, since I knew those were generally safe.

The other key factor in my decision-making process was the convenience of APT. I know it can be something of a crutch, but I really, really liked the convenience of being able to apt-get whatever it was I needed, with a reasonable expectation it would work. This is one of the main reasons I didn’t even attempt a Slackware solution (well, that and Patrick V’s lack of future support for KDE 3. But I digress.) I was really hoping a pure Debian option would work, but alas, that wasn’t the case. At any rate, I’ve been very impressed with Ubuntu and the various community releases. A big part of me wanted something that “just worked”, and all but the most stripped-down Ubuntu flavors delivered with flying colors.

All in all, I’m satisfied with how this project has turned out. We got two obsolete and under-powered laptops to a state in which they will function effectively and with minimal additional training, and that was really the object of the exercise.

Desalentadora la nota en el blog oficial de Linux Mint, en el cual anuncian avances sobre Linux Mint 8, donde la edicion LXDE para esta distribucion no se inicio asi que es cancelada (Ubuntu y Debian tendran su propia version con LXDE), y la version con Fluxbox, el encargado de mantener esta version ha decidido enfocarse en asuntos personales, por lo cual no habra Fluxbox edition para Linux Mint 7 (y quizas 8).

Ademas anuncian mejoras para las herramientas mintUpdate y mintInstall, asi como mintBackup y mintUpload, propias de la distribucion.
Lastima que esas versiones de Linux Mint no estaran disponibles, que vendrian muy bien en equipos con bajos recursos, y contar con la funcionalidad de esta distribucion. Lo bueno del mundo del software libre es que en cualquier momento puede volver a formarse una version con Fluxbox o LXDE .Alternativas a estas ediciones serian Crunchbang Linux (con openbox), Fluxbuntu (si aun sigue vivo), antiX (con IceWM).

Que opinan

Enlace | The Linux Mint Blog

Though Firefox’ Live Bookmarks are quite useful, I also like to be able to quickly inspect RSS feeds when not using the browser (especially on a netbook, where it takes a while to launch Firefox). As I use the Fluxbox window manager I decided to integrate RSS with the Fluxbox root menu.

The script is written in Python, and provides the following features:

• Command line update function to be used by crontab
• GUI for adding and removing feeds, and setting options
• Simple configuration file for feeds and menu features

The screenshots show the RSS menu in Fluxbox and the configuration GUI respectively.

FluxRSS in action. The feeds can be placed in any (sub)menu of the Fluxbox root menu.

FluxRSS GUI in action. The user can add or remove feeds, and set appearance preferences regarding the menu.

Por padrão, o gerenciador de janelas fluxbox (e outros como openbox) não utiliza a tecla PrintScreen e só conseguimos capturar a tela usando a linha de comando, o que se torna incômodo dependendo do número de imagens que precisamos.

Neste post vou mostrar como setar a tecla PrintScreen para realizar esta função.

Para realizar a função de captura de tela, usaremos o import, que vem no pacote do ImageMagick.

1. Vamos instalar o ImageMagick no Arch Linux:

# pacman -Syu
# pacman -S imagemagick

Existem basicamente 3 tipos de screenshots:
- Tela inteira
- Janela específica
- Região desenhada na tela

O segundo e terceiro itens podem ser realizados com a mesma função do import, já o primeiro item possui parâmetros diferentes. Para automatizar o processo, criei um script que, dependendo do argumento passado, tira a screenshot da tela inteira ou de uma região/janela específica. De quebra é possível definir o local aonde estas imagens (screenshots) serão armazenadas.

O script utilizado pode ser encontrado aqui.

Obs.: Sugestões para melhoria do código sempre são bem-vindas.

Tentei fazer o script bem documentado, mas aqui vai um resumo de utilização:

./screenshot.sh
Captura tela inteira e salva em $HOME.

./screenshot.sh -d ~/imagens
Captura tela inteira e salva em $HOME/imagens.

./screenshot.sh -r
Captura região/janela específica. Nesta opção o ponteiro do mouse vira uma cruz e com ela você pode selecionar a região ou clicar na janela que quer capturar.

./screenshot.sc -r -d ~/imagens
Captura região/janela específica e salva em $HOME/imagens.

Acho que já temos boa uma base do funcionamento do script.

2. Vamos mapear a tecla PrintScreen.
Acrescente no final do seu arquivo ‘.xinitrc’ (antes de carregar o fluxbox) as linhas abaixo:

# Mapea a tecla printscreen como F13
xmodmap -e "keycode 111 = F13"

Isto fará com que a tecla PrintScreen (keycode 111 [1]) seja atribuída ao nome ‘F13′ (não existente, poderia ser outro nome).

Já temos o script salvo e pronto para execução, também já definimos um nome para a tecla PrintScreen. Falta só juntar tudo nas keys do fluxbox.

O arquivo keys [2] (geralmente localizado em ~/.fluxbox/keys) é um arquivo de configuração para os atalhos do teclado. Aqui vamos definir literalmente o que será executado ao teclarmos PrintScreen.

Acrescente as linhas abaixo no seu ~/.fluxbox/keys:

None F13 :Exec ~/scripts/screenshot.sh -d ~/imagens
Mod1 F13 :Exec ~/scripts/screenshot.sh -r -d ~/imagens

Sendo:

Mod1 – Tecla Alt.
Mod4 – Tecla Windows.
Control – Tecla Ctrl.

Na primeira linha estamos definindo que ao teclar o PrintScreen (F13) o script irá capturar a tela inteira e salvar em ~/imagens.

Na segunda linha definimos que ao segurar Alt+PrintScreen o script irá capturar uma janela ou região de nossa escolha e salvar em ~/imagens.

Obviamente deve-se trocar o caminho para o diretório das imagens, assim como para o screenshot.sh.

Referências

[1] keycode – Se quiser saber mais sobre o keycode leia este post.

[2] keys – http://wiki.archlinux-br.org/Fluxbox#Atalhos_de_teclado

script usado no post – http://snipt.net/eddye/script-para-tirar-screenshot/

fonte: http://www.gentoo-wiki.info/TIP_Make_a_Screenshot_with_PrintScreen_Key

Potezna maszyna z pentium mmx 200mhz i 32mb ramu taktowanego zabojczymi 66mhz! Film przedstawia slackware 11 z xmms i atermem pod fluxboxem. System powstawiony w piatek, skonfigurowany w sobote a nagrany dzisiaj ^^

Film :

Screen :

At my office, we have a pair of old laptops purchased back in 2003 or 2004, which are terribly slow, woefully underpowered and horribly outdated, but which we still use periodically.  In other words, they made a perfect target for an OS makeover.

Anyone who has run Windows XP on a P4 with 256MB of RAM should be able to appreciate just how sluggish these machines are.  So with my boss’s blessing, I gathered the two machines and tried to breathe some new life into them.

Before I continue, it would probably be worth mentioning what I need these laptops to accomplish.  In a nutshell, they need to be able to run a proprietary java-based client, run Firefox and open Excel spreadsheets.  The ability to print to networked printers would be a bonus.  Finally, they are intended for a non-technical group used to working with Windows. We are not interested in any sort of in-depth training, we need an interface that is intuitive and gets people directly where they need to be.

Did I mention these machines are agonizingly slow?  I think that may have been an understatement.  Because this is an experiment, I had the luxury of being able to download and test several liveCDs for various distros, and play around with several window managers.  

Just as a point of reference, the Fedora 11 LiveCD took approximately 20 minutes to boot into a usable state (!), OpenSuSE took about 15, and Ubuntu around 10.  (All of the above had Gnome as the default window manager.)

For me, getting the first laptop done as a functioning proof of concept was a priority. With the help of some of the nifty tutorials located on this site, I ended up installing Xubuntu, then switching to Fluxbox for a window manager with idesk to handle the two desktop icons I really needed (the proprietary client and Firefox.)  While Gnome was marginally less slow than Windows XP Pro, and XFCE was tolerable, the Fluxbox solution was downright snappy.  There are still some quirks to work through, but I’m pleased with the results, and, more importantly, so is my boss.

Tinkerer that I am, though, all that meant was that I had one “production” machine, so now I have the time to experiment with making things even better, which means I’m free to try different distros and see how they stack up.  My first attempt was OpenSuSE.  Just to set the stage a bit, I cut my Linux teeth on Slackware back in the late ’90s.   After that, I got my hands on a “light” version of SuSE and decided to play with that for a bit, and found I liked it.  

But Slack remained my distro of choice.  Anyway, since I was given pretty much free rein to experiment, I decided to have a look-see.

Long story short, that didn’t work out so well.  Did I mention these laptops were excruciatingly slow?  Well, apparently YAST isn’t happy with less than 1 GB of RAM, so I went back to the drawing board.  Trent had mentioned to me that he’d heard good things about Mint, so I pulled down Mint 7 and decided to give it a look.

Next Page: Getting Minty
On the previous laptop run, I had fiddled with vanilla Ubuntu for a short time, so I had something of an idea as to how it would look and feel.  With that as my “baseline”, I went ahead and installed Mint, since I had heard it was essentially Ubuntu with some optimizations and a cleaner way of organizing things.  I’m a big fan of things that simplify my life, so I was all in favor of that!

In all fairness, I haven’t really looked “under the hood” that much.  My point of view is pretty much, “having used Ubuntu before, does Mint make it easier for me to do what I need to do, or is it about the same?”  Upon first glance, Mint looked a lot like normal Ubuntu, albeit with a more greenish tinge.  Most things were where I expected them to be, and it only took a brief moment for me to figure out where basic things were (wireless network, sound control, etc.)   So I went ahead and opened the “Menu” menu.

Right off the bat, the interface looked pretty intuitive.  That big “favorites” button includes hotlinks to commonly-used applications (Firefox, Thunderbird, etc.), although I haven’t yet figured out how to change those from the defaults.  (I’m sure I’ll be able to figure it out eventually.)  Coming over from a Windows XP environment, the interface was familiar, even if the purpose of the assorted applications wasn’t necessarily intuitive.

Mint does include a handful of its own applications, independently of Ubuntu.  MintUpdate, for instance, is another take on auto-update, but still uses APT as the underlying engine.  The big advantage to MintUpdate is that it provides more detail on what is being updated, and adds a “safety level” setting, so you can decide the relative risk for performing the update.  For instance, the most recent OpenOffice.org update was rated a “3″, presumably because it’s an outside application from a somewhat reputable source.

MintInstall (aka “Software manager”)  is also worthy of particular note.  It’s another package manager, but the various packages are split into far more intuitive categories.  Additionally, it includes screenshots, thumbnails and community reviews.

So what’s my overall feeling?  I like Mint, I really do.  However, as I mentioned before, these laptops are really, really slow, and Gnome is something of a resource hog.  If I were using a more up-to-date laptop, or had more RAM, Mint would very much be in the mix.  

Unfortunately, the realities of the situation dictate that I have to go lean and mean, and it’s looking like Fluxbox will remain the window manager of choice.  Whether I’ll run Fluxbox on top of this Mint install remains to be seen.  As mentioned previously, the prototype started as a Xubuntu box.

Honestly, I’m still on the fence.  Should I leave my Mint install intact and simply set up Fluxbox as the default WM, or would it be worth walking away and pulling down a minimalist Debian install and going from there?

El Zipit Wireless Messenger (Z2) es una pequeñísima maravilla de U$S 49,99 con un CPU XScale de 300 MHz, pantalla de 2,8 QVGA, ranura para una memoria Mini-SD y 32 Mb de RAM, que sin embargo puede hacer cosas como conectarse a redes WiFi 802.11 B/G y reproducir archivos MP3. Y no menos importante, tiene una activa comunidad Linux que hace cosas como la que se muestran en el video: correr un Kernel 2.6.29 y un entorno Fluxbox con soporte de mouse y audio incluídos (!).

Para hacer lo anterior posible el autor se basa en el trabajo del proyecto OpenZipit, que ya logró construir un Kernel 100% Open Source y su espacio de usuario para la Z2.

Esto me a causado gran entusiasmo y quiero tener una de estas para hacer mis cositas… .. Pero necesito saber si alguien a intentado flashearlo para integrarle full conpatibilidad con mouse, audio y fluxbox…

Segun este video se puede y tambien les dejo un manual en ingles de como hacerlo… pero  no me decido creo que mejor espero a alguien en mi idioma que ya lo haya intentado.. XD:..

EL Enlace .: http://hunterdavis.com/archives/201#more-201

[Hunter Davis] keeps rolling out the hacks for the Zipit. In the past he showed us how to run DOSbox, and then how to get NES emulation working on this tiny device. Now he’s got Linux kernel 2.6.29 running Fluxbox with mouse (newly added), audio, and WiFi functionality. Follow his step-by-step flashing instructions to load the kernel into the Zipit. Once flashed, a partitioned microSD card servers as the filesystem and swap.

Who needs a 10.1 inch screen or an Atom processor when you can get this 2.8″ QVGA beauty with an XScale processor for around $40?

[Thanks Matt]

Fluxbox is a window manager about which I have written a lot. The reason for that is because I use it every day, and I like it a lot. There’s a lot to like. It’s lightning fast, stable, and tweakable to a degree that will satisfy nearly every tinkerer when it comes to window managers.

But one of the biggest barriers to adopting Fluxbox for the “less tinkery” users out there is its configuration learning curve. Yes, Fluxbox is pretty simple when you get over the fact that you have to edit several configuration files by hand to set up your menu, your keys file, and other aspects. But for many users this is a big deal.

For some of those users, the answer to that dilemma is Fluxconf, a package of three applications that can be used to configure Fluxbox graphically.

Installation

Fluxconf is pretty easy to install. Download the source from here and unpack it.

CD into the fluxconf-0.9.9 directory created by unpacking the tar.gz file and perform the following steps:

./configure
su
make
make install

I didn’t have any problems performing the compile and installation on my Slackware box or my Ubuntu laptop.

Usage

As I had mentioned above, this installs three separate graphical configuration utilities for Fluxbox, and I’ll detail each below.

Fluxmenu

Fluxmenu is the most useful out of the three utilities in my opinion, at least for the basic Fluxbox user who just wants to set up a working menu with what they want on it and run with it. The command to launch it is simply fluxmenu, and that brings up a simple screen that looks like the screenshot I included to the right.

Menu items are added by clicking on the “Add exec” button. One thing to be aware of is the fact that the new item will appear below the item you currently have highlighted. Once the blank item appears, you can call the item what you want by entering text into the “Title” field, and then you can enter the command you want it to execute in the “Command/Comment” field just to the right of that. Once you hit the “Save” button, it commits the change and your Fluxbox menu should reflect the changes immediately.

To create a new submenu, click on “Add sub”, and the process is the same.

I didn’t quite understand the point of the “Add clever” button. What it does is add a new item of the same type that you currently have highlighted, whatever that might be. So if you currently have an “exec” menu item highlighted and click “Add clever”, it will create a new “exec” item just below that. If you have a menu item highlighted when you click “Add clever”, it will create a new submenu. This seems redundant to me, but if you’re building a menu from scratch, it might come in handy when adding 20 or 30 items to it, I suppose.

The biggest benefit to Fluxmenu over just editing the ~/.fluxbox/menu file by hand, at least for the newbie, is how it makes the process a bit harder to mess up than doing so with a text editor can be. When you edit the file by hand you run the risk of forgetting an [end] tag or deleting something by accident that can royally break the whole menu — and while I’m not a newbie by any stretch of the term, I still occasionally do this when I get careless. While I know this kind of thing tends to be easy to fix, the average user might just find themselves with a broken Fluxbox and move on to something else.

Fluxmenu makes it pretty hard to do this. The worst thing that could happen in Fluxmenu is that one could accidentally delete something that one doesn’t want gone, and as long as one doesn’t save the session, this is easily recovered.

Fluxkeys

Fluxkeys is a graphical method of creating custom key bindings in Fluxbox, and it is launched with the fluxkeys command. While at first glance it looks pretty confusing and cluttered, a closer examination of it reveals a much easier way to do the deed than the way I ended up doing much of mine by hand. The buttons on the left give you the various operation keys you want to use, and the first textbox column lets you enter the key to combine with it to do what you want it to do.

The real value in Fluxkeys is the next column (the one with the dropdowns). Each one contains all of the various commands/properties you have at your disposal for use in the Fluxbox keys file, so no more digging through the documentation to figure out what you need to put in there to do what.

The last column is where you can enter a command if your custom key binding is intended to execute some other program or action.

After you have everything set up in Fluxkeys, just click on the “Save” button and go to the Fluxbox menu and select “Restart” to apply the changes in your current session.

A lot of Fluxbox newbies probably won’t play around with custom key bindings like this, but since this is one of the biggest strengths of the Fluxbox window manager, it’s likely that they will want to eventually, and Fluxkeys is an excellent way of getting one’s feet wet. I do think that once you already know what you’re doing, it’s probably quicker and easier to just edit the ~/.fluxbox/keys file by hand, but Fluxkeys gives users less familiar with this task a simple way of getting key bindings set up without a lot of Googling around and trial-and-error.

Fluxconf

The third and final utility is launched with the fluxconf command. The actual Fluxconf utility is a graphical interface that can be used to change a wide variety of Fluxbox settings and behavior all in one place, ranging from the Fluxbox Slit, to the toolbar, the clock, focus behavior, and Fluxbox window tabs.

Everything in this particular utility is pretty straightforward and it all definitely works, but I don’t really understand why it’s here… everything that it does can be done from the Fluxbox menu by default, and Fluxconf doesn’t add any particular functionality or clarity to the things it configures, so this utility seems redundant to me.

The only things it makes easily available that might be a bit obscure to the new Fluxbox user is the ability to change the locations of various Fluxbox configuration files, such as the keys, menu, and styles… but again, the new Fluxbox user probably isn’t going to be wanting to change those things, and those of us who are a bit more under-the-hood with Fluxbox will just change those things in ~/.fluxbox/init by hand if we need them to point somewhere else for whatever reason.

Either way, however, it does provide another option for users to configure their Fluxbox, and it’s well-designed and intuitive to use.

Conclusion

Overall, the Fluxconf set of graphical utilities for Fluxbox are a lot like Fluxbox itself. They are simple, lightweight, powerful, and don’t make assumptions for the user, but are still quite easy to use. The project doesn’t look like it’s been updated in a couple of years, but at the same time, I’m not sure what would need updating in it.

In my evaluation of the three, I’ve added all three to my Fluxbox menu so that they can easily be launched, and I’ve been using the Fluxmenu tool lately (just out of laziness) whenever I’ve needed to change my menu, so I suppose you could say that at least one of the three utilities has grown on me. I have my keys file already pretty much the way I like it, but I do think that if I need to add anything to it or change anything, the Fluxkeys utility will come in very handy.

When I’ve examined the config files each utility manages after the fact it doesn’t appear to trash any of them or do anything horrible to them (like some graphical configuration utilities tend to do), so it doesn’t require lots of cleanup if you want to use one of them for a while and go back to using a text editor.

So, whether you are a Fluxbox newbie or a seasoned veteran, this set of utils is worth a try in my opinion, and to my knowledge it’s the only graphical Fluxbox configuration toolset out there, so it’s either this, or your favorite text editor. Enjoy!

This isn’t so much a review, just a rambling discussion on what comes to mind for me about Ubuntu after using it on my laptop for three months or so. I decided against writing a conventional “review” of Ubuntu… seems like there are enough of those, so I don’t see the value of it.

But I do see some value in a rambling discussion on the subject, so here goes.

Why Ubuntu?

I installed Ubuntu on my laptop back in June, since I needed to wipe it and rebuild anyway. I thought it was time I gave it a try, particularly since I wanted to give my own Linux experience a little more focus.

I thought, philosophically, that I’d split most of what I wrote about here on Linux Critic into two distros, more for simplicity’s sake than anything else. I figured I’d write about Slackware from a more technical perspective, for people who want to tinker, and I’d write about Ubuntu for people who are Linux newbies, or non-technical, or just don’t care so much about getting under the hood.

The best way for me to know what I’m talking about is to use it, and though I’ve been a Slackware user for years, I had never touched Ubuntu.

I installed Ubuntu 9.04 on my laptop pretty much accepting most of the defaults. I wanted to know what things were like out-of-the-box before I started tinkering with it, and as such, I forced myself to use GNOME, since it was the default desktop.

Since I was going to be writing howto posts and waxing philosophical about window managers and desktop environments, and since it had been quite a while since I had bothered to use GNOME, I thought it a good idea to re-acquaint myself with it.

What I ended up doing with it, and why

I’ll do a little recap as I go along here, so as to catch anyone up that hasn’t been following me.

One of the first things I did was make GNOME a little more conducive to to how I like things arranged. I discovered that GNOME had been improved in some ways since I last tried it, but, sadly, it had been made worse in some ways that bothered me quite a bit, namely in that the developers had oversimplified many things to the point of making them useless.

Frustrated by the lack of basic options in many things, and noticing how sluggish it ran on my aging laptop, I decided I’d flogged GNOME enough and I installed and configured Fluxbox to use instead, since Fluxbox is the fastest window manager I’ve ever used, and I’ve had good luck with it on this same laptop in the past.

That came with its own issues, of course, but many of those issues were simply problems or deficiencies in how it was packaged in the APT repositories, and after some additional troubleshooting, I shook out the rest of the issues in short order and had Fluxbox working pretty well.

Over the course of looking into alternate window managers, I came across Openbox and decided to give that a try. As it turns out, Openbox is very Fluxbox-like, and I found that I really liked it, and as it turns out, that’s what I’m still running on my laptop, even though I finished my evaluation for it for my article.

So as you can see, in going from GNOME to Fluxbox and finally to Openbox, I’ve put Ubuntu 9.04 through some motions, and I think in doing so I’ve looked under the covers quite a bit, and that’s given me a pretty good feel for what Ubuntu can and cannot do, what it does well and what it does not so well.

What I think about this whole mess

I said this wasn’t going to be a review, but I still think my opinion is relevant; it’s just not quite so formalized as I think most people expect from something labelled a “review”, so I would still like to avoid that term.

I’m pretty impressed with Ubuntu, to say the least. I’m a Slackware guy, and have been for years, and the primary reasons for that have been expressed by me in many other posts here: stability, reliability, simplicity, usability, and the simple fact that it stays out of your way.

While I’ve had to do some kind of crazy things to get Ubuntu to behave itself in some cases (like the gymnastics I had to go through on Ubuntu just to disable the touchpad on my laptop, as just one example), you have to remember, my view of “how to do things” is heavily colored by my ability in Slackware to simply edit one file, tweak one or two things, and have it do what I want it to do. I’m not used to the “here’s how we think things should work” vision the makers of Ubuntu have (which apparently doesn’t include a way to disable a laptop touchpad without a whole lot of extra work), so I’m always contrasting the two, whether I intend to do so or not.

For every problem I encountered, I eventually found an acceptable solution. For every piece of quirky behavior, I at least found a workaround, if not a satisfactory way to shut it off or change it. For every bit of flaky behavior (like the tendency for Ubuntu to hang on boot while doing its file system check every so often) there was a way to deal with it (I shut off the boot screen graphic in GRUB).

I can’t fault Ubuntu for any of these things… I can’t even imagine how many countless hours I’ve spent figuring things out that don’t work in Slackware; it wouldn’t be exactly fair for me to tear Ubuntu to shreds over the things I’ve encountered that were less-than-perfect. So I won’t. Every distro, I’ve discovered, has its quirks and its faults, and Ubuntu has plenty. But as I said, every one of them I encountered was something with which I could work. There weren’t any showstoppers among them.

One GOOD thing that stands out above everything else is APT. What a time saver THAT is. Yes, I’ve used it some here and there before, and in Slackware I use slapt-get to update my system and install the occasional package, but there’s almost no comparison. APT wins. Hands down.

For one example of how APT wins, just this morning I was busy evaluating music player software for Linux, trying to find a suitable replacement for Amarok. I looked at Rhythmbox, Songbird, Banshee, and Exaile, NONE of which — not a single one — could I get working on Slackware when I tried to do so a couple of weeks ago. Not at all.

But on my Ubuntu laptop, each one (with the exception of Rhythmbox, which was already installed there) was a single apt-get install command away. I was able to evaluate all of those applications in about an hour on my laptop.

On Slackware, a couple of weeks ago, after an hour of fighting with dependencies for EACH APPLICATION, I had given up on all of them without trying a single one.

So I can definitely appreciate the power of such a tool.

The documentation and the community are also quite good for Ubuntu, which contributed quite a bit to my earlier statement about not finding any problems I couldn’t eventually resolve. With the help of a few quick Google searches, I was able to find what I was looking for time and time again, and there’s a LOT of value in that.

Conclusion

So, I’ve banged Ubuntu around for a few months, shaken out all of its oddities, and filled my head with Ubuntu knowledge and learned its ways. What next? Move on to something else?

In a word, no. Ubuntu will be staying here, on my laptop, for the foreseeable future. I like Ubuntu, as I’ve discovered. And, since I’ve started recommending it to others, people for whom I provide ongoing computer support, I now need Ubuntu as well. It’s a lot easier to walk someone through something or troubleshoot something if you actually use it and have it in front of you. So no, Ubuntu isn’t going away. In fact, with my having begun to lose faith in Slackware lately, and with as good a handle as I feel I have on Ubuntu now, I might even be installing it on my main desktop at some point in the near future as well.

I had a lot of preconceived notions about Ubuntu, I’ll freely admit that. One of the main things that turned me off of it for so long was GNOME, and while I definitely still find GNOME to be counter-intuitive, sluggish, oversimplified, inflexible, and hard to work with, I also discovered that it’s easily discarded and replaced with any number of other window managers that do the trick for me. Underneath it all is a robust, well-supported, well-documented, and easy-to-maintain Linux operating system, and I found that I really enjoy using it, tinkering with it, writing about it, and showing it off.

So I took a bit of a journey myself; I went from just testing and playing with it to actually using it and then deciding to STICK with it, which impresses the hell out of me. Frankly, I haven’t been impressed by a Linux distro since I first started using Slackware. Most of the time, when evaluating a distro, I kick the tires, use it for a while, might see some good things, but still ultimately decide “it’s nice, but it sure isn’t Slackware” and don’t see it as good enough to replace Slackware as my main Linux distro.

For the first time in years, that has happened for me, and I’m very surprised to say that the distro with which that happened was Ubuntu. Combine that with what I’m seeing as some pretty good reasons to drop Slackware as my distro of choice going forward, and there’s a good chance that I might have found my new favorite Linux.

Chi usa screen (nota applicazione per Linux) saprà che permette di splittare la sessione per aprirne un’altra.

Questa feature però può essere utilizzata solo in orizzontale, cosa che con molte sessioni può risultare scomoda.

Bene vediamo come aggiungere lo split verticale in screen:

• Andiamo su http://ftp.gnu.org/gnu/screen/ e scarichiamo i sorgenti dell’ultima versione di screen.
• Dopo averli scaricati estraiamoli (avremo la cartella screen-xx).
• Scarichiamo la patch che trovate quì: http://fungi.yuggoth.org/vsp4s/ , avremo nella directory un file chiamato wrp_vertical_split_0.3_4.0.2.diff.bz2 , estraiamolo in modo da avere wrp_vertical_split_0.3_4.0.2.diff (estrarlo con bunzip2).
• a questo punto la parte importante, digitate su e mettete la password di root, entrate nella directory di screen appena creata e digitate questo:
patch -p1 < ../wrp_vertical_split_0.3_4.0.2.diff

  se tutto andrà bene avrete una risposta di conferma che dice che i file sono stati patchati.
• sempre da root adesso digitate:
  
./configure --prefix=/usr && make && sudo make install

  Per compilare e installare la nuova versione di screen patchata.
• Riavviate e avviate nuovamente screen, adesso per vedere se la patch ha funzionato (quindi per fare lo split in verticale) premete CTRL + a e successivamente SHIFT + V ; dopo spostatevi con CTRL + a esuccessivamente TAB ; e premete CTRL + a e successivamente c per creare una nuova sessione.
• Ecco a voi il nuovo screen con lo split in verticale.

Dopo sarete liberi di cancellare la dir appena creata di screen e il file .diff.

Questo è un piccolo esempio che ho realizzato (La mia fluxbox):  http://img2.imageshack.us/img2/3739/screeniw.png

Spero che questa guida vi sia utile per il vostro screen

]]> http://linuxcritic.wordpress.com/2009/08/28/the-first-time-ive-ever-been-disappointed-by-slackware/ Fri, 28 Aug 2009 23:05:25 +0000 Trent http://linuxcritic.wordpress.com/2009/08/28/the-first-time-ive-ever-been-disappointed-by-slackware/

DISCLAIMER: Be prepared. There is whining ahead. I want to preface this by saying that I’m not interested in having a discussion about why I don’t gush with love over KDE 4, and I’m not particularly interested in suggestions for forcing it to work for me. This post is more about me wrapping my head around planning for how my use of Linux is going to change now that I’m going to have to re-think a lot of things about what has been my favorite Linux distro for years.

Why I’m disappointed

I guess I probably shouldn’t be too surprised, because I knew that Pat Volkerding has been working with my least favorite desktop environment and it’s been in /current for a while now.

But I guess a part of me still was holding out a childish hope that KDE4 was going to be included in /testing only, and that the default version of KDE for the Slackware 13.0 release would be KDE 3.5.10, the last decent release of that desktop environment. Given Patrick’s tendency to play it safe in regular Slackware releases and stick with only stable, fully-developed and thoroughly tested applications and desktop environments, I would have thought that something like KDE 4 — a desktop environment that’s still easily a year’s worth of hard development away from being a suitable replacement for KDE 3 — would be back-burnered in Slackware in favor of what is known to work and work well.

I probably shouldn’t be upset about this; it’s Linux… if I don’t like it, I can just make my own distro, right? If I want to spend the hours and hours it’ll take for that, sure. Well, I’m not to the point of making my own distro yet. But this does mean I’m going to have to significantly change my Linux usage, starting with replacing a bunch of stuff.

Finding a replacement is hard

Unfortunately, I’m not sure where to go now. I’m in the process of downloading the Slackware 13.0 ISO right now, but my plans have already changed for it. Initially I had intended to burn the ISO to DVD and upgrade my primary desktop machine from Slackware 12.1 to Slackware 13.0.

However, after this bad news, there’s not a chance of that happening now. I have absolutely no use for KDE 4, and I was going to be switching back to KDE as my primary desktop environment again once Slackware 13 came out, because I figured it’d be the last version I’d be needing for quite a while.

But now, before Slackware 13.0 sees life on any of my real hardware, it’s going to be virtualized for me to poke at it with a stick first. For the first time, I’m now skeptical of the rest of Slackware as well, because this KDE thing is just too much of a deviation from what I’ve come to expect out of this distro, and I don’t want to start blowing away the Slackware 12.1 installation I have living on my primary machine in favor of something that’s going to take me a lot of work to bring up to usable levels without doing some testing first.

For one thing, I’ll be needing to replace some components that are now going to be missing out of Slackware due to a lack of KDE 3.

Window manager

I won’t be installing KDE 4, that’s for sure. I won’t be using it, and I don’t need it wasting space.

Now I’m glad I’ve spent the past few months reacquainting myself with Fluxbox; at this point, if I want to run something newer than Slackware 12.1 or 12.2, I’ll be needing that comfort level with Fluxbox. Fluxbox is something that I like a lot… it’s lightning fast, very stable, flexible, incredibly tweakable and incredibly customizable on nearly every level, and that flexibility, tweaking, and customizing is very easy to do in Fluxbox. In short, it’s nearly the exact opposite of KDE 4.

I can live with Fluxbox; it’s quite possible that even if Slackware 13.0 had included KDE 3.5.10, I may have ended up using Fluxbox as my main environment down the road anyway, because I do like Fluxbox that much.

But now I don’t really have much of a choice. For all the talk of a fork last year when KDE 4 was foisted upon us, nobody to my knowledge has since done anything worth mentioning with respect to a fork based on porting KDE 3 to Qt4, and, frankly, doing so myself would be getting me in way, way over my head. I’ve done some poking around, and the task of getting KDE 3.5.10 to work on Slackware 13 just seems like far more trouble than it’s worth.

So that means I’ll be using Fluxbox, plain and simple. Like I said, I can live with that. But the loss of some of the KDE apps that I’ve grown to love will hurt. Which brings me to my next subject.

Applications

I just don’t know what I’m going to do about some applications. While I’ve grown pretty comfortable using Fluxbox again, I still haven’t managed to shake my dependence on several KDE applications, such as Kontact, the Konqueror file manager, and most of all, Amarok.

I’ve done some testing (because I’ve been afraid of this day coming) and I can probably live with Thunderbird for mail and XFE for file management.

Thunderbird doesn’t do calendaring without a couple of add-ons, and it isn’t as robust as Kontact, but it’ll do, at least until I find something better.

XFE is faster than Konqueror, lighter weight, and pretty flexible… I just really wish it had tabs, damn it! That’s the one thing it’s missing that I’m really going to wish I had going forward. I use tabs in Konqueror all the time… it’s a very efficient way to do file management, and while some other file managers have tabs, most of them suck in ways that XFE doesn’t. When it comes down to it, I’d rather have everything else not suck and live without tabs than the other way around.

But Amarok, I just don’t know. I’ve had pretty awful luck getting a lot of other players working on Slackware (such as Rhythmbox, Banshee and Songbird, for example. All three were an exercise in dependency hell), and I really like Amarok a lot better as far as full-featured music players go (I’ve tried them out on my Ubuntu machine, I just couldn’t get them working in Slackware). Nothing against Xmms or anything, it just doesn’t do as much and I’ve gotten spoiled over the past few years with Amarok.

So I really don’t know where I’ll end up when it comes to music players. I’ll probably give one of the other ones a try that I couldn’t get working before, and just make do, like everything else.

Changing distros

Of course I have another option available to me, one I didn’t want to think too much about: I’m talking about abandoning Slackware entirely and moving on to a different distro. Considering how many other distros have also jumped on the KDE 4 bandwagon prematurely, I’m not sure what that’d get me. If my testing doesn’t find anything goofy or flaky with Slackware 13.0, I can guess I’ll probably still prefer Slackware for everything else despite the KDE 4 thing.

I have given Debian some thought, but I know they’re in testing with KDE 4 as well, even though the current regular version is KDE 3.5.9, so that wouldn’t help much. One nice thing about Debian is APT, with which one could easily install KDE 3.5 after doing a barebones install; that would be a heck of a lot easier to do with APT on Debian than it would be trying to do by hand with Slackware.

As long as KDE 3.5.* is maintained in the APT repositories, Debian could be a viable option going forward, at least until someone spins off a Slackware distro without KDE 4 as a part of it — and no plans to include it in the immediate future.

In my recent experiences with Ubuntu, I’ve learned to appreciate APT as a packaging tool, though I think if I were picking a Debian based distro to go with as my primary desktop OS, I’d probably just go with Debian itself rather than Ubuntu. I’m not completely finished assessing Ubuntu yet, but already I can tell you that I prefer a less in-your-face distro. A lot of what I’ve done on my Ubuntu machine has been disabling most of what it does that gets in my way… something tells me that doing a barebones vanilla Debian install and then adding on only specifically what I want would give me something close in terms of stability and usability to what I’m used to in my years of running Slackware.

I know, there are a lot of other distros out there yet to try, many of which are Slackware based and many of them DON’T have KDE 4 as their default desktop environment (yet).

I might have to do some more research and take a look at the myriad Slackware spinoffs out there and see if any of them are worth moving to permanently. If any of you can suggest a good Slackware based distro that packages KDE 3.5.9 or 3.5.10 as its desktop, I’d love to hear it.

Until then, I’ll be sticking with what I have. Slackware 12.1 has been excellent on this machine; I was looking forward to upgrading it, but since in doing so I’ll lose the use out of some of my favorite applications, I don’t really consider that an “upgrade” at this point, so 12.1 it is!

In exploring a renewed interest I’ve developed in Fluxbox recently, and spurred by some new stuff I learned from reading Patrick’s wonderful Fluxbox tweaking post a couple of weeks ago, I thought I’d do a writeup on another capability that Fluxbox has that I’ve never delved into: dockapps.

Fluxbox has as a part of its toolbox a friendly home on its desktop for dockable utility applications that can provide information, handy functionality, and even dress up the otherwise normally spartan Fluxbox user space. I don’t use many dockapps, but it’s worth using the ones I have as examples in this writeup, if nothing else just to demonstrate how to set this up and take advantage of this capability.

So in this post, I’ll be discussing three dockapps: GKrellM, WMix, and WMWeather.

Obtaining and installing GKrellM, WMix, and WMWeather

GKrellM is a versatile and useful source of information about your own system. It’s a vertical application, so it doesn’t take up valuable space, and it’s themable and highly configurable. I like it because it can tell me if my aging CPU is running hotter than I like, and it can tell me if there’s any unusual disk activity or if I’m suddenly running critically low on memory resources.

WMix is a useful little volume control application that allows the user to raise and lower volume simply by mouse wheeling over it. It can easily cycle through the various channels too, so with a click or two you can switch from your master volume to PCM to CD volume. In Fluxbox I used to use Kmix (KDE’s default volume control applet), but since I’ve been moving away from KDE lately, I figured I’d hunt for something else, and found that WMix fits in well with Fluxbox as a dockable app, and works great on top of it.

I’m also used to having a weather widget of some sort, having grown accustomed to KDE’s default applet in that department too. In my search for a suitable Fluxbox-friendly alternative, I came across WMWeather. WMWeather can be pointed at your weather information resource and give you basics like current temperature, dewpoint, humidity, wind speed, and even wind chill (if you live in place where that matters, like I do). Like WMix and GKrellM, WMWeather is also docakable, so it lives happily in the Fluxbox slit like the others.

Installation

If you’re running Ubuntu, you can install all three of these applications by opening up a terminal and running these commands, one at a time, and go through the normal apt-get process for each:

sudo apt-get install gkrellm

sudo apt-get install wmix

sudo apt-get install wmweather

If you’re not running Ubuntu or another Debian-based system, you’ll likely need to download and install these applications manually. I’ll be a nice guy and save you guys some hunting around by linking them here. All of these used to be readily available from Dockapps.org, but that site seems to have vanished, so this should save you some trouble.

GKrellM: Many distros package a version GKrellM out of the box, but just in case, it can be downloaded at GKrellM.net. There are packages available for a variety of different distros and architectures (there’s even a Windows installer), or you can download the source code and compile it yourself.

WMix: A big list of download mirrors is available here. Since I’m not sure how many of those still work (a few of those look pretty old), you may end up searching around the web some more for it like I did, otherwise I have it hosted on my web server here for your convenience. The file is the source code for it, so it’ll need to be compiled and installed.

WMWeather: I ended up downloading the source code for WMWeather from here, mostly because I couldn’t find it anywhere else. If that fails for whatever reason, like WMix, I have also uploaded the source code for WMWeather to my web server here to download at your leisure.

Configuration and Tweaks

If you’re playing around with Fluxbox at this level, I’m assuming you can probably handle extracting, compiling and installing those apps from source, so forgive me if I’ve leaped forward over that bit. I can provide some more instruction on that if need be, just post a comment and I’d be happy to help you out… it isn’t as hard as you might think, even if you’ve never done it before.

But once you have all three installed, you can configure them.

GKrellM is very themable; I frequently switch themes on mine, all of which I downloaded from Muhri.net. Any GKrellM theme can simply be extracted into the /~/.gkrellm2/themes directory. You can switch themes by right-clicking on GKrellM while it’s running and selecting “Configuration” and then “Themes”. If you put the themes you downloaded for it in the correct place, they should appear in the list of available themes from which you can choose.

The rest of the configuration options in GKrellM are pretty self-explanatory, once you’re in the Configuration window. Play around with it. You’ll find that there’s a lot you can do with this handy application. One thing you’ll want to make sure of, however, if you’re going to be using GKrellM as a docked application, is that the “Set window type to be a dock or a panel” checkbox located on the “Properties” tab under “General” is unchecked. I’ll get into more of this later.

WMix doesn’t require any configuration; it pretty much runs as-is. There’s no config file for it of which I am aware, and its usage is pretty intuitive.

WMWeather gave me a little trouble at first. It is configured via a plain text config file cleverly labelled wmweather.conf. However, unlike on my Ubuntu machine, where that file was simply located in /etc/wmweather.conf, I disovered that editing that file on my desktop computer did absolutely nothing, had no effect whatsoever on the behavior of the actual application.

I poked around a bit and discovered that the config file that actually needs to be edited on my Slackware box was located in /usr/local/etc/wmweather.conf. Make a note of that. You may want to disregard the one in /etc/.

At any rate, the very first thing you’ll want to do to that file is enter the four digit designation for your local weather information resource. Go to the NOAA.gov site recommended in the config file and look up what that should be for your location. Then edit wmweather.conf and enter that after where it says station = (mine is simply “KSTC”).

Below that, in mine anyway, metric was set as the default for some reason. I commented that line out with a “#” in front of metric, saved my changes, closed the file, and when I ran WMWeather it displayed everything the way I wanted it.

There are other things you can do with WMWeather that I haven’t gone into or even tried (I decided to keep mine pretty basic). Check out the man page for WMWeather for more info, or simply go to a terminal and type man wmweather and you’ll find lots of stuff to read.

Now that we’ve got all three installed and configured, we need to get Fluxbox set up so that it knows what to do with them.

Next page: Where the dockapps live: the Fluxbox slit

Where the dockapps live: the Fluxbox slit

In Fluxbox, there is a home for these kinds of “dockable” applications, and it is known simply as the “slit”. I generally tend to think of the Fluxbox slit as a spot — like a tiny, narrow corkboard — where I can use a stickpin to attach something useful.

Before proceeding with anything else regarding the slit, you’ll want to familiarize yourself with its options by right-clicking on your Fluxbox desktop to get your Fluxbox menu, go to your Configuration section, and find the “Slit” submenu. From there you can control where the slit is placed (I have mine set to “Bottom Right”) and other options. Go through these options and decide where you want these dockapps to be. You can always change it later if you don’t like what you end up with.

The Fluxbox slit is managed simply by a text file, much like everything else in this window manager. The file is /~/.fluxbox/slitlist, and it can be edited using any text editor with which you are comfortable. However, you shouldn’t need to do anything with it just yet. The slitlist file will self-populate (in theory), if everything else runs correctly.

So, the first thing you should do to accomplish this is open up your ever-present /~/.fluxbox/startup file in your favorite text editor, and add the following three lines to it:

gkrellm -w &
wmix &
wmweather &

The “-w” after gkrellm tells it to dock to the Fluxbox slit (which is why I advised not setting GKrellM in a “docked” state in its configuration before).

Save your changes and exit out of Fluxbox and log back in, and all three applications should be running in the slit, stacked like the ones in my screenshot on page one of this post.

I had a little trouble with the order of mine at first, so if you’re picky about that, you can edit the /~/.fluxbox/slitlist file and switch the order around. What I actually ended up doing was creating a separate slitlist, to keep my order from being overwritten by Fluxbox itself. If you need to do this, simply open up /~/.fluxbox/slitlist, save it as /~/.fluxbox/myslitlist, and then edit /~/.fluxbox/init.

In the Fluxbox init file, find the line that designates where the slitlist file is located. It should say session.slitlistFile:. All I did with mine was change the word “slitlist” the the subsequent path to “myslitlist” and saved it.

After that, I arranged the apps in myslitlist to the order in which I wanted them (the same order I gave them for the startup file, above), saved it, exited out of Fluxbox and logged back in, and everything was where it should be.

Other dockapps

I can’t speak much of other dockapps, as I haven’t used any besides those I just discussed, but I know that there are other applications out there that can do CPU monitoring, thermal monitoring, mailbox checking, and other useful tasks. Since I use GKrellM, which does a lot of that already, I decided just to stick with that, but most of its individual functions can be replaced by several dockapps. Do a little searching around and I’m sure you’ll find plenty to keep you busy in that department.

As always, if you have any questions or trouble, I’d be happy to help out… just post a comment and let me know!

Happy hacking!

I was looking around for ideas for something to write up today, so I asked a friend of mine about his most recent Slackware setup experience. He told me, “my sound isn’t working at the moment, but I really haven’t delved into that at all”.

Which got me thinking. This is a common question among people who are using Slackware and aren’t that intimately familiar with it. I know, this has been written up about a billion times, but not here, and it’s a nice basic HOWTO that I think really belongs on Linux Critic.

Step one: Configure ALSA

On a fresh Slackware installation, ALSA — the default sound engine for Slackware — isn’t usually configured.

So our first step is to open up a terminal and type su, enter your root password, and then type the following arcane command:

alsaconf

This will bring up a pretty easy to use, menu-driven configuration program that looks like this:

Follow the bouncing ball in the alsaconf program, let it figure things out, select your sound card, and you should be good. I’ve run this on a wide variety of hardware, and I’ve never had problems with this part, assuming there’s actually a sound device on the actual machine, of course.

Step two: Unmute your sound channels and set volumes

The next step is to undo the defaults of things in the sound world. For some reason, the default position for the master volume and the PCM volume is 0%, and by default both of those channels are muted in my experience.

This has led to numerous people banging their heads on their desks while screaming, “I got everything configured, it sees my sound card BUT I STILL HAVE NO SOUND!”. This is understandable, I was burned by this when I first started using Slackware too.

To remedy this, in that terminal again, type exit so that you’re no longer typing commands as root, and then type the following command (as your regular user):

alsamixer

This should bring up a screen that lets you use the arrow keys to set the volume levels on the various channels your sound device has built into it.

If you hit the “up” arrow, you’ll find that you can raise your master volume channel (which should be the first one) to the desired level, and by hitting the “right” arrow, you can switch to the next channels and do the same for each of them.

Now, one thing you’ll notice is that you may have “MM” at the bottom of some channels, like this:

Any channel that has this “MM” designation is muted. To unmute a channel, arrow over to it and simply hit the “m” key, and the “MM” should go away and you’ll have sound on that channel.

Once you’re done unmuting things and setting volume levels, simply escape out of this screen and you’re back to the command line, ready for the next step.

Step three: Save what you’ve done

In our final step, we need to tell ALSA that you’re not kidding about the volume settings, and that you want it to remember this.

To accomplish this task, still in your terminal, type su and then your root password again. Then type the following command:

alsactrl store

And that’s it. This tells ALSA to save the current state, and the system should remember this state every time you reboot. If you’re running KDE, you can adjust volume levels with Kmix, which is a standard KDE applet that can live in your tray in KDE. I say this just so you don’t think that you have to open a terminal and run alsamixer every time you want to adjust your volume (though you can if you really want to, or if you’re not running X, for some reason).

An additional step is sometimes necessary if you’re running Fluxbox; if you want your settings restored every time you boot, you may have to edit your /~/.fluxbox/startup file and add the following line to it:

alsactl restore

This isn’t always necessary, but I’ve found that sometimes it is, so your mileage may vary as well. As a rule of thumb, if you don’t like what is happening with your sound levels when you get into Fluxbox every time, adding that line to startup at least puts it in a state that you want right off the bat.

Do let me know if you have any questions regarding this simple procedure. As always, there is of course lots of variation from machine to machine out there, but I’ve never had sound problems (on working hardware) that this couldn’t cure on a fresh setup. In some cases, when sound has mysteriously stopped working, going through this three step process can get it working again, so don’t be afraid to run through this on a machine that has already been working for a while.

By popular demand, I downloaded, installed, and worked with the new Hannah Montana Linux distribution, and decided to post a review of this product, as well as some tips and tricks on how to get the most out of this niche Linux distro.

To aid the reader in following this review visually, I have taken numerous screenshots and included them here.

Downloading

I was able to download the ISO for HMLinux from the Sourceforge homepage of it. I downloaded “v2″ of it, using Bittorrent. It downloaded quite rapidly, only taking 15 minutes or so, leading me to believe that it is well-seeded as a torrent.

The ISO is a combination LiveCD and installation CD. I think it’s nice when distro developers/packagers do this, as it gives one the chance to see if the distro is going to work on one’s hardware simply by booting from the CD, and making that determination BEFORE one actually has to install anything to the hard drive.

Setup and installation

Since I don’t have a spare machine at the moment which could have served as home for Hannah Montana Linux, I opted instead to virtualize this installation. To this end, I used Sun’s VirtualBox, version 3.0.0, setting up the virtual machine with 387 MB of RAM, 64 MB of video memory and an 8 GB expandable virtual hard drive. I realize that this is probably insufficient hardware for purposes of a review, but it occurs to me that a Linux distro should be able to run on limited hardware as well as the most advanced.

Therefore, I make no apologies for virtualizing this machine in less than optimal conditions; the onus of stellar performance, it is my belief, lies upon those who package and distribute a Linux distro.

I mounted the ISO and had the virtual machine boot from it like I would a real computer utilizing a real installation CD. There, I was given the option to boot into the LiveCD environment, or “install to computer” (I selected the latter).

From there, the installation process moved on to a graphical environment that had me select my language, time zone, and preferred keyboard layout (all in a garish light purple, I might add).

It allows the user to select any customized partitioning options, or, as I did, one can select the default partitioning options. The next step asks for user information — user name, what password you would like that user to have, and what you want for the computer name/hostname. I entered “trent” as my user name, and I selected “hmlinux” as the hostname.

I considered this a good sign (the fact that it asked me to set up a password), as some Linux distros default to auto-logins, which is inherently insecure.

By the partitioning dialogue, it appears that Hannah Montana Linux utilizes ext3 as a filesystem, which I find to be quite acceptable.

Once all of these options are decided (which is a pretty painless process of question and answer where one can very safely just accept the defaults for most of these options), the actual installation runs. For me, on the virtualized hardware installing from a mounted ISO file of the LiveCD/installation CD, this part of the process took merely 12 minutes to complete, a fact with which I was impressed.

Overall the installation and setup of Hannah Montana Linux is very easy, very user friendly, and very fast, all three of which merit a thumbs up in my book.

Running Hannah Montana Linux

After the installation, it asks for a restart, upon which I unmounted the ISO image and restarted the virtual machine.

I could see on its first boot that it uses GRUB as its default boot manager, which isn’t surprising, as Hannah Montana Linux is based off of Kubuntu, which also uses GRUB.

It brought me to a login prompt, as I had suspected, where I entered my password and arrived at the default Hannah Montana Linux desktop, which appears at right.

The desktop starts up with a short piece of audio that is presumably from the Hannah Montana repertoire.

Hannah Montana Linux uses KDE 4.2.2, and there is no other window manager or desktop environment installed, so what you see is what you get as far as the user environment goes. My primary aesthetic problem with Hannah Montana Linux is related to the version of KDE which the makers of this distro decided to use. The main toolbar/panel is just too reminiscent of Windows 7’s ugly toolbar; I’m of the opinion that a Linux desktop environment shouldn’t waste time copying Microsoft’s efforts. A better choice for Hannah Montana Linux’s desktop would have been KDE 3.5.10, which is much more robust, much more user friendly, and far more stable.

For some reason, this interface has no desktop shortcuts or applications readily visible, but it instead opens with the “Desktop” folder in a separate window. I couldn’t figure out how to make actual application shortcuts on the desktop, but I could make them in the separate desktop window. This is a very puzzling way to do things, and it may hinder some less computer-savvy users’ ability to use this environment.

Applications can, however, be accessed via the menu in the lower left-hand side of the toolbar, like so:

I found the menu to be nearly unusable; in order to find anything in it, instead of wasting time fumbling around, I simply used the “search” function to find any of the applications for which I was looking.

In my poking around, I found that Hannah Montana Linux ships with the 2.6.28-13 Linux kernel. It also ships with no browser to speak of except Konqueror, which I found to be unsatisfactory and insufficient. A functional Linux distro should at least ship with a recent build of Firefox!

Problems and solutions

Like Kubuntu, however, Hannah Montana Linux is Debian based, so it uses apt-get as a packaging tool.

Since this wonderful tool was available at my fingertips, I decided to remedy the browser situation by installing Firefox via apt-get.

However, about halfway through the installation of it, the entire machine locked up (the Hannah Montana Linux machine, not my host machine) and was completely unresponsive. I rebooted, tried again, and crashed a second time while trying to install Firefox from apt-get.

Since there was apparently a problem installing software via apt-get while KDE was running, I logged out, selected the “console login” option, and logged in command line only. At that point, I decided I had had enough of the KDE 4.2.2 instability and usability issues entirely, so I utilized the command console to install Fluxbox via apt-get, a much more stable, resource friendly, configurable, and in my opinion user friendly window manager than KDE has become.

Hannah Montana Linux, properly configured

Once I had Fluxbox installed and configured, Hannah Montana Linux was a dream. Fast, stable, and user friendly, I was able to perform normal tasks without any issues or crashing (though attempting to install Firefox via apt-get still locked up the machine, even though I was able to eventually install it manually from a download without any problems).

I installed aterm to use instead of the much heavier/bulkier Konsole, and XFE to use as a file manager instead of the rather ill-designed Dolphin file manager, and things moved a long quite well on the rather limited resources I had allocated this virtual machine.

Along with some custom user styles, some new wallpaper, and utilization of the Fluxbox fbsetbg command, I finally had Hannah Montana Linux properly configured, as you can see below:

Conclusion

Hannah Montana Linux, while it has a seemingly stable underpinning of a Debian based Linux architecture, needs some work. Its default desktop environment is barely usable, very unstable and buggy, and has a selection of applications that are, in this reviewer’s opinion, sub-par for any serious computer user.

However, with a little bit of effort, the desktop environment can be easily replaced with a faster, more stable one, and other applications can be installed and configured to make even this relatively quirky Linux distro a robust environment that can be used for programming, heavy software development, or writing Linux related blog posts reviewing odd Linux distributions.

As always, your mileage may vary.

Continuing with my attempt to document the problems I’ve run into running Fluxbox on top of Ubuntu 9.04 and their solutions, I figured I’d present two more things I’ve encountered and resolved since the other day’s rather annoying touchpad fiasco.

These two were both relatively little things, but they’re the kind of things that tend to drive me nuts. The first was a problem with the screen automatically locking (using Xscreensaver’s built-in lock function — even though I had all such functions disabled), and the second was an issue with sound being muted and the master volume being set to 0% every single time I rebooted — necessitating my manually unmuting it and raising the volume if I wanted sound every day.

Closing the lid locks the screen

This one bugged the crap out of me, I won’t lie. It’s a little thing, but the simple fact that everywhere I looked showed screen locking to be disabled, unchecked, not turned on, drove me nuts!

I finally came to the conclusion that this had to have been something related to a power management setting — not an Xscreensaver problem — since it only seemed to happen when the lid closed. I know that shutting the lid on a laptop can trigger certain power events, whether they’re screen locking, suspend/hibernate functions, or simply screen blanking or backlight power management.

I found that I could get into the GNOME power management screen in Fluxbox by typing gnome-control-center in a terminal, then clicking on the power management icon in that window.

However, I discovered that even in the power management section, the laptop lid closing action wasn’t set to lock the screen.

This puzzled me, so I took a break and had some dinner, and came back to it a bit later… only to find that closing the laptop lid mysteriously no longer locked the screen!

To make a long story short, what I think is happening is that the GNOME Power Manager is not running until I actually go into the power management settings in the GNOME Control Center. I think that without the GNOME Power Manager running, it’s defaulting to some sort of basic set of instructions that are either compiled into Xscreensaver or into some power management portion of the kernel, and among those settings include an instruction to lock the screen any time the laptop’s lid is closed.

To remedy this, I added yet another line to my /~/.fluxbox/startup file, like so:

gnome-power-manager &

After this, any time I reboot it automatically starts the background daemon that supercedes any default kernel power management settings (or whatever was hijacking my laptop lid closing function) and it no longer locks the screen every time I close the lid. Problem solved!

Next page: Have to manually unmute sound every time I reboot

Have to manually unmute sound every time I reboot

This was another one that was driving me up a wall. I HATE having to manually reset anything like this every single time I log in or reboot.

Like the GNOME Power Manager daemon not running causing certain undesirable lower-level default behavior, I assumed that this was because of the sound server not starting automatically (since I wasn’t running GNOME as my desktop environment).

However, I couldn’t figure out what the heck I needed to start in order to make that happen. Worse yet, it DID seem to be running at the login manager screen, only to mute itself once I logged in to my Fluxbox desktop. Ubuntu has a default sound scheme, and it makes a sound once GDM is fired up.

But I’d get logged in, have no sound, and fire up any sound management app that I have — WMMixer, Alsamixer — and I’d see that master volume was all the way down to 0%, and the sound on that channel was muted on top of it all.

After playing around with having various things start up (I even added wmmixer & to my /~/.fluxbox/startup file, so that I could at least easily manually unmute it every time I logged in by having the WMMixer utility already up and running) I also ended up running alsamixer from a terminal, unmuted everything, set the master volume where it should be, and saved those settings the way I normally would, by typing sudo alsactl store.

This was all well and good, but it didn’t solve the problem. On the next reboot, sound was muted and at 0% volume again. It seemed like no matter what I did, I was going to have to manually adjust this every time I logged in.

Finally, Patrick suggested adding alsactl restore to my /etc/rc.d/rc.local. Being a Slackware guy, it’s an honest mistake to expect that there be an rc.local file to which one can add stuff like that, but in Ubuntu you have to do things a bit differently.

Besides, I didn’t think this needed to run on boot, since I apparently did in fact have sound all the way up until Fluxbox started.

However, this did make good sense to try to restore the ALSA settings I had previously stored… I thought they just needed to be restored once Fluxbox was started though. So I took a shot in the dark and added the following line to my /~/.fluxbox/startup file, slightly modifying Patrick’s suggestion:

alsactl restore

And that did the trick! I was a bit skeptical about doing this, as the alsactl command is a root-only command, and I was expecting it to simply not work in the startup file because of this, but when I tested it, sound was no longer muted by default in Fluxbox.

So, there went two more problems running Fluxbox on top of Ubuntu. If any more come up, I’ll make sure I post them and their solutions (assuming I keep finding solutions), if not solely for my own reference, then in the hopes that it saves someone else some time in troubleshooting this kind of stuff.

Until then, let me know your experiences with Fluxbox on Ubuntu. I think I now have most of the wrinkles ironed out, but I’d like to hear about any that I haven’t run into that others may have.