Yet another win for Systemd.

  • MigratingtoLemmy@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    1 year ago

    Oh, my gripe is not with Poettering creating a systemd service for it (for I cannot dispute that systemd wrappers such as this does make life somewhat easier), but I would have liked perhaps a more distribution agnostic method of running NVMe-TCP in a way that the OS would not have to be booted. I suppose I do understand the community’s support for this: systemd is used by most of the popular distributions, and writing a service in it will enable systemd to maybe interleave this between other processes and perhaps fulfill the goal of producing a block device on an L3 network without booting userland.

    As one can probably surmise, I do not have a great understanding of how the process works - will have to figure out how MacOS did it first, and then about how Poettering implemented it. I think I’ll have a better idea of what the solution is geared towards.

    Thanks for your comment!

    • patatahooligan@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      I would have liked perhaps a more distribution agnostic method of running NVMe-TCP in a way that the OS would not have to be booted.

      From the pull request:

      This all requires that the target mode stuff is included in the initrd of course. And the system will the stay in the initrd forever.

      I think that’s as minimal a boot target as you can reasonably get, or in other words you’re as far away from booting the OS as you can get.

      So now the question is whether this uses any systemd-specific interfaces beyond the .service and .target files. If not, it should not take much effort to create a wrapper init script for the executable and run it on non systemd distros.

    • stella@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      “Magic was meant to serve men, never to rule over them.”

      Pragmatism > all else.