Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus will not be merging any code from systemd developer

permalink.gmane.org

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Linus will not be merging any code from systemd developer

#11

Post by anaphor »

csmattryder wrote: post #5

Systemd is soon to be integrated as the default init daemon for Ubuntu, one of the most user-friendly Linux distributions available. It worries me that Sievers, and the systemd team aren't approaching testing with an almost paranoid attitude. Linux is finally getting a foothold in consumer desktops, it'd be a shame for people to go back to other operating systems purely because "it broke one day, something about syst…

Yeah I'm considering switching to FreeBSD or even OpenBSD (if it would be possible to play some of my games on it). I don't want to switch really, but if systemd is going to be the default init system from here on and it continues to be plagued by bullshit like this then I don't really want to be bothered by it. (FYI I currently use Arch Linux, one of the early adopters of systemd).

Re: Linus will not be merging any code from systemd developer

#12

Post by akira2501 »

dredmorbius wrote: post #6
csmattryder wrote: post #5

Systemd is soon to be integrated as the default init daemon for Ubuntu, one of the most user-friendly Linux distributions available. It worries me that Sievers, and the systemd team aren't approaching testing with an almost paranoid attitude. Linux is finally getting a foothold in consumer desktops, it'd be a shame for people to go back to other operating systems purely because "it broke one day, something about syst…

And I really, really wish Ubuntu had held out with upstart instead. We need the alternative. You don't cavilierly fuck with PID 1, and that's precisely what the systemd folk appear to be doing. I'm really hoping Linus's rant makes an impact on them.

They're fucking around well beyond PID 1. Default binary log formats. This odd binary messaging bus with god awful reverse domain names, a shifting binary protocol format that injects itself into the kernels standard text-based messaging formats.

I find the whole dependency system completely bizarre, because to truly implement it, you have to hook into _everything_ and make it part of this odd binary mess they've created above.

I really don't understand the route they are taking, I see the system becoming less capable and more fragile with this type of engineering being encouraged.

Re: Linus will not be merging any code from systemd developer

#13

Post by programmer_dude »

darkarmani wrote: post #10
shawnz wrote: post #9

Earlier quoted context omitted.

> Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong. My understanding is that this is not the issue and, in fact, the command line parameters are provided to userspace in the way that they are exactly so that applications can do this kind of thing. Rather, the real issue is that the flag IS commonly used this way, and systemd's response to it b…

Yes. Linus explains that the kernel will ignore flags it doesn't know for that reason; however, systemd should not be doing anything with the debug flag as that is meant for the kernel. The systemd flag should be namespaced.

I think as always the kernel should be made robust enough (in this case through rate limiting) to handle such abuse.

In a way this Sievers guy is right but he could have been more polite in asking the kernel devs for this feature. And he needs to co-operate by cutting down the log traffic until the kernel is fixed.

Re: Linus will not be merging any code from systemd developer

#15

Post by e12e »

Oh, the actual bugzilla thread is (if possible) even more depressing:

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

I had actually started to warm to the idea of systemd, thinking that it couldn't end up the same clusterf*ck of mismatched reinventions that didn't really solve any problems that pulseaudio was. I guess it's time to move to Debian/kFreeBSD and ignore this crap.

Re: Linus will not be merging any code from systemd developer

#16

Post by shawnz »

darkarmani wrote: post #10
shawnz wrote: post #9

Earlier quoted context omitted.

> Userspace tools should not be using the same kernel parameters that are defined by the kernel. That's just broken and wrong. My understanding is that this is not the issue and, in fact, the command line parameters are provided to userspace in the way that they are exactly so that applications can do this kind of thing. Rather, the real issue is that the flag IS commonly used this way, and systemd's response to it b…

Yes. Linus explains that the kernel will ignore flags it doesn't know for that reason; however, systemd should not be doing anything with the debug flag as that is meant for the kernel. The systemd flag should be namespaced.

I believe we are both referring to this post: http://permalink.gmane.org/gmane.linux.kernel/1677099

In it, Linus says the following:

> No, we very much expose /proc/cmdline for a reason. System services are supposed to parse it [...] And yes, that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature.

Re: Linus will not be merging any code from systemd developer

#17

Post by jzelinskie »

anaphor wrote: post #11
csmattryder wrote: post #5

Systemd is soon to be integrated as the default init daemon for Ubuntu, one of the most user-friendly Linux distributions available. It worries me that Sievers, and the systemd team aren't approaching testing with an almost paranoid attitude. Linux is finally getting a foothold in consumer desktops, it'd be a shame for people to go back to other operating systems purely because "it broke one day, something about syst…

Yeah I'm considering switching to FreeBSD or even OpenBSD (if it would be possible to play some of my games on it). I don't want to switch really, but if systemd is going to be the default init system from here on and it continues to be plagued by bullshit like this then I don't really want to be bothered by it. (FYI I currently use Arch Linux, one of the early adopters of systemd).

Speaking of FreeBSD, weren't they supposed to be adopting launchd? What's the progress on that?

Re: Linus will not be merging any code from systemd developer

#18

Post by anaphor »

jzelinskie wrote: post #17
anaphor wrote: post #11

Earlier quoted context omitted.

Yeah I'm considering switching to FreeBSD or even OpenBSD (if it would be possible to play some of my games on it). I don't want to switch really, but if systemd is going to be the default init system from here on and it continues to be plagued by bullshit like this then I don't really want to be bothered by it. (FYI I currently use Arch Linux, one of the early adopters of systemd).

Speaking of FreeBSD, weren't they supposed to be adopting launchd? What's the progress on that?

Googling tells me that they have been working on porting it and apparently it is more or less done but not yet the default.

Re: Linus will not be merging any code from systemd developer

#19

Post by dfc »

jzelinskie wrote: post #17
anaphor wrote: post #11

Earlier quoted context omitted.

Yeah I'm considering switching to FreeBSD or even OpenBSD (if it would be possible to play some of my games on it). I don't want to switch really, but if systemd is going to be the default init system from here on and it continues to be plagued by bullshit like this then I don't really want to be bothered by it. (FYI I currently use Arch Linux, one of the early adopters of systemd).

Speaking of FreeBSD, weren't they supposed to be adopting launchd? What's the progress on that?

Someone with better freebsd knowledge should chime in, but until then... It is my understanding that the launchd port was one guys google summer project, he worked on it for the summer, put it aside for a couple years and picked it up recently.

The fbsd wiki on launchd: https://wiki.freebsd.org/launchd

Re: Linus will not be merging any code from systemd developer

#20

Post by Rantenki »

programmer_dude wrote: post #13
darkarmani wrote: post #10

Earlier quoted context omitted.

Yes. Linus explains that the kernel will ignore flags it doesn't know for that reason; however, systemd should not be doing anything with the debug flag as that is meant for the kernel. The systemd flag should be namespaced.

I think as always the kernel should be made robust enough (in this case through rate limiting) to handle such abuse. In a way this Sievers guy is right but he could have been more polite in asking the kernel devs for this feature. And he needs to co-operate by cutting down the log traffic until the kernel is fixed.

While it would be nice for the kernel to handle any kind of bad behaviour by default, it isn't always realistic.

I mean, it would be nice if the kernel by default could handle a simple forkbomb, but it doesn't without restricting your limits.conf fairly severely. You can blow up the system in a variety of ways that are outside of the kernel's responsibility. It's not up to the kernel devs to hack around your bad behaviour.

Post reply on HN