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.
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.
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.
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.
I am always on the lookout for a new way of doing things when it comes to personal computing, and one of the best ways to do so is to experiment with different window managers for Linux.
Since I have my laptop set up as an Ubuntu test platform, and since APT makes it easy to download and install applications and not find myself in dependency hell, my laptop seemed to be a great way to play around with a window manager about which I’ve been reading for some time: Openbox.
Those of you who are familiar with LXDE will have some experience, albeit limited, with Openbox, as LXDE is based on it (with a bunch of other cohesive applications and a consistent look and feel integrated to complete the transition from “window manager” to “desktop environment”), but Openbox will seem much more familiar to users of Blackbox and Fluxbox, predominately in the sense that Openbox is built very light and minimal, with a desktop bare of icons, and a user-defined right-click menu that is used for launching applications. Like Blackbox and Fluxbox, Openbox is also dockapp friendly, and as a window manager it runs very fast on limited hardware.
I’m a big fan of Fluxbox, so I thought it worthwhile to give Openbox a try, if nothing else to give me material for a Linux Critic writeup, and instead I found that I just liked using Openbox, so this turned out to be more than just a review.
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
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.
In the wars between GNOME and KDE (which now has even split between the two factions warring over KDE4 and KDE3.5), some of the other environments get lost in the shuffle and are often forgotten about.
One which I think is underappreciated is Fluxbox. Based on the original Blackbox 0.61.1 code, Fluxbox is a blindingly fast, simplistic approach to providing a graphical user environment while staying out of one’s way. Easy to use, easy on resources, and easy on the eyes, Fluxbox is an elegant choice that is often overlooked when the options are weighed between other graphical environments on Linux machines.
I started using Fluxbox when I was on some extremely quarrelsome hardware and needed something with a lot less going on than GNOME or KDE so that I could more effectively troubleshoot it. What I found out was that Fluxbox had an extremely tweakable interface… and I like things I can tweak and customize. I also discovered that it ran extremely fast on the limited hardware I had at the time, something else that KDE and GNOME didn’t have.
Intrigued, I stuck with it for a while and over time I learned a few good hacks that I thought I would share with the three or four readers I’ve acquired here.