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.
- "FreeBSD review, Page 1"
- "FreeBSD review, Page 2"