The state of Linux

Desktop and Laptop Linux with the example of Mandriva Linux 2008.0

Site news

Latest site additions:

Updated January 13^rd 2008:
My LIRC page: The Linux Audio Server Project - Revisited

Added January 3^rd 2008:
My (K/X/)Ubuntu review: Ubuntu - beyond the hype

Added December 2^nd 2007:
My Mandriva 2008.0 review

Added November 20^th 2007:
The configuration page of Mandriva Linux 2008.0

Added November 18^th 2007:
The Installation walkthrough of Mandriva Linux 2008.0

Added November 17^th 2007:
The review of openSUSE 10.3

Added July 8^th 2007:
The Configuration page of Mandriva Linux 2007.1 Spring

Added July 1^st 2007:
The Installation walkthrough of Mandriva Linux 2007.1 Spring

Added December 18^th 2005:
The third and final part of my Mandriva Linux 2006 review

Added November 14^th 2005:
The second part of my Mandriva Linux 2006 review

Added November 6^th 2005:
The first part of my Mandriva Linux 2006 review

For older additions please see the articles page.

Review highlights

Return to top

This in-depth review discusses the state of Desktop and Laptop Linux with the example of Mandriva Linux.
Highlights of this review:

comparisons of the 64 bit versus the 32 bit versions, including benchmarks
battery considerations and benchmarking
comparisons with previous Mandriva Linux releases
misconceptions about Mandriva Linux
information about hardware compatibility, recommendations and configuration
information about software availability and configuration

Introduction

Return to top

The last Mandriva review I did dates back to 2005, it was about the 2006 release. Since then, things have been progressing nicely, although already then I had no major complaint. And now, 2007 is yet another year of the Linux desktop – at least at my place. 6th in a row. Indeed, I've not used any other OS on my computers in all that time. And it's yet another year of Linux on the laptop, 3rd in a row. The year 2008 is looking better and better to add up "one" to the years mentioned before. Vista is tempting, but not enough. I'm lying, it's not tempting at all...
OS X Leopard is tempting, but not enough. Well, it might be if it'd actually run on any of my hardware, and if I could try it out for free, as I can try any Linux distribution of any interest.
Do you have years of Linux at your place? Maybe you're an oldtimer, counting way further than I just did? Or perhaps you're still counting months, weeks, days? Perhaps it's not time yet for you to try out desktop or laptop Linux? Perhaps there are plenty of reasons to still not try out Linux. If you look hard enough, you'll always find some.
But then again, there are certainly plenty of reasons to go ahead and give Linux a try. You may just like what you find, and if you want to know what that might be: read on!

Enjoy,
aRTee

Please note: all screenshots are clickable, and they all have titles, which will show up when you position the mouse pointer over them.

Features of Mandriva Linux 2008.0

Here's a short list of highlights of the feature list of Mandriva Linux 2008.0 :

i586 and AMD64 versions available (powerpc not officially supported)
kernel 2.6.22.9
gcc 4.2.2
Software installation via vastly improved urpmi after setup with easyurpmi.zarb.org really great
drakwizards: Mandriva Control Center, with underlying tools: diskdrake, drakxservices, userdrake, drakTermServ, etcetc
Compiz-Fusion and Metisse 3D desktops
3D desktop wizard drak3d to easily enable Compiz-Fusion or Metisse
KDE 3.5.7
GNOME 2.20.0
X.Org 1.3.0.0
OpenOffice.org 2.2.1
Transfugdrake for easy migration from Windows to Linux
Easy wifi roaming, new unified network tool
Powerpack Edition: LinDVD - worldwide legal dvd playback out of the box
Powerpack Edition: Fluendo codecs, for broad media type support
great internationalisation - large choice of languages, with a nice configuration GUI: localedrake
the community around Mandriva Linux, friendly to new/inexperienced users (for instance mandrivausers.org)
an amazing amount of available packages/programs (~20GB of rpm packages!)

What's new and changed

Return to top

There are many changes under the hood, and quite a few jumping in the eye. There are updated versions of practically all software packages, and there's the addition of quite a few new packages and programs — Mandriva 2006 which was released in October 2005 had around 10GB of rpms in the 'main' and 'contrib' repositories, Mandriva 2008.0 has around 20GB of rpms in those repositories. Mandriva 2007.0 and 2007.1 Spring already had lots of rough edges polished and wrinkles ironed out. Perhaps some of this has to do with the added forces of the former Conectiva developers... Mandriva 2008.0 builds on top of 2007.0 and 2007.1 which were already excellent in many respects.
The first thing a user of the graphical tools will find is that Mandriva will do the configuration of the standard repositories (main, contrib, updates for each — all you need aside of the plf repositories), the user merely has to choose a mirror from the list. This feature was introduced in Mandriva 2007.1 Spring. If for whatever reason some repository configuration has been done, for instance through the command line (following the setup of easyurpmi.zarb.org), this setup proposal won't show up. So it may actually be that some experienced Mandriva users who already know that one has to hop by easyurpmi.zarb.org missed this point of improvement. One minor gripe I have with this automagical setup is that it uses only synthesis lists instead of the full sized lists – the download is significantly smaller (contrib: hdlist: ~50MB, synthesis.hdlist: <1MB), but there is much less information available (no descriptions, file lists nor changelogs available). Personally, I'd like to see an 'advanced' option for this automagical stuff; with my 10Mbit/s connection, 50MB instead of 1MB is not such a big deal anyway. Now that I'm reading from my wishlist, I'd like to have the option of having different mirrors in parallel, so that in case one is down or not fully sync-ed yet, the system can switch to the next.

As can also be seen from the screenshots, the software installer has been given a prominent place on the menu and it now offers the option to deinstall packages; this option has been requested for a long time instead of having to open up the deinstaller, and was first implemented in Mandriva Linux 2007.0 (fall 2006 release). The graphical tools for software management: repository setup and selection (enable/disable) and the graphical tool rpmdrake are very convenient and powerful.
Something you can't see from the screenshots is under the hood, one of the biggest and most welcome changes, namely: the speed improvement that was made in the software management tools. Starting up rpmdrake is much faster, and so is searching for strings in the descriptions or included file lists. Notable is that both my cpu-cores get taxed up to 70% and beyond (getting a speed boost up to their max of 1992MHz) — a relatively rare event to see programs using two cores instead of just one.

Another relatively big change is that since 2007.1 GRUB gets used as bootloader instead of LILO. This may mean that users who are multibooting and who've used only LILO before may have to read some man-, info or webpages to get their other systems going again. This brings me to the next point: one thing the system installer still doesn't do is add other Linux systems to the boot loader menu automatically (though if present, MSWindows is nicely added without any user input) — perhaps it's too much to ask, but how hard can it be to parse the LILO /etc/lilo.conf or GRUB's /boot/grub/menu.lst files of remaining or older system partitions and either add their entries, or at least propose to the user to select which of their entries to add?
Other distributions can manage that, why not Mandriva?

One big difference when using grub instead of lilo is that upon wakeup from suspend to disk, the bootloader menu is skipped and the system goes on with resuming. This behaviour can be changed if so desired, but it does make sense.

On the software repository front, there have been some major changes (also since 2007.1 Spring), leading to a few more repositories but all in all I must say the changes are for the better — much better. Now there are clearly named repositories; for instance for the main repository, there now is: main/release, main/updates, and main/backports. For those with a penchant for 'newer is better' there's even main/testing and contrib/testing, but personally I stay away from those.

[Update! Tuesday, December 4^th] Adam Williamson of Mandriva contacted me that I have the above wrong: the testing repositories are testing of updated packages before moving them into the updates repositories, and the backports repositories are the more 'dangerous' kind for those living on the edge. Well, Adam didn't say exactly that, just that I have those two mixed up. Apologies. When writing 15k words, some are bound to be wrong.
[/update]

There are the same repositories for contrib, and then there are the (again, since 2007.1 new and publicly available) non-free repositories (again in standard */release, */updates, */testing and */backports versions), which contain lots of proprietary drivers that are not available on the Free Edition (nvidia, ati, java, the intel wifi daemon ipw3945d that my system needs, and lots more), but that are included in the KDE One live cd. Kudos to Mandriva to make all those packages available to everyone!
Some other software that is available to clubmembers and on the Powerpack DVD is available from the vendors: acrobat reader, flashplayer, skype and opera can be had from Adobe, Skype and Opera respectively. Note that the PLF 32 bit i586 repository actually also offers Opera, so it's actually available through the software installer if you add the i586 plf-nonfree repository.

For those of you who have past experience with KDE on Mandriva, you'll be happy to know that KAT is absolutely gone, and replaced with Kerry Beagle, the KDE version of GNOME's Beagle, the Linux desktop search implementation. I must say that at the time, KAT gave me so many problems that I just had to deinstall it, no way to make it behave. And I know I'm not the only one by far. With Kerry Beagle, the Mandriva KDE desktop now has a well functioning search engine that doesn't hog the system resources and just does what it should do, and does it well: help the user find his files. That being said, I don't actually use it, since I'm quite well organised (at least, on my computer) so I know where I keep what. And if I don't know the location of some file, it's usually some system files of which I know the name (partially - through manual / web / info pages, forums or whatnot), so I would just run a find or locate – which brings me to another change: slocate was recently replaced with mlocate. Now that I mention that, I'm not sure if anyone reading this would care or even know what this is about. If the previous comment is over your head, please don't worry, it won't happen again, I promise...

In the looks department, Mandriva has been improved substantially compared to previous versions; for instance, the installer boot screen (that gradual fading in of the Mandriva name and logo is really good looking), the system installation part showing the package installation has been updated to show the package list being installed, instead of showing only each single package (this was already present in 2007.0), and one of the nicest visual improvements of the specific Mandriva things is shown when suspending to disk, with a nice 'Mandriva star sundown' screen (no idea why this isn't shown at resume though - something to improve still). I also love the new default backgrounds for the Free and Powerpack edition. You may not care for looks, but some do, and it's better to have a great system that also looks great than a great system that makes you want to poke your eyes out.
Speaking of suspend, Mandriva 2008.0 actually does suspend to ram and disk out of the box for all the laptops I threw it at; for 2007.0 I still had to add a boot option for suspend to ram to work properly. Naturally this improvement is courtesy of the kernel (perhaps with specific patches added by Mandriva developers) so this should be seen all around in all recent distributions, but progress is progress and Linux is making plenty.

Back to talking about the installer, the options at the installer boot screen have been improved. Sadly, the default boot device has been reverted back to the installer, not the hard drive (which was the default boot device in 2007.1). Since the installation dvd also holds lots of software packages and may have to be inserted for software installation — and consequently forgotten, this default cd/dvd drive system boot option really causes lots of annoyance for people who just want to quickly boot their machine, looked the other way during boot screens, and suddenly find themselves confronted with the system installer...
Mandriva 2007.1 actually had this part right, I have no idea why this was changed back in 2008.0.

Like Mandriva 2007.0 (fall of 2006 release), Mandriva 2008.0 actually offers worldwide legal dvd movie playback out of the box — that is, in the Powerpack edition. The program used for that is Lindvd, the Linux version of Windvd by Intervideo. When I tried it out under 2007.0, I was a bit upset since it actually automagically set the zone of my old laptop dvd drive (which had no zone set, it always played fine under Linux) and on top of that it stopped playing after 10 minutes!
I later found out that that was not intentional, it was not a trial version, and the fix was in the release notes. But since it was really adhering to the standards, I suddenly found myself confronted with FBI warnings and other intro messages of dvds — something I had been spared from by xine, mplayer and vlc with libdvdcss. So I reverted back to that, now also with my new laptop running Mandriva 2008.0. I did have a go at it on my desktop system, since both my Pioneer dvd rom drive and my NEC DVD burner are flashed with RPC1 firmwares and will not be affected by any software attempt to set the region code. It's not half bad, but I didn't feel in the mood to see if I could hack things up to work properly with LIRC, and mplayer and xine fulfill all my needs and wishes in terms of video playback. But it must be said: if use of libdvdcss is illegal in your neck of the woods and you care enough, your system of choice is Mandriva.

Aside all this, there are many small changes all over, such as bash using a different formatting for the date output when doing ls -l. Or such as the option to use UUID for device detection. I actually use this on my laptop.
There's also a new feature in konqueror as file browser: the metabar, which shows information, 'open with' options and more, for the current directory or selected file.

On my laptop, I used to have issues when connecting the battery (I usually work with the laptop plugged in, and it's supposedly better for the battery to be disconnected and even in the fridge...) with kpowersave, which would crash. Since Mandriva 2008 it doesn't anymore, and the related tools will get the correct info about the battery status.

The KDE menu / start button can now be easily changed and the type of menu (standard or kickoff style) can also be selected, by right clicking the start button. (As you can see below, there are some slight visual problems when switching, but otherwise this works fine.) Supposedly the kickoff style menu is based on research into human - computer interaction, and should be much more user (or perhaps: beginner) friendly. I rarely use the menu, I start most applications from the command line, but for new users this could be a big plus. My guess is that for people used to the classic menu type, this kickoff menu will most likely need getting accustomed to during the first few days, to the point where it may not make it past those few days. Remember, the change back to the classic menu is only one mouseclick away.

Misconceptions about Mandriva Linux

Return to top

It sometimes amazes me how much misinformation is spread about various distributions, Mandriva being one of the favourite targets at times, not by opponents of Linux, but by users (zealots?) of other distributions. It seems like Linux doesn't need Microsoft for an opponent, there are plenty of enemies in Linux' own camps!
Of all the reasons that people bring forward to not use Mandriva, the following untrue reasons are often at the top of the list, and if you ask me, they most likely signal a zealot FUD-master troll:

UNTRUE: "Mandriva Linux is not really free, you have to become a clubmember, which costs!"
UNTRUE: "with Mandriva Linux you have to pay for updates!"
UNTRUE: "with Mandriva there is no easy way to add proprietary stuff like drivers for graphics cards!"
UNTRUE: "rpm-package based systems open up a world of dependency issues and lead to dependency hell!"
UNTRUE: "you have to be a club member to use the Mandriva forums!"
UNTRUE: "Mandriva Linux isn't really Free, they close up and hide their stuff!"

I use the Free and Powerpack editions on and off. For 2008.0 I'm using the Powerpack, but for 2007.1 Spring I used and wrote instructions for the Free edition - practically all has remained the same from 2007.1 to 2008.0 in terms of configuration and setup of the Free edition. Read my installation page and my configuration page of Mandriva 2007.1 to see how I use the free and publicly downloadable Free Edition DVD of Mandriva to come to a full fledged fully usable Linux system. As the update repositories (for the built-in update system) and non-free repositories (for proprietary drivers and such) are freely and publicly available, there's no reason to pay for any updating, and I can indeed confirm the updater works fine for the Free Edition, nor is there any reason to pay for easy access to proprietary drivers, since they will all show up in the software installer and are readily available. So this settles the first three 'arguments' of the above list.

As for the claim that rpm-package based systems will lead to dependency hell — this has been untrue since the inception of urpmi somewhere in the last millenium (and comparable tools: yum for Redhat/Fedora, Yast for SUSE, smart for several) and with the requirement that the packages are properly built (with proper dependency information). The exact same is true for the apt-get system of Debian and all Debian based distributions such as (K/Edu/X)Ubuntu, if a package has wrong dependency information, you may be in for a rough ride, but this is not the fault of the rpm or deb system, merely of that particular broken package.
People who are so convinced that it's the rpm packages that make 'dependency hell' a sure thing just don't understand how things work. Often they are speaking from experience from a long long time ago (there were more 'badly wrapped' rpm packages at some point in history), or they speak from recent experience where they did not follow the rules, i.e. installing SUSE rpms on Mandriva or Fedora, or packages for a newer version onto an older system, without updating their setup accordingly.
I'm quite sure I can wreck any system with dependency resolution, just force some wrong things down its throat, and voila! instant dependency hell. That this would happen automatically with any rpm based system is ridiculous. Beware of FUD and zealots!

As for the Mandriva Club Forums, the useful sections were always publicly accessible, searchable and 'postable'; parts that were not open to the public were about clubmember wishes and such, no big deal to keep that closed if you ask me. Now the whole Mandriva setup has changed, the forums are fully open to the public.

As for the claim that Mandriva Linux is not really Free, and things are closed up and hidden: nothing shows signs of any kind of proof of this, and all Mandriva's tools (drake wizards and non-graphical tools such as the urpmi family) are GPL code. Development is open, with bug reporting tools and mailing lists publicly accessible. Yeah, I know, security bugs/reports are not all publicly accessible, but that's all in line with proper security processes.
Aside that, Mandriva sponsors and has sponsored various gpl projects, such as Frozen-Bubble (now with multiplayer online gameplay!) and K3B; more recently they have hired the lead developer of K3B, Sebastian Trüg.

I'm sure if one searches hard enough one might find plenty of things about Mandriva that could be used as an argument against using Mandriva Linux and against recommending Mandriva Linux to others, but as I hope I've shown in this section, the above arguments are wrong and highly worthy of the FUD label.

And for those in doubt: no, I'm not paid by Mandriva, and no, I don't own any Mandriva shares. But I just really wanted to clear that up.

Harware used for testing and hardware issues

Return to top

I've done most of the testing on my own laptop, though branded completely differently in fact an MSI Megabook S262. It has an Intel Core 2 Duo T7200 cpu, Intel Integrated graphics (GMA950, 945gm) and Intel IPW3945 802.11 a, b & g WLAN for wireless ethernet connectivity. It's a 12 inch machine, with a 1280x800 screen, four special (semi-)programmable buttons (alongside the on/off button); one of these toggles the wifi and bluetooth radios on and off (it cycles through the following combinations: wlan off, bt off; wlan on, bt off; wlan off, bt on; wlan on, bt on). There's a SD/MMC/MS card reader built in, a dvd+/-rw burner, three USB2.0 hispeed ports, a VGA port, firewire, gigabit ethernet, analog modem, audio headphone and mic connectors (no onboard mic, onboard speakers hardly worth mentioning — but for a 12 inch acceptable). It has a two-hardware button touch pad which has a scroll zone on the right (not marked, it took me some time to figure out it could let me scroll like that) and next to left click it also detects middle click, if tapped with two fingers at once — very nice due to the missing middle 'mouse' button, and it took me some more time to figure that out. It actually sends a right click event if tapped with three fingers — that took me even more time to figure out. You can read how I got this machine going with the Mandriva 2008.0 Powerpack or the Mandriva 2007.1 Free release on my configuration pages — the Powerpack naturally didn't need half as much configuration due to all drivers being present.
Oh, BTW, this laptop was preinstalled with SUSE Linux and Novell Linux certified hardware, and as a cherry on the cream on the icing on the cake, the exact same version with Windows was about 200USD more expensive.

For plenty of things, the Mandriva draktools (wizards) can be used, in some cases they start up automatically, such as printerdrake when I connected my printer. In other cases, one has to use the Mandriva Control Center to get to the desired tool, in the examples below the setup for nfs exports and the definition of hosts.

I did use some other hardware for the testing: most notably my desktop system, zurich, an Athlon 2400+ 2GHz 32 bit system with Nvidia and ATI graphics, a WinTV-FM tv card with the most useful accessory: an IR control.
All in all, on all machines all basic and most not so basic functionality worked out of the box: graphics, sound, wifi, you name it. Some not absolutely essential devices did not.

As for (Mandriva) Linux hardware support and hardware issues on my own laptop, I haven't tested the analog modem and the cardreader doesn't work with Memory Sticks. It actually first started working with Mandriva 2008.0; with 2007.0 and 2007.1 it didn't do anything, there wasn't even a kernel message. With 2008.0 it started working with both MMC and SD cards; I have had to borrow MS cards to test that functionality and found it didn't work. Since the hardware is directly accessible, contrary to an externally connected USB card reader, it should be possible to use it with SD-HC cards as well, something that Windows users of this laptop will not likely get, who'd backport the driver for them... Some points for Linux here, if all works out. I haven't tested that yet due to a lack of sdhc cards.

The external monitor connection works nicely now; with 2007.0 the whole machine would hang if I hit Fn+F2 (the keystroke to switch to external monitor). Nasty, but if you think such simple keystrokes should not just stop or restart (freeze or crash) a running Linux system, try hitting alt+sysrq+b or alt+sysrq+h. Found your way back here? Hope you did save before rebooting...
So I decided not to hit Fn+F2, until, of course, I had an other system to try it on, which was 2007.1. There the screen would get severely garbled when hitting Fn+F2 if there was no external monitor connected. Hitting it again would result in a hang (or, it did the one time I tried), but switching to console with ctrl-alt-F1 and back with alt-F7 would get me back to normal graphics mode. In case an external monitor is connected, the desktop would show up there as a copy of the laptop screen without issue.
Now with Mandriva 2008.0 there's also a new driver for Intel Integrated Graphics which I already tried with 2007.1, it was still experimental then. It worked better with an external monitor, but other than that I did't think it was worth the hassle of setting it up. That driver is now standard, and it works fine on my laptop in Mandriva 2008.0. I can connect an external monitor and instantly the external vga connector will be enabled and the monitor will show an image. The krandrtray tool has been improved to work with this functionality, and one can for instance independently set the resolutions of the laptop screen and the external monitor - of course within the capabilities of the onboard graphics adapter. On my laptop at least, this can not be used for a dual monitor setup (it's not capable of that at all).

The other issue that may be hardware related is my Wifi connection. It uses a proprietary daemon, which is the only closed source code related to my hardware. The only other closed source / non-Free programs being flashplayer (yeah, I'm counting Java as open already, although I got it from the non-free repository) and Majesty (my only closed source game).
There are two problems with the Wifi. The first is that the connection is not too stable; this may have to do a lot with the channel and disturbances by other networks. I recently switched to a different channel and the connection doesn't drop as much anymore. The second is that it's so promiscuous, it just keeps connecting to my neighbours fully open AP (aptly named ConnectionPoint) which is a beast of a device since I practically have to sit on my own AP to have a stronger signal. So it can take a few tries and some temporary repositioning to connect to my own WLAN...
I did try the new fully open source driver iwl3945 (different firmware, different driver and no daemon anymore — if you don't consider firmware to be software, which is how I see things, this is a fully open source software solution), but it wouldn't work after suspends, no matter what I tried, so I'll just keep using the default ipw3945 for now. I'm quite sure in the near future iwl3945 will start working.

IA32 / i586 32 bit vs AMD64 x86-64 bit

Return to top

In many cases, Linux hardware support is 'community developed' and only fully functional some time after market entry of the particular hardware. For AMD64 based systems this was different, Linux is one of the few systems that really supports the AMD 64 bit processors (AMD64, also known as x86-64 (generic name) and EM64T (Intel denomination and implementation, they apparently couldn't bear calling it anything with AMD in the name).
Moreover, in discussions about Linux versus Windows, the sometimes lacking and / or lagging hardware support is always used as a big argument in the favour of Windows. So now for once, Linux is ahead of Windows XP 64 bit, and the difference is supposedly even bigger comparing Linux to Vista 64 bit,... it may well be that of all hardware in the shops today, even when only looking at 32 bit operating system and drivers, Linux supports as much hardware as does Vista. Comparing 'older' hardware (a scanner that was fine about 3 years ago is likely still fine and up to its job today) in terms of Linux support versus Vista compatibility is like taking candy from a baby — just too darn easy. This follows quite naturally from the logic of business versus community: it's bad business to extend the usefulness of a sold piece of hardware if that means a 'lost sale', and for the community, it's added value to have the most hardware supported, which in the case of open source drivers doesn't exactly require special magic.

Back to the 64 bit AMD64 versus the 32 bit IA32 (i586, x86-32 or whatnot) discussion, here it's often argued that the difference isn't so big, so it shouldn't be dramatised if, due to hardware or software compatibility reasons, people have to run the 32 bit operating system and/or software. Naturally this argument is used by Windows users, since they're the ones 'stuck' with the old system on the new and more capable hardware, but also Linux users sometimes claim that it's not worth the hassle.
But instead of choosing sides just like that, I decided to figure things out for myself.

In exploring the differences between using a 64 bit (AMD64) Linux versus a 32 bit (i586) Linux, I decided I had to look at various aspects of interest. Naturally, the main point is performance. But other things might also be different, such as how long the system can run on batteries, how much diskspace is required, how much effort it takes to use and maintain a 64 bit system versus a 32 bit system.

Luckily, it's not too hard to compare AMD64 to i586. The great thing about AMD64 is the full backwards compatibility with 32 bit code, the only 'must' being that to run 64 code one has to be running a 64 bit operating system, which in turn needs 64 bit drivers. Knowing this, I used the command chroot to run 32 bit binaries and libraries under the 64 bit system, what I call 'hybrid system' below. Other than that, I ran native 64 bit code under the 64 bit Free Edition and 32 bit code under the 32 bit Powerpack installation that I have. Note that all benchmarks in this section were all run with Mandriva 2007.1 Sping.

For the hybrid 64 bit system setup with access to both 64 bit and 32 bit programs, one just needs to set up all repositories twice: both for 64 bit (x86-64) and 32 bit (i586). In case a 32 bit program is required, it can be installed as usual. This may require a bit of configuring in the software management GUI. So the total effort is twice that of a regular system when it comes to software repository configuration.
The libraries that are required will be installed as well, but since some libraries are needed in 64 bit form by some 64 bit binary, and in 32 bit form by some other binary, there's a /usr/lib64 directory for 64 bit libs and a /usr/lib for 32 bit libs. This means a bit more disk space is required in the case of a hybrid or even 'pure' 64 bit system - some libs and programs just come in 32 bit version only. I compared and found my 64 bit system having 1.1GB in the /usr/lib directory and 1.1GB in the /usr/lib64 directory. The 32 bit system had 1.9GB in its /usr/lib directory, with practically the same things installed. No big difference with the minimum disk size being at least 40GB (laptops) or 120GB (desktops) since a year or 2, so we can strike disk space requirements as a factor of interest in our 64-32 bit comparison.

For the following audio benchmarks, I used the 24 bit remastered 24kt gold plated UltraDisc version of Pink Floyds 'Dark Side of the Moon', track 4: Time... The motto here is, if you do benchmarks, there's no need to do them with inferior material (as in: crap pop, I'd take a home made audio cassette of this track if I had no other).
The wave file was compressed to mp3 using lame, to ogg vorbis using oggenc and to flac using flac. With all of these I used the command 'time' (how appropriate) to determine the score. I took the best score out of 5 runs (thereby making sure the harddrive was out of the question, the data was loaded already) and noted the user time in the following table. The last column shows the ratio of the time required by the pure 32 bit system divided by the time required by the 64 bit system.

Linux AMD64 vs i586 audio encoding benchmarks, time in seconds
	pure 32 bit system	64/32 bit hybrid system	pure 64 bit system	32bit time / 64 bit time
MP3 Lame	33.36	32.99	31.06	1.074
Ogg Vorbis	26.30	26.14	17.80	1.477
FLAC	5.02	5.05	6.53	0.768

Similar benchmarks were done on a 1.6GHz AMD Turion system (MSI s273 notebook, if I recall correctly) - thanks to my friend Alessandro d'Amato who was kind enough to run these benchmarks for this review. He used a musical piece by Tchaikovski of over 17 minutes for these audio benchmarks, on a 64 bit system with 64 bit and 32 bit binaries. The last column shows the ratio of the time required by the hybrid 64 / 32 bit system divided by the time required by the 64 bit system.

Linux AMD64 vs i586 audio encoding benchmarks, time in seconds
	64/32 bit hybrid system	pure 64 bit system	hybrid time / 64 bit time
MP3 Lame	109.17	108.01	1.011
Ogg Vorbis	78.63	55.10	1.427
FLAC	13.12	16.78	0.781

Some notes and comments, mostly referring to benchmarks on my own Core 2 Duo laptop: all runs showed only one cpu core being used.
I have no clue why pure 64 systems take longer for flac.
The three ogg compressed files were all different (on a binary level, not that I could tell from listening, but with the command 'diff' computers can tell such things) for the pure 64, pure32 and hybrid systems. For both flac and mp3 compressed files, the hybrid and pure 32 bit system had the exact same result, differing from the pure 64 bit system results. The flac files decoded back to .wav however were binary equal to the original, as they should be to qualify as fully lossless. In all cases, the 32 bit and hybrid system resulting files had the exact same size.
What this really means or why this is, don't ask me. I'm just the messenger.

From the above numbers, it's clear that for ogg and mp3 lame encoding the 64 bit system has the upper hand, for ogg quite strikingly so, with more than a 30% faster run. For lame mp3 encoding it looks like it's closer on the AMD system, in either case nothing to lose sleep about.

To do some more system taxing operations, I ran some video compression tests, using mencoder combined with the time command on some of my camcorder (SONY HDR-SR1 – from the evil rootkit CD company, but it runs Linux..!) mpeg2 files. The real time duration of the Video sample 1, 2 and 3 is 29s, 79s and 177s respectively. The last column shows the ratio of the time required by the pure 32 bit system divided by the time required by the 64 bit system.

Linux AMD64 vs I586 video encoding benchmarks, time in seconds
	pure 32 bit system	64/32 bit hybrid system	pure 64 bit system	32 bit time / 64 bit time
Video sample 1	12.54	13.33	11.84	1.059
Video sample 2	36.06	37.48	32.37	1.114
Video sample 3	76.38	74.80	63.78	1.198

Some notes and comments: again all runs showed only one cpu core being used.
As with flac and mp3 compressed files, the hybrid and pure 32 bit system had the exact same result, differing from the pure 64 bit system results.

So for these video encoding benchmark the 64 bit system is a clear winner, with more than 15% faster performance.

Now what should you make of these numbers? Well, there are some considerations to be made.
First, if 'high power' tasks are performed in less time, the total time the cpu runs at top speed is reduced, which will extend battery life or power consumption, and have your laptop run less hot.
Second, in my case, if today I'd wanted a faster cpu I could spend ~300USD more for the T7400 instead of the T7200 which I now have, for some 10 to 15% faster system. In other words, those running a T7400 with 32 bit system get the same performance (for some high power tasks) that I get with my 300$ cheaper T7200. Nice savings. From yet another angle, I didn't have the option of the T7400 at the time of purchase, it wasn't available yet - what if you've got the top of the line cpu and you want faster faster faster? That's right! Sixty four bit Linux!
And, for those tasks you have your system do often, you could actually figure out if the 32 bit or 64 bit program is faster, and create a hybrid system that's completely optimised!

In other words, 64 bit Linux systems go to eleven.

If you should care is totally up to you. Just reread the above and figure out if it matters to you.

Battery benchmarking

Return to top

Since I just had a look at the execution speed of certain processes comparing 64 bit versus 32 bit systems, I thought I'd have a quick look at what the cost is of running highly demanding jobs on a laptop. Note that it's not easy to determine the power usage of a desktop, and there's no urge to be able to shutdown or suspend before the battery runs out, but the results should not be so different for desktop CPUs that make use of the same power saving features as laptop CPUs.

Note: all numbers/benchmarks in this section are from my Mandriva 2008.0 64 bit installation. As I mentioned, cpu throttling/scaling worked fine out of the box, and I just had to do some tricks to get the CPU cores to run at their selectable clock speeds: 996, 1328, 1660 and 1992 MHz.

The first thing to look at, since Linux has apparently come to the point where both Suspend to Disk and Suspend to RAM function out of the box, is when which makes more sense. The time to Suspend to Disk and wake up is much bigger — a minute or two versus half a minute for Suspend to RAM. On the other hand, with Suspend to Disk the battery is not taxed any further, so you do not have to worry that the system will run out before it's properly woken up again — which would not be good (worst case: loss of data). To have a look at how much energie Suspend to Disk and Suspend to RAM cost, I looked at /proc/acpi/battery/BAT1/state, focusing on the value at remaining capacity. (To those who would like to do this easy experiment for themselves, I ran: while [ 1 ] ; do date >> [filename] ; cat /proc/acpi/battery/BAT1/state | grep -A 1 rate >> [filename] ; done and then did Suspend to Disk and Suspend to RAM).
For Suspend to RAM to do a suspend and subsequent wake-up, the value for the remaining capacity went from 944 to 920 mAh, for a sleep period of exactly 30 minutes, rounded that is 25 mAh. For a Suspend to RAM with immediate wake-up, the command I used only shows a 10 second gap in activity, and the remaining capacity went from 887 to 884 mAh: a grand total of 3 mAh to do a Suspend to RAM with wake-up. That means that half an hour sleep costs 22 mAh. For Suspend to Disk, to do a suspend and subsequent wake-up, the value for the remaining capacity went from 844 mAh to 814 mAh, for a total difference of 40 mAh. Naturally, in the case of Suspend to Disk, it's irrelevant how long the system sleeps. Putting a and b together, the following can be said: if you're going to suspend for a duration shorter than (40 - 3 / 22 * 30 = ) 50 minutes (say, changing trains or so), you'll get better battery lifetime if you do a Suspend to RAM, and for longer suspend durations, it's better to choose Suspend to Disk.

On with things, there are more considerations to be done. For instance, from the above numbers it can be deduced that a Suspend to Disk without wake-up probably costs around 20 mAh (supposing suspending and waking up takes equal amounts of energy; I think waking up probably takes a bit more, for instance due to the BIOS taking some time to start the system). So if your battery has 10 mAh left (say, you ignored some alarms and such), you have lots of programs open, and you're not too far from a power source, your best bet may be to Suspend to RAM, which will cost 1.5 mAh (or in any case less than 3 mAh) and which will leave you 8.5 mAh in sleep/standby mode, which should be around 11 and a half minutes (or at least 7 mAh or 9 minutes 30 seconds) to get your laptop plugged in. Suspend to Disk in this admittedly constructed situation would not be successful at all (half the required power is missing), and leave you with a corrupted suspend image. Or, you can say that with a 2200 mAh battery it is not very wise to set the Suspend to Disk level at 1% because it may just not be enough, whereas 3% should cut it with some margin.

On to the benchmarks. The following table shows the current rate with practically no load (both CPU cores were around 1%), just stepping from the lowest to the highest frequency (by messing with /sys/devices/system/cpu/cpu0/cpufreq/scaling_{max,min}_freq).

Unloaded system
Frequency of both CPU cores (MHz)	'normalised' frequency	current rate in mA	normalised consumption
996	3	1189	1.00
1328	4	1269	1.07
1660	5	1358	1.14
1992	6	1505	1.27

The following table shows the same, but now with 100% load (both CPU cores, doing a simple: while [ 1 ] ; do echo hello world ; done).

Loaded system
Frequency of both CPU cores (MHz)	'normalised' frequency	current rate in mA	normalised consumption
996	3	1551	1.00
1328	4	1835	1.18
1660	5	2194	1.41
1992	6	2704	1.74

Taking into account the battery capacity is rated at 2200 mAh, and assuming it can really deliver that, this laptop should be able to run around 1 hour 50 minutes if you just type some stuff, but if with the system continuously loaded to the max and in dynamic mode (where the cpu frequency will scale up to offer better performance), it will be empty in about 45 minutes - just over a third of the maximum time you might get out of the battery. Even if you're in powersave mode, and the CPU cores stay at 996 MHz, the battery lifetime just got shorter by almost 20 minutes.
Now, I know not everyone has a gkrellm open at all times, but I actually do, and I track what goes on on my system. So I can tell you for a fact that once, I opened a PDF from a webpage in Firefox, embedded in Acrobat reader, and after closing the pdf / acrobat reader, the CPU load went up to 100% and stayed there!
Well, until I killed the acroread process, that is. I just tried this again, and at the second (2 page ~80 kB) pdf document (at this page the pdf link is in the middle of the page) I opened and closed, this happened again...
Flash is known to also do this at times... Wonder if this is related to Adobe developers' Linux skills or if this also happens with their programs on other platforms...

What else does this teach us? Well, since the power consumption at maximum frequency and maximum load is not twice the power consumption at minimum frequency, and assuming that at twice the frequency the processing power is also doubled, it may actually be better for battery life to set the frequency policy to dynamic! And for your time as well! That is, in case you are really using the maximum power (compressing wav/flac files to ogg vorbis, mpeg2 to xvid, or some such encoding), and it's not some silly program needlessly sucking up all CPU cycles.

In relation with the previous section about the performance of AMD64 versus IA32 systems, it's clear that the faster system will have the better battery life - the faster system will finish the job faster and go into idle mode earlier. In many cases that will be the 64 bit OS.

There's more using power in a laptop than just the CPU(s), one of the major energy consumers is the display. I have had a look at the power consumption at lowest load, changing the display brightness in the 8 steps (or 9 levels, as you will) that this laptop has. The current rate went up from 1190 mA to 1524 mA, almost 30% higher, and thus a 30% shorter battery lifetime. With the lid closed, the current consumption actually drops to 1040 mA, and I'm not sure the display is completely off (the backlight is, but the LCD panel itself not necessarily), but this means at full brightness, the screen alone is responsible for (at least!) around one third of the power consumption. I wonder if a 15" or 17" screen take more power in relation to their size (same brightness output per square meter?) compared to my 12" panel... I would tend to think so.

Another considerable energy consumer is the graphics card or chip. In my case, I did some playing around with Compiz-Fusion and noted that with the cube spinning at maximum speed, or the shift-switcher activated, the current consumption went up from around 1300 mA to above 1600 mA. It's true that the use of Compiz-Fusion doesn't make the system any slower — my CPU cores are not taxed much: during shift-switching they go up to 6 or 7%, at the lowest clock frequency, rotating the cube as fast as it will go has them going up to 12% or so, so Compiz-Fusion certainly has no effect on the system speed in terms of user experience. But at the same time, there is an influence on the power consumption that is clearly non-negligible. Note that this extra power consumption is only there when the graphical effects activated; without special effects going on, the power consumption is the same as with kwin.

Next, let's have a look at the energy usage when the wifi is off, on but not doing anything, and active. To make it active, I mount an nfs share and run an md5sum on a large file (ubuntu iso image that I happen to have handy...). (The speed is around 2.8 MB/s, funny that these supposed 54 Mbit/s links are considered so nice, it's hardly better than 10 Mb/s ethernet.) The system uses respectively 1214, 1260 and 1360 mA. So turning off wifi can save another ~40 mA, whereas using it heavily costs an extra 100 mA, less than 10% of the total power consumption when the system is idling (as in, the user is web/text editing in Quanta Plus or so).

A very minor consumer is an optical mouse, I hardly see a difference in all the fluctuation of the current rate, but if I had to put a number to it, I'd say connecting an optical mouse to my laptop raises the current consumption by perhaps 10 mA.
A much bigger comsumer is the harddrive, doing an read of an iso (reading it into /dev/null) raised the current rate about 150 mA, not as much as I would have expected, considering the sustained 30 MB/s the drive managed.

Lastly, to have a look at the powerconsumption of media playback, first audio (with Amarok), which will trigger continuous disk activity (assuming the audio file that is played back is stored on your harddrive) and have the audio subsystem active. This draws around 20 to 50 mA of extra current. Playing back an xvid or mpeg2 file (with mplayer) takes about 100 mA of extra current if played in a window, around 150 mA if played fullscreen.

Naturally, these power consumption figures are related to my exact hardware, but in this section I have shown the methods to determine what's what in terms of battery life and you can now figure out for yourself what strategy you'll want to follow in dire times. (For the technically inclined nitpickers among you: note also that the current numbers have only a relative meaning - the battery voltage gradually drops when discharging, so the output power is less for the same output current when further discharged. In all the above comparisons of numbers, the numbers were taken closely after eachother, so the influence of the battery voltage drop is not relevant.)

If you don't care at all, that's fine with me. Some want to know what goes on under the hood, and with Linux you have easy tools to do so. Some just want to drive (not crash), and others want to make sure they get the best mileage.

Oh, and 64 bit Linux systems go to eleven also in the battery life department.

Some hardware recommendations

Return to top

I have some hardware recommendations for those facing a purchase decision, or even advising others with their purchase decision. But maybe more importantly, I have some words on freedom and independence and the point of having it in the hardware domain.

First of all, what hardware you should buy depends entirely what you want to do with it. In case you want to have the best Linux compatibility and/or you value your digital freedom and independence, you may want to focus on hardware with open source Linux drivers — if possible with drivers that are in the mainline kernel. For many types of hardware this is the case (chipsets, ide and sata controllers, even bluetooth devices), but especially graphics cards and wireless adaptors can be less than perfectly troublefree. As long as you can live with somewhat slower 3d graphics, I can currently only recommend the Intel Integrated Graphics to you - they have fully open source drivers, and therefor any (recent) Linux you throw at them should give you 3d accelleration out of the box, hassle free.
When I state 'slower graphics' it doesn't mean dead slow - on my Intel GMA950 chipset with the 945G graphics engine I have no problem running Compiz-Fusion with loads of plugins (cube, dynamic skydome, zoom, even silly things like water). Running 3d games like Glest and 3d applications such as Stellarium, Celestia and Google Earth is no problem at all. I must admit that for fullscreen 3d applications I prefer to turn off Compiz-Fusion (via the follow-up of beryl-manager called fusion-icon, if you can compile it — due to quality and compatibility issues it's not been made available by Mandriva packagers — or from the command line: kwin --replace).

If you want to go the really easy path, you should just order a preinstalled machine, for instance from Dell or soon also Lenovo (formerly IBM). They are making sure that the hardware has good Linux compatibility, and from the reports I've seen so far, it looks like Dell are doing things the 'Free Software way'. With that I mean to say that they are pushing hardware makers to make Open Source / Free Software drivers possible, and they choose hardware with Open Source / Free Software drivers. I'm not sure which path Lenovo will be going, but I hope they will do the same thing.

As I mentioned before, I actually did go this easier path, I bought my MSI s262 laptop with SUSE Linux preinstalled (and certified Linux compatible by Novell); the same hardware with Windows XP Pro would have set me back around 200US$ more. I was informed that the only part of this laptop that wouldn't work with Linux was the card reader, and that for the wifi (ipw3945 802.11 a/b/g) a proprietary daemon is required. Wel, the card reader started working with Mandriva 2008.0, and the proprietary daemon is on its way out. Otherwise, this laptop is a dream machine, and it should be possible to work well with practically any Linux distribution I might like to throw at it.
So I can hardly stress the point of convenience enough: buy Linux compatible hardware, buy hardware with Open Source / Free Software drivers, buy Intel integrated graphics, buy preinstalled if you can. This is really the only option for those who value their freedom.

So now that I'm mentioning freedom, after mentioning Open Source / Free Software drivers, I'd like to explain the reasoning behind wanting it.

I already mentioned the point of convenience with hardware for which there exist Open Source / Free Software drivers: it normally works with any Linux distribution, if all goes well out of the box.
In short: Free Software drivers offer an unparallelled level of convenience.