Alan Cox Quits As Linux TTY Maintainer — "I've Had Enough" 909
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.
Slashdotted - Google Cache. (Score:5, Informative)
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
*It happens (Score:5, Informative)
Time for all to give Alan a sound round of applause and thanks! The TTY subsystem is a gem thanks to his work.
Re:Slashdotted - Google Cache the real links (Score:4, Informative)
"stern criticism" -> link 1 [74.125.155.132]
"decided to walk away" -> link 2 [74.125.155.132]
"quite clear that he is serious" -> link 3 [74.125.155.132]
Re:No gratitude? (Score:5, Informative)
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?
If you really want to know, google up the "Greater Internet Fuckwad Theory" and the Penny Arcade comic that comes up will explain it for you, though you can probably guess the gist from the name. Sad but true.
FTA: (Score:2, Informative)
Re:On slashdotting... (Score:5, Informative)
Try Google Groups [google.com].
That's the entire thread, supposedly.
Alternative Link (Score:2, Informative)
http://marc.info/?l=linux-kernel&m=124870096801094&w=2 [marc.info]
Re:Linus (Score:4, Informative)
Con wrote some fantastic code that benchmarks over years constantly showed to be a huge improvement. Linus refused to incorporate good code.
Con maintained his patches separately, Even better, he took criticism on his work and sought to improve it. Time after time he made changes to his work to try and make it more acceptable to Linus. Linus rebuked Con and said not nice things. Con kept working.
This continued for years. Eventually Linus realized that Con was right on scheduler philosophy. But Linus couldn't admit that he had been an overbearing ass for the past three years on a technical issue where he was clearly wrong. He asked someone else to write a new scheduler from scratch rather than use one that has been tested for three years. When the new scheduler was hastily written, and Con's was faster, Linus said he only cared about superior code and making the right decision for the kernel. But he made sure to make several personal attacks on Con for good measure.
Logically, Linus inserted untested code that was still being developed in as the new scheduler. It didn't matter if it was technically inferior and unstable. His justification was that he felt the new code would be supported, where as Con would never support his code. This assertion flies in the face of Con supporting and improving his patches for years. I've contacted Con on his mailing list. He was always cordial, and willing to support people who wanted to use his patches. Nobody made Con support those patches. But he had the mailing list none the less.
There is no logical justification for taking inferior, untested, unstable code over superior, stable, tested code. Even worse, there was no reason for Linus to repeatedly attack Con personally and lie about him.
It is one thing to suggest Hans Reiser would abandon reiser4 the way he did reiser3. It is another to make baseless accusations at good developers.
Re:On slashdotting... (Score:3, Informative)
39 and 40 are the first two messages from the summary.
The third message linked in the summary seems to be from a different thread.
Re:Linus (Score:2, Informative)
About 2% (enormous amount)
Re:Linus (Score:5, Informative)
That's called the Dunning-Kruger effect [wikipedia.org]
Re:Linus (Score:4, Informative)
Mirror (Score:1, Informative)
You can get the whole convo at the lkml mirror:
http://marc.info/?t=124870111900001&r=1&w=2
Re:Not very responsible either (Score:5, Informative)
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.
Re:Linus (Score:4, Informative)
You just need to change in your article the name "linus" by "ingo" and then your post may have some sense. Which shows how much you "know" about the topic.
Linus didn't even bothered with the scheduler, Ingo was the maintainer and it was him who was in charge of deciding what should replace it. It was him who argued, not linus. It was him who ended up admitting that the ideas from Con were good and he wrote the scheduler which is now into the kernel. One that, according to Con, was better than his own scheduler.
Re:Linus (Score:3, Informative)
I read the LKML for years.
So do I, and I won't ask you to search proofs of what you say because it's just lies. Try to find just one single phrase where Linus tells Ingo to wrote a new scheduler. You won't find it because it was Ingo who decided to write it, as he explained in the initial announcement.
Re:Linus (Score:5, Informative)
Like him or not, Linus is still the man in linux kernel development circles, and for good reason.
Re:Linus (Score:5, Informative)
The whole thing is publicly available. See This Google Groups thread [google.com]
The big problem is that there where multiple issues, at least one of which was a userspace bug. Cox originally questioned the Emacs code on one half of the bug, although he seems to have since taken that back. At first Cox seemed insistent on solving the issue one way which appeared to work but was not technically sound. But now he and Linus appear to agree on the basic solution, although a few issues sound like they still need to be hashed out.
Overall a classic miscommunication flare-up.
Re:Thanks (Score:4, Informative)
I tried to drag and drop a jpg in a browser window (Firefox) to some photo editor. It didn't work. Macs and Windows have been able to do this since at least the mid-90s. I have no idea if you can drag an image from Firefox to the Gimp nowadays, and I don't care.
Just tried it, GIMP connected to the server and pulled the image from there. Not sure if that's how you want it to work though.
Re:Linus (Score:3, Informative)
The kernel still contains about two percent Linus-code, which is a staggering amount for one person on a project so large.
I'm pretty sure they're already separate... (Score:3, Informative)
Surely the TTY code isn't part of the serial driver subsystem? What the tty subsystem handles is line discipline, and that can be applied to any number of serial interfaces, both physical (serial ports) and virtual (sockets). If you talk to the serial port RAW there shouldn't be a line discipline involved.
(the issue of whether they're in the "kernel" or not is a separate issue, QNX being a microkernel being "in the kernel" there is kind of meaningless)
Re:He's still posting.... (Score:3, Informative)
Re:Linus (Score:5, Informative)
BSD has terrible driver support compared to Linux.
My experience has been exactly the opposite. It wasn't until Ubuntu 8.10 came around (having also tried Red Hat and Gentoo) that I found Linux's driver support to be acceptible. By contrast, my OpenBSD installs always worked for me out of the box. The only driver issue that's ever irked me there were USB-serial adapters. But the ease of configuration in OpenBSD has always been great, especially for wireless.
Anyhow, it probably depends on what you're doing, and with what hardware. Just thought I'd throw that out there, though.
Re:Could anyone shed some light... (Score:5, Informative)
The details are that TTYs in general on any *nix are a huge mess with lots of complicated interactions and weird historical behavior that doesn't make sense. The linux tty stack for a long time was a huge clusterfuck. Now thanks to Alan it's just a normal clusterfuck. That's the context for this incident, which basically happened like this...
Some dudes: there's a bug in the ttys
Alan: ok lets fix it
Some dudes: here's a patch
Alan: that patch breaks a dozen other things
Some dudes, Alan reject a bunch of solutions
Alan: we can fix it with a hack, but it breaks emacs. Emacs is relying on unspecified behavior, so it can go suck an egg.
Linus: well it SHOULD (sic) work like this, and emacs is too holy to break. This problem is easy, are you a retard?
Alan: look we can hack it and break emacs, or do a huge rewrite
Linus: hacks suck, linux should be awesome in every way. Also, your code smells
Alan: it's going to take forever to get this right
Linus: then revert the patch that introduced the bug
Alan: that patch was applied years ago and removing it would break a dozen other things. You didn't think I'd think of that? Who's the tty maintainer anyway, jackass?!
Linus: I don't like your attitude
Alan: Then fuck off I quit!
Linus: Oh yeah did I mention your code smells?
Linus: and let me quote you something you said earlier, so I can show what a bad attitude you have.
The TTY and serial line code is basically a huge Rube Goldberg machine and Linus was telling Alan to tweak something somewhere in the middle of this huge contraption. Having followed the TTY code a fair bit, I totally side with Alan on this. It's a miracle that it even works, and not something you can just stick your head in and give advice about how to fix. Also, if Linus is so concerned about proper behavior for user space programs maybe he should take a look at ioctl... because it's completely screwed up in linux.
Re:Thanks (Score:1, Informative)
That's not Linux, that's KDE or Gnome you are talking about.
Looks like I'm the dissident (Score:2, Informative)
I went to read the thread from around the message pointed by the article.
What I saw was a nervous breakdown from Mr. Cox because he had too much pressure on him and wasn't able to accept that his proposal was less optimal than that from others. See: http://lkml.org/lkml/2009/7/28/612 [lkml.org]
Mr. Cox finally comes to reason: http://lkml.org/lkml/2009/7/29/108 [lkml.org]
Considering the discussion going on from http://lkml.org/lkml/2009/7/29/276 [lkml.org] , maybe Mr. Cox will reconsider.
I don't know about other issues, but I wouldn't be too fast to point the finger at Mr. Torvalds in this case.
Re:Linus (Score:5, Informative)
He's obviously read "Psychology of Everyday Things" (later reprinted as "Design of ..."), where this door UI issue is discussed in several case studies. "POET" is a classic must-read for anyone that designs anything that anyone might be expected to use.
http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0465067107/ref=sr_1_1?ie=UTF8&qid=1248908564&sr=1-1 [amazon.com]
Re:Linus (Score:3, Informative)
I'll do that.
http://apcmag.com/interview_with_con_kolivas_part_1_computing_is_boring.htm [apcmag.com]
http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.htm [apcmag.com]
http://linux.slashdot.org/article.pl?sid=07/09/01/1853228&from=rss [slashdot.org]
vhttp://linux.slashdot.org/linux/07/09/14/156234.shtml
http://linux.slashdot.org/article.pl?sid=07/09/18/131240 [slashdot.org]
From my own post here http://linux.slashdot.org/comments.pl?sid=301061&cid=20655809 [slashdot.org]
Re:No you can not (Score:4, Informative)
by recoiledsnake (879048)
on Tuesday September 18 2007, @01:35PM (#20655809)
That is a gross over-simplication of what happened and almost qualifies as revisionist history and brushing things under the carpet. Let me summarize my understanding of what happened and someone please correct me if I am wrong.
Con Kolivas had been shouting from rooftops about slow desktop performance and was submitting feedback and bug reports. One of the kernel devs apparently said "I do not notice the issue on my quadcore machine with 4GB RAM". Rightly or wrongly, this lead Con to believe that the kernel devs do not care about desktop performance and only give priority to issues that big corporates complain about.
In the true open source style, he took upon himself to learn kernel programming and released a whole set of -CK patches and various versions of benchmarking tools and schedulers. On the other side, Ingo Molnar was the maintainer of the scheduler portion of the kernel and maintained that the O(1) scheduler(and the one before it?) is good enough and has no problems. Con conclusively started proving this wrong with his benchmarks. At this point, everyone assumed the -CK branch would be merged into the kernel at some point and Linus says he had been considering it.
At some point, Ingo starts making his own scheduler, which later evolved into the Completely Fair Scheduler. A number of posts claim that it was kind of rip off of the ideas behind Con's scheduler with which it was in a race to get included in the kernel. Then Linus decides to include CFS into the kernel instead of Con's scheduler. The reason he gave was that Con thought SD was perfect and that he ignored and flamed the users on the CK mailing list and that he(Linus) was far more comfortable working with Ingo since he knew him well. He also admitted that he might have formed this opinion on a single incident on the mailing list and he didn't have the time to follow the CK mailing list.
Some people on Con's side in the LKML tried to explain this by saying that the single incident was in response to a troll who submitted faulty bug reports and ignored the reasons for why they were rejected and that Linus was playing favorites. Con couldn't take the non-inclusion of -CK and plugsched(which would have given users a clean way of using a custom scheduler) and quit kernel development totally.
The latest twist in the story was reported on Slashdot here [slashdot.org]. The gist of it was that another hacker(Roman Zippel) was trying work on CFS. He had asked questions about what some parts of the code did, and also made some patches that considerably simplified the code and mathematically proved his patches made things better. In response, Ingo came out with a big patch that ripped out the code that was questioned and included Roman's Zippel's ideas(another rip off?) with hardly any discussion and a tangential acknowledgement of including his changes. Roman complained that talking in patches without explanation is detrimental to collaborative OSS development. /quote
Re:Linus (Score:3, Informative)
The only problem with this accounting is that it makes it seem like there wasn't much time between the -ck patches and the CFS. There was a three year period in there, in which Ingo reviewed the -ck patches repeatedly.
Ingo did publicly admit that he took the concept from the Staircase scheduler in writing his own CFS.
Re:Linus (Score:3, Informative)
Does FreeBSD even have any 3D video drivers for Nvidia or AMD? If not, then it's not worth even thinking about using it on the desktop for most people.
I think you'll find that most people actually don't really care about 3D. So long as the graphics drivers can run their desktop then most people are happy (Compiz Fusion runs just fine on Intel GPUs).
A minority of people are gamers and therefore do care about 3D. These people will be running Windows since thats where most PC games are.
An even tinier minority actually work in the field of 3D graphics.
Re:Linus (Score:2, Informative)
Re:Linus (Score:3, Informative)
Also, doors should be always pulled when you go in and pushed when you go out. That makes exiting the building easier in case of emergency (people don't rush to the door and jam it, preventing anyone from pulling it open.) and also when people are trying to get in and out at the same time, the person outside is more capable of keeping the door open for the person going out (it is better that people first get out, before new people get in, because inside there is a limited space, while outside contains usually a lot more room). Also outside usually contains more room for pulling, while the inside often has a wall that limits the space for pulling, especially if you want to keep the door open for someone else.
Your door would suffer from issues if installed in an environment where it snows a lot.
Re:Thanks (Score:3, Informative)
Re:Linus (Score:2, Informative)
BSD has terrible driver support compared to Linux.
Wrong. BSD has excellent driver support, but doesn't allow in binary-only black-box drivers nobody can maintain. Instead the developers reverse-engineer the hardware and make drivers anyone can maintain.
I checked this with Netcraft, and they confirmed it.
Re:Thanks (Score:3, Informative)
this particular exercise can be a bit subtle, at least in windows. (i know this is a linux discussion, but it may apply)
if the image is a Link, then what gets "dropped" onto the target application is the URL of the link, which many apps handle just fine. if it's not a link (ie it's an image tag not wrapped in an anchor tag) then what gets dropped is the binary data of the image itself, which fewer apps handle because it's a pita.
Re:So long and thanks for all the code. (Score:5, Informative)
There are two Alan Coxes, one for Linux and one for FreeBSD. It's confusing but there you go.
Re:Thanks (Score:4, Informative)
Hauppauge still hasn't moved from their stance of being completely unwilling to write functional x64 drivers for the WinTV series of cards. They still insist the cards won't work with x64 systems with more than 4GB of memory. [hauppage.com] Until my Hauppauge card works without me having to gut myself of more than 80% of its memory, they can go die in a fire.
Re:Linus (Score:5, Informative)
Personally, that tells me something!
Re:Drag'n'drop (Score:3, Informative)
But isn't that precisely what object orientation was invented to solve? To find a way of unifying data transfer between absolutely everything, everywhere, by sending not raw data but objects which could then be queried to ask things like 'what kind of thing are you?' and 'give me your data in Format X, Y or Z which I can read'.
Object orientation does solve this, but only for systems that can share objects with each other. The problem is that, typically at least, objects are represented as a data structure in memory that has, among other things, pointers to code to execute in response to different messages. To execute a method, we find the correct pointer, call that code and pass it a pointer to the object whose method it is. This is by far the most efficient way of implementing objects, so it is almost universally used.
The downside to this implementation is that objects depend on a specific memory map, i.e. they are process specific. You can't just rip an object out of one process and send it to another, you have to serialize it and deserialize it along the way, and the receiving process has to know about that object's class because it has to have access to its methods' code as well the object's data. There are three general solutions to moving objects from one application to another:
I'm not sur
Re:Especially if he wanted to work on the tty code (Score:4, Informative)
Terry Lambert is an actual Apple employee who, if I'm not mistaken, could quite honestly hire people like Alan to work on the "unix" portions of OS X. He's quite active on Apple's Darwin Kernel mailing list.
Re:Thanks (Score:2, Informative)
Re:Thanks (Score:3, Informative)
Is it really too much to ask for someone like Linus to respond with something like "I agree" rather than insulting the guy for making what appeared to the almighty godly genius as "obvious"?
Actually, the bit you reference isn't Linus being a dick to the person he's quoting. He's merely stating that the assumption *in the emacs code* is obvious, in that he believes that the assumption they make (that when a child writes data, then quits, the master should get the data buffered by the time the master hears about the child quitting) is reasonable (or, as he says, "obvious"). That wasn't a flippant dismissal of the person he was replying to.