There are three branches to FreeBSD. -CURRENT is where the active development goes on. Stuff in here shouldn't break, but it may only have been tested on one person's machine so there's a good chance that it will. After something has been tested, it moves into the -STABLE branch. Most users track stable by just running csup and then doing a make world. This gives them new features as soon as possible without compromising stability. The third category is the release branches. Releases are made by a code freeze and a few weeks of bug fixing in -STABLE. Then they are branched. After that, the release branch will only ever get bug fixes, never new features. If you run 8.2, you can keep tracking the 8.2 branch until it's no longer supported and you won't see any changes, you'll just get security updates. Or you can jump from 8.2 to 8.3 when it's released, or you can periodically grab the latest from -STABLE.
You're very unlikely to see any serious bugs in -STABLE, and people who can afford to see occasional ones are encouraged to use it and report any issues they find so that they can be fixed before the release (which is for 'stability at all costs' users). You are not encouraged to use -CURRENT unless you are a developer.
But it's never going to make it into an actual release of 8.x.
Absolutely untrue. It is in 8-STABLE, which means that it will be included in the next 8.x series release, which will be 8.3. If you're running 8.2 now, upgrading to 8-STABLE is easy and if you did it any time after June this year you'll already have found yourself with ZFS v28.
Why the hell do I have to swipe the deck off of the top of the screen to close it? How, in all that is holy, is that "intuitive"?
I'm always careful of using the word intuitive about any UI, but it seemed natural to me. I didn't read any documentation about WebOS before using it, and flicking a card away from the top of the deck to get rid of it seemed like the obvious way of getting rid of it.
To put some numbers on it, with my 1.6GHz AMD fusion CPU, I can only write at about 20MB/s to a three disk RAID-Z array with compression and deduplication enabled. For backups over WiFi, that's no limitation at all - it;s still ten times faster than the network. For local use, it's not ideal. That said, it's going to be a lot faster on a better CPU. It may also be possible in future versions to speed up the search for duplicate blocks by using a multiple threads.
Slashdot doesn't have a mechanism for sending messages between users, which pretty much disqualifies it as a social networking site. Friends and Foes are just moderation modifiers. I vaguely remember you being able to restrict journal posts so only your friends could comment, but I think that option went away. About the only thing that you can do as a logged in Slashdot user that you can't as an Anonymous Coward is get automatic notifications of replies to your posts.
Why don't you deduplicate everything? That sounds like there is a significant downside?
Deduplication comes with a fairly hefty memory cost and requries every disk write to be checked against a hash table of existing blocks. This cost is worth paying for things that are likely to contain a reasonable amount of duplication, but not for other things. The combination of compression and deduplication on my backup volume is saving about a third - the disk space used is about the same as if I were using JBOD instead of RAID-Z, but if one of my disks fails the filesystem will still be fine. On the filesystem where I rip my DVDs, enabling compression and deduplication would be unlikely to save even 1%, but would slow the entire system down. The ports tree has a compression ratio of 1.67x at the moment, and it contains a lot of small files so the overhead of decompression is likely to be lost in the noise of disk seek times. For other filesystems, it wouldn't make sense.
I also have an 8GB USB flash drive set up as L2ARC for that machine, which gets about a 40% hit rate and avoids the need to go to the disk at all for a lot of things.
Oh, and I'd take issue with the assertion that hard links are easier to understand than deduplication. Deduplication lets you just make copies, with hard links you have no copy on write, so you have to remember that modifying one copy will modify all of the others.
FreeBSD has you editing a makefile with minimal documentation.
No, it has you editing the kernel description file with lots of documentation. Here is the GENERIC kernel config for x86-64. If you want to compile a custom kernel, copy that file and modify it. You'll find a comment on every single line explaining what it does, and a longer comment above every section. Linux's menuconfig requires more keystrokes to remove options than editing that file in a text editor.
FreeBSD doesn't tend to split things up as much as Debian. For example, on Debian I have to install two packages for every library - one for the library and one for the headers. Often the documentation is another package. A GCC version is about a dozen packages on Debian, but only one on FreeBSD. Debian also has a habit of giving packages stupid names (e.g. libobjc2 is not libobjc2, it's an old version of gcc libobjc, the new llvm-gcc packages are not llvm-gcc at all, they're DragonEgg, which is a completely different project).
Really? I replaced my colocated server with a FreeBSD Xen DomU. Virtualisation is working there. On the FreeBSD-hosted side, I have several options:
For lightweight virtualisation, there are jails, which can be created with a ZFS clone in about 2 seconds, and let you create a new root account and do anything you could in a real FreeBSD system except modify the kernel.
For real virtualisation there's BHyVe, roughly similar to KVM on the Linux side.
For desktop virtualisation there's VirtualBox.
What's missing? We have lightweight containers, paravirtualised instances, and full system virtualisation. About the only thing I can think of is Xen dom0 support, and that's hardly a requirement for most desktops (and is coming soon)...
Totally irrelevant. A typical supercomputer uses Linux as a glorified I/O controller. SMP performance in the kernel is irrelevant - jobs get given 100% control over the CPU for the time that they run. The kernel is there (often in a coprocessor) to handle I/O requests issued by the code running on the real hardware. They certainly aren't scheduling jobs on a supercomputer in the same way that they are on your desktop. If they were, it would be a pretty compelling reason to not use Linux on the desktop: supercomputers are all about throughput, and if a job has to wait a few minutes to get CPU time then that's fine as long as it gets a huge amount of CPU when it runs. Desktops are all about latency: if your code is using 20% of your CPU instead of 10%, you probably don't care, but you do care if you have to wait a user-noticeable amount of time (more than a few tens of ms) for a response to an interface action.
ZFS has a fsck tool, it's called zpool scrub. It verifies the entire filesystem - including the contents of the files, by validating the checksums - and repairs it. The grandparent's complaint was not about the lack of fsck, it was about the lack of a fsck tool 'that doesn't just tell you that your filesystem well and truly IS fscked'. Being told that your filesystem is damaged is no use, you want the fsck tool to fix it. ZFS usually doesn't need fsck because it does background repair and recovery automatically on a live filesystem, but you can force it to verify and repair the entire filesystem if you want to.
Few people mock Gentoo. A lot of people mock Gentoo users. I've not heard much from the distro for a while, but when it first came out its users were always telling you how much faster everything went if you added -funroll-loops to your CFLAGS. Now, most people who use Gentoo care more about the fact source builds make it easier to customise the software you install and use portage just like FreeBSD ports, so they aren't mocked as much.
Mainframes are increasingly seeing competition from clusters of commodity machines running Xen or similar - the cluster is often less good, but at ten percent the cost of the mainframe it doesn't have to be to be tempting to a lot of users. This is an attempt to ensure that anything you can do with cluster of Xen machines, you can do with a mainframe (the converse is not true).
The problem is that FreeBSD's implementation of ZFS in stable builds is extremely out of date. FreeBSD currently supports ZFS v15 (current closed-source is v33), which means you're missing a lot of the features. No triple-parity RAID, no deduplication, no encryption, no snapshot diffs, etc.
As you say, FreeBSD 9 (currently in release candidate phase) supports ZFS v28. I'm using the RC now, and deduplication seems to work pretty nicely. I've got a compressed deduplicated volume that I use for Time Machine backups from a couple of Macs. Compression is saving about 25% of the space, and deduplication another 10% (I expect this to increase, because Time Machine creates a new copy of every file even if only one block changes).
Of course, the downside to all this is that ZFS is now effectively closed-source, and I'm not sure if we'll ever get anything newer than v28, unless it forks...
iXSystems sells ZFS-based storage appliances running FreeBSD. They've recently taken over development of FreeNAS and have publicly committed to continuing to develop ZFS on FreeBSD - they've already been responsible for fixing a few bugs that haven't get been fixed on Solaris. Whether the new versions will be compatible with Oracle's version depends on whether Oracle releases documentation, but either way ZFS in FreeBSD is not going to orphaned.
The locking of/dev/dsp is mostly ancient history at this point, even on Linux, where sound (finally) got the attention it needs
And yet I still regularly hear complaints from Linux users about sound-related problems.
I use schroot for the usecase you use ezjail for, and from your short note it looks mostly equivalent. I tend to use either a btrfs or lvm backend.
schroot uses chroot. Jail does a lot more than chroot - each jail contains an independent set of users, so things can run as root inside a jail without being able to escape.
As for creating new filesystems, I find that mostly a bother; what I want is just one filesystem to handle it all
I want my backups to be compressed and deduplicated. I want my hone directory to have some extra redundancy. I want my ports tree to be compressed but not deduplicated. I don't want setuid or execute flags to work on every part of the hierarchy.
The reason you want one filesystem is because you use a system where creating a new one that does what you want is expensive. Adding a new zfs filesystem is a single command and takes a few seconds (99% of which is the time taken to type the command, not the time for it to execute). Before using ZFS, I was in the same situation - I'd given up creating different filesystems for different parts of the tree. With the system I've set up to use ZFS, I currently have 24 ZFS filesystems mounted. There is no reason not to create more, and (since snapshots happen on a filesystem granularity) some very good reasons for creating new ones.
Snapshots are useful though (and supported by LVM and btrfs).
LVM snapshots are much more heavyweight than ZFS ones (which cost about as much as creating a hard link to create). I doubt you'd set up a cron job to take daily or hourly snapshots with LVM, but I wouldn't even think twice about doing that with the ZFS filesystem I use for storing backups.
Not sure about btrfs, but last I heard it wasn't even close to being production ready and, because it still uses the old SunOS-derived layering, doesn't fix the RAID-5 write hole or address half of the other things that ZFS does. Like many other Linux things, it's a superficial copy of something else, missing the parts that made the original interesting.
No, BSD was UNIX when it contained AT&T UNIX code and AT&T owned the trademark. After the UCB vs AT&T lawsuit, BSD removed the last remaining traces of UNIX code and was not UNIX.
What kind of nonsense are you spouting? FreeBSD has paravirtualised disk and network drivers for Xen and runs very well as DomU. Dom0 support is a bit less good, but if you want to run FreeBSD guests on a FreeBSD host there is BHyVe.
There are some benchmarks of FreeBSD 7 against Linux of the same era (that graph includes the version of Linux that was specifically released after the previous set of benchmarks showed FreeBSD beating Linux by even more). Both Linux and FreeBSD have improved in SMP support since then, so I don't know how they compare anymore. I suspect that both are in the state where the kernel is not likely to be the cause of any scalability issues that you encounter.
It's also nonsense. The ULE2 scheduler in FreeBSD has very good SMP support. Up to 8 cores, it gives a pretty linear speedup on the MySQL benchmarks I saw. Allegedly it should continue to scale well up to at least 64 cores, but I've not seen any real tests on bigger machines. This has been true since FreeBSD 7, although SMP performance improved a lot in the 8-9 window.
OS X is the only one you can call UNIX. The others are UNIX-like or UNIX-derived (in the BSD case). To be called UNIX (a trademark owned by The Open Group), you must be certified as implementing the whole of the Single UNIX Specification.
I read TFA when it was on OSNews, and it's a waste of space. I was expecting some actual points, but it seemed to boil down to 'I haven't rebooted this machine for three years! FreeBSD is therefore awesome!' When someone talks about uptime, it's a clear sign that they are an idiot: uptime is irrelevant, downtime is important. You can achieve good uptime by failing to install security updates, but it's far better to spend a minute rebooting than to spend a day cleaning up and reinstalling after a machine is compromised.
I have these reasons for using FreeBSD on the desktop:
I don't want to have to spend ages configuring stuff, or learning how to configure stuff. With FreeBSD, the stuff I learned ten years ago is still relevant. I only need to learn new things when there is new functionality. Contrast this with Linux where userspace tools change more often than Paris fashions. Just as you've learned one, it's deprecated, and then replaced by something else.
APIs are well designed and stable. A couple of years ago, I wrote some code for getting the battery status on a variety of platforms. On NetBSD, OpenBSD, and FreeBSD it was a few sysctls and worked on every architecture. On Linux, the interfaces were subtly different on every architecture, but there was a 300KB library that abstracted this for you. The code to invoke this library was more complex than the entire *BSD implementations combined.
Sound Just Works. FreeBSD has low-latency sound mixing in the kernel and has a really amazing implementation of the OSS 4 APIs. Multiple applications can just open/dev/dsp, issue a couple of ioctls() to select the sample rate and so on, and away it goes. I installed FreeBSD on a NAS / Media Center box a few weeks ago. 5.1 sound output in VLC just worked[1], and I can ssh into the machine and run another music player with the display exported to my laptop without needing to close the VLC that has the sound device open to play audio from DVDs, or configure some userspace sound daemon. The kernel just does what a kernel is supposed to do: abstract the details of the underlying system (including the fact that multiple unrelated processes are running) from userspace apps. This was what made me switch from Linux to FreeBSD in the 4.x days - multiple apps playing sound at once was easy. Apparently, three sound daemons later, it's almost easy in Linux, in a hacky kind of way, as long as PulseAudio doesn't hate you as much as it apparently hates most people...
ZFS. Seriously, if you haven't used it then you don't know how awesome it is. Creating new filesystems is as easy as creating new directories. Transparent compression, deduplication, and free snapshots are amazing. Even better is the integration with the ezjail tool, which clones a base system install and creates a jail. This is great if you want to run some untrusted code, or just set up a test environment - it takes a few seconds to create a new, isolated environment where you can test things, break things, and then destroy it when you're done. I've only used it on the most recent FreeBSD machine I've installed, and after a day I started missing it on systems where I wasn't using it. There are some places where it could be better integrated, for example apt-clone on Nexenta took a snapshot, installed a bunch of packages, and then reverted the filesystem if any of them failed - I don't know of any FreeBSD equivalent yet, but hopefully pkg-ng will introduce one.
Capsicum. The first security framework I've seen that is actually well designed. It's in -CURRENT, not sure if it will make it into 9.0, but should into 9.1 if it doesn't. Most of the standard userland tools are being modified to use it, and things like Chromium have already had Capsicum integrated - a tiny diff to do fine-grained sandboxing. An increasing number of ports are getting Capsicum support too, so expect to see your favourite desktop applications start to run with the absolute minimum required privilege soon.
[1] I spent a couple of hours looking for documentation on how to configure it. Then I decided to actually test it, found that it worked already, and felt quite silly.
Slashdot Mirror
There are three branches to FreeBSD. -CURRENT is where the active development goes on. Stuff in here shouldn't break, but it may only have been tested on one person's machine so there's a good chance that it will. After something has been tested, it moves into the -STABLE branch. Most users track stable by just running csup and then doing a make world. This gives them new features as soon as possible without compromising stability. The third category is the release branches. Releases are made by a code freeze and a few weeks of bug fixing in -STABLE. Then they are branched. After that, the release branch will only ever get bug fixes, never new features. If you run 8.2, you can keep tracking the 8.2 branch until it's no longer supported and you won't see any changes, you'll just get security updates. Or you can jump from 8.2 to 8.3 when it's released, or you can periodically grab the latest from -STABLE.
You're very unlikely to see any serious bugs in -STABLE, and people who can afford to see occasional ones are encouraged to use it and report any issues they find so that they can be fixed before the release (which is for 'stability at all costs' users). You are not encouraged to use -CURRENT unless you are a developer.
But it's never going to make it into an actual release of 8.x.
Absolutely untrue. It is in 8-STABLE, which means that it will be included in the next 8.x series release, which will be 8.3. If you're running 8.2 now, upgrading to 8-STABLE is easy and if you did it any time after June this year you'll already have found yourself with ZFS v28.
They fired the hardware team, the WebOS team is still there.
Why the hell do I have to swipe the deck off of the top of the screen to close it? How, in all that is holy, is that "intuitive"?
I'm always careful of using the word intuitive about any UI, but it seemed natural to me. I didn't read any documentation about WebOS before using it, and flicking a card away from the top of the deck to get rid of it seemed like the obvious way of getting rid of it.
QNX is a nice kernel, WebOS has a nice UI. Ripping Linux out of WebOS and replacing it with QNX might make a nice system.
Slashdot karma, the one currency worth less than bitcoins...
Perhaps the best example is the World's first megacorporation, the East India Company
Which one? There were several, and none were particularly non-evil...
To put some numbers on it, with my 1.6GHz AMD fusion CPU, I can only write at about 20MB/s to a three disk RAID-Z array with compression and deduplication enabled. For backups over WiFi, that's no limitation at all - it;s still ten times faster than the network. For local use, it's not ideal. That said, it's going to be a lot faster on a better CPU. It may also be possible in future versions to speed up the search for duplicate blocks by using a multiple threads.
Slashdot doesn't have a mechanism for sending messages between users, which pretty much disqualifies it as a social networking site. Friends and Foes are just moderation modifiers. I vaguely remember you being able to restrict journal posts so only your friends could comment, but I think that option went away. About the only thing that you can do as a logged in Slashdot user that you can't as an Anonymous Coward is get automatic notifications of replies to your posts.
Why don't you deduplicate everything? That sounds like there is a significant downside?
Deduplication comes with a fairly hefty memory cost and requries every disk write to be checked against a hash table of existing blocks. This cost is worth paying for things that are likely to contain a reasonable amount of duplication, but not for other things. The combination of compression and deduplication on my backup volume is saving about a third - the disk space used is about the same as if I were using JBOD instead of RAID-Z, but if one of my disks fails the filesystem will still be fine. On the filesystem where I rip my DVDs, enabling compression and deduplication would be unlikely to save even 1%, but would slow the entire system down. The ports tree has a compression ratio of 1.67x at the moment, and it contains a lot of small files so the overhead of decompression is likely to be lost in the noise of disk seek times. For other filesystems, it wouldn't make sense.
I also have an 8GB USB flash drive set up as L2ARC for that machine, which gets about a 40% hit rate and avoids the need to go to the disk at all for a lot of things.
Oh, and I'd take issue with the assertion that hard links are easier to understand than deduplication. Deduplication lets you just make copies, with hard links you have no copy on write, so you have to remember that modifying one copy will modify all of the others.
FreeBSD has you editing a makefile with minimal documentation.
No, it has you editing the kernel description file with lots of documentation. Here is the GENERIC kernel config for x86-64. If you want to compile a custom kernel, copy that file and modify it. You'll find a comment on every single line explaining what it does, and a longer comment above every section. Linux's menuconfig requires more keystrokes to remove options than editing that file in a text editor.
FreeBSD doesn't tend to split things up as much as Debian. For example, on Debian I have to install two packages for every library - one for the library and one for the headers. Often the documentation is another package. A GCC version is about a dozen packages on Debian, but only one on FreeBSD. Debian also has a habit of giving packages stupid names (e.g. libobjc2 is not libobjc2, it's an old version of gcc libobjc, the new llvm-gcc packages are not llvm-gcc at all, they're DragonEgg, which is a completely different project).
What's missing? We have lightweight containers, paravirtualised instances, and full system virtualisation. About the only thing I can think of is Xen dom0 support, and that's hardly a requirement for most desktops (and is coming soon)...
Totally irrelevant. A typical supercomputer uses Linux as a glorified I/O controller. SMP performance in the kernel is irrelevant - jobs get given 100% control over the CPU for the time that they run. The kernel is there (often in a coprocessor) to handle I/O requests issued by the code running on the real hardware. They certainly aren't scheduling jobs on a supercomputer in the same way that they are on your desktop. If they were, it would be a pretty compelling reason to not use Linux on the desktop: supercomputers are all about throughput, and if a job has to wait a few minutes to get CPU time then that's fine as long as it gets a huge amount of CPU when it runs. Desktops are all about latency: if your code is using 20% of your CPU instead of 10%, you probably don't care, but you do care if you have to wait a user-noticeable amount of time (more than a few tens of ms) for a response to an interface action.
GCC 4.2 on FreeBSD produces slower code than GCC 4.4 on Linux? Shocking! And clear evidence of the superiority of Linux!
ZFS has a fsck tool, it's called zpool scrub. It verifies the entire filesystem - including the contents of the files, by validating the checksums - and repairs it. The grandparent's complaint was not about the lack of fsck, it was about the lack of a fsck tool 'that doesn't just tell you that your filesystem well and truly IS fscked'. Being told that your filesystem is damaged is no use, you want the fsck tool to fix it. ZFS usually doesn't need fsck because it does background repair and recovery automatically on a live filesystem, but you can force it to verify and repair the entire filesystem if you want to.
Few people mock Gentoo. A lot of people mock Gentoo users. I've not heard much from the distro for a while, but when it first came out its users were always telling you how much faster everything went if you added -funroll-loops to your CFLAGS. Now, most people who use Gentoo care more about the fact source builds make it easier to customise the software you install and use portage just like FreeBSD ports, so they aren't mocked as much.
Mainframes are increasingly seeing competition from clusters of commodity machines running Xen or similar - the cluster is often less good, but at ten percent the cost of the mainframe it doesn't have to be to be tempting to a lot of users. This is an attempt to ensure that anything you can do with cluster of Xen machines, you can do with a mainframe (the converse is not true).
The problem is that FreeBSD's implementation of ZFS in stable builds is extremely out of date. FreeBSD currently supports ZFS v15 (current closed-source is v33), which means you're missing a lot of the features. No triple-parity RAID, no deduplication, no encryption, no snapshot diffs, etc.
As you say, FreeBSD 9 (currently in release candidate phase) supports ZFS v28. I'm using the RC now, and deduplication seems to work pretty nicely. I've got a compressed deduplicated volume that I use for Time Machine backups from a couple of Macs. Compression is saving about 25% of the space, and deduplication another 10% (I expect this to increase, because Time Machine creates a new copy of every file even if only one block changes).
Of course, the downside to all this is that ZFS is now effectively closed-source, and I'm not sure if we'll ever get anything newer than v28, unless it forks...
iXSystems sells ZFS-based storage appliances running FreeBSD. They've recently taken over development of FreeNAS and have publicly committed to continuing to develop ZFS on FreeBSD - they've already been responsible for fixing a few bugs that haven't get been fixed on Solaris. Whether the new versions will be compatible with Oracle's version depends on whether Oracle releases documentation, but either way ZFS in FreeBSD is not going to orphaned.
The locking of /dev/dsp is mostly ancient history at this point, even on Linux, where sound (finally) got the attention it needs
And yet I still regularly hear complaints from Linux users about sound-related problems.
I use schroot for the usecase you use ezjail for, and from your short note it looks mostly equivalent. I tend to use either a btrfs or lvm backend.
schroot uses chroot. Jail does a lot more than chroot - each jail contains an independent set of users, so things can run as root inside a jail without being able to escape.
As for creating new filesystems, I find that mostly a bother; what I want is just one filesystem to handle it all
I want my backups to be compressed and deduplicated. I want my hone directory to have some extra redundancy. I want my ports tree to be compressed but not deduplicated. I don't want setuid or execute flags to work on every part of the hierarchy.
The reason you want one filesystem is because you use a system where creating a new one that does what you want is expensive. Adding a new zfs filesystem is a single command and takes a few seconds (99% of which is the time taken to type the command, not the time for it to execute). Before using ZFS, I was in the same situation - I'd given up creating different filesystems for different parts of the tree. With the system I've set up to use ZFS, I currently have 24 ZFS filesystems mounted. There is no reason not to create more, and (since snapshots happen on a filesystem granularity) some very good reasons for creating new ones.
Snapshots are useful though (and supported by LVM and btrfs).
LVM snapshots are much more heavyweight than ZFS ones (which cost about as much as creating a hard link to create). I doubt you'd set up a cron job to take daily or hourly snapshots with LVM, but I wouldn't even think twice about doing that with the ZFS filesystem I use for storing backups.
Not sure about btrfs, but last I heard it wasn't even close to being production ready and, because it still uses the old SunOS-derived layering, doesn't fix the RAID-5 write hole or address half of the other things that ZFS does. Like many other Linux things, it's a superficial copy of something else, missing the parts that made the original interesting.
No, BSD was UNIX when it contained AT&T UNIX code and AT&T owned the trademark. After the UCB vs AT&T lawsuit, BSD removed the last remaining traces of UNIX code and was not UNIX.
What kind of nonsense are you spouting? FreeBSD has paravirtualised disk and network drivers for Xen and runs very well as DomU. Dom0 support is a bit less good, but if you want to run FreeBSD guests on a FreeBSD host there is BHyVe.
There are some benchmarks of FreeBSD 7 against Linux of the same era (that graph includes the version of Linux that was specifically released after the previous set of benchmarks showed FreeBSD beating Linux by even more). Both Linux and FreeBSD have improved in SMP support since then, so I don't know how they compare anymore. I suspect that both are in the state where the kernel is not likely to be the cause of any scalability issues that you encounter.
It's also nonsense. The ULE2 scheduler in FreeBSD has very good SMP support. Up to 8 cores, it gives a pretty linear speedup on the MySQL benchmarks I saw. Allegedly it should continue to scale well up to at least 64 cores, but I've not seen any real tests on bigger machines. This has been true since FreeBSD 7, although SMP performance improved a lot in the 8-9 window.
OS X is the only one you can call UNIX. The others are UNIX-like or UNIX-derived (in the BSD case). To be called UNIX (a trademark owned by The Open Group), you must be certified as implementing the whole of the Single UNIX Specification.
I read TFA when it was on OSNews, and it's a waste of space. I was expecting some actual points, but it seemed to boil down to 'I haven't rebooted this machine for three years! FreeBSD is therefore awesome!' When someone talks about uptime, it's a clear sign that they are an idiot: uptime is irrelevant, downtime is important. You can achieve good uptime by failing to install security updates, but it's far better to spend a minute rebooting than to spend a day cleaning up and reinstalling after a machine is compromised.
I have these reasons for using FreeBSD on the desktop:
I don't want to have to spend ages configuring stuff, or learning how to configure stuff. With FreeBSD, the stuff I learned ten years ago is still relevant. I only need to learn new things when there is new functionality. Contrast this with Linux where userspace tools change more often than Paris fashions. Just as you've learned one, it's deprecated, and then replaced by something else.
APIs are well designed and stable. A couple of years ago, I wrote some code for getting the battery status on a variety of platforms. On NetBSD, OpenBSD, and FreeBSD it was a few sysctls and worked on every architecture. On Linux, the interfaces were subtly different on every architecture, but there was a 300KB library that abstracted this for you. The code to invoke this library was more complex than the entire *BSD implementations combined.
Sound Just Works. FreeBSD has low-latency sound mixing in the kernel and has a really amazing implementation of the OSS 4 APIs. Multiple applications can just open /dev/dsp, issue a couple of ioctls() to select the sample rate and so on, and away it goes. I installed FreeBSD on a NAS / Media Center box a few weeks ago. 5.1 sound output in VLC just worked[1], and I can ssh into the machine and run another music player with the display exported to my laptop without needing to close the VLC that has the sound device open to play audio from DVDs, or configure some userspace sound daemon. The kernel just does what a kernel is supposed to do: abstract the details of the underlying system (including the fact that multiple unrelated processes are running) from userspace apps. This was what made me switch from Linux to FreeBSD in the 4.x days - multiple apps playing sound at once was easy. Apparently, three sound daemons later, it's almost easy in Linux, in a hacky kind of way, as long as PulseAudio doesn't hate you as much as it apparently hates most people...
ZFS. Seriously, if you haven't used it then you don't know how awesome it is. Creating new filesystems is as easy as creating new directories. Transparent compression, deduplication, and free snapshots are amazing. Even better is the integration with the ezjail tool, which clones a base system install and creates a jail. This is great if you want to run some untrusted code, or just set up a test environment - it takes a few seconds to create a new, isolated environment where you can test things, break things, and then destroy it when you're done. I've only used it on the most recent FreeBSD machine I've installed, and after a day I started missing it on systems where I wasn't using it. There are some places where it could be better integrated, for example apt-clone on Nexenta took a snapshot, installed a bunch of packages, and then reverted the filesystem if any of them failed - I don't know of any FreeBSD equivalent yet, but hopefully pkg-ng will introduce one.
Capsicum. The first security framework I've seen that is actually well designed. It's in -CURRENT, not sure if it will make it into 9.0, but should into 9.1 if it doesn't. Most of the standard userland tools are being modified to use it, and things like Chromium have already had Capsicum integrated - a tiny diff to do fine-grained sandboxing. An increasing number of ports are getting Capsicum support too, so expect to see your favourite desktop applications start to run with the absolute minimum required privilege soon.
[1] I spent a couple of hours looking for documentation on how to configure it. Then I decided to actually test it, found that it worked already, and felt quite silly.