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
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.
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.
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.