...making Linux just a little more fun!

FreeBSD - An Intro for Linux Devotees

By Henry Grebler

Disclaimers

Let's get the disclaimers out of the way quickly.

These are my impressions. I do not have a special pipeline to FreeBSD gurus.

I started using FreeBSD in January 2010, a bit more than a year ago. I was not a total stranger to FreeBSD, having done a little on it a few years earlier. But I have not used FreeBSD anywhere near as long as I've used Linux.

A Little History (Very Little)

There are 3 main BSDs and a handful of minor variations. The main ones are FreeBSD, OpenBSD, NetBSD. I can't tell you how they differ. Possibly, they are the analogues of Red Hat, Debian and SUSE. Of the 3, FreeBSD has the lion's share of users.

NetBSD and FreeBSD began with the same initial code base around 1993. OpenBSD is a later fork from NetBSD. To varying degrees, code from FreeBSD's precursor is used in Microsoft Windows, Darwin (Mac OS X), Solaris.

Look and Feel

What does it feel like to use FreeBSD on a daily basis? The short answer is that it's a lot like Linux. Or any other Unix, for that matter.

Readers of Linux Gazette may be aware of my HAL (Henry Abstraction Layer); that I use HAL to hide the differences between different platforms. But, in fact, I needed to make very few changes to my HAL to adapt to FreeBSD.

Linux users might notice that some of the standard commands don't have exactly the same options. FreeBSD ls is not GNU ls. For instance, they have conflicting interpretations of the "-T" option. In FreeBSD, "-T" produces complete time information, but not as detailed as "--full-time".

However, FreeBSD includes GNU ls as gls (/usr/local/bin/gls).

Further, if you really want something Linux, FreeBSD includes Linux binary compatibility which "allows FreeBSD users to run about 90% of all Linux applications without modification" (https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu.html).

So on top of gls, you can also get /usr/compat/linux/bin/ls. (That's 3 versions of ls for the price of 1!)

What's the difference?

$ /usr/compat/linux/bin/ls --version
ls (GNU coreutils) 6.12
Copyright (C) 2008 Free Software Foundation, Inc.
...

$ gls --version
ls (GNU coreutils) 7.5
Copyright (C) 2009 Free Software Foundation, Inc.
...

That's probably more than you ever wanted to know about ls (or any other command).

As a last resort, if you have a Linux program, you can try to run it under FreeBSD. There's a good chance that it will just work. And it's not an emulation. It runs at pretty much native speed.

Differences I've noticed

FreeBSD comes without bash. But, in fairness, on FreeBSD /bin/sh is vastly more than Bourne shell. But it's not bash.

Standard stuff that comes with FreeBSD can be found in /bin and /usr/bin. Alien software usually goes into /usr/local/bin. You can install bash and it will wind up in /usr/local/bin. Most of my scripts are Bourne shell; their first line consists of:

    #! /bin/sh

However, I do have a few bash scripts; these tend to have a first line:

    #! /bin/bash

I guess I could have found another solution, but it seemed simplest to make /bin/bash a symlink to /usr/local/bin. Some people might raise their eyebrows at this, but my system, my rules.

su is a bit different. FreeBSD has truss (similar to Solaris) rather than strace.

The Good

The sheer number of packages. FreeBSD has an astonishing number of packages. Looking at my system, I estimate over 22,000 (available packages - I haven't installed them all!). This number probably overestimates because some of these are to do with different languages (arabic, chinese, french, german, hebrew, hungarian, japanese, polish, portuguese, russian, ukrainian, vietnamese). But even without the languages, there were more than 21,800 packages.

I may not be interested in any of these languages since I am most comfortable in English. But I suspect that there are a lot of people in the world who would be quite grateful to be able to use their native tongue. This sort of thing only becomes an issue when one's preferred language is omitted.

There is heaps of documentation (are heaps?). And the documentation is pretty good.

I like the idea that there is a Master of the FreeBSD Universe. Consequently, no one can change a standard or the framework. But, individually, a user can still make any conceivable modification - because, ultimately, you are encouraged to build anything and everything for yourself.

The result is that you never get dynamic library conflicts. (I did once - it's a long story and an unusual scenario).

There is an overwhelming sense of quality, an expectation that things will just work. Whenever something didn't work for me, I assumed that it was simply a matter of my ignorance. Although this is usually a safe bet, it nonetheless speaks volumes about the quality of FreeBSD.

There are some exceptions at the margins.

The Bad

Here is something I noticed on the Internet:

        "... being a long time Linux person, I'm sad to say that
        FreeBSD ports/packages is really confusing to me."

I agree. I finally have a handle on packages. I'm still confused about ports. I'd like some tutorials or HowTos on how one is meant to manage ports. There is a plethora of similarly named tools. Which one(s) should I use? What's best practice?

At its simplest, packages are, or more specifically, pkg_add is, a lot like an inferior yum. It's like "yum install" without "yum list": it takes care of the installation, but it's an act of faith as to how much will be downloaded. Until recently, this was an ISP issue for me. It's still an issue for another reason. If I install openoffice blindly, I might end up filling a disk. "yum list" gives me some idea of what's involved *before* I commit.

There's another annoyance. Let's say you want to run Firefox. Of course you do. No problems. You can't go to the Firefox website and simply download the latest Firefox. The choices there are "Windows, Mac OS X, Linux" in many languages. Instead, you download it as a package. It's a big download, but, like yum, pkg_add takes care of dependencies.

Good, your happy. Your Firefox works like a bought one, straight out of the box. Until you go to, say, YouTube. Or any site that needs extensions. Let me be a little more precise: until you need some sort of plugin that executes proprietary binary code. Who makes Flash? Adobe. Is the source freely available? No, sir. Clearly a solution is needed. The solution is rather convoluted:

(From https://www.freebsd.org/doc/handbook/desktop-browsers.html)

6.2.3 Firefox and Macromedia® Flash Plugin

Macromedia® Flash plugin is not available for FreeBSD. However, a
software layer (wrapper) for running the Linux version of the plugin
exists. This wrapper also supports Adobe® Acrobat® plugin,
RealPlayer® plugin and more.

Now before you start laughing, let me say that I encountered a similar problem when I ran a 64-bit version of Firefox on CentOS at work (on a 64-bit machine). The Firefox works, but I couldn't get any plugins to work because there was no 64-bit Flash plugin. I don't understand why it couldn't run a 32-bit plugin, but there it is.

At least I have been able to get Flash working under FreeBSD. I can see video and hear audio. It was a complicated install, but now it's done.

The Indifferent

Don't expect FreeBSD to be like Microsoft Windows or even Ubuntu. You are expected to know what you are doing. If you don't, you can ask for help. But you will not be mollycoddled the way Microsoft or Apple do it. Personally, this is how I prefer it. I like my platforms a little user-antagonistic.

By default, FreeBSD uses ufs which is not at all like ext2 or ext3. And it talks of slices rather than partitions. So to install FreeBSD, you use something (eg fdisk) to partition the disk. Whichever partition you allocate to FreeBSD, it will slice up that partition into several bits. So, for example, I allocated partition 3 of the second drive (/dev/ad1s3) to FreeBSD:

    Device Boot    Start       End    Blocks   Id  System
/dev/ad1s3   *     10608     25846   7680456   a5  FreeBSD

(I've omitted the other partitions).

Here's the relevant bits of a df:

Filesystem                         Size     Used    Avail Capacity Mounted
/dev/ad1s3a                        372M     268M      74M  78% /
/dev/ad1s3e                        310M     117M     168M  41% /tmp
/dev/ad1s3f                        4.9G     3.5G     1.0G  78% /usr
/dev/ad1s3d                        558M      51M     462M  10% /var

FreeBSD uses the term "slice". It has taken the partition I gave it (/dev/ad1s3) and sliced it up (/dev/ad1s3a, /dev/ad1s3b, etc).

But the good news is that FreeBSD understands ext2. So, when I ran out of room in my FreeBSD partition, I simply mounted some Linux partitions. Further, FreeBSD not only understands NFS, I think it wrote the original book on it. So I am able to run both my Linux machine and my FreeBSD machine and mount drives from either on the other and just be on whichever machine without being too conscious of any differences.

I don't know the relative merits of ufs and ext2. It also looks like FreeBSD understands all of ext2/ext3/ext4. I wonder why I'm using ext2 and not ext3.

Why did I choose FreeBSD?

Good question. Difficult question.

I was trying to solve a problem. Maybe several problems.

My first problem is that I run an idiosyncratic environment. Why?

Imagine you have a car. I guess that's not a difficult exercise for most people. Let's accept, for the purposes of this exercise, that you are not a rev-head. You are not particularly interested in cars per se. You're a lot like my wife: you want to get into your car and drive to your destination. The only choice you want is the colour of the Duco.

So, after a while it's time to replace your car. But the latest model cars don't have the same controls as your previous car had. Steering wheel? No, we don't have one of them any more. We've got this new gadget. You sit on it; and when you want to steer, you sort of wriggle around. Sounds odd, but you'll soon get used to it. It's not actually better than a steering wheel, but it's the latest must-have. Everybody wants one. They were all getting bored with steering wheels. Brakes? Yes, we have a new way of stopping. We stick a gizmo in your ear and ...

That's what new releases of distros feel like to me. I went to "upgrade" from Fedora 5 to 10. I had had no problems going from 2 to 5. But 10 was another matter altogether. Just out of the blue, the names of disks changed. My Fedora 5 (which I'm still running) refers to /dev/hda. Fedora 10 decided to call it /dev/sda. Perhaps I'm naive, but I don't expect gratuitous changes like that from FreeBSD.

Every new rev of emacs introduces incompatible changes.

I don't turn on a computer so that I can learn new tricks. Not those sorts of new tricks. One of my computers has to be bread and butter, unchanging from day to day. I don't want to spend my time learning somebody's idea of a better editor. It's an editor! I just want the one I was using yesterday. Not better, not worse, not different. I DO NOT NOT NOT WANT ANY NEW FEATURES. If you want to do that, here's an idea: deliver emacs-classic and new-emacs. Put all your changes into new-emacs and leave emacs-classic as it is. Coke, anyone?

Every time they make it better, they make it worse. And that goes for Solitaire and aspell and ... the list goes on.

And these gratuitous changes come at a price. I used to run Slackware on a 16MB 100 Mhz Pentium 1. I was trying to install Fedora 10 on a spare machine and getting intermittent problems. After a while, they went away. It wasn't till much later that I twigged. I happened to notice in some documentation a declaration that Fedora would no longer run in 256MB; it needed a minimum of 512MB. While fiddling with my machine, I'd added some extra memory from another (dead) machine.

I decided I didn't like the notion of releases. Especially since Fedora is committed to producing a new release every year. That wouldn't be a disaster if there were any respect for backward compatibility. But there's not. There's the tacit assumption that the newest and latest will necessarily be the best. For everyone.

I asked around. Gentoo and Arch Linux were suggested as solutions to my problems. I was given to understand that they are more into the idea of just allowing the system to update organically. If you need a latter version of application X, just go get it. They had gone away from the idea of discrete releases. Sure, if you wanted to switch sects, you'd get the latest release. But you would not be penalised for running an old release. Maybe I misunderstood.

I tried Arch but found it difficult to get information. The idea is possibly ok, but I really felt isolated.

LG readers may be aware of my History files, records of what I do on the machines I administer. Here's a note from the day I installed FreeBSD:

	The documentation is excellent, by the way.

And that probably says it all. I dare say I encountered the same problems with FreeBSD that I did with Arch. But, with FreeBSD I was able to get answers.

I hope to find the source of a really old rev of emacs and build it. And keep it forever. Because rolling your own is encouraged with FreeBSD.

That's not to say I've abandoned Linux altogether. Recently I had power-supply problems with this machine. After I had replaced the power supply, the machine wouldn't boot. I tried running live FreeBSD off a CD, but could not get an environment which would allow me to examine the disks.

I booted a live Fedora and soon had things under control.

I've got KVM/QEMU working under FreeBSD. My next step might be to take my Fedora 5 machine and virtualise it. I've already got a virtual XP (which I've not returned to after proving I could do it), an Arch, a later rev of FreeBSD. And the first Linux I ever ran, a Slackware from 1995.

Some Random Observations

FreeBSD is comfortable with ext2/ext3/ext4 but my Fedora 10 was not as comfortable with ufs. When everything is running fine, these things may be much of a muchness. When it comes to recovery, be careful what you wish for. I could get access to some of my ufs slices from Fedora 10 - well, actually, only 1 - but not the rest. It's not normally a consideration, but perhaps it ought to be.

A similar argument could, perhaps, be applied to other less common or more refined file systems: Reiser, xfs, zfs, LVM. In fact, some time back, I had similar problems with LVM.

Summary

No platform is perfect. The best that I can hope for is a platform which is a reasonably good fit, particularly in the style in which it operates. I had come to the conclusion that Fedora was getting too concerned with look and feel and had consigned functionality to the status of second-class citizen.

I think FreeBSD provides me with a comfortable environment for keyboard, video, mouse and audio. For anything else, there are virtual machines.

References:

https://en.wikipedia.org/wiki/Bsd
https://en.wikipedia.org/wiki/FreeBSD


Share

Talkback: Discuss this article with The Answer Gang


[BIO]

Henry has spent his days working with computers, mostly for computer manufacturers or software developers. His early computer experience includes relics such as punch cards, paper tape and mag tape. It is his darkest secret that he has been paid to do the sorts of things he would have paid money to be allowed to do. Just don't tell any of his employers.

He has used Linux as his personal home desktop since the family got its first PC in 1996. Back then, when the family shared the one PC, it was a dual-boot Windows/Slackware setup. Now that each member has his/her own computer, Henry somehow survives in a purely Linux world.

He lives in a suburb of Melbourne, Australia.


Copyright © 2011, Henry Grebler. Released under the Open Publication License unless otherwise noted in the body of the article.

Published in Issue 186 of Linux Gazette, June 2011

Tux