Monthly Columns
 

From Linux to FreeBSD

Copyright © 1999 Justin Hawkins

A long time ago I shunned the commercial operating systems and started using Free Unix-like systems almost exclusively. Like many people my starting point in this area was Linux. Specifically Slackware Linux.

I used it quite happily on my home machine as a desktop operating system and, more recently, as a server operating system, doing some web development and providing Samba and Email services to my other PC.

When I started working at a local ISP I gained more and more experience with Linux, which was repaid by me being able to move into more interesting departments in the job. However; the technical manager had a strong regard for FreeBSD and started installing it on new servers that we implemented. The installation alone was a marked improvement. The network install just works every-time, and doesn't require playing around with messy NFS mounts (we have a local FreeBSD mirror).

The performance was excellent and the stability could not be faulted. All the major problems we've had with our FreeBSD boxes could be attributed to hardware. To be fair, the Linux boxes were stable as well, but the FreeBSD machines seemed to cope much better under heavy duress.

Recently I setup a new backup machine which doubled as my workstation. Since it was going to be a workstation I was loathe to put FreeBSD on it at first. I still see Linux as having a few advantages on the desktop. The console is much nicer, and the latest desktop software usually appears on that platform first.

However due to the tape backup activities that this machine was to perform, FreeBSD was the only option. It regularly processes single cpio[1] files around the 10Gb mark, which Linux filesystem limits would make impossible. We also needed the concatenated disk capabilities to combine 4 17Gb IDE drives into one large backup partition. I realize Linux has this as well, and I'm unsure how it compares [2].

I shouldn't have worried about it's desktop capabilities though. KDE compiled with about 20 keystrokes (thanks to the wonderful ports collection) and I was up and running a few minutes later. Even setting up kdm was simple and makes it easy for some of the casual employees to share the machine should the need arise.

Also, the machine performs beautifully! At some times of the day I have more than 10 simultaneous gzip's running. I found I could not nice these processes, otherwise they would not finish on time. However even with them running, my netscape (in which I do most of my work) is still responsive (if not snappy).

Apart from the tapes and the disk space, the machine is fairly basic - an Intel Celeron 300 and 64Mb RAM.

Based on these pleasant experiences I decided to scrap my home Linux system and install FreeBSD on there as well. My home box was by then running RedHat 5.0, and I had come to loath the RPM package management system. It works admirably - when it works. When it doesn't work you have to begin bypassing the dependencies to install new software, making more problems along the way.

It was with not a little trepidation that I began this - I had invested not a small amount of time configuring the Linux system. I also had over 90 days of Linux uptime, which is always difficult to throw away :-)

But I went for it. I obtained a CD of 2.2.7 and installed it. It was a home grown CD that I made, and it had no binary packages on it. That was the way I wanted it - apart from the base OS I wanted to compile it all myself.

The reasons for this were simple. Firstly, the aesthetic one - it's nice to compile it yourself. The ports collection makes it nearly as easy to install new software as a binary packaging system, and you get the satisfaction of knowing it's compiled as you want it to be.

Which leads me to the second point. Often with RedHat Linux RPM files I would have to make changes. As an example, here in Australia we use A4 paper, not Letter. At the very best I would need to setup a config file to tell the software to use that paper format. At the worst I would need to specify an extra command line parameter every time I ran the program.

With ports I compile the program with the correct defaults - for me. Other common examples are changing defaults for where log or configuration files are kept, changing default hostnames, and so on.

Within a few hours (unfortunately I'm still using a 28.8K modem) I had compiled and installed all my essential software, Samba [3], Apache[4], Ghostscript[5] and of course vim[6]. I dropped my old config files in place and pretty much everything just worked.

My transition to FreeBSD has been slow, but always interesting. I'm constantly impressed at the 'togetherness' of the whole FreeBSD system. While I was used to the Linux filesystem layout the FreeBSD one seemed strange, but now it makes sense, and it's much more consistent and logical.

Lastly, let me say that I don't think all Linux users should go out and change immediately to FreeBSD. It's very much a individual choice. However if you are a Linux user without much FreeBSD experience, I urge you to give it a try, if you have the chance. Even just via a shell account. It's different, but that's not a bad thing. It's the difference that makes it interesting.


Justin Hawkins, jh@tardis.selkie.org


[1] cpio is (arguably) a better version of tar - probably better suited to system backups than general archiving. 'man cpio' for details. Back

[2] Since I wrote those words I have had more experience with concatenated disks on both Linux and FreeBSD. While I can't make any comparisons on general performance, I can say that fsck times on md devices in Linux is appalling. It takes hours and requires an operator present to start (and then restart) the fsck manually.

FreeBSD takes about 15 minutes to check my 70Gb (17Gb x 4 drives) array - and it never requires intervention. Back

[3] Samba allows your FreeBSD (or other Unix) box to participate in a Windows network, providing file serving, printing and other services. http://www.samba.org for more details. Back

[4] Apache is the worlds most popular web server - http://www.apache.org. Back

[5] Ghostscript is an interpreter for PostScript (tm). It can output in a variety of common printer formats. This turns your cheap printer into a fully PostScript (tm) compatible printer. Back

[6] VI iMproved. Adds many features to standard vi, including colour syntax highlighting for program code. Back