Dear developers,
please don’t use a programming language for configuration files. Seriously. Don’t. Just don’t. You are only making live hard for people.
Here is what my polkit custom desktop policy looked like in Fedora <= 17:
Identity=unix-group:wheel Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-rollback;org.freedesktop.packagekit.system-sources*;org.opensuse.cupspkhelper.mechanism.*;org.libvirt.unix.*;dk.yumex.backend.pkexec.run ResultAny=no ResultInactive=no ResultActive=yes
I think this is pretty straight forward, but some people found it confusing and too complex. So David rewrote it.
Now let’s see how the same looks in Fedora >=18:
polkit.addRule(function(action, subject) {
if (subject.isInGroup("wheel") && subject.active) {
polkit.log("action=" + action);
polkit.log("subject=" + subject);
if (action.id.indexOf("org.freedesktop.packagekit.package-install") == 0) {
return polkit.Result.YES;
}
if (action.id.indexOf("org.freedesktop.packagekit.package-remove") == 0) {
return polkit.Result.YES;
}
if (action.id.indexOf("org.freedesktop.packagekit.system-rollback") == 0) {
return polkit.Result.YES;
}
if (action.id.indexOf("org.freedesktop.packagekit.system-sources.") == 0) {
return polkit.Result.YES;
}
if (action.id.indexOf("org.opensuse.cupspkhelper.mechanism.") == 0) {
return polkit.Result.YES;
}
if (action.id.indexOf("org.libvirt.unix.") == 0) {
return polkit.Result.YES;
}
if (action.id.indexOf("dk.yumex.backend.pkexec.run") == 0) {
return polkit.Result.YES;
}
}
});
What do we learn from this?
I am not a Sys Admin. However, I am a Linux user for, well a long time lets say. I thought that Perl, Python and the lot were scripting/programming languages on their own. Also, I (naively) thought the shell script was there for us to set up configurations to our own liking. Am I mistaken in this? The use of JS will result in less hands on by more Linux users, which sort goes against the open community ideal I think.
Well, I wanted to add +1, but then I recalled my younger days, where I made my life easier by generating TeX tables with computed data from config files that were written in C hidden behind huge overuse of C macro preprocessor, so while it was C, it looked almost like a normal config, but this way I could compute data in the table automatically instead of pre-computing them elsewhere. But heh, the polkit example really looks, well, how to say it…, terrible. Just plain terrible. Why in the world would anyone want to use javascript for this kind of config?!
I think David outlined the reasons in his blog post pretty well. I have to admit that with JavaScript, one is way more flexible than with the old ini-style configuration. But I think that needs to go into the code, not into the configuration.
Right, configuration must not be Turing-complete, logic belongs in the code, not in the configuration.
Yeah, I kinda agree, but javascript is IMHO even worse than your usual kind of language. Just hearing it makes my head ache because of how mozilla folks handle the interpreter. I’ve had more than enough long nights trying to fix gxine because mozilla folks changed JSAPI again and gxine upstream is really slow at fixing these 🙁 On that note I cannot thank enough to Pavel Alexeev and a couple of other folks for maintaining js package in fedora and epel. I hope David will be luckier.
i find polkit to be absolutely opaque no matter how the rules are encode. it interferes in strange ways. e.g. external file systems aren’t mounted automatically unless some polkit ACL is changed. NetworkManager’s command line client refuses to bring up a VPN unless you’re on the console because some polkit ACL says so. it encodes an enormous number of ACL’s that affect operation in many ways yet it is absolutely poorly documented.
Isn’t that the same stunt they pulled with GRUB 2?
No, grub is even worse: The config is in a couple of bash scripts which are then parsed by another bash script that writes out the config. 😉 But at least it’s plain bash, no real language.
actually when i tried to adjust a setting for GRUB2, the reaction seeing the “config file” was TL;DR. instead of trying to understand, i just googled a quick (but not recommended) fix and applied that. lloking at the polkit config above, the reaction would be the same.
I won’t use a programming language for configuration files…
I won’t use a programming language for configuration files…
I won’t use a programming language for configuration files…
David, remember the mantra.
+1
now imagine an Apache config file written in Javascript 🙂 or Sendmail…
+100, and you didn’t even mention the dependency bloat. (Aren’t you usually the first one complaining about that? 😉 )
We want .pkla files back!
Appropriate use of those memes, well done, sir!
Came across that same mess in Arch Linux a few days ago. It adds layers of overhead to a perfectly fine configuration. Thats just sad.