To BSD or not to BSD

After rereading my 1989 UNIX System Administrator’s Handbook, my QUE UNIX Hints and Hacks guide, and my FreeBSD handbook, I wondered why I wasn’t running a BSD box.

I decided to make a list of pros and cons for migrating dustpuppy to BSD

Pros

  1. BSD is a complete OS – Linux distros are customized Linux kernels with GNU and distro-specific apps built around them.  BSD has the BSD kernel and BSD apps.
  2. BSD is Real Unix (TM), not a work-alike like Linux.
  3. BSD is more secure (arguably – this is ignoring SELinux).
  4. BSD has a better TCP/IP stack since it has the original TCP/IP stack.
  5. BSD has better networking and disk performance.
  6. Apache2 runs much more efficiently on BSD.
  7. Samba runs much more efficiently on BSD.
  8. BSD’s kernel is customizable.  RHEL/Centos/OpenSUSE/*buntu is not. (other Linux distros are).

Cons

  1. Migrating to BSD would require a minimum of one day downtime.
  2. dustpuppy’s been a Linux server for all four of its incarnations (first Red Hat 9, then Fedora, then gentoo, and now CentOS).
  3. I would have to scrape the Tux sticker off the front of the case.
  4. I wouldn’t be able to run software RAID-5 on the disks – they’d have to be separate filesystems or two RAID-1 arrays.
  5. I would have to rewrite most of my admin scripts for BSD.
  6. I don’t know if BSD has drivers for my external USB hard drive that I use for backup.
  7. MySQL performance on BSD isn’t as good as Linux (ext3 with realtime block writes isn’t nearly as painful as UFS with write-cache disabled.)
  8. UFS takes forever to finish a fsck run.
  9. BSD runs a full fsck of every filesystem on boot.
  10. CentOS updates are fully automated.  BSD is not.
  11. If you deviate too much from the standard system setup, the ports tree breaks.
  12. J.D. Frazer, my geek idol, hates BSD.

So what do you guys think?  Should I stick with CentOS 5.5 or move to FreeBSD 8.0?

Advertisements
  1. #1 by Chadwick on May 22, 2010 - 1:04 PM

    Well, it’s a bit hard to judge from here…going through your Cons:
    #4 – How much of a hindrance would this actually be for how you use this system?
    #5 – Are we talking 10 hours of work, or 10 days?
    #6 – I assume that can be checked on in some fashion…but maybe I’m wrong.
    #8/9 – I assume that’s “it must complete uber-long fsck before it actually boots”…in which case, I have to ask how often you start the system. If it’s on a regular basis, this might kill it for me straight away.
    #10 – Not really a killer for me. While a server may be different, I generally prefer my updates to be manual.
    #11 – How much are you planning to deviate?
    #12 – With all due respect to J.D. Frazer, fuck J.D. Frazer.

    • #2 by Joshua on May 22, 2010 - 1:53 PM

      #4 – I haven’t decided. In theory, it would be much easier to manage (UFS on top of BSD slices on top of DOS MBR) than the current ext3 on top of LVM2 on top of Linux mdraid-5 on top of Linux partitions on top of DOS MBR). I would lose significant disk throughput as well as losing the ability to survive a disk failure. That said, if I ever get a job, a hardware RAID card and hotswap canister would solve all my disk problems forever.

      #5 – barely two hours of development, maybe a few days of testing since that mostly involves waiting for something specific to happen and seeing if the script reacts to the situation appropriately.

      #6 – Yes, easily on the FreeBSD HCL page. I just haven’t done it yet.

      #8/9 – You are correct in the assumption. Running UFS fsck on the BSD machine at the 440th (on 4x 1.2GB drives) took about 20 minutes total. Granted that was an older machine but from everything I’ve heard, UFS hasn’t changed much since 2001 when I worked there. However, I don’t intend to reboot all that often anyway (4x per year is my target).

      #10 – I sort of agree. Updates to the kernel and core utilities are very rare (once per year or less). Updates to apps like Apache and MySQL are of more concern. On RHEL / CentOS, the updater backs up my current config, stops the service, rolls in the new binaries, backs up the factory config files, rolls in my config files, and tries to start the service back up. If it fails, it rolls back to the first backup it made and restarts the service. But that’s rare – I’ve had several Apache and MySQL updates with no problems so far. On BSD, I would be updating from the ports tree, which means compiling from source. That can be automated to a large extent but I’d still have to stop the service, install the newly-compiled binaries, copy my config files in, and restart the service manually. Not a major PITA but still annoying. Granted, if I were getting paid to do this, I totally wouldn’t mind doing the Right Thing and testing all updates in a sandbox first. But I’m not getting paid to admin this box and I can’t afford a testing server right now.

      #11 – As little as possible so it shouldn’t be an issue.

      #12 – Lol.

      • #3 by Chadwick on May 22, 2010 - 3:34 PM

        In that case, I’m voting to swap to BSD. At least, if you’re in the mood to deal with it, which you may not be.

        • #4 by Joshua on May 22, 2010 - 3:57 PM

          Since the disk issues are yet unresolved in the absence of a RAID card, I think I’ll wait until I get a job and said hardware since I’d have to reinstall the OS anyway, and then install BSD instead of CentOS. So for now, I’ma stick with CentOS.

  2. #5 by Phillip on May 22, 2010 - 1:05 PM

    I figured it this way:
    Do you need the efficiency gains?
    Would the switch from striping to mirroring affect the performance more than the efficiency gain?

    I know that I’m not really the one to say to keep it the same since I know I’ve changed stuff that works just to have it work better. It’s a tough call really.

    • #6 by Joshua on May 22, 2010 - 1:55 PM

      No. I don’t need the efficiency gains. I actually just underclocked the aging CPU to get more stability under load.

      And I think that it would be a tradeoff since I could run the SATA pair off of the Northbridge and the PATA pair off of the Southbridge and keep the PATA pair for the OS and the SATA pair for user data (NAS, FTP, WWW, MySQL). It would be interesting to benchmark two mirrored pairs with one striped array with parity (RAID-1 vs RAID-5)

  3. #7 by Joshua on May 22, 2010 - 4:00 PM

    Someone voted “other” but I don’t see any comments suggesting what that “other” might be.

    • #8 by Matt on May 24, 2010 - 10:54 PM

      Windows Server! Make sure its NT.

      And you port forward.

      Yeah, that sounds good… 😉

      • #9 by Joshua on May 25, 2010 - 7:48 AM

        I’m tempted to treat this comment as spam…

        And yes, I used to have a Windows 2000 Advanced Server box acting as a scanning and imaging server since the network support in SANE wasn’t up to par yet. It is now.

        I’m not a Linux zealot to the extent that many think I am. I do use Windows for some things, mainly when the Linux alternative is nonexistent or horribly inferior. The best example is world design for Steam games. Yes, steam runs on Linux but the Hammer editor and successors and accessory tools did not at the time I was doing world design so I used Windows for that.

        • #10 by Chadwick on May 25, 2010 - 8:51 AM

          I assume you mean it runs under WINE?

          • #11 by Joshua on May 25, 2010 - 9:09 AM

            Yeah but that’s soon going to change. 🙂

          • #12 by Chadwick on May 25, 2010 - 10:10 PM

            Oh I know. If the right games start becoming fully Linux-viable, I’ll have no real reason to return to Windows anymore.

  4. #13 by Andrew D. on May 26, 2010 - 3:13 PM

    Please define Pro #8. To me, “customizable” means getting a vanilla kernel, manually patching it, and compiling.

    I’ve never had a problem building my own kernels on any of those distros, and I’ve used 3 of the 4 mentioned (not RHEL).

    • #14 by Joshua on May 26, 2010 - 3:57 PM

      That’s indeed what I mean. I stand corrected on the ‘buntus – they didn’t use to support the option of DIY kernels. They apparently do now. And OpenSUSE makes it downright easy to compile a custom kernel – it’s in the official doc. So the only distros that don’t let you are RHEL/CentOS and SLES/SLED. So Pro #8 is pretty well void.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: