FreeBSD – from the Linux user’s perspective (introduction)

With this (and the next) post we’re going to take a look at FreeBSD, assuming some basic Linux experience. The goal is to provide an easy introduction and to show where that system behaves differently from Linux. And we’ll also touch the subject of strengths and weaknesses of FreeBSD.

What is FreeBSD?

Linux is a Unix-like Operating system and the same is true for FreeBSD. The difference is that FreeBSD is a direct offspring of BSD-Unix whereas Linux was coded from scratch and did never have any code in common with Unix. So compared with Linux, FreeBSD is clearly “more Unix”. But why don’t we just say that it IS a Unix since it once was? Because of legal trouble…

Technically, FreeBSD is a much improved BSD-Unix. But there’s one problem: UNIX is a trademark. In order to call your system a Unix, it must comply with the Unix specifications. FreeBSD did this and probably still does for the largest part. That’s just the first requirement, though! The other is that you need to have your OS certified – which is not exactly a cheap thing to do. IBM did this for AIX, HP for HP-UX, etc. FreeBSD, being a non-commercial community project, needs the money it receives from donations for other things. And so – for legal reasons – FreeBSD is not a Unix but just a “Unix-like” system.

However it has come from Unix and it feels like Unix (with quite some things a little different from Linux). So if you don’t like the stiff term “Unix-like” you can of course think of your FreeBSD as a Unix system in contrast to Linux.

FreeBSD’s goal as stated by the project, is to provide a general purpose, secure and highly scalable operating system that is available free of charge. Sounds a lot like Linux so far, doesn’t it? Yeah, it does. But please keep in mind that this doesn’t make FreeBSD the boring rip-off. FreeBSD was there first! But even if you’d argue that it’s obsolete, now that Linux does extremely well in just about all areas (and admittedly better in quite some), there’s one more point. FreeBSD is meant to be available free of charge and under a permissive license!

Linux is GPL’ed. That makes it available for free and ensures that the code will always be open, because the license enforces these things. FreeBSD, licensed under the BSD license, does not do this. You are free to do things with it which the GPL does not allow. A whole lot of people don’t care (they have probably never even thought about licensing) and quite some people applaud the GPL’s approach. Others however prefer BSD-style licenses. It’s a matter of taste and a philosophic question that cannot really be decided once and for all.

I’ve written a short post on an introduction to licenses more than a year ago. It was meant to have a follow-up article but I didn’t find the time to write that one, yet.

System structure

The whole operating system is integrally connected. Where a Linux distro is actually “the Linux kernel plus (a lot of) packages”, FreeBSD is different. Programs from upstream are imported into the system repository and often patched. The versions are chosen to play together nicely with all the other components of the system.

This operating system consists of two parts: kernel and world, the latter being the userspace part of it. The actual software you install on top of the OS is separated from it: Files are put into /usr/local so they don’t mix with those that belong to the base system – which is quite a clean thing.

Traditionally FreeBSD has come with the ports system. If you want to install an application which is not part of the OS, you change into the respective directory of the ports tree and run make install clean. The Makefiles (and a few other files as well) then take care that the source code is downloaded, extracted and configured, that patches are applied, the program is compiled and installed. You do not need to know anything about how to get a program to work on FreeBSD. If somebody already wrote a port, it’s as easy as issuing that make command. The port will also ensure that any dependencies needed are present on the system and, in case any is missing, they are automatically built and installed by the ports system, too.

But that’s not all. Ports for many programs are created to allow you to select which features to compile a program with. A simple menu-driven UI let’s you check and uncheck features for each port. And of course it allows for clean removal of installed software using make deinstall. Also the ports tree often offers you various versions of a program to choose from. Want Apache 2.4 or probably rather 2.2? Or perhaps you need gcc. Feel free to choose any of 4.6, 4.7, 4.8, 4.9 and 5.1!

This allows for easy customizing of the software you install: You get exactly what you need and want. If you have no special needs for some programs and don’t want to compile it on your computer, you can of course use pre-built binary packages like on Linux. And the best thing: Since the ports system actually builds packages, you can mix the two as they play together nicely and won’t conflict!

Some strong points

FreeBSD has a world-class network stack – which is absolutely no wonder since TCP/IP was in fact developed on BSD Unix! This is one example where FreeBSD is superior to Linux.

Another nice feature are the so-called secure levels together with the extended file flags. The later open up some interesting possibilities: You could, for example, set the file flag “append only” on a log file. The log is not “read only” – it can be written to. So new log entries can be appended to the file. But it is impossible to either delete the file or remove content that’s already in it! If an attacker (who does not want you to notice that he broke into your system) tries to cover his tracks this can be extremely frustrating as there is no way he can get rid of anything that’s in the log!

That is… As long as he doesn’t just remove the file flag. But to make that impossible as well, FreeBSD has secure levels. You can always add file flags. But you can only remove them when the system is in secure level 0. And here’s the show-stopper: Once set to higher than 0 secure levels cannot be reduced. Not even by root and not even by yourself with physical access to your server! There’s exactly one way to get rid of a secure level greater than 0: Reboot… And a reboot won’t go unnoticed easily, right?

One more very cool feature are jails. Think of them as hardened chroot environments with a lot of extras (like IP addresses for a jail). They are kept strictly separate from the rest of the system (and from other jails). You have heard about all that “container” stuff that’s currently en vogue in Linux, haven’t you? No need for that on FreeBSD! If you want a secure environment (or several) for single applications – just jail them. FreeBSD offers this possibility for ages now (but to be fair I should mention that they were available on Solaris (where they are called “zones” even earlier).

And perhaps you have heard good things about the ZFS filesystem or about DTRACE. FreeBSD comes with both of them and they are considered stable. And of course there’s much more to it. But let’s leave that for the next post where we’ll get our hands on FreeBSD, right?

For those of you who are interested, here’s a little Unix history (it’s good to know because it helps understand why things are how they are today – but if you don’t care at all you can of course skip it).

Unix history

In 1964 AT&T, GE (General Electric) and the MIT (Massachusetts Institute of Technology) teamed up to create a sophisticated new operating system they called Multics. It was extremely innovative and pioneered many features in computing. A lot of people thought however that it was overly complex and not quite the system they wanted.

Eventually AT&T pulled out of the project and started another one in 1969 which followed the converse idea: Simplicity over complexity! This operating system is known as “research Unix”. In the following years various versions were completed and licensed especially to universities for little money (because AT&T was not allowed to compete on the software market at that time due to their telephone monopoly). During that time it was a matter of course that you got the source code when you bought software. For that reason students of computer science could look at the code – and modify it.

Coded in assembler first, it was soon re-written in the new programming language C which forever remains closely tied to Unix. Thanks to the availability of the code, the universities kept producing patches with new functionality for Unix and gave it away for free to anybody who had licensed the base product (Unix). At the center of this development was Berkeley University which collected these patches and patch sets. They created new Unix releases from those which were called “Berkeley System Distribution” or BSD for short. The first one was 1BSD in 1978 which was based on AT&T’s Unix Sixth Edition from 1975.

The university created the major releases 2BSD, 3BSD and 4BSD over the years. These grew in popularity fast and quite often Unix from AT&T was bought and put aside only to be able to actually use BSD legally! In 1986 4.3BSD was released (based on Unix System V from 1983). The year 1992 saw the release of a short-lived project which nevertheless had a huge impact: 386BSD or Jolix (named after its creators, Lynne Jolitz and William Jolitz). It was an effort to port 4.3BSD to the 80386 PC.

Now the BSD story repeated in a smaller scale: 386BSD enthusiasts created patches for the system and an unofficial patchkit was provided from it. Due to a difference in opinion the patchkit maintainers broke away from 386BSD and founded the FreeBSD project. About the same time another group of 386BSD users started they own project derived from that 386BSD: NetBSD was born.

The original BSD project ended in 1994 with a strange last release called 4.4BSD-lite. It was a crippled release that could not even run on its own! The reason was a lawsuit from the Unix System Laboratories. Formed after AT&T’s forced break-up, they finally could compete on the PC market and began to offer Unix for high prices. It goes without saying that the existence of BSD was a thorn in their side – and they meant to remove it!

But greed is not a good advisor and in the end the case was settled out of court. Why? Because the university proved that over the years almost all of AT&T’s code had been replaced. BSD was almost a system completely of its own! But that’s not all. In fact AT&T had taken the free code from BSD and used it in their newer Unix releases. While there’s nothing wrong with that, they didn’t give the BSD credit for their work. And by failing to do that it turned out that they were violating the BSD licence themselves!

It is the legal struggle and uncertainty that followed from the case which can be seen as one reason why Linux gained more and more attention: If you chose any BSD derivative you never know what might happen some day…

What’s next?

Next in line is a FreeBSD tutorial that puts focus on getting the system installed and exploring what’s different from Linux.

Advertisements

Taking a look at ArchHurd

Just as promised, this post will deal with ArchHurd a project aiming to bring what makes ArchLinux great to another kernel: GNUMach/GNUHurd.

edit: Sorry for making this long finished article public so late (same for the next one)… WordPress was giving me a hard time with my screenshots for some reason. But now I got things fixed.

Booting the live CD

So… Let’s take a look at the ArchHurd, shall we? However… Things are a bit.. messy right now. Let me make that absolutely clear before you might decide to give it a try, too. Don’t expect everything simply work like a charm. It won’t.

First it’s necessary to get the iso from the project’s download page. Don’t try to open the Installation Guide which the page links to. It points to the old wiki – which is gone. There are plans to re-add the old pages in the new wiki but this has not happened, yet. Fortunately there’s the Internet Archive which has archived the old wiki so that we can still access it here.

The bootloader: It has written “experimental” all over it.

The iso boots in a new VM set up for it. Despite the “hit ‘e’ and edit hd2 …” stuff things work if you have a standard VB configuration – and you wouldn’t be trying out ArchHurd on real hardware, would you?!

Booting the GNUMach micro-kernel.

Just be patient while the kernel probes the hardware – the rather old version which is used in ArchHurd contains a few glitches which make it take a long time to complete when used with Virtual Box.

Login – it’s not done automatically, yet.

Installing

Alright! ArchHurd has started up and we can move on to installing it. Just one more warning: There’s some kind of error in the kernel which makes the system freeze if doing nothing for a while. So keep it busy or pause your VM if you don’t want to reboot often!

Package selection in the installer.

I won’t cover the installation here – just follow the Installation Guide. The installation program is quite self-explanatory and the guide covers the rest you might need to know.

System configuration in the installer.

If you’re a long-time Archer, you’ll remember the “Arch Installation Framework”. If not, you’ll find out ArchHurd is also an OS without systemd and you have to take a look at rc.conf, the central configuration file which Arch Linux was famous for in the past.

ArchHurd!

After installing the bootloader according to the guide, we’re left with a working system. And after setting up network, it’s even actually usable. 😉 However the first time trying to update the repos, pacman crashed for me, so I had to remove the lock and try again. But from that moment on, network works fine. If you’re having trouble, selecting an older network card to emulate in VirtualBox (like PCnet-FAST III) might help with the Hurd.

Now let’s see how many new packages have been uploaded to the repos since the creation of the (now rather old live cd)!

Update the system?

Right, 31 packages is not really much… Especially if you’re used to ArchLinux’s rate of updating! So it might be a good idea to edit /etc/pacman.conf and uncomment the “testing” repo.

Updating with “testing” repo enabled

That’s not really up to date either, but at least a little more up to date. Ok, all nice and well… It’s a funny system – a little slow perhaps, rather old and pretty unstable. But what now? That just can’t be all.

Xorg running on ArchHurd

Of course not. X11 anyone? Yes, it does actually work. However I failed to get mouse support working in VirtualBox. If the xf86 driver for it is installed, Xorg won’t start anymore. Since I’m not an X guru, this is where I stopped and that’s also why I skipped showing you that ArchHurd is capable of running Openbox, too (which does in fact work – but is quite useless without a mouse…).

Anything else? Yes, a lot. The Arch Build System is working which means that you could build your own packages if you’re missing anything (which is rather likely ;)). That is: If you are lucky and the package will just work on Hurd – and if not you need some deeper knowledge about porting things over.

Building a package on ArchHurd

As an example I tried to build FLTK – and that proved to be one of the packages that simply worked. However I had trouble building with an ordinary user. The problem is known among ArchHurd developers and it’s not happening if you’re building as root (appending –asroot so that makepkg accepts this). I know that this is usually considered bad practice and should never be used on a productive system. But we’re playing around with the Hurd here, aren’t we?

Alright. This concludes our little examination of ArchHurd. If you liked what you just saw and are feeling brave enough – why not help the project a little? While it’s officially being worked on, it would certainly be nice if some visible progress was to be achived.

What’s next?

Next I intend to take a look at ArchBSD. Edit: You can count on it. I’ll do a little revision of the article and then set it to “public” in a few days.

BSD, HURD and Arch?

Today we’ll deal with Arch Linux’s principles transferred to other operating systems.

The Arch Way

Arch Linux’s slogan is: A simple, lightweight distribution. There are many people who want an operating system which truly fits their needs – and nothing else. Arch is usually a good choice for them due to its light-weight core system which can easily be expanded in any direction needed.


The Arch Linux logo

Sure, there are quite some other distribution worth considering. Gentoo, of course, which allows for even deeper customization thanks to its mighty USE-flag and portage system! But many people prefer to go without the hassle of compiling everything. This is often when Arch Linux comes in as it provides binary packages. If it has to be even more lightweight, there are a few distributions which are really fairly minimal. Alpine Linux is very interesting in this regard and some others like Damn Small Linux and Puppy come to mind.

In most cases though, Arch Linux is a very good choice. And that shows: This distribution has attracted many users over the years and is in the top 10 of the distrowatch rating. Why that? Probably because people like The Arch Way of putting together a distro.

Other Distros

Apart from classic Arch Linux there are some other Arch-based distribution. For example there’s ArchBang which combines Arch Linux with the OpenBox WM to provide a light-weight desktop upon installation.


The ArchBang logo

Then there’s Manjaro Linux, an Arch-based distribution which provides graphical tools for everything and aims to be beginner-friendly.


The Parabola logo

Others are Parabola, a distro using the fully free Linux-libre kernel, Arch Linux for ARM and ConnochaetOS, a fully free system that supports the i586 architecture.

If you’re interested in more of them, here‘s a list on the Arch Linux wiki.

Other kernels

Actually people seem to like The Arch Way so much that they miss it even when working with a system which is not Linux-based. For that reason some projects have arisen which kind of copy the Arch principles over to other systems!

There are for example ArchHurd and ArchBSD.

ArchHurd

The former is not exactly a new project – it was founded in early 2010. It made a lot of progress in a short time but seemed to have stalled by the end of 2011. There’s no news item on the project site after August of that year and while still new packages were created that also came to a halt about one year later. In the meantime even the wiki had disappeared.


The ArchHurd logo

Fortunately the project isn’t dead and after a while during which it only lived on in mailing list posts, at least the wiki is back again (which actually was the cause that made me write the previous and this post after I discovered it). Currently progress is still very slow which is due to problems with updating glibc. After the new toolchain is built the whole core repository needs to be rebuilt. So there’s enough work to be done there.

The new wiki has a severe spam problem right now. But I’m sure that can be taken care of sooner or later. And the most important thing is surely that the project is still alive!

ArchBSD

The other project is still very new. While the idea exited for a while, the site for it was put up in January 2013. ArchBSD is progressing nicely and considering the short time it exists, it already got pretty far in bringing the familiar Arch feeling to an OS using the FreeBSD kernel!


The Arch BSD logo

Right now it’s far to early to say whether this blend is to survive on the long run or not. Currently it looks good with quite some development taking place. And compared to ArchHurd it also has much newer packages in general (which however is no wonder since it started with later ones).

What’s next?

In the next post I’ll take a brief look at ArchHurd and ArchBSD.