I've talked to a mail admin from one of the companies involved in "Email made in Germany" once about it, and his reply was basically that of course it was marketing, and of course the techs had the idea to enable TLS in the drawer for years.
But at their scaling, enabling TLS means a lot of additional compute power, and due to that marketing campaign they now finally got the budget to install the additional hardware and enable it. Before, there was no business value that justified to spend that much more to get an - to the outside observer - unchanged product.
BioNTech developed the vaccine now mass-produced by Pfizer. For that, they received $445m from the German government. So, as a tax-paying German citizen I can say, not only will I do that, but even better, I already did.
It also feels deeply wrong to pull the "but all the research efforts that did not lead anywhere" argument, when Pfizer did not do the research in the first place. They should get compensation for organizing the huge trial, of course; that expertise was why they were on-boarded in the first place. And nobody expects them to manufacture that stuff at loss or cost. But we should not accept public money buying them goose laying golden eggs either.
They are not immutable in the 'chflags uchg,schg ' sense.
Updating these files is not in any way shape or form a hassle anymore if you do not update them. etcupdate has that solved. Even mergemaster has specific options to handle unchanged /etc that only diffs in svn-id tags and similar.
But in my opinion the basic premise of the article is false. mergemaster and etcupdate with their diff and 3-way merge capabilities are there because these files are assumed to have local edits.
The startup procedure, scripts, options are expected to be customized; thus the update procedure has handling to preserve local edits.
FreeBSD has had fully integrated, working ZFS for over 10 years. You were so excited to deploy the BSD killer app, you forgot to do so for ten years.
I can only tell you, whatever scary differences you expect between Linux and FreeBSD are probably no more than between any two Linux distros with different packaging systems.
Ten years ago, fresh out of a failed stint at university, I applied for a junior position at a Linux shop. Would nowadays probably be called junior system engineer or so. The night before the interview, I read around a bit in Stevens' TCP/IP Illustrated as well as Design and Implementation of BSD (to calm my nerves). I told them honestly, I had maybe 15 lifetime minutes on a Linux shell. But I started with FreeBSD4.4 and had by then already 8'ish years of experience on general *nix administration.
I'm still there. Pivoted around and upward a couple of times internally. But I still run FreeBSD on my workstation to get things done. And we're still fundamentally a Linux shop.
But the root cause of my career is a friend at university handing me a FreeBSD 4.4 CD. It is a tremendous system if you want to learn about the services a kernel offers to its userland. If you care to make the dive, it not only tells you the what and how, but the why and all the compromises that had to be made along the way. And that understanding is universal.
FreeBSD may be well known as a solid production platform. It's true strength is as the foundation for not only a lifetime of learning, but a lifetime of understanding.
But at their scaling, enabling TLS means a lot of additional compute power, and due to that marketing campaign they now finally got the budget to install the additional hardware and enable it. Before, there was no business value that justified to spend that much more to get an - to the outside observer - unchanged product.