Why I dislike systemd

Thanks, that wasn't the point. What I was trying to say is that if you use those helpers you're looking up stuff in a man page anyway, so knowing shell scripting isn't enough any longer.

My personal opinion is that having a simple, INI-derived language is better than keeping the weirdness of the shell language just to assign a couple of variables (and you can still launch shell scripts from units anyway).

> Looks pretty good to me.

Ok, let's put it to a simple test :).

# pkcheck --action-id org.freedesktop.udisks2.ata-standby pkcheck: Subject not specified

# man pkcheck /subject

It means to say that you have to specify a PID for which to check that. But the word "subject" doesn't even appear in the pkcheck manpage.

The synopsis also lists three possible forms for --process. However, only one of them is valid and (the developers currently think) presents no race conditions. There's a note warning that the other two are buggy, but they're still accepted for compatibility reasons, because those two (buggy) methods have been standard for years.

> I think that's the nature of the problem domain. polkit seems to be for enforcing arbitrary rules, when the built-in rules of something like sudo can't cope. Therefore: arbitrary code snippets as rules, therefore, no introspection.

I don't think it's the nature of the problem domain. The "arbitrary rules" can have a user- or group-base restriction. It's an architectural limitation that the system cannot go through the list of all currently enforceable rules and return those that match a particular user.

> However, [...] Gives a list of actions. Use pkcheck to probe for access.

The problem is that pkcheck verifies whether or not a certain process can execute a function. You can sort of hack it to do that, but it's not always effective.

By the way, the reason I need to be able to do it is the following gem:

> There is no guarantee that a function registered with addRule() or addAdminRule() is ever called - for example an early rules file could register a function that always return a value, hence ensuring that functions added later are never called.

This is extremely unpleasant, because you can (I have) run into problems of the following sort:

* I insert a rule with a particular priority that gets registered and runs. Ok, no problem.

* Later on, inserts another rule which returns a value, thus terminating the rule chain before my rule gets to run.

Now all I find is that my own rule is not enforced, but I can't tell why that happens. There's no trivial way to trace the rule chain.

It also doesn't help that errors in rule files seem to go unreported. If you type "heel" instead of "wheel" for a group name, the whole thing will happily carry on, or at least I haven't yet figured out how to look for those errors.

> That says nothing about why the systemd folks are entitled to hijacking a kernel flag instead of (more sanely) namespacing their own debug flag

"No, we very much expose /proc/cmdline for a reason. System services are supposed to parse it, because it gives a unified way for people to pass in various flags. [...] And yes, that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature."

http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01488.html

> which is the actual bug that was filed (and in turn met with "it's not a bug it's a feature,

And that is the appropriate response to the bug that was filed, with the title "Do not parse "debug" command line parameter".

The bug report makes it immediately clear that this is not really about a technical problem that ought to be solved - no, the dirty user-space programmers should get their stinking paws off of our good kernel command line flags, how dare they!

Kay pointed out in his first comment that there is already a different parameter that turns on debug output only for the kernel; the reporter said he's too lazy to start using it.

And this is not about "entitlement": there is a clear administrative use-case for systemd using the debug parameter: if your system doesn't boot you want a simple and obvious way to turn on debug logging in all of the relevant plumbing code, whether it's in the kernel, in the initrd or during service startup. You shouldn't have to remember five different parameters because then you'll forget one and your outage lasts 10 minutes longer.

If the bug report had been something more like "I've enabled debug and my system failed to boot" without prescribing a particular fix and leaving that at the maintainer's discretion, it wouldn't have been resolved as NOTABUG but fixed quickly.

Of course, a wiser and more socially skilled maintainer than Kay Sievers would have immediately filed a follow-up bug report, or re-titled the bug report instead of lowering himself to the level of the reporter and playing resolve-reopen ping pong. (Fortunately the systemd project also also has some more patient maintainers like Tom and Zbigniew.)

And "your" and "objection" are erroneous, there. (-: Hint: ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc

I agree that such a flag would be useful, too, in which case the systemd folks could very well have consulted with the kernel folks in advance to work out a deprecation path for the kernel-only behavior and an introduction path for a generic behavior that activates the respective kernel-specific and systemd-specific flags.

The problem is that such collaboration didn't happen, and the systemd folks assumed that they were the center of the universe and decided "well fuck the kernel, we're going to use the 'debug' flag for ourselves, everything else be damned", thus causing breakage and flamewars. Had they taken the 10 seconds to write up an email on LKML or somesuch saying "hey, we think the 'debug' flag should apply to everything, not just the kernel; y'all game?", the vast majority of the fallout would have never existed.