4 ms·

(I'm the author of the article in question) I disagree completely. Maintaining ABI compatibility is crucially important, and the kernel development community

by 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
      I was arguing more in terms of market- and mindshare than in terms of technical merit. Yes, Solaris grew a few very strong subsystems. The problem is that your list ends very shortly after Dtrace, ZFS and Zones (which is already matched by OpenVZ anyways). Those few bright spots are simply not enough reason for most people to put up with with an OS that is otherwise firmly stuck in the 90s (horrible userland, absence of a package manager, no worthwhile mass provisioning options, etc.).
      - gaius 17y ago
        What came first, Jumpstart or Kickstart? Again, Linux is playing catch-up. And the userland/package manager problem is neatly addressed by Blastwave.org.
        moe 17y ago
        This is leading offtopic, but anyways. What came first, Jumpstart or Kickstart? Again, Linux is playing catch-up. Jumpstart, Kickstart? Well, I guess they were hot in 2001, yes. All sizable solaris deployments I know today are struggling with FAI, puppet and a lot of custom glue scriptery to enable at least a basic grasp on their deployments. JET and the ilk is just not even touching a worthwhile real-world problem. And the userland/package manager problem is neatly addressed by Blastwave.org. Likewise I can only scratch my head over reading blastwave and "neat" in the same sentence. Have you even used it? I'm in fact a bit surprised it still exists because most solaris admins seem to either scoff at the idea altogether and stick with the regular pkgadd, or look for greener pastures in OpenSolaris - which wisely refrained from any attempts to re-invent apt. Well, but as said, my initial point wasn't even about discussing implementation details in one way or another. There is no doubt solaris displays great technical excellence in some areas. Unfortunately too often these are not the areas that people in the real world care about.
barrkel 17y ago
That's why (for example) Windows has compartmentalized and "pluginized" its AppCompat infrastructure. ABI compatibility trumps almost every other concern, IMHO.

by corbet 17y ago

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
    I was arguing more in terms of market- and mindshare than in terms of technical merit. Yes, Solaris grew a few very strong subsystems. The problem is that your list ends very shortly after Dtrace, ZFS and Zones (which is already matched by OpenVZ anyways). Those few bright spots are simply not enough reason for most people to put up with with an OS that is otherwise firmly stuck in the 90s (horrible userland, absence of a package manager, no worthwhile mass provisioning options, etc.).
    - gaius 17y ago
      What came first, Jumpstart or Kickstart? Again, Linux is playing catch-up. And the userland/package manager problem is neatly addressed by Blastwave.org.
      - moe 17y ago
        This is leading offtopic, but anyways. What came first, Jumpstart or Kickstart? Again, Linux is playing catch-up. Jumpstart, Kickstart? Well, I guess they were hot in 2001, yes. All sizable solaris deployments I know today are struggling with FAI, puppet and a lot of custom glue scriptery to enable at least a basic grasp on their deployments. JET and the ilk is just not even touching a worthwhile real-world problem. And the userland/package manager problem is neatly addressed by Blastwave.org. Likewise I can only scratch my head over reading blastwave and "neat" in the same sentence. Have you even used it? I'm in fact a bit surprised it still exists because most solaris admins seem to either scoff at the idea altogether and stick with the regular pkgadd, or look for greener pastures in OpenSolaris - which wisely refrained from any attempts to re-invent apt. Well, but as said, my initial point wasn't even about discussing implementation details in one way or another. There is no doubt solaris displays great technical excellence in some areas. Unfortunately too often these are not the areas that people in the real world care about.

barrkel 17y ago

That's why (for example) Windows has compartmentalized and "pluginized" its AppCompat infrastructure. ABI compatibility trumps almost every other concern, IMHO.