3 ms·

That's been pretty much the opposite of my experience, but I can definitely see why it would make a minimalist, or a natural first principles thinker miserable.

constantcrying 3y ago
Okay, riddle me this: I have a systemd unit which creates systemd mounts. Will these mount points be mounted if they are enabled and started? Does it matter if there is a systemd daemon reload in the unit file after creating the mount units? Other init systems are just shell scripts calling shell scripts in some order, it is very easy to reason about that. Obviously it would work.
- eternityforest 3y ago
  To be perfectly honest I don't actually know... I usually find things work About Like You'd Expect and the thing you're trying to do is in fact possible, but that's not really an answer. I guess that's a great example of how things can be amazing for one use case and horrid for others. I usually interpret having trouble reasoning about something as meaning whatever I'm doing is Not Best Practice for the tool I'm using. A lot of the time, I find there is a best practices solution I could do instead. When there isn't... yeah, that is in fact annoying and obnoxious.
  - constantcrying 3y ago
    It doesn't work. The reason for this are systemd transactions. And how they intersect with units. A daemon reload recreates the transaction, this allows e.g. new unit files to be correctly integrated into the dependency tree. As it turns out recreating the transaction from inside the transaction is not something systemd can do. I don't even have a technical judgement on this. It doesn't seem like that severe of a limitation, but my point is that it is extremely complicated and that systemd does not work the way people think it does. The real problem with systemd is that it often isn't the tool you should be using and that is what people are actually objecting too. Having a tool be extended to do things other tools are already doing for no conceivable reason. Why is the init system also the fstab, I don't think anyone would be able to actually explain coherently the thought process behind that.
    - eternityforest 3y ago
      I assume they want fstab integration because the goal is to have everything as fully declarative, and also because mount units have a much more explicit, spelled out syntax. It's also far easier to edit with automated tools than fstab, since it's separate files and there's no ad hoc text parsing to change one line. I am guessing they didn't do it in a more modular way because the target audience doesn't really have any intent of swapping out many pieces of the OS, and it would be extra work to implement? If you want to do stuff the devs intended, in the way they intended, it's fantastic, but it seems to disappoint people who need or want to customize.

constantcrying 3y ago

Okay, riddle me this: I have a systemd unit which creates systemd mounts. Will these mount points be mounted if they are enabled and started? Does it matter if there is a systemd daemon reload in the unit file after creating the mount units? Other init systems are just shell scripts calling shell scripts in some order, it is very easy to reason about that. Obviously it would work.

eternityforest 3y ago
To be perfectly honest I don't actually know... I usually find things work About Like You'd Expect and the thing you're trying to do is in fact possible, but that's not really an answer. I guess that's a great example of how things can be amazing for one use case and horrid for others. I usually interpret having trouble reasoning about something as meaning whatever I'm doing is Not Best Practice for the tool I'm using. A lot of the time, I find there is a best practices solution I could do instead. When there isn't... yeah, that is in fact annoying and obnoxious.
- constantcrying 3y ago
  It doesn't work. The reason for this are systemd transactions. And how they intersect with units. A daemon reload recreates the transaction, this allows e.g. new unit files to be correctly integrated into the dependency tree. As it turns out recreating the transaction from inside the transaction is not something systemd can do. I don't even have a technical judgement on this. It doesn't seem like that severe of a limitation, but my point is that it is extremely complicated and that systemd does not work the way people think it does. The real problem with systemd is that it often isn't the tool you should be using and that is what people are actually objecting too. Having a tool be extended to do things other tools are already doing for no conceivable reason. Why is the init system also the fstab, I don't think anyone would be able to actually explain coherently the thought process behind that.
  - eternityforest 3y ago
    I assume they want fstab integration because the goal is to have everything as fully declarative, and also because mount units have a much more explicit, spelled out syntax. It's also far easier to edit with automated tools than fstab, since it's separate files and there's no ad hoc text parsing to change one line. I am guessing they didn't do it in a more modular way because the target audience doesn't really have any intent of swapping out many pieces of the OS, and it would be extra work to implement? If you want to do stuff the devs intended, in the way they intended, it's fantastic, but it seems to disappoint people who need or want to customize.