back to article 'SHUT THE F**K UP!' The moment Linus Torvalds ruined a dev's year

A Linux kernel developer found himself in a perfect storm of Linus Torvalds' sharp tongue and his intolerance for bad code. Red Hat's Mauro Carvalho Chehab was told by Linux kernel chief Torvalds to "shut the f**k up" and fix his "approach to kernel programming" after Chehab passed off a bug in the kernel as something at fault …

COMMENTS

This topic is closed for new posts.

Page:

  1. This post has been deleted by a moderator

  2. Anonymous Coward
    Anonymous Coward

    Re: Torvalds is the greatest manager of them all

    Really? He is one of the worst possible managers I could imagine. If he had been an employee at Red Hat, he would now be an ex-employee. As technically proficient as he may be, that does not give him the right to abuse people in public (and that's what this was - abuse).

    And the problem continues when people who have no technical cops try and mimic him. "Oh, I'll say XYZ. Linus did it and everyone though it was the funzors. ROFL."

    Seriously, Linux needs to be removed from managerial duties but the Linux Foundation; he is not an asset in that regard.

  3. Steve Todd

    You know that Linux is just the Kernel, right?

    In the same way XNU is the Kernel for both iOS and OS X. On top of that are a bunch of layers for the GUI, video and audio abstraction etc. it's not dramatically better than any Unix derivative, but its cheap and hosts a lot of open source software out of the box.

  4. LordHighFixer
    Flame

    Re: Torvalds is the greatest manager of them all

    " If he had been an employee at Red Hat, he would now be an ex-employee."

    RedHat needs to get over itself. After working with it and them for a number of years I have noting good to say. Tech support is less than stellar, and google gives better answers. They have spun everything necessary into some form a GUI with, in many cases, no way to accomplish the same task from the command line. IMHO they have let their neck ties cut off the oxygen to their corporate brain. Getting on your knees to please a special interest group only pleases the special interest group and all you get is "reward" all over your face. RedHat needs to focus on making a functioning product and actually providing useful support, not just selling it to you.

  5. Lars Silver badge
    Pint

    Re: Torvalds is the greatest manager of them all

    "abuse people in public" in the open, open source, you know. Just accept it.

  6. John Smith 19 Gold badge
    Unhappy

    Re: Torvalds is the greatest manager of them all

    " They have spun everything necessary into some form a GUI with, in many cases, no way to accomplish the same task from the command line."

    Sounds like Windows to me.

  7. Alan Brown Silver badge

    Re: Torvalds is the greatest manager of them all

    " If he had been an employee at Red Hat, he would now be an ex-employee"

    Wich probably explains why Redhat developers have repeatedly gotten away with pulling the same crap on us at $orkplace as Mauro pulled on Linus.

  8. dssf

    Re: Torvalds is the greatest manager of them all

    The hardest and most unfortunate thing about the Internet and email is that unless emoticons or their analog are use throught text or in paragraphs' lead-ins, and unless the retrospective readers know the full context and the personalities of the involved, it is well too easy to take out of context a running disagreement or off comment and make a mountain out of it.

    But, in the absence of emoticons, and since someone published the comment, and since we do not know for certain whether the recipient or a casual discoverer leaked it, it is going to be hard to call it abuse or just a jest. Well, until more context is provided. But, doing that just may further damage both Linus and Mauro. After all, it *could* be presumed that Linus may have and *should* have in the past at least heard running complaints about Linux audio.... Then again, Linux and Linux-things probably need 10-100 Linus clones gate-keeping things.

    Actually, is there a software tool that has mostt of Linus' personality written into it? Some enterprising young dev might eclipse Linus by making a "WhaWouLinDoOSa" (What Would Linus Do Or Say?", or might be career-slaughtered for coming up with yet another gut-wrenching, eye-socket-annealing recursive algorithm...) to gate-keep all Open Source projects before they reach .09 or .08 stage, then every 1.2 release.

    With a touch of Ghandi, Tutu, Morrissey, and Torvalds (GTMT)

  9. Levente Szileszky
    FAIL

    Re: Torvalds is the greatest manager of them all

    You're not just an anonymous coward but an idiot, clearly.

    "If he had been an employee at Red Hat, he would now be an ex-employee."

    Is this the same RedHat where all support ends with fingerpointing someone else's code or driver? If so then I agree, Linus does not belong there and they should hire Mauro instead, with his tendency to BS about his failures and blame others he seems like a good fit...

    " As technically proficient as he may be, that does not give him the right to abuse people in public (and that's what this was - abuse)."

    Typical amateur armchair-manager bullshit.

    FYI it's a list and the guy is a volunteer, stop with your nonsense - Torvalds, as an efficient person, quickly put an end to an embarrassingly amateur cockup, period. You might don't like it but this is why you are nowhere near to these circles, you're just another stupid AC posting on a web board.

  10. Chris_Maresca

    Re: Torvalds is the greatest manager of them all

    I suggest you lookup 'flame war".

    This is hardly abuse in the context of what is the equivalent of a bunch of programmers meeting & discussing other people's code, particularly on a mailing list. And, you know nothing of either the way programmers discuss code or of the relationship between the people involved. The only thing you see is a snippet of a discussion and draw conclusions from only that

    Oh, and Linus doesn't have any managerial duties at the Linux Foundation.

  11. John Smith 19 Gold badge

    To be clear

    "" They have spun everything necessary into some form a GUI with, in many cases, no way to accomplish the same task from the command line.""

    To be clear. I was referring to the comment, which referred specifically to the Red Hat distro.

    The question is do those who use it (not maintain it) agree?

  12. Dave 126 Silver badge

    Re: Torvalds is the greatest manager of them all

    >not allowed to upset MS by installing Linux on desktops - YET.

    Before that happens, common Linux apps (music players, text editors, image editors etc) need to be given names that hint at their function. I enjoy word games based, but not everybody does.

    The other major factor for the bloke on the street (whilst he is at his desk) is support for the software he already knows... this is happening in a number of ways, including:

    -1st party support for Linux (ie Valve looking at Linux as a gaming platform), many games already straddle more platforms than commercial productivity applications (eg Win, Mac, Xbox, PS3, Wii) so are developed with this in mind.

    -Opensource alternatives to Win/Mac software (eg LibreOffice, GIMP),

    -Browser or cloud-based software being OS agnostic (eg, Google Docs, CAD at the other end of the scale -driven by convenience of being able to rent compute time as required, and the need to collaborate with colleagues, suppliers and clients)

    -WINE

    -VMs - though these still need a licence, and for the novice some hand-holding, perhaps to make the VM invisible to them

    It might be that Linux only becomes a main-stream OS choice when the choice of one OS over another becomes unimportant.

  13. Anonymous Coward
    Anonymous Coward

    Re: Torvalds is the greatest manager of them all

    "Is this the same RedHat where all support ends with fingerpointing"

    You miss the point, completely. It's not about RedHat (I picked that name just because it was in the story already), it's about abuse of people in a public forum. It's gross professional misconduct, potentially illegal (local laws depending) and should lead to summary dismissal.

  14. Anonymous Coward
    Anonymous Coward

    Re: Torvalds is the greatest manager of them all

    Surface already has a 0.4% tablet market share (by browser stats) in 2 months. That would make it a circa 2.5% market share in a year. Pretty good imo considering that it is just one of many Windows RT tablets - and is expensive.

    Surface Pro is what we are all waiting for anyway.

    Not sure in what way you think Linux is better? - it pretty much always lags behind Windows in terms of functionality and performance - and keeps copying Windows kernel innovations - for instance per processor cache lists. Plus it has miles more security holes and is much harder to work with.

    Anyway, it would be rediculous to teach something that less than 1% of the population actually uses in school as opposed to something that at least 90% of them use...

    Not sure where you get your ideas about power / performance either - Windows 8 RT outperforms most Android based tablets on that front: "the Microsoft Surface Tablet with Windows RT offered excellent battery life, finishing just shy of the 10-hour mark. The only devices that offered longer battery life were the Galaxy Tab 10.1, which has a lower-resolution screen, and the docked Asus Transformer Pad 300, which had the added benefit of a secondary battery"

  15. This post has been deleted by a moderator

  16. Anonymous Coward
    Anonymous Coward

    Re: Torvalds is the greatest manager of them all

    Why would someone want to post in their own name just to suffer your volleys of shill accusations?

    Stop calling everyone a shill. It's against the house rules and you've already had posts removed by moderators because of it.

  17. Xelandre
    WTF?

    Is this the whole story?

    I'm missing something here.

    What did the spec for IOCTL specify anyway? Did the incriminated "fix" make IOCTL comply with the specification? Or did the application rely on an undocumented buggy behaviour?

    Or maybe there are no detailed specs, besides the big guy's imprecations? (That would be pretty typical...).

  18. Xelandre
    WTF?

    Is this the whole story?

    I'm missing something here.

    What did the spec for IOCTL specify anyway? Did the incriminated "fix" make IOCTL comply with the specification? Or did the application rely on an undocumented behaviour, and required bug compatibility?

    Or maybe there are no detailed specs, besides the big guy's imprecations? (That would be pretty typical...).

  19. diodesign (Written by Reg staff) Silver badge

    Re: Is this the whole story?

    See Linus' email for the full technical reasons why: the ioctl was returning a code invalid for the operaton requested. Any app that properly checked its syscall error codes would be confused. The error code returned to pulseaudio was specific to paths, wheas ioctls operate on open files.

    C.

  20. rleigh
    Linux

    ioctl

    The prototype for ioctl(2) is:

    int ioctl(int d, int request, ...);

    where 'd' is an open file descriptor. The error being returned was ENOENT (no such file or directory). Since ioctl only works on open files, an error saying it doesn't exist is clearly awry. It has to exist: you already opened it! The file descriptor can be invalid, but that's EBADF.

    So Linus' criticism here is totally justifiable, since it's meaningless to return ENOENT in this context.

    Regards,

    Roger

  21. Ian Johnston Silver badge

    Re: ioctl

    As a matter of interest, what error code is returned if the file is successfully opened, but then becomes unavailable (deleted, device removed, whatever) before the access attempt?

  22. Gerhard den Hollander

    Re: ioctl

    EBADF, as explained in the post you replied to .

    The file descriptor is no longer available, so it's no longer a valid descriptor.

    EBADF is the error code to indicate that.

  23. rleigh

    Re: ioctl

    Deletion doesn't matter--the device is already open at this point, so unlinking the device node makes no difference. Most devices would prevent removal (e.g. module unloading) if in use, so this is an unlikely situation. But if it does occur and it disappears, you would probably get EBADF since the fd would no longer be valid. Not a situation I've ever seen though.

  24. Destroy All Monsters Silver badge

    Re: ioctl

    > the device is already open at this point, so unlinking the device node makes no difference.

    Correct.

  25. Levente Szileszky
    Thumb Up

    Totally reasonable outburst...

    ...after the guy he's yelling at had the audacity to blame someone else for *his* *own* fundamental mistake.

  26. Ian Johnston Silver badge

    Re: Totally reasonable outburst...

    Although it seems that it was someone else's mistake - this "Laurent" chap. As far as I can see, Mauro's offence was that, told a return code was causing problems, he asked "is that our problem or pulseaudio's" and Linus went off on one. Linux audio is such a hideous, bloated, buggy mess that it seems, from outside, to have been a reasonable question.

  27. Dave 126 Silver badge

    Re: Totally reasonable outburst...

    My first dip my toes in the Linux waters was installing Mint on an ancient ThinkPad with a mate, for shits and giggles... til that day, I had never even heard of SUDO before. We installed Mint fairly quickly, but getting audio to work took the rest of the afternoon, though to be fair we were complete novices and the internet suggested that model of ThinkPad had slightly esoteric audio hardware.

    I'm normally a Windows user, and I take a fairly dim view of its audio system as well. Trying to use ASIO is a PITA cos WSM keeps jumping in, trying to change the default MIDI device requires faffing around in the registry... I only mess around with audio applications for fun; if I had to do it seriously, I would get a Mac without question.

  28. Modeller
    Linux

    you still haven't learnt the first rule of kernel maintenance?

    What is the first rule of kernel maintenance?

  29. Anonymous C0ward

    Re: you still haven't learnt the first rule of kernel maintenance?

    You don't talk about kernel maintenance!

  30. Levente Szileszky
    WTF?

    Re: you still haven't learnt the first rule of kernel maintenance?

    Uhh, it's right there: you don't break user packages. If they suddenly blew up after your update then you did something wrong and ought to go back and fix it instead of asking them to change because you are a *maintainer*, remember.

  31. bolccg
    Happy

    Re: you still haven't learnt the first rule of kernel maintenance?

    You don't talk about it... It's the second rule too.

  32. Anonymous Coward
    Anonymous Coward

    Re: you still haven't learnt the first rule of kernel maintenance?

    Nah, there's been a mistake, the second rule is "No smoking".

  33. Anonymous Coward
    Anonymous Coward

    Re: you still haven't learnt the first rule of kernel maintenance?

    Would that apply if the use package was using an undocumented feature / bug? Or if it was assuming that a return code it had never received could never be received? If Linux is designed to keep buggy userspace applications working at all costs, much is explained.

  34. Ilgaz

    Here it is

    Quote from link:

    "If a change results in user programs breaking, it's a bug in the

    kernel. We never EVER blame the user programs. How hard can this be to

    understand?"

    Seriously, it is a rule which should apply to all operating systems up to Z/OS.

  35. Anonymous Coward
    Anonymous Coward

    Re: Here it is

    Isn't that like saying "The customer is always right, even if he's trying to return a used item from another store"?

  36. Dave 126 Silver badge

    The rules of kernel maintenance:

    Rule 1: No poofters.

    Rule 2: No member of the faculty is to maltreat the Abos in any way whatsoever—if there's anyone watching.

    Rule 3: No poofters.

    Rule 4: I don't want to catch anyone not drinking in their room after lights out.

    Rule 5: No poofters.

    Rule 6: There is no... rule six.

    Rule 7: No poofters.

    Oh wait, I think I have the wrong meeting...

  37. Northern-Alf
    FAIL

    Bit of a non-story; anyone who keeps a regular eye on the Linux kernel mailing lists would realise this is nothing out of the ordinary; Mr L.T. doesn't mince his words and I've seen plenty like this.

    Cheers

    Mark

  38. Johnsz

    John Szetela

    Software development isn't for wimps. I'm sure that Linus had had some very bad words for himself when he messed up some "important" code. Have engineers and programmers aver actually been normal human beings and expected to be treated thusly? I might be wrong but I rather put us in another class of beings and don't expect politeness and management professionalism as being quite so important. I'm done with software management now since I'm retired. However, I still both wince and expound quite vociferously at some of my own code. I only hope that others code is somewhat worse than mine...

  39. Richard 12 Silver badge
    WTF?

    Re: John Szetela

    Of course he did. Every programmer does.

    When I find something something stupid in code I'm maintaining, I almost always mutter "You ***** idiot" (or worse) under my breath.

    It doesn't matter whether I made the error or somebody else did - the mistake is stupid.

    I can't believe I'm the only one.

  40. Ilgaz

    Re: John Szetela

    I got a friend who got hospitalized for literally smacking a CRT monitor with filter noticing a very stupid bug in his own code.

    It took some time to explain to hospital police.

  41. Anonymous Coward
    Anonymous Coward

    Re: John Szetela

    Generally a "Disregard this, I suck cocks" is sufficient.

    What gets to me is that when I dare to call out crashing, unfit and undocumented crud (in some cases, unsecure crud) actually delivered to customers, I'm being called back by management. The justification being "but he's a good programmer, he delivers in time."

    What the hell?

  42. The Alpha Klutz
    Megaphone

    HOW DARE YOU DO THIS

    Get that Chebab guy here so i can shout at him too. what a tool. scum!

  43. Johan Bastiaansen
    Devil

    Very good

    There is way to much tolerance for mediocrity and for people who do the bare minimum.

  44. Will Godfrey Silver badge
    Meh

    What some people seem to forget is that this guy was not just any coder but one of the kernel maintainers, which is just about as senior as you can get in the Linux world. This is someone you would expect to be absolutely red-hot on correctness, yet he not only changed a return result, but changed it to something that was impossible for that situation.

    After it was pointed out to him just what he'd done wrong, instead of setting about correcting it he then proceeded to waffle and claim it was someone else's fault for using the API wrongly. Well, no. If a certain behaviour is listed, then you don't change it without warning.

    That is why he got chewed out, and he richly deserved it. I don't know if he still has the status of a maintainer, but he wouldn't have if I was the boss.

  45. koolholio
    FAIL

    Drivers run underneath the kernel

    It is not a kernels fault for driver development, not knowing which code this is reference to though...

    ioctl() does exactly what it says on the tin...

    input <|> output control...

    You can't blame a kernel for shoddy driver development! I've seen many a dodgy driver code in my time due to exception handling being missed out or broken! some causing some right old mayhem for device and machine. Not exclusive to linux either!

  46. LosD

    Re: Drivers run underneath the kernel

    Doesn't matter: The driver is distributed as part of the kernel, and is under the same rule: DO NOT break userspace.

  47. Anonymous Coward
    Anonymous Coward

    Re: Drivers run underneath the kernel

    I don't buy the "Don't break userspace" if userspace us implemented wrongly to make use of an existing buy in the Kernel, you fix the bug and bollocks to userspace. It would, of course, be courteous to let anyone you reasonably can in userpace, who is exploting the bug, know that you're doing this.

  48. John Smith 19 Gold badge
    Happy

    This is *not* a software development problem, it's a *management* problem

    Specifically a member of a team not taking responsibility for their c**kup.

    And as others have pointed as this is the kernel a screw up here affects every app that sits on top of it.

    I'm not sure if this is a paid role but I'm assuming if not then the fact you're trusted to have your work accepted into the core distribution bring lots of kudos and might have some benefits regarding your employer remuneration.

    I've always liked that like of Gene Hackman's in "Crimson Tide." "We defend democracy, we do not practice it."

  49. John Deeb
    Boffin

    midlife crisis what crisis?

    Just finished reading the exchange but Linus is blowing it all way out of proportion and Mauro just takes the higher road. Also technically I'm not that sure if Linux really understood the mess. My best guess: midlife crisis approaching.

  50. factor

    Re: midlife crisis what crisis?

    I just read that same thread - I fundamentally disagree.

    Linus complaint was:

    * a patch in the audio code had been accepted by Mauro that changed the error return codes of a function, this changes the interface which other applications could rely on.

    * this patch in the audio code broke a kernel release candidate, the fault was not picked up by testing tools Mauro also had responsibility for maintaining.

    * having broken a RC & received explanation of the problem error code he questions whether the userspace code is wrong rather than his code -- he allowed the interface to be changed!!

    * Linus suggests he should shut up before he embarrasses himself further.

    * then Mauro keeps talking .. have a funny feeling this has happened before. There is no excuse. Revert to the previously returned return codes. And larger changes require discussion first.

    * Mauro suggests that it is ok to make a change to an interface (which is in production) to gain consistency with something else. This is absolutely wrong, once the interface is set it cannot be changed, other applications are relying on it. This is the source of Linus frustration - Mauro hasn't learnt the first rule of kernel maintenance - you can't randomly change shit others could be relying on. If you do & something breaks it is the kernel's fault.

Page:

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2018