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.
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?
A lot of computer people are indeed that way. But many others are not.
Invariably, when something goes wrong, the group that doesn't read the manual visits forums or chats to seek help from the group that does.
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.
And FreeBSD should name things better. Those two things are not mutually exclusive.
There is RELEASE, CURRENT, STABLE. If you choose one without knowing the difference as to what those titles mean, you deserve whatever comes next.
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.
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.
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!
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.
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.
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.
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.
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.
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.
The closest linux analogy is Linus's unstable git branch or maybe the redhat rawhide https://fedoraproject.org/wiki/Releases/Rawhide - even that has warnings:
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
-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.
Yeah, and that's why you should use it, to be sure your app works ok with the upcoming changes to the core OS.
https://www.freebsd.org/releng/#freeze
and
https://www.freebsd.org/relnotes/CURRENT/relnotes/article.ht...
and
https://wiki.freebsd.org/WhatsNew/FreeBSD11
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.
Or in continuous integration like jenkins. https://wiki.freebsd.org/201405DevSummit/Jenkins
BUT NO - you would use it in testing only. You wouldn't use it as a main platform.
Unless you don't really care - then it's on you.
Many devs run 10.1 and then run -CURRENT in VM's or on a spare laptop or machine for this purpose.
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.
If they're confused on that, they probably have other isses to worry about.
Living with broken software isn't a compromise a lot of users make.
Yeah, because it could totally not slip through to a release... Like, you know, Heartbleed et al...