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?

Yes, people should read the manual.

And FreeBSD should name things better. Those two things are not mutually exclusive.

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 you give inaccurate information and then correct it in the manual, you still gave inaccurate information.

If you didn't read the manual before putting something in production, you still didn't do your job properly.

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.

I would not state it as broadly as "computer people."

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.

Who gave you inaccurate information? Assuming CURRENT means stable is just plain assuming.

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

If you go here: https://www.freebsd.org/where.html

There is RELEASE, CURRENT, STABLE. If you choose one without knowing the difference as to what those titles mean, you deserve whatever comes next.

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.

Many projects use "head" to refer to their development branch. That's equally as non-meaningful, yet nobody complains about that.

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

Given that... wouldn't -DEV or -EDGE or -UNSTABLE make more sense?