4 ms·

> Call me when `systemctl pull ...` fetches the binary and everything else needed to run it _and_ puts the .service file in the right spot. That would be prett

by JoBrad 1y ago

> Call me when `systemctl pull ...` fetches the binary and everything else needed to run it _and_ puts the .service file in the right spot. That would be pretty awesome, actually.

o11c 1y ago
I can already hear the systemd-haters complaining about The One True Unix Way™ is to have tools that only do one thing even if that leaves holes in their functionality. That seems like a `machinectl` task though.
speed_spread 1y ago
That would mean systemd entering package management territory. Now THAT would not be well received.
- zdw 1y ago
  IMO, docker layering over the OS's built-in package management and update lifecycle in an incompatible ways is far worse than systemd replacing the init system and other service management functionality. Back in the old days (late 90's, early 2k's) as a sysadmin I'd often write scripts to chroot or in other ways isolate services rather than run them as root, so extending the init system to handle those features feels like it's a logical extension, not a incompatible replacement.
- jeroenhd 1y ago
  systemd-sysupdate already exists. systemd won't run the software repository of course, but with systemd-sysupdate together with some overlay mounts you can get Steam Deck-like ease of use system updates. For software management in R/W environments, there's the podman + systemd combo that'll let you run containers like normal systemd services.
jeroenhd 1y ago
Isn't this literally what podman-systemd does? You don't exactly run a command to pull a container, but just like systemd you place a config file in the right directory, tell podman-systemd to reconfigure itself, and run the service the standard systemd way.
- baby_souffle 1y ago
  > Isn't this literally what podman-systemd does? That was my point, basically. You have two options: 1) the usual `curl` or `wget` to fetch the binary and the lib(s) and all the work of validating and putting them in place and the like and _then_ you can use a systemd/.service file to set up controls for the bin 2) podman pull and then either ask podman to make a .service file for you or write your own because only one of the two approaches has solved the package/distribution issue, containers are _not_ "less relevant given that systemd can twiddle the same isolation bits"
  - zdw 1y ago
    What "validating" does docker/podman pull do that is in excess of a curl of a file? One of the advantages of a real package manager is that it checks signatures on the content that is downloaded. The supply chain on a linux distro's package repos is much harder to break into than typosquatting into a docker registry somewhere.
    - baby_souffle 1y ago
      > What "validating" does docker/podman pull do that is in excess of a curl of a file? Every single thing has a sha hash so verifying that I actually downloaded what I meant to download is easy. This gets tedious if I have to `curl https://github.com/someUser/someProject/release/latest.tar.gz https://github.com/someUser/someProject/release/latest.tar.g...` and also get the `tar.gz.sha256` file (if they even publish one ...). Curl supports resuming a partial file (assuming the sending server also does) but it can't "know" ahead of time that the first 1/3 of the file I am downloading has already been fetched because it's also used by $someOtherArtifact. > One of the advantages of a real package manager is that it checks signatures on the content that is downloaded. So does docker/podman. > The supply chain on a linux distro's package repos is much harder to break into than typosquatting into a docker registry somewhere. Perhaps. For every "secure" package repo, I'll show you a much more up-to-date package in AUR/Nix.

by JoBrad 1y ago

> Call me when `systemctl pull ...` fetches the binary and everything else needed to run it _and_ puts the .service file in the right spot. That would be pretty awesome, actually.

o11c 1y ago

I can already hear the systemd-haters complaining about The One True Unix Way™ is to have tools that only do one thing even if that leaves holes in their functionality. That seems like a `machinectl` task though.

speed_spread 1y ago

That would mean systemd entering package management territory. Now THAT would not be well received.

zdw 1y ago
IMO, docker layering over the OS's built-in package management and update lifecycle in an incompatible ways is far worse than systemd replacing the init system and other service management functionality. Back in the old days (late 90's, early 2k's) as a sysadmin I'd often write scripts to chroot or in other ways isolate services rather than run them as root, so extending the init system to handle those features feels like it's a logical extension, not a incompatible replacement.
jeroenhd 1y ago
systemd-sysupdate already exists. systemd won't run the software repository of course, but with systemd-sysupdate together with some overlay mounts you can get Steam Deck-like ease of use system updates. For software management in R/W environments, there's the podman + systemd combo that'll let you run containers like normal systemd services.

jeroenhd 1y ago

Isn't this literally what podman-systemd does? You don't exactly run a command to pull a container, but just like systemd you place a config file in the right directory, tell podman-systemd to reconfigure itself, and run the service the standard systemd way.

baby_souffle 1y ago
> Isn't this literally what podman-systemd does? That was my point, basically. You have two options: 1) the usual `curl` or `wget` to fetch the binary and the lib(s) and all the work of validating and putting them in place and the like and _then_ you can use a systemd/.service file to set up controls for the bin 2) podman pull and then either ask podman to make a .service file for you or write your own because only one of the two approaches has solved the package/distribution issue, containers are _not_ "less relevant given that systemd can twiddle the same isolation bits"
- zdw 1y ago
  What "validating" does docker/podman pull do that is in excess of a curl of a file? One of the advantages of a real package manager is that it checks signatures on the content that is downloaded. The supply chain on a linux distro's package repos is much harder to break into than typosquatting into a docker registry somewhere.
  - baby_souffle 1y ago
    > What "validating" does docker/podman pull do that is in excess of a curl of a file? Every single thing has a sha hash so verifying that I actually downloaded what I meant to download is easy. This gets tedious if I have to `curl https://github.com/someUser/someProject/release/latest.tar.gz https://github.com/someUser/someProject/release/latest.tar.g...` and also get the `tar.gz.sha256` file (if they even publish one ...). Curl supports resuming a partial file (assuming the sending server also does) but it can't "know" ahead of time that the first 1/3 of the file I am downloading has already been fetched because it's also used by $someOtherArtifact. > One of the advantages of a real package manager is that it checks signatures on the content that is downloaded. So does docker/podman. > The supply chain on a linux distro's package repos is much harder to break into than typosquatting into a docker registry somewhere. Perhaps. For every "secure" package repo, I'll show you a much more up-to-date package in AUR/Nix.