> I feel like Docker and other containerization tools are becoming even less relevant given that systemd can twiddle the same isolation bits so there's no real difference in terms of security that using a container tool grants.

I see it as _exactly_ the opposite. Podman gives me more or less the same security controls as systemd and the package/delivery problem is solved.

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

▲

arianvanp 12 hours ago | parent | next [-]

Literally exists.

importctl pull-tar https://example.com/image.tar.gz && portablectl attach image

	▲	vlovich123 12 hours ago \| parent [-]
		Did you call him?

▲

nickysielicki 13 hours ago | parent | prev | next [-]

with podman-systemd/"Quadlet" we're basically there:

https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

	▲	trenchpilgrim 8 hours ago \| parent [-]
		I replaced all my home server services with this an uninstalled docker entirely. Been very nice.

▲

ndriscoll 12 hours ago | parent | prev | next [-]

nixos kind of does that except better. Usually just set services.foo.enabled to true along with any other config you want. It's also super easy to wrap services in a container if you want, and doing so is kept conceptually separate from dependency management. If you want to make your own systemd service, then referencing a package in `ExecStart` or whatever will make it automatically get pulled in as a dependency.

▲

9dev 13 hours ago | parent | prev | next [-]

That, and dependency management, no? I’m not going back to installing libwhathaveyou-dev-0.28c1 ever again.

▲

gf000 9 hours ago | parent [-]

Containers don't solve dependency Management, they just push it a layer up so it's only someone else's problem.

▲

trenchpilgrim 8 hours ago | parent [-]

That sounds like solving dependency management.

	▲	resize2996 2 hours ago \| parent [-]
		For certain values of 'someone else'

▲

JoBrad 13 hours ago | parent | prev [-]

> 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 13 hours ago | parent | next [-]

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.

▲

jeroenhd 12 hours ago | parent | prev | next [-]

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 9 hours ago | parent [-]

> 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 4 hours ago \| parent [-]
		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.

▲

speed_spread 13 hours ago | parent | prev [-]

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

	▲	zdw 12 hours ago \| parent \| next [-]
		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 12 hours ago \| parent \| prev [-]
		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.