I'm often asked by Windows users about a safe way of browsing the web. What they usually think of is a kind of minimal linux running nothing but a browser. The 'browser appliance' offered by VMWare is, in principle, exactly what they have in mind, but is dangerously outdated: it is based on Ubuntu 5.10 and was last updated in June 2006.

Out of sheer curiosity, I've build a kind of browser appliance based on Archlinux. Basically, it's a naked install of Arch, plus Xorg, and wmii as windows manager. One ttf font (liberation), one type1 font (xorg). One browser. Today, I felt like using firefox. 😉

The appliance includes, of course, all development tools necessary for the build of the guest additions in Virtualbox. It's just above 1 GB in size and has a memory requirement of less than 64 MB, so one can certainly run it even on low-end systems.

I know I'm late by one week, but if you don't use Zenwalk regularly, you'll be surprised when issuing the standard 'netpkg upgrade' in these days. Zenwalk upgrades itself to version 6.0 smoothly and without any issues. It was, in fact, so smooth that it took the new and really cool screensaver to make me realize that I'd just jumped from version 5 to 6. 😄

That turns my counter of easily upgradable Linux distributions one click to the right. Hm...to be exact, there's just one lonely contender left on the list, namely: OpenSuse. Before you start throwing eggs, tomatoes or worse things: try an online upgrade from OpenSuse 10 to 11 yourself. Hell, try one from 11.0 to 11.1 Online! And don't cheat ...

Nothing new, of course. What's new is that this already happens with Windows 7, which is still in the public beta stage. Yes, MS provides updates for a beta version...security updates, naturally, and quite a few of them. The latest ones, however, break Windows 7 when run in a virtual machine: windows can't be moved anymore, and their close button is inactive.

Memo to myself: I don't need a fun category. 😄

Update of the browser snapshot.

I own a 24" monitor with a resolution of 1920x1200 pixel. That's ample space for two DIN-A4-sized windows open side-by-side with plenty of room to share. I can, for example, work on a manuscript in kile, have okular displaying the compiled version right next to it, and still see gkrellm.

Whenever I mention this example, or demonstrate it, people start nodding. They always seem content to agree that wide-screen monitors are useful for displaying several applications at once.

Secretly, however, people love maximized windows. That's at least what I suspect after observing people using their desktop with similarly sized screens. Or when I have a guest who wants to check his/her email. 😏

Said guest would look at my browser window, and get visibly nervous. My browsers are always adjusted to display pages of a width of 1024 pixel in their entire beauty, but not more. 99% of all well-designed pages fall in this category, and, indeed, also the page my guest wanted to visit. But what was she doing? She maximized my browser window – poof!

What's the gain of maximizing a browser? If the website has a fixed width, you just end up with a huge browser window displaying lots of empty space. And if not, you get text lines with a width of 40 cm. Well, I guess the multi-column layout of newspapers and journals with a maximum column width of 8 cm is just old-fashioned. 😏

Why, indeed, are people so much drawn to maximization? Do they have a rational reasoning for their doing, or is all this deeply rooted in their childhood and related to the supressed sexual desire towards their first Atari? I was curious and asked. Here are the most frequent answers:

• What the heck are you talking about? (30%)
• My eyes, you know, my eyes! I need that. (20%)
• I want so see everything, also the things in the corner! (10%)
• That's just how you do it, you know. (10%)
• It's ... ehhhh.... you know. (90%)

Now, isn't that just hilarious? 😄 Let me summarize some technical ** facts **:

• The font of a page does not get bigger when you maximize the browser.
• Maximizing web pages does not deliver any "hidden" content.
• Maximizing windows will not magically heal your computer.

The century-years old knowledge of typographs is still valid. For optimum readabilty, text should be not wider than at most 60 characters.

Now, don't just shrug it off, laughing about “these Windows users”. True, the behavior described above is quite characteristic for users of Windows. But I have seen the same behavior even for veteran users of *nix. It's a disease. Help me to limit its spread. 😉

And, by the way: I've seen you maximizing too....

What I forgot to mention in my first post on Arch : you can, if you like, refrain from binary updates altogether and instead use an entirely source-oriented approach to package management. The "Arch Build System" (ABS) is completely analogous to the ports system, which dominates package management in any self-respecting *bsd. 😉 Upon installing the ABS system, you'll get an ABS tree in /var/abs, are able to create binary packages via makepkg, and install them with pacman. Compared to FreeBSD [1] I'd call the Arch procedure exceedingly simple and transparent.

In addition, Arch has something special in store for you: the "Arch User Repository" (AUR). The AUR contains source packages approved and prepared for build by the Arch community. To simplify usage, Arch programmers created yaourt (for our linguistically challenged American friends, that's French for yoghurt 😄 ). Yaourt is a wrapper for pacman and, furthermore, searches the AUR. It automates the build of binary packages from the source to such a degree that one needs to be quite observant to see the difference from a purely binary install 😉 .

[1] "portmaster -La"? "portmanager -su"? What about portupgrade? Of course, only one of these, but either one after "portsnap fetchupdate", and "portaudit -Fda". Of course. Naturally. )

Lenny ist da!

Note that Squeeze will initially not receive any security updates.

When installing Linux distribution XYZ these days, I usually get this "know that, been there" kind of feeling. It's depressing, but the fact remains that there's rarely an outstanding feature or characteristic. Comes with the age, I guess. 😒

If you know the feeling, and despise it, I have something for you which might be just the right antidepressant. 😉

ArchLinux. This distribution is different.

Listen to the current maintainer of ArchLinux, Aaron Griffin, who expresses the "Arch way" in a particularly eloquent and concise way:

If you try to hide the complexity of the system, you'll end up with a more complex system. Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding.

This is no marketing, no bullshit bingo. It's true. Downlad the 140 MB netinstall and see for yourself. I have never seen a textbased installation which is so very simple and really, truly, entirely transparent. In comparison, all other distributions look like Windows with regard to their transparency.

Technically, ArchLinux strongly leans to the *bsd side, in that it is configured by a central /etc/rc.conf, and foregoes the init system of system V (as also done by Slackware). Furthermore, Arch is a rolling release, meaning you don't have to worry about release dates and misburnt CDs. Instead, the package manager 'pacman' will both update and upgrade your system (with a simple pacman -Syu), and it is exceedingly fast in doing so. Since Arch keeps its packages very close to the originals, there are few patches and essentially no delays. Even without the 'testing' repository you'll always have current packages.

To give you an impression of the 'Arch way', here's the head of the central configuration file, /etc/rc.conf:

#
# /etc/rc.conf - Main Configuration for Arch Linux
#

# LOCALIZATION
#
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime"
# USEDIRECTISA: use direct I/O requests instead of /dev/rtc for hwclock
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
#
LOCALE="en_US.utf8"
HARDWARECLOCK="localtime"
USEDIRECTISA="no"
TIMEZONE="Europe/Berlin"
KEYMAP="de-latin1-nodeadkeys"
CONSOLEFONT="Lat2-Terminus16"
CONSOLEMAP=
USECOLOR="yes"

Unlike other distributions (and particularly those with an elitist touch 😉 ) Arch isn't ashamed at all to be explicit: it tells you exactly what to do, and where to find relevant information. You'll find the very same explicitness and clarity throughout Arch, starting with the installer, and not ending with the above central configuration file. In principle, once you're able to read, and to handle vi, you can't possibly fail with Arch. Just don't confuse it with Ark 😄

To conclude, here's the obligatory screenshot 😉 I thought xfce would fit Arch quite well.

A Javascript performance check which I will update in irregular intervals. Today's winner: Webkit. The loser: all the others, but particularly Opera. 😞

Native means: Mandriva Cooker x86_64 on a Core 2 Duo E6600. For comparison: FF 3.0.6 on my Mini (Ubuntu Intrepid on an Atom N270) needs 12474.6 ms to complete the test.

The performance of today's desktop computers is rarely, if ever, limited by raw CPU power or GFX speed. Instead, the bottleneck in most cases is the hard disk. Even if you own the latest quadcore CPU and 8 GB of RAM, your system will temporarily slow to a crawl once you try to, let's say, unpack a 4 GB 7z-archive on the disk which also holds your system. And, mind you, this will happen despite your state-of-the-art SAS RAID 0 capable of 175 MB/s serial read/write throughput.

An obvious hardware workaround consists of the use of two separate disks (or disk arrays), one dedicated to the system, the other for your data. As long as data are copied/packed/unpacked exclusively on the latter, the former is free to do whatever you want it to do (starting programs, for example). This strategy indeed frees your system from the worst lags. It does not help, of course, as soon as there is the need for massive I/O operations on your system disk such as as during the daily crontab runs at 4 am. 😏

A universal tool for dealing with this problem is ionice (the name comes from I/O nice, and is pronounced just like “ionize”). ionice allows you define the I/O priority of running processes only. That seems like an unfortunate restriction, but in fact, you can easily ionice an entire shell by issuing

ionice -c3 -p$$

with $$ being the pid of the current shell. Every command from that shell will now be ioniced. 😊

Now, unpacking the 4 GB 7z archive from above within an ioniced shell will not affect your system any more: it will silently proceed in the background without bothering you a bit. You'll be surprised by the silky smoothness of your system's reactions after ionicing it. 😉