3 ms·

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, th

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.
wredcoll 1y ago
I don't want my hammer to have a razorblade embedded in the handle so if I grab it "wrong" my hand gets sliced up. Look analogies work both ways!
- josefx 1y ago
  Poettering would assert that the razorblade is a part of their vision and systemd only supports modern, razorblade resistant hands anyways.
- Brian_K_White 1y ago
  There is no analogy that worked both ways here. Some fitting counter-analogy might exist, but this isn't it, because there are no razor blade analogs in the handle analog of init. I used hammer as the example because init is actually like a hammer. It is a dead simple impliment with limited scope and knowable, known, and absolutely predictable behaviors and properties. It doesn't actually do much of anything, which makes it infinitely flexible. By not having any will of it's own, it allows you to do more than a more complex, automatic, and integrated tool. It can't suddenly razor blade you because it doesn't have razor blades or any other special features in the first place. YOU are the complex integrator. And if you are not, I have no sympathy for you or whatever difficulty you have with responsibility. You can still have complex automation and management, built on top of simpler lower level agnostic layers and tools. There was never any requirement to remove that flexibility and elegant future-proof design in order to have all the things systemd promises (and really, merely promises, it does not actually deliver any better than anything else). Systemd is also a grand scope example of tight coupling. It's so bizarre how these supposed genius coders can commit such a huge example of something they all know to avoid like the plague in just a slightly different context.

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.

wredcoll 1y ago

I don't want my hammer to have a razorblade embedded in the handle so if I grab it "wrong" my hand gets sliced up. Look analogies work both ways!

josefx 1y ago
Poettering would assert that the razorblade is a part of their vision and systemd only supports modern, razorblade resistant hands anyways.
Brian_K_White 1y ago
There is no analogy that worked both ways here. Some fitting counter-analogy might exist, but this isn't it, because there are no razor blade analogs in the handle analog of init. I used hammer as the example because init is actually like a hammer. It is a dead simple impliment with limited scope and knowable, known, and absolutely predictable behaviors and properties. It doesn't actually do much of anything, which makes it infinitely flexible. By not having any will of it's own, it allows you to do more than a more complex, automatic, and integrated tool. It can't suddenly razor blade you because it doesn't have razor blades or any other special features in the first place. YOU are the complex integrator. And if you are not, I have no sympathy for you or whatever difficulty you have with responsibility. You can still have complex automation and management, built on top of simpler lower level agnostic layers and tools. There was never any requirement to remove that flexibility and elegant future-proof design in order to have all the things systemd promises (and really, merely promises, it does not actually deliver any better than anything else). Systemd is also a grand scope example of tight coupling. It's so bizarre how these supposed genius coders can commit such a huge example of something they all know to avoid like the plague in just a slightly different context.