My Low-End Set Up

I’m finding set ups that really work well for me and my low-end hardware. My present little piece of ancient computing nirvana is the following environment:

• running gnu screen within X (kdrive from DSL)
• using vifm by itself and within vim
• elinks most of the time, Opera when I need graphics
• snownews for rss
• mplayer (no gui) to stream audio

This isn’t my first time to enjoy the combination of vifm and screen. What’s so special about it? By issuing the “:screen” command within vifm, it will open new “windows” in the current screen session. Click on a text file (or any file without an association in the configuration file) and it opens in vim or whichever editor you choose. Set up a MIME association and it opens the app in another screen window.

The “mplayer” tab was opened when I selected the highlighted PLS stream.

The best part of all of this: I was only using 53MB of RAM to run all the normal processes (default DSL 2.4.31 kernel, modules, basic services, sshd, etc.), X, dwm, screen, vifm, zsh, elinks (two tabs open including gmail), naim, and a high-definition audio stream.

mplayer is the pig, but it’s still consuming a lot less resources than XMMS does. I can trim it all down further by running my custom kernel but I need to reinstall it (packaged from last hard drive install).

The console apps I selected give me just about every feature I could need — except support for images and video (just haven’t gotten that far with it yet). I compiled elinks with bittorrent and ftp. I also downloaded spidermonkey to add javascript support, so I’ll have that when I recompile. Now I just need a better-developed console spreadsheet and I’m set. I’m not setting all this up for this particular computer. It’s for something I’m taking on vacation this summer; I’ll have more details shortly (and explanations for why it needs to use as little power as possible).

Even though it appears vifm is no longer being developed, it works very well if you’re used to vi/vim commands. It’s certainly not as feature-rich as midnight commander or other file managers. It does most ordinary file management jobs very well. It can launch executables or open them in vim (or your choice of editor). It can be set up with MIME types as noted above. It can sort files by all the usual variables like name, size, date, etc. It can even accept shell commands. About the only thing I don’t like about it is the default white border and panel dividing the two panes (which can be set to one pane as well), which I set to black. Unfortunately, it only has eight-color support. I may see what I can do to get 256 (I need to update my version of screen.uci in MyDSL for that, too).

I like the combination of vim, vifm, and screen so much I compiled it as one UCI for personal use in DSL. I’m also considering using those as the basis of the user interface for my next DSL remaster, which is on hold until I get a chance to play with the next major version of DSL (2.6-based “tiny core”) since that may serve my purposes even better than stripping X apps from the current base.

JWM Theme: eye-insulin

With more reviews focused on default themes as reasons to use or not use certain distros, I decided to see if there’s some way to get some kind of transparency-like effect in jwm. The only way I can do that is to match the desktop background color with the window decoration background color. I also wanted to see if I could get a more console-like appearance in jwm, just to see what that would look like. I would submit this for DSL’s upcoming tiny core but I don’t think this idea would go over well even though it reduces use of resources.

I initially went with a flat four color theme: black, green (for active), red (for inactive), and yellow (for defaults without active/inactive settings). The only exception was in the menu because I wanted yellow as its default. I’d post the actual theme but I just told you what it is. For the record, I don’t have my tray set up with a menu button because I primarily use dwm and, in jwm I also use keybindings (and dmenu) to launch apps. That’s why my tray looks like that.

This is the first attempt. Click for full 800×600 (these are small enough that I left them full scale).

I could see right away I needed to more clearly differentiate the pager (far left) and the task list. So I changed those just a bit and used some yellow in it as well. This is the second try.

I only switched colors for active so green is the background instead of foreground and used colors for the tray to designate active and inactive. In the last shot, the first virtual desktop is blacked out because my aterm setting is full screen (and black is inactive).

I know it’s not eye candy; it’s more like insulin. It’s an antidote for clutter. It’s the solution to worrying more about appearances than to actually using your computer to get stuff done.

It looks better (or should I say more console-like? I think that looks better than  wallpaper in many cases) with the tray on autohide, but that’s my opinion. The only changes I’d consider making would be switching the default/inactive colors on the menu so it’s not black on black while it’s against the background. Maybe yellow on red and the active set to green on black? I don’t know if it would hurt or help my “mock transparency” to add a darker grey (grey22?) in the gradient for the title bars. I really don’t care.

I’m resigned that most people won’t care for this kind of look or appreciate its simplicity when so many distros put more emphasis on appearances, transparency, etc., over stability and even long term support. The sad part about that is, it uses up resources without much benefit other than an “improvement” to aesthetics (which is very subjective). This is the only approach we can take with jwm to get a transparency-like effect with the window decorations, but it won’t matter to users and reviewers whose demands include being able to see bits of 500kb wallpaper through the decorations and menus. Most reviews are — and will continue to be — little more than “beauty contests” rather than reviews of distros for their merits, stability, security, strengths, weaknesses, quirks, etc.

EDIT: I set up my dwm config.h with the same kind of color scheme. (My background was already black.)
EDIT2: And here’s how my gtk theme looks (it’s still a work in progress) to match this whole austere look.
EDIT3: I lightened up the backgrounds of the dwm bar. Note from pasting in commands (in vim, :r! ssh -V) that SSL has been updated to fix two vulnerabilities. Much more on this tomorrow or Sunday (always recompile OpenSSH against the new OpenSSL if you update SSL). Also, note that vim 7.1 has now crossed over the 300 patch level this week. I’ll also have more about this shortly.

DSL 4.4rc1 Released Today

Robert Shingledecker has announced the release of DSL 4.4rc1.

New this time around, we get a major improvement in the lua scripting which includes a refactoring of the FLTK bindings (thanks Florian) so that only the parts required by each script run at any given time load regardless of what the script does or needs (in contrast, murgalua offers a kitchen sink approach that requires a full runtime of lua, fltk, lua socket, lua filesystem, zlib, sqlite, etc., regardless of what any particular script needs). This change frees up FLTK for C/C++ programming in addition to lua (and possibly other languages?); it also necessitated rewrites of the DSL lua scripts. There’s also an upgrade of rsync, the search engines for firefox have been restored, new system font (artwiz smoothansi), lower resource gradient (using xsri — darkslategrey and looks like grey60ish, lightened from what I submitted) for background, and a few other tweaks.

I call the jwm theme “DSL light industrial.” It’s just a light alloy-like scheme that’s easy on the eyes and shouldn’t cause much strain. The background fits in with what I said I would do both here and in the Productive Linux podcast blog if I had my way: no wallpaper (though I did write I’d use a single color). There’s just a small (6kb) emblem floating over the xsri gradient. It makes a noticeable difference on resource consumption compared to using a wallpaper.

My only change to the system defaults in this pic is changing the font for torsmo to smoothansi to match the rest of the system. I’ve submitted that the gtk theme can also be updated to match the colors in the theme a little more closely as well as to use smoothansi. My suggestion to use it as the font in Firefox’ menus and popups by changing userChrome might not be as warmly accepted (maybe I should post screenshots of my browser with it and without).

Debian and Derivatives (and Beyond) Serious SSL Advisory

HD Moore of Metasploit has tested a serious problem with Debian-based implementations — including Knoppix, Finnix, Mepis, Ubuntu and its derivatives, et al. — dating to September 17, 2006, of OpenSSL due to removal of code that was responsible for seeding random number generation (which is used to calculate encryption keys). This makes random number generation predictable and means keys are guessable/crackable. Moore writes that “Instead of mixing in random data for the initial seed, the only ‘random’ value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.”

Debian OpenSSL Predictable PRNG Toys:

If we continue this process for all PIDs up to 32,767 and then repeat it for 2048-bit RSA keys, we have covered the valid key ranges for x86 systems running the buggy version of the OpenSSL library. With this key set, we can compromise any user account that has a vulnerable key listed in the authorized_keys file. This key set is also useful for decrypting a previously-captured SSH session, if the SSH server was using a vulnerable host key…

The interesting thing about these keys is how they are tied to the process ID. Since most Debian-based systems use sequential process ID values (incrementing from system boot and wrapping back around as needed), the process ID of a given key can also indicate how soon from the system boot that key was generated. If we look at the inverse of that, we can determine which keys to use during a brute force based on the target we are attacking. When attempting to guess a key generated at boot time (like a SSH host key), those keys with PID values less than 200 would be the best choices for a brute force. When attacking a user-generated key, we can assume that most of the valid user keys were created with a process ID greater than 500 and less than 10,000. This optimization can significantly speed up a brute force attack on a remote user account over the SSH protocol.

In his FAQ, HDM says, “It took two hours to generate the 1024-bit DSA and 2048-bit RSA keys for x86″ using 31 Xeon cores clocked at 2.33Ghz. He also adds that “It should be possible to try all 32,767 keys of both DSA-1024 and RSA-2048 within a couple hours” barring anti-brute force scripts on the server.

In my recent page for re-engineering DSL for traditional hard drive installation, I recommended updating zlib, openssl, and openssh because of the age and (in)security of the packages upon which DSL was built. Security is not a one-time shot, it’s a matter of persistence and requires constant attention and commitment. My page was published before becoming aware of this particular issue, which doesn’t affect DSL, per se, because the versions affected are Debian Etch and later; DSL was built on Woody, which predates Sarge and this particular Debian/SSL issue.

Unfortunately, this problem goes beyond just Debian users (and users of Debian-based distros like DSL) because of the number of certificates exchanged between secure sessions involving affected servers. Certificates from Debian servers — from banks, from websites, etc. — are affected regardless if the end user uses Debian, Slackware, FreeBSD, OSX, or Windows. As Moore adds,

In the case of SSL keys, all generated certificates will be need to recreated and sent off to the Certificate Authority to sign. Any Certificate Authority keys generated on a Debian-based system will need be regenerated and revoked. All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerabile system. Any tools that relied on OpenSSL’s PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.

The Debian advisory notes,

This is a Debian-specific vulnerability which does not affect other operating systems which are not based on Debian. However, other systems can be indirectly affected if weak keys are imported into them.

It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems is recreated from scratch. Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.

The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17, and has since that date propagated to the testing and current stable (etch) distributions. The old stable distribution (sarge) is not affected.

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.

Anyone who’s used SSH and/or OpenVPN between their own and a Debian- or any of its derivatives- based computer/server needs to update and generate new keys. Users of all operating systems may also get pop up messages from their browsers over the coming days that secure sites they visit may have new or different certificates. I think users should read each new certificate to verify integrity because this could prove wide enough that criminals may take advantage of the confusion with their own dubious and insecure certificates, which could make a bad situation even worse.

This was a dumb mistake made by the removal of only a few lines of code. Sometimes dumb mistakes turn out to have the widest effects on users. Even those who don’t use Linux or Debian.

Productivity Tip 1: Uh, This Isn’t Productive

Following my discussion with Nathan of the Productive Linux Podcast, I’ve decided to start a category for productivity shortcuts and tips.

Today’s tip: how to change a GTK theme quickly without a switcher.

Now, this isn’t exactly my idea of productivity because this is about how things look, not how things get done. This is just about how to change it quickly without compiling or installing anything so you can get it over with and do something more useful and productive with your computer. Because this isn’t something that requires some fancy interface to accomplish.

Your gtk theme information is read from a configuration file located in your home directory — usually separate ones for gtk1 (such as .gtkrc) and gtk2 (such as.gtkrc-2.0). These files are often pointers to a system or local gtkrc via an include statement with a path to a gtk theme directory and its gtkrc, i.e.,

include “/home/username/themes/NameOfLocalTheme/gtkrc”

Suppose you just cannot survive using a gaudy default gtk theme and you download one that you find more, ummm, productive. You should install it in a directory called “themes” in your home directory. Then you can manually edit the .gtkrc(-2.0) path so it reads from the directory where your new theme is. So if you download a theme tarball called clearlooks-productive.tar.gz and decompress it in ~/themes, your gtkrc would only need to be edited like this:

include “/home/username/themes/clearlooks-productive/gtkrc”

Of course, that’s not going to allow you to waste hours switching between different themes and show you how your apps look in them — as if the screenshots at whatever site you download your themes from don’t lend you guidance about how they look. That’s not my problem, I’m just trying to help people be more productive. Besides, how many themes do you need to be productive? And if it’s a fairly small number and you have only one file to edit to point to the one you want to use, why do you need “switchers” anyway?

Coming soon: more tips about applications, utilities, and other things that will actually help you get more stuff done with less effort.

What’s In a Number? Various Thoughts

What’s in a number?

I got to thinking about this when a question was asked about the kernel version I’m running on my desktop. The question presumes that just because I don’t have the most ecent kernel version, or rather kernel line, that somehow I’m shortchanged or missing something.

Nothing could be further from the truth.

HOW OLD IS YOUR EQUIPMENT?
Age is relevant to the question about loss of utility. The kernel I’m running was released last week — it isn’t archaic and it isn’t out of date. This computer is older than the 2.4 kernel. It has a 400mhz Celeron processor and over the years it’s received what I consider very minor upgrades over the decade or so I’ve had it. First there was the doubling of RAM from its original 64 to 128. Then this past winter I doubled it again to 256. Hardly impressive, but it makes a big difference in how it functions. This computer will probably outlast me and I don’t intend to toss it out while it still works.

When I bought this computer, Linux was still in 2.2 — 2.4 was available. I think I installed my first 2.4 kernel some time in 2003 when 2.2 development ceased. It was 2.4.10, IIRC (I’m not 100% sure of 2.4 version but I know it was 2003 when 2.2 development stopped — same year MS was supposed to drop NT4 life cycle support), when I switched. I think I could still resort to 2.2 and have nearly full function for everything this computer needs except (maybe) the particular USB adapter I use now (I’d been able to use CDCEther previously but that required connecting directly via bridge). I’d have to check changelogs and see if the adapter would work with 2.2. But 2.4 is very manageable for this particular computer (and would be reasonable, imo, even for my 1.4ghz Athlon box).

HOW OLD IS YOUR KERNEL?
The kernel is probably the one part of the system that can continue to be updated even when various software — especially window managers, desktop environments, and GTK+ applications — become too hefty to keep updated. I wasn’t enthralled with KDE or Gnome when I first used them. They’ve become much to cumbersome since then to use on this computer. Even Xfce is a bit too much now, imo.

WHAT’S THE BEST GUIDELINE BETWEEN HARDWARE AND KERNEL VERSION?
How do kernel changes relate to your own hardware? I don’t think too much has changed in terms of function between what was contemporary when this computer was bleeding edge. Many changes in kernel versions are bug fixes and security patches and the like. There’s some performance enhancements and lots of new drivers for newer hardware — I’d appreciate performance gains I might get from 2.6 (threading?) but I don’t need support for stuff this computer doesn’t and won’t have. I’m not hamstrung or limited or reducing anything. It freaking works.

If you have much more recent hardware, you obviously need a newer kernel with newer drivers; some of the newer drivers (including SATA support) are also in 2.4 so you don’t necessarily need 2.6.

If you’re still using older hardware — and I am — how new does your kernel really need to be? I think it’s a testament to the wisdom of Linus Torvalds and all the contributors to his kernel that what was efficient on this computer nearly a decade ago doesn’t really need much improvement. Certainly there are bug fixes and security issues that have been dealt with in the interim. Those don’t require the size of a 2.6 kernel.

I think it’s also fair to make this kind of comparison with other operating systems. When this computer was new, it had all kinds of stickers about how it was engineered for Windows 98. Windows 98 was gone shortly (as in hours) after I got it home, and the stickers still decorate an old desk like little war trophies.

Could this computer run XP? Yeah, but it would crawl. Even with 256MB of RAM now, I wouldn’t care to see how it runs. I wouldn’t even think of installing Vista on it. I thought of using my WinNT license with it but the only way to get USB support is via third party (Dell has a free driver) and Microsoft no longer issues SPs for NT. So what’s the point?

Yet that’s what I see so many people doing in equivalence with Linux. They’re taking bleeding edge distros intended for XP/Vista-era hardware and installing on Win95/98-era hardware. Sometimes the results are acceptable, but I’ve used KDE on this computer (last version: 3.5.8 iirc) and it was too slow for my tastes despite my best efforts to reduce icon sizes and other factors that can bog it down. The question I was asked isn’t asked in reverse — “Do you really need such new software on older hardware?”

I don’t think anyone does unless they have some new device that has only recently gotten driver support somewhere in the kernel. That’s the case with my laptop because I sold and loaned out my other two wireless devices that were 2.4-capable and my current card — Broadcom 43xx — has had kernel support since 2.6.19.

I mentioned something above about contemporary hardware:software relationships. While development continues, hardware is a snapshot in time. One of the things that many people observe when trying to keep bleeding edge software on vintage hardware is that it rarely works better than the software that was bleeding edge when the hardware was. Isn’t that to be expected when the software is being targeted at hardware made at that particular point in time?

That’s one of the reasons why I think Linux advocates are off-base when they suggest that newer distro versions are appropriate for older hardware. They rarely are. There are some that work better than others, and some that are oriented for older hardware. Truth be told, it rarely makes sense to upgrade more than two years after your computer becomes kind of “old” — which I put around five, six years. In the case of this old desktop, I could still happily run Slackware 8 which is still supported with updates (security, bugs, etc.).

There’s also something else to be said here about support cycles. Microsoft tries to keep its OS support on about seven year cycles. They take a lot of flack for doing that from users and critics alike. Ubuntu has LTS (long term service) which runs in five year cycles. They seem to get praise for five year cycles from the very people most willing to criticize Microsoft for seven year support cycles. Hypocrisy. But the point is, you can find adequate support for average hardware life cycles without having to stay bleeding edge — Windows does it, Slackware does it, and even Ubuntu does (though they’re relatively new to the game).

I think what matters most, though, is matching software to hardware with respect to era. What’s in 2.6.25 that I need on this desktop? Nothing. This computer is Linux 2.2/2.4-era — the same time frame as pre-XP. I have legitimate needs for 2.6 on a couple of my other computers — such as for bcm43xx support for the laptop and some of the new (proprietary) video drivers for the new desktop (I think I also scrolled past what I need in menuconfig for 2.4.36.3…).

In conclusion, don’t presume that the higher version number is inherently better for everything. It may be, it may not be.

Podcast Hell

I downloaded a ton of tech-related podcasts over the weekend. Some of them were older but still informative, others were more recent and not exactly worth the time or bandwidth it took to listen to them. I’m still going through them. Some merit more ear-time than others.

One of them seemed promising by its name: Productive Linux. I think I downloaded two or three episodes. I stopped the first one I listened to and forwarded to the next when the host started spelling out commands and options for editing Firefox chrome. The last thing I want to hear when I’m running at 4:30 in the morning is a spelling lesson. No thanks, next.

Then I got his review of Absolute Linux, one of the smaller and easier to set up (Slackware is NOT hard to set up — read the documentation and it’s quite easy) Slackware-based sub-distros suitable for older computers. Once I got past the host’s prattle about how “clean” and “vanilla” and “stable” it felt (compared, pray tell, to what?), I got the substance of his review and impressions.

First, the host very obviously didn’t bother to read the Absolute site because — RIGHT THERE ON THE FRONT PAGE — it very clearly mentions that it uses Slackware binary packaging:

Accepts packages made for same Slackware Version, so you can use Slackware software repositories.

Duh. Nobody reads anything anymore. Oh, and the bold and underlined emphasis is mine. I’d make it blink but wordpress doesn’t support it. TG.

So I then got to listen to him go off on a tangent about compiling. Yes, you can do that with Slackware because its base is very complete with the most oft-used libraries. But it’s untrue that Slackware requires compiling your own apps because Slackware does have binary packaging.

Then we got into his likes and dislikes. He was disappointed that it didn’t come with audacity. So? How does that relate to productivity? That’s available from the official and many of the unofficial Slack-package sites and repositories. He also didn’t care for the wallpaper or default GTK theme. What was the first application he compiled? A switcher for GTK themes. So productive. I then endured more talk about themes. Productive? Not IMO. He berated the sparse choice of included productivity software. Never mind anyone can get the most current version (that would be the one with the most recent bug fixes and security patches) of Open Office from the Open Office website or from (duh) Slackware’s repositories.

I was about to end this attack on my ears and my intelligence when the host said that the version of Absolute he was using was a release candidate. Oh, nice.

It would’ve been nicer to know that before listening to what an ‘unfinished’ product he thought it was. I wouldn’t have wasted my time. I would’ve been more productive.

EDIT: I realize what I wrote probably seems harsh, but I thought the review was overly critical especially considering it wasn’t RELEASE and because he started with a presumption that isn’t even true (binary packaging).

I take exception, too, to the prevailing standard too many reviews have for distros: that their initial mixes of application are how they should be judged. I think that’s bullshit because anyone can take distro X, change a few apps around, and call it distro Y. Look instead at their paradigms — what do they do differently than the others? In the case of Slackware, it’s about keeping things as simple and straightforward (in the Unix sense) as possible. In other distros, it’s about package management (after all, Debian is aiming for neutrality and has compatibility with other operating systems like FreeBSD and GNU Hurd). It’s not what it comes with but how you use it and what you can add and why. Tell me that, don’t tell me it still uses version A.B.C instead of A.B.D of some application. Tell me why it exists, why its developers do things in certain ways.

I also admit I don’t get the relationship between things like themes and productivity. I’ve edited many themes for jwm for DSL — not because that matters so much to me but to help reduce the noise from people who thought DSL wasn’t aesthetically attractive. As we’ve seen with DSL, it doesn’t matter how many themes you offer or how much you dress it up, people are going to grumble anyway. THAT’S WHY THEMES AND WALLPAPERS CAN BE CHANGED. IT’S SUBJECTIVE. IF YOU DON’T LIKE DEFAULT SETTINGS AND THAT’S GOING TO CAUSE YOU TO WHINE, CHANGE IT. BUT IS THAT REALLY THE MOST IMPORTANT THING ABOUT JUDGING HOW DISTROS ARE DIFFERENT?

That’s why I wrote fairly harshly about that particular podcast. Maybe the rest of his stuff is worth listening to, maybe it’s more of what I heard. When I think of “productive,” I think of substance. What little substance he had was misleading (Slackware does have binary packaging and Absolute Linux uses it) and the rest was about stuff that really doesn’t matter.

More DSL Hard Drive Fun

I decided to recompile my DSL hard drive install kernel while watching the Hornets beat down the Mavericks. My goal is to get it even smaller and faster.

Ten megabytes (plus some marginal amount cached) while running X and several other processes (I took the screenshot in console while ssh’elled in and then used sshfs to convert the image from a raw X dump to png on the laptop). Take a look at the torsmo shot in my ‘dsl hard drive’ page for comparison. I’m getting there. Now I need to see why hotplug-knoppix loaded fat/vfat modules (which were loaded when this shot was taken)…

As for the rest of the stats:

% du -h –max-depth=1 /lib/modules/
20M /lib/modules/2.4.31 (default)
1.7M /lib/modules/2.4.36.3-mini (first try)
1.2M /lib/modules/2.4.36.3-miniM (current)

984K linux-2.4.36.3-miniM (current)
988K linux24-31 (default)
My other one was 1.2MB but it was a case of ‘better safe than sorry.’

I’ve yet to run into any issues.

DSL Hard Drive Install Page

I’ve added and linked a shorter version of my Damn Small Linux “hardening” guide, which focuses on some of the changes I make immediately upon installing DSL to hard drive. Some of what I’ve added is security-related. After all, everyone thinks Linux is inherently more secure than Windows — so make sure it is. Other parts, such as recommending kernel recompilation, are less urgent. The gist of my opinion: it works and works well, but it’s easier using a distro that’s intended to be used for hard drive installs if you want to set it up correctly and safely.

The link is here and on the top under “My Pages.” I also hope to have the “MyDSL Pages” available soon, which will also have a link to it.

Additional note: I’ll recommend to Robert that zlib, ssl, and ssh be updated (or use dropbear, which hopefully is updated). If not, I’ll try to submit what I use as dsl/unc.

Tilting at Windows: Don’t Fight for Desktop Linux Adoption

I picked up this article by Caitlyn Martin from Steven Rosenberg’s Click blog. She takes a different tack on some of the issues I’ve addressed when I’ve commented on some of the more exhuberent (and less honest) Linux activism. Her article references one such article, a list of ten points about how Linux has outgrown its geeky past and is appropriate for desktop use.

She writes, “All 10 points in the article are valid. None of them, nor any other efforts at Linux evangelism over the last decade, have worked when it comes to moving the masses towards Linux in the home and office on the desktop. Look, I’m not critical of the article. It may even convince a handful or people to give Linux a look. It, and articles like it, won’t have a major impact.”

This is true and so is her suggestion that it’s preaching to the choir. There have been many activists who’ve attempted to make inroads and get Linux adopted on the desktop. She’s correct that it’s not about cost, it’s not about ease as Linux desktop environments and driver support have improved. Resistance is hard to overcome no matter what price tag you put on or take off.

I think she too easily dismisses a couple things, such as the ease with which devices still work with Windows because their vendors are Windows-centric. If I buy any webcam, I know it will probably work very easily with Windows — plug it in, voila. If I do the same for use on a Linux desktop, I need to first check to see if it’s natively supported in Linux. Failing that, I have to see if anyone else has a driver for it. Then, if there is one, I have to check and see if that driver has enough functionality to be worthwhile. And if I already have the camera and it already works in Windows, why would I want to switch to a “free” operating system that will require me to compile a separate module for my device, run depmod, etc., just to use it? We can argue all we want about closed hardware and software, but these things are reality. We don’t have a magic wand to make it go away.

Substitute scanner, printer, or any other device for webcam. The more stuff a user already has, the more resistance he or she will probably have in switching.

Martin suggests two ways that users may be lured to desktop Linux. One is via well-conceived and well-configured devices like the Asus Eee UMPC that come with Linux. These have been met with more enthusiasm by existing Linux users, though. With these UMPCs increasingly shipping with XP, I don’t see how this bodes well for Linux. (I’m neutral on superiority of Windows or Linux because often it boils down to the same thing: how well things are pre-configured for the less savvy user. The less savvy the user, the worse the perception is if it’s inadequately set up even if the “problems” are very benign.)

The second thing Martin says may help Linux adoption is via concerted effort between Linux developers and hardware vendors — more of a Microsoft approach. There’s a big problem with this: there aren’t many manufacturers of hardware ready to embrace open source, at least not with the kinds of strings that GPLv3 would attach with respect to firmware. While some companies are becoming more lenient when it comes to distributing their firmware (since I just compiled two 2.6.25 kernels, I noticed there’s a lot more of that than in the 2.4 line), they really don’t benefit by pushing Linux on desktops — even a 100% increase in Linux desktop adoption wouldn’t reach the 5% share, so spectacular growth rate keeps you in a marginal market. Hooray, BeOS!

I think where all of this is moot is, we’re moving away from traditional desktop computing. Whether you want to look at mobile computing vis-a-vis laptops, notebooks, and UMPCs or in the direction things appear to be headed with cell/smart phones and PDAs, the real growth is away from desktops. Dittos for other devices popping up in homes all over the world: TiVOs and other DVRs, game consoles, etc. Many of these devices are the real initial contact points people have with Linux.

That’s where hardware vendors are already onboard with Linux. And vice versa. Except for FSF and fringe types who object to the way the real world operates.

My beloved told me she would never use Linux on her laptop. She’s dead serious. She hates my computers. She stopped telling me she’d never use Linux when I pointed out where she was already using it: her cell phone, the router, the server, the DVR, the TV. Things she takes for granted because she turns them on and they work without “eye candy” or code she can audit herself (which would be quite interesting to see!) or lack of command lines. Just like Windows. She’s not in the open source choir and not interested in how many different window managers she can try. She’s just pragmatic.

What Martin argues for is already reality, just not on desktops.

Linux is widely used on mobile hardware like cell phones and it stands a much better chance of widespread adoption there barring more goofy GPL turf wars by zealots who make up words like “tivoization” for problems that don’t even exist (TiVo plays by the rules; so FSF changes the rules and moves the goalposts). Licensing really matters as much as whether the source is open or not. I’ll even argue that adoption of Linux and its funding from vendors would already be more widespread if its license were less restrictive — much the same way TCP/IP became an adopted standard in both open source and proprietary worlds because there weren’t petty restrictions preventing others from integrating it as they saw fit (it’s important to understand that Microsoft and Apple had every bit as much freedom to use TCP/IP as BSD; otherwise, we’d have closed networking stacks that don’t communicate very effectively with each other).

The real battle in this decade is away from the desktop. Those who want to win market share on the desktop are tilting at Windows.