Honestly, this is probably some kind of confusion over a company or two that has -CURRENT as an upstream to their own fork of the OS because they are reliant on some kind of new changes in the system that aren't in -STABLE.
Even if that's the case, you'd hope they'd be taking extra special precautions considering what they are doing.
I agree with you in principle but I think in practice you'd need to give a little bit of leeway here because 'CURRENT' is a very suggestive name. And it does not suggest 'Do not use for production'. It rather suggests the opposite.
When I read "CURRENT" I assumed that was the label for the most current stable release. I would expect NIGHTLY or ALPHA/BETA for something that shouldn't be used for important things.
I think you should learn and read about what you're downloading and running in production (given your hypothetical example). It's basic literacy. For example, would you go to Linus's github: https://github.com/torvalds/linux and just start downloading that and try running it verbatim in production because "oh! it's Linus's branch! Linus makes Linux. It is Linux!" and then complain because it's not an actual distribution?
Because that's how you read in your comment.
The linux development kernel is called "mainline" Would you want them to change it to Nightly or Alpha?
I agree you should read and understand what you're downloading and running in production. And I'd like to think that if I were in a position such that I was making those decisions I'd not make the mistake of assuming CURRENT meant current stable release. I'm just saying, reading the post I originally had assumed that's what current meant.
If there is one group that categorically does not read the manual then it is computer people. And if they do read the manual it is because something didn't work as expected.
That's not entirely wrong. On the other hand, if you can't tell whether the OS you deployed in production has, say, security support, maybe you're not the right person to administer it.
This probably comes from overconfidence. If you're pretty sure you can handle whatever comes up, it's easy to see reading documentation in advance as a potential waste of time.
Principle of Least Astonishment. The names of things should not mislead a reasonable user as to their purpose.
It is still the responsibility of the user to educate themselves on the things they use; but it's also the responsibility of the designer to make things straightforward and intuitive. I'm okay with blaming both of them, but don't pretend that the designer has no responsibilities here.
I can understand the terminology may be confusing to someone new to FreeBSD, but the handbook clearly documents the meaning of -CURRENT and -STABLE, and explains that -CURRENT is the "bleeding edge" of FreeBSD development.
"EDGE" may be a better term in that case... meaning it may cut you... there's risk... "CURRENT" to me brings a thought of, okay, it's current and up to date (safe from known exploits).
In my experience with open source projects, STABLE should be first on the download list. RELEASE should really be labeled release-candidate, with stable being considered the release.
RELEASE is the release, -STABLE is the minor branch for bugfixes and minor new features that don't break backwards-compatibility ("stable ABI"). -CURRENT is, well, current - it's the tree the developers are working on, and is the current state of FreeBSD, where releases are archives at a particular point (more-or-less).
I suspect much of this goes back to when development wasn't quite so public, so these are names that are meaningful to the developers, not the public.
Three key words there - "In my experience". Well now you've experienced a project who doesn't fit your current model of the world. Should those of us who have RTFM and experienced different vocabularies adjust to your model or should you recalibrate?
It doesn't really matter what anyone thinks a name means based on their prior experience. If they didn't RTFM I've no sympathy, particularly if that user is depending upon security features within the OS. Users, particularly corporates, have to take responsibility for your own situation and if they got caught out by this because they didn't understand or bother to take the time to read what -CURRENT is then I've no respect for them in any technical capacity.
So, then we should label the unstable may crash at any time release 'USETHISONE' and the stable one 'POSTALPHA'.
Really, I don't get this attitude of 'if they can't be bothered to read the manual they get what they deserve'. It's everybody's loss to have more compromised machines on the net because compromised machines allow bad elements to gain a foothold and from there it can get much worse in a hurry.
So you treat this as a communications problem and reduce the potential of error by properly labelling your releases (this costs $0) instead of telling those that got bitten by it that they 'got what they deserve'.
Whether you have respect for them or not doesn't enter into it, it's a security issue, not a respect issue.
CURRENT has meant MAYCRASH in BSD for... 25 years now?
I don't know how suggestive it is to someone who doesn't use FreeBSD, but if you as much as download and install it, there's no way you don't stumble into at least one "-CURRENT is not what you want for production" fine print.
This isn't a communication, security or respect issue, it's a competence issue. You don't just install an OS on a server and "somehow" not know you're installing a development version!
Lance Leventhal is one of my favorite authors of machine language books, he wrote a series of books on old school microprocessors, each of which followed a fixed template and taught you the basics of yet another processor in a familiar setting.
One of the lines from those books that stands out very clearly 25 years after reading them last: "If a variable is tallying the number of horses name it 'nhorses' not 'qdogs'".
Names matter. So if 'CURRENT' means 'MAYCRASH' name it so.
-CURRENT is called CURRENT because it reflects the CURRENT development efforts and their CURRENT state. Of course it may crash. When it stops crashing, it's going to be released and that's how it will be turned into a RELEASE.
There is literally (and I'm using the word in its proper sense, not as a hyperbola) no way you end up with FreeBSD on a server without knowing this. No one just installed it "by mistake" in a production environment or mistook it for a STABLE version.
"Head" is very commonly used because it is from the language of revision control systems. CVS, Subversion, Perforce, Git, Mercurial, and probably others all refer to the latest checkin as the "head". It has a specific meaning to a much larger group of people than just FreeBSD users.
-CURRENT machines shouldn't be "on the net" in any meaningful way unless you've calculated the risks and are willing to accept them.
I don't get this attitude of people who think projects should fit their model of how things should be named. Many of us have no problem understanding the labelling, its really fairly intuitive. We also have no problem understanding alternative schemes used in other projects. Just because its different to what you're used to doesn't make it wrong.
Whether or not I have respect for them matter quite a lot if they're trying to market security related products. Basing themselves on -CURRENT and not understanding the potential consequences speaks volumes about that organisation or teams competency in their chosen field.
No they don't. It's reasonable to trust that FreeBSD is providing decent RNG. Even in the dev branch. I mean, why would they not?
Don't blame the user for upstream's mistake.
Do FreeBSD developers (I mean, the ones who had nothing to do with this but also use the dev branch) "deserve" it, too?
In general, do you always blame the victim for someone else's mistakes?
edit: I am not a BSD user. I am reading now that the dev branch is purposely crippled anyway and known to be terribly unstable. If that's the case, maybe it is idiotic for non-developers to use it. I'll leave this comment here instead of deleting in so nobody else says the same thing. In the meantime, I'm glad to be using a rolling release Linux distro that always has bleeding-edge software without ever having any problems.
> bleeding-edge software without ever having any problems
Did you seriously just suggest that Arch never has any issues? How did you manage to achieve that, because I gave up on Arch due to it breaking at least once a fortnight. The "bleeding edge" is called that for a reason: you're likely to bleed when using it.
I run arch with the testing repos on both my work and home desktops, and the normal repos on one of my servers, and I've had updates break things exactly once between them (broadcom NIC wouldn't come up on my home desktop), and the fix was just a matter of rolling back 1 kernel version. So I guess YMMV?
I very rarely have any issues with Arch. Like, maybe once a year. And they're always easy to fix.
One big difference is I don't run a desktop environment (kde, gnome, or whatever crap is out there now). I suspect that makes things a lot less likely to break when I do updates.
It is also terribly stupid for software and application developers to run -CURRENT (as a base/primary platform) because it's for the development of the OS itself.
from the Rawhide wiki:
"Not recommended for production systems
We do not recommend that you run Rawhide as your primary production operating system. Instead, we suggest you could install and run Rawhide:
As a live environment only
In a virtual machine (VM) instance
On a secondary system
On a multiboot system, alongside a stable release of Fedora or another operating system
This allows you to test Rawhide without any impact to your day-to-day workflow. "
-CURRENT is the freebsd version of that: you know that it's going to be where things are being torn out and put back in on a hour to hour basis.
The group of people using -CURRENT is akin to the group of kernel maintainers in linux-land.
I do admit though - the rawhide warning is more verbose and clearer than the FREEBSD-CURRENT warnings. That's one part that I can see the community improving. I might even write some verbiage myself for contribution.
and be subscribed to the -CURRENT mailing list - which the development documentation indicate as mandatory when using a -CURRENT build.
Then you would know whether the compiler suite is being torn out (remember? FreeBSD switched from GCC to LLVM/Clang - yes - that was done in the last -CURRENT development cycle)
So your software might not even build because of certain base OS issues. BUT you would know all that already - and you would run -CURRENT in a VM that you blow away and rebuild as needed.
> No they don't. It's reasonable to trust that FreeBSD is providing decent RNG. Even in the dev branch. I mean, why would they not?
Because it's the dev branch and they could have any number of good reasons for disabling, removing, or temporarily breaking the RNG while they're rewriting or refactoring it.
It's very hard to have sympathy for people who may be using this in production. You have to go out of your way to get -CURRENT, and the download page clearly says it's aimed at "developers and bleeding-edge testers only." That's why the article is a message on the mailing list and not a security advisory somewhere.
By definition, the dev branch of any software project is unstable and not suitable for production.
> In the meantime, I'm glad to be using a rolling release Linux distro that always has bleeding-edge software without ever having any problems.
I think any long time user of Debian's unstable branch (almost equivalent to -CURRENT) would disagree with that statement.
Sometimes you end up depending on stuff that isn't in -STABLE yet. Sometimes it is edgy new stuff that comes with a risk, but fixes for existing functionality also fall in this category.
Living with broken software isn't a compromise a lot of users make.
The -CURRENT is absolute bleeding edge, it is what FreeBSD 11 is going to be in about two years. Are you sure you're not mistaking it with -STABLE which is the bleeding edge of 10.x?
I'm more inclined to believe that there major companies are running on -STABLE which is still somewhat risky, but at least typically everything that is there was somewhat tested.
It's entirely possible that a lot of people don't know what -CURRENT really means if they're new to FreeBSD. They could be on 10.1 and think that that means that they're on -CURRENT, and thus affected by this bug, but they're not.
Even if someone says they do, I don't believe it. As someone who runs -CURRENT on vm's and physical hardware, it's not stable to do anything aside from development and testing on it, and it's not meant to be stable as well on purpose.
Unless Netflix enjoys filesystem wipes, file corruptions, and extremely reduced performance due to kernel level debugging flags that are enabled by default (and often can't be disabled due to ongoing development efforts), then they are not running -CURRENT. Remember, -CURRENT runs slowly because of debugging code!!
There's a lot of public evidence of NetFlix's use of FreeBSD and their desire to generally stay up-to-date. I'm not aware of any credible statement that they're actually on -CURRENT though, and even if they were at some point they may not have updated since then.
They are heavily involved in FreeBSD development and I'm sure they're keeping on top of developments in -CURRENT, but I believe they are not using affected versions anywhere in production.
Right, which means that there will be a disproportionate number of FreeBSD developers running it. These developers have commit access to the source tree, including -STABLE and -RELEASE.
