MindlessCode.net

I couldn’t find a VMware virtual machine of Kubuntu 7.04 (Feisty Fawn) anywhere (I needed one for testing Autopackage). So, I created one:

• Kubuntu 7.04 (Feisty Fawn) VMware Image
  Compressed Size: 721M
  Uncompressed Size: 2.4G
  MD5Sum: b6d2b32e487859ef34fc5b1d0463a461

VMware tools are installed. The username and password for the user are “user” (w/o quotes). Security Updates are not installed.

Any of you smart people who know how to use Bittorrent are welcome to setup a tracker.

Note: The directory inside the tarball is called Kubuntu-7.05 (which doesn’t exist). Everything really is Kubuntu 7.04.

NOTE :: I had to remove the file because it burned too much bandwidth (1.4TB!?). If someone can host it, or setup a bittorrent tracker, send me an email (tajmorton@gmail.com).

NB: When this article says “Linux,” it refers the whole gig, not just the kernel. Also, this is about Linux on the Desktop. Severs are a completely different thing. OK?

Almost every year someone declares it to be “The Year of the Linux Desktop.” Yet, these pundits are wrong–every year. Definitely, Linux has made a lot of progress since the days of Red Hat 6.0, but it still has major architectural problems that have existed since the beginning (and actually, in the pre-Linux days as well).

Will Linux ever make it to the desktop? For a long time, I was optimistic about this. Linux has a terrific community of smart people and companies built around it. With this community, we’ve built a pretty amazing free operating system that does work. Maybe not for everyone, but it works for you and me. I like Linux because it makes my computer think like I think. I like Linux because I can easily tell my computer to resize all my photos into thumbnails, to create a list of all the postal abbreviations in the US, and to replace a line in a bunch of PHP files.

However, as it is, Linux is never going to replace Windows as Joe Average’s computer. It doesn’t matter how cool AIGLX/XGL look, how pretty Ubuntu’s Gnome is, or how it doesn’t get infected with Windows malware. As I see it, Linux has 6 fundamental problems that hold it back from being up to par with Windows or Mac OS X:

1. The Linux kernel has no way for hardware manufacturers to distribute drivers with their hardware.
2. Namespace Conflicts: Installing everything under one prefix just doesn’t work.
3. No Platform: Linux has no list of standard libraries/versions of libraries that all distros are guaranteed have. (ISVs need this).
4. A lot of important projects and libraries don’t seem to understand the importance of stable APIs/ABIs (and the pain breaking them causes).
5. ELF needs some work.
6. Centralized repositories for installation just don’t work.

Hardware Drivers

Hardware manufacturers face two (closely) related problems:

1. Drivers (modules) must be distributed with the kernel.
2. The kernel has an unstable interface.

Drivers must be distributed with the kernel

While not technically true (out-of-tree modules can and do work), for hardware to work “out of the box,” the driver needs to be part of the Linux tree. As the kernel is currently, there is no way for hardware manufacturers to ship a CD with a wizard and drivers that the user can simply pop in their drive–all drivers need to be compiled against the kernel they will be loaded by.

Even the optimal hardware manufacturer who releases their drivers under the GPL and sends them upstream for inclusion in the official kernel tree still face a major problem; they must wait for their users to upgrade to the new version of the kernel. Until that happens, their hardware doesn’t work out of the box. However, the manufacturer and the user don’t want to wait, they want their stuff to work “right now.” Which brings us to number 2…

The kernel’s unstable interface

The kernel has a fairly unstable interface. The most obvious example was the 2.4 -> 2.5 change which had a large number of changes. I don’t have a huge problem with this kind of “major version” breakage. Architectures changes happen (and usually for the better). You see similar things in the Windows and Mac OS X world, with different drivers for Windows 2000, Server 2003, XP, and Vista, etc. While not these kinds of changes are not optimal, often cause upgrade pain, and add to maintenance costs, sometimes they’re unavoidable.

However, the kind of breakage I’m talking about doesn’t happen between these large releases. The “bad” breakage happens in the minor releases (2.6.8 -> 2.6.9, 2.6.17 -> 2.6.18). This causes 2 problems:

1. HW Manufacturers need to constantly update their drivers (if they’re not maintained by the Linux community).
2. Drivers usually can’t be backported easily.

I’m going to use a software example first, because it’s something that bit me recently:
The VMware Workstation needs to install some kernel modules on the host system (and on the guest system if you want improved performance). The VMware folks provide a nice script that tries to automatically build and install the modules. It worked fine on my Slackware 11.0 with the fairly recent 2.6.19 kernel. However, I ran into trouble trying to get the guest system modules working on Fedora Core 6 (kernel 2.6.18) and openSUSE 10.1 (2.6.17, IIRC). On both these systems, the build failed rather spectacularly with lots of compile errors flying by.

It turned out that there were a few changes in some kernel functions and structs that the kernel provided. After a few hours of Google and nano and I had the drivers working, but it was a tremendous hassle. On Windows, the guest drivers (binaries) installed with just a click of the mouse, thanks to the fairly stable Windows API.

The VMware issue is an example of how the kernel’s interface isn’t stable and how hardware manufacturers need to deal with the hassle of maintaining up to date drivers (and the users need to find and apply the patches that the manufacturers provide).

Conclusion: The kernel needs to provide a stable interface for hardware manufacturers to use.

Namespace Conflicts

Traditionally, UNIX systems have followed the philosophy of dumping all programs under one roof, namely in /usr. This inevitably leads to conflicts where two applications have the same name. The FHS tells ISVs to install into /opt/appname. This works in theory, but not in practice, because distros don’t support anything outside of /usr (and sometimes /usr/local), but certainly don’t support adding new paths.

Conclusion: Fixing this (correctly) requires a new directory layout. GoboLinux provides one option. I personally favour something more unique than just the application name–a rootname (like is used in Autopackage) is probably the safest way to namespace something: @domainname.com/project/version.

No Platform

A platform is a set of libraries and applications that are guaranteed to be available for ISVs to use. These libraries must be very, very stable with few API additions and no ABI breaks (unless dealt with properly).

The LSB’s goal is for a standard platform. However, their platform was way too small to be of any use whatsoever. Statically linking kdelibs, aspell, gecko, python, whatever, will not work. It will simply create many bloated, memory hogging applications. A useful platform should provide the majority of libraries that desktop applications need (Qt/Gtk, Gecko, *spell, libcurl, glib…the list goes on and on).

In theory, distros are platforms. However, they fail on two important points:

1. They’re not stable
2. Different distros have provide different platforms

Stability

One of the most important corner-stones of a good platform is that old applications continue to function. Windows is a good example: An application written for and compiled on Windows 95 will still most likely run on Windows XP. If you’re lucky, you can even get Windows 3.11 apps working.

Linux distros, on the other hand, often break backwards compatibility. For example, KDE 2 was written using Qt 2. Almost as soon as KDE 3 was released (which used Qt 3), distros stopped distributing Qt 2, and moved up to Qt 3. Suddenly, any applications that used Qt 2 no longer worked on modern distros. This kind of removal of libraries can cause immense pain in the ISV world:

Imagine you’re an ISV who uses Qt 2 in your (Linux) application. You distribute a binary linked against Qt 2. At this time, all distros ship Qt 2 (or it’s available from their repositories), so you don’t bother to include an extra 15MB of files with your application, and rely on the distro to provide Qt for you. Suddenly, Qt 3 is released, KDE 3 is released, meaning that distros can drop Qt 2 because none of the apps they ship depend on it. However, you, as the ISV, are suddenly inundated by a deluge of support calls wanting to know why your app stopped working when they upgraded to Red Hat 8.

Distros as platforms

Distros have gone in the direction of each distro providing their own unique platform [1]–that is, one with no guarantee of compatibility with any other distro. This (in my opinion) is the worst kind of fragmentation possible. As ISV will sell an application as working on “Fedora Core,” while the Ubuntu people are left totally out in the cold with no support, and possibly no working binary at all. This doesn’t work unless 1 distro is going to “win” and have all the desktop market share, which I don’t see happening.

Conclusion: Create a list of the common libraries that desktop applications use, force stability of these libraries, and make sure distros ship these libraries (including the old versions).

The Importance of Stability

This goes along with the platform, but focuses on the projects instead of the distros. Unfortunately, a lot of high-profile projects don’t seem to understand the importance of ABI stability.
Examples include gcc and Python. Unintentional breaks also occur a lot too, see libtiff, freetype, and GTK+.

Conclusion: Stability is an essential requirement for any decent platform. Educate developers about the importance of stability. Don’t allow unstable libraries into the platform.

ELF

ELF, the format that binaries and libraries are in, needs some work. Basically, instead of loading DSOs in a tree, like you’d expect, it just binds against whatever library is loaded into the image. So, you can easily get your app bound to the wrong ABI of a library if a dependency needs a different version of a dep than you do. See this for more information.

Conclusion: Fix ELF so that it loads shared libraries as expected.

Centralized Repositories

All distros currently use a centralized repository for installing software. While it looks kind of cool at first, and it kind of works at a small level, it just doesn’t work in the end:

1. Users don’t want to wait until J. Random Hacker gets Firefox 2.2 packaged up and put into the repository, they want it right now.
2. Application developers can’t release beta versions that users can test easily.
3. The people doing the packaging (the distros) aren’t usually the most qualified people to package the application (that would be the app devs). Sometimes they mistakenly ship broken packages (bad patches, not including essential files, etc).
4. Distros can and will arbitrarily drop packages from their repositories, leaving users no way to easily acquire the software.
5. The protection that repositories provide against mal-ware is questionable at best.
6. Centralized repositories provide a huge single point of failure. Repository servers have been cracked (Debian), and almost certainly will be in the future. All it takes is for a server to be compromised for a few hours for it to infect thousands of machines.
7. It doesn’t work at all for proprietary vendors. “Truly Free” distributions won’t allow non-free stuff in their repositories. Non-Free as in beer ISVs (e.g., stuff you have to pay for) will probably be fairly reluctant to give their software over to these repositories.
8. It doesn’t scale. As Mike pointed out, it fails the Microsoft test. Imagine if Microsoft suddenly said that all software needed to be downloaded through http://download.microsoft.com for security reasons to protect their users from mal-ware. a) It wouldn’t work–there’s too much software for Microsoft to keep up to date and approve, and b) It would be way too monopolistic.

Conclusion: Distros have the power and control right now and nobody likes to lose control. Hopefully one distro will see the light.

Final Thoughts

As you can see, there’s a lot of work to do. Can it be done? I don’t know–maybe it can, but definitely not without a major shift in the current “UNIX Philosophy” that Linux has (binaries? not my problem, dump it all in /usr, keep it all centralized, etc).

Perhaps a new operating system would be a better place to start. There’s a huge number of very important “Linux” projects that are not Linux dependent at all–KDE/Qt, Gnome/Gtk+, Samba, Firefox, and CUPS to name a few. All of these projects (and many, many others) are vital to any free operating system. Linux has an amazing community of companies and individuals who have all put tremendous effort into the free desktop–it would be a shame to see it go to waste.

Sometimes I’ll take fairly random screenshots on my computer. Here’s my latest selection:

A Job Advertisment on The Daily WTF. A little ironic, in my opinion.

When Batteries Die:

taj@moria:~$ cat /proc/acpi/battery/BAT0/info|grep mAh|head -n2
design capacity: 6000 mAh
last full capacity: 65157 mAh


taj@moria:~$ cat /proc/acpi/battery/BAT0/state|grep m[AV]
remaining capacity: 65157 mAh
present voltage: 12600 mV


That’s on a Intel Pentium 4 2GHz processor w/ 1GB of memory. Nice. (If you can’t read it, Firefox is using 93.4% of my CPU and 12.2% of my RAM)

GMail shows the weirdest “related content” sometimes…

On a side note, I’ve finally gotten a Flickr Account. It’s got some of my favourite photos from 2006. Who knows, there might be one of you there. Actually not, because “you” don’t read this.

Oh, and I’ve lost 7 keys of my laptop keyboard now. 1 Ctrl, 1 Alt, 4 Arrow Keys, and End. A new keyboard (if you can find it) costs at least $100. I’ll suffer.

What does this mean? Your nerdiness is: High-Level Nerd. You are definitely MIT material, apply now!!!.

*Sigh*, I must be bored.
In case you want to see how nerdy you are.

I screwed up my neck somehow on Monday. I couldn’t play violin for a few days (still can’t). Whatever.

Anyway, I heard a review of Cuckoo’s Egg on LugRadio. I read the first few pages on Amazon and put it on hold at the library. What a great book.

Clifford Stoll, an astronomer at Berkeley runs out of money (his funding dries up) and so he gets “recycled” and ends up as a sysadmin running Berkeley’s UNIX boxes. Back then, computer time was billed by how much processer time you took up. So they needed to keep track of time. And, for some reason, they had 2, count ‘em 2, accounting systems to keep track of the time and sent off the bills to the correct departments every month.

One month, a sysadmin noticed that there was a discrepancy of $0.75 between the two systems. Intrigued, Clifford decides to take a look at the arcane accounting and try to figure out where that 75¢ had come from. He spends a day or two paging through the ancient source code, but doesn’t find anything that would amount to 75¢ of unbilled time.

Someone is stealing time, 75 cents worth of it–first-degree robbery, I know. Turns out someone had become the superuser by exploiting a bug in some great, popular, and common software that lots of people love and lots of people hate (it stars with an E and ends with an S and has an A in the middle). See Wikipedia’s page on the nesting habits of Cuckoos if you want a hint on how he got in.

After locating the all-powerful unauthorized superuser sets up a “monitoring system” which involves some old printers, a pager that gets called by a hacked up script that beep in Morse code, 50 “borrowed” terminals, and other such hi-tech network security paraphernalia.

A good intro/reminder of what the “internet” looked like in the 1980s and how everything worked back then. I loved it, go read it.

I love this song, Nickel Creek rocks.

I wanted to make a blog post, but couldn’t think of a good title, because I have no clue what to write…I still don’t.

Let’s start with the weather; It has been beautiful spring weather. For the past 2 weeks, it has been ~13°C (55°F), the sun has been out, no rain–just beautiful. This is following about 4 weeks of very heavy rain, so I may be slightly biased, but it is nice. Not that I don’t like the rain, I do! Changes are nice every now and then, though.

Anyway, what have I been doing? Not outside in the sun, no–inside, with the blinds down, in my nice dark hole (aka, the kitchen table). We bought an HP OfficeJet Pro K550 because a) our old HP Deskjet 932C was dieing, and b) the Deskjet didn’t “print pictures too pretty.” We have the K550 dtwn–not sure what the dt stands for, but wn stans for “Wireless/Wifi network”. Yes, we have a wireless printer, it’s very sweet. We could have gotten a wired one and saved about $20, or we could have gotten one with no networking and used our Netport (a device from Intel that has a 10Mbit ethernet port and a parallel (LPT) port) and saved about $60. But wireless was a good deal, given that we currently have one free port on our wireless router. Yeah, we have a crappy IPv4 router with 4 LAN ports and 1 WAN port, plus an antenna. Whatever.

This printer is sold as being Linux compatible (yes, I check, I’ve been burned before). Not trusting the people who want my money to always tell the whole truth, I checked LinuxPrinting.org (an awesome site, by the way), and the printer is reported as “Working Perfectly”. Great, I say–piece of cake! The first sign of trouble was that there was no mention of this printer on the CUPS drivers list where you select the driver for your printer. “No problem,” I thought, “Just download the PPD from LinuxPrinting.org and copy it into /usr/share/ppd. I did that, restarted CUPS, and the driver appeared–yay! So, I printed a test page, network activity occurred, the printer picked up a piece of paper and printed:

* Unable to open the initial device, quitting


*sigh* A few more pieces of paper, a little digging through the CUPS debug log, and a little Googling gave me a few hints. GhostScript didn’t like the OfficeJet K550, and was giving that cheery little message. I headed on over to the hpijs project page (HP’s drivers page for their inkjet printers). After reading some obscure ChangeLog, I found that support for my printer was only available in hpijs-2.1.8 and above–Slackware ships with version 1.7 (yes, even slackware-current). Heading on over to the SF download page, I discovered that hpijs is no longer distributed (last available version is 2.1.6), and is instead contained in hplip package, which is used for HPs Mopiers, or whatever they’re called–a printer, scanner, copier, fax machine, whatever all in one box. Turned out that LinuxPackages.net had a hplip package of “sufficiant versionage” (is that even close to a real word?). I used the one for Slackware 10.2, version 0.97p2, I beleive. I downloaded it, uninstalled the hpijs package, installed hplip and its dependecy net-snmp, re-downloaded the PPD from LinuxPrinting.org, restarted cups, readded my printer, and I was good to go! Yay!

EDIT :: You need to install the netsnmp package too.

Boy, I bet that was an exciting read. I really just posted it so that people who have the same problem might get an idea about what to try.

Back to the weather. I was outside a few minutes ago, it was warm! (Getting tired of those <em> tags yet? So am I.) Amazingly warm for the 2^nd week of February. It actually felt a little bit like August. Or maybe it didn’t, but it reminded me of August, which means it reminded me of all sorts of great things–Booher Camp, Willamette Valley Fiddle Contest, harvesting seed (oh yeah, that was reeally great, *sigh*). The Gaston fiddle contest has worn off me and I am missing my fiddle friends again. Oh well, the first fiddle camp isn’t until July, I guess I’ve got to wait a while…

On the QuickI front, it looks like I’m back to manually drawing on canvas again for printing. QTextDocument just doesn’t give me enough control. For example, I cannot set the border of a table (cell) to be exactly what I want. It’s like <table border=”1″> vs <table style=”border: .5em;”>. QTextDocument uses the HTML table border approach, using some sort of set widths that TrollTech came up with. 1 just is too big to make stuff pretty. Maybe I’ll try a simple sketch/mockup if I’m not too tired after I post this.

No, I did not “fix” the timestamp to say exactly 11:30 last night–it just happened.

GMail is at it again:

Shown next to this email:

Address book is all good. Trash still says “Malformed URL trash:/” but not
that big of deal.
System says, “Retrieving data from system is not supported.” and at the top it
says it is a KIOExec error.

Oh, and any ideas about those errors… If you go to trash:/ or system:/ in Konq., everything works fine–it only happens from .desktop files. I even copied trash.desktop from my system to the system with the problem, same error. KDE 3.4, Slack 10.1, Vanilla 2.4.30 Kernel.

Over the past three days, I’ve been trying to compile Qt 4.1.0. Compiling stuff is usually very easy, I know–I may lose my “Geek License” because of this.

Qt, the great cross-platform toolkit (which does everything from networking, to strings, to GUI that works almost everywhere) comes in the form of a 25MB tarball. “No problem”, I thought, “just run ./configure && make && make install.” Well, that probably would have worked, except for two things:

• libpng is broken
• ./configure doesn’t look in the right place for mysql.h.

Luckly, I caught both problems before I compiled everything. On Slackware, libpng does not link against libz, which is required. So, unless you manually pass -lz to gcc, you will get link errors. Oh, and I did get link errors. I’m not really sure if this is a Slackware or libpng problem, but I think it’s libpng–I don’t really see why Slackware would remove the -lz flag. I just modified the libpng test in config.tests/unix/libpng/png.pro and ran qmake.

The other problem was the MySQL test didn’t look in /usr/include/mysql for mysql.h–in fact it didn’t even look anywhere! I just added the following to config.tests/unix/mysql/mysql.pro:
INCPATH += /usr/include/mysql
and reran qmake.

I also editing the src/sql/sql.pro, or whatever it’s called and reran ./configure.
(I should tell Trolltech about these–I guess I will sometime)

Anyway, make should have “just worked” and I should of had a static and shared version of Qt 4.1 on my computer in a few hours. Note all those “should”s in there…

Nobody told me how much space was required to build Qt 4. Apparently the answer is “lots.” First, I tried compiling in /home/taj, I had about 500MB available there, and I figured that that would be enough to compile a 25MB tarball. Boy was I wrong!

I got lots of errors about “final link failed” because of lack of disk space on my home partition. Ugg. After deleting or moving about 2GB of stuff, I still was getting the error. What to do? Well, it turns out I have a 16GB partition that was formatted as NTFS, and was used for storing WAV files from our music recording. I moved the recordings onto xenon, our storage computer, and reformatted the partition. I untarred Qt there, hacked the libpng and mysql test qmake files, and ran ./configure && make.

Guess what I got! “ld: final link failed, no space left on device.” That is on a new, empty 16GB partition! That is, 16GB of files were created from a single 25MB tarball. What was taking up all that room? `du` revealed that the examples/ and demos/ directories were taking up about 15GB! I ran `make install` just for the fun of it, and my / partition, which had about 2GB available on it, gave me “cp: cannot copy, no space left on device”. The examples directory was 2.1GB! That is, the binaries and source of the examples is ~2.1GB!

Wow, that’s a lot! I went back to hacking .pro files. I edited projects.pro and removed both the demos and examples subprojects and reran qmake–sweet! I then ran `make distclean` (for some reason `make clean` left a bunch of stuff sitting on my disk, about 10GB of it, in fact!) in both of those dirs, and reconfigured. ./configure is now chunking along nicely, and my fresh partition “only” has 2.2GB in use.

Yay, yet another compile of Qt, it seems like it takes forever to compile. When I use -j with make (runs multiple compiles at once), I always get linker errors because one part of Qt is done compiling, but it depends on another part which isn’t finished yet. *sigh*

Oh well, it’s worth the wait and screwing around–Qt rocks, and Qt 4 looks like it’s going to rock even more!


taj@moria:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda2 21G 20G 564M 98% /
/dev/hda3 9.9G 9.9G 0K 100% /home
/dev/hda1 15G 14G 1.1G 93% /mnt/win
/dev/hda6 4.7G 2.9G 1.9G 61% /mnt/music
/dev/hda9 16G 1.7G 15G 11% /mnt/osx

That’s an 80GB HDD, by the way.

Oh, and I have no room in me /home because I’m trying to compile Qt 4.1. It almost finished, but errored with:

ld: final link failed: No space left on device


It’s a laptop, so I can’t just stick another HDD in there and use it with LVM or anything…

*shrugs* — maybe I’ll ditch my osx partition–I was running OS X through PearPC, then I used it to store audio from our recording session (hmm, I should really upload those in MP3s and make them useful…).

Or maybe I’ll delete my useless crap–although I’ve already (re)moved 3GB of it from /home. Qt 4 apparently requires lots of GBs to build… :!?

I just got a new WiFi card that actually works with Linux. I’ve suffered for about 2 years with a Belkin F5D6020 PCMCIA card that barely works under Linux. Unfortunately, I have version 2 of the card, which looks exactly the same as version 1 on the outside, but has completely different insides. Anyway, this card used the Atmel WLAN Drivers, which haven’t been updated in about a year. I was never able to get this card to work with 2.6, only 2.4.

So, I bought a Cisco Aironet 340 PCMCIA card, which supposedl works out of the box with Linux. It did–I just needed to rebuild my kernel with the airo_cs module, which I had skipped before. The only physical thing about it that I don’t like is the flashing “Status” and “Activity” lights. Both were quickly removed with a little black tape.

Rock on, WiFi!