I use Linux and I have for nearly all of my teenage and adult life. I had a short foray into Solaris; ZFS was nice, and so were the raid tools. Otherwise I found it to be rather tedious.
Tell me, why would I ever want to use one of those BSDs over Linux of some sort? What's the allure?
(Speaking as a FreeBSDer here -- I'll let NetBSD and OpenBSD folks cover those, since I don't follow them closely enough to offer accurate comments.)
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.
I've used FreeBSD for servers and my personal workstation for quite a few years. I love FreeBSD, and the thought of having to support a Linux variant is not a pleasant one. Not that I have a bone to pick with Linux, since I thought it was an excellent OS for the 10 or so years I used it before trying FreeBSD. But once I tried, and became accustomed to, FreeBSD, there was simply no turning back.
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.
The GCC situation is a bit more complicated than that. Importing new versions of GCC is a major PITA due to changes needed in FreeBSD not being accepted into the main GCC tree. We've been saying "gee, it would be great if we could get rid of GCC" since long before GPLv3 came out.
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.
Yeah point #1 is odd. GNU/Linux doesn't let licenses get in the way of technical decisions. DTrace and ZFS aren't in Linux because Sun explicitly designed their licensed to be GPL-incompatible.
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.
Exactly. I always read BSD discussions and think "what a bunch of licensing fanbois". I guess since the OS and the license have the same name...
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.
I'm imagining it. Posting a patch to your website is surely better than rewriting ssh from scratch or licensing SSH.com SSH. (Sure, BSD requires less effort on your part, but the community gets less in return. That's not good for the continued existence of the project.)
How many lawsuits figuring with the GPL have you seen?
I know of a handful and I've read and heard that the focus is not to sue but to educate the companies in compliance.
I'm not convinced this was such a great thing for Linksys, and I always thought it served as a warning to other companies that using GPL'd code can be a bit of a trap.
Furthermore, as far as I understood, it would be impossible to change the Linux kernel license today because of the large number of people involved (also because some authors are dead now).
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 ...
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.
> The effect of Sun licensing dtrace, ZFS and others as GPL-compatible would make Linux more competitive with Sun's Solaris.
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.
> 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.
Sun customers knew and trusted Sun. If they had matched Red Hat and HP/Dell's prices (which they have had to anyway) and actually made Solaris something pleasant to use (like a modern-day Nexenta, but in say 2004/2005) I think the company would still be alive.
Also: Sun never had the opportunity to sue anyone else who made a competing Unix-like OS. If they did, then sure, IBM-type tactic would have certainly held off their competitors.
I'm not trying to be argumentative, trollish, etc. But, really none of those are very compelling and a couple are negatives. I can see 3,4,5 being important if I developed software that is directly affected by any of that. 1 is a political argument and one that I stand on other side of the fence on. 2 just sounds like it takes longer for stuff to be released. 3 meh. 4,5 extra meh. Recompiling is so trivial that not having to recompile is a non-feature. 6. I never groked ports I might not hate it if someone explained it to me. OTOH rpm and apt made sense from reading docs.
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.
But, really none of those are very compelling and a couple are negatives
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.
I don't know, it's not like Linux just lets things in after a week of testing. I understand the need to do things right, but I also understand the natural tendency in developers toward perfectionism. You have to strike a balance -- in some cases Linux may be closer than BSD or vice-versa, but the real thing is that the open-source philosophy of release early, release often is better embodied by something active like Linux.
Well, not really. While the official releases are quite conservative you can follow CURRENT, which is (as the name suggests) the current development tree. It is all out in the open and if you want something which has not been officially released you can get yourself a copy of the source tree, build yourself a new world ("make world") and you have a current FreeBSD (I cannot speak for the other BSD variants here, but I think the process is similar) with all warts and all the new shiny developments. Oh - and all the bugs.
And the Plan9 compilers, the OpenSD team wanted to lose GCC and were considering the plan9 toolchain.
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 :
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.
Point 4 applies as much in Linux as it does in FreeBSD. I've got binaries I compiled against 2.0 and 2.2 kernels in the mid to late 90s that will still run on 2.6 kernels today. Stable userspace ABIs are something that everyone agrees on.
FWIW, and I realize not everyone likes it, but Gentoo goes a long way towards making Linux package management more like BSD ports (AFAICT; haven't used *BSD much). I really like that Gentoo encourages me to build my own (lean) kernel and allows me to pick what configure flags each package gets (instead of giving me packages that include everything out there, like in the .deb distributions).
One nice thing about the BSDs is that their users don't get annoying things like this when they look for basic manual pages:
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.
There is a fair amount of truth in the old joke that BSD is for people that love Unix, and Linux is for people that hate Microsoft. As the name says, GNU is not Unix, and that shows through in most Linux distributions.
That's a bit like complaining that when I use the BSDs they don't have documentation in Microsoft CHM format, or that they put stuff in /usr/local.
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
> Different systems simply have different conventions
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).
> Different systems simply have different conventions, and GNU picked GNU Info over man pages.
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.
> Sure, but that's no reason to be hostile to man pages.
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.
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.
But FreeBSD would not stand in your way if you wanted to take their documentation and incorporate it into whatever format documentation you wanted on your system. The GNU folks, on the other hand, will not allow people to take text from Info pages and incorporate it into BSD or Linux man pages.
At least for tar, the info docs are licensed under GFDL with invariant covers, which is not a free license, and so text from it cannot be incorporated in free works. There's an explanation at the Debian site of some of the problems with the license: http://people.debian.org/~srivasta/Position_Statement.xhtml
> There is a fair amount of truth in the old joke that BSD is for people that love Unix, and Linux is for people that hate Microsoft
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.
Some people don't like to read docs with info(1) for whatever reason. Having the full manual in the manpage instead of giving them a stub would be preferable.
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.
To add to what cperciva said, there's also the difference between the base system (/bin and /usr) and the ports subsystem (/usr/local). Most user space software is in /usr/local, which makes is convenient in that you could always solve nasty library/installation problems by removing /usr/local and starting from scratch.
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.
I used to play the "what distro are we running this week" game. Most were too big, others too small. Some had great communities, but lacked a killer feature. Etc. etc.
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.
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.
Well, I meant in terms of "plug it in and it appears on your desktop". When I'm coding, I don't have a desktop, nor any wish for one. All I do on this box -- by design -- is code and spend too much time on e-mail/HN/reddit/etc.
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.
I figured something like that. I generally avoid using the term 'Window Manager' because none of twm, fvwm, blackbox, enlightenment, etc. only provide window management - there's almost always some included app launcher.
Window management would be required to align the web browser with the terminal windows. A text web browser wouldn't require window management but omits a lot of content.
I used FreeBSD and OpenBSD for a while, and what drove me back to GNU/Linux was package management. OpenBSD was OK at it even if it had a limited selection, but I never had much luck with FreeBSD ports. Having a nice, stable base system wasn't very useful when ports were always being updated to the latest version; if I wanted a security fix, I had to take all the feature changes and new bugs, too. I tried a bunch of different port upgrading scripts but they always seemed to miss something. And upgrading ports took a long time; I want to be using my computer, not having my work interrupted by compiling in the background and occasional troubleshooting.
I have high hopes for Debian GNU/kFreeBSD - the FreeBSD kernel with the Debian package management.
Binary package management in FreeBSD isn't well-advertised, but it's definitely there:
# portupgrade -rvP --batch foo-1.2.3
This will upgrade installed package foo and anything that depends on it using binary packages from the mirror site, falling back on a build from source.
Installing a new binary package:
# portupgrade -vNP bar/baz
If you're using portaudit to stay on top of vulnerabilities (it's part of the default install these days), here's a nice way to upgrade everything:
# portaudit -a | sed -ne 's/^Affected package: //p' | sort -u | \
xargs portupgrade -rvP --batch
I'm like you, for some vulnerabilities I don't want to upgrade a ton of stuff. FreeBSD is perfect for this though, you can just pop into the port directory, "make extract," apply the patch, and "make reinstall." You can avoid full rebuilds by always passing "-W" to portupgrade whenever you install / upgrade stuff.
That example of how to upgrade for security fixes is much more complicated and less reliable than Debian's "apt-get upgrade".
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.
While I'm not as up on FreeBSD, OpenBSD's package management has really improved over a year or so ago - I run snapshots on my desktop, updating the whole shebang every week or two, and "sudo pkg_add -ui -F update -F updatedepends" just updates everything* via binary packages. It updates as smoothly as Debian.
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.
At my former employer, we had the same experience. Upgrading or installing a new package was always a pain and required you to jump through hoops while tracking down all necessary upgrades. And then it still broke. Switched to Debian, never looked back.
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.
FreeBSD 5.x was the learning curve for SMP (and also brought in a lot of other technologies such as power control); there was a tremendous amount of changed code. For some people it worked fine; for many it was pretty rough.
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.
If you want a desktop-oriented BSD "to try" I recommend PC-BSD. It's a very painless install and the whole distribution is geared towards a fairly non-technical user.
This guy sounds plenty technical, though. Also, PC-BSD starts losing the point of the unified system and kernel. It's essentially a FreeBSD fork with more GNU stuff.
I've used FreeBSD continuously (as a server, no GUI) since 1995, with some Linux use here and there, and I find myself leaning toward Linux lately, mainly because Ubuntu has done a lot of great work recently to support Amazon EC2. FreeBSD has fallen behind on Amazon EC2 support for some reason.
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.
I think FreeBSD boxes are generally used as perimeter boxes by most sys admins because of their reliability, therefore compatibility with virtualized environments is not a priority.
We once had some sort of explosion regarding mail-servers at a company I worked for. I have no idea, what the actual problem was, other than too much incoming mail combined with some settings goof. The mail server software ended up eating memory and cpu cycles like crazy. This was on a FreeBSD box. I remember the sysadmin saying "You know, linux would have just OOM-killed it at this point, but its a BSD box so it's doing the right damn thing". Ever since then I've carried around this idea that BSD is stable to a fault :)
Now that EC2 has support for PV-Grub you can almost run FreeBSD there. It would seem the insistence of FreeBSD to be booted from the loader is going to make it hard to run there.
As a Linux user, OpenBSD feels to me like using my father's old tools. They are old, have some funny practices, and aren't always pretty, but they are phenomenally functional, simple, fantastic at what they do, and when used properly virtually impossible to break.
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.
They have a different development model which is not as Linus-centric.
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.
ps. I should add that I really don't use BSD much anymore. The reason is that ease of administration and wider driver support is more important to me than purity of development, and neatness of the user-land.
For that reason I'm using Ubuntu Server for many roles now.
The BSDs always feel beautiful to me. (I'm a mixed GNU/Linux, FreeBSD, Mac OSX user. ) The kernel configuration feels more simple and the official documentation feels uniform, informative, and almost always sufficient.
If more virtualized hosting providers offered BSDs (FreeBSD in particular) I would choose them over Ubuntu for servers.
I had the same dilemma when looking for virutal hosting-I ended up at rootbsd.net because running FreeBSD was important to me. Not as cheap/featureful as linode, but its good enough for rsync.net its good enough for me.
is this true? hot damn, I am behind the times. do you know if it's the paravirtualized kernel? last I checked it wasn't particularly stable... but damn.
They don't officially support it. But they just run a normal Xen setup. Setting up any Xen OS that supports running in domU is relatively easy. There's a few people that have already done it for FreeBSD and NetBSD.
You can try it out locally by setting up Linux and running FreeBSD in domU. Then just transfer that image to Linode.
So, like I do with NetBSD then? well, I guess I actually have the netbsd installer in there.
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.
I emailed them about it after 8 was released-they have a 'non supported install method' for OpenBSD that a forum member wrote. They told me it SHOULD work for FreeBSD, but they're currently not devoting any resources to figuring out how to make it go
huh. the paravirt OpenBSD stuff is pretty old and dead (Theo, uh, is obviously not a fan of virtualization) I'd be interested to hear if anyone has gotten FreeBSD running on linode or another paravirt xen host, though.
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.
I have been an OpenBSD and FreeBSD user, as well as minor contributor, since the mid-90s. All the answers here are good, and I would like to add:
* 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.
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).
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.
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.
>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.
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.
* 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.
You are correct. It would be more accurate to say 'remote attack' with an up-to-date stable release. The point could be scaled back to say that FreeBSD has undergone extensive peer-review and security auditing to the point that the stable branches have not seen a remotely exploitable security vulnerability in a long time.
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.
Okay, yeah, I can't remember the last time there was an advisory about a remote hole in a default FreeBSD build.
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.
This post is awesome, but I do have to argue your point on FreeBSD 5. The release might have been very structured, but for me it was a gigantic clustercoitus that caused me to turn my back on FreeBSD.
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.
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)
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.
I work on both BSDs and Linux boxes and this fact struck me recently:
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.
The Linux numbers were actually taken from Debian. On both families of systems you can decide what to rule out and this is healthy thing to do. But, you know, there's still a difference in thinking. On BSD I'm sure what constitutes a core system and what belongs to the ports -- and that's what I was writing about, not the sum of programs installed but splitting them into sub-hierarchies in a sane way. Such distinction provides a subtle kind of hygiene which occasionally can be a savior. But yeah well it can be appreciated when you just use it for a while.
My main reason for no longer running FreeBSD (which we used for quite a few years) is that since I've switched my desktop environment to Linux I got caught time and again by small differences between the servers running FreeBSD and my dev box. So I switched everything over to Debian or debian derived distros. Ubuntu notebook remix for the laptop, Kubuntu for the desktop and straight debian on the servers.
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.
I've been using FreeBSD since the 8.1 release a few weeks back and as my first *BSD experience it is fantastic.
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.
I like OpenBSD the best of them all. The project has principles and they stick to them. It is simple and understandable and people like Stuart Henderson are very helpful with ports and new developers. It's a much smaller and friendly project than you may believe.
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.
I have an impression that FreeBSD are being strongly supplanted by Linux in these days of virtualization. There were times where jails ruled the parties, but now these days are over and Linux has a number of great virtualization solutions like KVM or Xen while there is no much progress on jails.
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.
I've been using FreeBSD and Linux side by side for about 10 years. FreeBSD appeals strongly to the developer side of me: a typical install puts the complete kernel source code in /usr/src, includes a compiler and other build tools, section 3 man pages, and Makefiles for 20,000+ software packages (the ports system). On Debian-based systems at least, these are things I have to ask for later, and there always seems to be a bit more struggle involved in any given developer setup...it's almost like there's a velvet rope separating users from developers.
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 quite like Debian for development - when installing a new system there's a slew of packages I always add (eg "manpages-dev"), and after that it's plain sailing.
Because it just works. Uptimes are counted in years. Low loads. Great memory management. Ports are compiled for your system from source pretty easily. It always seems able to stretch your hardware's potential. I'd never use it for a Desktop, but as a server, and a dev server especially, it rocks.
If you are using an Apple Mac, then you are using BSD (with bits of Mach and a sprinkling of Apple fairy dust) !
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.
They both use the same collection of GNU tools and open sourced programs like FireFox, Python, etc.
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.
The FreeBSD Portage System kept me there, until ubuntu did something similar, then the community got bigger and faster, then the portage feature + the community was better... so I stayed with ubuntu. Plus, FreeBSD is an ex-girlfriend type operating system now. Sure, you could go back and teach it... but... (I too used FreeBSD since the '90s, for whatever it's worth. Still love it, but cannot justify keeping it foremost. Besides, I use Mac OS X also, so yes, I still use FreeBSD)
Put simply, it's more integrated and unified than most Linux distributions. Instead of packaging this thing from here, that thing from over there, and ramming in this new toy from that place there, everything in each release - tools, userland, ports, kernel - moves in lockstep. The result is an OS that's very consistent once you figure out how it does things, and rock solid stable. It takes a bit more tweaking to get, say, your compositing window manager running - but once you do, you can be guaranteed it will keep running - even when you change or upgrade other things - with all the stupid consistency of a rotating planet unless you screw up and do something very bad. Also, in my experience, it's much more customizable than Linux. The kernel sources are included in the distribution, right there for the building, and the process of configuring and making your own kernel is fairly straightforward, even easy. Contrast with the closest thing I've seen on Linux, Gentoo - which is significantly more involved. That may seem like an obscure point, but if someone walked up to me and told me I needed to put a *nix on a server tomorrow and strip it down to get every last iota of performance out of that server, FreeBSD would be the first thing I reached for.
I've been using OpenBSD for several years (since 3.4...wow, that's almost seven years), as my primary OS. I had been running Debian for 2~3 years, and Red Hat (briefly, ick) before that. A lot has been covered already, but:
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.
> 5. I really like source / ports-tree-based packaging ... Some Linux distros (Arch and Gentoo) have similar packaging systems, now.
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?
While I've done very little with Gentoo, Arch's packaging seemed to me like running OpenBSD's ports tree from cvs, but without the option of an updated-every-six-months super-stable milestone release. It's inherently a "bleeding-edge" distro, which is not necessarily true for OpenBSD. (I run OpenBSD from snapshots/source and update a few times a month, but I also maintain some ports.)
I've only experimented with Arch, though, and I'd also like to hear from others who know both well.
I use both - Arch as a primary desktop and OBSD for my servers.
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.
I have been an Arch user for about 6 months now. jumped the ship from Gentoo. Since I like to stay bleeding-edge, on Gentoo that meant often-broken packages that took a lot of time to fix. Arch has been very smooth till now, despite my using a lot of AUR packages.
Arch user here. The great thing with a rolling release is that when something breaks there is usually a lot of people trying to solve the exact same problem at the same time. I think I learn a lot in problem solving because of that since I switch to Arch! And now every bug is a fun thing that almost never last long, you must be quick if you want to be the first to write the patch who will solve it!
I've used FreeBSD since the mid nineties (it's what I cut my teeth on, Unix wise). I've also been using Gentoo images over at Rackspace for a while now. From a basic standpoint, the two are the same - one command and off it goes, with a well thought out set of "pre-cooked" installations ready to go. However, I have to give Gentoo credit for being a bit smarter about dependencies. On the other hand, the structure for the actual portage tree is....less preferable than FreeBSD's layout for the ports collection. Also Gentoo's portage can "mask" certain builds, basically deprecating them in a way that's really hard to turn off, and that can get annoying at times.
I used to use OpenBSD as a personal mail/web server on a freecycled 486, and decided to go with Linux when I upgraded to newer and faster machines. My rationale was that even though I respect OpenBSD’s security philosophy, if anyone pwns my server, they’re not going to go through a hole in the base system; they’re going to go through a hole in the PHP scripts that run my blog. (Where, oh where, is a featureful blog-server framework that doesn’t depend on PHP?)
For dynamic Web-based applications, what advantages do OpenBSD have over Linux?
The last time I looked at the procedure for running Perl/PHP within a jail, it looked like a sysadmin’s nightmare. Of course, that was a while ago, in the pre-kernel-virtualization era. (There must be a way to run one virtual machine inside another, right?)
That's not correct re File system. Red hat linux usr local has always installed empty. Slash is used for essential binaries, usr for un essential binaries per the fhs.
It may just have been once packages were installed. I started using Unix ten-ish years ago with RedHat, and even as a beginner I saw that using RPMs quickly became a mess of inconsistent paths and circular dependencies. It was sloppy. Not even "bleeding-edge testing release" sloppy, just sloppy.
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).
> It may just have been once packages were installed.
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.
Well, ok, it may have just put them in /etc, /usr/opt, /etc/local, and /moustache. It wasn't that it did or didn't put things in /usr/local, but that there wasn't a consistently followed layout like OpenBSD's (http://www.openbsd.org/cgi-bin/man.cgi?query=hier). Also, like I said - it's probably gotten better since ten years ago. It was really annoying, though, and I'm not misremembering things: I specifically switched from RedHat to Debian because I was sick of it. It wasn't consistent with itself, let alone any standard.
I get that Linux uses a different standard layout than BSD. I really do. The thing is that when I was using RedHat, years and years ago, its paths were not internally consistently.
I'm talking about that specific distro, at that specific time. Debian was much better in that regard, and I didn't look back.
OK. I (and it seems the other poster) knows from our own experience that Red Hat's stuck closely to the FHS for years. There's only one folder - /etc/rc.d/init.d - consistent in Red Hat but symlinked to the correct /etc/init.d location used by other distros - that's been a significant difference in the last decade.
I really like OpenBSD, but if there is one thing I have to point to as annoying, it would be the lack of binary system patches. Call me crazy but I don't feel that I should have to have a compiler and tool chain installed to have an up to date system.
My first unix like system was FreeBSD. I then moved to Linux because it is more widely used and supported.
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 love OpenBSD's philosophy and documentation and enjoyed testing FreeBSD but I always return to Arch for my desktop and laptop and Debian for my servers. Except for two project that are on my todo list for years but never been completed: a router firewall using OpenBSD (with the wonderful PF) and a NTP server using FreeBSD and a GPS with time pulse signal.
I hope someday I will give them the time because I feel that I could have a lot of fun with that.
Doesn't look like anyone's mentioned another unique feature of a BSD: every OpenBSD release comes on a CD with funky artwork, stickers, and an original song. See http://openbsd.org/art1.html and http://openbsd.org/lyrics.html for more.
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.