It looks like Sun will soon deliver on their promise to allow the services that drive their Sun Ray thin clients to run on Linux. Coupled with the ability for desktops and laptops to act as Sun Ray clients, this feature will make the UBA architecture a very attractive proposition for mid and large-sized companies (even though I fear that Sun Rays for Linux will only run on a server version of Sun's JDS).
If Linux gains better integration with Active Directory (Kerberos auth for cifs network shares, a better ldap_nss or an easier way to share uids/gids with winbind) it could really become a serious threat for Microsoft in the corporate desktop market.
Yesterday I finally received a copy of the latest MadHatter beta available to clients, and installed it on my office desktop. Our Sun representatives warned me that there are bugs, many of which are already fixed in the latest betas which are only for Sun internal use.
As was to be expected, I found good things and bad things in MH, a few of which are undoubtedly due to SuSE 8.1, which is the distro around which MadHatter is built. Before proceeding to recount my first impressions, I have to say that I'm not so much excited in MadHatter (which at this point is little more than just another distro), as in the overall design of Sun's Unix Business Architecture. IMHO Sun is doing something very interesting, offering an attractive per-seat licensing scheme that grants you the rights to use most of Sun's server (messaging, directory services, etc.) and desktop (StarOffice, MadHatter) products.
When you throw in Sun Rays with Linux support (which should be available next year), Sun's offer looks like it has the potential to revolutionize Enterprise IT. The only glitch is that you're supposed to use ONLY Sun hardware, even if your server OS is Linux. I hope Sun realizes this is a huge mistake, as I don't see many companies willing to replace most of their expensive i386 servers with Sun i386 servers.
Back to MadHatter, or the Java Desktop System as everything from desktop icons to console graphics proclaim it to be. This is the thing that annoys me most about MadHatter. Not a bug or some missing feature (it's a beta of a Linux distribution after all, so I can live with those), but the feeling that it's just some sort of fancy packaging, or worse a not so clever marketing tactic. Things like this discredit the technical soundness and innovative potential of the Unix Business Architecture, and IMHO should be avoided at all cost.
Where's Java in MadHatter Desktop? A JRE is installed by default, but the same thing can be said for most modern Linux distributions. If you dig deep enough into the desktop menus you can find a link to Java Web Start, and a link to a Java application that displays disk usage. Not enough to call it the Java Desktop System. Wake up Sun, please don't try to rebrand Linux and Gnome.
On the technical side, there are a few things still out of place in MadHatter. A few of them expose a lack of coherence and vision in the overall architecture of MadHatter, others are the product of insufficient testing and can be expected in an early beta release.
First of all, MadHatter refuses to bring up my Intel EtherExpress Pro100. The desktop where I installed MadHatter has a prefectly working Slackware 9.1, which uses the same card without a problem. MadHatter sees the interface and brings it up, but can't use it either with dhcpcd or by assigning it a static IP. I tried swapping the e100 module with eepro100, but things did not change. What's worse, modprobe spits out errors about missing modules, which in fact are there and can be loaded fine with insmod. The problem is definitely kernel related, since when I tried booting MadHatter with the 2.4.22 kernel I compiled under Slackware, dhcpcd could assign a valid address to the interface and everything worked ok. While this may just seem a technical glitch due to the underlying SuSE 8.1 distro, I think it instead reveals a certain lack of planning in MadHatter: how can a distro come with the very latest stable Gnome release (2.4, released on September 10, 2003), and at the same time with an old stable kernel (2.4.19, released on August 3, 2002)? I think the MadHatter team has a bit overstated the desktop part of the equation, forgetting the importance that a latest stable kernel has for overall system stability, and support for new chipsets. The same goes for productivity languages like Python, which on MadHatter is stuck at the old 2.2.1 version. I suspect most of the other non-desktop programs and libraries to be slightly outdated too.
Another thing I did not like at all is MadHatter wiping out my Lilo MBR, without even acknowledging the presence of a second OS installed on my system. Editing Grub's menu is not a difficult task, but neither is recognizing other bootable partitions on installation.
The last (minor) annoyances I found in my first day of use of MadHatter are the Gnome clock set to GMT in spite of the system's timezone (which you can see in the picture above), and the default widgets theme messing up TTF fonts when using freetype compiled with the TTF bytecode interpreter turned on (here MadHatter's default theme, here the default Gnome theme on the same desktop).
What did I like in Madhatter then? Well, as I already said I like its role in UBA's architecture. As a day-to-day distro I like its polished look, which is not limited to Gnome's desktop but encompasses every part of the system with which the user can interact, including the console. I like it having StarOffice preinstalled (not that I use it much). I like its simple setup, with a limited set of options. I'm sure there will be more good stuff after having used it for a while, and after a few more betas.
update: I noticed from my logs that somebody requested a Google translation of this entry to Spanish so, being the ever curious type, I went to check it out. The best part is this one:
Nuestros representantes del sol me advirtieron que haya los insectos...
Which is a perfectly valid literal translation of Our Sun representatives warned me that there are bugs..., but takes a whole different meaning.
Many of you may already know about RFC1149 A Standard for the Transmission of IP Datagrams on Avian Carriers, which details CPIP (aka Carrier Pigeon Internet Protocol). For those who don't, the date when RFC1149 was issued should tell you something about its origins: April 1st 1990.
Tonight, while browsing new posts on alt.os.linux.slackware I stumbled upon a link to a site recounting the first (and only, I guess) implementation of CPIP.
The ping was started approximately at 12:15. We decided to do a 7 1/2 minute interval between the ping packets, that would leave a couple of packets unanswered, given ideal situations. Things didn't happen quite that way, though. It happened that the neighbour had a flock of pigeons flying. Our pigeons didn't want to go home at once, they wanted to fly with the other pigeons instead. And who can blame them, when the sun was finally shining after a couple of days?
Just what I needed for a good laugh after the second day of the advanced DB2 class I'm following this week (BTW DB2 is very interesting, if a bit archaic).
I have been trying for a while to get Mozilla Firebird to open .pls playlists with xmms. It turns out that you can get the helper applications back (along with a bunch of other options) by installing the Things They Left Out extension.
A quick tip for Gnome users. One of the new features introduced with Gnome 2.4 is the ability to force a window to be always on top. It's a long awaited feature, useful to watch videos while working, checking documentation while coding, etc.
Its implementation can be traced by following Gnome bug #98387, which was opened almost a year ago on November 13, 2002. The bug was not resolved earlier due to a philosophical conflict between the people wanting to keep Metacity's features to a minimum, and the people needing this particular feature. During this bug's life, a few patches were produced, implementing this feature with different ways to control it (a window menu item, a keybinding, etc.).
With Gnome 2.4, it appears that a consensus has been reached with the introduction of the new toggle_above keybinding. If you need this feature, open gconf-editor, navigate to apps/metacity/window_keybindings and assign the new keybinding a key combination.
Last night Italy suffered a massive blackout, so this morning I came back from the lake Maggiore to find my server dead. The server, which runs all our mail and web sites, was (yes, was) a very old Compaq Deskpro with a Celeron 300 and twin 4Gb disks configured as a software RAID-1 array. I liked it because it was a very silent and low- consumption machine with no CPU fan, and I don't need more power than that to manage a few mailboxes, a couple of web sites, and my home LAN.
I knew it was in bad shape, but I always managed to reboot it in the past, the very few times I needed to- Today I tried everything, but the bios screen refuses to come up, and no beeps escape from the speaker at boot time.
So I wasted all day trying to let my desktop's twin machine (an Athlon 750 PC I built three years ago) see my server's two disks, and remount the RAID array. The new machine's BIOS screws up the disks geometry, and if I attach both of them on the two IDE channels, I see only the first one. Weird.
So I burned a mini-CD with tomsrtbt, transferred everything on a 20Gb disk, rebuilt the array, hotraidadded one of the two 4Gb disks, reconfigured LILO, rebooted, and LILO started spitting out error messages. Reconfigured, double checked everything, LILO comes up with a checksum error. Hmmm I'm getting old for this, I remember when it was fun but it's not anymore.
In the end I installed Grub, took the 4Gb disk off the array, fscked to death the 20Gb disk who got corrupted in the meantime, and the server is back up. Tomorrow I will buy a second 20Gb or 40Gb disk and add it to the RAID array.
The only good thing to come out of this is that I learned something more about Grub, and I really like it. If things get tough, Grub is your friend. A few useful links if you want to switch from LILO to Grub, boot a software RAID partition from Grub, convert a running system to software RAID (mainly geared towards Debian users, Slackware users may find this more useful).
My fiber optic link where this site is usually served from is still down, something to do with the Catalyst in the basement who serves the whole building, I have called a few times but all I'm getting is it will be fixed RSN. If I knew how to lockpick the rack, and I had not spent the whole day fighting disks and LILO, I would be tempted to connect my laptop and try to bring it up myself (but maybe it's not so easy anymore to reboot a Cisco and get enable permissions). Luckily I have still my ADSL link, who promptly resumed service as soon as power came back. I have switched the DNS to the ADSL address, so this site will slowly resurface on the Web, but it will be pretty slow until the fiber optic link is working again.
A few days ago I finally got fed up with spam, so I decided to install a spam filter on my server. After reading around a bit, I settled on Spambayes, which (apart from being written in Python) looks a very solid and well maintained project.
I don't use Outlook (I run Linux both on my server and on my desktops), so using Spambayes Outlook plugin was not an option. Since I'm using Maildir as the storage format for both SMTP and IMAP, I initially tried the Spambayes IMAP filter. Unfortunately, the filter is still in its early stage of development, and the IMAP protocol varies significantly among different server implementations. The main problems I had with the IMAP filter were its marking all new messages as read after processing (this is apparently due to my IMAP server lack of support for an obscure IMAP command), and its frequent crashes.
So after a few hours of monitoring the IMAP filter's activity, I decided to change my approach. Reading around a bit, I discovered that the venerable procmail (which I used a lot until five or six years ago) now natively supports Maildirs.
A .qmail forward file, a .procmailrc recipe and a cron job later, I had a flawless Spambayes setup. In the past 3 days, Spambayes has worked admirably with minimal training, intercepting 99% of all spam and generating zero false positives. Definitely recommended.
My .qmail file simply passes everything along to procmail for delivery:
| preline /usr/bin/procmail
My .procmailrc recipe looks like this:
PATH=$HOME/bin:/usr/bin:/bin:/usr/local/bin:. MAILDIR=$HOME/Maildir DEFAULT=$MAILDIR/ LOGFILE=$HOME/procmail.log LOCKFILE=$HOME/.lockmail :0 fw | /usr/bin/sb_filter.py :0 * ^X-SpamBayes-Classification: spam .INBOX.spambayes.spam/ :0 * ^X-SpamBayes-Classification: unsure .INBOX.spambayes.unsure/
Notice how the trailing slash in the DEFAULT delivery identifies a Maildir storage. The rest is pretty self-explanatory, apart maybe from the folder namespace, which is the one used by default by my IMAP server:
- the first directive instructs procmail to feed the message to sb_filter.py
- sb_filter processes the message and adds the X-SpamBayes-Classification header with two values, the first one marking the message as either spam/ham/unsure, the second one displaying the exact numeric spam rating (from 0 to 1)
- the second and third directives match the header on its first value for spam and unsure, and deliver the message to the appropriate Maildir
- if a message is not matched by the second or third directive, it "falls off" the chain and gets delivered to DEFAULT, which in this case is my inbox
To train the filter, I run a cron job every half hour that looks into two Maildir folders for spam and ham messages (the following lines are ofc a single crontab line):
0,30 * * * * /usr/bin/sb_mboxtrain.py -d /home/ludo/.spambayes_hammie.db -g /home/ludo/Maildir/.INBOX.spambayes.train_ham/ -s /home/ludo/Maildir/.INBOX.spambayes.train_spam/ -n >/dev/null 2>&1
Meaning, every half hour cron runs sb_mboxtrain, instructing it to use the .spambayes_hammie.db (previously created with sb_filter.py -n), and to fetch ham messages from the .INBOX.spambayes.train_ham Maildir, and spam messages from the .INBOX.spambayes.train_spam Maildir.
The Maildir directories where spam/unsure messages get delivered, and where you deposit messages to train SpamBayes, can be created either from your mail client or with the command-line utility maildirmake, provided with qmail and courier.
The last piece of information you need before running this setup, is a .spambayesrc file in your home directory. Mine contains the following lines:
[Storage] persistent_use_database = True persistent_storage_file = ~/.spambayes_hammie.db
That's all, efficient and reliable spam protection in 5 minutes or so.
Tonight, while trying to scan very old (100 yrs or so) negatives on my cheap ScanJet 3400c, I managed to read the very good article The Mad Hatter meets the MCSE, mentioned on a Slashdot post.
As I wrote in a past entry, I saw Sun Rays and MadHatter at Sun's Milan offices a few weeks ago, and I was deeply impressed. This article examines in detail the impact of introducing a Lintel architecture in the Enterprise.
What I liked most from tonight's quick read of this article (gonna read and summarize it for the big shots tomorrow at the office) are a few well-made points:
- a Linux integration in the enteprise is a potential and very expensive failure, if it has to adapt to a Windows-based infrastructure
- a Unix-based architecture is unlikely to evolve in Windows or Mainframe centric environments due to cultural differences between the two worlds
- Sun's Unix Business Architecture (UBA) has a tremendous potential and could change the way enterprises design and manage their IT infrastructures
Definitely a recommended reading.
