7 ms·

Alan Cox Quits As Linux TTY Maintainer — "I've Had Enough"

deleted 17y ago
[deleted]
zaph0d 17y ago
From TFA - "After reading the thread on a mirror, it's important to note that after the argument, Alan and Linus continued to debate the technical merits of how to patch the bugs. The ongoing conversation was civilized and concise. Of course Linus is too much of a pompous ass to apologize to Alan for completely misunderstanding the problem and proposing dangerous and useless ways of fixing it, then arguing about it ad nauseum. Oddly, this doesn't seem to bother Alan or maybe he's just used to it."
- DarkShikari 17y ago
  This is one thing I have found true of great open source developers in general: regardless of their attitude, regardless of past events, regardless of the situation, they can carry on technical debates on how to deal with an issue. In other words, for such people, the technical merits of an idea supersede all other aspects.
  - pbhjpbhj 17y ago
    I read the thread (didn't understand most of it) but Torvalds describes Cox work as "crap" and tells him "you're full of crap". Way to stick to the technical merits there ... That's some attitude.
    - DarkShikari 17y ago
      Did I ever say I was referring to Linus? ;)
      - pbhjpbhj 17y ago
        No, I didn't assume you did. My comment was partially tangential (now there's a geeky oxymoron).
spoondan 17y ago
What I find impressive is that Alan continues to assist on the issue after he has "had enough", providing in-detail responses to questions and correcting part of Linus's patch. I think he also responded to Linus's initial complaint with grace and aplomb. I'd like to think I am poised and dedicated, but I doubt I am even half so as Alan.
- rythie 17y ago
  He has been doing it since 1991, and spent 10 years working at RedHat.
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.
radioactive21 17y ago
nerd fights make great drama. let me know when episode two starts. I wanted to edit that it would be freaking hilarious if Alan went and worked with Microsoft.
akkartik 17y ago
Alan: http://linux.slashdot.org/comments.pl?sid=1319387&cid=28875027 http://linux.slashdot.org/comments.pl?sid=1319387&cid=28... Linus: http://linux.slashdot.org/comments.pl?sid=1319387&cid=28873731 http://linux.slashdot.org/comments.pl?sid=1319387&cid=28... Coda: http://linux.slashdot.org/comments.pl?sid=1319387&cid=28873411 http://linux.slashdot.org/comments.pl?sid=1319387&cid=28...
- sachinag 17y ago
  Wait, none of these comments are actually made by the people you say they are.
  - akkartik 17y ago
    Yeaaaah.. they were summaries of positions. Thanks for insinuating that I was being misleading. Did you really think 'Coda' was a person? I've been watching parent get upmodded and my comment get downmodded with increasing disbelief. Time was that +16 used to mean it was not to be missed, and -4 was a troll or ad hominem.
    - benreesman 17y ago
      The voting is completely out of whack these days. I'm not sure if the constituency of the community has changed, or if people are just feeling ornery.
JeremyChase 17y ago
Being a fan of the BSDs I have to point out that this type of decision would not happen there. The reason being that the kernel and userland are not separate entities; they are a system. If you update your kernel the userland has to update with it, and that is to accommodate changes just like this.
- Saavedro 17y ago
  I would point out that the userland in BSDs that would update with the kernel would be the CORE utilities and programs. Say, like GNU utils on a linux distro. kdesu is part of KDE, which is an application installed on top of the OS, not something maintained as part of the OS. Would you say there wouldn't be any issue with a BSD kernel update breaking an extremely widely used application such as, say, Apache?
  - Malus 17y ago
    There would be issues, but the BSDs tend to break the ABIs on the development branches only, not the stable branches (e.g. CURRENT vs STABLE in FreeBSD). This usually gives port maintainers enough time to patch their ports appropriately or to send their patches upstream. Users should never see any breakage unless they choose to use the development branches.
  - JeremyChase 17y ago
    Your point is precisely the example I mean. In *BSD the kernel, core, and packages/ports are all tied to one ABI at any time. Linux/GNU's system is more free from, and as a result can result in these problems.
- rbanffy 17y ago
  Evolving the API is a fact of life. It your critical program breaks with the most current bleeding-edge version, then either fix it (or have your vendor do it for you) or don't run the latest release. It's not like someone will die for having an earlier release. That's also why Linux distros don't use the latest kernels: to allow the userland programs they package into them to run until they get fixed and the latest kernel can be added. While I know my Ubuntu doesn't run yesterday's kernel, I am happy it runs perfectly well with last month's kernel.
RyanMcGreal 17y ago
Is this a bad time for me to adopt my most gravitasy James Earl Jones voice and intone, "The perfect is the enemy of the good"?
- RyanMcGreal 17y ago
  Boy, did I ever misfire in my attempt at humour!
  - smithjchris 17y ago
    I +1'ed you to make you feel better :)
smithjchris 17y ago
This is the typical example where Linux suffers from lack of true engineering. The kernel API and libs should be stable, predictable and well documented. There should be no hacks to support odd behaviour because odd behaviour should not be specified. Isn't that why we have POSIX? What with recent issues with egotistical libc maintainers, people throwing their pacifiers over having to support junk, people moaning about ext4 (even though it works fine and is poor app behaviour), it doesn't give people much confidence. Confidence is key.
- varjag 17y ago
  If Linux had its API frozen in 1991 there would be very little use for it now. Sometimes you have to change things to move on.
  - smithjchris 17y ago
    Read this from end to end: http://msdn.microsoft.com/en-us/library/ms632680%28VS.85%29.aspx http://msdn.microsoft.com/en-us/library/ms632680%28VS.85%29.... Unchanged since 27 July 1993. Used trillions of times a day by millions/billions of computers.
    - varjag 17y ago
      Except that you are wrong, since the call includes special cases for Windows 98, ME, 2000 and XP.
- tezza 17y ago
  It sounds like your default state is "Full Confidence", and so Confidence is 'eaten away' in your description The better definition concerning Linux is that Confidence is "Built Up". Linux started as an unknown and has forced itself into people's confidence. Linux operates well 24x7x365 in many places, and that rate of Confidence build up is way more than any rate of loss due to Steering Committee squabbles.
- davidw 17y ago
  > The kernel API and libs should be stable, predictable and well documented. There should be no hacks to support odd behaviour because odd behaviour should not be specified. There should be a pony too. How can the kernel not have lots of hacks? It deals with hardware, which is often weird.

deleted 17y ago

[deleted]

From TFA - "After reading the thread on a mirror, it's important to note that after the argument, Alan and Linus continued to debate the technical merits of how to patch the bugs. The ongoing conversation was civilized and concise. Of course Linus is too much of a pompous ass to apologize to Alan for completely misunderstanding the problem and proposing dangerous and useless ways of fixing it, then arguing about it ad nauseum. Oddly, this doesn't seem to bother Alan or maybe he's just used to it."

DarkShikari 17y ago
This is one thing I have found true of great open source developers in general: regardless of their attitude, regardless of past events, regardless of the situation, they can carry on technical debates on how to deal with an issue. In other words, for such people, the technical merits of an idea supersede all other aspects.
- pbhjpbhj 17y ago
  I read the thread (didn't understand most of it) but Torvalds describes Cox work as "crap" and tells him "you're full of crap". Way to stick to the technical merits there ... That's some attitude.
  - DarkShikari 17y ago
    Did I ever say I was referring to Linus? ;)
    - pbhjpbhj 17y ago
      No, I didn't assume you did. My comment was partially tangential (now there's a geeky oxymoron).

spoondan 17y ago

What I find impressive is that Alan continues to assist on the issue after he has "had enough", providing in-detail responses to questions and correcting part of Linus's patch. I think he also responded to Linus's initial complaint with grace and aplomb. I'd like to think I am poised and dedicated, but I doubt I am even half so as Alan.

rythie 17y ago
He has been doing it since 1991, and spent 10 years working at RedHat.

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.

radioactive21 17y ago

nerd fights make great drama. let me know when episode two starts. I wanted to edit that it would be freaking hilarious if Alan went and worked with Microsoft.

akkartik 17y ago

Alan: http://linux.slashdot.org/comments.pl?sid=1319387&cid=28875027 http://linux.slashdot.org/comments.pl?sid=1319387&cid=28... Linus: http://linux.slashdot.org/comments.pl?sid=1319387&cid=28873731 http://linux.slashdot.org/comments.pl?sid=1319387&cid=28... Coda: http://linux.slashdot.org/comments.pl?sid=1319387&cid=28873411 http://linux.slashdot.org/comments.pl?sid=1319387&cid=28...

sachinag 17y ago
Wait, none of these comments are actually made by the people you say they are.
- akkartik 17y ago
  Yeaaaah.. they were summaries of positions. Thanks for insinuating that I was being misleading. Did you really think 'Coda' was a person? I've been watching parent get upmodded and my comment get downmodded with increasing disbelief. Time was that +16 used to mean it was not to be missed, and -4 was a troll or ad hominem.
  - benreesman 17y ago
    The voting is completely out of whack these days. I'm not sure if the constituency of the community has changed, or if people are just feeling ornery.

JeremyChase 17y ago

Being a fan of the BSDs I have to point out that this type of decision would not happen there. The reason being that the kernel and userland are not separate entities; they are a system. If you update your kernel the userland has to update with it, and that is to accommodate changes just like this.

Saavedro 17y ago
I would point out that the userland in BSDs that would update with the kernel would be the CORE utilities and programs. Say, like GNU utils on a linux distro. kdesu is part of KDE, which is an application installed on top of the OS, not something maintained as part of the OS. Would you say there wouldn't be any issue with a BSD kernel update breaking an extremely widely used application such as, say, Apache?
- Malus 17y ago
  There would be issues, but the BSDs tend to break the ABIs on the development branches only, not the stable branches (e.g. CURRENT vs STABLE in FreeBSD). This usually gives port maintainers enough time to patch their ports appropriately or to send their patches upstream. Users should never see any breakage unless they choose to use the development branches.
- JeremyChase 17y ago
  Your point is precisely the example I mean. In *BSD the kernel, core, and packages/ports are all tied to one ABI at any time. Linux/GNU's system is more free from, and as a result can result in these problems.
rbanffy 17y ago
Evolving the API is a fact of life. It your critical program breaks with the most current bleeding-edge version, then either fix it (or have your vendor do it for you) or don't run the latest release. It's not like someone will die for having an earlier release. That's also why Linux distros don't use the latest kernels: to allow the userland programs they package into them to run until they get fixed and the latest kernel can be added. While I know my Ubuntu doesn't run yesterday's kernel, I am happy it runs perfectly well with last month's kernel.

RyanMcGreal 17y ago

Is this a bad time for me to adopt my most gravitasy James Earl Jones voice and intone, "The perfect is the enemy of the good"?

RyanMcGreal 17y ago
Boy, did I ever misfire in my attempt at humour!
- smithjchris 17y ago
  I +1'ed you to make you feel better :)

smithjchris 17y ago

This is the typical example where Linux suffers from lack of true engineering. The kernel API and libs should be stable, predictable and well documented. There should be no hacks to support odd behaviour because odd behaviour should not be specified. Isn't that why we have POSIX? What with recent issues with egotistical libc maintainers, people throwing their pacifiers over having to support junk, people moaning about ext4 (even though it works fine and is poor app behaviour), it doesn't give people much confidence. Confidence is key.

varjag 17y ago
If Linux had its API frozen in 1991 there would be very little use for it now. Sometimes you have to change things to move on.
- smithjchris 17y ago
  Read this from end to end: http://msdn.microsoft.com/en-us/library/ms632680%28VS.85%29.aspx http://msdn.microsoft.com/en-us/library/ms632680%28VS.85%29.... Unchanged since 27 July 1993. Used trillions of times a day by millions/billions of computers.
  - varjag 17y ago
    Except that you are wrong, since the call includes special cases for Windows 98, ME, 2000 and XP.
tezza 17y ago
It sounds like your default state is "Full Confidence", and so Confidence is 'eaten away' in your description The better definition concerning Linux is that Confidence is "Built Up". Linux started as an unknown and has forced itself into people's confidence. Linux operates well 24x7x365 in many places, and that rate of Confidence build up is way more than any rate of loss due to Steering Committee squabbles.
davidw 17y ago
> The kernel API and libs should be stable, predictable and well documented. There should be no hacks to support odd behaviour because odd behaviour should not be specified. There should be a pony too. How can the kernel not have lots of hacks? It deals with hardware, which is often weird.