Lennart Poettering On The Open-Source Community: A Sick Place To Be In

[pininety]

*cough* OpenRC & cgroup segregation of daemons and cgroup cleanup...

That is actually true as far as I can tell.

From the gentoo wiki on openrc:
"
Service Cleanup

It's possible to trigger killing all service process tree (in process cgroup) when services is stopped or restarted. By setting
File/etc/conf.d/<service>an example of triggering cgroup cleanup

rc_cgroup_cleanup="yes"

This option should not be set globally as it will kill all service's child processes e.g. SSH connections or apache workers, as OpenRC doesn't support automatic process cgroup-relocation as it done in logind services. "

Did not know that so thanks for pointing this out. Maybe someone can explain a bit more that they mean by "automatic process cgroup-relocation ".
Up to know, I was working under the assumption that if you are using sshd.service a restart would drop all ssh connections while using sshd.socket would not but maybe there is something more to it.

[asdfblah]

Wrong. killall cannot reliably kill a daemon. What do you do if the main process of a daemon is called httpd and it frequently spans processes called fcgid or perl or rsync or whatever? And what if those processes detach completely from the main process? Do you want to killall perl and just hope that between the time killall is looking through the process list and the main process getting the kill signal it doesn't spawn a new process? Remember, I was asking about _reliably_ killing a daemon. That's not reliable. That's failing workarounds for SysV init's lack of features. And yes, this created real problems on real drbd based clusters. Neither killall, nor upstart nor any other init system except for systemd-init can do this reliably.

And you conveniently deflected my point: that's not exclusively a systemd feature. Again, there is not a single systemd-exclusive feature. Systemd is worthless.

[oleid]

And you conveniently deflected my point: that's not exclusively a systemd feature. Again, there is not a single systemd-exclusive feature. Systemd is worthless.

How did he?

Btw: The cgroup feature in OpenRC is quite new and not enabled by default for most daemons. Also, killing daemons manually will result in orphaned PID files, which have to be removed manually.

[gens]

Neither killall, nor upstart nor any other init system except for systemd-init can do this reliably.

process groups ? (killall -g)
session id ?
just killall until it returns non-zero ?
track it by monitoring proc events ?
just use the cgroups utilities and filesystem directly from the script that started it ?
yell "Wrong!!" on a forum ?

edit: you can't use the cgroups from script method with systemd, afaik
(and if you can now, you won't soon)

[gens]

...

also pkill -P pid and ptrace
upstart uses ptrace but idk how soon it bails and if that can be set
and there are plenty more init systems / process... forgot how it's named, trackers ? arbitrators ? overminds ? auditors ?

all in all many ways to do the same thing
all with good and bad sides
cgroups are the easiest since you basically just trow a process in a container and let it do whatever

[ceage]

Seriously, from where Lennart stands there's not much to worry about:

1. Almost every general purpose distro that matters has adopted his work.
2. Having a healthy number of notably incompetent opponents who can't do better than to spew insults instead of code and use words like `Lennux' and `Lennartware' is just an unrefined form of praise. Heck, he's not that old and has already become an adjective. He should feel flattered.
3. Those people are simultaneously making fools of themselves *and* helping to raise his profile even further.

What more could he ask for?

[ssokolow]

tsched=0

you are welcome?

Ugh. That was the one thing I didn't try because "tsched=0 uses more CPU" was the one thing everyone online seemed to be able agree on and I'd already had enough trouble tracing the 15-20% CPU load to "Turn off in-PulseAudio echo cancellation and use resample=src-linear"... at least it's only adding 1-2% extra CPU load.

However, it still doesn't make sense for "Is pavucontrol running?" to be the difference between the pulseaudio daemon taking 0% CPU load (no audio playing) or 3% CPU load (tsched=0, one stream) and it taking 10-12% CPU load (pavucontrol running, either of the aforementioned situations).

[oleid]

However, it still doesn't make sense for "Is pavucontrol running?" to be the difference between the pulseaudio daemon taking 0% CPU load (no audio playing) or 3% CPU load (tsched=0, one stream) and it taking 10-12% CPU load (pavucontrol running, either of the aforementioned situations).

A higher load probably due to pavucontrol reading the "waveform" to render the "loudeness bars".

[ssokolow]

A higher load probably due to pavucontrol reading the "waveform" to render the "loudeness bars".

Still a bug. I just found a more compact volume control GUI named veromix and, even with volume monitors for every single sink and source enabled and visible simultaneously, I couldn't drive the pulseaudio daemon's CPU consumption beyond roughly 4% for one stream. (compared to pavucontrol forcing a minimum CPU consumption of 10% even when NO audio is playing.)

That's MUCH more in line with what it should be. (2% CPU for running a single stream to the speakers via the src-linear resampler, 1% CPU as overhead for tsched=0, and another 1% CPU as overhead for VU meter queries on all sinks and sources simultaneously.)

[asdfblah]

How did he?

Btw: The cgroup feature in OpenRC is quite new and not enabled by default for most daemons. Also, killing daemons manually will result in orphaned PID files, which have to be removed manually.

Cgroups is not a systemd feature, is a kernel feature. you could make your own program to manage it, with or without systemd or even an init system. For the n-th time: systemd adds nothing new, no new features, it's worthless on itself. The only "feature" it adds is consistency in the configuration side, but even then, it removes flexibility.

Once again... You were sold an init system that was going to make boot times fast (as if it wasn't possible with the alternatives: http://gentooexperimental.org/~patri...9T08_32_52.txt ), remember? You guys bought the marketing speak, you now repeat it as if it was a given truth and then expect other people to believe it. You could, instead, try to understand how things work behind the command line... Poettering is a lot of talk, but he himself hasn't done anything outstanding (it's other people who end fixing his "amazing" software). More respectable, IMO, are those coding graphics drivers. I just wonder if he knows a thing or two about psychology...

Now he's taking things out of context (dead threats, wtf is wrong with this guy?) and playing the victim card.

Oh, and, seriously, the pseudo-"social justice warrior" and partisan talk has nothing to do with this... and if you consider yourself a "social justice warrior", why aren't you doing something against the NSA, stopping the wars in asia or hunger in africa or poverty in the world (or even your own "first world country")? It's because you don't care, you don't give a fuck if millions of people are being killed by your own governments, and you don't care because the statu quo is convenient for you. You won't leave your comfortable place. These "feminists" are a bunch of petite bourgeoisie whiners that aren't doing any favor to the world, to women, to minorities or anyone else. (and anyway, technology is itself is being used, precisely, to generate inequality, to massively spy on people and to destroy nature, while things could be completely different).

You guys make me sad. This has become another holy war (and you haven't even asked me what init system I'm using or why I'm bashing systemd...), and you don't see yourself as reactionary fanatics. Well, look at a mirror: you are a reactionary.