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."
And this is good.
Quote from the Linus email:
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.
Being Kay a Red Hat paid developer, perhaps it's not his entirely fault what's happening. But it's his name on the table, so it's his responsability nevertheless.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
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 would have gotten first post if I wasn't running both the base kernel’s debugging routine and that of systemd.
"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
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..."
Kay is either an arrogant asshat or an aspberger's victim. Either way, he hasn't demonstrated an interest in collaborating on a solution for the whole forest, over the pure vision of his one, true tree.
Without Linus, Linux is doomed.
"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.
who runs Linux these days?
Linux is 25 years old now. You don't run it, you walk it slowly with a leash and let it have a pee on the front lawn.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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...
Linus is generally fair from what I can tell, and does not except himself from criticism. In that very thread:
Yeah, what Andrew said. My suggestion of per-task or per-cred is
obviously moronic in comparison.
Linus "hangs head in shame" Torvalds
Someone proposed a better idea and Linus immediately admits his idea was worse and moves on. That was also one of Steve Jobs' greatest talents, even though it's in a completely different sphere. He originally said "no" to iPods for Windows and the iOS app store. People presented their case and he changed his mind.
We should all be so willing to admit when someone else has a better idea or we were wrong.
Natural != (nontoxic || beneficial)
I sometimes run Linux and sometimes run Windows. Why? Because it's nice for my OS to piss me off in different ways instead of always the same ways. :-)
For those of us lacking in perspective on how Fun! kernel debugging is, here is a voice from the MS side of things. Dangerous curveballs ahead.
http://research.microsoft.com/en-us/people/mickens/thenightwatch.pdf
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 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/...
Systemd replaces init and is the first daemon to start up in user space during boot and the last daemon to shut down. When its developer sees nothing wrong with breaking the kernel debug during boot merely because its developer feels that he's entitled to use the same parameter name and the kernel boot be damned, you REALLY have to wonder about the wisdom of using systemd.