Edit: Not sure if you're aware, but the paypal donation mechanism is triggering your spam detection:

This is an automated message.

The message you sent (attached below) requires confirmation
before it can be delivered. To confirm that you sent the
message below, just hit the "R"eply button and send this
message back (you don't need to edit anything). Once this is
done, no more confirmations will be necessary.

Also, it's encoding non-alphanumerics within the ASCII range in the forwarded message from Paypal. For example, "$" is being encoded as "=24", which makes it look like Paypal took two orders of magnitude more money than donated.

The problem was that paypal payments come in "from" the donor rather than paypal, and paypal was exempted but not all e-mails that were from paypal but listed as from the donor. This has now been solved.

It is only the 9th. Look at the marks of this year against prior years:

December 09, 2012: $260k ($500k goal)

December 14, 2011: $210k ($400k goal)

December 16, 2010: $210k ($350k goal)

Early Dec, 2010: $195k ($350k goal)

December 26, 2009: $250k ($300k goal)

It looks like the last weeks of December are a big time for donations, and they're seeing an early surge relative to prior years. It surprises me that FreeBSD is even this well-funded. Who still uses it?

I too would be interested, I was at NetApp when they acquired Spinnaker which was using Linux and that product was ported over to FreeBSD. That said NetApp has been a huge supporter of getting solid NFS support in Linux both through the pNFS effort and the work that was done at Citi/UMich.

That post is 6 years old and ONTAP has been through at least 3 major releases since then.

Additionally, the post states that the purpose of ONTAP on Linux was to simulate ONTAP for testing & education purposes. In 2006 this was probably the easiest way, but those needs have been met for years by the VMware images NetApp provides.

I heard during some NetApp training I took (not certain how authoritative my instructor was)that Data OnTap was a customized version of FreeBSD 4.x, which has long since been EOL. While I believe NetApp did contribute back some things to the FreeBSD tree way back in the day, I would guess they haven't in many, many years (but that's pure speculation on my part).

Quite the opposite, in fact. NetApp have contributed BHyVe (http://bhyve.org/ / http://wiki.freebsd.org/BHyVe), a full BSD-licensed Hypervisor, in the last year. They make regular contributions to several network card drivers and other low-level code. At least one or two FreeBSD committers are full-time members of NetApp staff.

> The NeXT and Rhapsody kernels used NetBSD as the basis for their BSD subsystem

NeXT started in the mid-80s (I first used a NeXT cube in 1988), and ceased to exist in 1996. NetBSD didn't exist until 1993...

[My impression is that NeXT for a long time used the same "non-server" version of Mach that was generally used at CMU at the time (BSD code originally derived from 4.3BSD still in the actual kernel, not as a separate subsystem).]

>My impression is that NeXT for a long time used the same "non-server" version of Mach that was generally used at CMU at the time (BSD code originally derived from 4.3BSD still in the actual kernel, not as a separate subsystem).

Right, NeXtStep was derived from Mach 2.5 which had a 4.3BSD emulation layer (still running in the kernel though) on a Mach "not yet a microkernel" (Mach transitioned to a full Microkernel in Mach 3.0 when the BSD emulation moved out from kernel to userspace). When it became OS X, the BSD emulation layer was updated to 4.4BSD (from FreeBSD) and the Mach part was updated to Mach 3.0. As an aside, Apple even experimented with a Linux Emulation Layer on top of a real Mach Microkernel (mklinux http://en.wikipedia.org/wiki/MkLinux) and as the work done in bringing this up actually was put into getting Mach upto 3.0 on xnu (along with the BSD update).

The other Unix which derived from Mach 2.5 was OSF/1->Digital UNIX->Tru64 UNIX.

Nice to see that the amound they manage to get seem to increase (which I admit is a guess but the numbers wouldn't make sense otherwise as they wouldn't keep asking for more if they didn't manage to get what they asked for or close to it).

Do we really need FreeBSD anymore when we already have Linux? I am genuinely curious from a technical point of view what important differentiators there are in FreeBSD,i m not interested in license or philosophy differences.

FreeBSD is a more centralized and more methodically developed operating system. It shows in a few important aspects: just about everything in the core system has a high quality man page -- the most significant difference being the kernel drivers, which have near to no accessible documentation in Linux.

The kernel and the core user space are developed together, which leads to better compatibility between these two.
FreeBSD usually supports 1-2 old major releases, which is an obvious good thing for servers.

ZFS and jails. BSD license. Competition. The open source world will be a lot poorer if it will consist of only GNU and Linux.

If I may be a bit less serious, I feel that there's a competition between two philosophies of software projects in the OSS world: one is "lets hack lol" and the other one is a more methodological, thoughtful way. Examples: MySQL & Postgres; ruby & python; Linux & BSD. It seems obvious that neither way is absolutely superiour.

A comparison of Linux and FreeBSD is a legitimate, interesting question, but I don't think this is the place to raise that issue.

The open-source community is strengthened by its diversity. Linux may be more popular, but that's no reason to weaken another, similar project by not supporting it financially. Personally, I use FreeBSD and I like it. I also know that Linux is available as an alternative, and I like to know that should I ever become dissatisfied, I have alternatives I can switch to. Supporting the FreeBSD Foundation is one way that you can feel safe in the knowledge that there'll always be an alternative to Linux should you become dissatisfied.

Please don't let one project be hindered by another project's success.

We need FreeBSD the most because of both license and philosophy points of view, and Linux has still a lot to learn from the BSDs from a technical perspective, too.

The only thing that keeps me using Linux is that nowadays a significant portion of self-proclaimed Unix software is in fact mostly Linux software with absolutely no interest being compatible with other Unix systems.

And let me add that the community around BSDs are far far greater than any of the Linux ones I've come across.

I've been under the impression that Linux's packet filtering options weren't as capable as BSD pf in years past but I know that, particularly as of 3.0, a lot of work has been done in this area. Would be worth researching but I haven't done it yet.

Well the ZFS is a particular case as it was deliberately licenced to be incompatible with Linux licencing as Solaris was suffering from competetion with Linux and Sun obviously didn't want to give away a competitive advantage to it's main competitor.

I'm a primary Linux user myself, but I think it's a good that we have other alternatives too. Competition is what makes the world go around, having alternatives is good. Also, if there are more targets, people tend to write more portable code.

a) because he disqualifies the license as a reason, even though it is actually the reason GNU came to be, without which what most people call "Linux", that is - GNU/Linux would have had little to stand on. So license on its own is an interesting enough reason.

b) because one second of googling would have shown that FreeBSD has numerous technical (his criterion) things that Linux does not yet at a comparable level, including (from the top of my head) ZFS, jails, dtrace.

d) because there are also things which are not license or technical details which matter (project management style, for example)

Comments like the GP can alternatively be phrased: "I'm a bigot about reasons things happen in the real world, and also I'm too lazy to look up if what I believe is actually true. Lazyweb, prove me wrong", and it would get about as many downvotes.

Comments like yours can be phrased "I'm a hateful liar who reasons that unless you blindly accept certain opinions as fact, I'm going to assume that any questions is bigoted. I'll also knowingly require that you search using Google, claiming that you'll find an answer there, though when someone does search, it will immediately discredit my comment. After all, if it only took a second, I could have provided the link that answered the question."

So, by all means, provide the search we should have used that explains what and why the technical advantages of FreeBSD over various Linux distros. It only takes a second.

Well, it took me all of 3 seconds to google "why choose freebsd over linux", and a few more to verify that most of the results I get on this page are relevant. Your google-fu may be weak, or duckduckgo may be.

Tip: if you are in search of information, rather than self-confirmation, try to prove the opposite of what you believe, rather than search for confirmation to your ideas, or even "balanced" info (because you are ALREADY biased, and you need to counter that bias).

Don't attribute your own faults to others. You seem to do a lot of that in your post above.

I was tempted to reply to the original question because it implies that there is (only) one correct way to build an operating system, and once you've arrived at the correct answer any duplication of effort is pointless. I find that a quizzical approach.

I suspect the downvotes come from the way 'diminish' phrased the question. Linux is implicitly being used as the standard against which FreeBSD is measured, but the question implies ignorance of FreeBSD. Imagine the tone of the responses if the OP has written, "I know linux but not FreeBSD. From a technical perspective, where do they not overlap?"

I get the feeling[1] some of the down votes probably come from people who would rather not have every BSD topic plagued by HN's version of the slashdot.org "BSD is dying" meme. It subtracts from the discussion at hand and given "i m not interested in license or philosophy differences" part - the poster didn't really want an honest answer anyway.

Okay, really, GP asks a genuine question, and you respond with this kind of misinformation? On the off chance that you're actually this confused - or on the likelier chance that someone else comes by and takes your comment seriously - let me make some corrections for you.

> There is no such thing as a vanilla Linux you can run

The phrase "vanilla Linux" doesn't even make sense. Linux is a kernel, not an operating system. If you're talking about the entire GNU/Linux operating system, it doesn't make sense to talk about a "vanilla" version, because there are thousands of different utilities that can comprise a GNU/Linux-based operating system, and there are combinatorially many ways to create a Linux distribution.

That's like saying that there's no "vanilla" BSD - only [Open|Free|Net]BSD - except worse, because some of the Linux "distributions" are really no more different than adding an extra package (eg, KDE) to an existing distribution and giving it a different name. It's as if you called BSD by two different names depending on whether or not you pre-installed Emacs.

> All the distros that have varying degrees of incompabilities and infelicities between each other.

This is vastly exaggerated. A properly compiled binary or a compatible source file should run on any distro - not just any modern distro, but any older one as well (assuming that it has the correct dependencies installed, etc.).

> And every now and then some figure who knows which political strings to pull uses that clout to load your favorite distro with pre-beta crapware.

If I wanted to get really snarky here, I'd say that the same thing could happen to BSD too and point to OS X. This is just ridiculous - Linux is open source and free-as-in-freedom, so just because somebody else packages your favorite distro with some stuff you don't like doesn't mean that anybody else has to as well - you can just as easily remove it and create your own "distro" as a fork.

I disagree that the GGP asked a genuine question (I've posted about this earlier), but just wanted to point out that the "genuine" question was about FreeBSD in particular, not BSD, and you're replying about BSD vs. Linux, rather than FreeBSD vs. Linux, so a bit of your answer is misdirected. That said:

> If you're talking about the entire GNU/Linux operating system, it doesn't make sense to talk about a "vanilla" version, because there are thousands of different utilities that can comprise a GNU/Linux-based operating system, and there are combinatorially many ways to create a Linux distribution.

That exactly WAS the GP's point about the difference, I think, and exactly what he said: There's no "vanilla Linux" you can run. There is a "vanilla FreeBSD" you can run. That's a huge difference.

> > All the distros that have varying degrees of incompabilities and infelicities between each other.

> This is vastly exaggerated. A properly compiled binary or a compatible source file should run on any distro

That's NOT vastly exaggerated. While it is usually possible to do so, it is usually painful unless you start from a source package. If you have a binary rpm or deb and want to install it on a distro it was not intended for (not easy even if its the same format, often hard if it's a different format), you have to be very familiar with both package standards to make it work. "alien" helps, but if your package has lots of dependencies, you really need to know what you are doing.

>That exactly WAS the GP's point about the difference, I think, and exactly what he said: There's no "vanilla Linux" you can run. There is a "vanilla FreeBSD" you can run. That's a huge difference.

Linux is the kernel, vanilla Linux would be the Linux mainline.

>That's NOT vastly exaggerated. While it is usually possible to do so, it is usually painful unless you start from a source package. If you have a binary rpm or deb and want to install it on a distro it was not intended for

The one you are responding to was talking about binaries, why are you conflating that with rpm/deb package formats? Like the aforementioned poster said, as long as dependancies are met there would be no problem running binaries across Linux distributions.

Without an "init" process (or equivalent), of which there is no vanilla, that's about as good as a power-on-self-test. So, yes, technically you can run a "vanilla Linux" kernel, but not a "vanilla Linux" system, because there is no such thing.

> The one you are responding to was talking about binaries, why are you conflating that with rpm/deb package formats?

I think you are misinformed. Both rpm/deb ARE binaries. You (and poster) might have meant "executables", which I didn't really pay attention to because it's a strawman. "Well, you can run a staticly linked executable!". Duh. It's likely output will be "can't find /var/share/blahblah" because there are very few standalone binaries these days. Once you have 2 files (even if they are statically linked binaries), there are assumptions that must be made about where files other than the binary can be found - is it /etc like LSB, or /package like djb or whatever GoboLinux is using, or whatever NixOs is using. Practically, anything you want to run is going to need some setup - a setup which package managers provide.

Furthermore, even textual executables cause problems: It's been a while, but a few years ago, you might get a script that hashbangs "/usr/bin/perl" where your system only supports "/bin/perl". It's easy to fix, either in the script or by making perl available in the other place - but, as I mentioned before, it is only easy if you know a lot about how the system works.

> So, yes, technically you can run a "vanilla Linux" kernel, but not a "vanilla Linux" system, because there is no such thing.

This is kind of quibbling over a comparison between apples and oranges - or rather, more like comparing apple seeds to an entire orange. Whatever a "vanilla" kernel is, it doesn't make sense to compare it directly to a "vanilla" operating system.

> I think you are misinformed. Both rpm/deb ARE binaries. You (and poster) might have meant "executables", which I didn't really pay attention to because it's a strawman.

You won't run into any problems if you have EITHER:

1. A properly compiled static binary
2. The compileable source code

Because of Debian's policies regarding open-source software, in practice #2 will be satisfied for any .deb package you care about.

It doesn't make sense to complain about improperly built packages or build files, because I can easily create a build process that will fail on some BSD systems and not others too - there are many ways you can either accidentally or intentionally hardcode system-specific attributes into a script; the filesystem layout is only one small portion of compatibility.

> It's been a while, but a few years ago, you might get a script that hashbangs "/usr/bin/perl" where your system only supports "/bin/perl". It's easy to fix, either in the script or by making perl available in the other place

There are more elegant ways of fixing this too. In practice, though, it's not a problem. Not only are there tools that will automate this process, but very few scripts are written this badly nowadays anyway. I run a distribution that doesn't use one of the common package formats, and I can't remember a single time in the last two years I had a problem binary portability because of distribution-specific issues.

The one you are responding to was talking about binaries, why are you conflating that with rpm/deb package formats? Like the aforementioned poster said, as long as dependancies are met there would be no problem running binaries across Linux distributions.

Of course there would be. The glib from debian is not the same as the glibc from red hat, despite the name.

>> If you're talking about the entire GNU/Linux operating system, it doesn't make sense to talk about a "vanilla" version, because there are thousands of different utilities that can comprise a GNU/Linux-based operating system, and there are combinatorially many ways to create a Linux distribution.

> That exactly WAS the GP's point about the difference, I think, and exactly what he said: There's no "vanilla Linux" you can run. There is a "vanilla FreeBSD" you can run. That's a huge difference.

If I want to use the FreeBSD kernel, I have many choices of distribution: FreeBSD, PC-BSD, Debian GNU/kFreeBSD, etc.

If I want to use the linux kernel, I have many, many, choices of distribution: Red Hat, SUSE, Debian etc.

> This is vastly exaggerated. A properly compiled binary or a compatible source file should run on any distro - not just any modern distro, but any older one as well (assuming that it has the correct dependencies installed, etc.).

Yes, if you feel like spending two hours compiling some code and twice that to debug some issues with the bug system on your repo. Fortunately this does not happen a lot, but it happens. Most of the things that are not in the package repositories for your distro is going to give you a hard time (6h install time might be reserved for extreme cases tough, if you are a seasoned linux veteran).

> Most of the things that are not in the package repositories for your distro is going to give you a hard time (6h install time might be reserved for extreme cases tough, if you are a seasoned linux veteran).

Honestly, how often does that really come up? This is one of those horror stories that I always hear people (particularly BSD users) telling, but I've never had problems of this sort[1].

I run a distribution which doesn't use deb/rpm packages, and I compile things from source all the time. The vast majority of the time spent is the sheer compilation process, not debugging any local problems.

The only times I've had issues with binaries are with sloppily compiled executables - and it's not worth complaining about those, because there are a hundred different ways that sloppy code can be incompatible with two different systems running the same distro.

A static

> Btw, I suppose the problem is the same between the different BSDs.

Yes, and frankly, if you have a piece of code that is architected to work on at least one Linux distribution and at least one BSD or OS X, I have a hard time imagining that it would fail on other Linux distributions as well.

If it's not "cross-NIX", then it's probably something that only makes sense in the context of your distribution anyway (say, a patch for your package .manager) or a small, one-off that is easily modified.

>The phrase "vanilla Linux" doesn't even make sense. Linux is a kernel, not an operating system. If you're talking about the entire GNU/Linux operating system, it doesn't make sense to talk about a "vanilla" version, because there are thousands of different utilities that can comprise a GNU/Linux-based operating system, and there are combinatorially many ways to create a Linux distribution.

The point is, when it breaks and you need someone to help you fix it, it's often not enough to find someone else who "uses Linux" - you need to find someone else who runs the same distribution, because they all have their own init scripts, packaging systems, filesystem layouts etc.

By contrast, because there is a single FreeBSD, anyone who "uses FreeBSD" can probably help you with your FreeBSD problems.

(Of course, if you choose a popular linux like Ubuntu, there are probably many more people who "use Ubuntu" than use FreeBSD)

>This is vastly exaggerated. A properly compiled binary or a compatible source file should run on any distro - not just any modern distro, but any older one as well (assuming that it has the correct dependencies installed, etc.).

Seriously? I don't think I've ever seen a cross-platform binary that worked without distro-specific hackery. Source sure.

>If I wanted to get really snarky here, I'd say that the same thing could happen to BSD too and point to OS X. This is just ridiculous - Linux is open source and free-as-in-freedom, so just because somebody else packages your favorite distro with some stuff you don't like doesn't mean that anybody else has to as well

You're right - but there is some truth to the generalization that linux distributions a) rush in software before it's truly stable (Debian stable being the exception that proves the rule) b) are more politicised than FreeBSD. The recent Gnome 3 / Unity fuss would be unthinkable in FreeBSD-land. In the time it's taken Linux to go OSS -> ALSA -> PulseAudio (and say what you like but I know several people whose sound broke with each of those) FreeBSD has stuck with OSS. Linux introduced devfs, encouraged users to migrate, then deprecated and killed it off in the space of about 18 months (in favour of udev); FreeBSD has only ever had one devfs. FreeBSD ships binary compatibility going back to at least version 5, while very few linux distributions still ship glibc5 libraries. In FreeBSD I've never had a driver that used to work stop working (under linux I used the qc-usb driver, which then stopped building against newer kernels; also the drivers for my PDA (sc-somethingorother)).

> The point is, when it breaks and you need someone to help you fix it, it's often not enough to find someone else who "uses Linux" - you need to find someone else who runs the same distribution, because they all have their own init scripts, packaging systems, filesystem layouts etc.

Again, greatly exaggerated. I'm usually able to use Ubuntu or Fedora forums to help solve my problems, even though I don't run a Debian-based distribution. If I'm having systemd problems, I can debug that the same way as with any system running systemd, whether it's Fedora, Red Hat, Arch, etc. If I'm having issues with my package manager, I can use resources from any distro that uses that same package manager.

You're assuming that these variations cause combinatorially many possibilities for problems, but in reality, Linux is designed to be modular enough that these things don't compound in practice.

That's not even taking into account that most Mint issues have the same solutions as they would on Debian/Ubuntu, etc., because most distros are derived from one of a small set of distros; very few start 'from scratch'.

> By contrast, because there is a single FreeBSD, anyone who "uses FreeBSD" can probably help you with your FreeBSD problems.

Yes, but NetBSD and OpenBSD? Not so helpful. And frankly, given the relative sizes of the Linux and BSD userbases, this isn't really a problem on Linux at all.

Define scalability please. If we are talking about single system image scaling up, such as a SGI Altix monster, nothing but Linux will run on it. I'm sure ill be proven wrong, but I'm unaware of a modern general purpose operating system that runs on > 2048 CPU beasts other than Linux. Certainly not Solaris. If we are talking about scaling out horizontally, Linux is the defacto tool for most supercomputer clusters in the top 500 supercomputer list. Heck, solid SMP is still a relatively new thing compared to Linux. When I see "scalability" touted as a feature any of the other 'nix or bsds have over Linux, I really question the other person's definition of scalability. It likely is not the same as mine.

You may not be interested in license differences, but many downstream vendors are. Several have a "No GPL-3 code past the front door" policy, and others would even like to not have GPL-2 code near their products. FreeBSD's active progress towards being entirely GPL free is very appealing to these people.

FreeBSD has made significant progress here, and 10.0 is on-track to be GPL-free for all tier-1 platforms, including:

* Clang/LLVM rather than GCC

* New BSD licensed toolchain

* New text processing tools (sort, grep, etc)

* bsdtar - since picked up and used by several other operating systems

pkgng is basically the next upgrade from the current package system/ports tree to having the possibility of having a full binary only system. pkg allows you to manage your packages using repositories that can provide your software, much like apt-get. On the plus side, you also get the power of the ports tree, so you can very easily compile newer packages yourself and host them as a repository, especially if you have to manage multiple FreeBSD systems.

* FreeBSD supports ZFS, whereas Linux can't really due to license issues. (Although people have tried-- please don't reply to me saying "but XYZ got it to run!" It's a legal issue that's not going away.) However, Linux has btrfs, which delivers a lot of the benefits of zfs. However, btrfs is not really at the same level of stability yet (although it may get there soon.)

* For its audio drivers, FreeBSD uses a descendant of OSS, whereas Linux moved to ALSA and later PulseAudio-over-ALSA. I have heard claims that OSS4 provides lower audio latency. I am not an expert so I cannot evaluate those claims. On the other hand, Linux also has JACK, an alternative sound API which is supposed to fix some of the latency issues of PA+ALSA.

* The original version of Rubberhose (the deniable encryption filesystem) was written for FreeBSD by one Julian Assange. I don't think it's still maintained, though. There was a version for Linux 2.2 at some point, but good luck getting that to compile in this day and age.

* Linux in general has a lot more APIs between kernel-space and user-space. In Linux, you've got procfs, sysfs, debugfs, netlink, and so forth. BSD was a lot more conservative about adding APIs.

* The FreeBSD jail mechanism is pretty good. Linux has seccomp, SELinux, SMACK, Tomoyo, cgroups, and so forth, but none of them are as easy to use as jails.

Disagree. I can create a Linux container (lxc) using virt-sandbox in fedora to bring up a container to run a single command with very ver little effort. It is roughly equal or less work to build a chroot

With very new Linux kernels that have almost all of the user namespace patches merged, there is very little difference. I am curious the technical and not assumed differences however. Note that I donated to the FBSD foundation not because I ever use FBSD, but because in the open source ecosystem, diversity is important. Also, I'm a huge fan of pcc and clang/llvm

Thanks for pointing out virt-sandbox. I wasn't aware of it until now; it looks pretty interesting. Unfortunately the apps I would most like to sandbox, like pdf readers, don't seem likely to work with this approach, since it precludes interaction with X windows.

virt-sandbox does not seem to be available on my Linux distribution (SuSE), so, at least for me, it trivially can't replace jails :) On a more serious note, though, jails seem more appropriate for sandboxing daemon processes than for running one-off commands. I don't think virt-sandbox was designed for this role. In that sense, SELinux is more of a replacement for jails than virt-sandbox.

I set up a monthly donation. I think the foundation would benefit from more marketing. Similar to other commenters, I wasn't even aware of the foundation prior to this HN post. Now that I know what to look for, the "Foundation" link on the freebsd.org home page is obvious, but I'd never actually noticed it before.

I think theres a misconception that OS X is in a huge debt to FreeBSD, or even runs it at its core. Apple runs a custom kernel, no relation to FreeBSD, with a mixture of *BSD user land tools--more NetBSD than FreeBSD the last time I looked, but certainly both. That's not nothing, but also not a situation where I'd expect Apple to be donating much.

As some anecdotal evidence here - I used to run FreeBSD on my laptop, and when I would connect to wireless access points of use vulnerability scanning software (as a student) - I would often be identified as running OS X.

Given how large Google is I'm certain they use FreeBSD in some form somewhere. Still it's kind of fun seeing Google who is predominantly Linux-based as a major sponsor and not Apple which likely ship code from the FreeBSD project in every device they sell. Also nice seeing Juniper contributing back but I can't see anything from Cisco...

Well while Clang is open source and permissively licenced it's not exactly as it's a code donation aimed at FreeBSD. Apple needed a compiler frontend/backend as they were stuck with a very old GCC 4.2.1 due to them not accepting GPLv3, thus they hired Chris Lattner of LLVM fame and started working on Clang (which turned out great, now we have two excellent open source toolchains competing which benefits all end users).

Likely FreeBSD is very thankful for the existance of a first-class non-GPL compiler frontend/backend toolchain like Clang/LLVM as it is in line with their licence philosophy, but that won't help if they can't generate enough funds to keep the project going.

Having Apple contributing some money back (it's not as if they are strapped for cash) to the project from where they lifted a good chunk of code would not seem out of place.

I think the philosophy behind the BSD license is to write great code and to maximize it's usage across the world without expecting anything in return. This is especially good for standardization of things, like the TCP implementation that even Windows used.

So, I guess the developers must be happy at it being widely used in the form of iPads, iPhones and iPod Touches, even if BSD doesn't see a dime of the $100B+ in cash and billions more every quarter that Apple made leveraging it.

So, I guess the developers must be happy at it being widely used in the form of iPads, iPhones and iPod Touches, even if BSD doesn't see a dime of the $100B+ in cash and billions more every quarter that Apple made leveraging it.

I would be sad, since even 0.01% of that is $10M, which would amount to 20 such FreeBSD fundraisers. Of course, the BSD license allows you to take code an run with it, but it would still be very nice if Apple donated at least some amount that is absolutely insignificant to them. Judging from [1], they don't even donate a penny.

My view is that FreeBSD 8 is far more coherent and complete, and just as stable, as FreeBSD 4. (FreeBSD 9.0 has a few glitches related to UFS SU+J but those are fixed in 9.1.)

As for the upcoming release schedule: The next release after 9.1 should be 8.4, early in 2013. Whether FreeBSD 8.5 ever happens is an open question; we'd like to offer major branches which live for longer than our current 5 years, but we're hobbled by some contrib code which is poorly supported upstream, so my guess is that it won't happen in the 8.x branch.

That is our view as well (that 8 is more coherent and complete, stable, etc.).

The problem is that it doesn't matter unless it has a long lifecycle with lots of minor releases.

You can't deploy on the x.0 release - a bigotry that we think is deserved given the results of 5.0 and 9.0. So you need to wait for .2 or .3 or so to be confident in the release at all. But then ... if .4 is as far as it goes, you've invested years of work and hundreds (or thousands) of thousands of dollars into just one more year of lifecycle.

So 8.4 would be a good sign, and 8.5 would be great, but we need a release that lasts for a good five years and runs up to the .10 or .11 or .12...

One of the links we just posted from that big thread (the second one, I think) is the proposal John made for picking a "long term release" every few releases and really committing both time and energy to making it last long enough so that serious investment can be made in it.

That's a two way street, btw - it's not just the ability to invest in your own processes and architecture, but the ability to invest back into FreeBSD. We've had a LOT of potential feedback and contributions that could have been made throughout 6 and 7 that just never seemed worth the time and effort given how excited everyone always is about the bleeding edge ...

Interesting to hear that rsync.net is based on FreeBSD. Just from curiosity, why don't you use a linux distro? What benefits does FreeBSD offer for you compared to Linux distros. What disadvantages would you count. (I mean if you ever had a chance to make a comparison).

Our current answer is that our platform is ZFS based, and given the muddy waters with Oracle and Solaris and so on, it's more responsible to deploy ZFS on FreeBSD.

But JUST BARELY. We've had our ZFS roadmap in place since 2009, and only just finally deployed in 2012. Our intention originally was to switch to Solaris, with real support contracts and contractual commitments and so on, but then Oracle came along.

So then we had to come back to where we've been all along, since the beginning of JohnCompanies[1] - with FreeBSD.

[1] JC deployed with FreeBSD since the first VPS product rollout was based on jail, so that was that.