MicroClient Sr. //at 04:35 //by abe

About a year ago, I bought a Norhtec MicroClient Jr., a complete 200 MHz MMX-compatible SoC (“Vortex86”) PC so small that it fits into your hand or onto VESA mountings. Althought thought as thin client, the machine has 128 MB RAM and runs Debian from either netboot, USB stick, CF card or 2.5” harddisk without problems and not even that slow.

Later last year, we needed more MicroClient Jrs. at work and since the MicroClient JrSX had a 300 MHz 486SX-compatible SoC processor (“Vortex86SX”) from MSTi and 128 MB DDR RAM instead of SD RAM, we expected them at least in the same performance range and bought a few for ETH and I also bought one for myself. Well, they were about three times slower, since the FPU is missing, not all programs from Debian Etch work fine, e.g. X doesn’t work without patching and recompiling (with Sid, X works, but not the kernel anymore – Update, 26-Jul-2008: See #454776 for a solution for this problem)…

BTW: I had both machines with me at FOSDEM ‘08 at the Debian booth and the MMX-compatible machine also at Chemnitzer Linux-Tage (CLT) at the Symlink booth and in Kurt Gramlich’s talk about ecological computers. So if you saw them there, just imagine the same case, with a twice to three times faster CPU and four times the amount of RAM, but with roughly the same carbon foot-print!

For our thin client purposes at work we now use ALIX boards from PC Engines (Mini-ITX format) with 500 MHz AMD Geode processors. They’re much faster than the MicroClient Jr. and need even less power.

Today, while surfing around on some Mini-ITX shops, I found some computer in obviously MicroClient Jr. case, but with 500 MHz VIA Eden processor and 512 MB of RAM. I first couldn’t believe it. They are selling it as eTC-2500. Since eTC-2300 was one of the brandings of the MicroClient Jr. which is called eBox-2300 officially by the manufacturer DM&P, I searched for eBox-2500, but didn’t find anything useful. Then I looked at the manufacturer’s product page at CompactPC.com.tw and found the eBox-4300 — so it’s really true, they managed to fit a board with 500 MHz VIA processor and half a Gig of RAM into the already fscking small space inside the MicroClient Jr. case, and even without needing more power: Still 15W from the power adaptor. Next stop was Norhtec’s Website. And yes, they also have a new MicroClient product: The MicroClient Sr.. I really need to have one of those for my MicroClient collection! ;-)

Axel’s Cruftiness Theorem //at 19:20 //by abe

Theorem: If aptitude is used, set to automatically remove unneeded packages and every not willingly installed package is marked auto, the system’s cruftiness is always 0.

Is ikiwiki a Website Meta Language killer? //at 22:29 //by abe

On this year’s Chemitzer Linux-Tage (CLT, engl. “Chemnitz Linux Days’) I attended a few talks of which especially formorer’s ikiwiki talk was very interesting.

I attended his talk since I found out that ikiwiki is command line wiki compiler in contrary to the thousands of solely web based wikis out there. As a big fan of statically generated content this idea sounded very interesting to me.

But just having a short look at ikiwiki’s web page didn’t help to get started and it seemed as if I had not the right idea of how ikiwiki works to get started. So formorer’s talk seemed to be a good possibility to get an idea of how ikiwiki works without much effort.

During the talk I noticed that ikiwiki can many things I do with the Website Meta Language (WML), but can do some more things WML can’t do out of the box:

1. It’s not only a framework to generate web pages, it’s more like a content management system (CMS).
2. Versioning is intergal part of ikiwiki without reinventing the wheel: It works out of the box with — beyond others — Subversion, Git and Mercurical (Hg).

And when formorer showed that even Tobi Oetiker uses ikiwiki, I noticed that ikiwiki probably could be a WML killer, since I knew Tobi as a WML fan. And ikiwiki looks very appealing for the WML fan inside me, too…

OTOH: Intergrating WML as a backend to ikiwiki could be an interesting idea, though.

Hearing what kind of input files ikiwiki can process, I also got the idea of using hnb (Hierachical Notebook) files as input for ikiwiki. hnb files are already XML and so a conversion to XHTML shouldn’t be that hard.

But when searching the web for “ikiwiki hnb” I found the blog postings of a few people switching away from hnb, e.g. to vimoutliner. Since I’m an Emacs addict and don’t like vim very much (if I use a vi, I use nvi or elvis), I searched for “emacs hnb” and indeed found someone who switched from hnb to org-mode – of which I never heard before. Unfortunately org-mode doesn’t seem to be in Debian (Update 00:23: Yeah, yeah, I now know it’s included in emacs22, but emacs22 hasn’t made it into kfreebsd-i386 yet, so I didn’t notice. See the comments. :-) but I’ll play around with it a little bit. Unfortunately a first test wasn’t that promising. But we’ll see.

Now playing: Men at Work — Down Under

WTF per minutes and yet another popular Blosxom-alike I didn’t know about //at 02:42 //by abe

Today while reading Planet Webtuesday, I stumbled upon a nice cartoon about the one and only measurement of code quality: WTF per minute.

Somehow I noticed that the blog in which this cartoon was posted in is powered by Blojsom, a Blosxom derivative written in Java (and nowadays database powered). I already have heard of a lot of blogging software which works similar to Blosxom and often is also named similar, e.g. Pyblosxom or Blosxonomy, but Blosjom hasn’t been noticed by yet although it is mentioned in Children of Blosxom where I first noticed Blosxonomy.

So far, so good, but what really surprised me is that a blog engine developed after Blosxom’s ideas officially made into MacOS X 10.4 Server. (BTW at a time, I neither had a blog nor knew about Blosxom. :-)

Segmentation faulty tree //at 21:28 //by abe

aptitude on Etch just gave me a funny error message:

1/0/0 root@c2:pts/2 21:14:24 [~] # aptitude upgrade 
Reading package lists... Done
Segmentation faulty tree... 87%
2/139/0 root@c2:pts/2 21:14:43 [~] # 

Ctrl-Ms can be nice sometimes…

Why I’m happy that FreeWRT doesn’t need a web interface //at 15:37 //by abe

When I have to read things like drive-by pharming (via Heise, Symlink article), I’m really happy that there are free 3rd party router firmwares out there, that don’t need any shitty web interface.

My ASUS WL-500g Premium runs FreeWRT and the only possibility to change the configuration is to login via ssh and edit the configuration files as root.

I really pity all those out there who have to cope with the partially really sleazy web interfaces home routers currently offer.

Following Bleeding Edge Software and still using Debian Stable //at 23:47 //by abe

Many Linux fans know that Debian Stable usually already lost the “b” when it’s being released. ;-) What seems not so well known (especially not by some DesktopBSD Marketing guy at last year’s LinuxDay.at :-) is that there is really a lot of people who really like this “stale” software collection — because it’s rock solid — especially compared to the ports in FreeBSD or DesktopBSD *evilgrin* which unnecessarily follow every new feature upstream introduces. This is really annoying in a server environment where you want as less changes as possible when updates are necessary due to security issues. My personal favourites here are Samba and CUPS. *grmpf*

Although I belong to those people who run Debian Stable even on brand-new hardware, I sometimes have to use the newest beta or alpha versions of some software to get it even only running. And doing so is fun but feels strange somehow, though. Currently I follow the pre-releases of three software makers quite close, due to a new laptop:

At the beginning of last semester I bought a brand-new Lenovo ThinkPad T61 (2,2 GHz Intel Core2 Duo T7500, 4 GB RAM, 160 GB HD, 1440x900 14” Widescreen) without preinstalled operating system (possible thanks to the ETHZ Neptun Project) and installed — of course — 64-bit Debian Stable on it.

While the Debian Installer from Etch worked fine even on such new hardware, not all features worked out of the box because some components were just too new.

So the first thing I did was installing 2.6.22 from Backports.org, quickly moving farther to vanilla 2.6.23. Nearly everything I needed worked except the wireless network card. It needs the iwlwifi driver which is officially in the Linux kernel starting at the upcoming 2.6.24 (said to be released during the next few days). So I run 2.6.24 pre-releases on the laptop since the first release candidate, always eagerly waiting for either the next RC or the final release. (And 2.6.24 looks impressively stable to me — even since the early release candidates. :-)

I even got the fingerprint reader working for login and sudo (but not xscreensaver) using libthinkfinger backported to Etch from Debian Experimental. I’m just not sure if this is a good idea since the back of the screen already has enough of my fingerprints on it. ;-)

The next software of which I’m currently running an alpha version is 64-bit Opera 9.50 (aka Kestrel, available at snapshot.opera.com) because no earlier Opera version is available for 64-bit Linuxes. Here I had different experiences: The builds from October and November were already quite stable, but since December it crashes usually several times a day.

At work I also run the 64-bit Opera on my workstation, but stalled updating it when I noticed that it became so unstable. So my Opera at work has currently an uptime of nearly four weeks — and would have probably more if I hadn’t rebooted my workstation in Mid-December.

Somehow this hunting for new versions and eagerly waiting for every new (pre-)release makes me really fidgety sometimes. And my understanding for people doing this for there whole userland or even operating system has grown, but I still prefer to have stale but stable software on all my productive machines, even on my laptop — just with some few and handpicked excpetions.

The third but less thrilling thing I’m following are nVidia drivers for X. Since the free nv driver of X.org doesn’t support (and not only just doesn’t know) my graphics card yet and nouveau isn’t ready yet, I run the binary only and closed source driver from nVidia, waiting for that one release which supports Xen since I really would like to run a Xen guest with Debian Unstable for testing purposes and package building on my laptop. Until then I have to content myself with the much more unwieldy QEMU respectively KVM.

Anyway, I’m very happy with the T61 and Debian Stable and can easily connive at the few not (yet) perfect issues like missing Xen support by nVidia, broken ad-hoc mode in the wireless card, no internal card-reader (as announced in the Neptun specifications) and no native serial port.

Some useful links regarding the subject of this post:

• Linux Weather Forecast
• Opera Desktop Team
• Nouveau: Open Source 3D acceleration for nVidia cards
• ThinkWiki

Now playing: Jean Michel Jarre — Rendez-vous à Paris