COMP 3000 2011 Drhill's Report: SalineOS 1.4

From Soma-notes
Revision as of 07:54, 24 November 2011 by Drhill (talk | contribs) (→‎References)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Part 1

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)SalineOSMintFedora Ubuntu
CPU timer7.69 sec7.74 sec10.94 sec7.66 sec7.05 sec
File timer (flush17.17 sec21.35 sec47.70 sec34 sec29.51 sec
File timer (no flush)1.92 sec1.33 sec2.41 sec2-3 sec1.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 timer18.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

Bootchart

As you can see to the right, there is a utility, Bootchart, that records and times the boot process, then prints it off in a graph. It can be used to try and pare down boot time, or just to see what runs. It also shows what process spawns what process, giving at least some of the dependencies (though undoubtedly there are other dependencies, eg a web browser depends on the network connections, but network connections don't spawn web browsers).

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, while at the same time telling the kernel where in memory it is located.

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

It then runs initramfs <ref name = "DebianWikiinitrd">Debian Wiki initrd</ref> which is 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. These lines specifically:

id:2:initdefault:

si::sysinit:/etc/init.d/rcS

l2:2:wait:/etc/init.d/rc 2

which run the scripts in the /etc/init.d/rcS directory (runlevel S), then the scripts for requested runlevels.<ref name = "DebianWikiinit">Debian Wiki init</ref> 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.

Software Packaging

Saline uses the Debian dpkg. You can list installed packages with dpkg -l. Adding or removing packages uses Synaptic (recommended). It also has Aptitude installed (though not really advertised), which is a little less user friendly, but has more functionality in terms of removing old package dependencies when you remove a package. Both are front ends for the APT (Advanced Packaging Tool).

APT can be functionally considered a front-end to dpkg. While dpkg performs actions on individual packages, apt tools manage relations (especially dependencies) between them, as well as sourcing and management of higher-level versioning decisions (release tracking and version pinning). <ref name = "APT">Wiki APT</ref> Apt-get (APT command) will call dpkg directly after downloading the .deb archive. So dpkg is the muscle, while apt is the brains.

There is an AutoUpdate function in the top panel, which runs and displays output from Aptitude.

The bottom panel has Synaptic, which is listed in the manual as the recommended way to install or remove packages. It handles standard .deb binaries.

Sometimes packages are only available on a website, not a repository. For these use the Debian release, and not the .deb intended for Ubuntu. For this purpose, GDebi is used, which attempts to install using dependencies. It will automatically run when you click on the downloaded package. I've installed a couple of things this way, and had no problems.

You can load from the command line using saline-get (saline-get install <package name>). It is a wrapper for aptitude.

Saline 1.x is compatible with all software packages for Debian 6.0 "Squeeze"

Updates and New Versions

The AutoUpdate button on the top panel will install security updates and new versions of select programs from Debian's official back-ports repository. It should be used as the sole method of updating the operating system and should be run at least once every 30 days.

Major versions are only released close to the release of a new Debian stable release. A script to upgrade will be available at www.salineos.com, but the recommended way to install is backing up your data and installing a fresh version from the iso.<ref name ="SalineUserManual">Saline User Manual </ref>

Major Package Versions


Package NameSaline VersionCurrent Version*Function
Kernel2.6.323.0.8Linux kernel
Xfce Xfce 4.6.2 Xfce 4.8 Desktop environment
Libc2.11.2 2.14 C runtime library
Bash4.1.5 4.2 shell
Dpkg1.15.8.10 1.15.8.11 Packaging system
X.org7.5 7.6Open source implementation of the X window system
Wicd****1.7.0 same Wired and wireless network manager
Chromium6.0.472.63 15.0.874.120(stable) Open source web browser
Ice Dove 3.0.11 3.1.15-1Mail client (repackaged version of Thunderbird)
Open Office**3.2.13.3.0Office suite
Osmo 0.4.0 0.2.10*** Personal organizer
Parole 0.2.0.2 0.2.0.6 Media player
RythmBox 0.12.8 0.13.3 iTunes inspired music player
Synaptic 0.70 0.75.3 Package manager
Terminal 0.4.5 0.4.8 Xfce Terminal Emulator - Command line


      *Current as of 11/11/11
    **Saline 1.5 now uses LibreOffice
  ***Not a mistake. Changelogs and/or websites not up to date.
****Saline 1.5 now uses NetworkManager

Saline uses Linux kernel 2.6.32, which dates back to Dec 3, 2009, and is the kernel of Debian "Squeeze". The current kernel is 3.0.8. Debian Sid (unstable) uses linux kernel 3.0.0, which presumably will be in the next major release of Saline.

Ps is version 3.2.8 and ls is version 8.5. Both of these are the versions found in Debian "Squeeze".

Xfce is version 4.6.2, which is the same version as Debian "Squeeze". Debian runs Gnome by default, but you may choose and run Xfce version 4.6.2 if you wish. Debian uses Xfce 4.8 in the current version ("Wheezy"), so presumably the next major Saline version will be running that as well. The GUI uses gtk+(v 2.20.1, current version is 3.2).

Saline explicitly preloads the bottom panel with software, as opposed to the usual drop down menu (or drop up) of many other Linux distros. I've included some of them in the above list, as the developers clearly attached some significance to them.

Osmo, Chromium, Parole, and Fotoxx tout themselves as lightweight and/or fast (which is the Saline philosophy), and are included as part of Xfce, which is both the desktop and the additional package Xfce goodies. Other packages are fairly consistently part of the Debian architecture. Saline runs on top of Debian, and they don't stray too far, as evidenced by being solely compatible with Debian packages. Debian is known for their strict adherence to Unix and free-software philosophies.<ref name = "Debianwiki">Debian Wiki</ref> Saline not so much. They take a looser view, including Wine repositories and other repositories, but are still mainly dependent on Debian flavoured free software.

So the majority of their system remains tied to the current Debian distribution, and the software that they run and rely on, as well as the software tied to the Xfce desktop environment. They have made some minor changes, mainly cosmetic or of convenience, but there is no major rewiring of the Debian or Xfce environments, as you might find in, say, Ubuntu.

Part 2 References

<references/>