DistroWatch Weekly

A weekly opinion column and a summary of events from the distribution world

DistroWatch Weekly

DistroWatch Weekly, Issue 358, 14 June 2010

Welcome to this year's 24th issue of DistroWatch Weekly! The question of binary firmware is a contentious issue in many Linux circles. Although many freedom-loving users accept the position of the Free Software Foundation (FSF) which advocates removing any drivers that require proprietary firmware from the Linux kernel, there are those who challenge this view as naive and even hypocritical. Our feature story, an opinion of an expert with years of experience in the electronics industry, offers an alternative position to that of FSF. In the news section, Fedora project reveals roadmap and early feature list for version 14, Eric Hameleers presents the recently released Slackware Linux 13.1, the developers of Peppermint OS talk about their vision of Linux-based cloud computing, and Lawrence Livermore National Laboratory ports parts of the Solaris ZFS file system to Linux. Also in this issue, a brief tutorial on creating an encrypted file system for storing sensitive data. Finally, for those readers who enjoy checking the package versions in our distribution tables, we'd like to hear your suggestions for the annual package database update. Happy reading!

Listen to the Podcast edition of this week's DistroWatch Weekly in OGG (32MB) and MP3 (44MB) formatsJoin us atirc.freenode.net #distrowatch

Feature Story (by Patrick Van Oosterwijck)

Binary firmware and your freedom

Introduction

In the world of technology, there is a continuous battle between forces promoting freedom and forces trying to take it away. The Free Software Foundation (FSF) has been a vigilant guardian of freedom that constantly has brought issues to our attention that, if left unchecked, could threaten our freedom as it relates to our use technology. Due to their efforts and the GPL license, we can benefit from such marvellous pieces of software as the Linux kernel, GCC and many more. I am convinced that the open source landscape wouldn't look nearly as good as it does if it hadn't been for the GPL protecting the rights of users of free software.

While I am very supportive of the FSF in most areas, one area where I disagree with them is the issue of binary firmware used in hardware drivers. The FSF explains its position on binary firmware on this page. The page admits the drivers themselves are free, but states that "it is a good idea to avoid hardware that requires these drivers" and that "hardware that relies on them is not compatible with free software" because they require proprietary firmware. Then it goes on to show a list of offending drivers found in the Linux kernel, and explains that these drivers have been removed from their own gNewSense distribution. Other projects like Debian GNU/Linux keep the binary firmware files out of the default kernel installation but make them available in a separate package that is not installed by default. This package needs to be loaded separately from the non-free repository if the user has any hardware requiring these files.

Why do I disagree with the FSF position on binary firmware? It is my opinion that in the best case, their position could be called somewhat naive, in the worst case it could even be called hypocritical. In either case, it also draws attention away from the real issue. Those are pretty strong statements, I know. Because of my professional involvement with the electronics industry, I do have a somewhat different perspective, a perspective from the "other side" you might say: that of the hardware manufacturers. (As a disclaimer, I am not employed nor have any business relation with any of the companies making the devices on the FSF's black list. I am merely a user of chips that require firmware to be loaded in one way or another, so I am more aware than most users of how these things work.)

What is binary firmware?

Most of the peripherals that can be connected to a PC have a brain of their own. This can be in the form of a microcontroller, a microprocessor or an FPGA. In any of these cases, the basic hardware parts in the peripheral are programmable, and the manufacturer of the peripheral must implement algorithms to make the peripheral do its task and communicate with the PC. These algorithms can be implemented in software code, as in the case of microcontrollers and microprocessors, or even in code describing programmable hardware connections, as in the case of an FPGA-based peripheral. This code is referred to as "firmware".

An important characteristic of this firmware is that it runs completely on the peripheral. The PC's microprocessor does not execute any of the instructions in the firmware. In most cases, it would be even impossible for the PC's microprocessor to execute any of the code in the firmware, since peripherals generally use chips with comparatively simple architectures and instruction sets that are different from the PC's own instruction set.

I want to make this very clear: the opinion expressed in this article only relates to binary firmware executing in the peripheral device, not to binary drivers that are loaded as kernel modules by the Linux kernel and execute within the kernel. Binary kernel modules present major issues that are completely different from those presented by binary firmware.

In recent years, more of the microcontroller and microprocessor architectures used in peripherals have become supported by free software compilers like GCC and SDCC, and the situation continues to improve. But as things stand today, many of these chips are still only supported by proprietary development tools, most of which do not run on Linux. If it was even possible for the Linux kernel build system to automatically build firmware from source during the kernel build process, it would obviously not be possible in all cases. Hence, the firmware for different peripherals is distributed with the Linux kernel as a set of binary files and is referred to as "binary firmware".

Now I do realize that it would be possible for manufacturers to make the source code of the firmware for their devices available, even if the kernel would have to include the firmware in binary form due to compiler limitations. It would still not be trivial to alter the code in that case, but it would be possible for a person with the right skills and access to the right tools. I do not know this for sure, but I would think the FSF might not have a problem with the firmware in that case. Unfortunately we do not live in a world where this is commonly done, as far as I'm aware.

If having source code available for all binary firmware was the center of the FSF's policy, I would not disagree with them in any way (although I would not have much hope of achieving this goal). My problem is with the fact that the FSF is blacklisting specific drivers based on how their binary firmware is distributed, instead of focusing on the real issue of whether firmware source code is available at all. And by targeting the wrong issue, they are at the same time giving their blessing to devices that use firmware that is just as locked up, or even more locked up, than those they are blacklisting. Let me explain.

How does the peripheral chip get the firmware it needs?

One possibility is that the firmware is programmed directly into the target chip that needs it. This is the case for many microcontroller-based and Flash-FPGA-based solutions. Often, the internal memory is protected in such a way that it is virtually impossible to access it or change it from the outside world. In some cases, with ASIC's or re-branded parts, it is impossible to even tell what architecture the chip uses, let alone what firmware it runs.

Another possibility is that the firmware is programmed into a memory chip that is part of the peripheral board, but external to the target chip that needs the code. Some microprocessor, microcontroller and SRAM-FPGA-based devices use this option. Usually it is possible to read out the code from the memory chip and, if you had the right software tools for the target chip and a programmer for the memory chip, you could load your own firmware code if you wanted to.

The third option is that the target chip has a boot loader that asks the PC to provide it with the firmware it needs to do its job. If the PC is running Linux, the Linux kernel will see this request and try to find the firmware. Then it will send the firmware to the chip, and once it is loaded, the chip will start to execute the firmware. Many manufacturers like this option because it provides the flexibility to update the firmware if necessary, just by changing a file on the PC, while at the same time saving cost because no non-volatile storage is needed on the peripheral.

What about your freedom?

Which of the above methods to store and deliver binary firmware seems more free to you? Remember, none of them qualify as free software, because no source code is available. But some are definitely more accessible than others.

In case of option 1, there is usually no way for you to access or change the code. In option 2, with the right tools, you have the ability to read out the binary code, and you might be able to disassemble the existing firmware code, or write entirely new code, which you can load into the device if you have a programming tool. In option 3, you can do the same thing, but you don't even need any tool to read out the binary code, because it is sitting right there in a file on your computer. There is no need for a programming tool, because the kernel takes care of loading the firmware for you. You can disassemble the existing code, or start from scratch, and change the firmware running on the peripheral just by replacing the firmware file.

I think it is obvious that option 3 grants you the most freedom, because it makes it the easiest to see what's there and make changes. No specialized hardware is needed. All you need is a disassembler and assembler for the target device and you can make changes to your hearts content. Yet this is exactly the option the FSF actively discourages and labels incompatible with free software! Why? Because of its distribution method. The firmware is distributed with the Linux kernel, instead of on the circuit board of the device. That is the only difference. Meanwhile, the FSF encourages us to buy other hardware, hardware that chooses a less accessible way of distributing its firmware: locked up inside the device. Firmware for which no source code is available either, and which is significantly harder to access and change. Yet, these devices get the FSF blessing, even though there is no source code available for their firmware either.

In my mind, this is totally wrong. Since no firmware source code is available, all these devices should be treated in exactly the same way. Either they're all okay or they're all bad. How the firmware is stored and delivered is irrelevant. Of course, declaring all devices running binary firmware unacceptable is not really an option, since that would mean you would have practically no hardware available to run your totally free OS on. Because at one level or another, you always run into a wall where things become proprietary and you lose control. After all, computing is just the execution of algorithms--whether this is done in hardware or software is merely an implementation detail. Why should it make a difference if one peripheral implements its functional algorithms totally in hardware, in a totally inaccessible way, and its associated driver is declared "free", and another peripheral implements the exact same algorithms partially in software, and its associated driver is declared "non-free" because the peripheral needs to be given a bunch of bits representing its algorithm first?

To any embedded software developer, the second option is the one that's significantly more free. To anyone else, who doesn't have the skill set or necessary tools, the two options are exactly the same when it comes to their freedom. They only have access to the PC side of the driver either way. In fact, the driver could look and act exactly the same for both devices, except for the part where one of them needs to send a file to the peripheral first before it can start to talk to it. There isn't more freedom to the kernel developer one way or the other. There isn't more freedom to the user one way or the other. They are the same.

How to rate hardware devices as related to our freedom

I suggest the following rating scheme for determining how "free" a device is and how friendly the manufacturer is to open source:

The most freedom-friendly device is one that uses an architecture supported by open tools and for which the source code of the firmware is available.

The next best case is that the source code of the firmware is available, but the device uses an architecture not (yet) supported by open tools.

The next best case is either a device that has its firmware built-in or that takes a binary firmware file from the kernel, and the manufacturer allows the firmware to be distributed with the Linux kernel. This is the case the FSF makes a big deal about, promoting the built-in firmware implementation as "free" and labeling the loaded-from-the-kernel implementation "incompatible with free software". As explained above, in practice it makes no difference to our freedom and is just a minor implementation detail. In either implementation, we don't have access to the source. In either implementation, it is very easy to use the device with our free OS of choice. [Except of course if this freedom is arbitrarily taken away, not by the hardware manufacturer, who should be commended for allowing their firmware to be freely distributed with the kernel, but by a distribution under the guise of "protecting your freedom".]

The next best case is that binary firmware needs to be loaded from the kernel, but the manufacturer does not allow the firmware to be distributed with the kernel. This is very inconvenient and the user has to jump through hoops to download the firmware and install it separately or even use some cutter tool to extract the firmware from the Windows driver. No kudos for the manufacturer here. But can you blame them? The FSF would put their device on the blacklist whether they made their firmware available for distribution with the kernel or not. So why would they bother?

The worst case is if binary firmware needs to be loaded from the kernel, but no one has found a way to get the firmware. If public documentation on the device architecture is available, it is conceivable that someone could write firmware to support the device. If no documentation is available, someone might figure things out by reverse engineering, but the chances are rather slim. It is likely that the device cannot be used with a free OS.

Conclusion

Freedom, including software freedom, is important. However, it is a fact that total freedom does not exist in any area of life. When it comes to computers, unless you have completely open software and hardware, all the way down to the design of the chips used, you will lose your freedom at some point. It is worth fighting for the ability to hold on to this freedom as long as possible, but making arbitrary rules about how something non-free happens to be distributed is not going to help anyone. Instead, it distracts from the real issue. The reality today is that just about every device out there runs binary firmware internally. Acting as if there is no issue if this firmware doesn't touch your hard drive by having it stored conveniently out of sight elsewhere in your PC is extremely naive.

The current position of the FSF is akin to a defending army making bold claims that they are fighting an invading army, but they are only attempting to stop enemy soldiers that have their guns in their hands. At the same time they let multitudes of others who have their guns slung over their shoulders pass along without interference. Then when asked about it, they claim all the ones they let pass were harmless civilians, since they weren't using their guns. It is just a token fight, and the real issue is ignored.

As a result of this senseless rule, users of devices requiring firmware loaded by the kernel get inconvenienced by having to hunt down these files on distributions that adhere to the FSF policy, or worse, they get encouraged to buy devices with the same closed source firmware locked up in the hardware. Either way, the closed source firmware is running in the user's devices. The only difference is that the user who buys devices where the firmware is distributed inside the hardware is diluted into thinking that they have somehow gained freedom. Then they can go brag on Internet forums that they are running a "totally free system", which couldn't be further from the truth.

I suggest that instead of these scapegoat tactics and acting as if they solve any real issue, efforts should be focused on encouraging manufacturers to publish open specifications for their chips and open the source code for their firmware, whether it lives inside the hardware or gets loaded by the kernel. And let's commend those manufacturers that allow their binary firmware to be conveniently distributed with the Linux kernel instead of punishing them by blacklisting their devices. That could be a first step toward improved communication with hardware manufacturers, which in turn might make truly free firmware more likely in the future.

Fedora 13 was released barely three weeks ago, but the developers of this popular distributions are already making plans for the next version (see the Upcoming Releases section below). Although these are still early days, Rahul Sundaram is happy to reveal three new features approved for Fedora 14 - more content in live images, faster picture browsing and multi-path device support: "Fedora is replacing the old and stagnant libjpeg library with libjpeg-turbo library by default. It contains numerous performance related enhancements and is at least twice faster in JPEG compression and decompression than original libjpeg on platforms with MMX/SSE instruction set. It has same API/ABI like original libjpeg and also runs on non-SSE platforms where it is around 25% faster. Adam Tkac is leading the fork effort as part of his involvement in the TigerVNC. As you might recall, Fedora switched over to using TigerVNC for Fedora 11 and this is a logical next step. Instead of multiple software components bundling patched versions of a library, Fedora will have a better maintained and faster equivalent. libjpeg-turbo is currently in the Fedora package review queue and looking for a reviewer. Hopefully someone volunteers to do that and we will see it in Rawhide soon."

* * * * *

Last week's link to Slackware Linux interview with Robby Workman resulted in a number of interesting comments here, so let's continue in the same spirit this week. Slackworld's new interview, entitled Slackware does exactly what I want it to do, is with Eric Hameleers: "Another thing I want to do is to investigate into the possibility to write a script that takes a Slackware DVD ISO (or a package tree) and creates a live DVD image out of that, for promotional purposes. The linux-live scripts are nice, but too complex for my needs, plus it requires that you already have a running system. Having a script that I can throw at a development tree and gives me back a live DVD would be very nice to have. And finally, I have ideas for a modified initrd.gz (this is the file on the Slackware boot disk that contains the installer) which lets you start a PXE server running right off the installation DVD. That would make it easy to install Slackware over a network on other computers that lack a DVD drive. I may have some time for all that, hopefully in the next few months."

* * * * *

While on the subject of interviews, here is another one - this time with the developers of Peppermint OS. This is a new Ubuntu-derived distribution with a number of web-based applications and other "cloud" features. Kendall Weaver and Shane Remington talk about the project's beginnings: "Originally the concept was rather simple, we were going to take Linux Mint and make it 'spicier' (hence the name Peppermint) by adding clean social network integration. I love the look of sidux so we decided on a color scheme in that general neighborhood. I guess the single biggest inspiration is the fact that with more applications moving to the cloud, your OS serves less purpose as an OS and more of a portal. We decided that we wanted to build the best portal. ... What we really wanted was that anyone with simple computing skills could use the software right out of the box. So, providing a very familiar workspace for the beginner was at the front of the design and operation. We want very young children to use Linux. We want to show those who are tired of overpriced and unstable operating system software that there is an alternative that works. When people hear the word 'Linux' they have a tendency to feel that they would never understand how to operate a Linux based system. We created Peppermint to lay that notion to rest once and for all and pull as many new users into Linux as we can."

* * * * *

Something more technical, but since several readers have suggested this topic for today's news section, here we go. It's about the port of ZFS, the famous file system developed by Sun Microsystems and used in Solaris, which is now being ported to Linux: "Developers at the Lawrence Livermore National Laboratory have cooperated with Oracle to port large parts of Solaris' ZFS file system to the Linux kernel. Their aim is to make the distributed Lustre file system available under Linux with ZFS. This narrow target also explains why the Native ZFS for Linux port is incomplete. Lustre is able to directly use the ZFS DMU (Data Management Unit), which connects to the Storage Pool Allocator (SPA, storage hardware interface) rather than go through the ZFS Posix Layer (ZPL) which provides an interface for the operating system. The developers therefore have not ported the ZFS Posix Layer to Linux and this currently makes it impossible to mount ZFS volumes under Linux. However, other developers are apparently already working on the ZPL. Native ZFS for Linux can be compiled with kernel versions up to 2.6.32; among the tested platforms are the 2.6.32 kernel in Fedora 12 and in the beta version of Red Hat Enterprise Linux 6, as well as the 2.6.18 kernel in RHEL 5. The build requires the Solaris Porting Layer and a 64-bit Linux system."

Questions and Answers (by Jesse Smith)

Encrypting hard disk partition

Worried-about-private-data asks: How do I encrypt a partition?

DistroWatch answers: First, you need a partition to work on. In this example, we'll assume you have a free partition on your hard drive called sda4 (/dev/sda4). If you don't have a spare partition you can use tools such as GParted to shrink an existing partition and create a new one with the free space. (Remember to always backup your data before adjusting your partitions.)

Once you have a spare partition we need to set up encryption on the available space. To do this, we use the cryptsetup command to prepare our partition. If you don't have the cryptsetup program on your machine, you will probably be able to find it in your distribution's software repository. Please note that to perform the commands shown in this example, you'll need to have administrative privileges on your machine. This first command sets up the partition to be encrypted:

cryptsetup luksFormat /dev/sda4

At this point the system will ask you for a pass-phrase. This is the pass-phrase which will protect your data, so make sure it's something hard to guess yet easy to remember. The next step is to access your newly encrypted partition and assign it a name. Once again we use cryptsetup, this time to open the partition:

cryptsetup luksOpen /dev/sda4 secret

You will be asked to supply the pass-phrase you created in the previous step. If all went well, we'll now have opened our encrypted partition, located on sda4, and assigned it the name "secret". Our next step is to write a Linux file system to our encrypted partition. We can do that by running:

mkfs.ext3 /dev/mapper/secret

Our encrypted partition now uses the ext3 file system. Once the partition has been formatted, we can move on to using it. We'll need to create a mount point:

mkdir /mnt/encrypted

And now we can mount our partition:

mount /dev/mapper/secret /mnt/encrypted

We can now save any sensitive data we have to the file system under /mnt/encrypted. When we're finished, we need to unmount the partition and then close the encrypted device:

umount /dev/mapper/secret cryptsetup luksClose /dev/mapper/secret

It's important to close the partition, otherwise someone else can re-mount it without needing your pass-phrase. From now on, if you want to manually access your encrypted data, you can run:

However, doing that at each boot-up can get tedious, so if you wish to mount the partition automatically and have the system prompt you for your pass-phrase at boot time, you can add entries to your /etc/crypttab and /etc/fstab files. The entry in /etc/crypttab will look like this:

secret /dev/sda4 none luks,check=ext3

And the entry in /etc/fstab, following our example, will look like this:

/dev/mapper/secret /mnt/encrypted ext3 defaults 0 0

Of course, if you're serious about keeping your data hidden from the prying eyes of the world, you shouldn't actually name your devices and mount points things like "encrypted" and "secret". That's a good way to advertise there is something special to find. You should probably pick something boring like "temp", "cdrom" or "sys", which will blend in better if anyone is looking over your shoulder. I also recommend reading the cryptsetup manual (man cryptsetup). The documentation is well laid out and offers useful options and tips.

There are some other interesting things you can do to keep your data hidden. If you're worried someone might notice your encrypted partition and try to access it, you can try a different tactic, such as creating a loopback device with a local file and encrypt the loopback file. The loopback file can be stored anywhere, including in a hidden directory. For the really paranoid, you can keep encrypted files inside a hidden, encrypted file. But, as with most security matters, there's a point where you're inconveniencing yourself more than accomplishing anything practical.

Kaj de Vos has announced the release of Syllable Server 0.4, a small (but extensible) server distribution built on top of a recent Linux kernel and the Linux From Scratch (LFS) base system: "We are pleased to announce that we have released the new Syllable Server 0.4. This release focuses on maturing existing functionality, improving security, ongoing system restructuring, and making the system a suitable base for third-party package managers. About half the packages in the system were upgraded, including key components such as the Linux kernel, udev, the LFS init scripts, DirectFB, SDL, Bash, Packager, OpenSSH, REBOL/Core, the Cheyenne web server and cdrtools. Other important packages such as Ruby, Midnight Commander, Links and Transmission were also updated. XZ-Utils was added, providing the same LZMA compression as in 7-Zip." See the release announcement and changelog for further details.

Marko Kaiser has announced the release of linuX-gamers Live 0.9.6, an Arch-based live CD/DVD/USB image containing a large collection of popular Linux games: "We recently released a new version of our games distribution. New features: host system in local network. New games: Osmos demo, LinCityNG, OpenTTD. All other games are based on their most recent versions. You will notice that there are two editions now. Lite ISO: a small CD image (700 MB) containing a limited games selection suitable for children and older computers. Burn it to a blank CD-R/CD-RW using regular Linux or Linux tools like Nero, K3B, Infrarecorder, etc. Alternatively, you can write it to a USB device (at least 1 GB capacity). Big ISO: a big DVD image (4.7 GB) containing the full games selection for adults and more recent computers. Burn it to a blank DVD-R/DVD-RW using any burning tool of your choosing or write it to a USB device (at least 5 GB capacity)." Here is the brief release announcement.

Jörg Schirottke has announced the release of KANOTIX 2010, a desktop distribution and live DVD with KDE 3/4 based on Debian GNU/Linux 5.0: "Just in time for LinuxTag 2010, updated KANOTIX 'Excalibur' versions are available. All based on Debian 5.0 'Lenny' with all the latest security updates and many extras. In short they contain: Linux kernel 2.6.32-ck2 (BFS powered); KDE 3.5.10; OpenOffice.org 3.2.1; GRUB 2 (1.97 beta 4); wicd 1.6.2.2; Pidgin 2.7.1; NTFS-3G 2010.5.22; WINE 1.2-rc2; Iceweasel 3.0.6 (XULRunner 1.9.0.19); Icedove 2.0.0.24; Kano scripts for installing NVIDIA or ATI graphics drivers, as well as FlashPlayer plugin." Read the release announcement for further information.

Paul Sherman has announced the release of Absolute Linux 13.1.1, a lightweight Slackware-based distribution with IceWM: "Absolute 13.1.1 released. New kernel and a boatload of updates from Slackware. Almost replaced Firefox with Google Chrome (which I really like) but due to an endless 'upload' bug that keeps crashing Chrome when you try to upload a file, it'll be in the CD2 directory for testing/playing. The 13.1.0 release was a naming snafu as it pre-dated Slackware's update. This release (13.1.1) incorporates Slackware 13.1 as well as several re-compiled packages on Absolute and a couple of scripting changes. Some add-ons in the CD2 directory of the FTP sites (Google Chrome and Picasa for example), gmail-notify added and incorporated into email notification setup as an option. Add/Remove programs (PERL script) updated." There is a brief release announcement on the project's home page and slightly more detailed one in the forum.

Artyom Zorin has announced the release of Zorin OS 3, an Ubuntu-based distribution designed for Linux beginners: "Welcome to Zorin OS 3. The Zorin OS team is very proud to release this software to you. We hope you will enjoy your experience with this new Zorin OS release. We have also provided you with some material about what's new and different in Zorin OS 3, what you'll need to watch out for, system requirements and other release information. What's new? Zorin OS 3 now comes pre-installed with a brand new exclusive program called the Zorin OS Look Changer. This allows you to use your desktop in not only a Windows 7 style, but also Windows XP and GNOME interface. During the installation of Zorin OS 3, you will see a slideshow that shows you around Zorin OS. This slideshow will get you familiar with Zorin OS and its advantages, programs and features." Read the detailed release notes for additional information.

Frédéric Boulet has announced the release of the "GNOME" edition of Zenwalk Linux 6.4, a Slackware-based distribution featuring the GNOME desktop: "We are proud to announce the release of Zenwalk Linux 6.4 GNOME edition. As always, Zenwalk features the latest Linux technology, including the Linux kernel 2.6.33.4 and the GNOME 2.28.2 desktop environment. The GNOME 2.28.2 desktop includes a number of new features: Totem has an asynchronous parsing API now, GNOME Power Manager now has support for laptops with multiple batteries and has added disk spin-down support for DeviceKit disks. The GNOME panel comes back to the origin layout. You will find the same software base as in the standard edition: Pidgin 2.7.0, Totem 2.28.6, Brasero 2.28.3, Goobox 2.1.1, Geany 0.8.1, gedit 2.28.4, OpenOffice.org 3.2.0, GStreamer 0.10.29; X.Org 7.5. Others GNOME applications are available in the extra repository." Read the rest of the release announcement for more information.

sidux 2010-01, a new version of the desktop distribution with KDE or Xfce based on Debian's unstable branch, has been released: "Now that KDE 4.4.4 and kernel 2.6.34 have entered the archive, we have the pleasure to announce the immediate availability of the final sidux 2010-01 'Hypnos' release. While waiting for the availability of KDE 4.4.x, 'Hypnos' development concentrated on overhauling the early boot sequence for live and installed systems with regards to concurrent dependency-based booting and the integration of kernel 2.6.34. sidux now uses CONCURRENCY=makefile and continues to embrace GRUB 2 on the installed system, with isolinux and an improved gfxboot theme on the live system. KDE-based ISO images can now make use of Partition Manager instead of GParted. As usual, a large number of individual functionality enhancements and bug fixes have been applied to the full package line-up." Read the detailed release notes for further information.

The Fedora project has published a release schedule for Fedora 14. Like the development of its current stable release, the upcoming version will have two public test releases, scheduled for 17 August 2010 (alpha) and 21 September 2010 (beta). The final release is set to arrive on 26 October 2010. A detailed schedule is available here.

The month of June is usually the time when we update the list of packages tracked by DistroWatch on the individual distribution pages and this year will be no different. Several package changes are currently under consideration, notably the replacement of VNC with TigerVNC (an actively developed and non-commercial project that is now part of Fedora and other distributions), and the switch from F-Spot to Shotwell (the Mono-based F-Spot has fallen out of favour in both Fedora and Ubuntu). Other requested packages that are likely to enter the database are lzip and Wordpress. On the list of to-be-removed packages there are currently DeviceKit and Zope.

As always, you are welcome to submit suggestions for packages that you want us to track - either by commenting below or by emailing to distro at distrowatch.com. Those packages that get most requests will be added to the package database by the end of this month.

* * * * *

New distributions added to database

Alpine Linux. Alpine Linux is a community developed operating system designed for x86 routers, firewalls, VPNs, VoIP boxes and servers. It was designed with security in mind; it has proactive security features like PaX and SSP that prevent security holes in the software to be exploited. The C library used is uClibc and the base tools are all in BusyBox. Those are normally found in embedded systems and are smaller than the tools found in GNU/Linux systems.

* * * * *

New distributions added to waiting list

Business OS. Business OS is a German Ubuntu-based distribution designed for self-employed people and small businesses. The project's web site is in German.

CIITIX-WiFi. CIITIX-WiFi is a Debian-based distribution that makes it easy to set up a secure WiFi hotspot.

vatlator. vatlator is a simple Ubuntu-based operating system with Tor (a privacy protection tool) set up for anonymous Internet surfing.

Star Labs - Laptops built for Linux.
View our range including the Star Lite, Star LabTop and more. Available with a choice of Ubuntu, Linux Mint or Zorin OS pre-installed with many more distributions supported. Visit Star Labs for information, to buy and get support.

Monomaxos was an Ubuntu-based distribution whose purpose was to provide a complete out-of-the-box functional Linux operating system by including browser plugins, media codecs, support for DVD playback, Java, Flash and other components. It also adds a custom desktop and menus, and a modified Wubi installer for making installation very easy. Monomaxos was compatible with Ubuntu software repositories.