Yet another systemd fiasco

Posted Nov 19, 2014 18:36 UTC (Wed) by jb.1234abcd (guest, #95827)
In reply to: Yet another systemd fiasco by jezuch
Parent article: Russ Allbery leaves the Debian technical committee

"With systemd the complexity is moved to the "engine" so instead of complex solutions for each individual problem we have a complex solution to a common problem so that the individual problems can have a simple solution. I think you can safely call that an "abstraction layer" :)"

Well, the smile is right :-)
Now, apparently systemd dev's got it wrong ... kind of backwards !

I think you should be a bit more sceptical about systemd and its devs.
After all, you said you are a software engineer.

Now let me explain one more time, in case you and other LWN posters missed it.

These are excerpts of my posts regarding systemd.
http://lwn.net/Articles/589108/

You can start with the background on the socket activation:
Posted Mar 6, 2014 14:45 UTC (Thu) by jb.1234abcd
"In a socket-based activation scheme, the creation and
...
sharing (e.g. net or file system availability, etc)."

Then you hit the post that made me respond to you:
Posted Mar 10, 2014 6:32 UTC (Mon) by jb.1234abcd
"Well, yes. But it is not the only attribute of a socket,
...
universal (abstract), and then select tools that were primarily created
for it."

So, you have to repeat the same misguided mechanism for handling services
dependent on various socket attributes for each type of such a socket-driven service (daemon).

This is problematic on various grounds:
- because there are many service daemons possible (blocking, non-blocking,
connection-oriented, connectionless, asynchronous i/o, etc, it will be
necessary to maintain different source code for socket passing
mechanism in systemd and daemons for each of them.
- it creates source-code level coupling between sys init (systemd
executable) and services (daemons); moving some of this code to
a library will not solve the problem (it would just move the staff
around).
The source-code level dependency is a big no-no; one should avoid it like
a plague. It is a maintenance nightmare.
- it creates functional coupling between sys init and services (daemons)
beyond their config files.

This is an example of how misunderstanding and mistakes made in domains analysis and modeling phases (building abstraction layers) lead to mistakes in programming tools (constructs) selections and implementation phase. It is a domino effect.

Sys init should treat services as black boxes to prevent any entanglement and avoid problems with maintenance of both. Now any time you want to add even a prototype of a socket-based service daemon you have to write and compile C code for both, service and systemd; in old days it was enough to write shell code for a service.

By systemd dev's own words, systemd is to be a *core component of an operating system*, an init sys and much, much more (systemd-resolved was already discussed here and alsewhere ..., other systemd-*d goodies will be in due time, I hope).

I think it is time for leadership of Debian project to make some hard
decisions. Things are already happening, but Mr. Bruce Perens has to follow thru with his unofficial mandate.

Yet another systemd fiasco

Posted Nov 19, 2014 19:07 UTC (Wed) by vonbrand (subscriber, #4458) [Link] (6 responses)

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.