Comment by forkqueue | Hacker News Reader

Comment by forkqueue | Hacker News Reader

Parent Full thread

A reasonable summary, but one that demonstrates some misunderstandings of the Linux world. To deal with the issues point by point:

* 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.

* That point about performance was more about FreeBSD being first with a lot of performance and security improvements. As I said, this argument was a lot easier 5-10 years ago but doesn't apply as much anymore.

* 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.

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

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 worst that can happen is porting GCC features over to a GPL-licensed Clang fork.

It's not a catastrophe. It's just more work. Which was my point.

It could actually be quite bad - maintaining a large featureset like this in a fork would probably cause major problems. Fortunately GCC compatibility is listed as one of the official goals of Clang.

I find that last line entertaining considering I feel the exact opposite way about linux and the utterly chaotic development model they employ.

I always feel like I'm building my castles on quicksand.

Reply on news.ycombinator.com