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.
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.
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.
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...
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.
http://www.freebsdfoundation.org/documents/FBSDF_3-fold_2012...
Key points:
* Robustness
* Networking
* Security
* ScalabilityFreeBSD 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.
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?