Linus Torvalds vs Kay Sievers
 

For those of you who enjoy tracking kernel development occasionally, take a look at this thread, especially Linus' response. You can also get the link to the freedesktop.org bug report where additional light may be shed.
http://lkml.iu.edu//hypermail/linux/...4.0/01327.html

Can't say I'm surprised.

First, the systemd team decided to interfere with the way servers are managed, but they couldn't be bothered to listen to anybody who actually does this for a living. Now, they've decided to make life difficult for kernel developers as well, also without knowing anything about how they work, and as a result they seem to have pissed off just about every kernel developer on the planet, including Linus Torvalds.

Having systemd grab the kernel command line and respond to a "debug" instruction obviously meant for the kernel, means nobody read the kernel documentation. That's bad. That systemd then proceeds to generate so much debug output that it causes a kernel panic indicates a stunning level of incompetence on the part of the systemd developers. That's pretty horrible.

But responding to bug reports by saying 'just because the Linux kernel used "debug" first doesn't mean they own it, so it's not our problem' is just asinine. Seriously? I mean, why don't they intercept the SysReq key while they're at it.

It's not like it's the first time the systemd team have shown zero interest in fixing serious bugs. Richard Weinberger pointed out that the "cgroups bug", which causes systemd to segfault if the kernel is compiled with CONFIG_CGROUPS=n, no only hasn't been fixed, but that Lennart Poettering can't be bothered to look at it because "nobody of us tests this". Well, yes, WE'VE NOTICED!

:p quiet dammit - they'll hear you .... :doh:
Gotta love reading this stuff first thing in the morning - thanks for making my day.

Reading this lkml thread made my day. Thanks for the heads up. After http://www.linuxquestions.org/questi...og-4175500254/ and this thread, I can't imagine anything cheering me up more. Talk about irony!

I do hope Linus T. takes a firm stand against these a*holes, as he has here. I'm sure he can do something to at least stall them. Maybe it'll give enough time to people developing alternatives.

I kind of see it as inevitable ATM tho. I don't know how these self-appointed a*holes managed to hijack and infiltrate so many projects, but I hope someone stops them or at least slows them down.

When I get some money, I think I'll hire some developers to develop a much better and more sensible alternative, with advice from the leading devs of the respective projects. It'll be FLOSS of course. I'm not much of a developer, so I can't do it myself. I know that system V init works just fine, but people don't want it anymore, so something else has to be developed at least to prevent these a*holes from handling it the way they do and will continue to do.

*Sits back with popcorn*

Looks like kdbus just got the guillotine.

In truth, all the projects that have been forcefully deprecated by systemd, now need to be restarted ASAP. I doubt Linus T. is going to allow Kay and Lennart to have their way over this ever growing mountain of buggy code they keep piling up.

You piss off the kernel developers and you might as well put a loaded bazooka to your head and fire.

I think Linus is more than regretting letting Kay and Lennart's trash anywhere in GNU/Linux. I'd die laughing if their entire history of code from udev and all got the axe from Linux and they restarted all the old projects like DevFS, HAL, Hotplug and such up again.

I don't even think a comment is needed there.

I have faith in Linus.

With Redhat, Suse, Debian (and thus Canonical) backing systemd ?. Where are you going to get the developers - and how long to get back up to speed ?.
Linux development (including the kernel) has been "facilitated" by the corporations for so long now it's too late to turn back.

The FOSS community doesn't blindly have to drink the kool-aid being shoved in their hands. These projects were only forced into deprecation by people simply stating they were deprecated, not because the code was old, stale, and less than usefully pointless.

OSS/Free is what you can call truly deprecated code. Against ALSA and OSSv4, OSS/Free is completely pointless. I'm not saying someone out there isn't using it, but it is truly deprecated code. Saying ConsoleKit and other modular projects are deprecated against systemd is about as big a lie you could say compared against the popularity of the Star Wars franchise.

Gentoo was the only distribution that actually has stood up to systemd and offered eudev as an alternative to systemd-udev. Slackware and LFS also have stood up to at least say they can get along with out it as long as possible, but everyone else is lining up for their RFID chips, bar codes, uniforms, and cups of kool-aid.

Linux development may have been facilitated by corporations, but government agencies, laboratories, universities, and even private individuals have done their fair share too.

11% kernel development is private individuals
more then any company
(data from... 2011 i think, can't remember)

in the rest of linux id guess the percentage is bigger

double post, internets broke

If you are interested in where kernel patches come from check out:
http://lwn.net/Articles/589728/

For now LWN is still posting statistics on each kernel, but may change the frequency as mentioned at the end of the article.

wrong thread ><

While I don't appreciate the behavior of some systemd developers and I am definitely not a fan of it, this bothers me:
A kernel crash due to too much output is a bug in the kernel, not systemd or any other userspace application. After all, systemd is userspace and according to Linus Torvalds userspace should never be able to crash the kernel.

Also, letting this impact the development of the first sane IPC mechanism for Linux (that will bring the Linux kernel on par with any other UNIX kernel and even the Windows kernel) is IMHO a bad thing. Of course developers with such attitudes should be monitored (or temporarily be banned from committing patches) until the problem is fixed, but that should not have an impact on making Linux better.

Remember, this only occurs when the kernel is given the "debug" parameter. Debug mode is not a normal operating condition for the kernel by any stretch of the imagination, and may indeed create an unusual dependency with the tty layer. That's basically what it's supposed to do.

I put the blame squarely on the systemd developers for failing to distinguish between "debug" and, say, "systemd.debug". Everybody else seems perfectly capable of doing just that, as even a cursory glance at the kernel documentaion will show.

Even if systemd was perfect and dbus was the best thing since sliced bread, it would be a mistake to trust such a grossly mismanaged project with providing important functionality to Linux in general.

Add to that the undeniable fact that the two senior (I'm using the term in the most loosely possible manner) developers are unwilling to listen to any viewpoint that conflicts with their own, and are demonstrably reluctant to fix their own crash bugs, and you get a perfect storm. This isn't going to end well.

I think Linus gets to the point build right or get out of the way. http://lkml.iu.edu//hypermail/linux/...4.0/01488.html

It doesn't matter if it is in debug mode or not, it is still a problem in the kernel, not any other software.
Indeed, a really weird behavior, Greg Kroah-Hartman has already announced on the LKML that he will fix that, it will indeed be systemd.debug.

systemd is not relevant for kdbus.
kdbus != dbus.
AFAIK, most of kdbus is implemented GKH, but you are right, those patches have to be reviewed extensively, but for such an important part of a kernel as IPC I would recommend that anyway.
I don't hope so, having good IPC is really something the whole Linux ecosystem can benefit from. But only time can tell.

fact remains that in 20 years no other program broke it
including the kernel itself

If you're asking the kernel to do "X" inside core kernel functions, and then prevent it from doing so by having a userspace program running as root block access to resources needed to do "X", is the kernel wrong/broken for crashing? Anybody with root privileges can crash any kernel in seconds. That's by design, and certainly not a kernel bug.

There was a discussion (just finished) on the LKML about this, and one suggestion was to simply remove userspace access to /dev/kmsg altogether. After all, it's the kernel log; why should applications be able to write to it at all? It would have been a sensible move, and would have utterly broken the debug facility in systemd. (Not that it would have mattered, as it's obvious that the feature wasn't being used since neither Kay nor Lennart had noticed that it would crash the entire kernel.)

In defense of allowing userspace access to /dev/kmsg, Theodore Ts'o also pointed out that it was never supposed to be a syslog replacement, which I found hilarious since the program that caused this problem in the first place by abusing the hell out of /dev/kmsg IS intended to be a syslog replacement.

In the end they ended up rate-limiting /dev/kmsg, to prevent any program from flooding the log. I guess now the systemd team will claim it was a kernel issue all along. Linus expressed hopes this was all caused by incompetence, but others weren't entirely convinced.

/dev/kmsg is supposed to act as log, even if it is not syslog, it shouldn't crash because it is logging. That it is the first time that a software crashes it by spamming doesn't matter, it still is a bug. I bet there are other bugs in the kernel that are not detected that are in a similar range of age, but that doesn't change the bug status.

Tobi if systemd is userland but is forcing a kernel crash through output generation, isn't that along the same lines as a major security flaw like a backdoor, memory leak, or other permission level elevation issue? Couldn't someone remote into a system and then use this parameter of systemd to bring down a system?

And BTW... sliced bread is not the best thing to have ever came along. Ethyl Alcohol is... ;)

The problem was caused by systemd spamming the dmesg log when it detected the debug commandline option. If an attacker has access to the kernel commadline (read: your bootloader configuration) you have problems that are significantly worse than a crashing kernel. By the way, Greg Kroah-Hartmann considered the excessive amount of verbosity of systemd to be a bug and fixed that already.

Not that often that we agree on something, but this definitely is true.

Actually Tobi, you're getting it wrong..

Even the systemd guys know the debug is producing too much noise to be of any use, however they decide to keep it enabled in the global parameter 'debug' that one would use, well, guess what.. for actual debuging..

Even if they (the kernel devs) do put a rate limit to avoid possible system crashes, the fact remains that when a user/developer is trying to debug the kernel (which is the main function for 'debug') they would get a whole lot of noise they didn't ask for..

I get the ideea of putting the whole system initialization into debug mode, but when you know it's not useful and even creates problems and you still do it and expect others to clean behind you or just deal with it, then who's fault is it?

To me, the kernel is like the engine in a car and the init system is like the gearbox, transferring the engine power into the drive train. If you drop in a new gearbox and the engine stalls when you select an unusual gear, then the problem is in the gearbox design.

For something to be a bug, it has to (at the very least) involve a feature or function not working as intended.

I guess you could argue that the kernel "debug" feature wasn't working properly if the init system chose to deliberately block it, but you'll have to admit that's a pretty absurd corner case.

Also, it involves a process with root privileges using a kernel feature in a way it was never intended to be used. Since any privileged process can still cause a kernel panic by abusing any number of other kernel services, should we be filing lots of bug reports?

Hey, see my other post about LKML April Fools Humor. Might be a good way to make a buck or so <GRIN>

I think this post by Linus is a great summary: http://lkml.iu.edu//hypermail/linux/...4.0/01488.html It's not that they are misusing a kernel feature, it's much simpler: their program causes systems to hang (for no good reason) when people are trying to debug Linux, so they should fix their program.

Thank you Linus!
 

http://lkml.iu.edu//hypermail/linux/...4.0/01488.html

Remember Just For Fun?
RHT Community Fork 2.0, Just For Shareholder Value.

Here's the bugzilla at freedesktop.org. The bug history(open/close/open/close...) is entertaining.

https://bugs.freedesktop.org/show_bug.cgi?id=76935

Yeah, it seems Kay only wants to avoid the issue entirely, not deal with it.

I hate to say it but Borislav and Mel are completely correct:

All the more reason I say, remove all support of udev from the Linux kernel, go back to DevFS, HAL, and Hotplug until Kay gets his head out of his or Lennart's arse.

comments to this gplus post are interesting too

https://plus.google.com/111049168280...ts/Kd57G8s1cTD

I posted the link on LXer just to have a little fun.

http://lxer.com/module/newswire/view/200597/index.html

I seem to recall "she who must not be named" saying that if something gets picked up by an aggregator, its credibility skyrockets in her eyes. So: good going. :)

And on a purely technical level, it sounds to me like Linus is 100 percent right and Kay is 100 percent wrong.

There I was, minding my own business administering my systems, when udev presented itself. I somehow broke Xsane, so I ripped out sane-backends and Xsane, then re-installed them. Sane-find-scanner finds the usb scanner, my custom /etc/udev/rules.d udev rule correctly sets the scanner permissions and changes the group to scanner, but Xsane just hangs for a while trying to find a scanner until impatience invokes kill or it just claims it can't find the scanner and goes away. I haven't done a postmortem yet, but this nonsense all happened when after a preview scan I pressed the scan button, the image flashed on the screen, then xsane *poof* vanished. Sew! off I go to compare things with a [aside: I put "fedora hat" into duckduckgo.com and it returned red hat. Go figure!] another system that was running the F-word to which I just referred. In /etc/udev, it had a hwdb.bin, so off I went to get smart on that. Seems the only reference I could find to any of the hwdb-related files on the F system was in the source tree of udev-182, which I was going to compile and install in desperation. Udevadm uses that file during run-time to find hardware. News to me, off I went to see if there was any skinny from the slackware experts herein only to find this amusing thread, since the only mention of a place to get udev source code, in hopes that there is a more recent version that works, had the Sievers e-mail address. In desperation, off I go to F-land to scan the documents my attorneys require, since the local Kinkos is usually packed with architecture students.
--
Obquote: "Fight, fight, fight, go ahead...." -Cary Grant, sitting on the staircase, "Arsenic and Old Lace (1944)"

I was looking for a reply to Borislav's (tongue-in-cheek?) suggestion that Linus should start his own init daemon project following the success of git.

Now THAT would|could|might be exciting!

But even he would first need to remind us all, what is it that is broken with SysV init and why we need yet-another-init-system?

If he does make one and defeats systemd, then he should be nominated for the greatest developer ever. He already qualifies, but still.

I've been watching this for months. People have serious concerns about the issues being created by systemd all over the place. I even read a chat log or two from the GNU devs wondering if more of the community leaders need to step up and say something.

The core issue with systemd isn't systemd, or udev, or d-bus, etc. The issue is the attitudes of a few of the freedesktop developers. The fact that they're trying to make Linux/GNU better is also not a problem. The problem is multiple displays of a callous & self-entitled attitude that have been carelessly tossed at anyone who's opinion differs from theirs. Linux, GNU, free software, etc., etc. are community projects. When a couple of people writing core services start behaving as if the entire community should work around the decisions they make without any possibility of compromise, you are going to have serious problems. Why? Because "collaborative dictatorship" is an oxymoron. Not only that, systemd seems to be almost marketed towards hard dependency by as many projects as possible. The net effect of that has been a whole host of frustrated people who either begrudgingly switch to systemd or virulently attack systemd and any related projects, some going as far as to drum up conspiracy theories.

The systemd situation is creating a rift in the community that is getting bigger by the day. Sadly, it's not a healthy rift about offering choice and instead is causing multiple rage forks. And, all of it because a couple of guys decided that behaving like systemd**s was the thing to do.

This is not a good place for the community to be and if it keeps up, I fear we're going to start seeing deliberate moves on either side to create incompatibility. That would be very sad for Linux.

(Oops missed already present link in earlier post...)

BTW: When I say, "deliberate incompatibility" I don't mean between kernel - systemd, or gnutools - systemd, etc. I mean less central projects posturing to either avoid a mandatory systemd by avoiding related components OR systemd components making forks difficult.

The issue is Red Hat. Everyone is pretending they are just "independent freedesktop developers", but they aren't. They got an assignment and their attitude helps their employer to accomplish his goals without getting the bad press. They got hired for exactly this reason. It's the well known good cop bad cop scheme, which we see in action here.

Agreed. When Red Hat decided it was their mission to profiteer off GNU/Linux the result was a downward spiral we've been forced into thanks to them. The only people who can break this destructive fall are the very people who are standing around wanting Linus to do something... the community. If the community wants to break Red Hat's hold on GNU/Linux, then it needs to do so.

If Linus could break the hold of UNIX with the efforts of GNU with Linux.

Why can't the community of GNU/Linux users stand up to Red Hat and strike them down all the same?

All the more the same, the cat's out of the bag. Time for more popcorn! :evil grin:

One of the things that bothers me is: Why does systemd have to do... Well, everything?

Start Processes
Stop Processes
Backwards Compatible with initd
Optional Support for declarative startup configs (needed to prevent async race and dependency-ladder processes)
Classic Run levels run classic, moving processes to declarative scripts enables async.
Async groups are started by named declarative script, rather than a number... this clearly separates SystemV from Async behavior in unambiguous way.
Optional: Find and kill wayward forks.

That's all it NEEDS to do, and it's only a couple of more things that SysV does.

I mean, look at these: http://en.wikipedia.org/wiki/File:Sy...components.svg && http://en.wikipedia.org/wiki/File:Li...nd_systemd.svg

PID1: init, login, log, network, user session...

Even WINDOWS doesn't do that! SMSS.exe (initd equiv) is PID1 (I think), which calls csrss.exe (client/server mgr) and winlogon.exe (user session mgr) and monitors them.

Winlogon manages all user processes, csrss manages all daemon type processes (net, IIS, log, etc.) The only job SMSS has is to launch and watch those to, start one if it dies and trigger kernel panic if either is killed manually by an Administrator. Systemd appears to place all that functionality, and more... in PID1. You can't replace that without a reboot, it's one hell of a single point of failure.

They can. By using Slackware, Gentoo, Crux, LFS, ...

Ubuntu can quite easily revert is decision, and quite frankly so could Debian (and they should to but the politics on the Debian mailing list would be as bad as on the kernel list). Upstart is a viable system and it is probably one of the only things from Ubuntu that isn't used already that Debian should use. In other words it isn't to late, things could turn around on many fronts but it seems increasingly unlikely that the turnaround will be in systemd.

I do agree with Tobi though, not to often that happens, if systemd is creating a situation where the kernel is crashing the kernel obviously has a problem as well.

Not a good comparison at all. The problem could be as simple as engine timing or torque curve. Drop a 6 speed g/box with an 0.50 overdrive and expect an old carby v8 from the early 1960s in a 2 ton car to pull 100kmh and be happy with any acceleration in that gear you've got another thing coming. The g/box is not at fault, the owner should have done some research and s/he would have realised the engines torque and power curves are not suited to the new g/box.

I've hesitated to make my mind up about Red Hat's role in this mess. But now we have more data. The person who raised the problem on LKML this week is a prominent kernel hacker for Red Hat, and he is evidently unhappy with systemd, and not frightened to stir things up. So (IMO) the Red Hat conspiracy theory needs, at a minimum, to be refined somewhat, and we certainly don't want to be unkind towards Mr Rostedt, who has achieved more against systemd than all the Debian systemd sceptics put together. Red Hat management needs to know that Mr Rostedt is making Red Hat look good.

IMO there has been a big problem with pro-systemd people not fully disclosing their allegiances in forum advocacy (not naming names, because that would be invidious, but LWN and Phoronix are two places where this is endemic). As a consequence of that, we've been saying 'Red Hat' when we should perhaps have been saying 'FDO people' or 'Friends of Gnome' or 'Fedorasts'. This is a trap laid by the other side. It would be far more effective to argue on the merits instead. See Graham's Hierarchy of Disagreement.

That is simply factually wrong, you really should update your knowledge about systemd. Those things are not running in PID1.

I personally watched what Red Hat's big backer do for the fastest computer in the world after watching them complain about hardware and the software and how to control it. The NCSA finally said hey you either going to build this thing or give the grant money back. years of wasted time.
Cray stepped in and asked the software developers how can we help with building the controller.

In what way can we support you. This was never heard before. AMD and Nvidia stepped in with Cray and the system came to life very fast.

That is called team work. And it booted Linux. http://hardware-beta.slashdot.org/st...er-blue-waters
The fact is IBM treated the developers of the software for the hardware like they where numbers. Cray does support it was amazing how fast it went online.

Having a chance to talk to people that are very close to the project it was never about the money it was a hardware issue and how to control the hardware.

when asked what Cray and NCSA would use for a operating system it was The Linux kernel. There is a big deal how we handle the start up process with linux.
You would think Red Hat's backer would have learned by now.

Yes, it is easy to push analogies to the point that they break, but in this case the designers of the gear box are cognisant of the existing engine and should have been more willing to accept design advice when presented with evidence of a deficiency. That said, the stress test that was imposed has resulted in suitable engine and gearbox modifications.

Until we know more about how much functionality would be lost for actual kernel debugging, just to accommodate systemd, this to me sounds like "Hey! If we drive a boat at full speed into this rock in the middle of the channel... it sinks. Must be something wrong with the boat"

I would not say "simply". Systemd (the init process, not the project) is handling certain aspects of these processes that init hadn't previously (namely the opening of sockets and connections to buses). Systemd (the project, not the init process) has taken on the porting of this functionality to systemd (init) and, what is rather troubling to some, done so with little regard toward maintaining compatibility with other init processes.

The answer is in Lennart's reply to Greg I think
GNOME OS is the goal, everyone else f*ck off.

I added the bold to highlight why I will never buy a RHT product. Lurking the systemd-devel lists shows a lot of ugliness. Transparency cuts both ways, asshats.