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.
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
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. "
"stern criticism" -> link 1
"decided to walk away" -> link 2
"quite clear that he is serious" -> link 3
http://stephan.sugarmotor.org
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.
The enemies of Democracy are
Try Google Groups.
That's the entire thread, supposedly.
Lurking at the bottom of the gravity well, getting old
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.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
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.
Nerd rage is the funniest rage.
That's called the Dunning-Kruger effect
Big ego != nasty
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
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.
By his own measure, he says about 2% of the code in today's kernel is written by him, but about 80% of it goes through him before being included. It's unrealistic to expect any one person to have a significant percentage of Linux code literally belong to them, so it would be disingenuous to use that 2% figure as some sort of argument to undermine Linus' authority with regards to the kernel.
Like him or not, Linus is still the man in linux kernel development circles, and for good reason.
The whole thing is publicly available. See This Google Groups thread
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.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
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.
Ignore my post (can I mod myself down ??) .... He has left tty maintainer, but is still posting on the kernel mailing list. I hope he re-considers talent like his is rare .
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.
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.
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
Before you design for reuse, make sure to design it for use.
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.
There are two Alan Coxes, one for Linux and one for FreeBSD. It's confusing but there you go.
Sam ty sig.
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. 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.
"There is much pleasure to be gained from useless knowledge." - Bertrand Russell.
In case you haven't noticed IQ is the acronym for Intelligence Quotient and the mean score 100 is the mean of the Normal Distribution for a large enough population.
Personally, that tells me something!
Parent post should be modded insightful or something, not funny.
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.