How about a FLOSS archive that provides peer-reviewed and signed application from a trusted source only?
Automated security updates? A security team that can provide fixes independently from the upstream authors?
...because I just described how Debian worked for the last 20 years.
Paying for certification is what's required. Governments require various certifications to sell to them, and that certification costs money in consultancies. RHEL paid for the testing, they get a certification and access to the customer.
It looks like this is probably referring to EAL [1][2].
In a market with a large number of vendors interacting with a large number of relatively unknowledgeable buyers, an oversight team is going to try to find a certification to give guidance (and ass covering).
Yes, this is a barrier to entry, but it's also a learned behaviour as buyers get repeatedly burned.
I would argue that this is equivalent to requiring your plumbers and electricians to be licensed.
It's easy to see conspiracy everywhere, but the truth is usually much more mundane. It costs a lot of money to security-certify an OS, so they probably only wanted to certify a small number. Windows is obviously the most-used desktop OS for PCs, so that seems the logical choice.
...until the unfortunate end user that needs to run tenths of systems runs in a security issue.
Then the admins cannot possibly learn how to fork, patch, rebuild, test, deploy in 20 different languages.
And they cannot rely on security updates from Linux Distributions because they installed vendorized code blobs.
The two are very connected. Yet, even with dynamic linking, the libraries could be always and only bundled with the application, and the application could be designed to work against the bundled versions and not even tested against other versions. On a practical level this makes it extremely expensive to perform updates.
Vendoring is what Linux distributions do. They also provide multi-language automatic builds, security updates and all the other things you mention.
So the problem is not vendoring itself. For a large organization like a Linux distribution, it's a valid technique. However, nobody is maintaining a distribution for the Go ecosystem, or at least not one that's publically available.
This criticism usually comes from people that do not use Nim.
I was very surprised as well at first - now after 1 year of using Nim I realize I never run into any trouble because of case/underscore insensitivity.
#1: those variables have to be in the same scope or be procs working on the same types to be an issue.
#2: I don't use nimgrep, I just keep a consistent style across my files. When reading somebody else's code, case-insensitive search is usually enough.
I suspect this criticism usually comes from people who don't use Nim because anyone inclined to be bothered by it will not use Nim for that reason.
I agree that "just keep a consistent style" is a good approach for single-person projects. It's harder to keep it working well as you get more people working on the code, though.
Actually Nim's attitude is more suitable for group work because every group can have its own style of coding. A simple transformer could be used to normalize the code. However it would force the developers to qualify all imported conflicting names which is a good idea anyway.
You cannot do this in C++ and Rust. There you actually have to keep a consistent style.
At least it's not written in Coffeescript and then further insulting you by calling it a JavaScript project despite being written in Coffeescript.
I've been foolish enough to have been quoted as saying "you can use JavaScript anywhere!" in the past (admittedly at the time, I was working on an embedded platform for TVs where apps were written in JS). Sadly it seems not everyone knows, just because you can doesn't mean you should.
While I agree with the "why!? Node" sentiment of parent, you'd be wrong with this extension. Myself as well as a few friends (who have extensive history with DNS at both a sysadmin and developer level) disprove the theory that there's no overlap in the two skill sets.
I would never contribute to a JS project, but it is the most used language in the world. Which language would you expect to have more overlap than the most used language in the world?
This statement is factually incorrect. C is the most common higher level language across all platforms, especially when you include embedded devices. (I'm not considering Assembly as a higher level language)
...because I just described how Debian worked for the last 20 years.