COMP 3000 2011 Drhill's Report: SalineOS 1.4

Background

SalineOS is a lightweight and fast open source operating system built on the Debian GNU/Linux repositories and uses Xfce as the desktop environment. The keyword here is fast. Saline still seems young, and its exciting to see how it will grow.

“The primary goal of the SalineOS project is to deliver a fast, lightweight, clean, easy to use and well documented operating system based on Debian GNU/Linux. “ <ref name = "About SalineOS">About SalineOS (Last accessed October 18, 2011).</ref>

Their tagline, which is in their website header, is “because speed and stability matter”.<ref name = "SalineOS Home">SalineOS Home (Last accessed October 18, 2011).</ref> And from a speed standpoint it is a pleasure to use. It is based on Debian Linux, and so has access to their well stocked repositories, as well as adding a few repositories that don’t fit into Debian’s strict free-software guidelines. Essentially they take Debian and make it “more complete out of the box”<ref name = "About SalineOS">About SalineOS (Last accessed October 18, 2011).</ref>, adding Wine repositories, as well as a script to install patent encumbered multimedia codecs, among other things.

You can obtain the .iso from their website, here, in the downloads section. It is roughly 931 mb in size.

They also have a server edition,<ref name = "Saline Server">Saline Server (last accessed Oct 19/2011)</ref> intended for use in a personal server, not really suited for large commercial servers. It lists its possible uses as a torrent seedbox, or an ftp filesystem, among many other uses. For the purposes of this report I will be focusing on the desktop (laptop) application.

Installation/Startup

SalineOS was installed in Oracle’s VirtualBox in a MacOSX environment. The virtual environment was set up with approximately 20 GB of hard drive space and 2GB of ram, of 4 GB available. I also did an install on my HP laptop.

Saline installing on VirtualBox

Saline itself is booted off of a live CD (or in this case a CD image). The live CD took less than a minute to boot up in this virtual environment. The install took just over 5 minutes. The install went well … mostly. I encountered one problem, which was something of a Garbage-in, Garbage-out problem. I tried to abort the install at one point by hitting cancel. I thought it had aborted, but there was simply a delay until the next window. In the meantime I had clicked on the install icon a few times as it was unresponsive (and I am impatient). I wound up with 3 separate installs running at once, none of which I was able to abort. Hitting cancel provides null or blank to the whatever the current question or input is and then continues the install. I had to shut down the virtual machine and start over. There was also another instance while installing on my laptop where my son mashed the keyboard and started a second install. In that particular case I let the second install hang and finished the first install and things worked out fine.

So typically things go quite smoothly, but if you are impatient or have kids or some other Murphy's law is at work, be wary during installation. I did manage to abort on one occasion, just before it wrote the boot sector on the hard drive. It asked if the information was correct; I clicked ‘no’ and it aborted the entire install without issue.

It is, of course, fairly easy to reboot and try again. Hopefully the future versions will have this sorted out.

One of the nice features of Saline right off the bat is the ability to make a boot-able USB stick using a graphic interface, Remastersys usb creator (which also has Backup and Grub Restore). Its very simple, and great if you want to try a bunch of different distributions. So I made a boot-able Saline stick in order to do a full install on my other laptop. However, upon booting up the live environment it was unable to detect my home network, or any of the dozen or so networks in my neighbourhood. I plugged in an RJ45 cable from my router and was able to access the internet that way. I researched and tried a few suggested solutions, but nothing would bring up any networks. From the forums this problem sounds quite common, and they may switch from Wicd to Gnome Network Manager in future versions.<ref name = "SalineOS Forums">SalineOS Forums (Last accessed October 18, 2011).</ref>

Some of the people on the forums had solved it, so I went ahead with the install anyway, and then downloaded network-manager-gnome from the repositories using Synaptic. However, that did not work either (and yes, the physical switch is turned on). So to this day I have no wireless. Some of the other people seem to have it licked, many by simply supplying “wlan0” as their default wireless connection, others by going with gnome network manager. Also it could be that my HP is having issues, as I also had no wireless in Fedora. (Things work great in Linux Mint, however.)

The VirtualBox on my mac supplied a virtual wired connection, so there was never a problem there.

Basic Operation

It runs the Xfce desktop environment, which is a lightweight desktop environment for UNIX-like operating systems. It aims to be fast and low on system resources, while still being visually appealing and user friendly.<ref name = "XFCE Desktop Environment">XFCE (Last accessed October 18, 2011).</ref>

Saline home screen

Since speed was the name of their game, I decided to test them out a bit. I used 3 different timers (from the Lab 2): I had a CPU timer, which did only CPU calculations and then output the time, I had a file timer (writing and then reading a file from the hard drive) that allowed the files to be buffered, and I had a file timer that flushed the buffers after every read and write. I tested 4 different Linux distributions, basically Saline against the 'big guns', all running in virtual machines with the same spec. Of the hardware only the CPU and hard drive are represented, but it is meant to give an idea how the distributions stack up speed-wise, and not meant to be gospel. The results were somewhat interesting:

	MacOSX(host)	SalineOS	Mint	Fedora	Ubuntu
CPU timer	7.69 sec	7.74 sec	10.94 sec	7.66 sec	7.05 sec
File timer (flush	17.17 sec	21.35 sec	47.70 sec	34 sec	29.51 sec
File timer (no flush)	1.92 sec	1.33 sec	2.41 sec	2-3 sec	1.31 sec

All the values are an average of three separate tests.

With respect to Fedora, something was not working with its internal timing (the first timer reported itself done in less than 1 second, while in reality it was closer to 7 seconds), so I timed it best as I could using an external clock. It lacks some of the accuracy, but I still think we get a fair sense of where it stands. Another note on Fedora, Gnome 3 was not working so it was in a fallback mode, which may have affected the results also.

The result? Saline does quite well against the competition, and gives the host a run for its money. Second only to the host OS, and only when you flush out the buffers. It is uncannily quick.

I can't account for the slowdown in Mint, except to say I ran the tests multiple times, making sure to minimize interference from other programs, and these are the (abysmal) values I got. (Though I still think Mint is a top distro and a lot of fun.)

I did the tests on my HP laptop (running Saline only) as well, but it was significantly slower across the board, almost certainly due to less powerful hardware. However, just in case anyone is interested:

CPU timer	18.02 sec
Filetimer (flush)	38.84 sec
Filetimer (no flush)	4.44 sec

With nothing to compare to it is more or less meaningless. And as much as I would love to sit through another 4 installs of various distributions, I think I will save that for another day.

Another issue I had was in trying to install Racket, which is a development environment for the Scheme programming language. I did a search in Synaptic, the package manager. It came back with three files interlinked for their dependencies. The install took over 10 minutes while “unpacking replacement racket-common”. I actually believed it frozen the first time, and killed Synaptic as it was completely unresponsive (which lead to issues with the lock not being released). I tried a few more times with the same result. I also tried apt-get install, which had the same result. I finally went to the Racket website and downloaded a version of Racket that had a shell script install, which installed in around a minute.

Ironically, in trying to recreate the problem in order to document it more completely, I let it run a bit longer and the install finished without incident. Still, the time seemed excessive for what was a 56 Mb program. Again, further research is needed to determine whether the bottleneck is occurring in the VM or Synaptic or somewhere else entirely.

I tried downloading other programs through Synaptic, and had one minor problem while downloading Eclipse. It was 237 Mb, took 4 minutes to download and then told me one of the files had failed to download, and asked if I wanted to install anyway. I said no. FileZilla, 1.2Mb, just under a minute using Synaptic. Bluefish, 11.9 Mb, 45 seconds. Kompozer 31.7 Mb, 50 seconds.

Chrome running in Mac. Note the fadeout on the bookmark bar. Fancy!!

Their desktop is attractive enough without being bogged down with lots of meaningless effects, which is keeping with their stated goals. I find Saline in general more responsive than MacOS, which surprised me. They choose their programs with the goals of speed and stability in mind, and stay well away from any effect or graphic or bloat that would slow it down. Mac generally chooses high quality programs and fancy graphic effects. I have also read that VirtualBox can make things glitchy for your home OS.

I opened many programs at random in both OS's, and found that Saline was difficult to bog down, and when it did it was only for a couple of seconds. MacOS wasn't that hard to bog down, though to be fair it tends to be a lot more responsive when VirtualBox is not running. Strictly my non-technical opinion, but Saline is definitively faster. Its responsive nearly all the time, and never needs time to “sit and ponder”.

Chrome running in Saline. Note the "..." on the bookmarks bar. Not as fancy, but works just fine

The default web browser is Chromium. I downloaded Chromium for the MacOS also in order to compare, but it was difficult to time precisely. They were within 10ths of a second of each other, with slowdowns coming at random, and likely through my ISP. There was no detectable difference in speed for browsing, but its difficult to tell for sure. Again the Saline Chromium looks like it sticks to serviceable graphics in order to keep with its minimalist, speedy paradism. For example, in the bookmarks bar, the Mac version has the title fading out as it approaches the edge (which is typical artsy Mac stuff), where on Saline it cuts the title off with '…'. They stay away from too many resource draining effects, and put their power into speed.

It comes with plenty of software, including Open Office, Remastersys, Parole media player, Xfburn, Fotoxx (for photos), and Rhythmbox, to name a few. You can download Iceweasel (which is a version of Firefox rebranded by Debian)<ref name = "Wikipedia">Wikipedia (Last accessed October 18, 2011).</ref> through Synaptic in place of Chromium if you wish. Also available on the forums under "Announcements" is Firefox 4 available for download.

Usage Evaluation

Overall, aside from a few issues (in particular the problems with wifi, which I was by no means alone in), I had a good impression of Saline. Overcoming their wireless problems is of course a must for future versions, and could help propel Saline into the mainstream. In particular if you like your Linux quick and responsive, this is the OS to keep in mind. I found it impressive that it was running in a virtual environment and was still noticeably crisp.

I also appreciate how they spruce up their Debian package, with stuff that, realistically, 95% of the people are going to install later. It saves time and hassle on the user end, and if you don't want it, it is all optional. The codecs are nice too. They are quite explicit in informing you in the user guide that you should have a legal right to them before you install them. And since one of my greatest pleasures in life is to religiously abide by codec patent and copyright laws, I made sure to click 'no' when consulted about them. I can't watch any videos on my Saline distribution, but I can look at myself in the mirror, even if its not quite as much fun.

References

<references/>

Part 2

Initialization

Saline 1.4 uses the bootloader GNU GRUB version 1.98+20100804-14. This gives you the option of running normal mode or recovery mode. Also you can pop into a command line, or edit the boot commands.

GRUB first loads the kernel as a compressed executable<ref name = "Novell">Booting with Initial Ram Disk in SUSE Linux (Last accessed Nov 10, 2011).</ref>,

linux /boot/vmlinuz-2.6.32-5-amd64

then loads the ramdisk that contains the drivers necessary to find and mount the filesystem,

initrd /boot/initrd.img-2.6.32-5-amd64

It then runs linuxrc, (a binary in the ramdisk) or initramfs <ref name = "DebianWikiramfs">Debian Wiki initramfs</ref> which are responsible for loading the device drivers and mounting the filesystem. After mounting the filesystem, it umounts the initrd, freeing the RAM, and runs init, which spawns every other process on the system. It looks in /etc/inittab for configuration settings. It then runs through the run-levels, running the scripts in the rc<number>.d directories, with <number> corresponding to runlevel. The Debian system (on which Saline is based) starts in runlevel 2<ref name = "DebianWiki">Debian Wiki boot Process</ref>.

Runlevels

There are 8 runlevels by default.

Runlevel S (reserved)

The boot runlevel, runs in single-user mode, afterwards automatically enters a multi-user runlevel

Runlevel 0 (reserved)

Used to shut down the system. It runs the scripts in the rc0.d directory.

Runlevel 1 (reserved)

Single-user mode

Runlevel 6 (reserved)

Used for rebooting the system

Runlevels 2-5

Multi-user mode runlevels

Concurrent Booting

It actually uses a concurrent boot process, which is now standard on Debian systems. The line at boot-up reads:

Using makefile-style concurrent boot in runlevel S

When they originally went to concurrent boot, they had a CONCURRENCY option in the /etc/default/rcS file, which is a configuration file for /etc/rcS.d scripts, which are symbolic links for the /etc/init.d directory. So if things went wrong you could disable concurrency. They have since taken that out, and concurrent booting is now the norm.

Part 2 References

<references/>