13 ms·

Linus Torvalds: Programs exist for their users

261 points by CJefferson 15y ago

groue 15y ago
It's like reading a Plato book where Socrates is bullying the guests :-)
deleted 15y ago
[deleted]
bravura 15y ago
The text: From Linus Torvalds <> Date Thu, 8 Mar 2012 15:40:26 -0800 Subject Re: [PATCH] sysfs: Optionally count subdirectories to support buggy applications On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > > Keeping compatibility is easy enough that it looks like it is worth > doing, but maintaining 30+ years of backwards compatibility Stop right there. This is *not* about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f*&^ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than *any* of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is *so* important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the *idiots* out there that don't understand that binary compatibility is one of the absolute top priorities. The *only* reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the *worst* offense any kernel developer can do. Because that shows that they don't understand what the whole *point* of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a *usable* system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus
route66 15y ago
The site is down, the content is (at least for me) not available in google cache, so I suppose it's the same for others as well. And yet it's the top story on HN right now. When do we start giving tl;dr's for the headlines? [EDIT] managed to find a mirror. This mail in the thread gives a bit more context: http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/00446.html http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/00446....
- ElliotH 15y ago
  Up here (and since you posted 0minutes ago, I imagine a refresh or two would fix it for you)
- Father 15y ago
  What it reads: * From Linus Torvalds <> Date Thu, 8 Mar 2012 15:40:26 -0800 Subject Re: [PATCH] sysfs: Optionally count subdirectories to support buggy applications On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > > Keeping compatibility is easy enough that it looks like it is worth > doing, but maintaining 30+ years of backwards compatibility Stop right there. This is not about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f&^ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than any* of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is so important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the idiots out there that don't understand that binary compatibility is one of the absolute top priorities. The only reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the worst offense any kernel developer can do. Because that shows that they don't understand what the whole point of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus
ttt_ 15y ago
Copy/paste from a reddit comment mirroring the content: From Linus Torvalds <> Date Thu, 8 Mar 2012 15:40:26 -0800 Subject Re: [PATCH] sysfs: Optionally count subdirectories to support buggy applications On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman ebiederm@xmission.com wrote: Keeping compatibility is easy enough that it looks like it is worth doing, but maintaining 30+ years of backwards compatibility Stop right there. This is not about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f*&ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than any of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is so important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the idiots out there that don't understand that binary compatibility is one of the absolute top priorities. The only reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the worst offense any kernel developer can do. Because that shows that they don't understand what the whole point of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus
dhconnelly 15y ago
Is this the same? http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/00491.html http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/00491....
- dhconnelly 15y ago
  wait, it's back up. but yeah, this is a mirror.
dsr_ 15y ago
Leadership: communicate a clear mission and inspire others to want to do it. Linus has it.
- exim 15y ago
  I would add politeness. Not sure about Linus, though...
  - akira2501 15y ago
    Leadership doesn't require politeness. Fairness is probably what you really want.
    - aiscott 15y ago
      I agree, fairness over politeness. I would say honesty over politeness as well. That isn't to say you shouldn't be polite; just realize that sometimes your decisions are going to hurt people no matter how nicely you put it.
    - tsunamifury 15y ago
      I think this is a good point. I don't want people to be needlessly polite, I want them to be truthful in a manner that is also respectful.
  - ajross 15y ago
    He's nicer than Jobs, at least.
    - microtherion 15y ago
      Granted, Jobs was not always a nice person behind closed doors. However, at least during his Apple 2.0 days, he did NOT trash the people working for him in public the way Linus habitually does. Another difference is that a lot of people working for Jobs (again, at least during the Apple 2.0 days) made f* you money for their efforts. There are engineers making a living working on Linux, but not on that scale, I think.
willvarfar 15y ago
Mirror of text from his email (Linux Kernel Mailing List (LKML) is under heavy load): From Linus Torvalds <> Date Thu, 8 Mar 2012 15:40:26 -0800 Subject Re: [PATCH] sysfs: Optionally count subdirectories to support buggy applications On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman ebiederm@xmission.com wrote: > Keeping compatibility is easy enough that it looks like it is worth doing, but maintaining 30+ years of backwards compatibility Stop right there. This is not about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f*&ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than any of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is so important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the idiots out there that don't understand that binary compatibility is one of the absolute top priorities. The only reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the worst offense any kernel developer can do. Because that shows that they don't understand what the whole point of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus
unicron 15y ago
I reckon that "drug induced microkernel" was a stab at Tanenbaum :-)
- radious 15y ago
  Pretty stupid stab, to be honest. Every major desktop/workstation operating system uses microkernel or hybrid architecture (even NT, yeah, that's true; I know that Linux thinks hybrid is another word for macro-). And it is like this for some purpose. To my best knowledge being macrokernel makes Linux "huge and bloated" like someone has once said.
  - andreime 15y ago
    http://en.wikipedia.org/wiki/Microkernel http://en.wikipedia.org/wiki/Microkernel search Windows or NT. OS X, Linux and NT don't use microkernels.
    - radious 15y ago
      NT and OS X use hybrid kernels (as well as Plan9). Linus believe that hybrid is another term for monolithic, but rest of the world does not. AFAIR micro- ones are used by QNX and Minix. Monolithic kernels are used by Linux, *BSD (with an exception for Dragonfly, which uses hybrid kernel), Solaris, AIX(?) and more SysV descendants.
      - gillianseed 15y ago
        < NT and OS X use hybrid kernels (as well as Plan9). Linus believe that hybrid is another term for monolithic, but rest of the world does not. Count me out of 'the rest of the world' then. Perhaps you can point me to the what part of NT which would make it a hybrid kernel as opposed to Linux. I've never seen any explanation of this.
    - pkmays 15y ago
      http://en.wikipedia.org/wiki/Hybrid_kernel http://en.wikipedia.org/wiki/Hybrid_kernel No, Windows and OS X use hybrid kernels.
jmitcheson 15y ago
Text-only google cache http://webcache.googleusercontent.com/search?q=cache:https://lkml.org/lkml/2012/3/8/495&hl=en&rlz=1C1ASUT_enNZ386NZ386&biw=1366&bih=667&site=webhp&strip=1 http://webcache.googleusercontent.com/search?q=cache:https:/...
jiggy2011 15y ago
Can anybody explain what this is approximately about?
- phn 15y ago
  Well, the first guy is submitting a patch to the linux kernel source that would make program binaries (executable files, sort of) compiled for an older version of the kernel break. This same guy looks like he is about to argue that it is not worth to maintain compatibility with 30 year old binaries. And then Linus (the guy behind Linux) goes on to explain that the OS should serve its users, and that keeping compatibility with existing programs, no matter how old they are is of utmost importance for users to be able to use that system. I don't know if I helped, or if I addressed your doubts. I hope so :)
Negitivefrags 15y ago
In my experience binary compatibility on linux is a train wreck. Ever tried to get a binary compiled 5 years ago to run on a fresh install of linux? Good luck. If you still have the specific version of every shared library that it loaded you might be able to get it to work. This isn't the fault of the kernel team though. It is probably to be expected on platforms in which distributing source code is the default option, but it makes the platform very hostile to closed source applications, particularly games.
- MatthewPhillips 15y ago
  It makes it hostile to abandonware.
  - gaius 15y ago
    Hostile to people who use their machines for Real Work.
- gaius 15y ago
  Compare and contrast: http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779...
- davidw 15y ago
  If you want to be sure it'll work, you compile it statically, and waste a little bit of disk space and memory.
  - protomyth 15y ago
    Trading security / bug fix updates in the process
- muuh-gnu 15y ago
  > This isn't the fault of the kernel team though. It is the result of having no unified platform and library release coordination, no long term plans, nothing, just chaos. Everybody just releases when he is in the mood for it. And since nothing is complete when released, devs further down the chain always go for the latest and greatest to get additional functionality. And to upgrade app1, you have to upgrade lib1 which triggers the updates of app2, app3, app4, lib3, etc. Sometimes you cant update a simple app without updating the whole desktop. The Linux dependency net appears nightmarish to everyone coming from Windows, where you have a reliable, stable base system which doesnt change for a decade and every app targets the same base system. Linux, the kernel, is only running that great because it has a dictator. But Linus' dictatorship ends at the kernel borders, he has little influence outside. The Linux desktop also needs a dictator to massively slow down the rate of uncoordinated changes and force-stabilize the ecosystem. I hoped that Mark Shuttleworth could be that man, but he then introduced Unity... but even with unity, Ubuntu is the only chance for the Linux desktop for having a single defined set of libs attractive and influential enough for app devs as a primary target so they can safely go with the library versions in Ubuntu, instead of constantly chasing the latest and greatest versions from the upstream.
16s 15y ago
I got a good laugh from this quote: "[Linux] is not some crazy drug-induced microkernel"
- stargazer83 15y ago
  All these years later, the flame goes on :p
- ot 15y ago
  That sentence is a betrayal of UNIX's history: There are two major products that came out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. (Jeremy S. Anderson)
  - mapleoin 15y ago
    I think it rather refers to MINIX.
    - Lozzer 15y ago
      More likely HURD
      - dfc 15y ago
        No, it was tanenbaum and minix.
    - abrahamsen 15y ago
      More specifically, it most likely refers to this discussion: http://groups.google.com/group/comp.os.minix/browse_frm/thread/c25870d7a41696d2/f447530d082cd95d?#f447530d082cd95d http://groups.google.com/group/comp.os.minix/browse_frm/thre... Linus was a kid in 1992, and got scolded by one of the greatest icons of the field. That could still sting 20 years later.
      - sixbrx 15y ago
        I always thought Linus gave better than he got in that argument, myself. He was pretty brutal to Minix in a couple of places. BTW. love the reference to "BSD detox" somewhere in that thread, it always gives me a chuckle.
oxxx 15y ago
<3
aptwebapps 15y ago
An easy way to read the whole thread: http://markmail.org/thread/wwi2aynfiliqanil http://markmail.org/thread/wwi2aynfiliqanil I don't understand why Mark Mail doesn't get more love. I wish they had better SEO or something, it's so much easier to read a long thread on their site then most mailing list archives.
- michaelmior 15y ago
  Here's a link to the actual message referenced by the submission http://markmail.org/message/d4dfw53uqwhdj24i http://markmail.org/message/d4dfw53uqwhdj24i
- mrud 15y ago
  I don't like it because it seems to have no threaded view. I really like gmane much more for mailing list discussions - http://thread.gmane.org/gmane.linux.kernel/1245999/focus=1264170 http://thread.gmane.org/gmane.linux.kernel/1245999/focus=126...
  - aptwebapps 15y ago
    Yeah, that is nice. Either one is a vast improvement over old-style list archives.
    - dredmorbius 15y ago
      mbox and your own damned client.
      - aptwebapps 15y ago
        If you happen to already be subscribed to the mailing list in question, sure.
        dredmorbius 15y ago
        There are list archives which provide mbox format archives. Mailman for example.
4ad 15y ago
It's great that Linus is committed to supporting old binaries, too bad all that effort is in vain because of the glibc disaster. Linux can run statically compiled binaries from 1993, but not the Firefox binaries from 2006.
- aniket_ray 15y ago
  Yeah, the gnu libc and libstdc++ projects have been particularly bad at maintaining ABI compatibility.
- malkia 15y ago
  wouldn't it be possible to still run them with some LD_xxx magic where the c++ shared libs are put in some folder and loaded from there? (It's really userspace problem).
  - A1kmm 15y ago
    Yes - I've done that to produce more portable Linux binary installers where static binaries would have caused other problems - I tested it for backwards compatibility, but hopefully it will also improve forward compatibility. One problem that you encounter if you do that is that glibc has an option to disable support for older kernels in exchange for better performance, so you lose backwards compatibility unless you are very careful about how you compile glibc (it fails with an error that the kernel is too old).
tete 15y ago
[Here the post in case the site is down...] On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Keeping compatibility is easy enough that it looks like it is worth doing, but maintaining 30+ years of backwards compatibility Stop right there. This is not about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f* &^ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than any of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is so important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the idiots out there that don't understand that binary compatibility is one of the absolute top priorities. The only reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the worst offense any kernel developer can do. Because that shows that they don't understand what the whole point of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus
famousactress 15y ago
Linus is very consistent when it comes to these things. A similar thread from a while back: http://news.ycombinator.com/item?id=2372096 http://news.ycombinator.com/item?id=2372096
dustingetz 15y ago
the full context of the quote provoking Linus's rant is extremely relevant here: The current counting that we do gives the wrong numbers, in the edge cases. To my knowledge a deleted sysfs directory has never returned nlink == 0. Keeping compatibility is easy enough that it looks like it is worth doing, but maintaining 30+ years of backwards compatibility is what nlink >1 in unix filesystem directories is. I don't see any practical sense in keeping . and .. directories on disk or upping the unix nlink directory count because of them. To me it looks like just one of those things you do. Like hash directory entries so you can have a big directory and still be able to have a 32bit offset you can pass to lseek that is stable across renames and deletes. to use PG's terms, Linus is arguing against this at DH0 or maybe DH1 here[1]. Maybe the above argument sucks, but Linus didn't refute it at all. [1] http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html
- icebraining 15y ago
  I disagree. He refuted the premise that breaking backward compatibility is OK under certain conditions, because "the only reason for an OS kernel existing in the first place is to serve user-space." That alone refutes the whole argument.
jonhohle 15y ago
> Programs exist for their users While this may be inferred from this discussion, this is not what Linus said in this thread. He actually said: > The *only* reason for an OS kernel existing in the > first place is to serve user-space. This is a much narrower definition without the philosophical implications of the title. Sometimes programs don't exist for their users. Take DRM for example - it is explicitly against the user.
- ahelwer 15y ago
  The DRM user is the publisher, not the user of the program itself.
  - jonhohle 15y ago
    I disagree. The Publisher in this case is the programmer - or at least distributor - of the program. Content consumers are the intended user.
    - namdnay 15y ago
      I have to disagree with you there, clearly the user of DRM is the copyright holder. They are using the tool to perform their activity, that of "safely" leasing their content to consumers. In the same way, the user of DirectX is the game publisher, not the consumer who buys the game.
      - jonhohle 15y ago
        I am my DVD player's user. The copyright holder does not come to my house to operate my DVD player. It will not allow me to play discs not encoded for my region. This program is not written for my preference or use, but in opposition to me. It also does not allow me to bypass certain segments of videos. Again - it opposes me. If it was written for me - the user - it would allow me to bypass all content and jump directly to the first title of every disc I inserted. The producers of this software have explicitly made it hostile to the user. I'm not saying this is not within their rights - I'm just saying it is. But this is a rat hole. My point was that this is not what Linus was saying. He was merely describing the purpose of one software component. A kernel is a hardware abstraction - a platform for building applications without concern for the details of components - including the version of the kernel itself. He was arguing against breaking that contract by introducing a change which fit the whims of the contributor but would break an unknown number of binaries compiled against that contract. tl;dr - "user" is not the same as "user-space"
cpeterso 15y ago
In contrast, here is a thread about Debian, after much deliberation, unanimously choosing to break kernel ABI compatibility with VMware. They didn't want to increase the ABI number during a "freeze", even though they broke the ABI. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607368 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607368
- danudey 15y ago
  While I disagree, in the end, about breaking user applications, I can appreciate their situation. They have an upstream kernel from which they get bugfixes and patches, but which has no guarantees of stability. Any guarantees that the Debian team decides to make are their own responsibility, and could result in them maintaining multiple patches just to fix ever-more-diverging upstream releases.
- lambda 15y ago
  That's the difference between the user-space interface, and the kernel ABI. The Linux kernel ABI has no compatibility guarantees. If you are linking to the kernel, you are considered to be part of the kernel, and thus you are expected to keep abreast of any ABI changes (preferably by getting your module into the kernel tree, so that anyone changing the ABI can fix your code too). The Debian kernel team tries to do a reasonable job of tracking kernel ABI compatibility changes, and updating the number when the ABI does change, to avoid having to recompile and reinstall everything for every patch to the stable tree. In this case, they decided that the ABI change was only intended for a single, in-tree module (KVM), and that they didn't have to increment the ABI number for a change that shouldn't affect anything else. This is really just an example of the Linux kernel developers' two approaches to compatibility. For the kernel ABI, they make no guarantees whatsoever about compatibility. For the user space interface, they are supposed to never, ever change the interface in ways that will break existing programs, though there are sometimes disagreements about what precisely constitutes this interface and what is outside the bounds of it.
- namdnay 15y ago
  Slightly off-topic, but often when reading these mailing lists I find some developers to be rather unhelpful, if not downright nasty. Take this example. Now I realise this isn't a company-client relationship we're looking at, but am I alone in thinking a bit more diplomacy wouldn't have gone amiss?
rogerclark 15y ago
that guy is such a turd
caycep 15y ago
This is straight out of the original Tron!
evanlong 15y ago
Come on people the future is node.js and MongoDB. WE DON'T NEED KERNELS!!! Async programming IS JUST SO MUCH FASTER!!!
lninyo 15y ago
Just as masturbatory a discussion as expected. Well done gentlemen.

261 points by CJefferson 15y ago

groue 15y ago

It's like reading a Plato book where Socrates is bullying the guests :-)

deleted 15y ago

[deleted]

bravura 15y ago

The text: From Linus Torvalds <> Date Thu, 8 Mar 2012 15:40:26 -0800 Subject Re: [PATCH] sysfs: Optionally count subdirectories to support buggy applications On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > > Keeping compatibility is easy enough that it looks like it is worth > doing, but maintaining 30+ years of backwards compatibility Stop right there. This is *not* about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f*&^ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than *any* of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is *so* important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the *idiots* out there that don't understand that binary compatibility is one of the absolute top priorities. The *only* reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the *worst* offense any kernel developer can do. Because that shows that they don't understand what the whole *point* of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a *usable* system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus

route66 15y ago

The site is down, the content is (at least for me) not available in google cache, so I suppose it's the same for others as well. And yet it's the top story on HN right now. When do we start giving tl;dr's for the headlines? [EDIT] managed to find a mirror. This mail in the thread gives a bit more context: http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/00446.html http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/00446....

ElliotH 15y ago
Up here (and since you posted 0minutes ago, I imagine a refresh or two would fix it for you)
Father 15y ago
What it reads: * From Linus Torvalds <> Date Thu, 8 Mar 2012 15:40:26 -0800 Subject Re: [PATCH] sysfs: Optionally count subdirectories to support buggy applications On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > > Keeping compatibility is easy enough that it looks like it is worth > doing, but maintaining 30+ years of backwards compatibility Stop right there. This is not about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f&^ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than any* of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is so important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the idiots out there that don't understand that binary compatibility is one of the absolute top priorities. The only reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the worst offense any kernel developer can do. Because that shows that they don't understand what the whole point of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus

ttt_ 15y ago

Copy/paste from a reddit comment mirroring the content: From Linus Torvalds <> Date Thu, 8 Mar 2012 15:40:26 -0800 Subject Re: [PATCH] sysfs: Optionally count subdirectories to support buggy applications On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman ebiederm@xmission.com wrote: Keeping compatibility is easy enough that it looks like it is worth doing, but maintaining 30+ years of backwards compatibility Stop right there. This is not about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f*&ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than any of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is so important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the idiots out there that don't understand that binary compatibility is one of the absolute top priorities. The only reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the worst offense any kernel developer can do. Because that shows that they don't understand what the whole point of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus

dhconnelly 15y ago

Is this the same? http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/00491.html http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/00491....

dhconnelly 15y ago
wait, it's back up. but yeah, this is a mirror.

dsr_ 15y ago

Leadership: communicate a clear mission and inspire others to want to do it. Linus has it.

exim 15y ago
I would add politeness. Not sure about Linus, though...
- akira2501 15y ago
  Leadership doesn't require politeness. Fairness is probably what you really want.
  - aiscott 15y ago
    I agree, fairness over politeness. I would say honesty over politeness as well. That isn't to say you shouldn't be polite; just realize that sometimes your decisions are going to hurt people no matter how nicely you put it.
  - tsunamifury 15y ago
    I think this is a good point. I don't want people to be needlessly polite, I want them to be truthful in a manner that is also respectful.
- ajross 15y ago
  He's nicer than Jobs, at least.
  - microtherion 15y ago
    Granted, Jobs was not always a nice person behind closed doors. However, at least during his Apple 2.0 days, he did NOT trash the people working for him in public the way Linus habitually does. Another difference is that a lot of people working for Jobs (again, at least during the Apple 2.0 days) made f* you money for their efforts. There are engineers making a living working on Linux, but not on that scale, I think.

willvarfar 15y ago

Mirror of text from his email (Linux Kernel Mailing List (LKML) is under heavy load): From Linus Torvalds <> Date Thu, 8 Mar 2012 15:40:26 -0800 Subject Re: [PATCH] sysfs: Optionally count subdirectories to support buggy applications On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman ebiederm@xmission.com wrote: > Keeping compatibility is easy enough that it looks like it is worth doing, but maintaining 30+ years of backwards compatibility Stop right there. This is not about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f*&ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than any of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is so important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the idiots out there that don't understand that binary compatibility is one of the absolute top priorities. The only reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the worst offense any kernel developer can do. Because that shows that they don't understand what the whole point of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus

unicron 15y ago

I reckon that "drug induced microkernel" was a stab at Tanenbaum :-)

radious 15y ago
Pretty stupid stab, to be honest. Every major desktop/workstation operating system uses microkernel or hybrid architecture (even NT, yeah, that's true; I know that Linux thinks hybrid is another word for macro-). And it is like this for some purpose. To my best knowledge being macrokernel makes Linux "huge and bloated" like someone has once said.
- andreime 15y ago
  http://en.wikipedia.org/wiki/Microkernel http://en.wikipedia.org/wiki/Microkernel search Windows or NT. OS X, Linux and NT don't use microkernels.
  - radious 15y ago
    NT and OS X use hybrid kernels (as well as Plan9). Linus believe that hybrid is another term for monolithic, but rest of the world does not. AFAIR micro- ones are used by QNX and Minix. Monolithic kernels are used by Linux, *BSD (with an exception for Dragonfly, which uses hybrid kernel), Solaris, AIX(?) and more SysV descendants.
    - gillianseed 15y ago
      < NT and OS X use hybrid kernels (as well as Plan9). Linus believe that hybrid is another term for monolithic, but rest of the world does not. Count me out of 'the rest of the world' then. Perhaps you can point me to the what part of NT which would make it a hybrid kernel as opposed to Linux. I've never seen any explanation of this.
  - pkmays 15y ago
    http://en.wikipedia.org/wiki/Hybrid_kernel http://en.wikipedia.org/wiki/Hybrid_kernel No, Windows and OS X use hybrid kernels.

jmitcheson 15y ago

Text-only google cache http://webcache.googleusercontent.com/search?q=cache:https://lkml.org/lkml/2012/3/8/495&hl=en&rlz=1C1ASUT_enNZ386NZ386&biw=1366&bih=667&site=webhp&strip=1 http://webcache.googleusercontent.com/search?q=cache:https:/...

jiggy2011 15y ago

Can anybody explain what this is approximately about?

phn 15y ago
Well, the first guy is submitting a patch to the linux kernel source that would make program binaries (executable files, sort of) compiled for an older version of the kernel break. This same guy looks like he is about to argue that it is not worth to maintain compatibility with 30 year old binaries. And then Linus (the guy behind Linux) goes on to explain that the OS should serve its users, and that keeping compatibility with existing programs, no matter how old they are is of utmost importance for users to be able to use that system. I don't know if I helped, or if I addressed your doubts. I hope so :)

Negitivefrags 15y ago

In my experience binary compatibility on linux is a train wreck. Ever tried to get a binary compiled 5 years ago to run on a fresh install of linux? Good luck. If you still have the specific version of every shared library that it loaded you might be able to get it to work. This isn't the fault of the kernel team though. It is probably to be expected on platforms in which distributing source code is the default option, but it makes the platform very hostile to closed source applications, particularly games.

MatthewPhillips 15y ago
It makes it hostile to abandonware.
- gaius 15y ago
  Hostile to people who use their machines for Real Work.
gaius 15y ago
Compare and contrast: http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779...
davidw 15y ago
If you want to be sure it'll work, you compile it statically, and waste a little bit of disk space and memory.
- protomyth 15y ago
  Trading security / bug fix updates in the process
muuh-gnu 15y ago
> This isn't the fault of the kernel team though. It is the result of having no unified platform and library release coordination, no long term plans, nothing, just chaos. Everybody just releases when he is in the mood for it. And since nothing is complete when released, devs further down the chain always go for the latest and greatest to get additional functionality. And to upgrade app1, you have to upgrade lib1 which triggers the updates of app2, app3, app4, lib3, etc. Sometimes you cant update a simple app without updating the whole desktop. The Linux dependency net appears nightmarish to everyone coming from Windows, where you have a reliable, stable base system which doesnt change for a decade and every app targets the same base system. Linux, the kernel, is only running that great because it has a dictator. But Linus' dictatorship ends at the kernel borders, he has little influence outside. The Linux desktop also needs a dictator to massively slow down the rate of uncoordinated changes and force-stabilize the ecosystem. I hoped that Mark Shuttleworth could be that man, but he then introduced Unity... but even with unity, Ubuntu is the only chance for the Linux desktop for having a single defined set of libs attractive and influential enough for app devs as a primary target so they can safely go with the library versions in Ubuntu, instead of constantly chasing the latest and greatest versions from the upstream.

16s 15y ago

I got a good laugh from this quote: "[Linux] is not some crazy drug-induced microkernel"

stargazer83 15y ago
All these years later, the flame goes on :p
ot 15y ago
That sentence is a betrayal of UNIX's history: There are two major products that came out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. (Jeremy S. Anderson)
- mapleoin 15y ago
  I think it rather refers to MINIX.
  - Lozzer 15y ago
    More likely HURD
    - dfc 15y ago
      No, it was tanenbaum and minix.
  - abrahamsen 15y ago
    More specifically, it most likely refers to this discussion: http://groups.google.com/group/comp.os.minix/browse_frm/thread/c25870d7a41696d2/f447530d082cd95d?#f447530d082cd95d http://groups.google.com/group/comp.os.minix/browse_frm/thre... Linus was a kid in 1992, and got scolded by one of the greatest icons of the field. That could still sting 20 years later.
    - sixbrx 15y ago
      I always thought Linus gave better than he got in that argument, myself. He was pretty brutal to Minix in a couple of places. BTW. love the reference to "BSD detox" somewhere in that thread, it always gives me a chuckle.

oxxx 15y ago

aptwebapps 15y ago

An easy way to read the whole thread: http://markmail.org/thread/wwi2aynfiliqanil http://markmail.org/thread/wwi2aynfiliqanil I don't understand why Mark Mail doesn't get more love. I wish they had better SEO or something, it's so much easier to read a long thread on their site then most mailing list archives.

michaelmior 15y ago
Here's a link to the actual message referenced by the submission http://markmail.org/message/d4dfw53uqwhdj24i http://markmail.org/message/d4dfw53uqwhdj24i
mrud 15y ago
I don't like it because it seems to have no threaded view. I really like gmane much more for mailing list discussions - http://thread.gmane.org/gmane.linux.kernel/1245999/focus=1264170 http://thread.gmane.org/gmane.linux.kernel/1245999/focus=126...
- aptwebapps 15y ago
  Yeah, that is nice. Either one is a vast improvement over old-style list archives.
  - dredmorbius 15y ago
    mbox and your own damned client.
    - aptwebapps 15y ago
      If you happen to already be subscribed to the mailing list in question, sure.
      - dredmorbius 15y ago
        There are list archives which provide mbox format archives. Mailman for example.

4ad 15y ago

It's great that Linus is committed to supporting old binaries, too bad all that effort is in vain because of the glibc disaster. Linux can run statically compiled binaries from 1993, but not the Firefox binaries from 2006.

aniket_ray 15y ago
Yeah, the gnu libc and libstdc++ projects have been particularly bad at maintaining ABI compatibility.
malkia 15y ago
wouldn't it be possible to still run them with some LD_xxx magic where the c++ shared libs are put in some folder and loaded from there? (It's really userspace problem).
- A1kmm 15y ago
  Yes - I've done that to produce more portable Linux binary installers where static binaries would have caused other problems - I tested it for backwards compatibility, but hopefully it will also improve forward compatibility. One problem that you encounter if you do that is that glibc has an option to disable support for older kernels in exchange for better performance, so you lose backwards compatibility unless you are very careful about how you compile glibc (it fails with an error that the kernel is too old).

tete 15y ago

[Here the post in case the site is down...] On Thu, Mar 8, 2012 at 2:18 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Keeping compatibility is easy enough that it looks like it is worth doing, but maintaining 30+ years of backwards compatibility Stop right there. This is not about some arbitrary "30-year backwards compatibility". This is about your patch BREAKING EXISTING BINARIES. So stop the f* &^ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than any of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. Binary compatibility is so important that I do not want to have anything to do with kernel developers who don't understand that importance. If you continue to pooh-pooh the issue, you only show yourself to be unreliable. Don't do it. Dammit, I'm continually surprised by the idiots out there that don't understand that binary compatibility is one of the absolute top priorities. The only reason for an OS kernel existing in the first place is to serve user-space. The kernel has no relevance on its own. Breaking existing binaries - and then not acknowledging how horribly bad that was - is just about the worst offense any kernel developer can do. Because that shows that they don't understand what the whole point of the kernel was after all. We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really. Linus

famousactress 15y ago

Linus is very consistent when it comes to these things. A similar thread from a while back: http://news.ycombinator.com/item?id=2372096 http://news.ycombinator.com/item?id=2372096

dustingetz 15y ago

the full context of the quote provoking Linus's rant is extremely relevant here: The current counting that we do gives the wrong numbers, in the edge cases. To my knowledge a deleted sysfs directory has never returned nlink == 0. Keeping compatibility is easy enough that it looks like it is worth doing, but maintaining 30+ years of backwards compatibility is what nlink >1 in unix filesystem directories is. I don't see any practical sense in keeping . and .. directories on disk or upping the unix nlink directory count because of them. To me it looks like just one of those things you do. Like hash directory entries so you can have a big directory and still be able to have a 32bit offset you can pass to lseek that is stable across renames and deletes. to use PG's terms, Linus is arguing against this at DH0 or maybe DH1 here[1]. Maybe the above argument sucks, but Linus didn't refute it at all. [1] http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html

icebraining 15y ago
I disagree. He refuted the premise that breaking backward compatibility is OK under certain conditions, because "the only reason for an OS kernel existing in the first place is to serve user-space." That alone refutes the whole argument.

jonhohle 15y ago

> Programs exist for their users While this may be inferred from this discussion, this is not what Linus said in this thread. He actually said: > The *only* reason for an OS kernel existing in the > first place is to serve user-space. This is a much narrower definition without the philosophical implications of the title. Sometimes programs don't exist for their users. Take DRM for example - it is explicitly against the user.

ahelwer 15y ago
The DRM user is the publisher, not the user of the program itself.
- jonhohle 15y ago
  I disagree. The Publisher in this case is the programmer - or at least distributor - of the program. Content consumers are the intended user.
  - namdnay 15y ago
    I have to disagree with you there, clearly the user of DRM is the copyright holder. They are using the tool to perform their activity, that of "safely" leasing their content to consumers. In the same way, the user of DirectX is the game publisher, not the consumer who buys the game.
    - jonhohle 15y ago
      I am my DVD player's user. The copyright holder does not come to my house to operate my DVD player. It will not allow me to play discs not encoded for my region. This program is not written for my preference or use, but in opposition to me. It also does not allow me to bypass certain segments of videos. Again - it opposes me. If it was written for me - the user - it would allow me to bypass all content and jump directly to the first title of every disc I inserted. The producers of this software have explicitly made it hostile to the user. I'm not saying this is not within their rights - I'm just saying it is. But this is a rat hole. My point was that this is not what Linus was saying. He was merely describing the purpose of one software component. A kernel is a hardware abstraction - a platform for building applications without concern for the details of components - including the version of the kernel itself. He was arguing against breaking that contract by introducing a change which fit the whims of the contributor but would break an unknown number of binaries compiled against that contract. tl;dr - "user" is not the same as "user-space"

cpeterso 15y ago

In contrast, here is a thread about Debian, after much deliberation, unanimously choosing to break kernel ABI compatibility with VMware. They didn't want to increase the ABI number during a "freeze", even though they broke the ABI. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607368 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607368

danudey 15y ago
While I disagree, in the end, about breaking user applications, I can appreciate their situation. They have an upstream kernel from which they get bugfixes and patches, but which has no guarantees of stability. Any guarantees that the Debian team decides to make are their own responsibility, and could result in them maintaining multiple patches just to fix ever-more-diverging upstream releases.
lambda 15y ago
That's the difference between the user-space interface, and the kernel ABI. The Linux kernel ABI has no compatibility guarantees. If you are linking to the kernel, you are considered to be part of the kernel, and thus you are expected to keep abreast of any ABI changes (preferably by getting your module into the kernel tree, so that anyone changing the ABI can fix your code too). The Debian kernel team tries to do a reasonable job of tracking kernel ABI compatibility changes, and updating the number when the ABI does change, to avoid having to recompile and reinstall everything for every patch to the stable tree. In this case, they decided that the ABI change was only intended for a single, in-tree module (KVM), and that they didn't have to increment the ABI number for a change that shouldn't affect anything else. This is really just an example of the Linux kernel developers' two approaches to compatibility. For the kernel ABI, they make no guarantees whatsoever about compatibility. For the user space interface, they are supposed to never, ever change the interface in ways that will break existing programs, though there are sometimes disagreements about what precisely constitutes this interface and what is outside the bounds of it.
namdnay 15y ago
Slightly off-topic, but often when reading these mailing lists I find some developers to be rather unhelpful, if not downright nasty. Take this example. Now I realise this isn't a company-client relationship we're looking at, but am I alone in thinking a bit more diplomacy wouldn't have gone amiss?

rogerclark 15y ago

that guy is such a turd

caycep 15y ago

This is straight out of the original Tron!

evanlong 15y ago

Come on people the future is node.js and MongoDB. WE DON'T NEED KERNELS!!! Async programming IS JUST SO MUCH FASTER!!!

lninyo 15y ago

Just as masturbatory a discussion as expected. Well done gentlemen.