Forgot your password?
typodupeerror
Programming Linux

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

Posted by timothy
from the when-smart-people-clash dept.
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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Anonymous Coward on Wednesday July 29, 2009 @04:04PM (#28872357)

    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)

    by stox (131684) on Wednesday July 29, 2009 @04:07PM (#28872399) Homepage

    Time for all to give Alan a sound round of applause and thanks! The TTY subsystem is a gem thanks to his work.

  • by sugarmotor (621907) on Wednesday July 29, 2009 @04:08PM (#28872429) Homepage

    "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)

    by Chris Burke (6130) on Wednesday July 29, 2009 @04:09PM (#28872455) Homepage

    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)

    by Wally4u (603232) on Wednesday July 29, 2009 @04:11PM (#28872485)
    > Quite frankly, I don't understand why I should even have to bring these > issues up. You should have tried to fix the problem immediately, without > arguing against fixing the kernel. Without blaming user space. Without > making idiotic excuses for bad kernel behavior. > > The fact is, breaking regular user applications is simply not acceptable. > Trying to blame kernel breakage on the app being "buggy" is not ok. And > arguing for almost a week against fixing it - that's just crazy. I've been working on fixing it. I have spent a huge amount of time working on the tty stuff trying to gradually get it sane without breaking anything and fixing security holes along the way as they came up. I spent the past two evenings working on the tty regressions. However 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. --- MAINTAINERS~ 2009-07-23 15:36:41.000000000 +0100 +++ MAINTAINERS 2009-07-28 20:09:32.200685827 +0100 @@ -5815,10 +5815,7 @@ S: Maintained TTY LAYER -P: Alan Cox -M: alan@lxorguk.ukuu.org.uk -S: Maintained -T: stgit http://zeniv.linux.org.uk/~alan/ttydev/ [linux.org.uk] +S: Unmaintained F: drivers/char/tty_* F: drivers/serial/serial_core.c F: include/linux/serial_core.h
  • by TopSpin (753) * on Wednesday July 29, 2009 @04:13PM (#28872515) Journal

    Try Google Groups [google.com].

    That's the entire thread, supposedly.

  • Alternative Link (Score:2, Informative)

    by steltho (1121605) on Wednesday July 29, 2009 @04:18PM (#28872599)
    Here is a link to the start of thread that has not been slashdotted ... yet.
    http://marc.info/?l=linux-kernel&m=124870096801094&w=2 [marc.info]
  • Re:Linus (Score:4, Informative)

    by Enderandrew (866215) <enderandrew@gmaUMLAUTil.com minus punct> on Wednesday July 29, 2009 @04:22PM (#28872675) Homepage Journal

    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.

  • by maxume (22995) on Wednesday July 29, 2009 @04:32PM (#28872879)

    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)

    by Anonymous Coward on Wednesday July 29, 2009 @04:40PM (#28873041)

    About 2% (enormous amount)

  • Re:Linus (Score:5, Informative)

    by Bill Dimm (463823) on Wednesday July 29, 2009 @04:43PM (#28873131) Homepage

    That's called the Dunning-Kruger effect [wikipedia.org]

  • Re:Linus (Score:4, Informative)

    by Metasquares (555685) <slashdot AT metasquared DOT com> on Wednesday July 29, 2009 @04:52PM (#28873291) Homepage
    Big ego != nasty
  • Mirror (Score:1, Informative)

    by Anonymous Coward on Wednesday July 29, 2009 @05:19PM (#28873751)

    You can get the whole convo at the lkml mirror:
    http://marc.info/?t=124870111900001&r=1&w=2

  • by PeterBrett (780946) on Wednesday July 29, 2009 @05:23PM (#28873809) Homepage

    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)

    by diegocgteleline.es (653730) on Wednesday July 29, 2009 @05:28PM (#28873905)

    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)

    by diegocgteleline.es (653730) on Wednesday July 29, 2009 @05:46PM (#28874185)

    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)

    by Hikaru79 (832891) on Wednesday July 29, 2009 @05:55PM (#28874303) Homepage
    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.
  • Re:Linus (Score:5, Informative)

    by Tacvek (948259) on Wednesday July 29, 2009 @05:59PM (#28874363) Journal

    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)

    by krkhan (1071096) on Wednesday July 29, 2009 @05:59PM (#28874367) Homepage

    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)

    by FishWithAHammer (957772) on Wednesday July 29, 2009 @06:18PM (#28874625)

    The kernel still contains about two percent Linus-code, which is a staggering amount for one person on a project so large.

  • 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)

  • by yossarianuk (1402187) on Wednesday July 29, 2009 @06:42PM (#28874917)
    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 .
  • Re:Linus (Score:5, Informative)

    by raddan (519638) * on Wednesday July 29, 2009 @06:46PM (#28874951)

    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.

  • by cryptoluddite (658517) on Wednesday July 29, 2009 @06:52PM (#28875027)

    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)

    by Anonymous Coward on Wednesday July 29, 2009 @06:53PM (#28875035)

    That's not Linux, that's KDE or Gnome you are talking about.

  • by hrimhari (1241292) on Wednesday July 29, 2009 @06:55PM (#28875055) Journal

    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)

    by MoeDrippins (769977) on Wednesday July 29, 2009 @07:04PM (#28875155)

    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)

    by recoiledsnake (879048) on Wednesday July 29, 2009 @07:25PM (#28875389)

    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)

    by Enderandrew (866215) <enderandrew@gmaUMLAUTil.com minus punct> on Wednesday July 29, 2009 @07:30PM (#28875439) Homepage Journal

    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)

    by FireFury03 (653718) <slashdot.nexusuk@org> on Wednesday July 29, 2009 @07:41PM (#28875541) Homepage

    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)

    by Dan9999 (679463) on Wednesday July 29, 2009 @07:49PM (#28875601)
    part of this reminds me of how annoying it is to have people try to get into the elevator before everyone has gone out
  • Re:Linus (Score:3, Informative)

    by Phoenix138 (61439) on Wednesday July 29, 2009 @08:13PM (#28875827)

    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)

    by Intron (870560) on Wednesday July 29, 2009 @08:15PM (#28875855)
    A browser gets the original image from the server along with html tags width & height and information about your PC's display mode. Then it mangles the image to fit - losing resolution and pixel depth along the way. An image editor like the GIMP wants the full-size original.
  • Re:Linus (Score:2, Informative)

    by machine321 (458769) on Wednesday July 29, 2009 @09:02PM (#28876241)

    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)

    by cathector (972646) on Wednesday July 29, 2009 @09:07PM (#28876283)

    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.

  • by setagllib (753300) on Wednesday July 29, 2009 @09:34PM (#28876467)

    There are two Alan Coxes, one for Linux and one for FreeBSD. It's confusing but there you go.

  • Re:Thanks (Score:4, Informative)

    by Pyrion (525584) * on Thursday July 30, 2009 @12:22AM (#28877571) Homepage

    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)

    by dominious (1077089) on Thursday July 30, 2009 @06:30AM (#28879493)
    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. [wikipedia.org]

    Personally, that tells me something!
  • Re:Drag'n'drop (Score:3, Informative)

    by julesh (229690) on Thursday July 30, 2009 @07:32AM (#28879893)

    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:

    1. Run all applications in the same address space/virtual machine. This is the approach that Smalltalk took, and is also done today in some research systems (Microsoft's Singularity springs to mind, but there are others too... and I think Singularity prevents objects being transferred between running processes for its own subtly different reasons, IRRC). It isn't done in mainstream operating systems because there are a few serious downsides:
      • All applications must be written in languages that are compatible with each other's object representation. In most cases where systems like this have been implemented, there is only a single language available.
      • In order to meet the process isolation requirements that we have of modern operating systems (i.e. a failure in one application doesn't cause the entire system to fail) the language _must_ be both type safe and memory safe (i.e. memory used by an object of one type cannot be reused by an object of another type while there is a live pointer to that memory in the system). Memory safe languages almost always do not offer explicit memory management, as the two features are extremely difficult to combine. Some operations are less efficient in type safe environments. Consequently, such environments usually offer poor responsiveness and are not suitable for realtime uses. People avoid such environments.
      • If you don't have a type safe environment, or your type system does not offer protection of private elements and a means to prevent subclassing, it is impossible to implement a secure system. Any running application can interfere with any other running application at will. Smalltalk suffers from this problem: any code running on a smalltalk system can perform any operation it is possible to perform on the system. Smalltalk cannot provide isolation of multiple security domains.
    2. Provide a remote method invocation framework. Objects are held in a server process that receives messages from client processes and invokes operations on the object in response to them. Such systems are generally cumbersome to work with, requiring a lot of developer overhead in most cases. COM, which Windows' drag & drop is based on, uses this approach.
    3. Serialize the object, deserialize it in the recipient, and provide a copy of the object's methods in a form which can be linked on demand into the recipient. Windows implements this in the form of OLE, an extension of COM, which some drag and drop applications support (e.g. MS Office). The problem with this is that the requirements are extremely complicated so few developers bother registering their objects as OLE-capable. It just isn't worth the effort.
    4. I'm not sur

  • by Zaurus (674150) on Thursday July 30, 2009 @02:38PM (#28885739)
    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.
  • Re:Thanks (Score:2, Informative)

    by tholme (1385629) on Thursday July 30, 2009 @06:25PM (#28889439)
    It sounds like you doesn't understand what Linus is saying. He isn't insulting OGAWA by telling him that what he found out is obvious. He is just saying what _emacs does_ is an obvious assumption and therefore the commit in question is "a buggy pile of shit" and argues that it should be reverted.
  • Re:Thanks (Score:3, Informative)

    by kelnos (564113) <bjt23&cornell,edu> on Friday July 31, 2009 @03:30AM (#28893199) Homepage

    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.

It is impossible to enjoy idling thoroughly unless one has plenty of work to do. -- Jerome Klapka Jerome

Working...