2008-09-12

Desktop Linux suckage: a quick exercise

One claim you'll sometimes hear is that, although Mac OS or Windows are better for stuff like word processing, spreadsheets, presentations, reading mail, drawing, painting, cataloging and touching up digital photographs, games, and all those other things that only real people do, Linux is best for hard-core nerdy shit.

Coincidentally, I just so happen to have a hard-core nerdy desire, one that, by this theory, Linux ought to do way better on than Mac OS? Yeah, it's an unscientific sample size, but it still might be instructive, and it's an actual question I want answered right now...

The problem
I want to know how many DIMM slots my motherboard has, and what DIMMs I have fitted.

Apple's solution
On the Mac, I click on the little Apple icon, I click "About this Mac...", I click "More Info..." and System Profiler starts, letting me see any detail about my system's hardware and software, including a convenient detailed display what DIMMs are in which slots. It even lets me save a handy .txt summary for inclusion in bug reports and the like.

Linux's solution
On Ubuntu, on the best-avoided crock that is the "System" menu, I have both "About Ubuntu" and "About GNOME". Neither contains a single piece of useful information. System Monitor, which I always have running because I like visual feedback telling me whether my computer's actually busy, waiting for I/O, or just ignoring me, has recently grown a perfunctory summary of my hardware that's not really useful yet. Maybe it'll improve, but I'd rather see a useful "About" menu item rather than rely on a panel applet that isn't there by default. If I go to someone else's system, I don't want to have to start installing stuff to help answer their simple hardware questions.

So I start a terminal and cat /proc/meminfo, but the information there is too high-level for my present purposes. I tab-complete on "ls", thinking there might be some equivalent of lspci(1), but the promising-looking lshw(1) is another dead-end, telling me only the total amount of memory fitted. Okay, screw guessing about on the command line. I know there is a command, because I've used it before, but I can't remember it, and I was supposed to be using the desktop anyway.

I start Firefox and search the web for "dimm equivalent of lspci" and a few variations before I stumble on "lspci ram" on Yahoo (I never did find anything relevant via Google, even with the search string that works with Yahoo). This gets me a handy Gentoo page (naturally) Detecting your Hardware which suggests hardinfo(1) which, once installed, gives me a GUI which is indeed pretty similar to the Mac's System Profiler. The memory information, though, is /proc/meminfo in a GTK+ text area. The authors seem to have been more interested in benchmarking than hardware inventory. I mutter something about Gentoo users, uninstall, and go back to searching.

The only other GUI I found was sysinfo(1) which was almost like someone's joke entry in a "worst ever Linux software" competition. When it starts, the UI is animated, but doesn't actually show anything that has any meaning. There's a preference dialog, mostly taken up with a preference to turn off the pointless start-up animation. (And don't get too excited by my use of the word "animation". I use it in the loosest possible sense. Think of Windows XP's lame bouncing arrow pointing to the "Start" button.)

sysinfo's status bar constantly shows the date (in some random localized time format that I certainly never asked for). If you expectantly click on "Memory" in the list of options (decorated for some obscure reason with the icon usually reserved for copy-to-clipboard menu items), you see two sliders showing the free/used fraction of "Memory" and "Swap". There's a hopeful-looking disclosure triangle labeled "More details", but that just shows "Cached", "Active", and "Inactive", which I know by now are just the next three lines of /proc/meminfo. Looking to see who was responsible for this travesty, I noticed that the Close button in the about box doesn't work, which I thought was a particularly nice finishing touch to the encounter.

Failure
At this point, I resigned myself to either not knowing what DIMMs I have fitted, or opening the case to take a look.

I don't present this anecdote with any particular interpretation in mind, nor because the specific example is particularly representative, but it should at least serve as a warning to anyone foolish enough to think that "at least Linux is okay for the nerdy stuff". No, it's really crap there too. We have too many half-baked attempts at writing the same few things, and almost nothing that's followed through to a useful "shippable" point.

We're stuck with our 1980s XTerms and our 1970s Emacs/Vim (or our IDEs written by people paid to work on them by commercial vendors) and our compiler, which alongside the Linux kernel is one of our few real successes. Like the Linux kernel, though, many commercial vendors pay people to work full-time on it. We kid ourselves if we think that these are fruits of the "community" of bedroom hackers. Those are the people churning out the the half-baked "utilities" that had more time spent on their about box and their start-up animation than on their usefulness or usability.

On the internet, no-one knows you're 14 year old or a raccoon. Until they use your software.


Postscript
David Bristow reminded me of dmidecode(1) which was the command-line program whose name I couldn't remember that does provide the relevant information though (as David admits) in somewhat hard-core form. Harald Koch explained how to get lshw(1) to do the right thing: "sudo lshw". He also suggests "sudo lshw -short" which provides a much more convenient overview style of output than I'd seen before. To be fair, when not run as root, lshw(1) does say "WARNING: you should run this program as super-user". But it makes the common command-line mistakes of (a) outputting this first rather than last, (b) continuing anyway rather than exiting or insisting on some kind of --partial option before doing the wrong thing, and (c) going on to produce so much output that the warning scrolls off the top of the display or is lost anyway. Sadly, no-one cares enough about command-line usability these days to teach the lost art.

Playing more with lshw(1), it turns out to have a companion GUI called lshw-gtk(1), but the interface is truly awful. You know NeXT's awkward column view interface style that's been slowly dying out in Mac OS because it just doesn't work well? lshw-gtk(1) goes to some effort to recreate that, complete with useless top levels and a requirement that you double-click rather than single click to see a node's children. The Debian package also causes it to hide itself in System > Preferences (surely Administration would make more sense?). Despite these problems, it's still the least worst GUI solution I've seen. The individual panes are really nicely presented if you're persistent enough to navigate all the way down to them. And the "you really need to run this as root" warning is a lot stronger and does actually make you click a button before it'll do the wrong thing. But honestly, my recommendation would be "sudo lshw -short" in the terminal emulator of your choice.