> I'd suggest building an auto-upgrade system on top of Arch (or Alpine), and go for immutable infrastructure as the selling point. That's stepping on CoreOS's toes a bit, but I haven't seen any progress from that crowd ever since Red Hat bought them, so it'll probably get even worse now.
In that case, why not go all the way over to NixOS? They already have a more or less complete cloud stack with NixOps, the only problem is hardly anyone knows how to use it.
I agree that it's a nontrivial problem to learn a piece of complex software from scratch to the point that you can offer comprehensive enterprise support for it, but how is that show-stopping?
No, I mean NixOS/NixOPS being incomprehensible to a large amount of us even after several years of existing. That's a huge problem, and it's their problem.
I'm not sure what the cause is. If it's a fundamental technological problem, then it's insurmountable, but if it's just a documentation problem, then it might be fixable. It doesn't look good though, since, like I said, the whole stack has existed for a long time. You would think that something would've been done about it.
All that said, perhaps I'm just dumb. I'll be happy to see someone prove me wrong and succeed with that combo. The underlying technology is certainly interesting and powerful. But I won't be trying it.
> "the cloud" is, and always has been, antithetical to Unix (Unix being about site autonomy and simple tools working together)
Does the physical hardware being on the actual premises or not really have anything to do with "site autonomy" or the granularity of the toolchains?
In fact, can you even buy any viable physical hardware to run on your site that's not already a virtualised "cloud" with the real host OS firmly in the control of your corporate overlords, e.g. Intel ME and AMD PSP?
I'm going to go against the grain here and say that the cloud is not simply 'server hosting' because, if that was the case we'd still be calling them VPS'.
"The cloud" is a set of APIs for provisioning but also a bunch of managed services that surround your instances, pub/sub, DNS, load balancers, managed SQL. All of this is almost designed to be a vendor lock-in.
However, disregarding the vendor lock-in: How does my OS integrating with AWS's APIs help my on-prem services?
> "The cloud" is a set of APIs for provisioning but also a bunch of managed services that surround your instances, pub/sub, DNS, load balancers, managed SQL. All of this is almost designed to be a vendor lock-in.
A lot of it is, but I strongly disagree that all of it is. Many of these are perfectly interchangeable with the exact same software (FOSS DBMS, web server, load balancer, etc.) running on a competitor's managed service, VPS or on your own premises. As for the services that aren't, I do think the IT architects and managers who agree to use them are absolutely crazy and ought to be fired. If all of them are fired, cloud providers would be forced to provide interoperable provisioning APIs and services or perish.
> However, disregarding the vendor lock-in: How does my OS integrating with AWS's APIs help my on-prem services?
I suppose it doesn't, but why should it? If you think they bloat up your local installation, maybe you can just not install the kernel modules/daemons/libraries in question.
Does it say anywhere in that manual why the right margin is supposed to be so narrow? I find it very uncomfortable to read texts with very narrow margins.
SCART is another disgusting connector that European readers will be familiar with. I like the idea of combining multiple video formats with sound as a predecessor to HDMI, but the least they could have done was put a decent D-sub or the Amphenol-style ribbon connector.
I recently got pretty heavily into SCART connectors because of retro video game stuff (the most common rgb connector you can use with older consoles is scart) and after a few months I've thrown it all away in exchange for special component cables instead because scart is just terribad in terms of staying connected.
Can't count the number of times I've had colour production go wonky just because of a tiny bump of the scart cable.
Connected a SCART TV and STB when I first moved to France. The cable was stiff, heavy, and unwieldy and it neve quite fit once everything was pushed back into the cabinet.
> For instance, call them by the names they use, and honor their preferences about their gender identity
That's a backhanded way of cementing the validity of the concept of "gender expression" throughout the GNU project.
I would have been perfectly on board with a guideline that simply said not to police people's gender expressions, the question being rather off-topic and disruptive in the given context. That would do the job regardless of what your political opinions on the gender question are.
The question is how to talk to and about other members of the community.
Calling other people by their preferred names is a basic norm that goes beyond gender.
Gender expression is rarely relevant in the context of software development, but gendered language is common enough in English to make the issue of gender identity unavoidable. You can require speakers to respect others' preferences, mandate gender-neutral language, or allow speakers to refer to others however they like.
Is it not possible to refer to someone by the name and pronouns they refer to themselves by not because you believe in the validity of transgenderism, but because that has simply always been the social convention? Gender identity needs to play no part in it, even if gendered language is being used. The outcome in the software should be the same whether the developer who claims to be a woman is really a man or vice versa.
Someone who isn't satisfied with that but rather requires full intellectual submission to their ideology is just as disruptive on a software mailing list as those who go out their way to "root out the trannies".
> While the original Pentium, a superscalar x86, was an amazing piece of engineering, it was clear the big problem was the complex and messy x86 instruction set. Complex addressing modes and a minimal number of registers meant few instructions could be executed in parallel due to potential dependencies. For the x86 camp to compete with the RISC architectures, they needed to find a way to "get around" the x86 instruction set.
I've always struggled to understand why they didn't simply retire the x86 instruction set by the early 90s.
The best reason I've been given is an existing body of x86 software, but that's obviously nonsense as demonstrated by the Transmeta Crusoe and Apples's move from 68k to PPC to x86.
In that case, why not go all the way over to NixOS? They already have a more or less complete cloud stack with NixOps, the only problem is hardly anyone knows how to use it.