|
|
Log in / Subscribe / Register

Another daemon for managing control groups

Another daemon for managing control groups

Posted Dec 10, 2013 12:34 UTC (Tue) by dgm (subscriber, #49227)
In reply to: Another daemon for managing control groups by anselm
Parent article: Another daemon for managing control groups

>> A package involving 69 individual binaries can hardly be called monolithic.

It can. Modularity is not a question of the number of pieces, but of the coupling between them.

AFAIK, systemd modules are not "replaceable" in any sensible way, because they are highly coupled, their interfaces undefined and continuously changing. But I may be wrong.


to post comments

Another daemon for managing control groups

Posted Dec 10, 2013 13:01 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

There is a page on the systemd site which lists the interfaces systemd adheres to between its components. It has been linked from this thread at least twice (search for "Promise").

Another daemon for managing control groups

Posted Dec 10, 2013 13:21 UTC (Tue) by mchapman (subscriber, #66589) [Link]

> AFAIK, systemd modules are not "replaceable" in any sensible way, because they are highly coupled, their interfaces undefined and continuously changing. But I may be wrong.

I think the big problem here is that people are talking about (at least) two different kinds of "modularity".

There have been comments claiming that too much is being put into PID 1. The "69 individual binaries" comment should be a good counterclaim to that -- the majority of those binaries live in /usr/lib/systemd/ and are separate from PID 1 specifically because their functionality doesn't need to run in PID 1.

That's one kind of modularity. The other is "replaceability". Here I would have to agree with you: most of those /usr/lib/systemd/ binaries are not really that replaceable. (I'm not sure I'd say the interfaces are "undefined and continuously changing", though -- that makes no sense from a maintainability point of view, and at least the ones I poked directly on my system all responded nicely to --help). Perhaps this is a concern to some people... but I'm not sure what the alternative might be. They're only supposed to be used internally by systemd, so replacing them with functional equivalents wouldn't change anything.

Another daemon for managing control groups

Posted Dec 10, 2013 13:34 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> AFAIK, systemd modules are not "replaceable" in any sensible way, because they are highly coupled, their interfaces undefined and continuously changing. But I may be wrong.
You are, there are lots of interfaces that can be reimplemented independently, and most of the systemd interfaces are fully documented.
http://www.freedesktop.org/wiki/Software/systemd/Interfac...

Another daemon for managing control groups

Posted Dec 10, 2013 16:55 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

AFAIK, systemd modules are not "replaceable" in any sensible way, because they are highly coupled, their interfaces undefined and continuously changing. But I may be wrong.

You are partially wrong (interfaces are defined and described here). But more important is somewhat relevant question: why do you care?

It's true that systemd components are separated into a bunch of small programs designed to work together… just like UNIX was always developed. It's true that systemd components are not designed to be easily replaceable… just like UNIX components were never designed to be easily replaceable. It's kept as one single (and relatively large) source codebase… just like which was delivered as large code dumps on a few tapes.

Basically the story with systemd always goes in the same circle again and again. Somewhat like this:

Detractor: Systemd developers totally don't understand “Unix Way” because they are doing A, B and C!
Supporter: Well, systemd does X, Y and Z—why it's not enough.
Detractor: If systemd does not do A, B and C then it's against “Unix Way”, it's an abomination to be stopped at any cost. Only if you do A, B and C you can call yourself “true Unix believer”
Old beard: I was there at the beginning and I can vouch that Unix was never about A, B or C.
Detractor: You, the doited idiot, you've made Unix, but you totally don't understand it. Your Unix never did A, B and C but of course it does not matter: if you don't do A, B or C then you are doing things wrong!

When you define something which Unix never did, something which it never planned to do, something which only some other systems ever did as as “true Unix Way” then it's kind of hard to discuss your arguments rationally.

Unix components were never intended to be used on other platforms. Many components were ported to other platforms or rewritten in compatible way (GNU project is most famous for that), but it was not something UNIX creators ever cared about and it was not something they planned for.

Yes, components had more-or-less clean interfaces, but UNIX man was designed to always usee UNIX troff and it was never designed to use groff, UNIX cc was designed to be used with UNIX as and UNIX ld, it was not compatible with other tools (indeed even GNU toolchain sometimes is forced to use native components on some systems because they are tied to tightly to other components). So why, just why systemd should be designed differently? Because some people who don't plan to use systemd anyway desire that? Makes no sense to me.

Another daemon for managing control groups

Posted Dec 11, 2013 16:59 UTC (Wed) by dgm (subscriber, #49227) [Link]

> You are partially wrong (interfaces are defined and described here).

It happens to me all the time. Oh, well.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds