> You've adopted a LTS release which was made public 2 years ago, was already a couple of years in the making, and is aimed at establishing a solid and reliable base system that can be targetted by the whole world with confidence.
From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release. They just want a quick linux install to run their shit on, or it was handed that way by the Uni department / company / whatever. Or just because it's the biggest name and you're sure to find help online. And then a lot of people don't upgrade - I work with my fair share of people running win 7 (even still have an XP person around), OS X < 10.10 and Ubuntu 14.04, just because they can't afford newer hardware required to make the experience of newer OSes not a laggy shitfest.
> And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure?
gcc is not part of infrastructure, just like Xcode.app or Visual Studio aren't part of Windows or macOS infrastructure.
> From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release.
Your experience and my experience differ greatly, then. I manage around a hundred virtual and bare-metal Ubuntu 18.04 LTS systems. Most of our docker containers (not included in the number above) are based on an Ubuntu 18.04 image because that's what we have standardized our infrastructure around.
The LTS choice was an easy one to make. We are too busy focusing on delivering value to the business to spend much time constantly playing around with the underlying technology. We are not early adopters for much of anything (except hobby projects at home) because we need our technology to be an asset to the business rather than a liability. Depending on new and bleeding-edge software for production systems just creates unnecessary risk.
We'll probably start thinking about upgrading to 20.04 in six months or so.
> We are not early adopters for much of anything (except hobby projects at home) because we need our technology to be an asset to the business rather than a liability.
I'm really glad there are still companies with such values. For some strange reason, these days people equate innovation with using fancy/barely tested tools.
This disagreement is why multiple distros exist. Ubuntu LTS is a reasonable choice for entities that want stability and are willing to accept the occasional migration cost of upgrading to the next LTS (note: this applies to lots of desktop users as well as businesses). Fedora and Arch are reasonable choices if you want cutting-edge software, but come with risks as software changes under them.
> there are a lot more linux users out there than business users
maybe, but there are a LOT more linux servers out there than linux users, if by "linux users" you meant "people running linux on their computers".
those servers (and the people that run them) generally require stability.
would you care explaining what you mean? is it not fair to say that there are many orders of magnitude more instances of linux running on servers than there are instances of linux running on people's home or work computers? that is indisputable, no?
It makes as much sense for me to count individual servers than to count individual docker containers.
It's the amount of people administering those systems which matters - having many servers to manage just means that you have to know how to setup automation
> From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release.
You might be right, that %.05 of people choosing to use LTS distros are doing so for its service promises. But I'd counter that the majority of those who care are managing hundreds or thousands of machines / users. The end users might not know that they care, and that's because the admins are doing a good job.
> for the simple reason that you need the same compiler version to build Linux kernel modules.
Which kernel modules wouldn't come as precompiled packages in Ubuntu ? (real question - as an Arch user for instance I haven't had the need for DKMS for years)
DisplayLink is something that comes to mind. For Arch (btw i use) it needs DKMS and comes out of the AUR[0]. For Ubuntu, it looks like you need some 3rd-party packages that will need to be compiled for modern kernels.
From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release. They just want a quick linux install to run their shit on, or it was handed that way by the Uni department / company / whatever. Or just because it's the biggest name and you're sure to find help online. And then a lot of people don't upgrade - I work with my fair share of people running win 7 (even still have an XP person around), OS X < 10.10 and Ubuntu 14.04, just because they can't afford newer hardware required to make the experience of newer OSes not a laggy shitfest.
> And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure?
gcc is not part of infrastructure, just like Xcode.app or Visual Studio aren't part of Windows or macOS infrastructure.