Tell me, why would I ever want to use one of those BSDs over Linux of some sort? What's the allure?
1. We don't let licenses get in the way of making good technical decisions. This means that, for example, we had no problem with importing DTrace and ZFS.
2. We have more of an emphasis on doing things right. This often means that it takes longer before we acquire new features; but it means that once we acquire new features, they work and aren't likely to be removed or completely rewritten any time soon.
3. We develop the kernel and userland in tandem. This allows new features in the kernel to be accessed from userland faster (usually immediately) whereas in Linux there will often be a significant lag time before your libc supports everything in your new kernel.
4. We have stable development branches, and we're serious about them. Not "stable" in the linux kernel sense of "we think this won't crash" -- stable in the sense of APIs and ABIs, so that code you compile on FreeBSD 8.0 will work without recompiling on FreeBSD 8.4 five years later.
5. Our stable branches apply to the kernel, too. You can compile a kernel module for FreeBSD 8.0 and use it on later versions of FreeBSD 8.x, too -- linux, in contrast, has on occasion broken kernel ABI compatibility in security patches. ("Gee, do I want to apply this security patch, or do I want to keep using the video card driver supplied by my vendor?")
6. Personally I greatly prefer the FreeBSD ports tree over the linux equivalents, but that's just a matter of taste and what you're used to.
Turning Plan 9 from open source into Free had plenty of teething troubles, getting the lawyers from Bell-Labs then Lucent then Lucent-Alcatel into the idea took years. Originally Plan 9 was paid for software with full source included. Then from v.3 it was a free download but with its own license which included a "if you make modifications you must send your changes back to Lucent".
Then it was lobbied for change and to comply with US munitions law Lucent included the export restrictions proviso OpenBSD's Theo so eloquently argues against :
http://groups.google.com/group/comp.os.plan9/browse_thread/t...
Ironically the compiler suite became available under GPL / MIT via Vita-Nuova who bought the rights to Inferno.
Licensing helped keep Plan9 away from developers at exactly the same time GNU/Linux and OSS exploded on to the scene in much the same way early adopters got interested in GNU/Linux it during the BSD / AT&T lawsuit.
How our computing landscape would be different if we all valued freedom.
However, I take issue with your #1 bullet point above. If the FreeBSD camp truly was about the technical stuff, we wouldn't be stuck with a crusty, substandard version GCC in the base system.
For those not in the loop, the last GCC version with a GPLv2 license was 4.2.1 (from 20070719 according to "gcc -v" on my 8.1 machine). Due to not liking the GPLv3, the FreeBSD developers have stuck w/ this old GCC version, denying users the current set of optimizations and architecture support.
Sure, we can use GCC from ports, but that's not officially supported for the base system or the ports tree. True, they're working on getting the clang LLVM front-end to be the official base system compiler, it'll be 5 to 10 years before it's as stable and usable as gcc is today.
But that is about my only gripe with FreeBSD, and as far as gripes go, it's a relatively minor one.
Where that isn't the case nobody is seeking to replace code due to license reasons. E.g. you don't see Linux people trying to replace X11 or Sendmail because of their licenses. But the BSD systems are actively trying to phase out GPL licensed code due to not liking the license.
Anyway, here's why I support Linux and the GPL: the WRT54G. Linksys would have never released the source code for the router's kernel without being forced to. But when they did it, an amazing thing happened, third-party developers made their product one of the most popular wireless routers ever. With open source, everyone benefited -- users got better products, hackers had fun, an d Linksys made more money.
If Linux was BSD-licensed, the WRT54G would be a long-forgotten relic of the past.
This is a pot-kettle situation if there ever was one.
The effect of Sun licensing dtrace, ZFS and others as GPL-compatible would make Linux more competitive with Sun's Solaris. That's clearly undesirable. Sun faces a lot of competition from IBM and HP, both with offers to migrate to AIX/HP-UX and to Linux on x86 hardware. Enhancing Linux was a big no-no for them.
Yes
> That's clearly undesirable
Why? Sun's been bleeding customers towards Red Hat and (to a far greater extent) Novell since the early 2000s. Holding onto the Solaris/SPARC combo in the hope the high end customers would the be last to leave (which they were, but sooner than Sun expected) killed the company.
Giving Dell all the tools to fight SPARC/Solaris effectively would only kill it faster.
As a high-end hardware manufacturer, they were pressed from below by Linux on cheap x86 hardware. One possible solution would be to press back with SPARC/Solaris hardware at x86 prices. Sticking to the high-end may be a good strategy, but that's why IBM does not make an x86 version of zOS.
And that's why they lawyer to shreds anyone who tries to sell and support zOS on emulated zSeries hardware.
Relicensing linux is not an option, whether you believe GPL is good or not.
There are solutions to this, but you have to act in advance: for example if you want to contribute code to the clojure open source project, you have to sign and send by snail mail a contributor agreement (http://clojure.org/space/showimage/ca.pdf) which regulates the ability of the project funder some freedom in relicensing.
btw, this formality, especially the printing and snail mail thing, actually stopped me from contributing my code to clojure-contrib. You know, I just wanted to quickly share a bugfix, I don't know in advance how much involvement I will have with something which starts only as a side effect of my job
furthermore since I made the contribution during my daily job, my company itself would have to sign that contract etc etc, licensing some stuff with GPL is one thing, granting unrestricted sublicensing right is a different issue ...
GPLv3 caused Apple to support LLVM development, which caused LLVM to be production-ready; and that combined with the general crappiness of gcc is causing FreeBSD to switch to LLVM. The licensing issue is a slight irritant, and without it we might have ended at 4.3 or 4.4 instead of 4.2.1; but it's certainly not the biggest issue.
My point is, isn't there anything else? Cause if that's it, I totally understand the respective "market share" FreeBSD and Linux have.
btw I've used OpenBSD for public facing firewalls way long ago cause it's security emphasis was a huge feature over Linux.
For you, that might be entirely true. We're not fanatics; we have no trouble accepting that for some people FreeBSD isn't the best OS for every task. There are FreeBSD developers who are perfectly happy using Linux, OS X, OpenSolaris, and even Windows on a daily basis.
This attitude demonstrates a pretty significant lack of experience.
Your reading comprehension needs improvement.
The GNU folks, in general, abhor man pages, and create info documents
instead. The maintainer of tar falls into this category. This man
page is neither complete, nor current, and was included in the Debian
Linux packaging of tar entirely to reduce the frequency with which the
lack of a man page gets reported as a bug in our defect tracking system.
If you really want to understand tar, then you should run info and read
the tar info pages, or use the info mode in emacs.
Problems with this man page should be files as bugs against the Debian
tar package, not submitted to the tar maintainers.
Curious... I always thought BSD was for people who hate GNU, Linux, the GPL... ;-)
The wise route out of this problem is to create an info2man utility that converts info pages into man pages. Can't be that hard, can it? And, once you learn your way around it, info is much nicer than man. It's sily to hang on to 60's tech when there is 70's tech available.
It's odd that Debian doesn't simply use it instead of creating their own bastardized manpages of GNU programs.
A man2info tool and linking man to info would solve the problem just fine.
The GNU folks, in general, abhor man pages, and create info documents instead. *Unfortunately, the
info document describing tar is licensed under the GFDL with invariant cover texts, which makes it
impossible to include any text from that document in this man page*. Most of the text in this document
was automatically extracted from the usage text in the source. It may not completely describe all
features of the program.Different systems simply have different conventions, and GNU picked GNU Info over man pages. That bastard GNU tar(1) man page was created because Debian has a policy that everything must have a manpage.
I like Unix, but the GNU Info format solved some real issues with man. It has built-in index and cross-reference metadata, scales to the size of entire books (the FreeBSD manual would be a single info page), and is much easier to write. I much prefer reading info pages to man pages for that reason.
A lot of people seem to dislike GNU info because they confuse the GNU TexInfo / info format with the info(1) program. I'm not a big fan of the default reader (I use the Emacs one instead). But the TexInfo format can be exported to multiple formats and read by multiple programs. Here's the exported GNU Tar documentation for instance: http://www.gnu.org/software/tar/manual/index.html
Yes, but one OS should not have two different conventions.
(I'm actually a GNU user, but they fucked up here - if they wanted to promote info, the man binary should just direct you to the info page, and fall back to man - avoiding horrible situations like this).
Sure, but that's no reason to be hostile to man pages. Ideally you have a man page, which provides a standard quick reference for those how know the command, and then other documents (such is Info) for people who need more detailed information, complete manuals, etc.. In fact, that's how it was way back in the Seventh Edition days of Unix, with the UPM providing the in-depth documentation and the man pages providing the quick reference.
If the GNU people don't want to actually write the man pages, they could at least not stand in the way of those who would like to provide them. Here's another variant of the note from the GNU tar man page on some Linux systems:
The GNU folks, in general, abhor man pages, and create info
documents instead. Unfortunately, the info document describing
tar is licensed under the GFDL with invariant cover texts, which
makes it impossible to include any text from that document in this
man page. Most of the text in this document was automatically
extracted from the usage text in the source. It may not completely
describe all features of the program.They're not being hostile to man pages. They just don't maintain them. They're no more hostile to man pages than FreeBSD is to info pages.
> Ideally you have a man page [...]
That doesn't sound very ideal. man pages and info pages are formatted differently and take a different approach to explaining things. Having both would mean that the maintainer of each package would need to expend effort on maintaining both.
As an example. Here's the FreeBSD strlen() manpage: http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=strle...
And the equivalent section in the GNU libc manual: http://www.gnu.org/software/libc/manual/html_node/String-Len...
On FreeBSD I'd do `man 3 strlen' at the nearest terminal. On GNU I'd do `info libc' followed by `m string<TAB>' to find that node.
You can't easily turn that documentation into a man page. E.g. on FreeBSD you'd have one manual page for malloc(3), but in the libc manual the documentation for malloc and other allocation functions is part of an entire chapter on "Virtual Memory Allocation And Paging". You can't easily tear that out into a man page.
> They could at least not stand in the way of those who would like to provide them.
Well, would the FreeBSD project stand in my way if I started sending them patches to duplicate their documentation in some new format like GNU info or perldoc? Probably yes.
Documentation isn't a one-off thing. It incurs a long-term maintenance cost. So it's best to pick one system and stick to it.
And really, it's not too much to ask that you just familiarize yourself with the conventions of the OS or system you're using. To stick to just ways of reading documentation I use man, info, perldoc, rdoc, phpdoc, javadoc, online tutorials etc. regularly.
The whole of userland and the kernel can also be built with a single command ("make world"). The code is often beautiful and easy to read (my alma mater taught a graduate OS Case Study class where the textbook was "Design and Implementation of FreeBSD" and assignments involved fixing bugs in the FreeBSD kernel) and you get a chance to play with some interesting things (DTrace and ZFS).
It really depends on what you're looking for. If you're going to deploy a production web app it may or may not be the best choice (I honestly don't see a big advantage). FreeBSD once used to be lauded for network performance and while it's still excellent, Linux has caught up. Depending on what you're doing e.g., a distributed storage or processing cluster, it may well be worse than Linux (but again, benchmark and stability test it yourself before taking my word for it).
If you're curious about operating systems (or are interesting in building your own custom OS without licensing issues e.g., what Juniper did with JunOS), it's perfect.
Then I found FreeBSD. The learning curve was steeper, you had to know more about how things actually worked under the hood (a plus, in my book) and the system was elegantly clunky.
A cohesive whole -- more or less -- instead of endless re-packaging of the same things.
I do a minimum install, then build my system up from the ports system. (Ports is like apt-get, pacman, other package management systems. Compiling from source can be a bitch, but only for big things -- Emacs, X11, Firefox etc. but it allows unparalleled customization, or at least the option for it.) Installing binaries is also an option if you don't want to compile.
It has had every piece of software I've ever needed (minus http://joey.kitenet.net/code/mr/) already in ports.
I even recompiled my first kernel within three days of starting out (thanks to Absolute FreeBSD, by Michael W. Lucas), something that seemed a dark art on GNU/Linux.
I've had no stability problems in the last year or so, and I just upgraded from 8.0 to 8.1 smoothly. Everything important on my laptop is supported.
If I want shiny stuff like webcam, usb auto-mounting, all that, I reboot into Ubuntu. Not because FreeBSD can't (I'm mostly assuming), but because this is my dev box and I'm not supposed to be doing anything shiny or distracting on here, hehe.
In short, think of an older truck with a manual transmission -- it's dependable, gets you there and back with minimum of frills and you can tinker rather than a new SUV with bells and whistles. While FreeBSD is more angled towards servers, I love it as a desktop OS -- at least for coding and light web browsing.
And it's a single community, without the balkanization of GNU/Linux.
If I need to work with a digital camera or a flash drive, I just reboot into Ubuntu and do it quickly there. FreeBSD is strictly for work (in theory).
I've only mounted stuff under FreeBSD maybe once in the past year or two, so it isn't even on the list for me.
So, from my point of view as a software developer who lives in Firefox and Emacs, it's shiny. Others differ. But for me, it's not required, at all.
How do you read docs without a web browser?
It does, but after using one for a while, most of it seems superfluous.
X alone doesn't provide that -- think back to Windows 3.1 days. You had a background, but not a desktop.
I do have a desktop background, though I rarely ever see it.
What I meant was I don't have a desktop in the Windows/Mac OS X sense -- a place with icons, documents, mounted drives and the like.
FreeBSD, OpenBSD, NetBSD, Dragonfly BSD, BSDI, Darwin, PCBSD... ;-)
The Linux kernel isn't (at the moment) balkanized.
I have high hopes for Debian GNU/kFreeBSD - the FreeBSD kernel with the Debian package management.
Also, in 7 years, I've never had package updates break things on OpenBSD (aside from config file formats changing or postgres database transfers, with warnings at update). That happened to me a couple times with Debian (around woody).
* except for my ports that haven't made it upstream yet.
# portupgrade -rvP --batch foo-1.2.3
Installing a new binary package:
# portupgrade -vNP bar/baz
# portaudit -a | sed -ne 's/^Affected package: //p' | sort -u | \
xargs portupgrade -rvP --batch
For example, take a Firefox or PHP security vulnerability. Those projects generally don't just release a new version with the security fixes; they'll throw in whatever feature changes they've made along the way. I don't want to sort through the various changes and patches to find the right combination; trust me, it's no fun, I worked on the Debian security team for a while. It's important to me to get just the security fixes because I don't have time for a constant upgrade treadmill and there will be new bugs in with the new features.
I really want my operating system to just work and get out of the way. If I didn't need any packages from ports, I think FreeBSD would fit that bill.
The primary functional differences are a more mature code base (I didn't say more technically advanced or superior) and in general a unified system. What most people have come to know as "Linux" or "GNU/Linux" is a kernel mashed together with the GNU userland. And most distributions then further pile things onto it, kind of assuming they know what kinds of things the end-user will want to do, and picking a few applications that will help the end-user accomplish those tasks. Maybe it's Gnome, OpenOffice, Firefox and Pidgin.
The BSDs provide a system. The kernel and userland are maintained and enhanced by the same group of people. There's a bit more control in what's provided in the base system.
After installing Free/Net/OpenBSD Users are generally left with a text-mode login console where a small subset of non-BSD-based things are installed but often not active. X.Org may be ready to go, as may Apache, lynx and some others. In the case of OpenBSD, these tools are often patched considerably before packaged with the base OS.
Want something other than twm for your Window Manager? Want a graphical web browser? An office productivity suite? You can install them easily via binary packages, or use the ports system.
If you've used Gentoo or Arch Linux, you will probably find that the ports system (/usr/ports/* if you installed it) is familiar.
I use OpenBSD quite a bit, even on the desktop. It's fast, free, and very robust. It's also probably the most strictly audited operating system code base in existence. Those guys (like me) are pedantic when it comes to security.
I highly suggest you fire up one of them (OpenBSD or FreeBSD, I'd suggest) in a VM and give it a shot. VirtualBox is free. NetBSD is primarily geared toward maximum portability between hardware platforms. I personally think that's the only thing it's got over OpenBSD.
I used to be a FreeBSD fan before 5.x. The team had a really rough time after Jordan left for Apple. I became disenchanted and haven't really given it the time of day for almost a decade now. It's probably a fine OS.
The decision for 5.x was to gamble that single-core systems were going to become less important than multi-core systems, and that FreeBSD should push to optimize for the latter. Around the 7.0 timeframe, that promise finally started paying off. By that time, performance and stability on SMP were on a par with what 4.x had had on single-core.
Let's put it this way: there were no tears shed when 5.x went EOL :-) (fwiw, the last maintenance release of 5.x was in 2006.)
For anyone whose last experience was 5.x, 8.1 will be a difference of night-and-day.
I was initially attracted to FreeBSD because I had first learned Unix on a BSD system in the late 80s, and the more restrictive licensing terms of Linux made it difficult for my company to use it.
So unless you have a specific need like ZFS or liberal licensing terms, I can't think of a reason for a long-time user of Linux to switch to FreeBSD. Similarly, unless you have a specific need like Amazon EC2, I can't think of a compelling reason for a long-time FreeBSD user to switch to Linux. Both are good, solid systems with some minor individual strengths and weaknesses.
Similarly, OpenBSD is sometimes trailing in features, and as a desktop with a pretty UI and all the most recent packages, it did very poorly. But as a server, IMHO it is fantastic.
To give you an idea of the beautiful simplicity; the OpenBSD install environment is... a kernel. You download a kernel that's a couple of megabytes, boot it as if it was any other kernel, it asks you for your install source, and then continues with other questions. That's it.
The user-land and kernel ship together as a more tightly integrated package.
In terms of performance, I found that the linux kernel is often optimised for bandwidth at the expense of latency.
eg#1, When the system is under heavy memory pressure, Linux tends to grind to a halt and start killing processes randomly, where FreeBSD responds more gracefully.
eg #2, In highly-threaded environments (eg, 32 or more cores), Linux doesn't really work very well unless you pin processes to specific CPU cores. In fairness, BSD doesn't perform much better, but at least avoids pathological cases.
For that reason I'm using Ubuntu Server for many roles now.
If more virtualized hosting providers offered BSDs (FreeBSD in particular) I would choose them over Ubuntu for servers.
I don't see it in their 'distro manager' thing
You can try it out locally by setting up Linux and running FreeBSD in domU. Then just transfer that image to Linode.
freeBSD 8 requires at least xen 3.3 to run in paravirt mode; this is why it won't work on ec2, so I don't know if that counts as a 'normal xen setup' -
The thing is, last I read FreeBSD8 was not stable under paravirt xen, and I was hoping to hear this had changed. Also, last I remember, it didn't work at all with more than one vcpu.
In that case I might as well give a shout-out to my current VPS host, ARP Networks:
http://www.arpnetworks.com/vps
They virtualize using KVM rather than Xen, so you can run any variety of OpenBSD, FreeBSD, NetBSD, or Linux without worrying about Xen support in your guest OS. Their performance seems as good as any other VPS host I've used (Xen or otherwise), I think the price is pretty good, and I haven't had any downtime to speak of so far. So I recommend giving them a try if you're looking.
* FreeBSD is on the cutting edge of performance. Because it is a total OS (as opposed to just a kernel), performance improvements are made and integrated into the binary packages and ports build options of common packages. FreeBSD was one of the first operating systems to implement kqueue, which is now available on OS X. This was part of the reason why for years FreeBSD dominated high-performance web serving. If you asked this question 5-10 years ago, the answer would simply be 'FreeBSD performs a lot better than Linux with web serving', but that is not as true today since Linux has caught up in the 2.6.x branch (with epoll). For more info see the classic: http://www.kegel.com/c10k.html
The good servers like nginx and varnish take advantage of these performance benefits that FreeBSD offers.
(there was a similar system here with the virtual memory manager, while the Linux kernel struggled with this issue ~01-02 FreeBSD was miles ahead). FreeBSD is the starting and development point for a lot of new technologies.
2. Everything is done the BSD way, from directory layout to the rc.x startup system. It is the same and uniform and integrated with the kernel and doesn't vary across releases. There is a single reference handbook, and POSIX compliance. I have always preferred the BSD way of file system layout, and that is what I have become accustomed to. (ie. /usr/local/ really is usr local).
3. The BSD's are a monolithic kernel (which Linux is today, mostly, if you choose to) which has performance implications. FreeBSD support kernel modules, but the monolithic approach is preferred. It is very easy to build your own custom kernel (I suggest you do for servers) and the defaults are include nothing and build what you need from there, which provides a very small, fast and optimized kernel image. Linux distributions tend to take a 'kitchen sink' approach, since they are aimed at people who don't want to compile and load a kernel module for device XYZ. FreeBSD places the onus on the user to know what they are doing - which forces you to understand the internals of the operating system and how it works. Linux usually has different distributions depending on the target, but FreeBSD is flexible enough to only have a single distro that can be customized from a 20MB install image through to a desktop system that will support your Chinese webcam when plugged in. It can do this without compromising on performance or bloat. I suggest you start FreeBSD with the minimal binary install plus the ports tree (the ISO is 50MB, install is about that).
4. You can take this one 'distro' and way of doing things across a multitude of architectures.
5. jemalloc - a virtual memory manager for parallel processing that outperforms Linux, see: http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf
6. The GCC compiler and toolchain are steadily being replaced by the less bloated and much faster Clang/LLVM which are part of Xcode and BSD licensed. It allows much better IDE integration, is modular and a lot lot faster than GCC. Clang/LLVM are already at the point now where they can compile all of FreeBSD
7. The TrustedBSD event auditing, ACL, stack protection, other security features and OpenBSM make FreeBSD orange book compliant in terms of security. OS X also has this (it is the same security model). This is important if you are in a corporate environment and need to stamp some certifications or meet compliance regulations with the systems you choose.
8. Zen and VMWare virtualization support available in kernel. Virtualization support is very good in Linux, but the virtualization providers have been supporting FreeBSD for a while now, and have hired core team members to develop software. EC2 needs better support, but I am sure it is coming.
9. Linux has abandoned the development branch approach (ie. 2.7.x) and instead trails along 2.6 releases with releases candidates. With FreeBSD you can be assured that STABLE is stable and CURRENT is current. Releases are taken very seriously, as can be seen by FreeBSD 5 (one of the best OS releases every, IMO) took years to finalize. Point releases are binary and API compatible with .0 releases (ie. 5.5 binaries are guaranteed to run on 5.0)
10. You have linux binary compatibility anyway, at near-zero cost.
11. A more liberal license to use in commercial environments (ie. if you sell a firewall, or an embedded device, no need to release your own code - Apple have done this spectacularly).
12. ZFS (works)
13. Excellent handbook that encompasses the entire operating system: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
14. Average knowledge of a FreeBSD/OpenBSD community member is higher than Linux (personal experience) and since there is usually only one way of doing things, you will find consistant answers and advice on your questions or issues across the web.
15. FreeBSD hasn't had a default install, STABLE security advisory in ~10 years.
In conclusion, if you like to know what is actually happening on your server or machine so that you can tweak, optimize and better understand performance and other issues, BSD will almost force you into understanding it. If you are running linux and just downloading and installing binary packages, you are simply unaware of what is happening on your system (no different to running Windows, really). BSD will teach you the old school UNIX way of doing things, is consistant throughout and through just using it it will teach you a lot more about your system and operating systems in general than Linux.
You make several good points here, but I'm not sure what you mean by that one.
Consider the most recent advisory, FreeBSD-SA-10:07.mbuf, listed here:
http://www.freebsd.org/security/advisories.html
default install: yep, kernel mbuf code
STABLE: yep, FreeBSD 7.1 and later
security advisory: yep, privilege escalation
in the past 10 years: yep, three weeks old
That said, FreeBSD doesn't excuse sysadmins from not being vigilant with monitoring advisories and keeping their systems up to date. Nor does it prevent vulnerabilities being introduced through installed userland software or other applications.
One benefit would be that with patches and ports, you can patch any vulnerability in a service without being forced to upgrade to a new version that might have incompatibilities with your system or that might introduce performance degradation.
You see this all the time with PHP, sysadmins run binary upgrades on the packages because of a security vulnerability, only for the website to spit out a bunch of warnings about functions that have been deprecated in the new version.
You credit FreeBSD's "extensive peer-review and security auditing" for this... do you have more information or links about that? I know the FreeBSD folks have been proactive about fixing security bugs, and conservative in their default build design, but I haven't heard about their peer-review and auditing.
sudo pacman -S virtualbox-ose* FreeBSD has better performance than Linux? This is, as you almost concede, no longer true.
* Lack of kernel modules an advantage? Hardly. Linux loadable kernel modules produce no extra performance overhead, but make life a lot simpler for everyone. The only extra 'bloat' is having ~100MB of drivers of which you probably only need 10% or so. If this an issue for you (ie, you're running an embedded system) you can of course cut down the modules to only those required, or even compile into the kernel just as with FreeBSD.
* The GCC compiler and toolchain aren't optimal, and I fully expect a major Linux distribution to switch to Clang/LLVM in the not too distant future. If this is a success (and I expect it to be), I wouldn't be at all surprised to see most/all Linux distros switch. This isn't a Linux vs FreeBSD issue, this is GCC vs Clang/LLVM - a battle I believe Clang/LLVM will win.
* As far as I'm aware TrustedBSD offers no more features than SELinux, and the Linux ACL system, but maybe I'm showing my lack of BSD knowledge here.
* Xen and VMWare virtualization is there but not 100% in FreeBSD. They're rock solid on Linux, which also has KVM, a very viable alternative to the two.
* The development branch/stable kernel approach is irrelevant - people don't use Linux, they use a Linux distribution (OK, OK, a GNU/Linux disitribution :)). In most distributions point releases are binary and API compatible with .0 releases (RHEL 5.5 binaries are guaranteed to run on RHEL 5.0).
In conclusion, is FreeBSD good? Undoubtedly. Is it better than Linux? It's hard to make a case for that. It has less device support, less software support and a massively smaller user base.
FreeBSD is nice to tinker with, but it doesn't offer enough benefits to justify putting production software on it. It's great to learn about the old school UNIX way of doing things, but that's not what I want to be doing on a live server.
Have you looked through the Linux kernel code? There is a lot of gcc specific stuff in there. I don't think the Clang change will be as fast as you think.
* The Mono vs Micro kernel debate between Linux and BSD doesn't apply as much anymore since they both support both. With Linux is varies a lot between distro vendors. Vendor kernels also tend to lag behind the main branch (at least this is my experience, mainly with Debian and Fedora). I find that FreeBSD, as a distro, allows easier kernel optimization especially since the default kernel is tight. Again, this is something that on the Linux side of the argument is the responsibility of the vendors, who approach the issue by providing targeted server and desktop distributions (most do). You are right though that there is very little performance diff between Micro v Mono (see the classic debate from when Linux was announced: http://oreilly.com/catalog/opensources/book/appa.html). I have always preferred only having code on the server that is required by the system (code coverage), and the FreeBSD way of doing this is managed better than any of the Linux distros, IMO.
* As somebody mentioned below, the Linux kernel is very much tied to GCC and its toolchain. It is so tied to it that the Intel compiler uses the Linux kernel as a test for its GCC compatibility mode.
* A BSD port of SELinux is actually part of TrustedBSD, which has in-turn been ported to FreeBSD. There are a bunch of other things that TrustedBSD entails, I can't name them off the top of my head atm, but both SELinux and TrustedBSD line up with orange book
* You are correct that the stable/release cycle of Linux is more up to each distribution, but since there is a step between kernel and distro (which FreeBSD as a total operating system doesn't have) there is a lag there, and a risk of support ceasing (or patches/updates/support suddenly becoming a commercial service, as it did at Red Hat)
In the end it depends on how you define 'better'. It is tiresome to enter debates about benchmarks and features, it is what you are most comfortable with. If you want to hack at a UNIX operating system that is very neat and cool, FreeBSD is a very good choice. If you like knowing what every file and every command does on your system, and prefer a UNIX-like uniformity in how things are done, then FreeBSD is again a good choice.
I would thoroughly recommend all hackers try out FreeBSD and become familiar with it. It will alert you to why some things are done the way they are, and there is a very deep history in that operating system, so at times it feels like opening a time capsule.
Add to that, if you need an OS for commercial purposes, FreeBSD is free as in 'do whatever you want', which can also be an advantage.
I always feel like I'm building my castles on quicksand.
Do you use the default install? Even OpenSSH (which would be in the default install of Linux) is from ports IIRC.
Each time i've tried a "stable" release right out the gate (5.0, 6.0, 7.0) I have had numerous random crashes and bugs in the default install. I always have to wait a few minor revisions for the bugs to be worked out. Of course, i'm a Linux guy, so maybe i'm doing something wrong.
Just one of the many annoyances: The package manager would attempt to use gunzip on the new packages which had been tar/bzipped and thus binary package installation was completely borked for a good while after release. I ended up having to manually patch the package utils.
I agree with everything else. It's amazing how Open, Net and FreeBSD work together on a lot of things, particularly hardware support and userland performance. The BSD Way (all of it) is a great comfort to me, and knowing The BSD Way ahead of time really helped me out when I went to start working on big enterprise platforms like Solaris and AIX. I fear many GNU/Linux admins would take much longer to adapt to how things are done on those platforms than someone with a really solid BSD background.
for i in /bin /usr/bin /usr/local/bin; do ls $i|wc -l; done
Linux: 124 2155 67
FreeBSD: 44 430 1067
On BSD, you clearly see which programs are essential for your system to be up & well, which are service additions and which are 3rd party stuff (yeah I missed sbin but you see the picture). On Linux there's a big bag of /usr/bin and a beginner can have no clue if some stuff is important or not.
And the sources. On BSD, sources of kernel all system programs are at your disposal in /usr/src and that's it; they represent a coherent view of what meat you have running. On Linux of course you can download the sources and most probably your distro will help you with obtaining the right version. But it isn't the same when you hit the problems, esp. on production. Well even without the need of fixing anything or tracking problems, the sources serve a great educational value with an immediate availability.
In general, the BSD approach seems to come from a longer experience of establishing best practices. I'd say the principle is the same with Linux and BSD, but the devil (pun intended) is in the details, and BSD details look as better engineered for many.
[edited for clarity]
That's installed as a desktop about a month ago, with all the basic stuff I need installed.
Other than that, my experience with FreeBSD is that it was absolutely rock solid and bullet proof, uptimes of many years with machines pumping out data at a pretty decent clip for the time we're talking about.
*BSD is not always as fast with supporting the latest hardware or adding a new feature or technology but what's done stays done. Linux tends to yoyo for a bit before settling.
The only thing which will keep me from committing to it is the absence of a stable and/or official version of Google Chrome (the only freebsd versions of Chromium I've found have been very much alpha software).
I (like a lot of people I suppose) spend too much time in my browser to have this be a negotiable point.
I have been very much impressed by the cohesiveness of the platform (akin to what Ubuntu has achieved on the linux side) and the documentation is fantastic so if you're a FF user anyway, go for it.
It's not in the tree yet due to some licensing problems that need to be sorted out. The newest shar file as of this writing is here: http://chromium.hybridsource.org/chromium-stable-125.shar.tx...
Theo and Ted and Marco and OGA and all the other devs are great and they are all very open about everything they do. I only have one majpr concern with OpenBSD:
* Multiple CPUs/Cores
With the lateral move by Intel and AMD to more and more cores rather than more hertz the future of CPU processing seems very clear. The problem is that OpenBSD has primitive SMP support, and is nowhere near FreeBSD or Linux. It's hard to find single core servers these days and in a few years, 12 or 16 cores will probably be entry level and 48 to 64 will be common... maybe more.
In short, I hope OpenBSD can keep up with multiple CPUs/cores. Otherwise it will seem just wrong to load it on new servers.
If they do not keep up, I would still buy the CDs to support the project and its many side projects (OpenSSH, OpenBGP, OpenNTP, the new smtp system, etc.). Even if you, as a Unix user absolutely hate OpenBSD for whatever reason, you should still buy the CDs to support OpenSSH.
Also, for some reason it's not very popular in enterprise despite of API and ABI stability, i.e. one could hardly find enterprise products like e.g. IBM WebSphere available on FreeBSD. One probably could use Linux ABI support but I'm not sure how reasonable that is.
I used to work at ISPs few years back and FreeBSD was very popular in this circles. At one place we had FreeBSD running on absolutely all servers and in other one we had only one RHEL box which was a requirement for some VoIP billing.
About two years ago I moved to a software development organization which is quite close to enterprise and virtualization and I've seen 'live' FreeBSD only once and the folks are going to migrate to Linux in the near future (I don't know what their reasons are though). And that's quite sad because I really like FreeBSD.
Maybe other developer-centric Linux distros have caught up in certain ways; I'm actually quite interested in hearing more about them. With FreeBSD though, the low barrier to development has always been there, and when you dig deeper, you'll start to feel like part of a great tradition.
I'm over simplifying, but with Linux or BSD it's really only about the kernel. They both use the same collection of GNU tools and open sourced programs like FireFox, Python, etc. Package management is more a distro issue, than a Linux vs. BSD issue.
If you want to customize your kernel for a specific server configuration, then one of the BSD's might be more optimal. However, if you just want something that works with most devices, especially notebooks, then Linux has a larger collection of drivers.
http://events.ccc.de/congress/2007/Fahrplan/events/2303.en.h... http://vimeo.com/6955695
This is incorrect. BSD systems for the most part eschew GNU tools. You will find many annoying differences in programs you take for granted like find, xargs, ps, top, etc.
1. The BSDs feel significantly more cohesive to me. Other people have mentioned this, but it deserves greater emphasis. The config files, man pages, etc. are quite a bit more consistent, and my first guess about where something is located is nearly always right. Red Hat, in particular, seemed to cavalierly scatter things in /usr/bin, /usr/local/bin, /usr/local/sbin, etc. (Around 7.0, IIRC.) The man pages & other docs are consistently excellent, for everything from malloc to spamd, it's a cleanly and consistently designed system for learning Unix / system administration.
2. OpenBSD has a focus on security. While this isn't my top priority, personally, I really like its secondary effects - it tends towards minimalism, so there are less dusty corners to harbor exploitable bugs, and they pass security patches upstream. OpenBSD's malloc (http://www.openbsd.org/cgi-bin/man.cgi?query=malloc) can also be configured for very aggressive scrutiny. Not quite the same as running everything under valgrind, but it has also much less overhead since it's better integrated. If you're working in C, it's a great platform.
3. I can install and configure an OpenBSD system in under ten minutes, easy. Its installer is spartan and based on text prompts. Once you know what to expect, it's a snap. Also, they put all recognized drivers in the kernel (ostensibly since debugging weird custom-kernel issues would be tough with a smaller community) - if the dmesg doesn't say "... - not recognized" at boot, you're usually set. No rebuilding kernels or modules just to get things working. I haven't dealt with much really weird hardware, but any random crappy old x86/amd stuff has worked fine. (Cheap old Thinkpads run BSD brilliantly, by the way. I'm typing this on a T41.)
4. The BSDs have less GNU stuff in the userland. This is probably a matter of taste, but a lot of the GNU stuff seems really bloated by comparison - gmake vs. BSD make, gawk vs. awk, etc. (That said, I'm also an Emacs user. :) ) The BSDs also seem less political. It isn't Linux or GNU/Linux, it's just BSD.
5. I really like source / ports-tree-based packaging. You can still use binary packages (especially if you're installing KDE, doing that from source is just silly), but ports+flavors works quite well. Some Linux distros (Arch and Gentoo) have similar packaging systems, now. Of course, some programs are hard to bootstrap - GHC, in particular, has lagged behind.
I've only used FreeBSD a bit here and there, but it also seems like an extremely solid OS, and most of the same advantages apply. It doesn't have as much focus on security, but its community is much larger, and it's probably more newbie-friendly.
FreeBSD user here. I've always been curious about the ports-tree-based packaging systems found in these Linux distros. Is anyone familiar enough with both to offer a comparison?
I've only experimented with Arch, though, and I'd also like to hear from others who know both well.
For all practical purposes you are correct.
I personally think of Arch as a collection of components loosely put together, you pick and choose what you want and they generally work together, there are no releases per-se, stable or otherwise. OBSD is a more coherently designed and engineered system, if you want a particular feature that is available in a new release , the logical way to get it is to update to a new release. If you don't want it , you can simply stay on your release and just apply the rare security patches that come through.
The situation has probably improved, but I moved on to Debian, then OpenBSD. I'm still happy with OpenBSD, but my next choice would probably be FreeBSD, Debian, or Arch (in that order).
The whole OS is packages. The first thing that goes on a new system during the OS installer (anaconda, again more than 10 years old) is the glibc package. 10 years ago I assure you no package of the thousands included in Red Hat Linux put something in /usr/local.
* Config files go in /etc.
* Spools, caches an so on go in /var
* Binaries for all users go in /bin if they're important, /usr/bin if they're less so
* Binaries for root go in /sbin if they're important, /usr/sbin if they're less so
The standard was mature a decade ago and long before then. I suspect you just may have not been used to the standard.
I'm talking about that specific distro, at that specific time. Debian was much better in that regard, and I didn't look back.
For dynamic Web-based applications, what advantages do OpenBSD have over Linux?
You could run your blog stuff chrooted / in a process jail, either way.
I still have a sweet spot though for FreeBSD. The main reason is that they have figured out the perfect balance of how much to include without being overwhelming. It is also a great learning system because FreeBSD forces you to understand all the pieces of *nix.
I hope someday I will give them the time because I feel that I could have a lot of fun with that.
Personally, I like both OpenBSD and Arch Linux.
This question reminded me of this episode.
I'm kidding.
The cathedral nature of BSD likely gives it a security edge.