4 ms·

Embrace, Extend, Extinguish.

by throw7 3y ago

mort96 3y ago
There was no embrace step; systemd served to replace sysvinit with a new way of doing things, supporting sysvinit scripts for backwards compatibility only. There was no extend; systemd's sysvinit scripts didn't have features which are lacking from the original sysvinit in an effort to cause the proliferation of sysvinit scripts which only work with systemd. EEE is a very specific strategy. It's not the general concept of making a new system to replace an old system.
- Brian_K_White 3y ago
  But it never actually did support sysv init scripts, because it fundamentally can't. All it has is ExecStart which is trivial garbage that does not replicate or emulate sysvinit functionality at all. I had a tiny little simple 2k init script that managed lxc containers. It provided: * graceful start all at boot * graceful wait while shutdown all at shutdown * Enable/disable of individual containers * Start/stop of individual containers * Console access to individual containers * Query status (running/not/etc) of individual containers at any time. * Query status of entire metaservice at any time All without any manager/monitor daemon either for the metaservice or the individual containers, and the script was tiny, maybe not even 2k. Under systemd, it's not possible to have an init script that can just check the status and then exit again, and where the definition of status is whatever conditions you want to code up. There is no ExecStatus because the fundamental way systemd tracks upness or downness is not by performing an action to get the answer but by monitoring a process or a port or a file itself. It requires a constantly running daemon of some sort that systemd can detect that it exited or is still running, or it requires one of a few other things that systemd just declares as all the possible options anyone can ever need. A port, a file, a process etc. The way my script answered the up or down question was it examined a few things about the container and decided based on what it saw. There didn't need to be any persistent process dedicated to monitoring a container, or all containers. The containers could run any sort of processes and didn't have to do anything a certain way in order to coordinate. IE, a container might have it's own copy of init as it's pid 1, or just bash, or screen, or a random binary. The script got it's info from kernel cgroups info by reading files and making a determination based on the contents of the files. It did this on demand and only when requested. There was no server process to monitor, no pid/lock file to monitor, no port to monitor. I'm not saying the cost of another process is so intolerable, I'm saying you can't actually do whatever you might want to do. You can only do that which the lord hath provided for. In a sysv script, you are free to code up whatever unpredictable logic you may happen to need, without the init author from 50 years ago having to predict what your needs will be and providing some managed limited answer for those specific predicted needs. Init not only doesn't care what you write in your script, it doesn't even care if it's a script at all. It doesn't have to be sh or even any scripting language, it could be a binary. The joy and relief of systemd is the relief of "everything would be so much simpler if everyone just did exactly the same thing", which is the same as saying if everyone else just did what I say. Here's how you know systemd's claim to being a good citizen is bs: Why can't I run systemd as just another service that isn't pid 1? I would have had far less problem with systemd merely existing in the world if it were like say xinetd where it could be run as a service that managed other services that wanted it, but was not pid 1 because I happen to want init, or any other thing of my choice to be pid 1, for whatever my reasons are, and systemd nor Poettering nor anyone else has any right to know or care what those reasons are, certainly not to decide for me that they are not valid. systemd presumes to know all the possible valid ways any service could operate, and any service that isn't covered is conveniently by definition invalid or insane, and so doesn't matter. Systemd is tight coupling. In every other aspect of IT, tight coupling is recognized as inflexible bad architecture. And this is all just the process/service management parts. The binary logs are a whole other example of tight coupling. It's a pattern.
  - kaba0 3y ago
    Maybe read the manpages, instead of ranting.
    - Brian_K_White 3y ago
      Maybe you should? I took the time to describe an actual problem, you didn't even so much as link to the supposed page that you imply negates it. Regardless, no man page "informs away" the tight coupling. How can you even remove support for something if you aen't coupled enough that it's even possible become no longer compatible? The very fact that the announcement "we're deprecating init scripts" even makes any sense proves the point all by itself.
op00to 3y ago
This is a low effort post. Please don’t do that here. What about these words compelled you to post them? Tell us what’s in your brain!
- laserdancepony 3y ago
  [flagged]
  - op00to 3y ago
    You’re annoying.

Embrace, Extend, Extinguish.

by throw7 3y ago

Embrace, Extend, Extinguish.

There was no embrace step; systemd served to replace sysvinit with a new way of doing things, supporting sysvinit scripts for backwards compatibility only. There was no extend; systemd's sysvinit scripts didn't have features which are lacking from the original sysvinit in an effort to cause the proliferation of sysvinit scripts which only work with systemd. EEE is a very specific strategy. It's not the general concept of making a new system to replace an old system.

Brian_K_White 3y ago
But it never actually did support sysv init scripts, because it fundamentally can't. All it has is ExecStart which is trivial garbage that does not replicate or emulate sysvinit functionality at all. I had a tiny little simple 2k init script that managed lxc containers. It provided: * graceful start all at boot * graceful wait while shutdown all at shutdown * Enable/disable of individual containers * Start/stop of individual containers * Console access to individual containers * Query status (running/not/etc) of individual containers at any time. * Query status of entire metaservice at any time All without any manager/monitor daemon either for the metaservice or the individual containers, and the script was tiny, maybe not even 2k. Under systemd, it's not possible to have an init script that can just check the status and then exit again, and where the definition of status is whatever conditions you want to code up. There is no ExecStatus because the fundamental way systemd tracks upness or downness is not by performing an action to get the answer but by monitoring a process or a port or a file itself. It requires a constantly running daemon of some sort that systemd can detect that it exited or is still running, or it requires one of a few other things that systemd just declares as all the possible options anyone can ever need. A port, a file, a process etc. The way my script answered the up or down question was it examined a few things about the container and decided based on what it saw. There didn't need to be any persistent process dedicated to monitoring a container, or all containers. The containers could run any sort of processes and didn't have to do anything a certain way in order to coordinate. IE, a container might have it's own copy of init as it's pid 1, or just bash, or screen, or a random binary. The script got it's info from kernel cgroups info by reading files and making a determination based on the contents of the files. It did this on demand and only when requested. There was no server process to monitor, no pid/lock file to monitor, no port to monitor. I'm not saying the cost of another process is so intolerable, I'm saying you can't actually do whatever you might want to do. You can only do that which the lord hath provided for. In a sysv script, you are free to code up whatever unpredictable logic you may happen to need, without the init author from 50 years ago having to predict what your needs will be and providing some managed limited answer for those specific predicted needs. Init not only doesn't care what you write in your script, it doesn't even care if it's a script at all. It doesn't have to be sh or even any scripting language, it could be a binary. The joy and relief of systemd is the relief of "everything would be so much simpler if everyone just did exactly the same thing", which is the same as saying if everyone else just did what I say. Here's how you know systemd's claim to being a good citizen is bs: Why can't I run systemd as just another service that isn't pid 1? I would have had far less problem with systemd merely existing in the world if it were like say xinetd where it could be run as a service that managed other services that wanted it, but was not pid 1 because I happen to want init, or any other thing of my choice to be pid 1, for whatever my reasons are, and systemd nor Poettering nor anyone else has any right to know or care what those reasons are, certainly not to decide for me that they are not valid. systemd presumes to know all the possible valid ways any service could operate, and any service that isn't covered is conveniently by definition invalid or insane, and so doesn't matter. Systemd is tight coupling. In every other aspect of IT, tight coupling is recognized as inflexible bad architecture. And this is all just the process/service management parts. The binary logs are a whole other example of tight coupling. It's a pattern.
- kaba0 3y ago
  Maybe read the manpages, instead of ranting.
  - Brian_K_White 3y ago
    Maybe you should? I took the time to describe an actual problem, you didn't even so much as link to the supposed page that you imply negates it. Regardless, no man page "informs away" the tight coupling. How can you even remove support for something if you aen't coupled enough that it's even possible become no longer compatible? The very fact that the announcement "we're deprecating init scripts" even makes any sense proves the point all by itself.

op00to 3y ago

This is a low effort post. Please don’t do that here. What about these words compelled you to post them? Tell us what’s in your brain!

laserdancepony 3y ago
[flagged]
- op00to 3y ago
  You’re annoying.