Lennart Poettering, Christian Brauner founded a new company

Post by storystarling » Tue, Jan 27, 2026, 9:55 PM UTC

forty wrote: post #107

storystarling wrote: post #97

Earlier quoted context omitted.

Quadlet actually solves this. It's the newer way to define containers for systemd and handles the rootless user case properly. I migrated my services to it recently and it's much more robust than the old generate scripts.

Quadlet are great but running podman via systemd as a non root user worked perfectly well before quadlets and I have no idea what your parent is talking about (I'm currently in the process of converting my home services from rootless podman over systemd to quadlet)

Post by warkdarrior » Tue, Jan 27, 2026, 9:56 PM UTC

dTal wrote: post #43

blixtra wrote: post #23

Earlier quoted context omitted.

As per the announcement, we’ll be building this over the next months and sharing more information as this rolls out. Much of the fundamentals can be extracted from Lennart’s posts and the talks from All Systems Go! over the last years.

I'm sorry, you're "happy to answer questions" and this is your reply to such a softball? What kind of questions will you answer? Favorite color?

Post by storystarling » Tue, Jan 27, 2026, 10:00 PM UTC

plagiarist wrote: post #179

storystarling wrote: post #97

Earlier quoted context omitted.

Quadlet actually solves this. It's the newer way to define containers for systemd and handles the rootless user case properly. I migrated my services to it recently and it's much more robust than the old generate scripts.

Could you give an example system-level quadlet that accepts connections on a low port, like 80, but runs the actual container as a non-root user (and plays nice with systemd, no force kill after timeout to stop, no reporting as failed for a successful stop)? My understanding is quadlet does not solve this, and my options are calling "systemctl --user" or "--userns auto". I would love to be wrong here.

Post by bri3d » Tue, Jan 27, 2026, 10:01 PM UTC

mikkupikku wrote: post #176

bri3d wrote: post #155

Earlier quoted context omitted.

The technology needed to implement DRM has been there for 20+ years and has already evolved in the space where it makes sense from an "evil" standpoint (if you're on that particular side of the fence - Android client attestation), so someone implementing the flip side that might actually be useful doesn't particularly bother me. I remember the 1990s "cryptography is the weapon of evil" arguments too - it's funny how…

The technology already exists and also there is unmet industrial market demand for the technology. Incoherent. If it already exists as you say, then Lennart should fuck off and find something else to make.

Post by jacquesm » Tue, Jan 27, 2026, 10:02 PM UTC

blibble wrote: post #183

dijit wrote: post #170

Earlier quoted context omitted.

The trick is the same: use a popular linux distribution and don't fight the kinks. The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way. SystemD is very opinionated, so you'd assume it wouldn't have the same results, but it does.. if you use a popular distro then they've done a lot of the hard work t…

I only use debian pulseaudio I had to fight every single day, with my "exotic" setup of one set of speakers and a headset with pipewire, I've never had to even touch it systemd: yesterday I had a network service on one machine not start up because the IP it was trying to bind to wasn't available yet the dependencies for the .service file didn't/can't express the networking semantics correctly this isn't some hacked u…