4 ms·

> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to t

> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none. You should look at it differently, and then it'll make perfect sense. systemd has long stopped being just an init system. It's a system tooling suite. When thinking about systemd don't think "PID 1", think "Linux New System Software Suite". It's a big umbrella project in the style of Gnome and KDE. For example, systemd-boot is a perfectly normal bootloader that's just been systemd-themed. It has a "ctl" tool, has the same command-line aesthetics as other systemd-group tooling, and so on. It's not in any way dependent or even interested in the init system.

constantcrying 2y ago
>systemd has long stopped being just an init system. I think that this has always been the core criticism of anyone who objects to them. Besides systemd, the init system, just being very poorly thought out.
- dale_glass 2y ago
  What's poorly thought out about the init system? It's not perfect for sure, but on the whole I don't have any issues with it.
  - constantcrying 2y ago
    How much time have you spent writing and debugging systemd init files?
    - dale_glass 2y ago
      I've written a fair amount. Nothing much to debug in most of them.
      - constantcrying 2y ago
        Riddle me this: can I create new mount files inside a systemd unit and have them activated to mount the locations specified? Do I need a daemon reload, for this?
        dale_glass 2y ago
        That sounds like a job for systemd.generator. I don't think having an unit that generates units at runtime is an officially supported use case, since generators exist.
        constantcrying 2y ago
        This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help. >I don't think having an unit that generates units at runtime is an officially supported use case Are you sure? Can you tell me how I would find out?
        dale_glass 2y ago
        > This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help. That's the point. Any situation in which you have a system modify itself at runtime is a recipe for a headache. So you do your auto-generation first, then work from a stable state. > Are you sure? Can you tell me how I would find out? Aside from that this kind of recursion seems like a great way to get weird problems, and that generators exist for this exact thing, the whole design of systemd discourages this kind of trickery. Units are just supposed to start a command and little else. Maybe somebody made an official pronouncement on this somewhere, but my personal take on this kind of thing is that it's a bad idea, anywhere, not just systemd.

constantcrying 2y ago

>systemd has long stopped being just an init system. I think that this has always been the core criticism of anyone who objects to them. Besides systemd, the init system, just being very poorly thought out.

dale_glass 2y ago
What's poorly thought out about the init system? It's not perfect for sure, but on the whole I don't have any issues with it.
- constantcrying 2y ago
  How much time have you spent writing and debugging systemd init files?
  - dale_glass 2y ago
    I've written a fair amount. Nothing much to debug in most of them.
    - constantcrying 2y ago
      Riddle me this: can I create new mount files inside a systemd unit and have them activated to mount the locations specified? Do I need a daemon reload, for this?
      - dale_glass 2y ago
        That sounds like a job for systemd.generator. I don't think having an unit that generates units at runtime is an officially supported use case, since generators exist.
        constantcrying 2y ago
        This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help. >I don't think having an unit that generates units at runtime is an officially supported use case Are you sure? Can you tell me how I would find out?
        dale_glass 2y ago
        > This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help. That's the point. Any situation in which you have a system modify itself at runtime is a recipe for a headache. So you do your auto-generation first, then work from a stable state. > Are you sure? Can you tell me how I would find out? Aside from that this kind of recursion seems like a great way to get weird problems, and that generators exist for this exact thing, the whole design of systemd discourages this kind of trickery. Units are just supposed to start a command and little else. Maybe somebody made an official pronouncement on this somewhere, but my personal take on this kind of thing is that it's a bad idea, anywhere, not just systemd.