Slashdot Mirror
Linus Torvalds Suspends Key Linux Developer
alphadogg writes: "An argument between developers of some of the most basic parts of Linux turned heated this week, resulting in a prominent Red Hat employee and code contributor being banned from working on the Linux kernel. Kay Sievers, a well-known open-source software engineer, is a key developer of systemd, a system management framework for Linux-based operating systems. Systemd is currently used by several prominent Linux distributions, including two of the most prominent enterprise distros, Red Hat and SUSE. It was recently announced that Ubuntu would adopt systemd in future versions as well. Sievers was banned by kernel maintainer Linus Torvalds on Wednesday for failing to address an issue that caused systemd to interact with the Linux kernel in negative ways."
Time for that boy to move along and let someone with fresh ideas take over.
- oh yeah, fresh ideas like: "you didn't build that".
Fresh ideas like: "the consumer created those jobs".
Fresh ideas like: "all responsibility is shared".
----
I think Linus is 100% spot on with his comment:
Key, I'm f*cking tired of the fact that you don't fix problems in the ....
code *you* write, so that the kernel then has to work around the
problems you cause.
But I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project. Because I am *not* willing to take patches from people who don't clean up after their problems, and don't admit that it's their problem to fix.
Kay - one more time: you caused the problem, you need to fix it. None of this "I can do whatever I want, others have to clean up after me" crap. .....
Linus
You can't handle the truth.
"I'm not accepting any patches until you fix your bugs" is hardly suspending someone, it's re-focusing them. This is an important part in any software project, and Linus is doing it well here. There's no ambiguity or hyperbole, just straightforward communication identifying issues and prompting action to correct them.
"Start fixing your shit" isn't even remotely the same thing as "stop doing things".
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
First the idea of "Suspending" a kernel developer is inane. Kernel developers don't work for Linus. Anyone can fork the kernel and work on his own version of it. Furthermore, Kay can write code that other people audit, modify and submit further.
Secondly, it's not an 'indefinite, unconditional ban' as suggested by the summary. Here's the specific line from Linus' email:
Greg - just for your information, I will *not* be merging any code
from Kay into the kernel until this constant pattern is fixed.
In other words he might start accepting patches from him if he changed his style of operating.
From the previous message in the thread, to which Linus was reacting:
It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line. What happens is that the user space tool parses the
kernel command line, and if it sees "debug" it will spit out so much
information that the system fails to boot. This basically renders the
"debug" option for the kernel useless.
This bug has been reported to the developers of said tool
here:
https://bugs.freedesktop.org/s...
The response is:
"Generic terms are generic, not the first user owns them."
That is, the "debug" statement on the *kernel* command line is not
owned by the kernel just because it was the first user of it, and
they refuse to fix their bug.
I don't care if Kay wrote "Jesus 2.0". He broke kernel debugging for all development and responded to this with arrogant platitudes based on architecture principle, rather than join with cooperative interest to seek a solution.
Linus was restrained, in response to such a "community contributor". This is the Linux kernel, not Oxford dons, vying for college chairs.
"Flyin' in just a sweet place,
Never been known to fail..."
Here is the actual bug and arguement: https://bugs.freedesktop.org/s...
Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.
Because the code that needs "fixing" is in systemd, not in the Linux codebase. therefore Linus cannot revert.
Signature v3.0, now with 42% less memory usage.
because it's a bug in *systemd*, not in the kernel, but it prevents the kernel from loading in debug mode.
The message to which Linus responds is also interesting:
Short story:
The systemd guy uses the debug keyword on kernel command line to spool a huge log - which can hang the boot process, and that is the problem.
Then the same guy claims that the debug keyword is generic so it can't be reserved by the kernel, even if it's been used first by it since a long time...
I can say that Linus is right there, for sure. He's maybe too kind...
They just aren't accepting code from him until he fixes that issue. The summary makes it sound much more dramtic than it really is.
His problem is that he believes he is right in all things and has a huge ego.
Here's the thing: in this case, Linus is definitely right, and Kay is definitely being dickish. Namespacing the switch (checking for "systemd.debug" instead of just "debug") would take all of 5 minutes and would solve the problem, the only inconvenience would be to the systemd developers who would need 8 (!) extra characters on their kernel command lines. Acceptance of systemd is already lower than it should be if everyone judged it purely on the merits, and this kind of thing does not help at all.
Let's take a step back and consider what systemd has given us compared to what we had before.
Before systemd, configuring what gets started on Linux systems was standard across all distributions, dating back to before 1995, when I started developing software with Linux. There was /etc/rc.d/init.d or in some cases /etc/init.d and in most cases there were links in rc1.d, rc2.d, rc3.d, etc. It was that simple. Nothing ever broke.
With systemd, a solution in search of a problem, everything changed. Now you have all of these directory hierarchies and countless old bugs that take years to get resolved. For example, "network restart" was broken in Fedora for ages for a machine of mine with one DHCP Ethernet interface and two static Ethernet interfaces (with nothing fancy like wireless). "network restart" fails on a variety of machines I have access to; forget about "network reload." ifcfg-eth0 and the like are simple things, some of the most basic boot-related operations. I've tried to open bugs but the problem seems to be buried somewhere in the guts of systemd.
I've had systems rendered unbootable during upgrades because of silent failures trying to make a good initrd. It's too complex to get everything right with systemd. For a long, long time when the boot scripts died with systemd there was no obvious way to see any errors. Recently they added some more debugging output suggesting that you use journalctl. Why didn't they tell us about that earlier? The reason? No documentation. They wrote an entirely new way to boot the system but kept the design in their heads. Maybe, many years later, there is some scant documentation available (except for that one old useless design document justifying systemd's existence that everyone has read). Of course, nobody writes man pages anymore but they were sure to remove the man pages for the old boot system.
So what new things does systemd give us? Pretty much nothing except for bugs. Maybe there are a few oddball use cases like booting off of weird media, but most people today boot off of a fixed hard drive that doesn't change in years. 19 years later it might be an SSD, but that is the same use case.
Kay's been a kernel developer for years, and has clashed with Linux many times in the past, all for the same reasons: Kay patches something, breaks a lot of things, says everyone else has to fix their code to work around the things he broke as it's "not his problem". Linux has finally had enough of that attitude.
I read the mailing list thread as well as the bugzilla report...Kay certainly was certainly being a complete dick here. Too many people will see this as "an asshole being an asshole" w/respect to Linus, but he actually had a reason [this time, lol].
Well, if Kay doesn't want to fix it, why doesn't Linus simply revert his buggy commit/branch?
I don't understand.
Because having "debug" on the kernel command line has worked for years/decades with the Linux kernel, and now suddently systemD is doing something /proc/cmdline that causes systems to stop booting when it is present.
Nothing is broken with the kernel: it boots, finds devices, and starts PID 1. It's only when systemD is PID 1 that having "debug" causes a problem. The change occurred with systemD, and so the reversion should occur with systemD because it breaks backwards compatibility with a well-known API (in this case the the kernel "CLI").
I used to work with a guy who was a MS kernel hacker. He knew the debugger setup in all it's arcanity backwards and forwards, and had a lot of code knowledge there too, despite never working at MS. It was great fun to watch IT try to manage his machine through normal tools (to push updates and reboots and whatnot). He was having none of that, but he wasn't going to pick a fight with IT, instead he just ensured that the IT client tools were kept happy, that the kernel always told them what they needed to hear.
Never pick a geek-fight on a machine that your opponent has a kernel debugger attached to. Ahh, old-school hacking. How I miss the art.
Socialism: a lie told by totalitarians and believed by fools.
Another response from Linus...
http://lkml.iu.edu//hypermail/...
Whoever marked this as off topic didn't read the source material. This comment was really quite funny!
But hey, a hater has to hate, eh?
And a fanboy has to worship.
If Jobs was so great then why did NeXT, a company completely controlled by Jobs, do so poorly?
According to this article the decision on iPod for Windows came about exactly as I described. From the article:
"We argued with Steve a bunch [about putting iTunes on Windows], and he said no," Rubenstein recalls. "Finally, Phil Schiller and I said 'we're going to do it.' And Steve said, 'F#@k you guys, do whatever you want. You're responsible.' And he stormed out of the room."
That does not sound like Jobs changed his mind. Schiller and Rubenstein did it in spite of what Jobs wanted.
Jobs was brilliant but not perfect. Jobs combined with a strong Board that can override some of his decisions is why Apple did so well. With Jobs alone you get NeXT; a failure.
> Yea, but if you mess up and do something he declares "STUPID"
And if HE messes up he calls it moronic.
http://lkml.iu.edu//hypermail/...
And Linus isn't afraid to admit something is complex.
http://lkml.iu.edu//hypermail/...
He can, but they're tired of Kay breaking other portions of the system by making changes to the specific program he develops. Kay then will tell people to submit a patch to fix it since his program is working the way he wants, even if it is breaking other things by not following an established method. This has been going on for years. In this case he broke a system that has worked fine for decades and sees it at someone else's problem. It will get fixed by someone else and Kay has been suspended from sending in more system breaking changes, but if Kay was willing to clean up his own mess for once, people wouldn't be so upset with him.