Linux Pipe Code Again Sees Patch To Restore Buggy/Improper User-Space Behavior

[NobodyXu]

NobodyXu

You're unintentionally confirming what I said with your argument -- both that the kernel could use a way to break itself during an anticipated update and that if you don't pay for maintainers the community is expected to step up and become maintainers.

You basically listed example after example of why anticipate updates with breaks/changes are necessary. Even gave an example of a build system to cope with all the versions and changes over the years and decades...and gave a better name than grace period. There is no reason the kernel can't do the same with a major version change. Turn the last 5.X into ELTS and let 6.0 drop any fixes, duplicated efforts, etc because of things like this (not like I have a running tally here).

While potentially a pain, I can't think of another way for the kernel to truly advance itself...maybe only doing that once every 10 or 20 years to reduce the burden.

They don’t have to annouce a 6.0 for such change…Just add another new syscall, problem fixed.

Or, add a new bitflag to pipe2 (not pipe) syscall https://man7.org/linux/man-pages/man2/pipe.2.html

[skeevy420]

They don’t have to annouce a 6.0 for such change…Just add another new syscall, problem fixed.

Or, add a new bitflag to pipe2 (not pipe) syscall https://man7.org/linux/man-pages/man2/pipe.2.html

How many of those exist in the kernel? Both an old and a new way.

I don't understand why both have to stick around after major version changes. Not breaking userspace seems like too rigid of a protocol to be sustainable for another 30 years. For another hundred and thirty years. What if this is done wrong, a new language feature comes out, etc? Will that lead to a pipe3? A pipe8?

And that begs the question of what's the point of Extended Long Term Support (and Long Term Support to an extent)? Why can't the people who have to stick with the old use that? Why can't ELTS be used as Linux Legacy?

And if they're not allowed to break userspace, how come they can break user hardware? How come they can drop hardware support? At some point following that protocol becomes silly when you look at it in that regard.

I don't consider the answer of "just add more on top" to be a good answer when there are means in place to facilitate the making of what could be called a "next-gen" Linux kernel, the handling of long term and/or legacy users, and dropping kernel syscalls and code that need dropping.

And I'm just using 6.0 because the kernel is in the 5.X series. 6 is just the next major revision number and the major revision number is where most other projects do breaking changes...just easier to use as a talking point/rhetorical example.

[stargeizer]

You people forget the fact that Linus Torvalds is the guy that mandates the kernel, and for him, the only unbreakable rule is "do not break userspace". All of the rest of rules he can (and had) forego in the past when necessary (Albeit reluctantly, and with colorful language answers). And also, he also mentioned many times that kernel versioning has nothing to do with the MAJOR.MINOR semantic. He just put minor versions up to 20 and automatically ups the major version by one when minor reaches 21.

You can argue advantages and disvantages for versioning APIs, but for reference, the OS that everyone hates here (except Birdie, who loves it), also has the same restrictions. The Win32s userspace interface is unchanged since windows 2000. (And yes, you can run software for windows 2000 on windows 10, except for those software written using undocumented API's, or use creative kernelspace antipiracy protection schemes, or games that used creative ways to abuse DirectX or OpenGL, for those there's the compatibility troubleshooter). Nowadays they tried to have versioning API's since windows 8 in parallel ,but they failed to impress programmers and external developers with these, (Remember .NET and how was rejected in the beginings?? It wasn't until version 4 of the API that coders accepted to use it, but M$ still had to support the old Win32s API, and will do so even in windows 11.).

This will change?? Probably when Torvalds leaves kernel developing and the next leader can be convinced to clean the userspace API. Knowing the devs, the probability is basically nil.

[Ironmask]

Python updated and all the scripts adapt.

Not a great analogue, since Pythons scripts did not adapt, and instead there are simply two simultaneous versions of Python, and there always will be, because it's a popular programming language, just like COBOL. Python is used as an example to language designers what not to do when upgrading your language.

[NobodyXu]

How many of those exist in the kernel? Both an old and a new way.

I don't understand why both have to stick around after major version changes. Not breaking userspace seems like too rigid of a protocol to be sustainable for another 30 years. For another hundred and thirty years. What if this is done wrong, a new language feature comes out, etc? Will that lead to a pipe3? A pipe8?

And that begs the question of what's the point of Extended Long Term Support (and Long Term Support to an extent)? Why can't the people who have to stick with the old use that? Why can't ELTS be used as Linux Legacy?

And if they're not allowed to break userspace, how come they can break user hardware? How come they can drop hardware support? At some point following that protocol becomes silly when you look at it in that regard.

I don't consider the answer of "just add more on top" to be a good answer when there are means in place to facilitate the making of what could be called a "next-gen" Linux kernel, the handling of long term and/or legacy users, and dropping kernel syscalls and code that need dropping.

And I'm just using 6.0 because the kernel is in the 5.X series. 6 is just the next major revision number and the major revision number is where most other projects do breaking changes...just easier to use as a talking point/rhetorical example.

IMHO in this case it’s because removal of driver only happens if:
- the hardware has almost disappear from the market
- nobody is willing to maintain it (likely because they also don’t have one anymore)

And that is probably the same as Linux syscall.
When all the softwares that relied on it has moved on, then it’s likely that they can get it removed.

Second, if you treat LTS as legacy, then every software we use are legacy.
Once a technology/software is rolled out to the public, it is legacy because by the time it becomes mature enough, it’s probably already depending on legacy technology that has released a new version.

Example will be Java 8 and Java 11.
The latest version java is Java 16, released this year, but again, not many projects have switched to it yet.

Many projects are still sticking with Java 11, some even sticks with Java 8.

Same for other languages, such as C++.
C++17 has released for 3 years, but the adoption rate is slow.

And that are not limited to programming languages, but also to softwares/frameworks writen upon it.

I think you misunderstand how industry works.
You think they are willing to adopt new technology and throw away the old one as long as the new ones are mature and supported.

THIS IS SIMPLY NOT THE CASE.

The industry don’t throw away usable softwares.
They only do that when it’s absolutely necessary due to serious bug/security problem, or adding so many new features that existing tech cannot cope with it anymore.

The one you see that adopt new technology ASAP are the fraction and are limited to certain usecase.
Most won’t adopt as soon as it’s available and won’t throw away they existing implementation until decades later.

That’s why COBOL is still a thing.

[yump]

Not breaking userspace seems like too rigid of a protocol to be sustainable for another 30 years. For another hundred and thirty years. What if this is done wrong, a new language feature comes out, etc? Will that lead to a pipe3? A pipe8?

yeschad.tif

You may not like it, but that is what 1,000 year software looks like.

The python 2-3 transition was an enormous clusterfuck, and an example that should not be repeated.