In Favor of FreeBSD On the Desktop 487
snydeq writes "Deep End's Paul Venezia wonders why more folks aren't using FreeBSD on the desktop. 'There used to be a saying — at least I've said it many times — that my workstations run Linux, my servers run FreeBSD. Sure, it's quicker to build a Linux box, do a "yum install x y z" and toss it out into the wild as a fully functional server, but the extra time required to really get a FreeBSD box tuned will come back in spades through performance and stability metrics. You'll get more out of the hardware, be that virtual or physical, than you will on a generic Linux binary installation.'"
Performance gets eaten by old software (Score:4, Interesting)
Hostile community (Score:2, Interesting)
The FreeBSD community takes a "blame the user" stance that is going to alienate most desktop users, who want to use the machine to get something done and don't want to be held up by snafus that may take days to fix.
Much of BSD's documentation is wrong or vague, many things are still broken within the OS and especially in the parts a desktop user would use, and when there is a problem, there's nowhere to go for a clear, quick solution.
A friend of mine installed FreeBSD on some older hardware and couldn't get the mouse to work. After two weeks of back-and-forth on the mailing list, someone else chimed in that they had the same problem... and then another... and another. It turned out that for the previous for years the FreeBSD community had been screaming "RTFM" at people, when the error was actually in the FreeBSD code.
Most desktop users are going to prefer Linux or Windows, despite the decreased efficiency, because they work and when you have a problem, there are multiple resources so that you can resolve it quickly. With FreeBSD, a broken driver may require 30 minutes to fix, or 48 hours of solid hacking. If you're trying to use your computer to do something unrelated to the operating system, that's too painful of a loss of time.
more stability? (Score:3, Interesting)
Re:Shouldn't Apples count? (Score:5, Interesting)
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.
Re:Shouldn't Apples count? (Score:4, Interesting)
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.
Chroot is just filesystem isolation. It was never intended for security purposes, and can be trivially breached. Jails provide real OS and memory isolation, dedicated addresses, and even dedicated network devices and stacks. It's more analogous to Solaris Containers and Linux LXC.
Having an integrated filesystem and volume manager affords certain capabilities that LVM cannot do. Without looking deeply at the implemented capabilities, BtrFS should be comparable to ZFS. The reason for multiple filesystems is to allow independent management of each. One with primarily text files could have compression enabled. One with important data could specify multiple duplicates, which makes sure those files are stored on multiple zvols in case one fails. If nothing else, it allows you to maintain independent snapshot strategies for different directories.
Re:Shouldn't Apples count? (Score:4, Interesting)
ZFS. Seriously, if you haven't used it then you [...]
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.
The good news is that FreeBSD 9.0 will bring this up to v28, the version used in the last release of OpenSolaris. My home file server is running OpenSolaris with a ZFS v28 storage pool, and I'm planning on trying to migrate to FreeBSD 9.0 as soon as it's out (RC2 should be out any day now, so close...)
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...
Re:Shouldn't Apples count? (Score:4, Interesting)
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.
Re:Shouldn't Apples count? (Score:5, Interesting)
The important part isn't how FreeBSD's ZFS compares with Solaris's; it's how it compares to available Linux filesystems. You're not getting triple parity or dedup support there either. The ZFS v15 is still miles ahead of any stable Linux FS for many applications. Block checksums is the feature I miss most on Linux, with good snapshot support being a close second. v15 may not have the latest snapshot diffs, but it's still better than how Linux's snapshots require LVM to work, and even then are very hackish to use.
Re:Shouldn't Apples count? (Score:5, Interesting)
So true...For me, FreeBSD adoption went like this: Debian eventually became huge stagnant swamp. To get out of it, you had to run unstable. A big mess ensued. Enter Ubuntu, the revenge, the promise. Poor documentation. Installation breakage. 6 months later, upgrade wreckage. Fsck this, I thought.
I have installed FreeBSD once. Ports may take longer, but they are much more current then Debian ever was, and than the current Linux I use, Mandriva. You have to wait for the Package Masters...Also, with ports I have a much more fine-grained control. But let's get this out of the way: you can install packages in FreeBSD, and you do binary upgrades. There are lots of tools to handle ports. With today's speeds and RAMs, it's no big deal compiling ports. Only huge software, such as Java may take many hours (use the weekend or get the binaries and that's that..) FreeBSD takes some tweaking - because all you get is a Unix with no assumptions about what color the user favors, or which icons... -, but it's not a problem for the advanced Linux user (if you're a n00b, then there's PC-BSD, which actually should be the first approach to BSDs for the user workstation these days).
I look at today's Linux and I don't regret my choice. What's the sane choice? Fedora is an experimental platform for Red Hat. That means, from time to time, they'll make you their guinea pigs...Debian can't even be considered secure (no less than twice they had their servers hacked), and who cares about dinossaurs, anyway? Ubuntu's the new Debian. Ubuntu shoves their choices down your throat and continues the Debian tradition of delivering broken software (the new GUI, etc.) and infighting. And Ubuntu is a fantasy. The only reason it exists is because there's a money-loosing millionaire backing it up. The fantasy island one day will blow up in the fanboys' face. Mandriva I find agreeable, but they don't offer many packages, and they have too few commercial partners (so why pay?) Other distros aren't even worth mentioning.
I've used expensive proprietary mathematical software for Linux on FreeBSD, using their Linux binary layer, after the Linux upgrade destroyed library compatibility (they pride themselves in having unstable ABIs).
Linux are a mess. Each one is different, full of stupid little quirks. Libraries differ in place, version, even names. FreeBSD is just as good for the desktop. The system is sane, advances by increments, has documentation, and man pages that are actually worth reading. It's a system where decisions are not made on political bases, but technical. The noise level is much lower. One of the reasons Linux makes much more headlines (besides the PR department from Big Iron, that is) is the constant noise and turmoil. BSDs are not like that...6 months later, you learn they added a cool feature. "Thou shall not fight about bikesheds."
Linux development might get more resources. But, of course it does! Linux was part of a strategy to kill Sun Microsystems and Solaris.