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