Slashdot Mirror
Alan Cox Quits As Linux TTY Maintainer — "I've Had Enough"
The Slashdolt writes "After a stern criticism from Linus, the long-time kernel hacker Alan Cox has decided to walk away as the maintainer of the TTY subsystem of the Linux Kernel, stating '...I've had enough. If you think that problem is easy to fix you fix it. Have fun. I've zapped the tty merge queue so anyone with patches for the tty layer
can send them to the new maintainer.'" A response to a subsequent post on the list makes it quite clear that he is serious.
Thanks for all the hard work. Good luck to the next maintainer. Not much else to say.
Give me Classic Slashdot or give me death!
Linus is brilliant. He is funny. Most days I really agree with anything he has to say.
However, he has butted heads with people in the past. Perhaps this is just human nature and unavoidable from time to time. Linus isn't perfect, nor always right. I thought he was really unfair to Con Kolivas when he drove Con away.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
I see the tags 'butthurt' and 'whaaaaaaaaa', but no 'thanksforyourtime'. Why won't anyone show any gratitude for the years of work he's generously offered to the project?
Remember Windows ME?
Bingo.
(Just kidding I have no idea WHAT went wrong there)
WHY can't lkml.org's mailing list retriever handle a slashdotting?
Its not like the flashcrowds are all THAT big.
Test your net with Netalyzr
Indeed, ive jumped into quite a few projects replacing a previous programmer. Some were experienced and reading their code was really interesting, others were fired for being incompetent and I ended up rewriting most of their code.
In any cases, the first few days, weeks or months depending on the size of the code are spent studying the structure rather than actually coding.
Do you D?
In before the Karma-Whores.
"stern criticism" -> http://74.125.155.132/search?q=cache:http://lkml.org/lkml/2009/7/28/373&hl=en&strip=1
"decided to walk away" -> http://74.125.155.132/search?q=cache:http://lkml.org/lkml/2009/7/28/375&hl=en&strip=1
"quite clear that he is serious" -> http://74.125.155.132/search?q=cache:http://lkml.org/lkml/2009/7/28/378&hl=en&strip=1
How long does a bear have to be? Is it proportional to long cat?
http://xkcd.com/323/
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Time for all to give Alan a sound round of applause and thanks! The TTY subsystem is a gem thanks to his work.
"To those who are overly cautious, everything is impossible. "
Everything.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Are we talking tail-to-nose or is that a phalic reference? OTOH, how you would know your bear's penis length is something that should probably go unsaid.
ive jumped into quite a few projects replacing a previous programmer. Some were experienced and reading their code was really interesting, others were fired for being incompetent and I ended up rewriting most of their code.
In any cases, the first few days, weeks or months depending on the size of the code are spent studying the structure rather than actually coding.
The differences here are that A) this is an open-source project, B) this is a *HIGH PROFILE* open source project, and C) Alan was the maintainer, not sole coder (so he both coded, and accepted patches from others.)
It's possible that Alan was the only one who knew anything about the TTY code and how it worked, but I'd doubt it. I'd be really surprised if the new maintainer comes into the role cold.
Alan Cox announces he will maintain Slashcode: "After this, it will be bloody easy to maintain the Slashcode codebase."
The overwhelming majority of people I have encountered are jerks. That's nothing open source developers, or any kind of developer, has a monopoly on.
Give me Classic Slashdot or give me death!
Yes, indeed it could have been. But unfortunately that's Linus' modus operandi and we all know from long experience that while a great programmer, his ego is far too big to allow him to apologize publicly in the same fashion in which he slammed Alan. Quite unfortunate really since both are quite talented individuals.
You can't expect to publicly berate people and have them bow to your every demand and not have it backfire on you at some point.
...about the details of this argument? I know Linus might not be the easiest person to work with, but he seems to make some sense here.
Alan thank you for your contribution to the open source community!
"You claim that emacs sh*ts itself when it gets EAGAIN, and you think
that's an emacs bug. And I think you're full of crap..."
I'm sure there's a job waiting in the diplomatic corps for Mr Torvalds...
----------------------------------- My Other Sig Is Hilarious -----------------------------------
The true point of contention? Emacs vs. Vi. Loons.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Linus: Hey Alan finger my tty
Alan: No Way! i quit!
Politics is Treachery, Religion is Brainwashing
"Please talk to the new tty maintainer whoever that ends up. I no longer
care."
You know what really gets on my nerves? When people say they no longer care, when in reality they do. If he really didn't care, he would have typed the first sentence and stopped.
Linux is a great product, and that is the result of the magnificent work of all the coders and contributers. But sometimes they just act like children.
As always.
The argument started when someone found the tty layer had a regression. Linus cares about regression deeply. His basic philosophy is old bug is better than new bug. If a fix introduces a new bug that breaks a real world application, then the fix should be reverted and a better fix should be worked out.
This ensures predictable behavior of an OS that you can actually rely on, and better release management.
Alan didn't think so. He thought his fix was too important to be backed out, although it introduced a regression. Linus was frustrated that he had to explain to Alan, a long time Linux hacker, about the rules. And that's where Alan got impatient too.
First of all I am very greatful for everything he did. I know he contributed a lot. Hope the handover will be more than this emotional message: "Please talk to the new tty maintainer whoever that ends up. I no longer care."
You'll be pleased to hear that not only is Alan helping with the handover, he's been providing some constructive criticism about the way the bug is being fixed now Linus and a few other people have turned their full attention to it.
Pirate Party UK
To be fair, "I no longer care" is shorthand for the closely related "I no longer care enough to put up with the criticism" which is just a statement of cost/benefit analysis. He does care, but not enough to keep going, and that roughly approximates "I don't care".
Nostalgia's not what it used to be.
Drag and drop is quite convenient. It is also a security chasm. Once you can drag and drop one thing then you want to be able to drag and drop anything. In the case of arbitrary file formats not only must you implement code to check the incoming data stream (thus exposing yourself to all of the security considerations of "how many different ways can someone try to wax my process of checking the incoming data stream?") but you must consider that a data stream which is valid using one codec algorithm may cause a fault using another codec algorithm. Competing algorithms exist for many data format structures and the presumed same data format may have three or four codecs at use between X, the WM, a monolithic app like a web browser, and a devoted data editor (eg. GIMP), and even a devoted data viewer (eg. a multiformat display application). It isn't the simplest consideration.
With so much of the problem and criticism with the reigning proprietary OS being security related the open source community has tried to remain a little more focused on security related issues. Combine that with the difference in conceptual organization--F/OSS guys don't get paid to go to in house meetings together--and it is completely logical that something as "simple" as drag and drop is not implemented across largely unrelated application development groups.
Within a particular desktop environment using apps which were written specifically for that desktop environment (often referred to as a desktop suite) there is probably a more consistent end user experience.
It is the culmination of (years of) similar situations which has brought many rifts in major F/OSS development groups.
I find myself personally familiar with the situation which caused Alan to leave. The difference is that Alan has enough financial backing and social connections behind him that he likely will not end up living on the streets.
Can you imagine a headline,"Major developer sick and tired of political crap, leaves development group, will take up a section of cardboard on the sidewalk just down the block from Slashdot's HomelessinLaJolla"?
the NPG electrode was replaced with carbon blac
If Alan Cox wanted to work at Apple, it would take 1 phone call. Devs like him don't have problems getting hired. I don't know if he's been working on FreeBSD or not, but if so that isn't the reason.
I still have more fans than freaks. WTF is wrong with you people?
Oh boy, I can't agree more with this statement. I realize this is anecdotal, but here's my own personal experience...
In the Gentoo Freenode channel, it was difficult to so much as type without bumping into someone's ego. Participants were generally rude, crude, and--perhaps most ironically--threatened to kick people for using swear words. I have no idea if this has changed at all in the 4 or 5 years since I last joined... but it wasn't a pleasant experience.
Contrasted with the various FreeBSD channels I used to join infrequently, the experience was on the whole much better. People were friendlier, had a sense of humor, were helpful, and didn't get their underpants in a dozen knots over something incidental like a single, mostly unoffensive swear word. Again, it's been years since I participated in that as well and perhaps the FreeBSD channels have changed...
Personally, I doubt it. It's a cultural difference, I think. The BSD crowds seem more product-driven (let's get Y done) versus some Linux distros that seem process-driven (I don't like how you're doing X and it doesn't matter if we're making Y).
This, of course, is purely anecdotal. You don't have to agree with it because it was my personal experience, and as such, FreeBSD folks have come off to me as MUCH more friendly and cooperative.
He who has no
Solaris :)
you had me at #!
Actually, and bizarrely enough, there is a high level FreeBSD developer named Alan Cox too
http://en.wikipedia.org/wiki/Alan_Cox
I'm ready to scream bloody murder over it not being included yet.
"If Alan Cox wanted to work at Apple, it would take 1 phone call."
Especially if he wanted to work on the tty code.
-- Terry
Assuming what Linus said is true, about Alan blaming user land code for problems he was responsible for, then Alan was clearly in the wrong. However, Linus is wrong to have taken him to task in such a public forum. If he had any sense, he'd have done it privately, and Alan Cox would probably still be the maintainer. There's more to managing people than simply "being right".
I sometimes wonder if it's the very public nature of Linux (and much open source) development that gives that creates this impression of everyone acting like children. I've heard plenty of people describing working environments (no matter the expertise) that sound exactly the same as this, it's just that no one outside the company will ever see it. It's kind of a software development soap opera...
far more often than technical challenges. This incident provides an enlightening view into Linux development. Working for someone with the social skills of a 13 year old girl, who doesn't actually pay you, never ends well.
Back in 1938, a massive alien invasion took place in Grover's Mills, New Jersey -- during Orson Welles' famous "War of the Worlds" broadcast about Martians. Maybe it wasn't a hoax? Applications were discovered for social security cards from a list of men with no backgrounds -- all named Cox:
Alan Cox
John Big Cox
Dewey Cox
Dixon Cox
Ima Cox
.
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
When I was in college, I was in a volunteer group. I took a project leadership position, and I was warned that the people volunteering for us were unreliable and unpleasant to work with. Later I was pleasantly surprised to find that not to be the case. Of course people did mess up from time to time and sometimes people found themselves over-committed, but on balance I found the volunteers cheerful, eager and reliable as I could reasonably expect under the circumstances.
I found other project leaders would talk about *the same people* I worked with successfully as if they were totally unreliable. What was mystifying is that I am so *not* a nice guy. I'm not a *bad* guy, either, but I'm kind of gruff and impatient, and I don't mince words either.
So I watched how *they* managed volunteers, and compared to how *I* managed volunteers.
I'd say, "Can you do such and so on Saturday? You'll need to show up at noon and stay until four. You can? Good. Do you want to scare up some helpers or would you like to take care of that? Great, thanks. Give me a call if anything changes."
They'd say, "Look, we really, really need somebody to do such and so. I know you're *so* busy, and I really hate to ask you to do this, but nobody else can and we're desperate. Can you, PLEASE? Really? Are you *sure*? It'll be a disaster if nobody shows up so I really need to know for sure. Really? OK I know this is a HUGE sacrifice for you."
The conclusion I came to was that the other guys were trying way too hard to be nice, and so they were failing on an epic scale. It didn't even *occur* to me to try to be nice, and so I didn't commit any of their horrible mistakes.
I think the problem with the phony "nice" approach was it demonstrated lack of respect in so many ways. First of all their attitude practically radiated their lack of confidence in the volunteer. They assumed the volunteer didn't want to volunteer, and would volunteer just to shut them up (probably true) and then not show up (also often true). They assumed the volunteer would be swayed by flattery (you're so busy), guilt (it'll be a disaster if you don't show up), twisted pride (this is a job so horrible nobody but you would consent to do).
It's hard not to step on that disrespect third rail now and then, but these guys were jumping up and down on it from the get-go. It's ALWAYS a mistake. If you want a guy to leave, you should just say, "Sorry, this isn't working out. Let's move on." Getting snarky on them just means they'll stay and work like malcontents.
Linus's post is perfectly understandable. I don't think it shows towering ego and arrogance. We all get exasperated now and then. He's trying to be nice about it, but he just can't help himself. He's only human. It doesn't *matter* whether he's right or wrong, he let his exasperation show. When you're on the receiving end of that it comes across as disrespectful. Sometimes *trying* to express your exasperation *nicely* is even worse. It's patronizing.
One thing I learned is that people will do good work for no money before they'll do good work for no respect. And the best people won't work at all without respect.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I was just going to reply and say the same thing as the GP - there is another Alan Cox for FreeBSD.
I have a theory that all OSes have their own Alan Cox but maybe they sometimes use pseudonyms to keep that secret!
There are two Alan Coxes, one for Linux and one for FreeBSD. It's confusing but there you go.
Sam ty sig.
> why isn't Reiser 4 in the damn kernel already?
Vendor lock-in.
>Cox -> submits code which apparently caused a bug
>User -> Reports breakage
>Cox -> Can't replicate breakage and asks user for debug info so he can fix it.
>User -> Says they don't know what to debug for, but is willing to work with Cox.
Here they have found the bottom issue: emacs was expecting some reasonable behavior from the kernel: data delivery before notification of producer's termination. The behavior was broken.
>Linus -> Jumps in and calls Cox's code a buggy piece of shit before any debugging took place, and before it is established if the code is buggy or not.
Hello? The code broke a reasonable expectations of its users. Not buggy? That's technically is a DEFINITION of a bug.
>Cox -> Continues to troubleshoot the issue.
>Linus -> Flames Cox personally and says Cox is unwilling to work on the issue.
Cox was proposing some strange solutions.
>Cox -> Takes his ball and goes home, except in this case, it is OSS so he doesn't really take any ball with him. He just leaves.
Then they had a technical discussion, and it appeared that Linus was right.
I think I need to start writing my own OS...