4 ms·

If you want to read some actual detail on this, read this LWN article: http://lwn.net/SubscriberLink/343828/d298eb0f131f2039/ http://lwn.net/SubscriberLink/3438

by rythie 17y ago

If you want to read some actual detail on this, read this LWN article: http://lwn.net/SubscriberLink/343828/d298eb0f131f2039/ http://lwn.net/SubscriberLink/343828/d298eb0f131f2039/

barrkel 17y ago
A telling piece of opinion in that article: > This code worked with the older TTY code, but broke with 2.6.31. There is probably no way to fix it which doesn't saddle the kernel with maintaining weird legacy bug-compatibility code "Maintaining weird legacy bug-compatibility code" is the essence of professional and responsible platform software engineering - the software that other software relies upon. It's one of the reasons why platform software development is so hard and why software engineers are paid as much as they are. There's another misguided notion mentioned that I see a lot in both open source and Wikipedia, two kinds of crowd-sourcing efforts which generally desperately seek authority-figures of some kind, like "standards": > Alan thinks this behavior is reasonable; it complies with the applicable standards Compliance to the "applicable standards" isn't worth anything if it breaks software and makes users' lives worse. It's not for nothing than POSIXLY_CORRECT applies to many GNU apps, and is not enabled by default.
- corbet 17y ago
  (I'm the author of the article in question) I disagree completely. Maintaining ABI compatibility is crucially important, and the kernel development community understands that. But ABI compatibility does not mean going to all lengths to enabling buggy code to continue to work. In this case, "fixing" kdesu would have required putting in code to recognize this specific data stream and ensure that a read terminated exactly where it always used to so kdesu wouldn't get confused and throw away good data. It would be an albatross around the neck of any developer working in the TTY layer for years, and those developers are already up to their asses in albatrosses. All to perpetuate an easily-fixed bug in an open-source application. That kind of "compatibility" wrecks your platform over the course of a few years; you simply can't maintain code like that. A "professional and responsible" software engineer needs to recognize that and avoid it.
  - Gormo 17y ago
    Maybe Linux (and other similar projects) ought to divide into separate streams - one "research" trunk, that focuses on cleanliness, elegance, and standards compliance and is not constrained by backward compatibility commitments, and from which multiple "practical" branches might diverge, each always maintaining compatibility to its point of origin, despite the tendency to accumulate cruft as it evolves.
    - davidw 17y ago
      You're free to fork it:-) Quick answers aside, those guys work hard to try and make everyone happy with the resources they have available, and it's not an easy job.
  - gaius 17y ago
    Maintaining ABI compatibility is crucially important, and the kernel development community understands that. History suggests otherwise. Compare that to Sun's attitude, which is if your old binary doesn't run on the latest Solaris then it's a bug in our code and we'll fix it.
    - moe 17y ago
      Well, also compare where solaris is today. Software development is about trade-offs and apparently linux wasn't hurt as bad by the occassional ABI breakage as solaris was hurt by the "backwards compatibility above all" mindset (which ofcourse reaches way beyond the basic ABI). It's all about the albatrosses.
      - gaius 17y ago
        Dtrace and ZFS and other features that Linux is struggling to copy (e.g. SystemTAP and BTRFS). Backwards compatibility in Solaris is a matter of minor annoyances (e.g. ksh93) it hasn't hindered it being a cutting-edge Unix.
        moe 17y ago
- rbanffy 17y ago
  ""Maintaining weird legacy bug-compatibility code" is the essence of professional and responsible platform software engineering" I couldn't disagree more with your point. Open source is about openness. This is about evolving a platform in a clean and open way. If someone's program is buggy and does weird things it shouldn't do, then the bug should get fixed, not a bug be added to another piece of software in order to make the buggy program (that worked properly only by accident) still work. A feature that is not needed is a bug all in itself. If your old program won't work with your new OS, then don't upgrade. There is no pressing need to run the latest and greatest OS, at least not in "professional and responsible" environments.

by rythie 17y ago

If you want to read some actual detail on this, read this LWN article: http://lwn.net/SubscriberLink/343828/d298eb0f131f2039/ http://lwn.net/SubscriberLink/343828/d298eb0f131f2039/

barrkel 17y ago

A telling piece of opinion in that article: > This code worked with the older TTY code, but broke with 2.6.31. There is probably no way to fix it which doesn't saddle the kernel with maintaining weird legacy bug-compatibility code "Maintaining weird legacy bug-compatibility code" is the essence of professional and responsible platform software engineering - the software that other software relies upon. It's one of the reasons why platform software development is so hard and why software engineers are paid as much as they are. There's another misguided notion mentioned that I see a lot in both open source and Wikipedia, two kinds of crowd-sourcing efforts which generally desperately seek authority-figures of some kind, like "standards": > Alan thinks this behavior is reasonable; it complies with the applicable standards Compliance to the "applicable standards" isn't worth anything if it breaks software and makes users' lives worse. It's not for nothing than POSIXLY_CORRECT applies to many GNU apps, and is not enabled by default.

corbet 17y ago
(I'm the author of the article in question) I disagree completely. Maintaining ABI compatibility is crucially important, and the kernel development community understands that. But ABI compatibility does not mean going to all lengths to enabling buggy code to continue to work. In this case, "fixing" kdesu would have required putting in code to recognize this specific data stream and ensure that a read terminated exactly where it always used to so kdesu wouldn't get confused and throw away good data. It would be an albatross around the neck of any developer working in the TTY layer for years, and those developers are already up to their asses in albatrosses. All to perpetuate an easily-fixed bug in an open-source application. That kind of "compatibility" wrecks your platform over the course of a few years; you simply can't maintain code like that. A "professional and responsible" software engineer needs to recognize that and avoid it.
- Gormo 17y ago
  Maybe Linux (and other similar projects) ought to divide into separate streams - one "research" trunk, that focuses on cleanliness, elegance, and standards compliance and is not constrained by backward compatibility commitments, and from which multiple "practical" branches might diverge, each always maintaining compatibility to its point of origin, despite the tendency to accumulate cruft as it evolves.
  - davidw 17y ago
    You're free to fork it:-) Quick answers aside, those guys work hard to try and make everyone happy with the resources they have available, and it's not an easy job.
- gaius 17y ago
  Maintaining ABI compatibility is crucially important, and the kernel development community understands that. History suggests otherwise. Compare that to Sun's attitude, which is if your old binary doesn't run on the latest Solaris then it's a bug in our code and we'll fix it.
  - moe 17y ago
    Well, also compare where solaris is today. Software development is about trade-offs and apparently linux wasn't hurt as bad by the occassional ABI breakage as solaris was hurt by the "backwards compatibility above all" mindset (which ofcourse reaches way beyond the basic ABI). It's all about the albatrosses.
    - gaius 17y ago
      Dtrace and ZFS and other features that Linux is struggling to copy (e.g. SystemTAP and BTRFS). Backwards compatibility in Solaris is a matter of minor annoyances (e.g. ksh93) it hasn't hindered it being a cutting-edge Unix.
      - moe 17y ago
rbanffy 17y ago
""Maintaining weird legacy bug-compatibility code" is the essence of professional and responsible platform software engineering" I couldn't disagree more with your point. Open source is about openness. This is about evolving a platform in a clean and open way. If someone's program is buggy and does weird things it shouldn't do, then the bug should get fixed, not a bug be added to another piece of software in order to make the buggy program (that worked properly only by accident) still work. A feature that is not needed is a bug all in itself. If your old program won't work with your new OS, then don't upgrade. There is no pressing need to run the latest and greatest OS, at least not in "professional and responsible" environments.