4 ms·

> sysvinit had no problem being told to mount /usr [..] if you set up an init script to run before /usr was available, > the world needs to make sure /usr is m

> sysvinit had no problem being told to mount /usr [..] if you set up an init script to run before /usr was available, > the world needs to make sure /usr is mounted before systemd even gets started, so systemd doesn't have to fix its bug. Unironically in the same post despite being, to my untrained eye, the same thing.

amiga386 1y ago
The difference being that the authors of sysvinit didn't advertise obnoxious messages at boot time (https://systemd.io/SEPARATE_USR_IS_BROKEN/ https://systemd.io/SEPARATE_USR_IS_BROKEN/) and try to get the filesystem standards changed. One is like "I'll run some scripts in order, everything else is on you", the other is like "I'll take care of everything, I'll do that, WHAT YOU DIDN'T MOUNT /USR ? SHAME ON YOU I DON'T WANT TO DEAL WITH THAT CORNER-CASE"
- immibis 1y ago
  In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc). From the creators of systemd we also have GNOME, PulseAudio, and Wayland. They have some design philosophy in common. BTW most sysvinit distros barely even use sysvinit. sysvinit is a service monitor, similar to systemd but more primitive, but typically most of what it's configured to do is to launch some shell scripts on startup. We really have "systemd distros" and "ad-hoc script distros", not sysvinit distros ("ad-hoc" is not a pejorative). I don't know why they don't make init a shell script directly - you can do that, and it's typically done that way in initramfs.
  - jcgl 1y ago
    > In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc). Name one thing you can do in sysvinit (or "ad-hoc script"-init) that you cannot do in systemd. With systemd, you're still entirely free to write your own artisinal shell spaghetti and jam it in alongside the otherwise clean unit structure.
    - immibis 1y ago
      name one thing you can do in systemd that you can't do in assembly code
      - jcgl 1y ago
        Assuming that your comment is in good faith, that comparison doesn't work in the way I think you're trying to make it work. systemd operates (when used normally) at a higher level of abstraction than a bucket-of-scripts/sysvinit. Especially because systemd units are declarative, this higher level of abstraction affords you (the sysadmin) the ability to more precisely specify the behavior you want. However, you can of course run scripts from systemd, so you've got whatever escape hatches you like. My question was asking if there was anything in sysvinit that those escape hatches didn't cover adequately. Assembly, on the other hand, operates at a far lower level of abstraction. Inappropriately low, in fact. Because of this, you actually have less practical ability to specify the precise behaviors you want. For example, you'd be hard-pressed to use assembly to start a webserver after the network is up but before some other piece of software that depends on the webserver.
- Brian_K_White 1y ago
  systemd is my hammer having it's own opinions about what nails I hit & where & into what & why. I want a nail only driven half in and at some crooked angle, that's my business. It's not my hammers job to agree or disagree that it's a bad nail hammering job as far as it knows. I don't wantto have to convince it of the validity of a use-case it didn't think of before, or thought of and decided it doesn't agree to support. I just want that crude coat hanger and I don't care who else likes it or doesn't like it or who else thinks I should buy an actual coat hanger and attach it in some way that someone else approves of.
  - ElectricalUnion 1y ago
    > systemd is my hammer having it's own opinions about what nails I hit & where & into what & why. I feel like the exact opposite. systemd has way too many layers of customization. Things can be in /etc/systemd/system/, /run/systemd/system/, /usr/lib/systemd/system/* and those are just the "basic" override locations. And those edits and masks usually don't clash with each other, so your customizations and quirks stick, even if the rest of your system changes. Now, if you are in a system that doesn't use systemd, if you mess with the "sacred and sanctioned" system service summoning scrolls, now you're on your own to diff whoever stuff the maintainer did, every time the summoning scroll changes, and to make sure that probably Turing-complete mess still summons a valid, working and safe system component instead of rampaging thru your system.
    - bitwize 1y ago
      Systemd is what happens when a software engineer says "What you have here is not a hammer but a Wood Fastening Device Driver..." We used to throw such people into moats. https://www-users.york.ac.uk/~ss44/joke/toast.htm https://www-users.york.ac.uk/~ss44/joke/toast.htm
    - jcgl 1y ago
      > Things can be in /etc/systemd/system/, /run/systemd/system/, /usr/lib/systemd/system/* and those are just the "basic" override locations. And those edits and masks usually don't clash with each other, so your customizations and quirks stick, even if the rest of your system changes. I really encourage you to learn the difference between these three places. They are semantically distinct, and it's truly an advantage to have the system distinguish them. They're all sources of configuration, of course. But one is managed by the OS vendor, one by the sysadmin, and one by the sysadmin at runtime. Runtime isn't as significant a distinction, but having a clear, bright line between vendor-provided and sysadmin-managed config is huge.
- ElectricalUnion 1y ago
  I read that message as "Whoever is the poor soul attempting to fix this system that doesn't boot, (because who otherwise inspects early boot messages?) whoever installed this system is running a known-fragile configuration." And that's what I expect of systemd? That it should complain loudly whenever me, the daemons I'm attempting to run, or the overall system is doing things in a weird, known-bad, known-fragile way and warn me about it before it breaks if possible.

amiga386 1y ago

The difference being that the authors of sysvinit didn't advertise obnoxious messages at boot time (https://systemd.io/SEPARATE_USR_IS_BROKEN/ https://systemd.io/SEPARATE_USR_IS_BROKEN/) and try to get the filesystem standards changed. One is like "I'll run some scripts in order, everything else is on you", the other is like "I'll take care of everything, I'll do that, WHAT YOU DIDN'T MOUNT /USR ? SHAME ON YOU I DON'T WANT TO DEAL WITH THAT CORNER-CASE"

immibis 1y ago
In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc). From the creators of systemd we also have GNOME, PulseAudio, and Wayland. They have some design philosophy in common. BTW most sysvinit distros barely even use sysvinit. sysvinit is a service monitor, similar to systemd but more primitive, but typically most of what it's configured to do is to launch some shell scripts on startup. We really have "systemd distros" and "ad-hoc script distros", not sysvinit distros ("ad-hoc" is not a pejorative). I don't know why they don't make init a shell script directly - you can do that, and it's typically done that way in initramfs.
- jcgl 1y ago
  > In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc). Name one thing you can do in sysvinit (or "ad-hoc script"-init) that you cannot do in systemd. With systemd, you're still entirely free to write your own artisinal shell spaghetti and jam it in alongside the otherwise clean unit structure.
  - immibis 1y ago
    name one thing you can do in systemd that you can't do in assembly code
    - jcgl 1y ago
      Assuming that your comment is in good faith, that comparison doesn't work in the way I think you're trying to make it work. systemd operates (when used normally) at a higher level of abstraction than a bucket-of-scripts/sysvinit. Especially because systemd units are declarative, this higher level of abstraction affords you (the sysadmin) the ability to more precisely specify the behavior you want. However, you can of course run scripts from systemd, so you've got whatever escape hatches you like. My question was asking if there was anything in sysvinit that those escape hatches didn't cover adequately. Assembly, on the other hand, operates at a far lower level of abstraction. Inappropriately low, in fact. Because of this, you actually have less practical ability to specify the precise behaviors you want. For example, you'd be hard-pressed to use assembly to start a webserver after the network is up but before some other piece of software that depends on the webserver.
Brian_K_White 1y ago
systemd is my hammer having it's own opinions about what nails I hit & where & into what & why. I want a nail only driven half in and at some crooked angle, that's my business. It's not my hammers job to agree or disagree that it's a bad nail hammering job as far as it knows. I don't wantto have to convince it of the validity of a use-case it didn't think of before, or thought of and decided it doesn't agree to support. I just want that crude coat hanger and I don't care who else likes it or doesn't like it or who else thinks I should buy an actual coat hanger and attach it in some way that someone else approves of.
- ElectricalUnion 1y ago
  > systemd is my hammer having it's own opinions about what nails I hit & where & into what & why. I feel like the exact opposite. systemd has way too many layers of customization. Things can be in /etc/systemd/system/, /run/systemd/system/, /usr/lib/systemd/system/* and those are just the "basic" override locations. And those edits and masks usually don't clash with each other, so your customizations and quirks stick, even if the rest of your system changes. Now, if you are in a system that doesn't use systemd, if you mess with the "sacred and sanctioned" system service summoning scrolls, now you're on your own to diff whoever stuff the maintainer did, every time the summoning scroll changes, and to make sure that probably Turing-complete mess still summons a valid, working and safe system component instead of rampaging thru your system.
  - bitwize 1y ago
    Systemd is what happens when a software engineer says "What you have here is not a hammer but a Wood Fastening Device Driver..." We used to throw such people into moats. https://www-users.york.ac.uk/~ss44/joke/toast.htm https://www-users.york.ac.uk/~ss44/joke/toast.htm
  - jcgl 1y ago
    > Things can be in /etc/systemd/system/, /run/systemd/system/, /usr/lib/systemd/system/* and those are just the "basic" override locations. And those edits and masks usually don't clash with each other, so your customizations and quirks stick, even if the rest of your system changes. I really encourage you to learn the difference between these three places. They are semantically distinct, and it's truly an advantage to have the system distinguish them. They're all sources of configuration, of course. But one is managed by the OS vendor, one by the sysadmin, and one by the sysadmin at runtime. Runtime isn't as significant a distinction, but having a clear, bright line between vendor-provided and sysadmin-managed config is huge.
ElectricalUnion 1y ago
I read that message as "Whoever is the poor soul attempting to fix this system that doesn't boot, (because who otherwise inspects early boot messages?) whoever installed this system is running a known-fragile configuration." And that's what I expect of systemd? That it should complain loudly whenever me, the daemons I'm attempting to run, or the overall system is doing things in a weird, known-bad, known-fragile way and warn me about it before it breaks if possible.