FreeBSD 5.2-RELEASE is the third major 5.x release for the next generation of the FreeBSD Unix system (release notes). For the last few years I only used the 4.x stable releases, waiting for a mature 5.x release to come out before trying it. I felt that the time had come with 5.2, but has it?
The text-based installation is the same as in past versions of FreeBSD, so there is nothing new to report on this. As long users gets their head around FreeBSD’s partitioning/slicing scheme, the rest should be pretty straight forward for most users.
The FreeBSD installer let me choose of 2-3 ways of configuring X, and I first chose the graphical one, which failed. I decided to deal with X later (after the installation had finished), and so later I just copied my XF86Config from my Slackware 9.2-Current partition and used that successfully.
Our firewall/router here at home is based on FreeBSD 4.x and so I got… proof that FreeBSD excels as a server (we haven’t seen a single crash with it for the last 2 years). However, my FreeBSD 5.2 installation was done on my AthlonXP 1600+, which is a desktop system, and so this evaluation of the FreeBSD software was done with that in mind (hardware description: 256 MB RAM, 32MB GeForce2-MX400 AGP, 80 GB IDE, Matsushita 4x DVD-ROM, BTC CD-RW, Yamaha YMF-754 PCI sound card, Texas Instruments PCI Firewire card, IOGEAR ALi-based USB-2 PCI card, 19″ LG 995E CRT monitor).
The FreeBSD boot screen has a text selection menu with an ascii Daemon next to it: from there you can choose the kind of booting you want (normal, safe mode, single user etc).
When I created the “eugenia” user using the installer, I typed /bin/bash as the shell for that user but what I didn’t remember was that the location of that binary on FreeBSD was /usr/local/bin/bash. I could edit the passwd files later to correct this, but as I was already booted to KDE as root (couldn’t login as “eugenia” yet because of bash’s wrong path) I decided to use the kuser KDE application to fix my user’s entry. A minute later I had everything saved and tried to login as eugenia. Seemingly everything went ok. But when I needed to “su -” to root to do some additional first-time configurations I noticed in terror that I could not login as root at all anymore. Apparently kuser had mangled both the /etc/passwd and /etc/master.passwd files and deleted the first 3 lines of these files which contained the information for root. It took me over an hour trying to find on Google clues as to how to put my installation back together as my last resort would have being re-installation. So, I fixed it by booting to single user, doing a “mount -t ufs -a”, and then going to /etc and doing a “pwd_mkdb -p master.passwd.bak” which re-created my passwd file and its user database (thankfully there was a .bak backup file there, otherwise I would have to re-install like this guy had to do).
I wrote to the FreeBSD KDE members about this incident and apparently this was a known problem but the fix was commited two weeks after the code freeze. In my opinion this utility should have either not included at all (the problem existed on FreeBSD 5.1 as well for months now!), or they should have accepted the patch in time for 5.2. I will take one point off for FreeBSD — not because of the bug (bugs happen) — but because of the decision to not do something to fix this important problem in time for 5.2 while it was a known problem. While most users will follow the Handbook and use the adduser command, others might just find convienient a GUI tool at some point and then face unnecessary hell. (After this report, the 5.2 Errata was updated).
FreeBSD includes Gnome 2.4.1, KDE 3.1.4, AfterStep, and Windowmaker. I used Gnome most of the time. FreeBSD found and supported all my hardware except my USB-2 ALi-based card (only works with Windows) and my Creative USB web camera (works with Linux). The ov511 driver for FreeBSD is not up to date for 5.2, but even if it were, it would not work with Gnomemeeting because the driver port from Linux was done to merely grab snapshots from it and not to do video. I wrote to some of the ov511 developers about it and they told me that they wouldn’t do the job to completely port the driver properly because there is no infrastructure on FreeBSD like Video4Linux is on Linux. Regarding the USB2 card, I could not test it because I couldn’t see any EHCI option (“device ehci”) on the FreeBSD configuration kernel file except of OHCI and UHCI and so I didn’t bother recompiling the kernel (especially now that the 5.x kernels come precompiled for sound there is little incentive to mess with it anymore). I might look into this further in the future, though ’cause I know that EHCI *is* supported by newer FreeBSDs.
FreeBSD doesn’t come with all the cool stuff already preconfigured for the user as most newer Linux distros try to. For example, I had to create links for /dev/dvd and /dev/cdrw to the actual device names; I had to chmod them to 666 so all my users can use them, and turn vfs.usermount on sysctl to 1. I had to edit /boot/loader.conf and add DMA support for my IDE and ATAPI drives to increase performance, and I also had to load the sound card driver manually too (which was an exercise in frustration as the DS1 driver is not really documented as much as the emu10k driver is). I also had to edit rc.conf to enable Samba and FAM support (Samba configuration still requires more tweaking; it seems as Nautilus just can’t use smb:/// at all).
Speaking of FAM and Nautilus, Gnome wouldn’t use FAM even after this was installed. I had to setup and use cvsup for the ports tree, download a new /devel/gnomevfs2 tarball and recompile it with FAM in it and with -DWITHOUT_KDE_MENUS, because the default gnomevfs2 has all the KDE menus loading inside Gnome’s, hence creating a terrible sight. Special thanks to Marcus from the Gnome-FreeBSD project for his help.
On the upside, FreeBSD 5.2 comes with client support for NFS version 4, much better integration with the ACPI power management subsystem, full tier-1 support for all AMD64 systems, better driver support for IDE, SATA, and 802.11a/b/g devices, dynamically linked root partition and (experimental) first-stage support for multithreaded filtering and forwarding of IP traffic. More new features are listed here.
After I had cvsup’ed, I decided to give it a go and play a DVD using VideoLAN. After about 40 minutes of compiling it and its dependancies I had VidioLAN up and running, only to get a black output window (the video was playing fine and the sound was fine but it would render black and it would take an awful lot of cpu, error messages on the terminal would appear, Google didn’t help). After hitting a few random buttons on its window to make it stop, FreeBSD would just crash and the machine would reboot. Upon rebooting I installed Ogle which would give me the error message “DVDsetRoot is not set” or something to this effect. I have all devfs links needed setup (/dev/dvd, /dev/cdrom, /dev/cdrom1, /dev/cdrw) however Ogle was possibly trying to find a device link that doesn’t exist. I had to tell it “ogle /dev/dvd” to get it to open the right device. After doing that, Ogle would play the DVD just fine, even with overlay capabilities. Totem with Xine backend would also work with no problem. But regarding VLC 0.7, still not joy.
A few more bugs I found were that the gnomegames package would not get installed properly thinking that the 2.2.0 version is installed (please note that this was a clean installation), and so the HighScrores would not get recorded. Upon forcing the gnomegames-18.104.22.168 package to re-install from the CD, it would then install all the right files in the right places. Another problem was that any CD or DVD it mounted would not have a title but it would show as jibberish, it would have a filename with weird characters. This is apparently a known bug, fixed in the CVS for Gnome 2.5. As I mentioned above, I gave the right permissions to all devices/mounted dirs and told sysctl to let my users mount CDs, but still no joy with Nautilus.
Other ports problems include the libvorbis and libogg telling me that they are newer versions available (check screenshot) and upon upgrading them they keep telling me the same thing (I fear that the bug is just a typo in their version the db looks up), while every gtk application I compiled creates dependencies to the /devel/qmake package for some reason. I wouldn’t normally mind, but trying to use portupgrade would tell me that the db has problems because of these dependencies. Running “pkgdb -F” to fix these packages, it would tell me that all those packages have “stale dependencies” (whatever that means) and it would just not properly fix them (I recreated the index.db too with no results).
Later, I wanted to mount (read-only) my Fedora ext3 partition using the EXT2FS driver. I do not understand why the actual mount_ext2fs command exists while the kernel module for it is not compiled and even more weirdly, while the “option EXT2FS” is now completely removed from the GENERIC kernel conf file. From the moment the mount_ext2fs command is present to the system the option should have been in the kernel conf file, commented out even.
Not all is bad though. On the upside of FreeBSD you will find its speed. On my AthlonXP 1600+ 1.4 GHz, FreeBSD boots in about 16-18 seconds, the same as a lite Slackware or Gentoo, but way faster comparatively on other popular Linuces like Fedora or Mandrake or SuSE. As I have mentioned in the past Slackware was the fastest platform to run X/Gnome/KDE according to my tests, but the crown of DE speed now goes to FreeBSD 5.2. GTK apps are a bit faster than in Slackware overall but applications load significantly faster on FreeBSD.
The ports tree –while time consuming when compiling a port and its dependancies– it has its advantages. It is well-maintained and generally trouble-free (just not always as I demonstrated above). Linux solutions with Red Carpet, Debian, Gentoo etc., also have good results though today, so I don’t see the FreeBSD Ports anymore as the big selling point of the OS. Once upon a time this was a big bragging point for the Linux/Unix folks, but today is nothing that would make any new user or “switcher” awe. Especially when there are not many binary packages to choose from, it can be a disadvantage to subject the time users long compilation times (e.g. compiling OO.o could take many-many hours as it downloads Java, Mozilla and other such monster software to compile them as dependancies).
The big advantage FreeBSD still has today is that it is not a bunch of kernels, then gnu utils on top and then a gazillion of other third party apps on top of that. The OS feels integrated, it is a system designed and maintained from the ground up, not like any random distribution. This is a major selling point and is what makes FreeBSD feel like a trustworthy product.
In my opinion, FreeBSD rocks as a server, but it is pretty poor as an “out of the box” desktop system is concerned. But then again, FreeBSD is a server system in its heart, a real Unix; it is just that I can’t overlook the fact that they ship with desktop software and so this has to work as well as the system utilities and servers. I might sound like a mega-whiner here, but despite all these discomforts I had to go through again since my previous 4.x installation, extra work that the user has to do, and the occassional unexpected bugs, I still like FreeBSD. As long you stick to it and spend a few hours (or days, depending on your experience) fixing and configuring your way through to get the results you are looking for, you should be able to get a good setup and a worthy system to do your day to day job. It doesn’t come with all comforts that most Linuces come with (Flash, Java pre-installed, media software etc) but it is a worthwhile experience and it is generally very stable.
If you are after the “experience” go for it. If you want a solid server system, go for it too. If you are after an easy-to-use desktop system that doesn’t require you to learn anything new, then you better look elsewhere.
Good points: Faster than Linux on the desktop (at least compared to kernel 2.4.x distros), easy to configure via its well-documented conf files, feels integrated and like a mature Unix that you can trust (at least as a server).
Bad points:Limited ‘exotic’ hardware support, silly little annoyances all over the place, not many binary packages available and so compilations from ports may take ages.
Hardware Support: 6/10
Ease of use: 7/10
Credibility: 7/10 (stability, bugs, security)
Speed: 8.5/10 (throughput, UI responsiveness, latency)