Latest Toy: The Orange Pi PC

You may have heard about the latest Raspberry Pi 2 clone: The Orange Pi PC, a device that sells for only $15 yet comes with a quad-core Allwinner H3 and 1 GB RAM. (But don't be fooled - while "open source" is mentioned everywhere on that website, the actual open source situation is still pretty bad).

After my Raspberry Pi started acting up and run very unstable a year ago, this looked like a nice replacement. Thus I decided to order the "Orange Pi PC set 3" including a plastic case and power cable from AliExpress, and will try to get Gentoo running on that device. The manufacturer's Gentoo forum section is all crickets, so I expect to encounter at least some problems.

If you want to see this thing in action, or at least watch me struggling to get Gentoo running, come next weekend (10+11 October 2015) to the Prague Linux Days and visit the Gentoo booth.

Which should be the default in Gentoo, ffmpeg or libav?

There has recently been a discussion among developers about the default choice of ffmpeg/libav in Gentoo. Until recently, libav was the default implicitly by being the first dependency of virtual/ffmpeg. Now the choice has been made explicit to libav in the portage profiles, and a news item regarding this was published.

In order to get a data point which might be useful for the discussion, I have created a poll in the forum, where Gentoo users can state their preference about the default:

https://forums.gentoo.org/viewtopic-t-1010096.html

You are welcome to vote in the poll, and if you wish also state your reasons in a comment. However, as the topic of ffmpeg/libav split has been discussed extensively already, I ask you to not restart that discussion in the forum thread.

New mesa features for the adventurous: Radeon UVD and Gallium3D HUD

Those of you who don't live under a rock will have learned by now that AMD has published VDPAU code to use the Radeon UVD engine for accelerated video decode with the free/open source drivers.

In case you want to give it a try, mesa-9.2_pre20130404 has been added (under package.mask) to the portage tree for your convenience. Additionally you will need a patched kernel and new firmware.

Kernel

For kernel 3.9, grab the 10 patches from the dri-devel mailing list thread (recommended) [UPDATE]I put the patches into a tarball and attached to Gentoo bug 466042[/UPDATE]. For kernel 3.8 I have collected the necessary patches here, but be warned that kernel 3.8 is not officially supported. It works on my Radeon 6870, YMMV.

Firmware

The firmware is part of radeon-ucode-20130402, but has not yet reached the linux-firmware tree. If you require other firmware from the linux-firmware package, remove the radeon files from the savedconfig file and build the package with USE="savedconfig" to allow installation together with radeon-ucode. [UPDATE]linux-firmware-20130421 now contains the UVD firmware, too.[/UPDATE]

The new firmware files are
radeon/RV710_uvd.bin: Radeon 4350-4670, 4770.
radeon/RV770_uvd.bin: Not useful at this time. Maybe later for 4200, 4730, 4830-4890.
radeon/CYPRESS_uvd.bin: Evergreen cards.
radeon/SUMO_uvd.bin: Northern Islands cards and Zacate/Llano APUs.
radeon/TAHITI_uvd.bin: Southern Islands cards and Trinity APUs.

Testing it

If your kernel is properly patched and finds the correct firmware, you will see this message at boot:

[drm] UVD initialized successfully.

If mesa was correctly built with VDPAU support, vdpauinfo will list the following codecs:

Decoder capabilities:

name               level macbs width height
-------------------------------------------
MPEG1                16 1048576 16384 16384
MPEG2_SIMPLE         16 1048576 16384 16384
MPEG2_MAIN           16 1048576 16384 16384
H264_BASELINE        16  9216  2048  1152
H264_MAIN            16  9216  2048  1152
H264_HIGH            16  9216  2048  1152
VC1_SIMPLE           16  9216  2048  1152
VC1_MAIN             16  9216  2048  1152
VC1_ADVANCED         16  9216  2048  1152
MPEG4_PART2_SP       16  9216  2048  1152
MPEG4_PART2_ASP      16  9216  2048  1152

If mplayer and its dependencies were correctly built with VDPAU support, running it with "-vc ffh264vdpau," parameter will output something like the following when playing back a H.264 file:

VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration

To make mplayer use acceleration by default, uncomment the [vo.vdpau] section in /etc/mplayer/mplayer.conf

Gallium3D Head-up display

Another cool new feature is the Gallium3D HUD (link via Phoronix), which can be enabled with the GALLIUM_HUD environment variable. This supposedly works with all the Gallium drivers (i915g, radeon, nouveau, llvmpipe).

An example screenshot of Supertuxkart using GALLIUM_HUD="cpu0+cpu1+cpu2:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered"

If you have any questions or problems setting up UVD on Gentoo, stop by #gentoo-desktop on freenode IRC.

Gentoo on the OLPC XO-1.75

Currently at the Gentoo Miniconf 2012 in Prague, we have two OLPC XO-1.75 devices and are working to install Gentoo on them.

These XO-1.75 is based on the Marvell Armada 610 SoC (armv7l, non-NEON), which promises countless hours of fun enumerating and obtaining obscure pieces of software which are needed to make the laptop work.

One of these is the xf86-video-dove DDX for the Vivante(?) GPU: The most recent version 0.3.5 seems to be available only as SRPM in the OLPC rpmdropbox. Extracting it reveals a "source" tarball containing this:

.:
total 1364
-rw-r--r-- 1 chithanh users 423968 12. Sep 14:39 aclocal.m4
drwxr-xr-x 1 chithanh users     80 12. Sep 14:39 autom4te.cache
-rwxr-xr-x 1 chithanh users    981 12. Sep 14:37 build_no_dpkg_env.sh
-rw-r--r-- 1 chithanh users      0 12. Sep 14:37 ChangeLog
lrwxrwxrwx 1 chithanh users     37 12. Sep 14:39 config.guess -> /usr/share/automake-1.12/config.guess
-rw-r--r-- 1 chithanh users   2120 12. Sep 14:40 config.h
-rw-r--r-- 1 chithanh users   1846 12. Sep 14:40 config.h.in
-rw-r--r-- 1 chithanh users  43769 12. Sep 14:40 config.log
-rwxr-xr-x 1 chithanh users  65749 12. Sep 14:40 config.status
lrwxrwxrwx 1 chithanh users     35 12. Sep 14:39 config.sub -> /usr/share/automake-1.12/config.sub
-rwxr-xr-x 1 chithanh users 440014 12. Sep 14:40 configure
-rw-r--r-- 1 chithanh users   2419 12. Sep 14:37 configure.ac
-rwxr-xr-x 1 chithanh users   1325 12. Sep 14:37 COPYING
drwxr-xr-x 1 chithanh users    262 12. Sep 14:37 debian
lrwxrwxrwx 1 chithanh users     32 12. Sep 14:39 depcomp -> /usr/share/automake-1.12/depcomp
drwxr-xr-x 1 chithanh users    252 12. Sep 14:37 etc
drwxr-xr-x 1 chithanh users     44 12. Sep 14:37 fedora
lrwxrwxrwx 1 chithanh users     35 12. Sep 14:39 install-sh -> /usr/share/automake-1.12/install-sh
-rwxr-xr-x 1 chithanh users 293541 12. Sep 14:40 libtool
lrwxrwxrwx 1 chithanh users     35 12. Sep 14:39 ltmain.sh -> /usr/share/libtool/config/ltmain.sh
-rw-r--r-- 1 chithanh users  27005 12. Sep 14:40 Makefile
-rw-r--r-- 1 chithanh users   1167 12. Sep 14:37 Makefile.am
-rw-r--r-- 1 chithanh users  25708 12. Sep 14:40 Makefile.in
drwxr-xr-x 1 chithanh users     76 12. Sep 14:40 man
lrwxrwxrwx 1 chithanh users     32 12. Sep 14:39 missing -> /usr/share/automake-1.12/missing
-rw-r--r-- 1 chithanh users   4169 12. Sep 14:37 README
drwxr-xr-x 1 chithanh users   1192 12. Sep 21:48 src
-rw-r--r-- 1 chithanh users     23 12. Sep 14:40 stamp-h1

src/:
total 688
-rw-r--r-- 1 chithanh users   3555 12. Sep 14:41 compat-api.h
-rw-r--r-- 1 chithanh users    805 12. Sep 14:37 datatypes.h
-rw-r--r-- 1 chithanh users  55994 12. Sep 21:22 dovefb.c
-rw-r--r-- 1 chithanh users  32160 12. Sep 15:11 dovefb_cursor.c
-rw-r--r-- 1 chithanh users    278 12. Sep 17:09 dovefb_cursor.lo
-rw-r--r-- 1 chithanh users   6052 12. Sep 14:41 dovefb_driver.h
-rw-r--r-- 1 chithanh users    974 12. Sep 17:09 dovefb_drv.la
-rw-r--r-- 1 chithanh users  13856 12. Sep 14:37 dovefb.h
-rw-r--r-- 1 chithanh users    264 12. Sep 17:09 dovefb.lo
-rw-r--r-- 1 chithanh users 128733 12. Sep 15:11 dovefb_xv.c
-rw-r--r-- 1 chithanh users    270 12. Sep 17:09 dovefb_xv.lo
-rw-r--r-- 1 chithanh users   2548 12. Sep 14:53 list.h
-rw-r--r-- 1 chithanh users  22242 12. Sep 17:08 Makefile
-rw-r--r-- 1 chithanh users   2121 12. Sep 14:37 Makefile.am
-rw-r--r-- 1 chithanh users   2134 12. Sep 14:37 Makefile.am.sw
-rw-r--r-- 1 chithanh users  21742 12. Sep 14:40 Makefile.in
-rw-r--r-- 1 chithanh users  18584 12. Sep 15:11 mrvl_crtc.c
-rw-r--r-- 1 chithanh users    856 12. Sep 14:37 mrvl_crtc.h
-rw-r--r-- 1 chithanh users    270 12. Sep 17:09 mrvl_crtc.lo
-rw-r--r-- 1 chithanh users    851 12. Sep 14:37 mrvl_cursor.h
-rw-r--r-- 1 chithanh users   2509 12. Sep 15:11 mrvl_debug.c
-rw-r--r-- 1 chithanh users   2284 12. Sep 14:37 mrvl_debug.h
-rw-r--r-- 1 chithanh users    272 12. Sep 17:09 mrvl_debug.lo
-rw-r--r-- 1 chithanh users  32528 12. Sep 15:11 mrvl_edid.c
-rw-r--r-- 1 chithanh users   5794 12. Sep 14:37 mrvl_edid.h
-rw-r--r-- 1 chithanh users    270 12. Sep 17:09 mrvl_edid.lo
-rw-r--r-- 1 chithanh users  84262 12. Sep 17:07 mrvl_exa_driver.c
-rw-r--r-- 1 chithanh users    282 12. Sep 17:09 mrvl_exa_driver.lo
-rw-r--r-- 1 chithanh users  10388 12. Sep 15:11 mrvl_exa_fence_pool.c
-rw-r--r-- 1 chithanh users    290 12. Sep 17:09 mrvl_exa_fence_pool.lo
-rw-r--r-- 1 chithanh users   9189 12. Sep 14:51 mrvl_exa.h
-rw-r--r-- 1 chithanh users   4258 12. Sep 14:37 mrvl_exa_profiling.h
-rw-r--r-- 1 chithanh users  46583 12. Sep 15:11 mrvl_exa_utils.c
-rw-r--r-- 1 chithanh users   3768 12. Sep 15:06 mrvl_exa_utils.h
-rw-r--r-- 1 chithanh users    280 12. Sep 17:09 mrvl_exa_utils.lo
-rw-r--r-- 1 chithanh users  20622 12. Sep 15:11 mrvl_heap.c
-rw-r--r-- 1 chithanh users   3256 12. Sep 14:53 mrvl_heap.h
-rw-r--r-- 1 chithanh users    270 12. Sep 17:09 mrvl_heap.lo
-rw-r--r-- 1 chithanh users   1774 12. Sep 15:11 mrvl_offscreen_memory.c
-rw-r--r-- 1 chithanh users    235 12. Sep 14:37 mrvl_offscreen_memory.h
-rw-r--r-- 1 chithanh users    294 12. Sep 17:09 mrvl_offscreen_memory.lo
-rw-r--r-- 1 chithanh users  47286 12. Sep 15:11 mrvl_output.c
-rw-r--r-- 1 chithanh users    274 12. Sep 17:09 mrvl_output.lo

More pictures of the Gentoo Miniconf can be found at the Google+ Event page.

xorg-server-1.12 going stable

It is time for xorg-server-1.12 to go stable in bug 419473. If you want to help testing, run the awk command

# awk '/YOURARCHHERE/ {print "="$1}' x11_stable.list > x11_stable.keywords

on the stabilization list attached to the bug, and add the result to /etc/portage/package.accept_keywords (or package.keywords if you are still using the legacy location).

After the xorg-server upgrade, do not forget to rebuild all x11-drivers. If you find a regression, please report a bug (if none already exists) and make it block bug 419473.

In related news, our current x11-drivers/ati-drivers maintainer Enrico Tagliavini is going to step down, as support for his notebook was dropped by AMD in version 12.6. Enrico has done an excellent job maintaining the package and we thank him very much for his work.
If you care about this package and like writing ebuilds, please come to #gentoo-desktop on irc.freenode.net and contact the x11 team.

xorg-server-1.11 going stable

In bug 394393, a number of x11 packages are going stable, including x11-base/xorg-server-1.11.2-r2.
After you upgrade, don't forget to rebuild your x11-drivers packages. Use the command that is shown in the elog messages to find out which. In case you missed it:

# qlist -I -C x11-drivers/

The output of qlist can be directly passed to emerge like this:

# emerge -1 $(qlist -I -C x11-drivers/)

If you are sitting at a gdm/kdm/xdm/... login prompt and can't type anything, press Alt+SysRq+R to switch to raw input mode and Ctrl+Alt+F1 will bring you back to the console.

Should portage hide build output from the user by default?

There has recently been a discussion on gentoo-dev about making portage output less noisy
http://archives.gentoo.org/gentoo-dev/msg_4f0401066abe2dc04458a952ac2a17bd.xml

A solution was implemented to suppress the build output (the configure, make and install) by default, unless the user specifies --quiet-build=n explicitly. There were both supporters and critics of that idea, but no real data about what users think.

If you have an opinion on this, please visit  the forums and participate in the poll and/or comment in the forum thread:

http://forums.gentoo.org/viewtopic-t-901858.html (plain)
https://forums.gentoo.org/viewtopic-t-901858.html (ssl)

Mesa 7.9 with Gallium3D entered ~arch

Mesa 7.9 was just added to the portage tree. Along with it came a new eselect module, eselect-mesa, which allows you to switch between classic and gallium drivers.

Especially interesting are the Radeon r300 and software renderer gallium drivers, which can give a significant performance and feature boost over the classic counterparts (enable USE="llvm" for best results). Gallium hardware drivers require DRI2/KMS to be active.

Please give it a good testing and report any issues that you find.

Booting from a btrfs filesystem in a GPT-partitioned USB flash drive attached to a non-EFI system

Previously thought impossible, thanks to syslinux 4 this feat can now be achieved in a few easy steps.

Background

Recently, I had a talk on IRC with the developer of the Arch Linux installer, who wanted to enable Arch Linux installation on legacy BIOS systems with GPT partitioned media.
As I usually carry a bootable USB flash stick with me, containing the netboot installers for various popular Linux distros (don't worry, all of them can be abused to install Gentoo as well), I thought that maybe it is time to get this up to date with the latest and greatest in partitioning and file systems.

• Why GPT?
  GPT, short form of GUID Partition Table, is the standard for EFI systems and is intended to replace MBR style partition tables. Advantages of GPT include support for up to 128 partitions (no distinction between primary and logical), no limitation to 2³² sector disks (2 TiB for 512 byte sectors), and increased redundancy for easier recovery.
• Why btrfs?
  No real reason, other than it being the new hotness (in spite of some design flaws).
  
• Why syslinux?
  EXTLINUX from the syslinux family of boot loaders can boot both from GPT and btrfs. An alternative would be GRUB 2, which however uses not the standardized method described in T13 EDD-4 Annex 1 and needs special patching for btrfs still.

Prerequisites

• A USB flash drive of >256 MiB capacity
• sys-apps/gdisk
• >=sys-boot/syslinux-4.00
• sys-fs/btrfs-progs

Partitioning

When first launching gdisk you will be greeted by a message that either the disk was found unpartitioned and a new GPT has been created, or that your existing MBR has been converted to GPT. In this example we use /dev/sdc as the device and /mnt/usb as the mount point.

# gdisk /dev/sdc
GPT fdisk (gdisk) version 0.6.9

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.

Now we proceed to create a partition (gdisk syntax follows fdisk closely) and then enter expert mode to mark this partition legacy BIOS bootable.

Command (? for help): n
(answer the questions)
Command (? for help): x
Expert command (? for help): a
Using 1
Attribute value is 0000000000000000. Set fields are:
Known attributes are:
0 - system partition
1 - hide from EFI
2 - legacy BIOS bootable
60 - read-only
62 - hidden
63 - do not automount
Toggle which attribute field (0-63, 64 to exit): 61

Note that due to a bug in gdisk-0.6.9 and earlier, you need to enter 61 instead of 2. This will be fixed in a future release. Verify that you have the correct attribute flags, which are 0000000000000004. Now write the partition table to disk and exit gdisk.

Installing the MBR/GPT boot code and EXTLINUX boot loader

Install the GPT boot code into the MBR

# dd if=/usr/share/syslinux/gptmbr.bin of=/dev/sdc

Create a btrfs filesystem in the partition

# mkfs.btrfs /dev/sdc1

Install the EXTLINUX boot loader into the partition

# mount /dev/sdc1 /mnt/usb
# extlinux -i /mnt/usb
/mnt/usb is device /dev/sdc1
# cp /usr/share/syslinux/menu.c32 /mnt/usb 

Configuring the boot loader

In this example, we put the Debian Squeeze amd64 netboot installer on the USB drive. Same thing works for the netboot (sometimes called PXE) installers of other distros too.

# mkdir /mnt/usb/debian-amd64
# cd /mnt/usb/debian-amd64
# wget http://ftp.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux
 http://ftp.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz

Create /mnt/usb/extlinux.conf with the following content:

DEFAULT menu.c32
PROMPT 0
MENU TITLE Select Installer

LABEL debian-amd64
   MENU LABEL Debian Squeeze amd64
   KERNEL /debian-amd64/linux
   APPEND initrd=/debian-amd64/initrd.gz

Now your USB stick should be bootable and ready to use.

Other Thoughts

While syslinux supports chainloading on GPT disks, you cannot boot Windows this way, because Windows requires an EFI system in order to boot from GPT.
ChromeOS uses a slightly different method of booting from GPT, which resembles the old syslinux 3 and current FreeBSD way (even using the gpt utility from FreeBSD). If you are interested in their way, look at the ChromeOS installer scripts and the gpt utility.
A nice description of the issues surrounding booting from GPT can be found at the gdisk website.

Mesa and Gallium3D

Gallium3D is the new driver architecture for Mesa. In the X11 overlay you will now find an eselect mesa module, which in conjunction with the live mesa ebuild allows you to switch between classic and gallium.

Of course, this only works for drivers which exist both in a classic and gallium version. At the time of writing these are:

• i915, i965: The gallium drivers for Intel chipsets are presently inferior to the classic drivers. There is little reason to use them at this time.
• Radeon r300: The radeong gallium driver works well and has recently surpassed the classic driver in terms of features and performance.
• Radeon r600: The r600g gallium driver was added to mesa a week ago and does not do anything useful yet.
• Software renderer: If Mesa was built with the "llvm" USE flag enabled, then the gallium llvmpipe driver will give you much improved performance over the classic software rasterizer. As a tile based renderer it will use multithreading too. However some graphical glitches are still visible.

If you encounter any issues with eselect mesa, feel free to join #gentoo-desktop on freenode or report a bug, prefixing the summary with "[x11 overlay]".

Update: If you had already installed mesa-9999 from the X11 overlay, please rebuild it to ensure proper functioning of the eselect module.

Nouveau on Gentoo

For some time already, Gentoo has provided packages for the open source nouveau driver for NVidia graphics chipsets. Some users have discovered this and attempted to install nouveau, running into a few problems, most commonly experiencing the API break before libdrm 2.4.18 and after kernel 2.6.33.

Should I run nouveau or not?

Nouveau works strictly better than xf86-video-nv and has the following philosophical and technical advantages over the proprietary driver:

• Open source.
• Can always build with the latest kernel and xorg-server code from git.
• Supports all Riva TNT, GeForce and integrated chipsets, except for the GTX 400 series.
• Kernel Modesetting for framebuffer console at native display resolution and flicker-free vt switch.
• XRandR 1.2 support for dynamic output configuration.

Nouveau does however not yet support some features of the proprietary driver. So if you depend on those, you will have to stay with the blob for now:

• No power management support.
• No video decode acceleration.
• Limited multi-card support (all non-primary cards must be NV50/G80 or later generation, no SLI)
• TV-out only works on NV40 and older.
• 3D acceleration is experimental and not recommended for the timid.

Check the nouveau Feature Matrix for more details.

Installing nouveau on Gentoo

If you have decided that you want to try nouveau, the best way to proceed depends on whether you run a (mostly) stable system, an unstable (~arch) system or whether you always live on the bleeding edge of development.

Before you begin, ensure that eselect opengl is set to x11 and you are not loading the proprietary nvidia kernel module.

Stable users: You can run nouveau on an otherwise stable system with the following packages from ~arch:

• Kernel 2.6.33 (set DRM_NOUVEAU=m or =y)
• x11-drivers/xf86-video-nouveau (latest version)
• x11-drivers/nouveau-firmware (only needed for NV50 generation cards)

However the drm in kernel 2.6.33 is a bit old and will not support the integrated 8200/8300/9300/9400/ION chipsets.

~arch users and stable users who want newer nouveau: You cannot use the nouveau drm in kernel 2.6.33 with the unstable version of x11-libs/libdrm due to the aforementioned API break. So you need the following packages:

• x11-base/nouveau-drm (latest version), see here if it complains about missing kernel options which you cannot find in menuconfig
• x11-drivers/xf86-video-nouveau (latest version)
• >=x11-libs/libdrm-2.4.18

Bleeding edge users, or users who want 3D acceleration: You should run the latest kernel and mesa code for best results:

• Nouveau from Kernel 2.6.34_rc4 or newer, or x11-base/nouveau-drm-9999 from the x11 overlay (needs 2.6.34_rc2 at least)
• x11-drivers/xf86-video-nouveau (latest version)
• >=x11-libs/libdrm-2.4.20
• =media-libs/mesa-9999 from the x11 overlay, built with USE="gallium" and VIDEO_CARDS="nouveau" (only if you want the experimental 3D acceleration for which nouveau developers provide no end user support).

Stop by in #gentoo-desktop on freenode or post in the forums if you have any questions.

UDF, the new lingua franca of filesystems?

Not too long ago, when creating a filesystem on a removable storage device, or on a hard disk shared between several different operating systems, the natural choice was FAT32. FAT32 is reasonably well supported on all major OSes, however its limitations (eg. 4G maximum file size) make it unsuitable for large media.

So what is an adequate replacement for FAT32? NTFS support in Linux has improved a lot in the last years. Unfortunately, it is based on reverse engineering instead of public specifications. Due to its proprietary nature, the NTFS specification can change without notice, possibly leading to data loss/corruption when accessed with unprepared tools.

Enter UDF, which was developed for removable optical media, has no silly limitations and can be read and written to by current versions of Linux, Windows and Mac OS X. One minor issue is that the UDF specification does not allow placing it inside a partition, it must always occupy a whole disk. But no ill effects are expected from ignoring this.

Now in Linux create a partition of type 0x7 (IFS), run mkudffs, and boot into Windows. Whoops, no filesystem recognized. Ok then, run format /fs:udf then boot into Linux again. Whoops, UDF-fs says "No partition found". Experiment with different UDF revisions, no luck. Examine more closely, find out that the Linux UDF driver defaults to a block size of 2048 bytes, while Windows format uses 512 byte blocks. Mount with mount -o bs=512 and it works! Well, almost.

Copy a small file on the partition and it is recognized by the other OS. Copy a 6G file with Linux, and Windows doesn't see it. What is going on here?

Nigeria dumps Linux, or: Mandriva in bed with the wrong people

It's all over the news, Mandriva closes a deal to deliver thousands of laptops to schoolchildren in Nigeria with Mandriva Linux preinstalled. Then suddenly the customer decides to replace Linux with Windows. Mandriva CFO cries "foul" and the usual frenzy ensues.

A sad day for Mandriva? Certainly. A sad day for education in developing countries? Not particularly. For their project, Mandriva chose the Classmate PC, a laptop project which was envisioned by Intel after the latter missed out on the OLPC educational project and had to hack together something cheap. The folks at OLPC however realized from the very beginning that selling stripped-down ordinary computers below cost would bring them nowhere.

Now the whining is all about how hard it was to coordinate everything, how much work went into it, and so on. But they chose an inferior and unsustainable platform. The OLPC's visionary design required a clean software design to complement it, something Microsoft has had a hard time to achieve. Making the Classmate PC run Windows doesn't cost Microsoft a thing, so it's hardly surprising that they opted for piggybacking into Nigerian classrooms.

I hope Mandriva have learned their lesson and stop being bad losers. They have interesting products in the pipeline. Had their laptop been based on the same CPU as their upcoming Loongson Box, they wouldn't be in that position now.