FreeBSD 8.2 Released 183
meta coder writes with word of the release of FreeBSD 8.2: "This is the third release from the 8-STABLE branch which improves on the functionality of FreeBSD 8.1 and introduces some new features. Some of the highlights includes improvements in Xen support and various bugfixes."
Either or.. (Score:3, Insightful)
Re:Why use FreeBSD when you can use Linux? (Score:5, Insightful)
Well if you're going to put it this way, it's probably better to ask why OpenOffice isn't a good enough alternative to MS Office and why Linux gaming is so lackluster.
The answer is money. Oh, business customers pay well to have their servers supported so the kernel, network stack, server software, databases etc. is in tip top shape. But the desktop? Very little. Of course open source isn't all about the money, but there's the stuff everyone want to do and there's the drab stuff no one really wants to do. Microsoft and Apple pays people to do a *lot* of boring shit, so do the application developers out there. Ubuntu and friends not so much, least not on the desktop side.
Small money adds up, Angry Birds have now grossed $50m on $1 sales. But most people in the open source community would be violently opposed to a "if you like it, pay a buck" attitude. The software is free/Free/gratis, you pay for service & support. Except I've never wanted nor needed any kind of service or support for Angry Birds and if I did I'd probably declare the game broken and move on. I'm not saying you would be a multimillionaire out of it, but it would help if developers could make a living writing desktop apps. Or at least pizza and beer money. But neither the system nor the attitude is in place.
Re:Why use FreeBSD when you can use Linux? (Score:4, Insightful)
Where does Linux fail where BSD succeeds?
Sound. I switched to FreeBSD 4.x almost a decade ago, when Linux had two sound stacks. OSS didn't support sound mixing, ALSA did, but needed apps rewriting for it. So you needed a userspace sound daemon if you wanted more than one app to play audio at once. Some of my apps used the GNOME one, some the KDE one, and some just opened /dev/dsp. With FreeBSD 4, you could set up multiple /dev/dsp.x devices, and set each sound daemon or app to write to a different one. With FreeBSD 5 (2003), each device that opened /dev/dsp got a new audio channel. Multiple apps all playing audio just worked.
With FreeBSD 8, the sound system added full OSS 4 compatibility, and a few things that the 4Front OSS implementation lacks. It also added a new sound mixing algorithm, which has even better performance. Oh, and per-channel (i.e. per app) volume control. From a developer perspective, audio is simple: open /dev/dsp and write audio data, with a few ioctl()s to tweak parameters. No libraries to link, no complex APIs, it's simple to use. From a user perspective, there's no messing around with sound daemons, no dependencies, stuff just works. Every time I hear a Linux user complaining about PortAudio, I wonder why they're still bothering with Linux.
What else? Jails are useful - lightweight VMs that cost about as much as a chroot. The ez-jail port uses union mounts to allow you to create new jails in a few seconds, with about 5MB of disk space each. It also integrates with ZFS, so you can use ZFS cloned volumes instead.
From a developer perspective, BSD libc is a lot less painful to work with than glibc. The system actually comes with documentation - compare GNU/Linux man pages with their FreeBSD equivalents some time. There's also the fact that FreeBSD doesn't change user-visible interfaces without a good reason. If you learned how to use FreeBSD 2.x, most of that knowledge is still valid. New stuff gets added, but the older stuff still doesn't get changed randomly. You may get new implementations of features, but they're exposed using the same set of commands or the same APIs.
Not sure about performance these days. Last benchmarks I saw showed FreeBSD outperforming Linux. Not sure if this is still the case. I did some tests recently for a course that I'm teaching, with large numbers of threads and found that Linux seems to have much lower defaults for the maximum number of threads - not sure what the FreeBSD limit was: Linux was running out of threads but with 64 times more, FreeBSD was still going.