[concede_pluto]

If we ship code that runs on SuSE 234 and RHEL 345, that's what we test on. If we run on our own hardware or AWS, we pick a distro and test on that. I don't care whether it builds or runs on a laptop; I don't write twitch games and interesting problems don't fit on a single machine anymore.

It's been a decade since I worked at such a tiny nascent company that all the software was written in just one language. Language packages almost never express dependencies on either system packages or other languages' packages, making "bootstrap to the point of being able to use all of the languages' toolchains" a manual process that lacks any guardrails. Nothing ensures you have a httpd version that's compatible with all your apps, because each of them just sort of assume httpd is out there somewhere without saying anything about it. Staying on the right versions of shared libraries is even more error-prone since the system package manager literally doesn't know you're using them.

If you want to read upstream security advisories and use such bleeding-edge software that even the bleeding-edge distros don't trust it yet, you're basically rolling your own distro that only exists on one machine in the world (because some languages' package managers aren't idempotent and symmetric) and is supported by nobody besides you. I'd rather delegate that to the people who specialize, because the best case is that I don't fuck it up too badly, I'll never add value that way.

[ubernostrum]

If we ship code that runs on SuSE 234 and RHEL 345, that's what we test on.

By all means run the test server as an environment identical to production. I've never said you shouldn't. But people do have to locally run the code on their laptops to do dev work.

I don't care whether it builds or runs on a laptop

Good for you! Now, clean out your desk, because "build custom infrastructure to suit my workflow, but your workflow isn't important" is a clear admission that you don't ever get to work on my team, or probably anyone else's.

I don't write twitch games and interesting problems don't fit on a single machine anymore.

Ah, so you only will work on "interesting" problems, and literally all possible problems you don't find "interesting" are in categories like "twitch games", to be insulted and belittled. It's a good thing you were already fired a paragraph ago, because you'd get fired for that too; turns out most companies don't have problems you'd consider "interesting". So sorry for that, but them's the breaks.

It's been a decade since I worked at such a tiny nascent company that all the software was written in just one language.

With a head that big, what's your size in hats?

Language packages almost never express dependencies on either system packages or other languages' packages

But to actually respond: how many single applications do you think the average company has which are written in, say, five or more different languages and must deploy the entire codebase to a single machine? You know, that single machine you refuse to work with, because it must be just for a "twitch game" or some other tiny puny baby child's toy of a program.

If you want to read upstream security advisories and use such bleeding-edge software that even the bleeding-edge distros don't trust it yet

So sorry that I wanted to use the version with the feature that didn't make it in under the distro's freeze date. Guess we'll just wait ten years until the support contract expires and we're finally forced into an OS upgrade, then? Management will be very happy to hear that timeline, I'll bet they give you a promotion and a raise when they find out you're the one holding it up!

you're basically rolling your own distro that only exists on one machine in the world

I have reproducible builds using language packaging toolchains. Turns out it's 2017 and we can do that now.

I'd rather delegate that to the people who specialize, because the best case is that I don't fuck it up too badly, I'll never add value that way.

There are parts of this sentence that I agree with.

[concede_pluto]

I don't mean to disparage twitch games, that's my go-to example of one of the last domains where it's cost-effective to get really good at living within customers' hardware constraints. But when prod is a growing distributed system, it's natural for tests to assume the same distributed system, and forcing those tests to sort-of run on a single box with the wrong kernel/fs/network config just trades in cheap hardware for expensive engineers doing work that doesn't make prod better.

When I write java, I can't run maven in prod and expect it to get native libraries into /usr/lib64 and the sysadmins' Python and Go plumbing and config files into ... wherever the hell that may live. So together we tweak a .spec file that not only provisions the entire machine correctly but answers questions about whether the entire machine is provisioned correctly, not just the java half. (We probably could make maven do all that, but the result would be worse in every conceivable way, and in most languages it's not even an option.)

If you want a rolling release distro, use one. Godspeed. But nobody's going to sell a support contract that covers random alpha builds published overnight. "We can't upgrade the distro and get the code we need, so we're smuggling in code that the distro doesn't trust yet" is just devs and sysadmins playing chicken over the fate of the project. The bleeding-edge vs supported argument should have been settled before going live.