Hacker News new | ask | show | jobs
by wand3r 3344 days ago
Thats the nature of the beast; everyone wants to release new garbage; which itself was clean until it had to put just a few bits of old rubbish in until it became trash.

Can't find it now but someone posted a Linux mailing list where Torvalds ripped a Dev for breaking something that impacted a user. The dev responded something like the parent: It's a 3rd party app/not Linux responsibility.

The OS has to be stable and the users experience is Paramount. Even a technical crowd (based on the thread) is 50/50 split on this being a Microsoft issue. A non-technical users response: "this software is shit, these idiots broke X in [this version] Microsoft sucks"

1 comments

I believe the thread you're looking for is this one, about never breaking user space:

https://lkml.org/lkml/2012/12/23/75

And this is why the kernel is "everywhere" while "year of the desktop" never happens. Because Linux userspace is all to happy to break itself again and again and again...
Isn't this more of a social problem than a technical one? It seems to me like the main issue is a convention that a system only have a single version of a library installed, the anointed "system" version of that library. And often, binary releases of software are built against a particular cocktail of library versions from a particular distro at the time of release, each of which depends on its own cocktail of libraries, etc... In reality it's not complicated to get virtually any binary running on any system (in the worst case, just put the distro it expects into a chroot) - and there's no reason why applications couldn't just bundle all the libraries they need, right down to glibc - but it's just Not Done.
exactly that. thank you.
And Linus taking glibc devs to task for them breaking Adobe Flash Player, due to a bug in Flash's use of memcpy():

https://lwn.net/Articles/414467/

That was an interesting read; he wasn't even very confrontational there. The point was also solid - they had an internal performance optimization change which was unproven, yet broke things in the real world. That, and the lack of guidelines or tests for what kind of usage results in the behaviour, it's a de-facto "feature" of the interface that they should not break.
I do wonder what the correct workflow is for preventing this - release binaries with assertions in place for development, so that if any of your input constraints are violated that aren't guaranteed to fail fast in the release version, then it's enforced in this debug version?
And it is a point that so much of Linux userspace continue to ignore to thus day...