4 ms·

you are exactly on point. the unix way is simplicity and transparency. systemd is complex and opaque. it's ok to have systemd's goals, but an additional goal

by bossrat 11y ago

you are exactly on point. the unix way is simplicity and transparency. systemd is complex and opaque. it's ok to have systemd's goals, but an additional goal should be "not a huge monolith"

otterley 11y ago
What is the criteria by which you classify something as "opaque"? The documentation for systemd and its utilities is second to none.
- vezzy-fnord 11y ago
  The documentation for systemd and its utilities is second to none. God help the software industry if that is indeed the case (of course, it is not).
  - witty_username 11y ago
    How so? I was able to easily use systemd and the man pages seem decent. Maybe not the best documentation, but it seems reasonable.
    - simoncion 11y ago
      In order to see the quality difference, you have to compare the docs to another project that you make extensive use of. I know that Postgresql's and Erlang's documentation is really rather good. So, go use Postgresql or Erlang for a slightly non-trivial project, then -now that you know about the topic that the docs cover- compare the quality of the systemd documentation to the documentation of either other project. Pay special attention to the documentation provided to folks who want to understand the internals of systemd, Postgres, or Erlang. AIUI, [0] systemd's internals documentation is woefully lacking. [0] And as has been repeated by everyone I've ever seen try to use said documentation.
      - witty_username 11y ago
        True, systemd's documentation isn't very bad though, it's reasonable (lack of internal documentation is pretty common in many open source projects).
        simoncion 11y ago
        Remember that this thread was sparked by otterly's comment: [0] > The documentation for systemd and its utilities is second to none. What little I've seen of systemd's user/sysadmin documentation leads me to believe that it is okay. I also understand that documentation is often the least interesting part of any project, and often sorely neglected. However. Everyone I've heard of that tests out the Systemd Cabal's claim that "Systemd is not monolithic! Systemd is fully documented and modular, so any sufficiently skilled programmer can replace any and all parts of it with their own implementation." by attempting to make a compatible reimplementation has failed at their task [1] and reported that the internals documentation is woefully insufficient. When you're writing software for general consumption, good user documentation is a requirement. After all, if noone can figure out how to use your system, "noone" will use it. When you also claim that you go out of your way to provide enough documentation to allow others to understand the relevant parts of your internals, and be able to write compatible, independent implementations of your software, the quality of the documentation about your internals is now in scope for evaluation and criticism. [0] https://news.ycombinator.com/item?id=10485095 https://news.ycombinator.com/item?id=10485095 [1] I am very aware that this task is made harder by the fact that it is large and thankless. :)
  - otterley 11y ago
    What specifically do you find lacking in it?
- e12e 11y ago
  > The documentation for systemd and its utilities is second to none. $ man none No manual entry for none Sounds about right.
- digi_owl 11y ago
  Perhaps. Observed a lovely exchange a while back where a database was being publicly shamed for producing a poor unit file (i think they actually had the unit file launch a shell script that fired up the database). Their response given was that it was the only way for them to avoid tying their database to the systemd signaling lib. This was counted by one of the systemd devs claiming they could just use a socket that systemd provides. But when i poked at the documentation, the only place such a "option" was mentioned was at the bottom of the man file for said lib. And it was presented as a note on the internal workings of systemd. And you will find warning after warning about not using systemd internals, as the devs reserve the right to change the behavior of those internals at any time.
  - otterley 11y ago
    Right, you're supposed to use the published interfaces. There's nothing particularly novel about that -- neither Microsoft nor Apple will support you if you don't use their public APIs, and in fact Apple will refuse to publish your software in their app store if you don't. With respect to socket activation, a pretty useful tutorial, published by the systemd author, can be found here: http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... The DBus API can be found here: http://www.freedesktop.org/wiki/Software/systemd/dbus/ http://www.freedesktop.org/wiki/Software/systemd/dbus/
    - simoncion 11y ago
      > Right, you're supposed to use the published interfaces. You missed the point. I'll isolate each component for you: "[A] database was being publicly shamed for producing a ... unit file ... [that used] a shell script [to start] the database[.]" "[The database devs mentioned] that it was the only way for them to avoid tying their database to the systemd signaling lib." "[O]ne of the systemd devs [mentioned] they could just use a socket that systemd provides." "[But this] ... 'option' ... was presented [at the bottom of the man page for the systemd signalling lib that the database authors were trying to not use] as a note on the internal workings of systemd." "[You] will find warning after warning about not using systemd internals, as the devs reserve the right to change the behavior of those internals at any time." So, this "option" -as documented- is something that you cannot rely on, as it is subject to change at any time, without warning. > With respect to socket activation, a pretty useful tutorial... Tutorials are no substitute for documentation. Documentation describes the contracts that the software commits to. Tutorials can exploit edge cases and undocumented behaviors without warning. Moreover, if the docs say that the tutorial is demonstrating a feature that's subject to change at any time, you'd have to be a madman to rely on it. > The DBus API can be found here... If the database devs don't want to depend on the systemd signalling lib, I bet they really don't want to depend on DBus. This might come as a surprise to some, but many servers don't run a DBus daemon.
Avshalom 11y ago
The unix way is also a different incompatible implementation of regex in every utility and a thousand interesting and dangerous modes of failure in the event of whitespace Systemd has issues I'm sure and I don't trust poettering's software further than I can throw him but not being 'unix'-y isn't a strike against it.
- iuguy 11y ago
  > The unix way is also a different incompatible implementation of regex in every utility and a thousand interesting and dangerous modes of failure in the event of whitespace Then_stop_using_whitespace_and_that_problem_is_solved_for_some_values_of_solved_;)
  - GFK_of_xmaspast 11y ago
    "You're doing it wrong and should have known better" is also the unix way.
emmelaich 11y ago
Things should be as simple as possible but no simpler. We all agree with you on the 'simple as possible' but you need to spend some effort on the 'no simpler' part.

by bossrat 11y ago

you are exactly on point. the unix way is simplicity and transparency. systemd is complex and opaque. it's ok to have systemd's goals, but an additional goal should be "not a huge monolith"

otterley 11y ago

What is the criteria by which you classify something as "opaque"? The documentation for systemd and its utilities is second to none.

vezzy-fnord 11y ago
The documentation for systemd and its utilities is second to none. God help the software industry if that is indeed the case (of course, it is not).
- witty_username 11y ago
  How so? I was able to easily use systemd and the man pages seem decent. Maybe not the best documentation, but it seems reasonable.
  - simoncion 11y ago
    In order to see the quality difference, you have to compare the docs to another project that you make extensive use of. I know that Postgresql's and Erlang's documentation is really rather good. So, go use Postgresql or Erlang for a slightly non-trivial project, then -now that you know about the topic that the docs cover- compare the quality of the systemd documentation to the documentation of either other project. Pay special attention to the documentation provided to folks who want to understand the internals of systemd, Postgres, or Erlang. AIUI, [0] systemd's internals documentation is woefully lacking. [0] And as has been repeated by everyone I've ever seen try to use said documentation.
    - witty_username 11y ago
      True, systemd's documentation isn't very bad though, it's reasonable (lack of internal documentation is pretty common in many open source projects).
      - simoncion 11y ago
        Remember that this thread was sparked by otterly's comment: [0] > The documentation for systemd and its utilities is second to none. What little I've seen of systemd's user/sysadmin documentation leads me to believe that it is okay. I also understand that documentation is often the least interesting part of any project, and often sorely neglected. However. Everyone I've heard of that tests out the Systemd Cabal's claim that "Systemd is not monolithic! Systemd is fully documented and modular, so any sufficiently skilled programmer can replace any and all parts of it with their own implementation." by attempting to make a compatible reimplementation has failed at their task [1] and reported that the internals documentation is woefully insufficient. When you're writing software for general consumption, good user documentation is a requirement. After all, if noone can figure out how to use your system, "noone" will use it. When you also claim that you go out of your way to provide enough documentation to allow others to understand the relevant parts of your internals, and be able to write compatible, independent implementations of your software, the quality of the documentation about your internals is now in scope for evaluation and criticism. [0] https://news.ycombinator.com/item?id=10485095 https://news.ycombinator.com/item?id=10485095 [1] I am very aware that this task is made harder by the fact that it is large and thankless. :)
- otterley 11y ago
  What specifically do you find lacking in it?
e12e 11y ago
> The documentation for systemd and its utilities is second to none. $ man none No manual entry for none Sounds about right.
digi_owl 11y ago
Perhaps. Observed a lovely exchange a while back where a database was being publicly shamed for producing a poor unit file (i think they actually had the unit file launch a shell script that fired up the database). Their response given was that it was the only way for them to avoid tying their database to the systemd signaling lib. This was counted by one of the systemd devs claiming they could just use a socket that systemd provides. But when i poked at the documentation, the only place such a "option" was mentioned was at the bottom of the man file for said lib. And it was presented as a note on the internal workings of systemd. And you will find warning after warning about not using systemd internals, as the devs reserve the right to change the behavior of those internals at any time.
- otterley 11y ago
  Right, you're supposed to use the published interfaces. There's nothing particularly novel about that -- neither Microsoft nor Apple will support you if you don't use their public APIs, and in fact Apple will refuse to publish your software in their app store if you don't. With respect to socket activation, a pretty useful tutorial, published by the systemd author, can be found here: http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... The DBus API can be found here: http://www.freedesktop.org/wiki/Software/systemd/dbus/ http://www.freedesktop.org/wiki/Software/systemd/dbus/
  - simoncion 11y ago
    > Right, you're supposed to use the published interfaces. You missed the point. I'll isolate each component for you: "[A] database was being publicly shamed for producing a ... unit file ... [that used] a shell script [to start] the database[.]" "[The database devs mentioned] that it was the only way for them to avoid tying their database to the systemd signaling lib." "[O]ne of the systemd devs [mentioned] they could just use a socket that systemd provides." "[But this] ... 'option' ... was presented [at the bottom of the man page for the systemd signalling lib that the database authors were trying to not use] as a note on the internal workings of systemd." "[You] will find warning after warning about not using systemd internals, as the devs reserve the right to change the behavior of those internals at any time." So, this "option" -as documented- is something that you cannot rely on, as it is subject to change at any time, without warning. > With respect to socket activation, a pretty useful tutorial... Tutorials are no substitute for documentation. Documentation describes the contracts that the software commits to. Tutorials can exploit edge cases and undocumented behaviors without warning. Moreover, if the docs say that the tutorial is demonstrating a feature that's subject to change at any time, you'd have to be a madman to rely on it. > The DBus API can be found here... If the database devs don't want to depend on the systemd signalling lib, I bet they really don't want to depend on DBus. This might come as a surprise to some, but many servers don't run a DBus daemon.

Avshalom 11y ago

The unix way is also a different incompatible implementation of regex in every utility and a thousand interesting and dangerous modes of failure in the event of whitespace Systemd has issues I'm sure and I don't trust poettering's software further than I can throw him but not being 'unix'-y isn't a strike against it.

iuguy 11y ago
> The unix way is also a different incompatible implementation of regex in every utility and a thousand interesting and dangerous modes of failure in the event of whitespace Then_stop_using_whitespace_and_that_problem_is_solved_for_some_values_of_solved_;)
- GFK_of_xmaspast 11y ago
  "You're doing it wrong and should have known better" is also the unix way.

emmelaich 11y ago

Things should be as simple as possible but no simpler. We all agree with you on the 'simple as possible' but you need to spend some effort on the 'no simpler' part.