[felixgallo]

You missed the point completely, I'm afraid. The point was that it's a leaky abstraction composed of half implemented concepts that devs have to add to their brain. It does not replace the existing functionality or improve it.

[jcrites]

Respectfully, actually, I think you missed the point. Linux itself offers a number of powerful features such as namespaces to isolate programs, capabilities that can be dropped, etc., including the User Namespace feature we're discussing presently [1].

Systemd's job and goal is to provide a simple configuration file format that makes it easy to enable these features with installed system daemons.

You may overlooking the parameters supported by systemd and their benefits. Admins get a single way to manage their services and dependencies, and a way to do that that works consistently across all services. These features can be enabled even if the services were not designed for it (e.g., chroot). With systemd you can employ these settings from the outside with any service, and that's a big advance. Difficult to achieve otherwise.

> The point was that it's a leaky abstraction composed of half implemented concepts

I am unclear what part you want to criticize. The Linux kernel is what provides the User Namespace feature. Systemd helps users take advantage of it. What part do you consider half-implemented or a leaky abstraction?

Please also consider whether you might have the wrong mental model for the feature or its employment. In particular, the documentation for PrivateUsers= says: "This is useful to securely detach the user and group databases used by the unit from the rest of the system, and thus to create an effective sandbox environment." The usage you had in mind when you wrote your comment may not be compatible with the purpose of PrivateUsers. I recommend reading up systemd.exec params [1] before criticism. PrivateUsers= is intended for scenarios like transient sandboxed environments, so I'd suggest we discuss a simpler example like PrivateDevices=

[1] http://man7.org/linux/man-pages/man7/user_namespaces.7.html

[felixgallo]

With all due respect, I'm afraid you're addressing a series of unrelated points and indulging, hopefully unintentionally, in a rhetorical smokescreen, which includes editing your original post to hide an important topic.

I'm aware of what systemd claims to be. I'm aware of the benefits that its fans claim it, and it alone has.

My criticism is not with the Linux kernel (!?!) or user namespacing as a concept. My criticism is that systemd takes all of the rich complexity of user namespacing and, in response, adds the flag 'PrivateUsers=yes' -- a boolean. That's not what user namespacing is for and now we have two problems: systemd, which has no business making that decision and has done it the wrong way, and the continuing need, which has not been solved by a boolean flag, for daemons to have competent, complex user namespaces. Now devs have to know both ways: the half-assed way, and the real way, instead of just having a tool that gives them the real way.

That's what we in the software design business call a shitty design that would make Guy Fieri blush. But I guess we're all in Flavortown now.

[mixedCase]

>The point was that it's a leaky abstraction composed of half implemented concepts that devs have to add to their brain.

As opposed to a multitude of implementations of varying quality and functionality for the same concept in each init script that needs it?.