While you're here, have you donated[0][1] yet? :) You may or may not be aware, but FreeBSD runs your movies on Netflix, your games on PlayStation 4 and Nitendo Switch, your files on FreeNAS and ZFS, your friends on WhatsApp and OpenBSD runs everything else on OpenSSH. ;)
So, you may or may not know that, but you need FreeBSD and OpenBSD and they also need you! Every cent counts and so does every contributor, that helps the foundations keep their non-profit status.
> [...] have you donated? [...]
> FreeBSD runs your movies on Netflix, your games on PlayStation 4 and Nitendo Switch
This really isn't how this should work. If one uses Netflix or some gaming hardware (for which one payed) one should not feel obligated in any way to give to FreeBSD. The Netflix or Nintendo might want to donate to ensure they have an even better system available in the future, but because of the BSD license, they aren't obligated either.
That aside, as a personal FreeBSD user, I have actually donated to the FreeBSD foundation every year for the last four or five years and plan to do it again this year.
These examples are not used to imply that it should the way you suggest they do. They are used as an example to show, that one day if you want to run a business requiring advanced technical platform available for free, you can do it thanks to FreeBSD and you can be as successful as these companies. Not only these commercial products use it, but also many free/open projects and non profit companies, and if that doesn't open your heart and wallet, then I don't know what would, if at the same time you're OK paying for products ;)
Or is it, not wanting to start any kind of flame-war, just the fact that the BSD licenses used here means these commercial products are not obliged to give back making non-BSD licensed software (e.g. GPLv*) less likely to be used for these companies?
Or looking at it cynically, I am paying for Netflix development who then also charge me for the privilege.
> because of the BSD license, they aren't obligated either.
No free software license that I know of would obligate them to donate money to FreeBSD.
I know you didn’t say otherwise, but in license discussions a lot of people (particular GPL fans) suggest changing to a copyleft license would improve FreeBSD’s financial status, without anything to back it up.
Netflix currently employs about 8 FreeBSD committers (possibly more, I'm counting on my fingers before coffee, so I might be forgetting people). Most of us contribute our changes back to the project. Some of these are major things, like async sendfile. Our goal is to upstream everything we can.
We also do other things, like sponsor conferences, and work behind the scenes, advocating for FreeBSD support from a wide variety of enterprise hardware vendors.
But why FreeBSD over Linux? Honestly it all seems like a waste of time. Linux is already the dominant free OS. Maybe it would be better to put resources into improving Linux (like Microsoft and Google do) instead? You can advocate for it all you want but the idea that FreeBSD is going to ever become as relevant as something like Linux is extremely unrealistic.
Not to mention Linux has a much better license for end-users in that it makes some effort to guarantee the code stays free, and that corporations can't close and modify the code and redistribute it for profit.
I feel like "advocating for FreeBSD" really does more harm to the open source ecosystem than good.
>You can advocate for it all you want but the idea that FreeBSD is going to ever become as relevant as something like Linux is extremely unrealistic.
Do you have any idea what you're talking about?
BSD literally invented the networking stack that was copied (poorly) by Linux, and most other Unix variants including Darwin (macOS). It is strictly superior for networked applications. Read here for more info (https://news.ycombinator.com/item?id=8167126)
Would also add that, overall, BSDs are much more lean and well designed than Linux.
There are thousands of Linux developers submitting patches all the time, in every direction. That's part of what makes Linux great, but it also makes it a huge mess of code duplication and design bloat. Dbus is a mess, /proc is a mess, netlink is a mess, systemd is a mess, hell eBPF is an insane mess. Linux has a huge legacy of bad APIs, tools and design choices, that were integrated in a rush. That makes Linux trendy, but definitely not what you want when you're just interested in a stable, understandable kernel to run your core infrastructure ou embedded equipments. Not to mention even tooling and network daemons on BSDS are much easier to work with and configure IMHO.
I've been doing kernel development for Linux since a while now, and I'm always amazed at how much time it takes me to understand a new subsystem I didn't use before, because everything is SO damn over engineered it's a farm fest for geek. Whereas when I hack OpenBSD or FreeBSD on my free time I feel like I can be productive making changes in an unknown subsystem in just a few days of reading code and playing with it.
They way I've seen it described is that BSD is designed, Linux is grown.
Every part of BSD is from BSD. The kernel, network stack, init system, userland, sshd, etc are all made and released together. Ideas are driven by teams and committees and then implemented.
Every part of a functioning Linux system is from a different vendor. "Linux" makes the kernel and network stack, the init system comes from the FreeDesktop project, the userland comes from GNU, sshd comes from BSD. Things are driven in a variety of different ways, by different people, with different goals and thoughts on how Linux should look. Eventually it all gets glued together and we see what we've got.
> But why FreeBSD over Linux? Honestly it all seems like a waste of time. Linux is already the dominant free OS.
Linux isn't an OS, it's a kernel. There are hundreds of distributions that package Linux and make an OS out of it. You don't think that all that duplication of effort is an even larger waste of time?
Who cares if FreeBSD isn't as relevant. Monocultures suck. There's lots to like and lots to dislike in Linux, and I'm happy that we have other working systems from which to draw lessons and inspiration.
You gotta be joking here right?! Because something is more popular doesn't mean it has quality over everything else. And with licensing we could argue about your statement. I will end it here with BSD's networking stack, kqueue, jails, dtrace and for god's sake try something different, you may be surprised (illumos based operating systems for example)
>Not to mention Linux has a much better license for end-users in that it makes some effort to guarantee the code stays free, and that corporations can't close and modify the code and redistribute it for profit.
I disagree very strongly with this statement. The best license for the end user is the one that enables the developer to thrive financially. If that license is open source it's a bonus for the end user. I also believe that the software is only truly free if you're contributing because you care, not because of a viral contractual clause.
Was it a token gift redolent in condescension or was it actually something approximating some meaningful fraction of the opportunity cost of having selected something else other than the BSD project as a supplier?
Cynicism would say the former but I'd be delighted if I were wrong.
Whatsapp donated 1 million dollars two years ago and 500000 dollars last year iirc.
For Netflix I don't know but they employ a lot of FreeBSD devs and upstream all their work.
I can't be responsible for their donations, just as you can't so let's not try asking each other about that. Both of us, however, can be responsible for our own donations. I have already donated, what's your excuse? ;)
They have some obligation to answer to their customers (yes I know for private corporations the shareholder is ultimately the authority but shareholders exist because there are customers not the other way around) so we, as their customers should call them out on it.
Even though other people have made the point we can't state enough times that these corporations have more of a duty to donate seeing as they extract far more value.
Given the license gives them complete freedom of what the do with FreeBSD, I wouldn't agree they have any duty. I would agree it would be nice, for sure it would be welcome, but nice & welcome doesn't constitute any duties. Just imagine under how huge pressure and scrutiny ALL linux distros, projects and companies should be for using OpenSSH _everywhere_ and not donating a penny to OpenSSH/OpenBSD projects. But the license allows it and that's the point and spirit of Open Source in eyes of BSD.
A moral duty. And I agree OpenSSH/OpenBSD/*BSD should receive a lot more support from the Linux community, as should any project that is used for the benefit of others. No arguments there.
There is nothing proving that.
If you look at the licence in the switch menu you will see way more licence header than the network stack (there is even jail and MAC framework licence).
Unless they took some random licence my bet is the Switch OS is FreeBSD based.
Nintendo have a Network stack since the Gamecube, why would they took the FreeBSD one 16 years after ?
Dude, people are reverse engineering the nintendo switch OS in an attempt to get homebrew. Those guys already got quite far, and have confirmed multiple times that the OS is not FreeBSD.
Just looking at how syscalls are made proves that it is not a FreeBSD kernel (It's possible to dump a few nintendo switch binaries, like the webkit browser, through pegaswitch[0]).
I do not say that the kernel is FreeBSD, just that it's FreeBSD based.
They took some code that they didn't wanted to write themselves.
syscalls means nothing, it's "easy" to replace syscalls when you control the userland.
As roblabla said, multiple people are in the process of reverse engineering the Switch and they have all confirmed that the OS itself is NOT FreeBSD based. The network stack may be, but the kernel itself is an iteration on the 3DS' kernel.
Yes, Netflix, Sony and Nintendo should donate. And guess what, where did they get the money to donate? From US: customers! So we already donated indirectly.
... and although many of the core team had agreeable sentiments in the very long discussion that followed, nothing at all has changed.
The poster is correct - there is indeed no point in using the 10.x branch. What he doesn't know is that there has been no point in using the 10.x branch for over a year now[1] but since the 11 release was at "dot zero" you were ill-advised to use that as well. This means that for over a year there has been no good answer to the question "which version of FreeBSD should I use".
In summary:
FreeBSD is an operating system by, and for, FreeBSD developers. It is very difficult to invest time and money into FreeBSD because the platform is neither stable[2] nor long-term. Finally, FreeBSD, possibly unwittingly, loses a lot of end-user development and reinvestment since end users are never working on the same OS that the developers are.[3]
[1] As usual, all new drivers and non-critical bug-fixes go to 11, since that is what "is current" and nobody bothers backporting any of it to 10. This was true even before 11.0-RELEASE came out.
[2] I don't mean stable in terms of reliability - FreeBSD is rock solid and we trust all of rsync.net to it - I am speaking of the stability of the OS platform itself and what functions it is capable of.
[3] I'm not interested in your success stories running CURRENT in production. The official stance of the FreeBSD project is that CURRENT "includes works in progress, experimental changes, and transitional mechanisms". They go on: "FreeBSD-CURRENT is not in any way “officially supported".
This means that for over a year there has been no good answer to the question "which version of FreeBSD should I use".
Not true at all. The answer is:
1. If you have systems which are already running 10.x, you should run the latest 10.x release.
2. If you're deploying a new system now, you should deploy it with the latest 11.x release.
3. If you're building a product which you will be selling next year, you should build it on top of FreeBSD HEAD, so that it will be running a recent release when it ends up being deployed.
Old STABLE branches get updates and new releases because there are deployed systems which are using them. Think of 10.3 as "FreeBSD 10, service pack 3".
Those are exactly my thoughts. Long time ago we didnt upgrade Business Systems from XP to Windows 7, you apply the Services Pack for as long as possible. Of coz you should be upgrading now because XP is no longer supported.
A long time ago I thought it was stupid not to upgrade to the latest and greatest. It turns out in business stability triumph over everything else. ( That is assuming you have a decent security measures put in place already )
@cperciva, I think rsync point is that it hasn't been since 4.x that a release had had more than 3-4 dot release. Just look at the version history. Most major releases are only developed for approx 2 years. https://en.m.wikipedia.org/wiki/FreeBSD#Version_history
@rsync, is there any other BSD out there that has a better model than FreeBSD? (E.g. netbsd, openbsd, dragonflybsd)
"If you're deploying a new system now, you should deploy it with the latest 11.x release."
Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD.
I think that's a decent heuristic in general - for instance, I don't buy a car until they've been rolling off the line for 9-12 months - but in the case of FreeBSD it is a concrete rule based on experience - not a superstition.
So again, the cool kids all stopped working on 10.x[1] over a year ago, and 11.1 was not released.
In our case, 10.x was working fine for us and nothing was terribly broken driver-wise (unlike 8.x when we desperately needed intel NIC fixes circa 8.2 that all went to 9 and never got backported).[2] So we kept deploying 10.3.
[1] Driver fixes all go to 11, non-critical bugs all "committed to stable", etc.
[2] Well, except for some nice new bhyve features that all went to stable were not available to us for the last 12-18 months (and will never go to 10).
Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD.
Frankly, if that's the lesson you learned from FreeBSD 5.0, I don't know that there's anything I can say to help you.
A more appropriate lesson to learn from FreeBSD 5.0 would have been "don't use releases which are cut from HEAD and announced as being for 'early adopters'". The FreeBSD 5.x stable branch started at FreeBSD 5.3.
I think the long-standing impression left by 5.0 (despite carrying explicit warnings about being appropriate for early adopters) carries a good lesson for us: this sort of lore is surprisingly sticky. It doesn't matter that 5.0 was very much an anomaly that wasn't repeated, and that recent .0 releases were very stable. I suspect end-users like John are going to avoid .0 releases for as long as they use FreeBSD.
You're probably right, but that doesn't mean that we shouldn't point out at every possible opportunity that 5.0 was an anomaly and was clearly identified at the time as being an anomaly.
Maybe we can't convince John to unlearn his wrong lessons, but I'd like to avoid having him teach those wrong lessons to everybody else.
> It is very appropriate that you remember the 4.x days like that since that is the last time there was a long term, stable target for FreeBSD development (and investment).
> Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD.
The important thing to keep in mind is that these are two consequences of the state of the FreeBSD tree in the early 5.x days. There's no question the first couple of 5.x releases had a great number of stability and other issues, and I can certainly understand that experience leading to an approach of "never use a .0 release." But it is precisely because early 5.x was in such bad shape that 4.x continued to receive ongoing development for so long.
Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD.
If FreeBSD were to accommodate this kind of SOP given their current resources, what could they do other than just call the first release x.1 instead of x.0?
I've been using FreeBSD since the late 4.x days and I really don't feel the same way. It's always been the same rule of thumb as far as I'm concerned, "try to avoid x.0 releases and don't upgrade to the newer version as long as you don't need a new feature and the n-1 is still supported".
It's also generally very conservative with its feature set, unstable and experimental features are generally very clearly labeled and are not marked as stable until actually stable.
You're a power user and you follow the development of FreeBSD extremely closely and you're frustrated that you have to wait 10 months for a feature to make it into a release. That's understandable. I on the other hand use FreeBSD as some kind of 'install and forget' OS. It's stable, it Just Works and I just need to remember to run freebsd-update from time to time.
>FreeBSD is an operating system by, and for, FreeBSD developers.
I see your point but I'll take that over what seems to be the mindset of most Linux distros these days, "let's dumb everything down and hide everything behind mountains of crappy abstractions to cater to the mythical 'average desktop user' who doesn't even use or care about our OS anyway".
FreeBSD has a very good documentation but it doesn't attempt to dumb things down and assumes a certain level of technical knowledge from its users. I think understanding the release cycle is part of that, all the information is out there, it's up to you to decide what's good for you. CURRENT, release, oldrelease, they all have their use case.
Another issue is that, at least in my experience, the upgrade experience can be a bit fraught. Especially if you're using packages. I've been using FreeBSD intermittently since somewhere around 1997 or 1998, so I'm not a complete n00b. But I've had enough instances where an upgrade hosed something important that I'm hesitant to upgrade until I'm sure I'll have time to troubleshoot fix something weird and new. And this of course ends up being a self-fulfilling prophecy because the longer I wait to upgrade, the more likely stuff is to break.
I don't think I'm an idiot, but sometimes FreeBSD makes me feel like one. (This is, of course, in contrast to OpenBSD where the software may not make me feel like an idiot, but the developers do.)
I can add that I have experienced upgrade problems firsthand while running FreeBSD on Digital Ocean. In my case, rebooting after an upgrade would hang.
Yeah, I had that bug too (or another one that caused similar behavior). Great fun.
Edit: I realize my comments may sound a bit unfair. I don't want to come across as saying "they had a bug in their software, so they suck!" I realize stuff happens, and these are complex things. But I'm bothered by the fact that it has happened often enough that I'm actually nervous to upgrade my FreeBSD system, even though I have been using the OS for 20 years and did time as a professional sysadmin. I guess the flip side is that once it's working, FreeBSD is so stable and drama-free that my incentives for upgrading are very low unless there's a critical security issue.
I am an extremely casual FreeBSD user. I also happen to be an obsessive compulsive software updater conditioned to systems restarting and coming back after a few minutes. So this hanging thing had me completely baffled. It was also my first time ever looking at the Digital Ocean console.
I agree with your observations, but I'm not sure that I agree that this is a huge problem; but maybe I've been using FreeBSD differently than you have.
At my current employer, and the previous, we used FreeBSD for its base OS, and then most of the services we ran were our own proprietary code, built with in-house patches on top of an open source language. We didn't and don't tend to upgrade the OS unless a release (or a patch) fixes a specific issue we're seeing, or is a security issue in things we actually use, but new hardware tends to get the latest OS (we're currently installing 10.3, but may consider 11.1 now that it's out; we do have a couple machines running 11.0 because they need the per disk io threads and fixes to directio that i think were in 11 as well). When we run into problems, we'll look to see if it has been fixed in upstream, and see if we can apply that to the whatever release we're currently using. If not, we try to fix it ourselves, and then offer the fix back; but we're happy to run with our version of the fix until it makes it upstream.
We've had pretty good luck with upgrades not causing major issues, but we did have some trouble with mrsas drivers for a while, and the VM change in 10.x where pages are marked inactive and can get swapped out without memory pressure caused us a lot of trouble until we figured it out.
The benefit of the lengthy release process is that the releases are pretty solid, and once a system is setup, we don't have to touch it. Also, because FreeBSD doesn't change for the sake of it, we don't usually have to worry about some systems being on 9.x, some on 10.x, and some on 11.x; we just are sure to build software either on the hosts themselves, or on an older system, so it'll run on all systems.
Edit to add: The most frustrating thing for me are the many Bugzilla entries for issues that I'm having, with patches, that are sitting there for years. For example this one https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=25986 which was open for 14 years before it became CVE-2015-5358
> The most frustrating thing for me are the many Bugzilla entries for issues that I'm having, with patches, that are sitting there for years. For example this one https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=25986 which was open for 14 years before it became CVE-2015-5358
That one is a particularly disappointing and egregious example, but highlights the problem we have with stale PRs and patches. There are a number of folks in the FreeBSD community working on triaging old (and new) PRs, but it's slow going and a mostly thankless task.
If you have other cases of issues that have existing PRs and/or patches please feel free to let me know (email in profile) and I'll try to find out why it's stalled and if someone can help out.
While I disagree with your point of view, I understand that you may perceive things like that. However, the problem is very simple: vast majority of work done in FreeBSD is being done by unpaid volunteers, unlike in case of RHEL/Fedora/Centos and Ubuntu/Debian. The solution to this problem is also very simple: donate money to the project with that particular request. Once enough money is donated, the project can deliver what users like you are asking for, by hiring engineers to work on it. I don't know if you have or have not donated money to the project, but looking at FreeBSDFoundation donors list I can't see rsync.net there ;) So, everything is in your hands!
> However, the problem is very simple: vast majority of work done in FreeBSD is being done by unpaid volunteers, unlike in case of RHEL/Fedora/Centos and Ubuntu/Debian.
You don't get to use the "unpaid volunteers" excuse when a good portion of FreeBSD's site is dedicated to explaining why GPL and copyleft is anti-corporate and big business should be/is afraid of it, and how BSD is more business friendly.
Red Hat is a business. FreeBSD is a volunteer/community project.
FreeBSD is a volunteer/community project that offers more business-friendly licensing than gNewSense, which is also a volunteer/community project. It is not, however, a business like Red Hat.
Red Hat development gets all that funding because Red Hat is a business. FreeBSD relies more on volunteer time because it is not a business.
Fedora is a "community" project of Red Hat. FreeBSD is a community project of, well, a community. Red Hat funds Fedora (astroturf project) as its testing ground for RHEL (commercial project), while FreeBSD is just a community project.
I don't really see your point, these two things have nothing in common. Where a commercial company has resources to provide long support (paid by, hey, customers money) the volunteer based project doesn't have them, simple as that. It doesn't change the fact that BSD license is more friendly to businesses and that's why so many companies can and DO choose FreeBSD as their technology and are completely FREE to share their code and/or money with FreeBSD. But again, that's not the point.
I'll try to refine the point I was making. For years FreeBSD has explained away their problems by saying "we don't have big business helping us" and then they turn around and say "one of our key advantages is we're more friendly to big business". At some point, you need to stop offering up ONE of those arguments because while theoretically both points can be true, you have to eventually ask if FreeBSD is so good for business, why aren't there Red Hat, IBM, or Linaro for FreeBSD? And if so many businesses ARE choosing FreeBSD, why isn't it showing up in more tangible ways? Netflix might contribute a lot back to FreeBSD, but, can I watch Netflix on my FreeBSD computer? I say this mostly out of frustration with a project and product that I do really like. FreeBSD just needs better arguments in support of it.
"I don't know, in the 4.x days I worked for a company that built and deployed very stable commercial grade products on the 4.x release."
It is very appropriate that you remember the 4.x days like that since that is the last time there was a long term, stable target for FreeBSD development (and investment). Remember, the 4 branch went to 4.11.
It is 4.x that I identified in my original mailing list post (2012) as the time, after which, I thought FreeBSD began having problems with focus and longevity.
I can't remember if I've ever had a FreeBSD release panic on a server, but I've seen plenty over the years on laptops. The largest source of panics is drivers, and there's far more diversity (and less testing) in the mobile space than in the server space.
Consider yourself lucky you don't have to deal with radeon drivers! This week alone, I had two different kernel panics, one on my notebook and another on my desktop, both of which use radeon (different gpu models), and in both cases radeon was the culprit.
For the record, I think we all agree that this kind of panic is not FreeBSD's fault. Linux support for this kind of driver is more stable and advanced, but, even though I use FreeBSD both for production and personal use, its "expected" case is production server.
I have kernel panics on 10.3 on a regular basis, varying from several times per day to a couple of times per week according to workload.
There's something inside wait6 and kevent that causes a thread to sleep whilst holding a non-sleepable lock. I hit it more than most I suspect because on my systems a lot of processes are blocked in kqread, whereas with the stock toolset one sees few processes using kevent.
I brought the subject up last year on freebsd-hackers, but nothing came of it.
As ambiguous as the current situation is, at least they've fixed the situation where there were five point versions marked as "production" on the website.
>FreeBSD is an operating system by, and for, FreeBSD developers. It is very difficult to invest time and money into FreeBSD because the platform is neither stable[2] nor long-term
While I don't want to dismiss you... The number of extremely profitable companies that built their products on top of freebsd tells me you're completely off base with your opinion.
Just off the top of my head: netapp ONTAP, emc isilon onefs, juniper Junos, Sony PlayStation, ixsystems, pfsense, Netflix, Intel, etc.
That's a really good point. Have any of the branches tried to address this? There's nothing stopping anybody from making a branch that does sane versioning & maintenance.
I'm not sure how you would address this with a branch, while keeping your sanity. If I understand the parent, he would like to see more frequent releases, especially more frequent releases of fixes to bugs seen in the released versions, but I think he would also want to keep quality of releases about the same.
That means, you probably just can't cut releases on a schedule and call it a day, you also have to decide which commits should be added to your inbetween releases, and which should wait. Sometimes, that's probably pretty easy, but other times, I would expect a lot of things to be mixed together, especially when code refactoring is needed to enable new features, the refactoring may (hopefully) fix existing bugs, but the new features are likely to be unstable for some time, and shouldn't really get into a release until they're done.
Managing that without upstream cooperation sounds like a nightmare, or at least like something that needs a team of smart people.
This release also finally compiles NAT-T into the kernel by default. I can finally run a strongswan/ikev2 server without needing to compile a kernel just for nat traversal. woohoo!
I use IPSec for my VPN needs (accessing my stuff at home from remote places mainly) and run FreeBSD. Getting it set up was annoying, to say the least.
I have no idea why they didn't include NAT-T by default in 11.0. I'd hazard a guess that most VPN connections involve at least one end being behind NAT.
Since I'm not an expert, I went with FreeNAS. It's largely "ready to go" out of the box, and having a GUI makes things very discoverable. Even if you're comfortable with CLI tools, you might not be familiarized with all the tools used in a typical NAS setup. Heck, you might not have much devops experience, which could lead to overlooking a key detail, such as setting up regularly scheduled scrub and SMART tests and having it email you if anything requires your attention.
Even if you're well versed on these topics, I'd still suggest trying it out on a VM, or at least reading through their guides. Seeing the approach taken by someone else might help you refine your own setup.
Unfortunately, the last few months haven't been great for FreeNAS. They had a horribly botched release. It was killed off fairly quickly, but a few people got burned over it. The good news is that they changed their mind on their expected breaking changes. Initially they intended to kill off jails in favor of docker, which made it a painful upgrade process for some existing users. From an outsider's perspective, it looked rush. Even though I'm happy with my setup, it made me a little more weary about quickly adopting major upstream changes.
"If I'm comfortable using command line tools, should I just use FreeBSD and ZFS directly to build a NAS, or should I go with FreeNAS?
I assume that using version 11.1 is the way to go? No point in using the 10.x branch?"
I would build the NAS using plain old FreeBSD and I would indeed use 11.1.
If it were a week ago, I would have advised 10.3 as, historically, x.0 releases of FreeBSD have been ill-advised.
If you are comfortable on the command line I see no reason to use FreeNAS/TrueNAS.
This is how I run my home fileserver. It is also how I/we run all of rsync.net - ZFS filesystems on top of plain old FreeBSD.
I don't believe I'm in such a unique position of having run both FreeNAS and FreeBSD on the same hardware (with the same zpool) so I expect others to chime in.
FreeNAS has been better from a performance perspective than FreeBSD raw was- why? Probably because I didn't do the right thing for good performance on FreeBSD. But that's my point here.. why spend ages configuring things to get the same performance you'd get OOTB with FreeNAS? You also get a webUI for "free" and plugins to run things like transmission and plex.
I don't advise using raw FreeBSD for home use, power users can still have all the CLI access on FreeNAS too, but may not want the "bloat" of a webUI.
I built a NAS with base FreeBSD, because I am comfortable with the command line, and didn't need a gui solution. Not much to report -- it works great.
If you go with plain FreeBSD, yes...go with 11.1. No point using the 10.x branch unless you have some specific reason to (eg. some specific legacy support requirements or something).
I've been using FreeBSD as a NAS with ZFS since ZFS was first added. I love it! The man pages are fantastic, the FreeBSD handbook is amazing, and the whole system feels really cohesive and well-designed.
I use Arch Linux on my desktop but I would switch to FreeBSD in a heartbeat if it addressed the desktop-related issues I had last time I tried it. It would be especially amazing if they fixed all the sleep and power management stuff so it could be used on a laptop with good battery life.
I was a long time FreeBSD user before I switched to Arch.
FreeBSD is a pure and beautiful system, but Linux provides much better performance and ease of use in desktop related tasks. The network stack on FreeBSD is of magnitudes faster than Linux (based on my experience with both OSes), however this does not compensate for power management issues and general slugishness while using linux software.
If you're using FreeBSD on your main computer, you need some kind of a Desktop Environment, if you don't want to stick with KDE4, you install GNOME. However, GNOME is ported from Linux and although most of the time it works without problems, there is a speed compromise (again only based on my experience).
Upsides of FreeBSD:
• The Package Repository is great, most apps such as firefox, emacs, IDE's are maintained at their latest versions.
• The system works solid, no crashes
• FreeBSD feels more like Unix, and if you're interested in the low level stuff you can learn more quickly. The source code is clean, the implementations are not complicated.
• Drivers are scarcer than Linux, but if there is a driver, it works flawlessly.
The points I'm neutral about:
• Behyve and ZFS are all great technologies, however they were a bit complex for my test. I couldn't manage to setup a Linux server with X11 forwarding. As for ZFS, I used FreeBSD on my laptop with a 256G SSD drive, so I did not see much benefit of ZFS. However, I was aware that if I had used VMs, ZFS would offer much better IO performance.
As for sleep and power management issues:
• Power management on FreeBSD is good, not great like Linux and you don't have powertop and tlp available. But it's good. You can expect upto 70-80% of the battery life you get in Linux. (You don't even have to tinker with C-States and all, just powerd or powerdxx works great out of the box.)
As for sleep issues, mostly on FreeBSD the closing the lid or pressing the power button won't be recognized as a sleep trigger. But on most laptops 'acpiconf -s3' puts your laptop to sleep.
This was already mentioned here but what's up with people thinking that ZFS is only for large storage arrays? You don't need anything more than a small SSD to get the benefits of snapshots, compression, and general ZFS reliability (copy on write — no data corruption ever, except for like hardware bugs). Boot Environments is an especially great snapshot-based feature.
Also how is bhyve complex? It's the simplest hypervisor ever.
Thank you for the hw.acpi.lid_switch_state heads up.
Bhyve seemed complex to me, because I was accustomed to Virtualbox and VMware. I tried to boot up ubuntu server with behyve and finding the kernel images, loading them, typing the boot commands were a hassle. Maybe if I had some prior experience with hypervisors, I could better understand behyve.
As for ZFS, I always had extra space in my SSD, so compression was of little use to me. My FreeBSD system only used 30-40 GB of space (including downloads). I had 8 Gigabytes of RAM, but FreeBSD only needed 1.4 GB, even whilst browsing.
I haven't used the snapshot feature, although I imagine it's powerful. I also haven't made use of FreeBSD jails, which are, according to what I read, far better than chroot.
On a similar sized ssd I'm saving a good bit of space with compression, have benefited from snapshots and rollback, and zfs send beats rsync by a mile for backups.
You might want to look into these and other benefits I think it's worth it even on single disk setups.
One important thing, that is not pointed out yet: FreeNAS has easy upgrade path for major OS versions. That is something that I miss when running plain FreeBSD.
Plus, you can always switch between plain and FreeNAS installation.
It mainly depends on what you are trying to achieve and whether you consider that time worthwhile.
They are both great options and FreeNAS already gives you a lot of flexibility.
It's a bit like with a router. Do you use something along the lines OpenWRT and mainly log in to the command line, not because you have to, but because you can then you might want to go with FreeBSD and ZFS.
However, if you don't know if it is flexible enough and fits: Go with FreeNAS and fall back to FreeBSD. I think that's the best option for most people.
I've been using FreeNAS for over two years and I would hate to try to use plain FreeBSD. FreeNAS is, as they say, "batteries included". If you're specifically setting up a NAS, I can't imagine why you would want to do more work for apparently little benefit.
For home use FreeBSD+ZFS will leave more control in your hands. For a (stable) filesystem node If I were you, I'd let others debug the latest release and just use 10.3. Or at least lag the latest release by a few months to a year or so.
You're comfortable with CLI tools, but there are other considerations. Do you like "appliances"? How much do you value "stability" as in running old stuff?
I would recommend HardenedBSD 12-CURRENT but maybe that's just me :D
I'm interested in what people think. For me, I'd be inclined to go FreeBSD as I perceive it to be more standard. If you're actually using either branch you had better be great at the cli.
I just meant it's easier to use a purpose built thing like FreeNAS vs. FreeBSD 11.1 which just came out. FreeNAS will be on 11.1 soon enough; unless there's a feature in FreeBSD 11.1 you absolutely need right now, most people will be better off using FreeNAS for now.
ZFS on Linux is quite inferior; there's a lot of missing functionality and some not so nice bugs. You also can't run ZFS on root without manual installation (I've done this).
ZFS on FreeBSD has been flawless for me. ZFS on Ubuntu is functional but limited, and I've experienced some odd glitches.
Not to mention the bug "zfs file io suspended", if you unplugged an usb device without exporting the pool(the process is also unkillable). And you can't mount/unmount anything else!!
Other than difficulty with ZFS on root, I think you're just making stuff up. I run a rather heavily used set of RAIDZ2 arrays and everything works fine. No "odd glitches" or anything.
On the contrary, it's quite true. I'm a little disturbed by how readily people ascribe nefarious intent to assertions regarding things they have not experienced themselves. You might not have experienced problems, but that does not logically imply that it is free of problems.
A few months back, I booted my Ubuntu 16.10 workstation. No ZFS datasets were mounted at boot. Regular "zfs mount" and "mount" failed. Could not get the datasets to mount at all, even though the pool was active and the datasets were visible. Solution: changing the mountpoint worked for some reason. Still no idea what triggered this or why the fix worked. Either way, it broke the system's normal functioning through no intervention of my own.
I've also had the zfs and zpool commands get stuck in "D" state indefinitely because something internal had blocked everything. Mounted filesystems continued to work, but no admin commands would work. Triggered by running some trivial admin function. After a few days I had to hard reset the system to regain control. This looks like a locking bug.
I've also had poor behaviour when a disc glitched and I got an oops rather than ZFS coping with the short outage. IIRC I got the same "D" state issue as above.
I never encountered any such problems with FreeBSD, and I've run it on both platforms for years. ZFS on Linux is functional, and I use it daily, but the FreeBSD implementation is better.
Apart from ZFS, the big draws for me (compared to Linux) are:
1) There is a clear separation between the base system and the extra software. On a typical Linux distribution, everything gets installed into /usr, /etc, /var, etc. On FreeBSD things that aren't part of the base system go into /usr/local.
2) The base system is designed as a whole cohesive system. The kernel and userland are kept in sync through the update process.
3) The documentation is fantastic.
It would be unfair to Linux if I didn't mention some downsides though:
1) Upgrades are more painful than Linux, and more painful than they need to be. On my OpenSUSE boxes, an upgrade is literally "sudo zypper dup; shutdown -r now". On FreeBSD, the same task requires multiple reboots[0]. Then you need to update any extra software as a separate step.
If you have a custom kernel (because you needed IPSEC and/or NAT-T), it's even more painful.
2) The base system is fairly sparse. You want to use bash? That's an extra package. Want sudo instead of su? That's an extra package. Don't get me wrong, the base system is very usable, but it does lack a lot of things that Linux users take for granted.
Ubuntu does not make the use of ZFS that one sees in the FreeBSD world. An example is TrueOS.
On TrueOS out of the box everything is ZFS, even the root volume, and that has been the case for a while, now. The operating system is in a single ZFS dataset (with things like /usr/ports, /usr/jails, /var/mail, /var/log, /usr/obj, and /usr/home split off into their own datasets). This is used to provide "boot environments".
System upgrade goes like this: The upgrade script makes a clone of the current operating system dataset, mounts it, and runs freebsd-upgrade on it chrooted at the mount point. This results in a new boot environment with the upgraded operating system ready to be rebooted into. ZFS copy-on-write means that an upgrade does not consume twice the disc space; and the separate dataset means that one retains an untouched current boot environment throughout the process.
Anybody know what the deal with blacklistd is? I googled and finally found the man page, but it's not immediately apparent why one might choose using it over using something like fail2ban (which works for any service and can block all ports, not just ssh)?
It listens on a socket for failed login notifications from other daemons. I'd say this approach is better than what fail2ban does (scans logs with regexps), but it has to be supported upstream so the daemons actually notify blacklistd.
So, you may or may not know that, but you need FreeBSD and OpenBSD and they also need you! Every cent counts and so does every contributor, that helps the foundations keep their non-profit status.
[0] https://www.freebsdfoundation.org/donate/
[1] https://www.openbsd.org/donations.html