I could be wrong, but isn't the entire debian stable tree maintained for years via open source contributions? Sure the redhat downstreams might be on their own, but there's plenty of non-commercial distros that keep up to date.
this post was submitted on 29 Jul 2023
95 points (98.0% liked)
Linux
48003 readers
1166 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
According to Debian Releases
Debian announces its new stable release on a regular basis. Users can expect 3 years of full support for each release and 2 years of extra LTS support.
So about 5 years, though it is not clear how well this works in practice (how much is actually updated and how well supported).
From the Debian Wiki - LTS:
Companies using Debian who benefit from this project are encouraged to either help directly or contribute financially. The number of properly supported packages depends directly on the level of support that the LTS team receives.
I think this is sort of what the article is pointing towards... long-term support really depends on commercial support, as volunteers are more likely to work on the current or more recent thing than go back and backport or update older things. If corporate funding dries up (which it appears to be doing), then while volunteers will still contribute some to long-term linux distributions, it won't be at the same level it currently is with commercial support.
Yes but the real issue is the downstream have had it pretty easy and now have to do more work.
The rationale for using LTS distros is being eroded by widespread adoption of containers and approaches like flatpak and nix. Applications and services are becoming less dependent on any single distro and instead just require a skeleton core system that is easier to keep up to date. Coupled with the increased cost needed to maintain security backports we are getting to a point where it's less risky for companies to use bleeding edge over stable.
widespread adoption of containers and approaches like flatpak and nix
And it's about flippin time. Despite predating app stores by decades, the Linux package systems have been surprisingly conservative in their approach.
The outdated and hardcoded file hierarchy system combined with the rigid package file management systems have ossified to a ridiculous degree.
It's actually telling that Linux packaging systems had to be circumvented with third party approaches like snap, flatpak, appimage etc. — because for the longest time they couldn't handle stuff like having two versions of the same package installed at the same time, or solving old dependencies, or system downgrades, or recovery etc.
Linux had advanced stuff like overlayfs 20 years ago but did not use any of it for packages. But we have 20 different solutions for init.
Like everything, it's a trade off. Windows allows different versions of the same libraries, but at the cost of an ever growing WinSXS folder and slow updates
And that skeleton of a system becomes easier to test.
I don't need to test ~80 - 100 different in-house applications on whatever many different versions of java, python, .net and so on.
I rather end up with 12 different classes of systems. My integration tests on a buildserver can check these thoroughly every night against multiple versions of the OS. And if the integration tests are green, I can be 95 - 99% sure things will work right. The dev and testing environments will figure out the rest if something wonky is going on with docker and new kernels.
I believe that the main problem is how companies work. If I say finance that I want to donate to an open source project half of what we are paying for the licenses of the alternative rubbish commercial product we are using now, they will simply say no. No discussion at all. We always need to find commercial entities that work via licensing to support open source tools. This is also a reason of the success of red hat compared to debian. Companies don't pay debian, I couldn't even if I would like, because they don't offer a package of enterprise licenses... That is the only option finance understand
It is crazy and a pity...
Agreed, but there's more to it than just "we need to pay for support contract." There's also "we want a contract that indemnifies us against a FOSS reciprocal license claim against the product we sell." That is something that really contributed to RHEL's dominant position.
Linux can work without big and bloated components. Companies funded development of components that are replaceable by simpler and easy to maintain ones.
Interesting article, thanks for sharing