I’ve been a Linux zealot since way back in the days when even most tech people said “What’s a Linux?”. I’ve used that damned kernel for so long, I can hardly even remember what it’s like to run anything else. Oh sure, i’ve always various mixes of *nix (Solaris, HP-UX, AIX, SCO, SVR3/4, etc, etc) while at work and sometimes at home, but i’ve always been primarily powered by the penguin. Desktops, Servers, etc… the only thing left without *nix was my game rig, which was always something Win32 based… i’m too lazy to get into Wine/Cedega and all of that stuff.

After all of these years, why would I suddenly decide to switch? Well, the Linux kernel doesn’t love me anymore. I have an “oddball” machine, a Dual Processor Athlon-MP 2600+ built on the AMD-762 Chipset. From what I can remember, there were only three motherboards built on this chipset… so it’s kinda rare. Oops. Bad purchasing decision. The Athlon-MP turned out to be a heat factory and nobody bought them. Needless to say, drivers are scarce and never updated. Toss in one of the first generation RAID controllers from the Adaptec/DPT merger and you’ve got yourself a Linux disaster waiting to happen. Start with an IDE controller that fails to auto-detect most of the time, so you need to force the correct driver in the kernel or on the boot loader command line. Follow that up with a RAID controller that has TWO drivers in the kernel that will run it, now you have to force that as well. You end up with a machine that’s FLAKY under Linux and isn’t hardly worth running most of the time. Especially as your primary machine.

Is the OE the problem? Not really. It’s the kernel. Ever since kernel 2.6, i’ve had hell with this machine, it worked wonderfully under 2.4.x. The first sign of trouble was when the dpt_i2o driver didn’t get any love in kernel 2.6. I was patching the driver back in on day 1 of 2.6. That should have been an indicator to me that the end was near. I later discovered the new I2O system that would support my controller. “Ah ha! THIS is why the dpt_i2o controller driver wasn’t updated! I don’t need it!” Well, ummm… yes I do. I switched everything over to the I2O subsystem and hated life. It DESTROYED my RAID 1 mirror setup. You know, the setup I use to PROTECT my data. I2O exposes the SCSI LUNs of the physical drives as /dev/sda and /dev/sdb, and the RAID device becomes /dev/i2o/hda or something like that. So, what happens when you run damned near any disk utility in Linux? It defaults to /dev/sda… because that’s your HD, right? Wrong… that’s the LUN of the physical disk, something you do NOT want to mess with in a RAID array. Bad move guys, after a kernel upgrade, my machine mapped the disk label to the physical drive during a reboot and DESTROYED the array b/c it was reading/writing to one drive instead of both. That’s just sad. I could see having those things as read-only devices so you could monitor your drives using S.M.A.R.T. or something, but read/write pointers to the physical drives when they’re part of a RAID array? Are you high? This is just dumb. I must not be alone in disliking the I2O subsystem, because the dpt_i2o driver got fixed back up and put back in the main stream! “Sweet! Now i’m back in business!” I was just so excited to have my dpt_i2o driver back. I wiped the machine and slapped on a fresh Gentoo build. (Yeah yeah, i’m a Gentoo guy) 2 days later when the compiling was over, I was happy… except for the fact that my array would just die every few weeks or under heavy I/O. It locks the machine up solid. This is NOT good. I’ve tried BIOS upgrades/downgrades, controller firmware upgrades/downgrades… no luck. Bang on the disks too hard and you’re toast. The machine locks and the array goes out of sync again. This is just horrid. It does it whether i’m in KDE, GNOME, or just at the CLI with no X running, so it’s not an environment. Lowest Common Denominator… it’s the kernel.

After over a year of fighting kernel 2.6 on my aging machine, I decided to give old Beastie a whirl. We haven’t had a go for years and I thought to myself “surely it’s come a long way in the years since i’ve seen it”…. Wow… Ummmmm… Errrrrr… Kinda? So here it comes, my official FreeBSD 6.2 review!

Download

Easy, hit FreeBSD.org and grab two ISOs, three if you want Docs. They even provide a “Boot Only” ISO for those with local repositories and such. Sweet. Nice packaging. Simple and to the point.

Installation

Boot on CD #1. Here comes the beast! … And that same old text mode installer … I’m okay with this. I’m a Gentoo guy where the installer is a new thing and most people still just bootstrap the thing and do it all from the CLI. The BSD installer was a welcome change from this, it made me quite happy to be online and running quickly instead of the 12h installation process. No offense to Gentoo, that’s good Linux. I miss it alot.

First Impressions

Wow. It’s ummm… BSD. I’m instantly thrown back to the days of borrowing shell accounts on a friends’ BSDi box… circa 1993. The beast still feels like it always has. No hyper fast response (no pre-empting that i’m aware of), but you can’t bog it down. I’ve commenced to putting a load on the box through multiple compiles over SSH, mega find commands for extra disk I/O, etc, etc… nothing. The beast tears it down just like it used to. If you can slow it down, everything degrades gradually, but it does finish. It doesn’t error… it doesn’t panic. It’s rock solid. Amazing kernel. Always has been. I’m so happy now. BSD’s kernel is running rock solid on my machine in the first 48h burn in. But wait… all of these packages are old… quite old. KDE 3.5.4, Xorg 6.9, and these wretched BSD command line utilities. I need my updated OE. I’m so used to the GNU versions of things, I can’t go back to BSD style. It’s just too far back, I use a lot of that new functionality and need some newer SUS compliance!

Post burn-in Software Installation – Ports

After my burn-in, i’m hitting that realization that this isn’t Linux… at all. It’s BSD. I truly had forgotten what it meant to run BSD. So, no problem, there HAS to be some way to load some newer utilities on my machine, BSD practically invented the concept of 3rd-party utilities through the use of /usr/local. You can do it on Sun, HP-UX, and Solaris, so you have to be able to do it here! Sure you can! It’s called Ports, the package manager that Gentoo’s Portage is based on. I ought to be right at home! Well… um… no. Note the use of the words “based on”, that’s very important! Portage uses a lot of the concepts of ports, but works completely different from a usage standpoint. Time to relearn everything.

So, after discovering that BSD’s Ports has lots of “options” for it’s use, I begin to get frustrated at even the simplest concepts. Being a Gentoo user, I know that step #1 is to upgrade the package DB via a snapshot or from the live repository. I choose a snapshot because, well, it’s easy. So, I go to the FreeBSD documentation and discover “portsnap”. I follow the directions and painfully get through this process. Wow, what a PITA. It’s a slew of commands. They’re documented, but it’s still a slew of them! In Gentoo, there is a single command to grab a snapshot, or you can download/untar it yourself (but why?). Anyway, so now i’m done… let’s upgrade those ports! Wait. How? Oh oh, portupgrade, that’s how! Oh wait, it’s not installed on the damned system. Hmmmm… how do I get that. pkg_add or by the ports method? Well, that depends. I go for pkg_add, it’s easy… and it works. Okay, thankfully the FreeBSD docs are solid and get me through this. Now, back to upgrading! I read the docs, which just says to run “portupgrade -a”… all kinds of stuff happens… compiling kicks off and i’m under the impression that were’ good. No. We’re *not* good. There’s a few in there that won’t survive the portupgrade process due to crazy dependency problems. Being a Gentoo guy, i’m used to things happening and I know that the move from Xorg 6.9 to Xorg 7.2 is a rough one… but MAN. I totally wasn’t ready for this. Too little, too late, I find the “UPDATING” document that covers how to upgrade your ports. *argh*. I’m unhappy. I crank up pkg_info and pkg_delete to get rid of all of the damage i’ve done, then start over. Too bad I couldn’t have gotten a warning/error message about that critical information. *sigh* So now, here we are. It’s 2 days later and i’m ALMOST done.

Ports is sub-par to Portage in a lot of areas. Portage is more complex at first but infinitely more powerful in the end. And it usually does a good job of warning you when you’re about to do something stupid. Ports tends to let you go ahead and kick it out. About the only difference here is that portage will let you uninstall packages to the point where you can’t boot anymore! In FreeBSD, the ‘core’ OS is in a different folder hierarchy, so you can’t really mess with it unless you get carried away with the rm command.

Here’s a quick rundown for people who have run Gentoo and are considering a run with the beast.

Portage vs Ports

Directory Structure
Ports : /usr/ports
Portage : /usr/portage

Naming Convention
Ports : category/package – You can tell that there was/is a transition going on here. Some categories have long names like “utilities”, some categories have abbreviations like “net-im”.
Portage : category/package – All categories have abbreviations like “net-im”.

Commands to Manipulate
Ports : Too many to list, lots of 3rd party is required to really get nasty with it.
Portage : emerge will do all primary functions, including searching. 3rd party is available for enhancements.

Dependency Checking
Ports : Nightmare.
Portage : Can be a hassle for large upgrades, like using a 2 year old base image and then trying to upgrade everything at once. It can be accomplished, but it’s definitely not advisable.

Pre-Installation Preview
Ports : None that I can find at this time. More research required.
Portage : ‘emerge –pretend’ (or -p for short)

Package Option Selection
Ports : It normally runs in Interactive mode… so that means that if you start a big install/upgrade and go to bed, you’ll probably wake up to it asking you to select what options you want for a particular package. You can negate this with environment variables and setting the install/upgrade run for batch mode. But you have to define all of that. Finding out what to define for what package is also a hassle… you have to know how to read make files. There might be a utility for this, i’m still searching. Per package flagging is done by a make trick. You basically check what package that you’re in via the current directory variable and then set variables. That way the variables only get set/unset if you’re in the right package. (I know, nasty isn’t it?)
Portage : Use flags. Emerge -pv will show you what packages are going to be installed and what use flags they support. Here’s where portage falls off though. In order to find out what those flags mean, you either have to go edit the build script (ebuild) or use a 3rd party program like ufed. Use flags are set in a single environment variable in make.conf. Per package use flags can be set in a separate file called packages.use (or package.use, can’t remember which right now)

Configuration Update
Ports : Backup Configurations, Update Packages, Merge old options into new configuration files. I think it makes backups of the old configurations, but I don’t know where they are so i’m not taking chances!
Portage : If the ebuilds are correct, portage has a “CONFIG_PROTECT” variable that protects all files in specific directories. (Like /etc or /usr/kde/3.5/etc) Portage will not replace files in any of these directories, it will simply copy the new file in with a different name. A utility called etc-update will scan the directories and find the new files, then allow you to merge them in or overwrite. It will also automatically merge trivial changes (comments, CVS headers, etc)

Snapshot Sync
Ports : A list of commands, well documented process though
Portage : ‘emerge –websync’ (manual is available)

Live Repository Sync
Ports : Via CVSup, csup, anonymous CVS, and others. CVSup/csup require configuration files to be built and an understanding of the repository. This process is well documented and samples of the required configurations are just a Google query away.
Portage : ‘emerge –sync’. There is one master repo. That’s it. All packages are in it.

Additional Repos
Ports : Unknown at this point, although i’m sure you could just add them in and remove CVSup’s ability to delete unknown.
Portage : Yes, they’re called overlays and can be managed manually or through “layman”.

Final Thoughts

So anyway, i’m just about done compiling KDE 3.5.7 and i’ll have more later. My experience at the command line has been the same as it always has been with BSD. It just feels old and outdated. The kernel is rock hard as far as I can tell. It handles every load I can put on it without really sweating. That’s fantastic! So, take the kernel and slap a nice OE on top of it and you’ve got yourself a product… and they’re probably call it OSX or something like that.

I’m going to give the beast a fair shake of at least 10 more days. Once I hit that marker, i’ll know if I have to switch away or not. Hopefully I can make the OE work, but i’m not sure if i’m ready to maintain all of this. Gentoo has to compile new updates as well and that can get annoying when Mozilla kicks out a new Firefox/Thunderbird every few weeks. At least portage is easily managed for that sort of thing though!

If anyone can she some light on my lack of ports knowledge, PLEASE do so. I’d love to fill this in and do a real comparison of ports vs portage with the help of a power user. The BSD kernel works like a champ on my machine, I just need the OE to work as well for me as Gentoo did and i’m set!

Like

Unlike