Hacker News Reader

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 )

It's also very easy to upgrade FreeBSD from one major release to the next.

I've been steadily upgrading FreeBSD since version 8.x.

@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.

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?

> 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.

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.

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.

https://www.freebsd.org/security/advisories/FreeBSD-EN-15:05...

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.

It's nice that DigitalOcean gives you actual console access… AWS gives you screenshots and text dumps for serial, no write access :D

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.

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.

Bullshit.

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.

What part of this do you not understand?

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.

And having used FreeBSD for nearly 18 years now, there have certainly been hiccups, but for the uses I have had 9 and 10 were perfectly usable.

"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.

Funnily enough, 4.x is when jkh went to Apple.

I've never had a single kernel panic on FreeBSD and I'm using it since the 4.0 release.

had a kernel panic once, i think it was some 9.x, when unplugging a mounted usb stick (oops)

Maybe 7.x? Until 7.2-RELEASE removal of active disk devices was a very reliable panic.

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.

Isn't the radeon driver proprietary?

Have you tried drm-next? https://github.com/FreeBSDDesktop/freebsd-base-graphics

It's an update of the graphics stack to match modern Linux. Apparently amdgpu leaks memory, but radeonkms might work fine.

AMD/ATI graphics drivers have always been terrible. Never seen a problem with NVidia or Intel.

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.

* https://news.ycombinator.com/item?id=13622945

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.

That was definitely a low point for the Project.

Edit: Ha! It looks like we have this conversation every time there's a new release: https://news.ycombinator.com/item?id=12368914

>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.

Maybe you are not aware, but you are replying to the owner of rsync.net - which runs on FreeBSD.

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.

I'm thinking it'd have to be a whole new ???BSD.

Sibling's right that this is... nontrivial, but I believe TrueOS does this.