Network deployment and alternative OS's – 1.

These are exciting times for devices. You will have the options of Android, ChromeOS, FirefoxOS, KDE Plasma Active, etc. How do they differ and how do you play with them?

One striking difference is that each one is supposed to have a distinct personality in addition to, perhaps, some differences in functionality. This is in contrast to the flexibility of distributions like Fedora and Arch Linux, where we can get a very different environments by switching between KDE, Gnome, Cinnamon, XFCE, LXDE, etc. Ubuntu may have a preference for Unity but it too can be changed to any of the other personalities.

You may also differentiate various environments on the basis of thin and thick clients. The new environments seem to fall between the two. They rely predominantly on the web or the cloud but do have local applications, which tend to be lightweight. They also rely upon a rich browser which can work with local data as well. So, would you consider these devices the clients in a client-server environment, as per the comparatively ancient terminology?

Given so much new choice, especially as developers, you need a way to play around with the various alternatives and understand their specialities and idiosyncrasies. In a corporate or educational environment, you may need to support and manage the variations.

It is good to re-look at some of the old and not so old solutions and see how they perform today. One of the ideas would be to explore if you could extend some of these solutions to incorporate desirable features of the new environments in the corporate and educational environments.

Running Linux from RAM

If you haven't tried Puppy Linux in a while, do try it. It is not that Puppy Linux is very different from what it was some years ago. It is that if you run it on a recent desktop, the user experience is remarkable. It is incredibly responsive.

Puppy Linux has packaged a limited set of applications, which are small in size. The default operation is that it runs from RAM. So, when you boot into Puppy Linux it seems to take a comparatively long time for such a compact distribution; however, this time is needed to copy and set up the root partition in RAM.

Base Puppy Linux consists of three files – vmlinuz, initrd.gz and a root squash file system (something like puppy_precise_5.4.3.sfs). You may copy the three files in, say, puppy subdirectory under /boot partition and add an entry in grub menu -

menuentry 'Puppy Linux'{
linux /boot/puppy/vmlinuz-puppy psubdir=boot/puppy
initrd /boot/puppy/initrd-puppy.gz

You may wish to experiment with booting from a server over the network. Since the puppy kernel does not come with nfs support, the easiest option is to create a new, larger initrd file by adding the sfs file in the initrd. You will need to suitably configure dhcpd, tftpd and html servers. The latter is important as booting using tftp is slow for large files and ipxe boot roms ( support a variety of options, including html. You may use ipxe.krn from, which includes all the supported drivers. The grub entry is simple -

menuentry “ipxe”{
kernel16 ipxe.krn

A comparison of booting times on the same hardware is as follows:

Ubuntu 12.10 from local disk 45 sec

Precise Puppy 5.4.3 from local disk almost 40 sec

Precise Puppy 5.4.3 using html over 100 Mbps net just over 1 min

Precise Puppy 5.4.3 using html over 1giga bit net 50 sec

Porteus – An alternate RAM resident distribution

Wikipedia has list of distributions which run from the RAM. Porteus seemed appealing. It evolved from Slax, which also runs from RAM and uses a KDE desktop. Porteus offers you an option of KDE and LXDE desktops. The newly released version 2 has an XFCE based alternative package as well. Another attraction of Porteus is that it includes the option to boot into Porteus using Pxelinux from a machine running Porteus. The version 2 is even easier as it has an initrd with the network drivers included; so no modification of initrd is needed for the client machines. You may adopt the scripts to use dhcpd and apache web server instead and boot into Porteus from a server running Fedora ( see for details), Ubuntu or any other distribution.

Proteus v2.0 KDE from local disk 35 sec

Proteus v2.0 LXDE from local disk under 20 sec

Proteus v2 KDE using html over 1 giga bit net 50 sec

Proteus v2 LXDE using html over 1 giga bit net 40 sec

Proteus v2 KDE using html over 100 MBPS net 70 sec

Proteus v2 LXDE using html over 100 MBPS net 55 sec

What is striking is that Proteus with LXDE desktop is booting from the local disk in half the time of Puppy Linux! Even KDE desktop boots in less time. The most likely reason could be the more recent kernel version used by Proteus. Puppy linux uses Linux kernel 3.2 for i386 while Porteus uses Linux kernel 3.7 and we chose the x86_64 architecture. Subtle differences in the Linux Live Kit scripts between the two might also make a difference.

I had not expected the network boot to add about 15 seconds to the boot time even on a giga bit network for distributions of the order of 200MB. Hopefully, with the renewed active development of ipxe, you may see significant improvements.