A view from the hill

Debian just published an update to their stable distribution etch dubbed etch-and-a-half. The big news here for everyone not accustomed with Debians release cycle anyway is that it's the first time that it's not only a point release that fixes security issues but it's an update to the stable release that gasp adds support for new hardware, too. It even brings important fixes for some applications.

First of all, that's a tremendously good step in the right direction. In the past I've been bitten more than once by the long release cycle of Debian, outlasting all care taking of hardware compatibility. It's the primary reason that the only machine under my direct control running Debian is my rusty private workstation at the moment, all other machines needed newer drivers and hence are installed with Ubuntu. So, if Debian finally realizes that it has to change something to support newer hardware that's more than welcome.

However, it's not really etch-and-a-half. It's not much more than a new kernel which I would compile regularly from kernel.org myself anyway. Admittedly, there are also two new xservers (for nv and intel), but that's still not very helpful for people with newer ati hardware, for instance. But I'm a developer and much more than any hardware hassle I'm much more bitten by really outdated development tools. I've written only one blog entry about the issue, but it's a topic that most developers could write books about -- or maybe not, most of them probably just compile newer versions as needed and are done with the issue. This looks like the easy way out but it doesn't really solve the issue: if you've got to deploy your software you'll need to ensure that what you need is there. But using newer versions of base libraries forces you to deploy them yourself, which also means that you got a problem whenever a security issue will be found in those libraries. On the contrary, with system libraries you don't need any manual deployment of libraries you're only using and you can hope to participate of all system updates. So, in my eyes that's clearly a big advantage for using system libraries. But with Debian (and etch-and-a-half doesn't change this) you're stuck with older libraries which a) might lack long wanted functionality and b) are incompatible with versions from other vendors, which is a pain if you need to deploy on different platforms. Now, granted that the latter problem is not only tied to the age of libraries, but it would be a lot smaller if Debians general release cycle wouldn't be that long. I know of software vendors who have thus decided to develop for Ubuntu but not for Debian, in order to minimize portability issues due to library/functionality mismatches between platforms. To me, that looks like quite high a price to pay.

I've tried Compiz with Metacity again and switch it off after a day -- again. I'm not willing to do without working software suspend just for some graphical whizz. I've been using Metacity for, I think nearly two years now, on my work computers and have somehow accomodated to it's various glitches (for instance the unusable keyboard settings). On my trusty home workstation, however, I've stuck with WindowMaker, which I think I've been using roughly since 1997 (I can't remember the version number, but it was fairly low). Unfortunately, development seems to have stopped -- since quite some time there is no sign of activity on the webpage and the mailing list archive is dead.

Yesterday, out of a current frustration about Metacity, I installed a naked current version of WindowMaker on one of my machines, under Ubuntu 8.04 (don't try to make WindowMaker work under Gnome: While WindowMaker does "work" under Gnome, it is really crippled. For instance, the keyboard setting know nothing about WindowMaker but still override your keyboard settings via, say, WPrefs.). Nearly everything worked as expected, but there were two glitches: the menu didn't reflect the installed software. Having customized the thing under my Debian system, I knew that this was supposed to work with the update-menu script, but that was missing. Some web-searching revealed that for some reason or other Ubuntu no longer installs the menu(-xdg) package. The other glitch was a very old complaint: That WindowMaker doesn't ship with a virtual desktop switcher or pager. You don't need to tell me about the different philosophy of WindowMaker, I know all about it. However, I've been using Fvwm and OpenLook (OLVWM) too long.

I could use gnome-panel (which I've done before in the past), but of course that brings me those two panels that make sense for Metacity and besides it also means that I would still depend on gnome. I've did quite a bit of looking around to find out what all the cool Fluxbox, Openbox etc. users are using and finally found fbpanel (the trick was to search for "taskbar" instead of "pager"). So, finally thanks to netwm support (which I think is in WindowMaker since 0.90), the one missing bit from WindowMaker is finally there without Gnome. Oh my, I'm finding this out really late.

Steve Yegge blogs about XEmacs needs to die and I would like to add my own little comment on the issue. First, perhaps some background: I'm a long-term XEmacs user, since about 1995, I think. I started hacking Elisp around 1996, implementing a major mode for the Otter theorem prover and various other stuff. Since 1997 or so, I had been somewhat active on the xemacs-beta mailing list, reporting build successes/failures, participating in discussions etc. and even writing an article on the then-new XEmacs port to Windows in the german iX magazine. So, perhaps, I'm a bit biased towards XEmacs. That I've been using XEmacs instead of Emacs had a lot to do with two factors: at my university, the local Emacs guru used XEmacs and provided a very complete configuration to start with. To start hacking Prolog source didn't require any configuration on my side at all. When I tried to re-establish that configuration on my own linux box, using Gnu Emacs was totally out of the question, which is basically the second reason: XEmacs came with a lot of batteries included, whereas Gnu Emacs only came with a directly dying low battery at best. And third, the XEmacs interface experience was a lot friendlier than with the naked Gnu Emacs.

Now, at the time I was actively following XEmacs development, XEmacs had a whole lot of man power behind it, with lively discussions and an exciting movement of adding new features. At the same time, RMS discussed switching Gnu Emacs to Guile (a scheme dialect), which me, as a Common Lisp user, scared me off even more. Around 2002 or so, my spare time for XEmacs dropped to zero, so I unsubscribed the development mailing list and was just a happy user. Until two seemingly unrelated things happened: first of all, Unicode was no longer to be ignored and it was obvious that the Mule (multiple languages for emacs or some such) for XEmacs wasn't up to the task, especially not on Windows. That was quite a problem for me back then with the then current stable XEmacs 21.4. Now, six years later, XEmacs 21.5 is still not there (aka released as the new stable version) and it's unicode support still sucks (not so much as it did, say, two years ago, but it still fails a lot of tests from Markus Kuhn unicode test suite). The second development was that the Emacs team, which I had only barely been aware of previously, somehow gained a enourmous momentum and catched up a lot of ground, where XEmacs had been the leader by far. In particular, as of Emacs 22, nobody in its sane mind could argue against the fact that the current Emacs handles Unicode etc. far better than XEmacs (this is especially true for XEmacs 21.4 on Windows, but even the current beta XEmacs 21.5-b28 on Unix isn't where it should be). This seems to be directly related to the fact that a lot of the key developers of the end of the last century no longer actively participate in XEmacs development. I think only few people from the XEmacs crowd would argue against the impression that XEmacs development has more or less cringed to a halt and the distribution of development power between Emacs and XEmacs development is nowadays reversed to the situation from the 90s.

That being said, I still stick with XEmacs. Last time I tried using Gnu Emacs (that's the Emacs 22 from Ubuntu Hardy), I still found that I'm far more accustomed with the XEmacs intrinsics on how to perform specific actions than with how it works in Emacs. And I never got around to clean up my mess of configuration files to properly support the various flavours plus adding the extension libraries that still don't ship with Emacs (Slime, for instance). Finally, with more and more users switching to Emacs, there has to be someone reporting problems,

Now, back to Steves blog post: I think he has some valid points in it, but for the most part I disagree. First of all, while I agree that Eclipse and similar IDEs are still not at the greatest enemy to Emacs (regardless of flavour). I'm currently again using Eclipse at work and it's a pain finding out how to properly associate an unknown file extension with some specific editor (mode). And it's a memory hog that results in unbelievable handling (on my dual core 2GB equipped desktop) that is even worse than my first XEmacs experience on my 486/33 with 8MB ram in 1995. Eight megs and constantly swapping? Hah! I can't believe that even today I have to hear that Emacsen would be too complicated, given that for any task/configurations I spend endless time searching/clicking through the gazillions of settings in Eclipse.

However, I also don't believe that a marriage between Emacs and some web-browser is the way to go. There are much more pressing issues to move Emacs into the next century than switching from Elisp to <whatever>. If you're interested in extending your editor, you have to learn about the way how to do that. But that is totally independent from the question which editor you're going to use in the first place.
What is a much more pressing need in my opinion is finally implementing multi-tasking for the (X)Emacs core. Still being locked in a single-threaded application model is sooo 1990s. It's not becoming more and more ridicuosly, it's utterly unbelievable.

In one other point, though, Steve is right on track: the divergence between APIs is becoming a bigger problem with every passing day. I think it's very unfortunate that a) Emacs developers don't let them inspire by the existing APIs in XEmacs and vice versa and b) that there are too few XEmacs developers that merge current Emacs enhancement into the XEmacs codebase (the other way 'round is always problematic due to license issues).

So, before I would consider pursuing a major architectural change like XUL or some such for Emacs, I would first work on the much lower-hanging fruit of narrowing the gap between the two flavours. It's a pity I myself only have the spare time to write such blog posts instead of actively working on code towards that goal.

Dell is selling Ubuntu equipped systems since about a year now and seems to be quite happy with it. Whatever that effectively means, at least I can tell that I'm quite happy with Linux on Dell systems, too.

Through the last five years, I've been using Linux on a number of Dell systems. Under my personal control there have been three laptops (Dell C610, D610 and a Latitude 640) and a desktop (Optiplex 755), on which I have been running Debian Sarge, Ubuntu Dapper, Feisty and now Hardy. We also had several Dell servers at work running more or less smoothly with Debian (sarge, etch). Using Linux wasn't always without problems: I had trouble with built-in modems, PCMCIA ISDN cards and acpi/hibernation. For example, on my private Latitude 640, I have trouble suspending at all, because of the ipw3945 driver for the wlan. But the important thing to note is that basically all problems were really small and never of a size requiring me to use some other OS in the first place.

The only real issue is not with Dell per se, but more with my favourite OS, Debian: over the years, and especially with the ever-lasting sarge release, getting Debian to run on a recent system got more and more difficult. That's the main reason why I've been using Ubuntu on all recent hardware I had contact with: it's more or less (more so than less) a Debian system but does run on modern hardware. Main issues here were graphics adapters, sata/scsi hostadapters and network/wifi cards, or to put it otherwise: too old kernels, too old X.org. Both problem sources can simply be solved by using a recent version of Ubuntu. Sorry, Debian, but your release cycle is just too long to be acceptable. Granted, all these problems are mostly an issue when installing a new system, but it's not always possible to plug in some old disc with a working version of Linux.

Recent fun:
- Working hibernate/suspend without any manual configuration on a brand new Dell desktop using Ubuntu 8.04 (beta).
- Watching a self-generated video CD (probably done under Windows) under Linux without any problem with my wife that we couldn't watch on Windows due to scrambled colours under Windows media player.

Recent less fun:
- Hibernate/suspend on our older Dell laptop with Ubuntu 7.10 and finding it's a known issue with the ipw3945 driver.
- Getting vmware to work on a recent 2.6.24 system.
- Having fixed that finding out the hard way that Aero won't display in the VM, requiring to go back to cloning the (not so small) physical machine a third time.
- Being unable to get a DHCP lease over the rt2x00 driver for my USB wlan stick with kernel 2.6.24, despite being able to get a sucessful connect via wpa_supplicant/wext.

Two days ago, I updated my laptop from Ubuntu 6.06 "Dapper Drake" (aka LTS) to "Feisty Fawn", aka version 7.04. Just in case you wonder, how I did that, I just followed the usual directions and first updated to Edgy and then to Feisty via issuing "gksu 'update-manager -c'" twice. Things went quite smoothly, but I did encounter some problems:

- I lost access to my databases during the migration from Postgres 7.4 to 8.2., i.e. there was no proper migration and as support for version 7.4 has been dropped, I even have no way to dump the old data and import it again. I need to figure out whether I can easily access the old dbs from Postgres 8.2 (mind you, I'm talking of the raw data and the DB server, not client access).

- As a result, my local copy of serendipity stopped working. I re-installed serendipity (a clean start seemed to be a good idea), but still Iceweasel gets wrong information about the phtml files it generates. Probably a problem with the PHP installation, which I need to get straight (I'm not a PHP guy, though).

- When booting into Edgy, when switching from the splash screen to X. the screen went black and there was no way to get a display. I solved that by ssh-ing into the box, modifying /etc/X11/xorg.conf by using the ati driver instead of the fglrx driver and then editing /boot/grub/menu.lst so that it wouldn't show the splash screen or suppress messages. The problem went away after going to Feisty.

- To get VMware running again, it wasn't enough to issue the usual /opt/bin/vmware-config.pl that you have to do with every new kernel. It kept telling me that the headers directory wouldn't fit my current running kernel. Fortunately, I already had loaded the new version down which solves the problem (I guess there is a new version numbering scheme in newer kernels).

- The update of course also brought with it the switch to Iceweasel, so of course, I lost some of my trusted extensions (Reveal, Surfkeys).

- What really annoyed me was the ugly, fat looking "optimal" font that I encountered in most applications. Why Gnome doesn't use subpixel hinting as a default is beyond me (especially as I'm quite certain to have had that setting in the old setup, too).

- The new eclipse version of course knew nothing about my local installed plugins, implying that I had to reinstall them.

On the nice side, my mail setup kept working and the network setup kept working, which I think is way more important.

Dear Lazyweb: Are there any good tutorials on turning a running native Windows installation into a Xen instance (i.e. without a fresh installation)? Preferably on an Ubuntu (edgy) host? Alternatively, Debian etch would also be an option, though I don't believe the OS of the host system matters much. Yes, I know, I need paravirtualization for that, but apart from that I know next to nothing about Xen, so all up-to-date tutorials on Xen are welcome, too.

The other issue is that I never got hibernation working on the server and I fixed that today, too. I use a vanilla kernel.org self-compiled kernel on the box, so I could have gone for Suspend2, but as I have sysfs_power_state working on my Ubuntu laptop without much hassle, I wondered what was the problem on the server. As it turned out, suspend to ram (mem) doesn't seem to work and as that always had failed, I think I never really tried suspend to disk. Additionally, I hadn't added a resume line to my grub configuration, so it wouldn't have worked anyway. After a freeze in NetworkStop on my first try with suspend to disk, I added the rt2570 module to the list of blacklisted modules and now suspend to disk (and resume, of course) works. Yay! I'll be able to continue my hacking on UCW without having to boot it all the time, for instance. Here is what is actually doing the work from the config file:

[root@bauhaus->root]grep -v '#' /etc/hibernate/hibernate.conf | sed '/^$/d' UseSysfsPowerState disk PowerdownMethod shutdown Verbosity 1 LogFile /var/log/hibernate.log LogVerbosity 1 Distribution debian SaveClock restore-only UnmountFSTypes smbfs nfs UnloadBlacklistedModules yes LoadModules auto DownInterfaces rausb0 eth0 UpInterfaces auto XStatus x XSuspendText Preparing to suspend... XResumeText Resuming from suspend...

In BaWü gibt es seit einiger Zeit die glorreiche Idee, dass die Schüler, die im sog. Rheingraben in der Nähe (30km) zu Frankreich wohnen, ab dem nächstem Schuljahr an den Gymnasien in den fünften Klassen mit Französisch statt mit Englisch beginnen. Während die Idee auf den ersten Blick ja ganz vernünftig klingt (es ist durchaus hilfreich, wenn man die Sprache seines Nachbarn versteht), bringt sie auf den zweiten Blick eine Menge Probleme. Eine Webseite der Jungen Union (!) www.region-fuer-englisch.de listet einige davon auf (Danke, Kris). Am heftigsten sind m.E. nach folgende zwei Punkte: 1) Der Wechsel von Realschule auf das Gymnasium wird damit fast unmöglich gemacht. 2) Bei einem Umzug aus dem Rheingraben in eine andere Region hat man augenblicklich eine miese Note in Englisch. Und das, obwohl gleichzeitig überall mehr Durchlässigkeit zwischen den Schulsystemen und auch Flexibilität bzgl. der eigenen Lebenssituation gefordert wird. Liebe Politiker, wenn ihr schon das Verständnis zwischen den Ländern fördern wollt, solltet Ihr dafür nicht das Verständnis zwischen den Schülern im eigenen Land vergessen.

Finally, I wanted to give the not-so-new-by-now SBCL 1.0 a whirl. Google led me to Peter van Eynde's Dapper packages, which you can install if you add the last of the following lines to your /etc/apt/sources.list:

root@elendil:~# grep cl-dapper /etc/apt/sources.list
deb http://people.debian.org/~pvaneynd/cl-dapper-packages ./

Unfortunately, on Dapper this breaks CL-SQL or more exactly the version 3.53 it is shipping with. SBCL, or more exactly PCL barfs

When attempting to set the slot's value to (OR NULL T) (SETF of SLOT-VALUE),
the slot TYPE is missing from the object
#<CLSQL-SYS::VIEW-CLASS-DIRECT-SLOT-DEFINITION CLSQL-SYS::VIEW-DATABASE>.
[Condition of type SIMPLE-ERROR]

I haven't seen any complaint about this on the CL-SQL mailing list, so I guess I'm the only one using such an old CL-SQL version with the shiny new SBCL. So, currently I have a broken CMUCL on Debian Sarge and a broken CL-SQL on Ubuntu Dapper. Sigh.

Update:Manually switching to CLSQL solved the problem. Just in case you have relied on Debian or Ubuntu to supply you with the right packages, I found replacing them to be dead easy. I just 'apt-get remove'd cl-sql, but left cl-uffi and cl-md5 in place. Then, I untar'ed the source archive of CLSQL to /usr/local/src/clsql/. One link from there to /usr/share/common-lisp/source and a 'cd /usr/share/common-lisp/systems/ ; for i in ../source/*.asd; ln -s $i . ; done' later, SBCL 1.0 loaded CLSQL 3.8 like a charm.

"Even the greatest stars discover themselves in the looking glass."
-- Siouxsie and the Banshees, "Hall of Mirrors"

Well, if that's so, Sun should probably take a second look at their new 3D desktop, Looking Glass. As they even provide packages for Debian and Ubuntu, getting the stuff installed was a quite easy journey. But unfortunately, the target wasn't really worth it -- Looking Glass is not really ready for prime time (i.e., daily usage), it's more a technology study. Sometimes it's the details that make the difference, e.g. blurry background and fonts, missing keyboard shortcuts to switch between virtual desktops etc. But this time, it's not only the details: I didn't manage to get the 3d file manager to display correctly (i.e. in front) after moving it out of the way, for instance, and I got a hanging desktop altogether very quickly (after about five minutes usage). Most of the apps that you'll get with Looking Glass were non-functional either. Looking Glass is also really slow, even Gnome or KDE are light-weight by comparison. I'll have a second look next year. Or make that 2008.

Peter vanEynde discusses his experience with binary-only drivers for his ATI card:

The machine (a Lenovo Z61m) uses a X1400 ATI chip, so I have to use the ATI binary-only driver. Well. I'm trying to use it. The amount of grief I'm getting from it would convince even billg himself that opensource drivers are mandatory in an opensource system. Strange errors pop up and you're just lost, googling only gives you forums where other poor users are trying to make it all work.

I think he's wrong about convincing that billg. Isn't that just the current Windows experience brought to Linux?

FWIW, when I needed a new laptop for work, I also ordered one with an ATI chip. There is a working X.org driver for it, though, and I double-checked prior to the order. On the other hand, I'm currently using the Ubuntu provided proprietary ATI driver without any trouble. But even if ATI decides in half a year that it no longer wants to support my ATI M300 with their linux driver, the open source driver will be there. So yes, I'm all for open source drivers, but I would be happy with a scheme that has been applied by several vendors in the past: keep the driver proprietary for some time, but release it as open source when your technology has moved to new heights. Perhaps Nvidias and ATIs current behaviour just reflects that there hasn't been any advances in their drivers?

It's no fun when the only thing you can't check in a virtual machine test installation is the connection thingie you have to use when on the road. In my case, the AVM Fritz capi module shipped with Ubuntu Dapper Drake is broken. The bug report is about two months old and still has status "unconfirmed"? At least the bug is not in the binary only firmware but in the source around it. I knew there is a reason I like open source, even if this "open" tastes more like "open beer" in this case (the Fritz drivers still only target the ancient SuSE 9.3).

Getting started with CL-SQL was actually a pretty easy experience. I stumbled over one problem though, and it has a name, even. The packages shipping with Sarge are outdated. So outdated, that I couldn't get my files compiled that would otherwise work fine from the REPL or even load successfully as source files. And, hey, most of the time they would even compile with ASDF, unless I was using load-system from Slime.

Actually, that wasn't the first time I had trouble with Common Lisp packages on Debian. Getting UCW to work actually required a far newer version of sbcl than that old 0.8.12 shipping with Sarge. I built one myself, however, thanks to the work of Rene van Bevern (why isn't he on Planet Lisp?), a recent version (0.9.11) is available from backports.org, so that shouldn't be a problem anymore. New versions of CL-SQL are not available, though, so I copied the newer version of the files shipping with Breezy, which finally fixed the problem.

Yesterday, I ranted about Cincoms inability to fix an apparent incompatibility of VisualWorks with Xorg on Ubuntu. Today, it looks like it's not Cincom fault, but a user-overfriendlyness by
Gnome. I can use VisualWorks on Xorg with e.g. WindowMaker without any problem. Gnome (2.8, at least, as shipped with Ubuntu) generates an empty fonts.dir file in ~/.gnome2/share/fonts which seems like a very pointless idea. It also breaks other applications besides VisualWorks. I will have to wait for Dapper to arrive to see whether Gnome 2.10 fixes the issue.


The other possibilty, of course, would be to drop Gnome (and that Metacity) again. Seems we won't become friends.