Linux Changes Pipe Behavior After Breaking Problematic Android Apps On Recent Kernels

[uxmkt]

Quick, just write a program that relies on the new behavior, then you can claim regression if and when it does switch back to the 4.x behavior in 5.14.

[pmorph]

Quick, just write a program that relies on the new behavior, then you can claim regression if and when it does switch back to the 4.x behavior in 5.14.

I suppose what matters is how bad the end user effect will be. Similarly as no company would choose to break the products their customers are using, just to make something technically correct.

[arQon]

I do believe this is one of the few times Linus is in the wrong on that pledge

Agreed. What's puzzling though is I think the "right" solution here is obvious: this is something that *mainline* should fix, and Android should carry the hack out of tree.

"We don't break userspace" notwithstanding, I don't see why that isn't the path he's chosen here. Especially since Android is realistically a closed-source project anyway. I don't see any reason for the kernel not to treat it the same as nvidia drivers or any other such case where non-GPL software is involved, and the responsibility for coping with kernel changes lies with the people who've chosen to opt out of the GPL ecosystem.

[Charlie68]

Wait, so technically anyone who has found a bug that needs to be adressed, can write some dumbass code that uses it, and then effectively hold the entire Linux kernel hostage?
Surprising that it hasn't happened before.

This is just an extreme concept, the software is much more complicated and some changes can lead to breakages, if these breakages concern a large number of devices and systems, if it is not a security problem it is reasonable to give time to modify this behavior. Time has actually been there, but being Android (in this case) using an old Lts kernel, only now they have noticed.
Linus simply made a reasonable decision, as he does not compromise the security of any devices and gives time to troubleshoot.

[sophisticles]

Can someone explain to me what this means:

some Android libraries abused the functionality

There was certain functionality built into the API and libraries where coded to use it.

How is this the applications' or libraries' fault?

[bachchain]

How is this the applications' or libraries' fault?

Because it was undefined behavior, and relying on undefined behavior is wrong.

[curfew]

There was certain functionality built into the API and libraries where coded to use it.

How is this the applications' or libraries' fault?

The documentation (supposedly) clearly stated that a signal has purpose X, but a bunch of developers used it for another purpose Y, because by consequence it seemed to work how they wanted it to work. But then the code changed, still remaining fully compatible with the intended/documented/allowed use cases, but it became useless for the purpose Y.

Nowhere was there ever any "permission" to do Y with this signal so there is also no permission to whine that is has been broken. Usually when you do stuff that goes against the intention of the said feature, then it's your problem if the feature changes in a way that doesn't allow for your crazy monkey business anymore.

[curfew]

To my understanding Android phones are usually more or less locked into a specific kernel version (or two) even between major Android upgrades? So this looming kernel upgrade was never going to break any (apps on) existing phones anyway? Given that Linux is on its way out soon anyway, Google is ramping up with its Fuchsia OS, why would you bend over backwards to avoid upsetting some crappy software vendors on a platform that's barely yours anyway?

What upsets me is that it reeks of submission to commercialism. What happens when KDE or Gnome devs come and say that we did something stupid, can you lock your kernel to this ridiculous setting until the end of time because we are busy doing more fun things? Now something that was previously undocumented is suddenly a documented, officially-sanctioned feature, and they will have to honour that commitment forever.

[ed31337]

This is fantastic. One of the big problems with developing on Windows was that Microsoft would constantly change things in subtle ways and mysteriously break stuff people downstream are using. Then there were all the things that were overtly dropped, deprecated, etc (a problem Google commits so often too).

Linux is so much better to work with because code written today will continue working for a long, long time thanks to Linus's excellent stewardship.

[andreano]

Microsoft would constantly change things (…) drop, deprecate, etc

Anecdotally, they are also trying ridiculously hard not to break userspace, to the point where it hurts their API:

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/

That's an old post though, so I may be outdated on that.