Slashdot Mirror


In Favor of FreeBSD On the Desktop

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.'"

3 of 487 comments (clear)

  1. Re:Shouldn't Apples count? by TheRaven64 · · 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.

    --
    I am TheRaven on Soylent News
  2. Re:Shouldn't Apples count? by TheRaven64 · · Score: 5, Informative

    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.

    --
    I am TheRaven on Soylent News
  3. Re:Shouldn't Apples count? by greg1104 · · 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.