Yet another systemd fiasco

Posted Nov 19, 2014 19:07 UTC (Wed) by vonbrand (subscriber, #4458)
In reply to: Yet another systemd fiasco by jb.1234abcd
Parent article: Russ Allbery leaves the Debian technical committee

I'd very much prefer having one well-scrutinized and maintained version of the code doing the different dances for daemon use-cases (where they really are different in setting the sockets up) instead of having a gazillion half-baked snippets in all sorts of random packages scattered all over the Internet. Exactly as I don't like the thousand-line "shell libraries" used by several-hundred shell line "service files" duplicating all sort of very tricky code, and the exacting dance forced on daemons to get rid of their inherited environment. Yes, I've tried (on Solaris, Red Hat, and Fedora, and other SysV-ish systems I forget about) to make enough sense of it all to fix some mistery or create my own script. I still shudder.

BTW, your argument works exactly the same against having one libc, or any other basic infrastructure code. Even the Linux kernel itself. That systemd isn't packaged up as a library doesn't mean it's purpose isn't offering common code/services to a variety of users in a convenient, safe way.

Yet another systemd fiasco

Posted Nov 19, 2014 19:32 UTC (Wed) by smurf (subscriber, #17840) [Link] (5 responses)

Correct, even Linux … which is why Debian tries to run on kFreeBSD and some people test how far they can get with rebuilding it all with some embedded-style libs … and also why some Debian people don't like to depend on systemd, which can't run anywhere but Linux 3.x without a major brain transplant.

NB: … doesn't mean *its purpose …

Yet another systemd fiasco

Posted Nov 21, 2014 12:26 UTC (Fri) by jezuch (subscriber, #52988) [Link] (4 responses)

> which is why Debian tries to run on kFreeBSD and some people test how far they can get with rebuilding it all with some embedded-style libs

And they're free to do that, and if something breaks with kFreeBSD or HURD, bugs are reported and (supposedly) fixed - even though 99,9% of the project doesn't give a darn about these kernels. So even if sysvinit becomes a HURD of init systems in Debian, I expect that people interested in running it (and I fully expect that there will be *much* more of them than those running HURD) will file bug reports when something breaks and these bugs will be (supposedly) fixed. That's why, in my opinion, so many DDs voted "no GR needed" in the recent GR, and how I would've voted if I was a DD instead of a mere user.

Yet another systemd fiasco

Posted Nov 21, 2014 13:15 UTC (Fri) by Zack (guest, #37335) [Link] (3 responses)

> even though 99,9% of the project doesn't give a darn about these kernels.

Seeing how there's more than 1 developer running it, that's hyperbole. And just because DDs are not running it, that doesn't imply they don't give a damn about it.

It's also not about extending sysvinit's lifespan indefinitely. It's about Jessie+1 (or Jessie+n), when another init is presented (let's say OpenRC) which says: this init works well with and without cgroups enabled , it doesn't depend on kdbus but can make use of it, it runs on all Debian kernels (which OpenRC already does), and it's actually in FreeBSD's ports as a viable alternative. In short: it's the init Debian deserves!

Only to by met with: "So how good is it with DNS resolution?"

Yet another systemd fiasco

Posted Nov 21, 2014 14:18 UTC (Fri) by smurf (subscriber, #17840) [Link]

Presumably there'll then be another resolved implementation if some programs depend on it. Same as with logind (or its underpinnings) or timedated or whatever other can't-live-without-it services people come up with.

I'd reserve judgment on resolved anyway. It's strictly work in progress at this time. Lennart's grumpiness nonwithstanding, hardening a DNS client implementation is not the very first thing you do when implementing it, so calling "CVE" on it really is out of line.

Anyway, that's not the problem. The problem is that sitting in a hotel room with a VPN tunnel to $HOME active works perfectly EXCEPT FOR DNS (and having more than one tunnel up is strictly worse). The systemd people are the only ones who actually *do* something about this problem. Instead of, say, telling other people that their approach is misguided.

The dbus-based approach may well be wrong, but even if systemd's solution ends up being broken we'll have learned something about the problem and can do better next time, just as systemd learned from upstart's mistakes.

The true fiasco seems to be that it seems to be impossible for some people to write critical comments about anything systemd-ish without derogatory side remarks. No wonder these get ignored. I would, too.

Yet another systemd fiasco

Posted Nov 22, 2014 14:44 UTC (Sat) by mpr22 (subscriber, #60784) [Link] (1 responses)

Conveniently, people have actually looked at the task of creating independent reimplementations of "upper" portions of the systemd suite and declared it feasible. After all, from the perspective of programs using systemd-logind or systemd-resolved, those things aren't programs; they're D-Bus interfaces.

Yet another systemd fiasco

Posted Nov 23, 2014 10:54 UTC (Sun) by makomk (guest, #51493) [Link]

The only parts they've reimplemented are timedated and hostnamed, each of which export only a handful of relatively trivial APIs. Their localed is a stub that returns empty strings when reading information and denies all writes, and their logind doesn't even appear to have do-nothing stubs for its API calls. This is unsurprising, given that logind is far more complicated and the systemd developers don't think it can be independently reimplemented. Unfortunately, it's also required by Gnome and soon by other desktop environments.