1. 47
  1.  

  2. 32

    His stance is laid out more clearly later in the thread.

    People should basically always feel like they can update their kernel and simply not have to worry about it.

    I refuse to introduce “you can only update the kernel if you also update that other program” kind of limitations. If the kernel used to work for you, the rule is that it continues to work for you.

    And I seriously will refuse to take code from people who do not understand and honor this very simple rule.

    1. 23

      Also relevant is John Johansen’s response.

      1. 29

        What a difference between his first post and this one. In the first one he comes off like a colossally toxic asshat. I know this is no surprise to anyway, but still. That kind of behavior is not OK. Period.

        This post on the other hand is clear headed and explanatory. It lays out the rules and why it’s important to follow them.

        Maybe Linus just needs a 1h send buffer? :)

        1. 2

          “That behavior is not OK” is equivalent to “I am offended”, for this case.

          For all types of behavior, you can always find someone that thinks it is not OK. Should it matter? It would be severly limiting for everyone on a place like the Internet.

          1. 19

            It’s not “I am offended”, but rather probably 95% of people would be offended if they would hear something like this headed their way. Linus probably forgot how it’s like to hear this level of toxic communication because nobody speaks with him like that. I know his “ideology” behind his behavior (he talked about this several times), but honestly saying such “sh**” to people is low, and most people are above that, that’s why he stands out.

            1. 3

              Personally this power relationship is why I’m against BDFLs once a project reaches a certain size.

              1. 1

                I agree in principle. In practice I have to wonder - what are the alternatives? Design by committee has some well known flaws :)

              2. -1

                Do you even know what toxic means ?

                1. 8

                  Toxic means that it is in some way damaging to a relationship between two individuals, groups, etc. In this case it is indeed toxic because it seeks to gain in some goal at the cost of the relationship with the submitters. Toxic isn’t strictly bad, sometimes a goal is so important that you need to break the relationship, however you should always choose the least toxic strategy that will ensure success. After all who knows when you’re going to need those people’s help in the future.

                  In summary, dark_grimoire seems to have a correct understanding of toxic, and mytrile does not which I assume is why they are being downvoted.

              3. 22

                It would be severly limiting

                It’s already limiting though – many people silently stop contributing when they receive messages like this or never consider contributing in the first place. This means the negative impact is hidden. Since it’s hidden, it becomes much easier to defend the status quo when an alternative might result in a better kernel.

                1. 6

                  By the same logic, the positive impact is also hidden. Because it is conceivable that without these messages, the kernel might have imploded upon itself, and the prevention of said implosion is doubtlessly positive.

                  If you are going to argue with hidden stuff then it goes both ways.

                  1. 10

                    Do you really believe that it’s not possible to enforce rules and maintain high standards without calling people idiots, their contributions garbage, and so on?

                    I can certainly believe the parent comment, as it’s something I hear regularly, from people who decide not to get involved in projects/make further contributions/pursue opportunities at companies/etc because of things like this. FWIW, one of my friends can be found in the kernel CREDITS, and decided to walk away because of the LKML.

                    1. 6

                      it is conceivable that without these messages, the kernel might have imploded upon itself

                      As a counterpoint, I’ve worked on a project that has a similar code size, customer reach, and zero-tolerance stance on security and stability bugs as the Linux kernel: Chromium. Chromium does not have anywhere near the level of abusive discourse on its mailing list as the LKML, and it has not imploded on itself as you have suggested. So the burden of proof is on the abusive language to show it is needed and not the other way around.

                  2. 7

                    I disagree. I am not offended by his behavior, I find it to be unacceptable by virtue of the fact that I feel human beings should treat each other with a modicum of respect. Linus’s communications very often do not meet that standard. Hence from my book they do not represent an acceptable way to treat people, especially people volunteering to donate time to an open source project.

                  3. -5

                    Who are you to say what’s OK?

                    1. 16

                      He can certainly say what’s OK and NOT OK in his opinion.

                2. 25

                  Mercurial, made by another (in my opinion) much more well-spoken kernel hacker, is what really introduced me to the concept that you do not break interface for downstream users, no matter how wrongly you may think they are using the interface.

                  It’s an attitude that is difficult to convey because software developers always want to have the freedom to “improve” their own software, even at the possible cost of breaking something for some users (and worse, even telling users that they shouldn’t have been doing that in the first place).

                  I keep going back to this blog post which I wish more people agreed with (Steve Losh is another person influenced by Mercurial):

                  http://stevelosh.com/blog/2012/04/volatile-software/

                  1. 4

                    Good write-up. And, yet, backward compatibility is the reason for most woes of IBM/COBOL and Wintel. Both improved their stacks a lot by creating incompatible additions. On IBM’s side, they added stuff from UNIX ecosystem. On Microsoft’s side, they broke the driver model and permission model after switching to managed code for lots of apps. The author you linked to could’ve written a similar piece on Vista as almost everyone did. Although they did botch execution of it, the key, painful changes that were polished up by Windows 7 were great for the long term in both reliability, security, and (.NET) maintainability getting off C++. Just the driver architecture and verifier alone eliminated most blue screens.

                    Note that what I described doesn’t mean changing things randomly and unnecessarily which cause a lot of what author describes. The companies doing high-availability software often create deltas in between that support old functionality/configurations and new ones. Optionally tools to convert between them manually or automatically. Then, the upgrade doesn’t have unplanned downtime or headaches. Minimal at least. We don’t see most proprietary or FOSS software doing that. Instead, it’s “Surprise! Your stuff is now broken!”

                    The other thing to address is the author writes as if developers owe the users something. There’s some moral imperative. There are FOSS developers out there who are fairly selfless in that they’re all about the experience of their users. Many aren’t, though.They might be working for corporations such as Red Hat or IBM contributing to Linux. They might be building something mainly for themselves or a small group of contributors that they share with the world. They might even be building a product with a somewhat-neglected, FOSS version with less features. In any case, most of the users will be freeloaders who the developers are not working for or value very little. If those people are having problems, the developers with such motivations should ignore them.

                    So, I’d ask whether the Skype developers were trying to create a fantastic experience for Steve Losh on his new box or were doing what their managers wanted for the product for whatever reasons the business had. I’m leaning toward the latter which reframes his gripe about them. Maybe similar with the others. They also maybe well-intentioned but sloppy as he says. Who knows. Just not as simple as all developers having a moral imperative to create a specific experience for specific or all users.

                    1. 3

                      “And, yet, backward compatibility is the reason for most woes of IBM/COBOL and Wintel.”

                      I’m no kernel expert, but I think what Linus means about no regressions/don’t change the interface is only referring to minor versions, major versions of the kernel are allowed to change the API?

                      1. 7

                        I’m no kernel expert, but I think what Linus means about no regressions/don’t change the interface is only referring to minor versions, major versions of the kernel are allowed to change the API?

                        No. The kernel’s public API is supposed to be backwards compatible even between major versions. From https://github.com/torvalds/linux/tree/master/Documentation/ABI :

                        Most interfaces (like syscalls) are expected to never change and always be available.

                        1. 1

                          How did you get “Active user with invites disabled” on your profile?

                          1. 1

                            How did you get “Active user with invites disabled” on your profile?

                            By inviting each and every user that asked for an invite through the website form. This must have upset the gatekeepers who decided that since some of those were spammers (probably the self-promotion type) I need to have my inviting rights revoked.

                        2. 4

                          Linus has made it clear that version numbers of the kernel mean nothing and are entirely arbitrary. In his last interview(https://www.youtube.com/watch?v=NLQZzEvavGs&feature=share) He makes it VERY plain this is the case. He said basically that after the minor numbers get into the double digits he starts to lose track and bumps the major number. So we should hit 5.0 around next summer, but he made zero promises of this.

                          1. 4

                            See this other thread. You need to click “Show 89 previous comments” because Google+ seems to be unable to link to specific comments.

                            Alan Cox (a kernel hacker) writes “my 3.6rc kernel will still run a Rogue binary built in 1992. X is back compatible to apps far older than Linux.” and I would assume it still runs today.

                            And below Alan is Linus ranting about Gnome breaking stuff all the time.

                            1. 4

                              To add to what @stefantalpalaru said, actually in Linux version numbers mean not much. They’re added to distinguish between versions, and the major version number changes every time Linus thinks the minor version numbers are getting too big.

                              1. 1

                                I was replying to the linked article.

                          2. 5

                            How are other kernels managed?

                            Doesn’t never “breaking compatibility” result in accumulating “technical debt”?

                            What would it take for user space stuff to adapt to changes in a kernel’s API?

                            1. 9

                              Other OS’s have ABI versioning and the userspace matches that.

                              1. 9

                                FreeBSD is allowed to break ABI in a new major release. Compatibility layers are provided for old binaries (down to 4.x!) and they work… when reasonable — right now in -CURRENT every <=11.x binary that touches stat and dirent is kinda screwed thanks to 64-bit inodes.

                                OpenBSD, IIRC, doesn’t have any compatibility layers or even minor releases. New release — new ABI, recompile your crap.

                                1. 2

                                  That’s sad. I really like the backwards compatibility that FreeBSD and NetBSD provide.

                                  1. 7

                                    What is sad about getting a new set of binaries every 6 months?

                                    1. 6

                                      Christos (from NetBSD) was really into binary compatibility (among other things) and he used Franz Lisp compiled for NetBSD 0.9 in 1994 (http://www.aiai.ed.ac.uk/~jeff/franz-for-386.html) to test NetBSD’s binary compatibility over the years. Last time I saw him reporting success was around NetBSD 4.0. If he continued this work, Franz Lisp is likely still running, unchanged, 20 years later.

                                      I think that’s something to be proud of.

                                      1. 4

                                        Having to manually adjust hard-coded information about syscalls in languages like Go every 6 months or risk your programs failing at run-time

                                        1. 3

                                          syscalls will usually be given at least 2 releases cycles (12 months) to phase out.

                                          But such problems do happen sometimes, indeed. However, if there’s a process in place to deal with such changes on a regular basis, they can be dealt with more easily than if they only happen once in a decade, making everyone forget how to best transition to a new ABI.

                                  2. 8

                                    On Darwin (macOS/iOS/…), the syscall boundary isn’t considered ABI. Rather there’s a libsystem_kernel.dylib that provides the userspace system call stubs and the functions exported there define the ABI. This allows lockstep kernel/user changes and userspace can use symbol versioning or other tricks to keep old software working.

                                    1. 3

                                      Windows does this too, though it’s just one of the numerous schemes (of varying insanity) to avoid breaking userland.

                                    2. 5

                                      I don’t know about kernels, but

                                      Doesn’t never “breaking compatibility” result in accumulating “technical debt”?
                                      

                                      isn’t true in a wider scope, you can just mark a method as deprecated and add a new method instead that does what you want. Then there’s some deprecation policy that’ll let you remove the old code eventually. You have to tolerate the debt for the period of the policy.

                                      I think we as developers really hate that once we create an API we’re locked into it. It really annoys us, but when you write an API, you’ve made a contract and you’ve got to deal.

                                      This is why I avoid working on APIs ;)

                                      1. 7

                                        Or you can add longer and longer calls to sleep() below the deprecation message: https://twitter.com/johnregehr/status/920691341738123264

                                      2. 4

                                        Doesn’t never “breaking compatibility” result in accumulating “technical debt”?

                                        Yes, it does. There are numerous system calls (i.e. mmap2 or statx) which should be used instead of older system calls but remain “optional.” It’s not as much of a problem as one might think, however. A lot of new functionality is instead implemented as a file (although /proc is fairly crufty itself) or as an ioctl.