The FreeBSD Foundation falls short of its 2012 fundraising goal by 50%
freebsdfoundation.org
freebsdfoundation.org
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.
This email account is protected by: Active Spam Killer (ASK) V2.4.1 - (C) 2001-2002 by Marco Paganini For more information visit http://a-s-k.sourceforge.net/
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.
I'm not affiliated with the FreeBSD Foundation, but I created a thread on the FreeBSD forums about the spam detection issue so hopefully the message will make its way to someone who can look into it:
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 dunno, everyone in the world running Mac OS X?
Apple's developer site has a page listing the pieces of FreeBSD which were incorporated into OS X:
https://developer.apple.com/library/mac/#documentation/Darwi...
You are technically correct that it isn't FreeBSD but, for most intents and purposes, Mac OS X re-uses many parts of FreeBSD.
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).]
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.
> Who still uses it?
Read the rest of the comments in this thread :)
Apparently Netflix, http://opsec.eu/backup/OpenConnectDeploymentGuide-v2.4a.pdf
Dell, Citrix, F5, Juniper, Netapp...
https://en.wikipedia.org/wiki/List_of_products_based_on_Free...
Cisco bought an existing company, and the product is stagnant.
Citrix bought an existing company, and the product is stagnant.
F5 went to Linux many years ago
Juniper is still FreeBSD. They win this one ;)
NetApp has a port to Linux, but is still shipping FreeBSD. 50/50.
Nokia/CheckPoint went to Linux (SecurePlatform)
http://lists.freebsd.org/pipermail/freebsd-jobs/2012-Novembe...
And they're not the only ones...
This is the first I've heard of this. Source?
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.
So, this almost certainly does not exist anymore.
Usually people running away from Linux, Drepper-isms, Oppan Poettering Styles, and the like.
Doesn't everybody love the smell of bikesheds in the morning?
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.
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.
IIRC, linux had lost out on these gems due to licensing issues. Oracle seemed quite keen on developing the zfs-clone btrfs - but after they had gobbled up sun, interest in btrfs seemed to have waned.
http://duckduckgo.com/?q=freebsd+v.s+linux (and g! doesn't help any more)
The "best" resource I could find between those two searches resulted in:
http://www.wikivs.com/wiki/FreeBSD_vs_Linux
I'm not sure of the quality of the results of that page.
Regardless, we've gone well beyond "a second of googling."
> Comments like the GP can alternatively be phrased...
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.
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 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?"
1) as in I didn't down vote but assume...
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.
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.
> 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.
> 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.
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.
Of course there would be. The glib from debian is not the same as the glibc from red hat, despite the name.
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.
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.
> 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).
Btw, I suppose the problem is the same between the different BSDs.
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.
[1] Problems, sure, but not problems arising from distro variation.
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)).
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.
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.
http://www.freebsdfoundation.org/documents/FBSDF_3-fold_2012...
Key points:
* Robustness
* Networking
* Security
* ScalabilityI'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.
* 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.
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.
Wiki says it's not maintained and never made it out of alpha. Is there much difference between it and a hidden truecrypt partition?
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 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
I couldn't get anywhere without FreeBSD running my servers.
EDIT: The fundraiser letter is on the website, if you still want to read it: http://www.freebsdfoundation.org/announcements.shtml#fundrai...
I'm a huge fan of BSD and would love to see it on EC2. :)
Unfortunately I can't talk about things Amazon is doing to help with this, but I have seen ample evidence of Amazon's interest in and effort towards making this work.
Some of the Apple additions/inventions are also merged into FreeBSD proper: http://appleinsider.com/articles/09/10/16/freebsd_adds_suppo...
500k appears to be quite a nominal amount when you put all these "Big Corp" names together. Or is this fund raising set apart from what the "Big Corps" pay? Not sure how this works...
http://www.freebsdfoundation.org/donate/sponsors.shtml
Sadly, the number of corporate ($$$) donors has dropped off in the last couple of years...
I have seen this happen in many Fortune 500 projects.
At least in some instances. Clang comes to mind.
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.
OT: yxhuvud, är du också svensk?
OT: Japp.
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.
Of course, in the past they used to donate code.
"FreeBSD end-of-year fund raiser on target" http://www.h-online.com/open/news/item/FreeBSD-end-of-year-f...
"FreeBSD veteran confident of reaching fund-raising goal" http://www.itwire.com/business-it-news/open-source/57855-fre...
https://npo.networkforgood.org/Donate/Donate.aspx?npoSubscri...
Like givewell or whatever with a tech filter?
We (rsync.net) are based entirely on the FreeBSD platform, and have been since we first offered offsite backup in 2001. Our principals have been server and desktop users since 1998.
Further, we built JohnCompanies (the first VPS provider)[1] entirely on FreeBSD and jail.
So with that disclaimer, we are compelled to point out that the high water mark of FreeBSD ... coherency ? completeness ? stability ? ... was 4.11 in 2005.
John Kozubik posted this long and detailed rundown of the situation in January of 2012:
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-Janu...
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-Janu...
and there was much agreement and nodding of heads. $50k over five years was committed by Kozubik to support a new development trajectory:
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-Janu...
There is a good litmus test going forward. If you see 8.4-RELEASE, and see 8.x supported as "production" and not "legacy" well into the 9.x lifecycle, things are getting better.
If you see 10.2 and 11.0 and so on before you see 8.4 or 8.5 then FreeBSD is just a research project.
[1] Yes, Verio was doing that weird virtualization thing with their e10ks (or whatever it was), but in October of 2001 we were the first to make available what anyone today would recognize as a "VPS".
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.
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.
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 ...