Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Theodore Ts'o
Shared publicly - 2014-03-30 A realization that I recently came to while discussing the whole systemd controversy with some friends at the Collab Summit is that a lot of the fear and uncertainty over systemd may not be so much about systemd, but the fear and loathing over radical changes that have been coming down the pike over the past few years, many of which have been not well documented, and worse, had some truly catastrophic design flaws that were extremely hard to fix. For example, I still have the following magic installed in /etc/polkit-1/localauthority/50-local.d/dont-bug-me.pka:
[Don't Bug Me]
Identity=unix-group:sudo
Action=*
ResultActive=yes
I added this because Network Manager insisted on popping up a window and asking me to type my password whenever I tried joining a new network. And figuring out how to make Network Manager not do such a brain-damaged thing was so painful, that after going through reams of poorly documented XML schemas, and 50 language translations interspersed with actual configuration in various XML files, I just gave up and used the Big Hammer to make policykit just Completely Go Away.
I could tell similar horror stories about dbus when I had to debug various suspend/resume failures, which is something else which is similarly opaque and impossible to understand, but the point is that many of these failures have caused many people to want simple shell scripts, instead of having to crawl through badly designed XML schemas, or someone else's complex C or C++ code, just to figure out what the hell they did and how to patch around their design fail.
It's not entirely fair to charge all of this to Systemd's account, but I think one of the reasons why this happens is because+Kay Sievers and+Lennart Poettering often have the same response style to criticisms as the+GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away.
That being said, I recently did try moving my laptop to systemd, and I was pleasantly surprised by the Debian's integration --- it didn't blow away my rsyslog configuration, or do any number of a things that I'm worried about. +GNOME may start depending on more and more of systemd's features, and thus make it even harder to configure away its design failings, but that's+GNOME's problem, not systemd. And besides, this is why I'm using XFCE and not GNOME. :-)
I do find it very difficult sometimes to figure out why a particular systemd service gets started, and when I tried putting together a battery target which would automatically shut down various daemons that I don't need when I want to save power, it apparently somehow caused the brightness keys (fn-F5 and fn-F6) to mysteriously stop working --- and as I expected, it was impossible to debug. So instead of using a systemd target, I'll just hack together a shell script that runs the necessary "service <foo> stop" instead of using a systemd target. If things start breaking horribly, I'll file debian bugs, and try to find ways to work around the brain damage. The fact that I won't be able to edit shell scripts to work around brain damage is still a little anxiety-producing, and the fact it's much more difficult to create a runlevel which is "just like runlevel 3 but without certain services running" is unfortunate, but I'll give it a try and see how much pain is involved.
At least with Debian, it's relatively easy (at least at this point) to roll back to sysvinit if systemd proves to be intolerable. I figure I might as well try it now before I'm forced off of sysvinit and then discover all of the things that break and which can't be easily worked around.
[Don't Bug Me]
Identity=unix-group:sudo
Action=*
ResultActive=yes
I added this because Network Manager insisted on popping up a window and asking me to type my password whenever I tried joining a new network. And figuring out how to make Network Manager not do such a brain-damaged thing was so painful, that after going through reams of poorly documented XML schemas, and 50 language translations interspersed with actual configuration in various XML files, I just gave up and used the Big Hammer to make policykit just Completely Go Away.
I could tell similar horror stories about dbus when I had to debug various suspend/resume failures, which is something else which is similarly opaque and impossible to understand, but the point is that many of these failures have caused many people to want simple shell scripts, instead of having to crawl through badly designed XML schemas, or someone else's complex C or C++ code, just to figure out what the hell they did and how to patch around their design fail.
It's not entirely fair to charge all of this to Systemd's account, but I think one of the reasons why this happens is because+Kay Sievers and+Lennart Poettering often have the same response style to criticisms as the+GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away.
That being said, I recently did try moving my laptop to systemd, and I was pleasantly surprised by the Debian's integration --- it didn't blow away my rsyslog configuration, or do any number of a things that I'm worried about. +GNOME may start depending on more and more of systemd's features, and thus make it even harder to configure away its design failings, but that's+GNOME's problem, not systemd. And besides, this is why I'm using XFCE and not GNOME. :-)
I do find it very difficult sometimes to figure out why a particular systemd service gets started, and when I tried putting together a battery target which would automatically shut down various daemons that I don't need when I want to save power, it apparently somehow caused the brightness keys (fn-F5 and fn-F6) to mysteriously stop working --- and as I expected, it was impossible to debug. So instead of using a systemd target, I'll just hack together a shell script that runs the necessary "service <foo> stop" instead of using a systemd target. If things start breaking horribly, I'll file debian bugs, and try to find ways to work around the brain damage. The fact that I won't be able to edit shell scripts to work around brain damage is still a little anxiety-producing, and the fact it's much more difficult to create a runlevel which is "just like runlevel 3 but without certain services running" is unfortunate, but I'll give it a try and see how much pain is involved.
At least with Debian, it's relatively easy (at least at this point) to roll back to sysvinit if systemd proves to be intolerable. I figure I might as well try it now before I'm forced off of sysvinit and then discover all of the things that break and which can't be easily worked around.
172
40
95 comments
Jérôme Carretero
+
0
1
0
1
0
Reply
Thanks for the post. BTW, wicd can do that today. But sometimes I have issues with it, for example it is reporting information from 2 hours ago when the laptop was 20 km away, or can't connect to a network and then I have to stop the service and manually use wpa_supplicant and dhcpcd to connect to networks which can't connect with wicd o_O ... but I'm used to these quirks that I haven't complained yet.
ThantiK
+
0
1
0
1
0
Reply
+Theodore Ts'o, I'm guessing it doesn't handle that situation all that well; from my experience it tends to group the settings for APs based on mac address or something? -- I can have multiple password protected APs, and if the MAC changes, it asks for the password for that AP again. Doesn't ask for admin pw though - and I'm running systemd, no workaround was required.
J.O. Aho
+
1
0
1
0
1
0
Reply
I got the impression that systemd kind of breaks the "unix" philosophy of making one program which is good at one task, instead systemd feels like one program which tries to do everything and those fails to be good, but I do guess poor documentation and extreme high threshold to learn could be blamed to the reason people like me don't like systemd.+Lennart Poettering and+Kay Sievers maybe next release of systemd should just include fully detailed man/info pages describing all tweaks and settings in detail?
David Johnston
+
0
1
0
1
0
Reply
Improved logging would help. If the primary cause for a systemd event or an IPC call or any other state change, it would be easy to diagnose what happened. Logging process ids is pretty useless because the process will be long gone by the time you seevthe log. I had this problem when debugging random shutdowns on my android phone. Log the source by name instead.
Bill Bogstad
+
9
10
9
10
9
Reply
It is probably my old age, but it seems to me that almost nothing is documented in any detail any more where free/open source is concerned. The documentation was just barely adequate ten years ago and since then multiple layers of libraries/frameworks/XML based configuration files have been added (but lurking underneath is all the code & complexity of a decade ago). A basic desktop environment probably has several times the amount of code running on it now then it did back then without a similar increase in the documentation. For me at least, just reading the source is no longer an option. There is just too much of it.
Tom Gundersen
+
7
8
7
8
7
Reply
+Theodore Ts'o systemd is staying away from XML files to the extent possible (still some backwards compatibility to keep legacy dbus policies working, but it should be increasingly irrelevant as things get ported away from it). I understand that that was just an example, but at least we are not committing that particular sin.
In my subjective opinion+Kay Sievers and+Lennart Poettering are not at all closed to criticism (no comment on GNOME), but don't take my word for it, just post any technical problems you are having, or things that seem opaque/obscure and we will surely see if things should be changed (or simply better documented). As always, you should of course be prepared to defend your feature requests (or whatever it is) on technical grounds, not just things like "this doesn't feel quite like the stuff I'm used to, please make it feel differently" or other vague or philosophical complaints. For a kernel developer I suppose you won't have hard time though, moving from the LKML to the systemd mailing list is probably akin to moving from a war-zone to a spa. In my experience any contributions/questions are taken seriously and people are treated with respect, even though not everything gets merged nor all feature requests get implemented.
If you want commit access, simply start submitting high-quality patches and it will almost certainly be given to you; as it was to me and about a dozen other contributors (number pulled out of my ass, I lost count).
In my subjective opinion+Kay Sievers and+Lennart Poettering are not at all closed to criticism (no comment on GNOME), but don't take my word for it, just post any technical problems you are having, or things that seem opaque/obscure and we will surely see if things should be changed (or simply better documented). As always, you should of course be prepared to defend your feature requests (or whatever it is) on technical grounds, not just things like "this doesn't feel quite like the stuff I'm used to, please make it feel differently" or other vague or philosophical complaints. For a kernel developer I suppose you won't have hard time though, moving from the LKML to the systemd mailing list is probably akin to moving from a war-zone to a spa. In my experience any contributions/questions are taken seriously and people are treated with respect, even though not everything gets merged nor all feature requests get implemented.
If you want commit access, simply start submitting high-quality patches and it will almost certainly be given to you; as it was to me and about a dozen other contributors (number pulled out of my ass, I lost count).
Olav Vitters
+
5
6
5
6
5
Reply
+Theodore Ts'o: NetworkManager, Policykit arefreedesktop.org technologies, not GNOME. Interesting to see that you think that they are, or unaffected because you're using XFCE.
Regarding GNOME and "commit privs": I gave 2 MATE developersgit.gnome.org access and they can approve newgit.gnome.org accounts (so pretty sure almost all MATE developers havegit.gnome.org accounts atm). They took over some modules and a few of them can release tarballs (onhttps://download.gnome.org).
Regarding overusage of XML: the kdbus stuff will make the XML bit for dbus (not policykit) go away IIRC.
Filing bugs is good, that way things can be improved.
Regarding GNOME and "commit privs": I gave 2 MATE developersgit.gnome.org access and they can approve newgit.gnome.org accounts (so pretty sure almost all MATE developers havegit.gnome.org accounts atm). They took over some modules and a few of them can release tarballs (onhttps://download.gnome.org).
Regarding overusage of XML: the kdbus stuff will make the XML bit for dbus (not policykit) go away IIRC.
Filing bugs is good, that way things can be improved.
Nick Alcock
+
5
6
5
6
5
Reply
+Olav Vitters, I am overjoyed to find that dbus is migrating slowly away from XML, though its XML usage was nottoo odious as these things go. I was less overjoyed to find policykit migrating (with no backward-compatibility) from the rather unpleasant .pkla to, of all things, Javascript. (WTF WTF. Turing-complete configuration for security-critical services, and in a particularly badly-specified language to boot, what on earth gave anyone the idea that was a sensible thing to do?!)
Bernd Paysan
+
2
3
2
3
2
Reply
Great rant against unnecessary complexity; I completely agree! If you make things too complex (XML instead of simple [group] key=value files), they are too difficult to deploy and debug. Do we really want that?
And the support mentality is broken, too. Support is the primary business model around Free Software, so make you support good, and people will love your software (because it works, and if it doesn't, helpful people will make it work quickly). Remember: For every person complaining, there are 100 persons who have the same problem, but don't bother to complain.
And the support mentality is broken, too. Support is the primary business model around Free Software, so make you support good, and people will love your software (because it works, and if it doesn't, helpful people will make it work quickly). Remember: For every person complaining, there are 100 persons who have the same problem, but don't bother to complain.
Theodore Ts'o
+
1
1
2
1
2
1
Reply
+Olav Vitters I'm aware that PolicyKit and NM arefreedesktop.org, and not GNOME. OTOH, they blamed GNOME that it was GNOME's responsibility for configuring whether you need to pop up a password prompt every time you need to add a network printer, or connect to a wireless network. Or maybe it was that they blamed the distro packagers, and they blamed GNOME because in some cases you do want to lock down what networks NM can connect to, so it's something that should be configurable. And the moment it has to be configurable, GNOME's policy is to remove configurability, since if the user wants the option to do something different from GNOME's point of view (and GNOME has a very strong point of view), it's the user's bug, and not GNOME.
This is why I believe it will harm the user if and when GNOME starts using more systemd technologies. Because with systemd, you can no longer hack around its clients' design fail by hacking shell scripts, and GNOME doesn't care about people like me as users (only the clueless types that will buy Apple products anyway). What I did to hack around Policykit is actually quite evil from a security perspective, but the bottom line is that I couldn't figure out any other way to do it, and at least this way, I've neutered Policykit, so while I still think it's design is horrible, it's at least no longer getting in my way. And the moment wicd can actually competently handle a large number of AP's supporting a single SSID (such as can be found at any conference or on the googleguest wireless network), I can dump NetworkManager (and I suspect so will a lot of other people).
Effectively I've dumped GNOME in favor of XFCE, and my only concern now is that there are still some some places where various GtK applications still have GNOME dependencies. For example, it's due to some weird GNOME setting why roxterm refuses to let me change its keyboard accelerator. And by that, I mean more than just the can-change-accels registry entry/dconf entry/gconf entry. (D*mnit, if I liked manipulating secret registry entries, I'd still be using Windows.) But it's completely non-transparent why this GtK application is refusing to let me edit its keyboard accelerators, even after I tried editing the sekrit registry entry. Fortunately, I figured out which non-documented text file it uses to store its keyboard accelerators, and I hand-edited it to fix my problem. This example encapsulates everything that I hate and loathe about GNOME --- and to bring back this back to systemd, this is the sort of non-transparency and non-debuggability and non-flexibility that people fear about systemd. So for you systemd folks --- the reason why people hate systemd IMHO can be largely blamed on people worried that you already have a terminal case of GNOME disease.
This is why I believe it will harm the user if and when GNOME starts using more systemd technologies. Because with systemd, you can no longer hack around its clients' design fail by hacking shell scripts, and GNOME doesn't care about people like me as users (only the clueless types that will buy Apple products anyway). What I did to hack around Policykit is actually quite evil from a security perspective, but the bottom line is that I couldn't figure out any other way to do it, and at least this way, I've neutered Policykit, so while I still think it's design is horrible, it's at least no longer getting in my way. And the moment wicd can actually competently handle a large number of AP's supporting a single SSID (such as can be found at any conference or on the googleguest wireless network), I can dump NetworkManager (and I suspect so will a lot of other people).
Effectively I've dumped GNOME in favor of XFCE, and my only concern now is that there are still some some places where various GtK applications still have GNOME dependencies. For example, it's due to some weird GNOME setting why roxterm refuses to let me change its keyboard accelerator. And by that, I mean more than just the can-change-accels registry entry/dconf entry/gconf entry. (D*mnit, if I liked manipulating secret registry entries, I'd still be using Windows.) But it's completely non-transparent why this GtK application is refusing to let me edit its keyboard accelerators, even after I tried editing the sekrit registry entry. Fortunately, I figured out which non-documented text file it uses to store its keyboard accelerators, and I hand-edited it to fix my problem. This example encapsulates everything that I hate and loathe about GNOME --- and to bring back this back to systemd, this is the sort of non-transparency and non-debuggability and non-flexibility that people fear about systemd. So for you systemd folks --- the reason why people hate systemd IMHO can be largely blamed on people worried that you already have a terminal case of GNOME disease.
Robert Marcano
+
0
1
0
1
0
Reply
+Theodore Ts'o your problem with NetworkManager look like a bug in Debian configuration of polkit and not something global, It doesn't happen on my Fedora install.
New polkit don't use those INI style files, they use JavaScript code. That sound like a weird decision, but from a sysadmin point of view that has allowed me to define policies that were impossible to do with rigid configuration files.
New polkit don't use those INI style files, they use JavaScript code. That sound like a weird decision, but from a sysadmin point of view that has allowed me to define policies that were impossible to do with rigid configuration files.
Theodore Ts'o
+
2
3
2
3
2
Reply
+Tomasz Torcz systemctl list-dependencies will tell you what is required for a service is started, and will partially help if you want to figure why a service wasn't started. The problem is I was trying to do the reverse. That is, I'm trying to create a battery.target that is just like graphical.target,except that certain things like tor.target, pcscd.target, etc., that tend to wake up the CPU more than 10 times a second aren't started (and in fact will stop them if I run "systemctl isolate battery.target"). I could do this by creating a battery.target file that included some conflicts, but apparently that caused something else to get shutdown, and that something else made fn-F5 and fn-F6 stop to configure the screen brightness (although xbacklight -set 5 still worked).
So what I really need is a "systemctl --verbose isolate battery.target" which tells me exactly which services it is starting up, and which services it is stopping, and why. Basically, what I need is something like "make -n -d" (although hopefully with a slightly better output format). Maybe there's a secret command option or environment variable or log file that will tell me all of this. But I've looked through all of the FAQ's and man pages I could find, and I couldn't find it.
This is not a disaster, I'll just create a "powersave-battery" shell script that will run the "service pcscd stop", "killall -9 scdaemon", etc. commands explicitly. Shell scripts are explicit, and easily debuggable. Systemd may be "magic" in that it doesn't require all of this explicit commands, but debugging its implicit dependencies and conflicts makes all of the magic disappear, and makes the result pure hell.
So what I really need is a "systemctl --verbose isolate battery.target" which tells me exactly which services it is starting up, and which services it is stopping, and why. Basically, what I need is something like "make -n -d" (although hopefully with a slightly better output format). Maybe there's a secret command option or environment variable or log file that will tell me all of this. But I've looked through all of the FAQ's and man pages I could find, and I couldn't find it.
This is not a disaster, I'll just create a "powersave-battery" shell script that will run the "service pcscd stop", "killall -9 scdaemon", etc. commands explicitly. Shell scripts are explicit, and easily debuggable. Systemd may be "magic" in that it doesn't require all of this explicit commands, but debugging its implicit dependencies and conflicts makes all of the magic disappear, and makes the result pure hell.
Colin Guthrie
+
5
6
5
6
5
Reply
I have to say I find it very strange that some people here talk of "poor documentation" in relation to+systemd. Having hacked with open source stuff for the last decade or two, I have to say that the breadth and depth of systemd docs is quite staggering! It's definitely one of the best documented projects I've seen and the amount of supporting material in terms of blog posts and guides etc. is also very good. That's not to say more docs would not be appreciated! Documentation patches, man page fixes even code comment or spelling errors are all quite welcome and regularly get merged.
I also don't agree with the statement: "I think one of the reasons why this happens is because Kay Sievers and Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away." This has just not been my experience. While I've known Lennart for a number of years, I don't think I can remember any time when I've had this kind of response delivered with this kind of attitude. Sure, I've had some suggestions or ideas shot down before, but never with a "you're too dumb, go away" response - always with a good technical argument and nothing in the way of any kind of personal attack! Just read the systemd mailing list and see the kind of responses given - they are almost always productive discussions with any reasons to reject a patch given clearly based on technical merit. Being able to reject patches and steer a project is a key skill and accepting patches so as not to offend someone is probably the worst thing you could do.
But as Tom said above, the systemd mailing list is actually a nice place to be. Discussion are productive and rarely bike-sheddy or flamey.
Anyway, I'm glad you had a good experience with switching to systemd on your system and I hope you and others will reassess some of the opinions you have on the attitudes of the people involved.
I also don't agree with the statement: "I think one of the reasons why this happens is because Kay Sievers and Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away." This has just not been my experience. While I've known Lennart for a number of years, I don't think I can remember any time when I've had this kind of response delivered with this kind of attitude. Sure, I've had some suggestions or ideas shot down before, but never with a "you're too dumb, go away" response - always with a good technical argument and nothing in the way of any kind of personal attack! Just read the systemd mailing list and see the kind of responses given - they are almost always productive discussions with any reasons to reject a patch given clearly based on technical merit. Being able to reject patches and steer a project is a key skill and accepting patches so as not to offend someone is probably the worst thing you could do.
But as Tom said above, the systemd mailing list is actually a nice place to be. Discussion are productive and rarely bike-sheddy or flamey.
Anyway, I'm glad you had a good experience with switching to systemd on your system and I hope you and others will reassess some of the opinions you have on the attitudes of the people involved.
Theodore Ts'o
+
5
6
5
6
5
Reply
BTW, free hint. If you like gnome-terminal, but you don't like how gnome-terminal-server is constantly waking up the CPU for no good reason, try switching to roxterm. Hat tip to+Keith Packard for showing me this trick, which has allowed the CPU to stop being 99% in C2 state even when the system was idle, which was a serious drain on my battery life.
Tom Gundersen
+
1
2
1
2
1
Reply
+Theodore Ts'o if you increase the log level of systemd itself to 'debug', it should spit out a lot of info about what jobs are queued. Not sure if it will suit your precise use-case, but may be worth a try.
If you want to introspect the dependencies statically without actually starting the target, all the info should be exposed by "systemctl show <some unit file>", the frontend is not ideal for your use-case (as you probably want to do this recursively), but this info is also exposed over dbus if you prefer that (or you could parse the text output if that's your thing).
If you want to introspect the dependencies statically without actually starting the target, all the info should be exposed by "systemctl show <some unit file>", the frontend is not ideal for your use-case (as you probably want to do this recursively), but this info is also exposed over dbus if you prefer that (or you could parse the text output if that's your thing).
Michael Biebl
+
0
1
0
1
0
Reply
+Theodore Ts'o I'm surprised you mentioned network-manager in Debian as such an example because we went to great efforts to actually make it possible to use network-manager without admin privileges.
We do ship custom patches for network-manager, network-manager-gnome and gnome-shell to not require admin privileges and fall back to create user connections instead in such a case.
So you shouldn't ever see such a PolicyKit prompt.
See e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696256
We do ship custom patches for network-manager, network-manager-gnome and gnome-shell to not require admin privileges and fall back to create user connections instead in such a case.
So you shouldn't ever see such a PolicyKit prompt.
See e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696256
Theodore Ts'o
+
2
3
2
3
2
Reply
+Robert Marcano The problem is thereare some cases where you do want to constrain the user from hopping onto any random wireless network, and when you might not want the user adding arbitrary printers. This could cause security problems in some situations. So the distro folks have to make decisions over which case they think is more common, and their argument is that it should be configurable in something like the control panel. Since it isn't controllable, they have to pick a default, and sometimes the default causes rants such as this one: https://plus.google.com/+LinusTorvalds/posts/1vyfmNCYpi5.
OK, that's fine. My complaint is that once youdo want to configure things, it's hard or impossible to figure out how to do it. And I don't consider Javascript an improvement. Does that mean that you need to understand Javascript in order to join a wireless network for the first time? Does that even sound right to you?
OK, that's fine. My complaint is that once youdo want to configure things, it's hard or impossible to figure out how to do it. And I don't consider Javascript an improvement. Does that mean that you need to understand Javascript in order to join a wireless network for the first time? Does that even sound right to you?
Theodore Ts'o
+
1
2
1
2
1
Reply
+Tomasz Torcz Yes, I tried it with the --reverse. That still doesn't help me if I am trying to design a target which is shutting down services. It doesn't take conflicts into account.
And indeed, that's not really what I needed. What I really needed is a "what will happen if I run 'systemctl isolate battery.target', given my current system state vis-a-vis what services are currently running?"
And in turn, I need this because I want to shut down a number of services when I do the equivalent of "enter runlevel N" in sysvinit speak, where I created runlevel N by first cloning runlevel 3 via something like "rsync -avH --delete /etc/rc3.d /etc/rc4.d" and then manually adding and deleting some symlinks. From looking at the contents of /etc/rc4.d, it's immediately obvious what will happen when I enter runlevel 4, both in terms of which services will get started, and more importantly, which services will get stopped.
From looking at the contents of battery.target and related systemd config files, it is NOT obvious, especially with how the /etc/init.d backwards compatibility feature seems to create implicit phantom services files and phantom multiuser.target.wants entries.
And indeed, that's not really what I needed. What I really needed is a "what will happen if I run 'systemctl isolate battery.target', given my current system state vis-a-vis what services are currently running?"
And in turn, I need this because I want to shut down a number of services when I do the equivalent of "enter runlevel N" in sysvinit speak, where I created runlevel N by first cloning runlevel 3 via something like "rsync -avH --delete /etc/rc3.d /etc/rc4.d" and then manually adding and deleting some symlinks. From looking at the contents of /etc/rc4.d, it's immediately obvious what will happen when I enter runlevel 4, both in terms of which services will get started, and more importantly, which services will get stopped.
From looking at the contents of battery.target and related systemd config files, it is NOT obvious, especially with how the /etc/init.d backwards compatibility feature seems to create implicit phantom services files and phantom multiuser.target.wants entries.
Theodore Ts'o
+
2
3
2
3
2
Reply
+Michael Biebl I didn't realize the network-manager was fixed. I added the pkla file before the bug was filed, and I've kept it because it's not worth my effort to figure out which bugs I will unmask if I remove it. Last I checked, there was also an issue with adding a printer which is why I still have the dont-bug-me.pkla file.
BTW, the network manager commit described in the bug entry very much describes the GNOME philosophy. "Fixing the underlying problem is too hard, so we'll just remove functionality, and screw over users until we get around to fixing it correctly --- which might be never."
commit 443c95a6b9c8709f5d9038421df1856f190eeb24
Author: Daniel Gnoutcheff <daniel@gnoutcheff.name>
Date: Tue Jul 13 18:09:56 2010 -0400
nm-manager: start removing user settings services
It turns out that user settings services are strange and complicated
beasts. We will remove support for them, and we will later implement
security mechanisms on the system settings service that will do what
user settings services were intended to do.
This commit is a bulk removal of nm-manager's internal support code for
user settings services. The external API is largely unchanged, but
errors are returned if anyone ties to do something with user settings.
Work remaining includes some possible flattening of nm-manager's
internal code, along with code removal and API changes in other modules.
BTW, the network manager commit described in the bug entry very much describes the GNOME philosophy. "Fixing the underlying problem is too hard, so we'll just remove functionality, and screw over users until we get around to fixing it correctly --- which might be never."
commit 443c95a6b9c8709f5d9038421df1856f190eeb24
Author: Daniel Gnoutcheff <daniel@gnoutcheff.name>
Date: Tue Jul 13 18:09:56 2010 -0400
nm-manager: start removing user settings services
It turns out that user settings services are strange and complicated
beasts. We will remove support for them, and we will later implement
security mechanisms on the system settings service that will do what
user settings services were intended to do.
This commit is a bulk removal of nm-manager's internal support code for
user settings services. The external API is largely unchanged, but
errors are returned if anyone ties to do something with user settings.
Work remaining includes some possible flattening of nm-manager's
internal code, along with code removal and API changes in other modules.
Theodore Ts'o
+
0
1
0
1
0
Reply
+Robert Marcano I guess I still consider that to be papering over a fundamental design flaw in polkit or Networkmanager. Now different distributions may have different magic unix groups that you need to be in before you can connect to a new wireless network for the first time. And since I bet Fedora doesn't put new users into the "wheel" group by default, now if I am configuring a laptop for child or a friend, and they call up from the school saying, "help, I need to get onto the school network", the answer should not be that you have to text your password to them.
At the very least Network manager should have shipped with some default polkit files that used some standard group, and made sure that was extremely well documented, and encouraged distributions to add that group, so that whether you need to put random desktop users into "wheel" or "sudo" or maybe some new "network-manager-usable" group, it's standard across distributions.
At the very least Network manager should have shipped with some default polkit files that used some standard group, and made sure that was extremely well documented, and encouraged distributions to add that group, so that whether you need to put random desktop users into "wheel" or "sudo" or maybe some new "network-manager-usable" group, it's standard across distributions.
Michael Biebl
+
0
1
0
1
0
Reply
+Robert Marcano What if you don't want to add your users to group wheel? There are very valid reasons not to do that. Requiring users to be in group wheel to not be bothered by PK prompts is a workaround at best.
I think Debian is actually the only distro which does the network-manager integration properly, ie. make the connections system-wide if the user has admin privileges and user-owned, if not.
I think Debian is actually the only distro which does the network-manager integration properly, ie. make the connections system-wide if the user has admin privileges and user-owned, if not.
Robert Marcano
+
0
1
0
1
0
Reply
+Theodore Ts'o +Michael Biebl I just tested and on Fedora to use new wireless network doesn't need being a member of the wheel group. Fedora is using upstream (as always) GNOME (and NetworkManager) policies, so if Debian chose to change it, I don't consider it a "design flaw in polkit or NetworkManager". If Debian choose to change ls permissions to 700 and not allowing anyone but root to execute ls, It is not fair to say that the posix file permission model is flawed
Michael Biebl
+
0
1
0
1
0
Reply
What Fedora does is ship the NetworkManager policy with
<action id="org.freedesktop.NetworkManager.settings.modify.system">
<defaults>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
That means every local user can read the secrets from such a system connection. That is fine for a single-user system, but I consider that a security flaw for a multi-user installation
<action id="org.freedesktop.NetworkManager.settings.modify.system">
<defaults>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
That means every local user can read the secrets from such a system connection. That is fine for a single-user system, but I consider that a security flaw for a multi-user installation
Colin Guthrie
+
1
2
1
2
1
Reply
I think the worst possible solution would be to define a "network-manager-usable" group. That's just moving the problem space to a sysadm problem whereby you now have a magical list of groups you need to grok when managing users. The 'wheel' group is a a well-known group and having rules that skip various bits of auth (or substitute the user p/w for root p/w if the user is in the wheel group) based on this group makes sense. But just like "solving" audio device ACL issues by adding your user to theaudio group, I'd hate to see this being something we're expected to have to do. IMO it's much better to have a tool like e.g. msec in Mageia which lets you pick different security levels that adjust such things for you (although it's not received much love recently so doubt it wouldactually help in this case, but it is IMO the correct place to implement such features - totally outside the stack of GNOME, FDO or whatever - just a nice tool provided to help you configure your system).
Theodore Ts'o
+
1
2
1
2
1
Reply
+Michael Biebl OK, so that means that if a sysadmin tries to use Fedora for multi-user installation, they will be faced with a serious security flaw unless it's well documented or they know how to trace through reams of XML configuration files. Maybe that's a better default for most Fedora users, but I hope you agree that's not optimal, and still working around Network Manager brain damage.
Theodore Ts'o
+
0
1
0
1
0
Reply
+Colin Guthrie From a security perspective, unless you are willing to ship distro-specific patches (which is what Debian has done), I think the best way to salvage a bad situation is to create a new network-manager-usable group, and then add all users by default to it. (You certainly don't want to add new users to group wheel by default!)
Yes, it means that a system administrator who needs to lock down the system will need to edit /etc/groups, but better editing /etc/groups than forcing the system administrator to find an XML file, and then paw through 50 different translations of descriptions which was also inexplicably dropped into the same XML file, and edit said XML file. Sys admins are at least more used to understanding and editing /etc/groups, and if users are dropped into network-manager-usable by default, at least that way it's obvious that there is some group magic going on. I didn't say it was perfect, but IMHO it's a better way of papering over a Network manager Fail.
Yes, it means that a system administrator who needs to lock down the system will need to edit /etc/groups, but better editing /etc/groups than forcing the system administrator to find an XML file, and then paw through 50 different translations of descriptions which was also inexplicably dropped into the same XML file, and edit said XML file. Sys admins are at least more used to understanding and editing /etc/groups, and if users are dropped into network-manager-usable by default, at least that way it's obvious that there is some group magic going on. I didn't say it was perfect, but IMHO it's a better way of papering over a Network manager Fail.
Michael Biebl
+
1
2
1
2
1
Reply
Btw, just wanted to mention that I'm the Debian maintainer of the network-manager package and it is not my intention at all to bad-mouth NetworkManager. On the contrary, I think NetworkManager does a lot of things right and I'd hate to go back to the times where I had to deal with wpa_supplicant.conf and different wireless drivers and crap. I also don't think that the NetworkManager upstream developers have the we-know-better mentality and I have to say+Dan Williams is doing a great job and listens to user requests. But as always, there are things which can be done better. And the PK integration certainly is such a case.
As wicd was mentioned earlier, I just want to add that from a security POV it has an all-or-nothing approach and is much less flexible then NetworkManager. In wicd, everyone which is granted access to wicd can read the secrets fromall connections.
As wicd was mentioned earlier, I just want to add that from a security POV it has an all-or-nothing approach and is much less flexible then NetworkManager. In wicd, everyone which is granted access to wicd can read the secrets fromall connections.
Michael Biebl
+
0
1
0
1
0
Reply
+Robert Marcano I can not confirm that this has been fixed in Fedora. I've just tested this on a F20 installation:
a/ I've created a wireless connection as user A (the one which was created during installation with admin privs)
b/ I've created a second user B without admin privs and logged in as that user.
c/ I was able to read the stored wpa-psk created by user A using gnome-control-center or nm-connection-editor
a/ I've created a wireless connection as user A (the one which was created during installation with admin privs)
b/ I've created a second user B without admin privs and logged in as that user.
c/ I was able to read the stored wpa-psk created by user A using gnome-control-center or nm-connection-editor
Theodore Ts'o
+
0
1
0
1
0
Reply
+Michael Biebl I don't see Debian's patches in https://bugzilla.gnome.org/show_bug.cgi?id=660392. I assume you posted in some mailing list, as opposed to attaching the patches to the BZ entry? (Which might be the right way to do things in the NM development community; I don't know what their general practices are in this regard.)
Robert Marcano
+
0
1
0
1
0
Reply
+Michael Biebl my test was wrong, I couldn't see the system connection password with the test user because the password was set to "store only for this user", so a system connection with a system password is visible to all user as you say, my error.
As you say NM policies could be improved, but I don't see design problems with NM or polkit, I see implementation bugs.
I think I never noticed this problem because my multiuser installations always disable all ModemManager, NetworkManager, packagekit and udisk policies (and removable media only for some users) Seehttp://fpaste.org/90251/27776713/
As you say NM policies could be improved, but I don't see design problems with NM or polkit, I see implementation bugs.
I think I never noticed this problem because my multiuser installations always disable all ModemManager, NetworkManager, packagekit and udisk policies (and removable media only for some users) Seehttp://fpaste.org/90251/27776713/
Theodore Ts'o
+
1
1
2
1
2
1
Reply
One additional note: Reading through the BZ entry, the fact that developers can blithly say things like:
dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager
/org/freedesktop/NetworkManager org.freedesktop.NetworkManager.GetPermissions
Is how you should debug things, is a symptom of the problem. Exactly how are you supposed to know that the magic destination is "/org/freedesktop/NetworkManager/org.freedesktop.NetworkManager.GetPermissions"? And you say that editing /etc/rc.d files is opaque?!?
dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager
/org/freedesktop/NetworkManager org.freedesktop.NetworkManager.GetPermissions
Is how you should debug things, is a symptom of the problem. Exactly how are you supposed to know that the magic destination is "/org/freedesktop/NetworkManager/org.freedesktop.NetworkManager.GetPermissions"? And you say that editing /etc/rc.d files is opaque?!?
Theodore Ts'o
+
7
8
7
8
7
Reply
+Robert Marcano The fact that the way you are debugging these things is to create test accounts and login to them, and you could still be confused, is a symptom of the design failure. Policykit's over-complexity is just security accident waiting to happen. You thought your system was secure, but because you did the test wrong, you were wrong.
And adding a Turing-complete configuration language, and forcing sysadmins to use it, does not make a bad situation better. And if you are going to use a Turing-complete configuration language, I would argue that it should be shell scripts, since that way system administrators only have to learnone turing-complete configuratoin language. I can't wait until someone decides that the next critical piece of desktop infrastructure requires ruby as the configuration language. :-)
And adding a Turing-complete configuration language, and forcing sysadmins to use it, does not make a bad situation better. And if you are going to use a Turing-complete configuration language, I would argue that it should be shell scripts, since that way system administrators only have to learnone turing-complete configuratoin language. I can't wait until someone decides that the next critical piece of desktop infrastructure requires ruby as the configuration language. :-)
Dan Williams
+
3
4
3
4
3
Reply
The debugging process is similar to anything that uses IPC, just that there's a standard tool to talk the IPC (dbus-send) instead of every single piece of a system inventing its own protocol, parser, and front-end. That's a huge win for users
For your specific comment, the upcoming 0.9.10 release has "nmcli g perm" which shows you the permissions you have, like:
org.freedesktop.NetworkManager.settings.modify.system yes
org.freedesktop.NetworkManager.settings.modify.own yes
org.freedesktop.NetworkManager.settings.modify.hostname auth
We've spent a load of time over the last two years enhancing our command-line tools (nmcli) to ensure that NM can be used without any GUI whatsoever.
The core issue you had is that (a) WiFi connections are created system-wide for all users, partly so they are available before you log in, (b) creating network connections is inherently a privileged operation since networking is a shared resource, and (c) NetworkManager punches holes through the kernel's CAP_ADMIN restrictions to do this stuff, so we have to be really careful about security.
NetworkManager upstream shipped with a restrictive default security policy, which we intended to be customized by distributions. A desktop-targeted distro should probably set modify.system=yes while a server-targeted distro should set modify.system=auth_admin_keep. These rules can be further customized with PolicyKit logic on user/group/whatever basis. We probably did not communicate this adequately downstream.
+Michael Biebl has been a huge advocate for solving these issues in a better, more usable manner, and I'm very grateful to him for continuing to push this.
For your specific comment, the upcoming 0.9.10 release has "nmcli g perm" which shows you the permissions you have, like:
org.freedesktop.NetworkManager.settings.modify.system yes
org.freedesktop.NetworkManager.settings.modify.own yes
org.freedesktop.NetworkManager.settings.modify.hostname auth
We've spent a load of time over the last two years enhancing our command-line tools (nmcli) to ensure that NM can be used without any GUI whatsoever.
The core issue you had is that (a) WiFi connections are created system-wide for all users, partly so they are available before you log in, (b) creating network connections is inherently a privileged operation since networking is a shared resource, and (c) NetworkManager punches holes through the kernel's CAP_ADMIN restrictions to do this stuff, so we have to be really careful about security.
NetworkManager upstream shipped with a restrictive default security policy, which we intended to be customized by distributions. A desktop-targeted distro should probably set modify.system=yes while a server-targeted distro should set modify.system=auth_admin_keep. These rules can be further customized with PolicyKit logic on user/group/whatever basis. We probably did not communicate this adequately downstream.
+Michael Biebl has been a huge advocate for solving these issues in a better, more usable manner, and I'm very grateful to him for continuing to push this.
Colin Guthrie
+
3
4
3
4
3
Reply
+Theodore Ts'o "Policykit's over-complexity is just security accident waiting to happen". Absolutely! Ido like the power of it, but it's certainly very easy to open huge security holes.
Not all that long ago, I found a rather interesting tutorial which basically opened up a huge security hole due to bad javascript syntax! I thought it was a bad bug but limited in scope, but+Zbyszek Jedrzejewski-Szmek (another systemd guy) highlighted that it was actually even worse than I thought! The article is updated now so the bug is gone, but it was up there for some time giving out bad advice. I think the problem would have been avoided had the "configuration" syntax been a bit saner (i.e. not Turing complete!)http://www.linuxsysadmintutorials.com/configure-polkit-to-run-virsh-as-a-normal-user/
The dbus policy stuff is another example. I found a bug in a Fedora tool a year or so back (CVE-2012-1615) whose broken dbus policy let normal users access dbus interfaces they weren't meant to. In my case this allowed my user to restart any systemd services (due to the use of dbus). Ironically the tool in question was called "sectool". (https://bugzilla.redhat.com/show_bug.cgi?id=809437) Installing it for extra security kinda backfired!
Ultimately, I'mvery happy Lennart, Kay and Daniel (and others) are reworking the policy stuff to be more sane, with man pages and not XML based!
Not all that long ago, I found a rather interesting tutorial which basically opened up a huge security hole due to bad javascript syntax! I thought it was a bad bug but limited in scope, but+Zbyszek Jedrzejewski-Szmek (another systemd guy) highlighted that it was actually even worse than I thought! The article is updated now so the bug is gone, but it was up there for some time giving out bad advice. I think the problem would have been avoided had the "configuration" syntax been a bit saner (i.e. not Turing complete!)http://www.linuxsysadmintutorials.com/configure-polkit-to-run-virsh-as-a-normal-user/
The dbus policy stuff is another example. I found a bug in a Fedora tool a year or so back (CVE-2012-1615) whose broken dbus policy let normal users access dbus interfaces they weren't meant to. In my case this allowed my user to restart any systemd services (due to the use of dbus). Ironically the tool in question was called "sectool". (https://bugzilla.redhat.com/show_bug.cgi?id=809437) Installing it for extra security kinda backfired!
Ultimately, I'mvery happy Lennart, Kay and Daniel (and others) are reworking the policy stuff to be more sane, with man pages and not XML based!
Colin Guthrie
+
1
2
1
2
1
Reply
Regarding debugging,+Daniel Mack has written a wireshark extension to show kdbus stuff nicely over the wire, and Kay has written some nice command line tools to monitor the traffic there with nice highlighting and such like. I think the tools available in this area are definitely improving with kdbus!!
Theodore Ts'o
+
6
7
6
7
6
Reply
+Dan Williams If you need to use an IPC mechanism to debug a frustrating configuration problem, your product has failed. Whether it is using a standard IPC mechanism, or a non-standard one, or even wireshark, is besides the point. If you tell a user that using telnet to connect to a magic port (which isn't documented well) and type a series of HTTP commands, is a "win" because they get to use "standard tools", I predict you won't get a friendly response.
So while "nmcli g perm" may be an improvement, what's really important is that the user can find out, at that very moment that they are getting a frustrating popup dialog box demanding that they type in either their password or worse, the root password (both of which violates many security guidelines), there should be a way they should be told: here are the files and the line numbers that caused policykit to return the decision that it did.
And this is why having a turing-equivalent configuration language for policykit makes things worse, not better. It means that it's a lot harder to give the user a set of files and line numbers of indecipherable XML filled with translations of $!@! descriptions into Polish, Danish, German, etc., Instead, you would have to give them a full set of indecipherable Javascript files and hope the user can understand Javascript. Oh, Joy.
So perhaps the real problem is that network manager decided to rely on PolicyKit, which is a User Experience Disaster and complete Design Fail.
So while "nmcli g perm" may be an improvement, what's really important is that the user can find out, at that very moment that they are getting a frustrating popup dialog box demanding that they type in either their password or worse, the root password (both of which violates many security guidelines), there should be a way they should be told: here are the files and the line numbers that caused policykit to return the decision that it did.
And this is why having a turing-equivalent configuration language for policykit makes things worse, not better. It means that it's a lot harder to give the user a set of files and line numbers of indecipherable XML filled with translations of $!@! descriptions into Polish, Danish, German, etc., Instead, you would have to give them a full set of indecipherable Javascript files and hope the user can understand Javascript. Oh, Joy.
So perhaps the real problem is that network manager decided to rely on PolicyKit, which is a User Experience Disaster and complete Design Fail.
Dan Williams
+
4
5
4
5
4
Reply
I have no stake or opinion about what configuration PolicyKit uses. I agree that adding JavaScript support makes things less straightforward when diagnosing bugs, while the tradeoff is more flexibility. I'm going to opt out of this part of the discussion because I'm not involved in PolicyKit development at all.
In ageneral comment though, if not PolicyKit, thensomething is needed to handle finer-grained access control like PolicyKit does. sudo, suid, CAP_*, and every existing option before PolicyKit were coarse-grained and insufficient to implement flexible policy.
I'm also not very interested in creating a parallel, duplicated-effort solution that's specific to NetworkManager, because that's a ton more code to maintain and and it must work on all DEs/platforms including the command-line.
What I would suggest, if the existing PolicyKit does not do what you'd like it to do, or does not operate how you'd like it to, that you or somebody else improve PolicyKit in cooperation with the community to ensure that the goals of both you and the community that currently relies on PolicyKit are satisified. Otherwise we'll just keep turning the fragmentation wheel with multiple-but-incompatible implementations of the same general functionality.
We need something like PolicyKit, if not PolicyKit, or better yet, a better PolicyKit. Having a single "admin yes/no" switch is not sufficient.
In ageneral comment though, if not PolicyKit, thensomething is needed to handle finer-grained access control like PolicyKit does. sudo, suid, CAP_*, and every existing option before PolicyKit were coarse-grained and insufficient to implement flexible policy.
I'm also not very interested in creating a parallel, duplicated-effort solution that's specific to NetworkManager, because that's a ton more code to maintain and and it must work on all DEs/platforms including the command-line.
What I would suggest, if the existing PolicyKit does not do what you'd like it to do, or does not operate how you'd like it to, that you or somebody else improve PolicyKit in cooperation with the community to ensure that the goals of both you and the community that currently relies on PolicyKit are satisified. Otherwise we'll just keep turning the fragmentation wheel with multiple-but-incompatible implementations of the same general functionality.
We need something like PolicyKit, if not PolicyKit, or better yet, a better PolicyKit. Having a single "admin yes/no" switch is not sufficient.
Theodore Ts'o
+
3
4
3
4
3
Reply
+Dan Williams So this is where the kernel philosophy of "never add regressions" is really important. It may be that solving this problem of fine-grained permissions is an important one to solve. But solving this should not mean making things worse for other users! Removing functionality just to fix a bug, if it means a user-visible regression, is not acceptable in the kernel world. Regrettably, in the GNOME and FreeDesktop.org world, it seems to be something which is embraced with eagerness.
What I would have done if I were running things is to allow for a local configuration file that allowed for coarse-grained authentication. That way, for those people who were happy before Network Manager 0.9, wouldn't break when their distro upgraded to a newer version of Network Manager.
The decision to remove functionality was made in 2010, and here we are, in 2014, still Waiting For Godot. (At least to be merged upstream. Kudo's to+Michael Biebl coming up with a proper fix years earlier.)
It's the lack of taking responsibility for ones own product, and instead foisting off responsibility to some other component such as PolicyKit (or claiming it's the distro's fault), which is why people get really worried when something like Systemd shows up on the horizon, claiming to offer "new features", and the risk is that components such as Network Manager will start depending on the new hotness, abandon local, traditional Unix configuration schemes, which had the advantage that they were at least more comprehensible than XML and Javascript config files. The fact that using the new hotness might result in some new feature, or solving some Really Important Problem, doesn't really increase users' trust, when they know there is a distinct possibility the new hotness might result in a regression for the use case they care about.
P.S. In retrospect, it probably would have been better to have shipped NM with a number of sample polkit configuraiton files, one of which used traditional Unix group permissions, and explicitly told distributors that this was something important they needed to worry about, and given how awful PolicyKit was, here was some possible workarounds.
What I would have done if I were running things is to allow for a local configuration file that allowed for coarse-grained authentication. That way, for those people who were happy before Network Manager 0.9, wouldn't break when their distro upgraded to a newer version of Network Manager.
The decision to remove functionality was made in 2010, and here we are, in 2014, still Waiting For Godot. (At least to be merged upstream. Kudo's to+Michael Biebl coming up with a proper fix years earlier.)
It's the lack of taking responsibility for ones own product, and instead foisting off responsibility to some other component such as PolicyKit (or claiming it's the distro's fault), which is why people get really worried when something like Systemd shows up on the horizon, claiming to offer "new features", and the risk is that components such as Network Manager will start depending on the new hotness, abandon local, traditional Unix configuration schemes, which had the advantage that they were at least more comprehensible than XML and Javascript config files. The fact that using the new hotness might result in some new feature, or solving some Really Important Problem, doesn't really increase users' trust, when they know there is a distinct possibility the new hotness might result in a regression for the use case they care about.
P.S. In retrospect, it probably would have been better to have shipped NM with a number of sample polkit configuraiton files, one of which used traditional Unix group permissions, and explicitly told distributors that this was something important they needed to worry about, and given how awful PolicyKit was, here was some possible workarounds.
Olav Vitters
+
2
3
2
3
2
Reply
+Bernd Paysan: Initially you said:
"And the support mentality is broken, too. Support is the primary business model around Free Software, so make you support good, and people will love your software (because it works, and if it doesn't, helpful people will make it work quickly)."
I don't understand the relationship between primary business model and what you're saying now. You're not paying GNOME. We lack people who provide support, so there barely is any support. I don't see primary purpose of GNOME is to provide support. It would be very welcome if support was given, but that's not what is happening. So I'm wondering if you mean GNOME, or some company packaging GNOME.
Regarding: "we know it better and you are an idiot"-mentality, I think this is more assumption than based on interaction? Note that I base this exactly on the wording you've used/quoted.
"And the support mentality is broken, too. Support is the primary business model around Free Software, so make you support good, and people will love your software (because it works, and if it doesn't, helpful people will make it work quickly)."
I don't understand the relationship between primary business model and what you're saying now. You're not paying GNOME. We lack people who provide support, so there barely is any support. I don't see primary purpose of GNOME is to provide support. It would be very welcome if support was given, but that's not what is happening. So I'm wondering if you mean GNOME, or some company packaging GNOME.
Regarding: "we know it better and you are an idiot"-mentality, I think this is more assumption than based on interaction? Note that I base this exactly on the wording you've used/quoted.
Dan Williams
+
3
4
3
4
3
Reply
+Theodore Ts'o NM has for a long time had a configure-time option --enable-polkit=no if you don't wish to use PolicyKit. We did not see a good case for having it be a runtime decision that could be set from a config file, but that could be done.
I'd also note that, while I don't necessarily disagree with your suggestion for a simpler file-based permissions setup, adding support for that increases the number of codepaths for security-critical operations and increases the complexity ofany code, and it's important to recognize the tradeoffs. I'd much rather solve the problem by providing examples, fixing any PolicyKit issues, and taking improved approaches to permissions issues instead of adding another security-critical codepath.
I'd certainly agree that we dropped the ball on documenting the enhanced permissions framework that NetworkManager 0.9+ use, and how to take advantage of that using PolicyKit. We can and will do better.
I'd also note that, while I don't necessarily disagree with your suggestion for a simpler file-based permissions setup, adding support for that increases the number of codepaths for security-critical operations and increases the complexity ofany code, and it's important to recognize the tradeoffs. I'd much rather solve the problem by providing examples, fixing any PolicyKit issues, and taking improved approaches to permissions issues instead of adding another security-critical codepath.
I'd certainly agree that we dropped the ball on documenting the enhanced permissions framework that NetworkManager 0.9+ use, and how to take advantage of that using PolicyKit. We can and will do better.
Bernd Paysan
+
0
1
0
1
0
Reply
+Olav Vitters A lot of people pay for RedHat and SuSE. Support is so far the primary business model of free software, this is a fact; though advertising is gaining (it is also an important business model). The "we know it better"-mentality is something+Theodore Ts'o already mentioned; I've observed this mentality quite often. To be honest, even from Ted himself - remember the data loss with ext4? He said "it's POSIX compliant, case closed". Well, the case wasn't closed, and ext4 became more robust as a result, which is good, and shows that listening to your "customers" (whether they pay or not) is important, even if you think you had done a good job. Maybe the customer wants something else than you considered important. That's quite often the case.
Theodore Ts'o
+
2
3
2
3
2
Reply
+Bernd Paysan Absolutely. Even though the bug may have been in the applications (for not using fsync() when they should have), ultimately the number of application programmers outnumber the number of ext4 developers, and so we did what we could to fix most of the problem at our level. Yes, it meant adding a bit more code complexity into ext4, and it doesn't solve the problem 100% (that requires an application level fix; even if the file system does its best to paper over the problem, if the application doesn't use fsync(), and the user gets unlucky with the timing, datawill be lost. Ultimately, though, we shouldn't use the excuse that we can't solve 100% of the problem; it's better to do the best that you can.)
What's important is putting the user first --- and not some software engineering ideology.
What's important is putting the user first --- and not some software engineering ideology.
Olav Vitters
+
0
1
0
1
0
Reply
+Bernd Paysan: Red Hat and SuSE is not GNOME. It also seems that your definition of support is different than mine. So please explain further.
If you aren't satisfied with the level of support given by Red Hat or SuSE, then complain to them. But for GNOME, there barely is any support.
You're also comparing something which needs lots of usability testing (UI) with something which you can more easily determine technically (POSIX complaint vs what programs are doing). Those are worlds apart.
I've read the bugreports about where people complain about the default setting for some true/false option. It was changed and new GNOME is released. Another group complains that the default for that option obviously should be different.
There is not a lot of usability testing going on and it is very hard to judge things. I can point out the many instances where people have been looking for feedback and changing things. At the same time, there probably are lots of times where that didn't occur. It's not perfect.
If you aren't satisfied with the level of support given by Red Hat or SuSE, then complain to them. But for GNOME, there barely is any support.
You're also comparing something which needs lots of usability testing (UI) with something which you can more easily determine technically (POSIX complaint vs what programs are doing). Those are worlds apart.
I've read the bugreports about where people complain about the default setting for some true/false option. It was changed and new GNOME is released. Another group complains that the default for that option obviously should be different.
There is not a lot of usability testing going on and it is very hard to judge things. I can point out the many instances where people have been looking for feedback and changing things. At the same time, there probably are lots of times where that didn't occur. It's not perfect.
Theodore Ts'o
+
4
5
4
5
4
Reply
+Olav Vitters Changing defaults is one thing. Removing functionality and/or forcing users to go into a registry editor to make changes to config options that were previously on the control panel GUI, and then not documenting the registry keys (or requiring users to program javascript and to use interfaces that are not guaranteed to be stable and will break from release to release), isquite a different thing.
This is why the kernel mantra is so important:
Thoushaltnotbreakthings.
Noregressions.
This is why the kernel mantra is so important:
Thoushaltnotbreakthings.
Noregressions.
Zeeshan Ali
+
2
3
2
3
2
Reply
"I added this because Network Manager insisted on popping up a window and asking me to type my password whenever I tried joining a new network"
Really? There must be something terribly wrong with your system cause I don't remember NM doing such a thing. And yes, I do connect to new networks all the time (wireless and wired). Such issues usually turn out to be user trying to be oversmart and fiddling with their system. Since youare a smart guy, I sure hope you are not one of those. :)
Really? There must be something terribly wrong with your system cause I don't remember NM doing such a thing. And yes, I do connect to new networks all the time (wireless and wired). Such issues usually turn out to be user trying to be oversmart and fiddling with their system. Since youare a smart guy, I sure hope you are not one of those. :)
Theodore Ts'o
+
1
2
1
2
1
Reply
+Zeeshan Ali This was a bug from a while ago. See the Debian bug referenced earlier in the comment stream. Many users ran into this problem. Linus ranted about it (see the Google Plus post referenced ). He ran into the problem on OpenSuSE; I ran into the problem on Debian. It was not isolated to a single distribution.
The reason why we are discussing this is that there is a mindset (``It's not my problem, it's PolicyKit's! It's a distro bug![1]'') that seems to be very common amongst different FreeDesktop.org and GNOME projects, and it relates to how people react to systemd's takeover with fear and loathing. We saw how well Policykit's attempt to take over the world worked out.
[1] And I'm sure the PolicyKit folks will blame the distributions and/or Network Manager. That's part of the problem. No one is taking responsibility for delighting the user, or at least, not making things worse. (And if you do make things worse; you put things back. You revert the change. Or you fix the regression immediately, not wait four years. No exceptions.)
The reason why we are discussing this is that there is a mindset (``It's not my problem, it's PolicyKit's! It's a distro bug![1]'') that seems to be very common amongst different FreeDesktop.org and GNOME projects, and it relates to how people react to systemd's takeover with fear and loathing. We saw how well Policykit's attempt to take over the world worked out.
[1] And I'm sure the PolicyKit folks will blame the distributions and/or Network Manager. That's part of the problem. No one is taking responsibility for delighting the user, or at least, not making things worse. (And if you do make things worse; you put things back. You revert the change. Or you fix the regression immediately, not wait four years. No exceptions.)
Bernd Paysan
+
0
1
0
1
0
Reply
+Olav Vitters Ted's reply sums it up:
"What's important is putting the user first --- and not some software engineering ideology."
And if you look at why he made that decision: It wasuse cases. It wasn't POSIX. From a POSIX point of view, Ted's first reaction at the ext4 bug was right. But in the end, the solution was a pragmatic solution, and as result, I'm convinced that I can trust Ted and his file system. Or Chris Mason, who fixed the same problem in btrfs back then.
I can't add much beyond that; this doesn't depend whether it's Gnome, the kernel, RedHat or SuSE. A lot of free software development isn't done by students in their spare time, but sponsored by companies which make money with Linux systems (they employ the developers); quite often, their business model is actuallysupport (with advertising as second business model catching up - but advertising means the user is not the customer; this explains why Android's quality is pretty low, at least compared to RHEL/Fedora and SLES/OpenSuSE). Another reason to employ a FOSS developer is because the company depends on the product (like Google or Oracle), and that also means "support" is what pays the wages of the developer. Support includes adding features.
"What's important is putting the user first --- and not some software engineering ideology."
And if you look at why he made that decision: It wasuse cases. It wasn't POSIX. From a POSIX point of view, Ted's first reaction at the ext4 bug was right. But in the end, the solution was a pragmatic solution, and as result, I'm convinced that I can trust Ted and his file system. Or Chris Mason, who fixed the same problem in btrfs back then.
I can't add much beyond that; this doesn't depend whether it's Gnome, the kernel, RedHat or SuSE. A lot of free software development isn't done by students in their spare time, but sponsored by companies which make money with Linux systems (they employ the developers); quite often, their business model is actuallysupport (with advertising as second business model catching up - but advertising means the user is not the customer; this explains why Android's quality is pretty low, at least compared to RHEL/Fedora and SLES/OpenSuSE). Another reason to employ a FOSS developer is because the company depends on the product (like Google or Oracle), and that also means "support" is what pays the wages of the developer. Support includes adding features.
Daniel Stone
+
9
10
9
10
9
Reply
Conflating 'people make decisions I don't agree with' with 'people don't take feedback' is honestly seriously childish. You might not like the decisions the GNOME (and other userspace stack) developers have taken, but that doesn't mean they haven't listened, or haven't thought it through.
The rant about configurability made me laugh though; I wouldn't say /proc, /sys, module flags and random bonkers ioctl()s (all wholly undocumented) is really the state of the art in user-accessible configurability.
But maybe, given that I like using GNOME 3 on my Apple laptop (which is obviously the total opposite of people who do Real Software Development), I'm precisely the kind of idiot who should blindly assent to all these kinds of statements passed down from the great moral high ground.
The rant about configurability made me laugh though; I wouldn't say /proc, /sys, module flags and random bonkers ioctl()s (all wholly undocumented) is really the state of the art in user-accessible configurability.
But maybe, given that I like using GNOME 3 on my Apple laptop (which is obviously the total opposite of people who do Real Software Development), I'm precisely the kind of idiot who should blindly assent to all these kinds of statements passed down from the great moral high ground.
Daniel Stone
+
7
8
7
8
7
Reply
On regressions, the GNOME 1.4 panel configuration looked like this: http://web.archive.org/web/20131229230337/http://www.linuxselfhelp.com/gnome/users-guide/figures/glob_pref_anim.png
Must it look like that for eternity? Is removing the slider for hide-animation speed a regression, because some people really need to configure it? Or is this, in fact, utterly subjective, and at the whim of personal preference and belief, unable to be called a 'regression' or otherwise?
Anyway, while we're speaking of desperately poor user experience: why the absolute fuck does running dd to an SD card, or just copying files to a USB thumbdrive, still make my audio skip in 2014? I'm 100% sure this used to not happen in the past. (Is the answer here to ionice random chunks of your session to real-time, and dd to idle? If so, consider if that qualifies as exactly the kind of the mystical undiscoverable configuration voodoo you so dislike.)
But rather than embark on a grand self-serving diatribe about how kernel developers are idiots who wouldn't know sensible behaviour (non-skipping audio over a little less throughput) if it bit them on the ear, I'll just chalk it down to something that requires improvement and hope it gets fixed some day.
Must it look like that for eternity? Is removing the slider for hide-animation speed a regression, because some people really need to configure it? Or is this, in fact, utterly subjective, and at the whim of personal preference and belief, unable to be called a 'regression' or otherwise?
Anyway, while we're speaking of desperately poor user experience: why the absolute fuck does running dd to an SD card, or just copying files to a USB thumbdrive, still make my audio skip in 2014? I'm 100% sure this used to not happen in the past. (Is the answer here to ionice random chunks of your session to real-time, and dd to idle? If so, consider if that qualifies as exactly the kind of the mystical undiscoverable configuration voodoo you so dislike.)
But rather than embark on a grand self-serving diatribe about how kernel developers are idiots who wouldn't know sensible behaviour (non-skipping audio over a little less throughput) if it bit them on the ear, I'll just chalk it down to something that requires improvement and hope it gets fixed some day.
Nick Alcock
+
3
4
3
4
3
Reply
I note that when non-X.org f.d.o stuff (thinking particularly the crawling horror which is udisks here, but to a degree policykit too) goes wrong -- which it does too often -- I have a feeling of sinking dread. Nothing good can happen here: at best I'll get supercilious responses belittling me for daring to not have a system precisely like the maintainers', and the chance of any fix actually being forthcoming, or even one of my own being applied, is next to nil. I have been burned repeatedly, and no longer bother even reporting bugs to such upstreams. Life is too short to be used as a punching bag by unpleasant people. I don't use GNOME, so have no such experience with it, but have had assurances from people whohave tried to report bugs in it that much the same awaits people who do that.
Meanwhile, on the vanishingly rare occasions that anything goes wrong with ext4, there is no dread, even if my backups are out of date,even though all my data depends on ext4 working properly and none of it depends on e.g. udisks working (what breaks? calibre. big deal). Why? Because I know the maintainers will start from the assumption that if the thing went wrong there is probably something wrong withit, not with the user, and that bugs in one's own software are a very bad thing and should be crushed, even if that meansgasp talking to users and getting problems replicated on a God-knows-how-weird alien bizarro-world system that you don't even have access to. None of this feeling that what they're thinking is "not the same distro as me? sod off".
It's a matter of pride in craft. The ext4 developers have it, as do e.g. the new glibc developers, and the software shows that. I'm not so sure about f.d.o stuff. (systemd seems much better than the norm in this area though, and should I find bugs Iwill report them and try to fix them, an exception to my general rule.)
Meanwhile, on the vanishingly rare occasions that anything goes wrong with ext4, there is no dread, even if my backups are out of date,even though all my data depends on ext4 working properly and none of it depends on e.g. udisks working (what breaks? calibre. big deal). Why? Because I know the maintainers will start from the assumption that if the thing went wrong there is probably something wrong withit, not with the user, and that bugs in one's own software are a very bad thing and should be crushed, even if that meansgasp talking to users and getting problems replicated on a God-knows-how-weird alien bizarro-world system that you don't even have access to. None of this feeling that what they're thinking is "not the same distro as me? sod off".
It's a matter of pride in craft. The ext4 developers have it, as do e.g. the new glibc developers, and the software shows that. I'm not so sure about f.d.o stuff. (systemd seems much better than the norm in this area though, and should I find bugs Iwill report them and try to fix them, an exception to my general rule.)
Dan Williams
+
3
4
3
4
3
Reply
+Theodore Ts'o I don't believe identifying the specific place in the stack that needs improvement and advocating for that improvement is dodging responsibility. If there is a component of the system that is in error, or must be fixed, then we're not going to work around that just because it's broken. You fix the system piece by piece until you make it better.
NetworkManager doesn't (often) work around kernel driver problems. We fix them at the source, and that's why you'll find my and other NM developer's names in the kernel commit logs. That's the only way things get better. Working around problems only complicates our code and doesn't make the world better. "Temporary" workarounds tend to stick around since the problem gets papered over and the impetus to solve it disappears.
All that said, I certainly agree that the new WiFi network issue could have been better handled through more downstream communication, more attention to how distros do their default configuration, and more attention to+Michael Biebl's tireless efforts to push the issue forward.
NetworkManager doesn't (often) work around kernel driver problems. We fix them at the source, and that's why you'll find my and other NM developer's names in the kernel commit logs. That's the only way things get better. Working around problems only complicates our code and doesn't make the world better. "Temporary" workarounds tend to stick around since the problem gets papered over and the impetus to solve it disappears.
All that said, I certainly agree that the new WiFi network issue could have been better handled through more downstream communication, more attention to how distros do their default configuration, and more attention to+Michael Biebl's tireless efforts to push the issue forward.
Nick Alcock
+
1
2
1
2
1
Reply
+Daniel Stone, what? No no no I'm not complaining about the GNOME stuff I don't report bugs in, only mentioning thatothers have noted that the symptom I have noted in some fdo stuff is repeated there. The -- non-X -- fdo stuff Ihave reported bugs in has often had frankly horrible responses, the sort of responses that remind me of XFree86 at its 'go away, users, we don't want you' worst. And look what happened tothat project.
(X.org -- and, one hopes, systemd! -- are giant exceptions to this, helpful to a fault.)
(X.org -- and, one hopes, systemd! -- are giant exceptions to this, helpful to a fault.)
Nick Alcock
+
2
3
2
3
2
Reply
Perhaps I should rephrase. Developers should assume that apparent bugs in their software are actual bugs. Every time you say 'the bug is in the user', the bug is actually in thesoftware.
Similarly, every time you as a developer throw away something users are using and say that oh, it'll be back soon, get on without it, you're really telling them "don't trust anything we produce from now on: for that matter, don't start using any new features we may introduce, because we might take them away just as fast, then castigate you if you complain that a useful feature was removed". And castigating users in public for 'disliking change' when their workflows are repeatedly brokenis something I have seen come from the GNOME crowd. (In public, as if that matters. Contempt for one's users is still contempt when it happens in private.)
btw, if this sounds bitter -- this is what is left after repeated rounds of self-censorship and removal of potentially inflammatory material. It wasmuch more bitter before: that's how unpleasant reporting bugs to these (carefully unnamed) projects can be. If potential bug reporters are made to feel like this, I'd say you're doing something wrong. Certainly you'll get fewer bug reports.
Similarly, every time you as a developer throw away something users are using and say that oh, it'll be back soon, get on without it, you're really telling them "don't trust anything we produce from now on: for that matter, don't start using any new features we may introduce, because we might take them away just as fast, then castigate you if you complain that a useful feature was removed". And castigating users in public for 'disliking change' when their workflows are repeatedly brokenis something I have seen come from the GNOME crowd. (In public, as if that matters. Contempt for one's users is still contempt when it happens in private.)
btw, if this sounds bitter -- this is what is left after repeated rounds of self-censorship and removal of potentially inflammatory material. It wasmuch more bitter before: that's how unpleasant reporting bugs to these (carefully unnamed) projects can be. If potential bug reporters are made to feel like this, I'd say you're doing something wrong. Certainly you'll get fewer bug reports.
Chester Moy
+
0
1
0
1
0
Reply
+Theodore Ts'o I think your services are stopping because you're usingsystemctl isolate
From what I can see from'systemctl --help' , it basically works like switching runlevels:'Start one unit and stop all others'
Maybe what you're looking for is'systemctl start' instead of'isolate'. See if'systemctl start battery.target' accomplishes what you want.
From what I can see from'systemctl --help' , it basically works like switching runlevels:'Start one unit and stop all others'
Maybe what you're looking for is'systemctl start' instead of'isolate'. See if'systemctl start battery.target' accomplishes what you want.
Theodore Ts'o
+
1
2
1
2
1
Reply
+Chester Moy Note that there was a "Wants: graphical.target" in the battery.target file. I thought this was supposed to keep those services running, even though I was using "isolate". I can try using "start" instead, and trust that the "conflicts" will do the right thing.
Basically, the documentation about how "conflicts", "wants", "requires", etc. interact with each other is a bit tricky, and the reason why I want to do this is because I want to keep "battery.target" to be "the same as graphical.target except certain services should be stopped and one or two one-shot scripts should be run". It's not clear what's the most colloquial way to express this using systemd's constructs.
Basically, the documentation about how "conflicts", "wants", "requires", etc. interact with each other is a bit tricky, and the reason why I want to do this is because I want to keep "battery.target" to be "the same as graphical.target except certain services should be stopped and one or two one-shot scripts should be run". It's not clear what's the most colloquial way to express this using systemd's constructs.
Chester Moy
+
0
1
0
1
0
Reply
+Theodore Ts'o Hmm. Interesting. Maybe whatever it is that handles your backlight keys isn't a dependency of any of the targets.
The service might have been started through some socket, dbus or systemd.path activation or by some uevent. I guess in those cases, none of the targets explicitly have it as a dependency since the started services aren't pulled in by anything, but are "activated" by some other non-dependency based trigger (Though I'm just guessing here) and a 'systemctl isolate' would kill it since it doesn't show up in the dependency tree. An example would be cups.service, it's not pulled in as a dependency but is instead triggered by a socket.
So it's probably not so good to use isolate, because it would probably also stop the static units that you manually start yourself (if you use such units).
The service might have been started through some socket, dbus or systemd.path activation or by some uevent. I guess in those cases, none of the targets explicitly have it as a dependency since the started services aren't pulled in by anything, but are "activated" by some other non-dependency based trigger (Though I'm just guessing here) and a 'systemctl isolate' would kill it since it doesn't show up in the dependency tree. An example would be cups.service, it's not pulled in as a dependency but is instead triggered by a socket.
So it's probably not so good to use isolate, because it would probably also stop the static units that you manually start yourself (if you use such units).
Bill McGonigle
+
1
2
1
2
1
Reply
Your rsyslog kept working? Mine broke. Spent about two hours reading through "documentation" and searching mailing lists, but never got the journal to duplicate traffic to rsyslog. If anybody has a link to a HOWTO, I'd be grateful for a link! And, yeah, I'm not a complete dummy and failed to get my logging working again after two hours of trying on one server. I realize I've only been adminning linux for 20 years, though, so maybe Ted's general point is invalid.
Chester Moy
+
0
1
0
1
0
Reply
+Bill McGonigle You might try looking into /etc/systemd/journald.conf for the ForwardToSyslog option. 'man journald.conf' for reference. Also rsyslog should be packaged with native systemd units.
systemctl enable rsyslog
systemctl start multi-user.target
and /var/log/syslog should be populated
I don't have syslog set up, so I don't actually know if the option flip is all it takes to get it working.. Hopefully that helps
systemctl enable rsyslog
systemctl start multi-user.target
and /var/log/syslog should be populated
JohnFlowerful
+
0
1
0
1
0
Reply
>It's not entirely fair to charge all of this to Systemd's account, but I think one of the reasons why this happens is because +Kay Sievers and +Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away.
…https://lkml.org/lkml/2014/4/2/420
“I willnot be merging any code from Kay into the kernel until this constant pattern is fixed.”
LEL, go back to never fixing ext4 corruption issues.
…https://lkml.org/lkml/2014/4/2/420
“I willnot be merging any code from Kay into the kernel until this constant pattern is fixed.”
LEL, go back to never fixing ext4 corruption issues.
Antoine Martin
+
0
1
0
1
0
Reply
+Theodore Ts'o This sort of breakage is definitely not allowed in the kernel, so why is it OK for things higher up the stack?
My latest gripe (and time wasted): logind replacing upower functionality for no good reason, with a new and more obscure dbus name.
If you don't run logind, no more dbus power events for you. See:
http://lists.freedesktop.org/archives/devkit-devel/2014-March/001581.html
My latest gripe (and time wasted): logind replacing upower functionality for no good reason, with a new and more obscure dbus name.
If you don't run logind, no more dbus power events for you. See:
http://lists.freedesktop.org/archives/devkit-devel/2014-March/001581.html
Bill McGonigle
+
0
1
0
1
0
Reply
+Theodore Ts'o This is on Fedora 20.
+Chester Moy Thank you - I did go through those steps, but got stuck when it didn't work like it said on the tin. It's been a couple months, so I'm not recalling the precise details at the moment, but I think it was that having rsyslog consume systemd journal data directly was considered to be a broken setup but that systemd forwarding to syslog was supposed to work OK. I love having rsyslog split out all my logs by machine, date, service, etc.
+Chester Moy Thank you - I did go through those steps, but got stuck when it didn't work like it said on the tin. It's been a couple months, so I'm not recalling the precise details at the moment, but I think it was that having rsyslog consume systemd journal data directly was considered to be a broken setup but that systemd forwarding to syslog was supposed to work OK. I love having rsyslog split out all my logs by machine, date, service, etc.
Theodore Ts'o
+
4
5
4
5
4
Reply
+Bill McGonigle Well, it works just fine under Debian Testing. :-)
Part of this is an attitude thing. The Debian systemd maintainer is deliberately taking things slow, and not doing things that would infuriate people and cause people to say, "See, I told you systemd was a mistake".
The systemd people seem to want it both ways. Sometimes, people will say that the systemd has many components, and no one is forcing you to consume all of them --- and so they are not trying to take over the world. Other times, if anything breaks, and you're not using all of their components, they will say that you have a broken setup, and the only way to use Base OS (and sometimes this was known as GNOME OS, but I think they realized that was going too far, and/or GNOME was pissing off too many power users) is to use all of the pieces of their Base OS.
Part of this is an attitude thing. The Debian systemd maintainer is deliberately taking things slow, and not doing things that would infuriate people and cause people to say, "See, I told you systemd was a mistake".
The systemd people seem to want it both ways. Sometimes, people will say that the systemd has many components, and no one is forcing you to consume all of them --- and so they are not trying to take over the world. Other times, if anything breaks, and you're not using all of their components, they will say that you have a broken setup, and the only way to use Base OS (and sometimes this was known as GNOME OS, but I think they realized that was going too far, and/or GNOME was pissing off too many power users) is to use all of the pieces of their Base OS.
Felipe Contreras
+
0
1
0
1
0
Reply
+Theodore Ts'o Howe many services do you need to be started at init?
If you don't need a complicated system you can use this simple init system I wrote:
https://github.com/felipec/finit/blob/master/init
You can add a ton of services if you need, but you would have to do it manually, so it might be a hassle, but I bet definitely less than having to deal with systemd stupidities since you can actually read and understand the whole code. It's a simple script of 230 lines of code.
If you don't need a complicated system you can use this simple init system I wrote:
https://github.com/felipec/finit/blob/master/init
You can add a ton of services if you need, but you would have to do it manually, so it might be a hassle, but I bet definitely less than having to deal with systemd stupidities since you can actually read and understand the whole code. It's a simple script of 230 lines of code.
digi owl
+
1
2
1
2
1
Reply
There is change in the "feel free to come join us when you like" and then there is "join, or have everything you know get set back by a decade". The core issue is not change itself, but the "mission creep" of Systemd. The biggest of such was putting the udev source inside the Systemd source, as such joining them at the hip after a decade of udev existing independently.
Kevin Cave
+
1
2
1
2
1
Reply
+Theodore Ts'o I've had the same problems as yourself regarding PolicyKit, as it greatly affects what happens when you log onto a system remotely via RDP (xrdp/X11rdp).
The default PolicyKit rules as supplied in various distros renders things like NetworkManager, printer management, and a whole suite of other stuff, unusable in an RDP session.
So I sat down one day and tried to grok how PolicyKit actually worked - the documentation was (and still probably is - I haven't checked) opaque and mysterious, and just plain outright /bad/.
The end result was an article I wrote ( http://scarygliders.net/2012/06/20/a-brief-guide-to-policykit/ ) - which outlined my understanding of it at the time and seems to have helped other to get to grips with it. The method of altering the XML files is probably all wrong (i.e. better to generate pkla files rather than change the default distor-supplied policies), but that was how far I was prepared to take it at that point, and I got diverted by real life and other more interesting things.
A spin-off from looking into it was that I wrote Polkit Explorer, which turns the XML files into something a human can quickly understand by presenting the info in a GUI; http://scarygliders.net/2013/03/26/polkit-explorer-v1-0-released/
The repo is at https://github.com/scarygliders/Polkit-Explorer , and hasn't been touched for a year now - anyone wishing to fork it and/or use it is free to do so.
PolicyKit is a real PITA.
The default PolicyKit rules as supplied in various distros renders things like NetworkManager, printer management, and a whole suite of other stuff, unusable in an RDP session.
So I sat down one day and tried to grok how PolicyKit actually worked - the documentation was (and still probably is - I haven't checked) opaque and mysterious, and just plain outright /bad/.
The end result was an article I wrote ( http://scarygliders.net/2012/06/20/a-brief-guide-to-policykit/ ) - which outlined my understanding of it at the time and seems to have helped other to get to grips with it. The method of altering the XML files is probably all wrong (i.e. better to generate pkla files rather than change the default distor-supplied policies), but that was how far I was prepared to take it at that point, and I got diverted by real life and other more interesting things.
A spin-off from looking into it was that I wrote Polkit Explorer, which turns the XML files into something a human can quickly understand by presenting the info in a GUI; http://scarygliders.net/2013/03/26/polkit-explorer-v1-0-released/
The repo is at https://github.com/scarygliders/Polkit-Explorer , and hasn't been touched for a year now - anyone wishing to fork it and/or use it is free to do so.
PolicyKit is a real PITA.
Russell Nelson
+
1
2
1
2
1
Reply
systemd is not very Unixy. Then again, neither is X11. I ought to be able to pipe something into an X program, and then pipe its output into something else. Why NOT have a version of 'tr' which, if you give it no parameters, pops up an X dialog that lets you specify the parameters using point-and-click. Presumably this is a helper program whose invoker prints "tr: two strings must be given when translating" if the helper cannot be found because this machine or session doesn't have X.
Or for that matter, if I'm running a pipe from a terminal that takes "too long", and X is available, then it can pop up a completion display. It's ... it's ... it's ... like design of the shell stopped when X started.
Or for that matter, if I'm running a pipe from a terminal that takes "too long", and X is available, then it can pop up a completion display. It's ... it's ... it's ... like design of the shell stopped when X started.
Erick Mendoza
+
1
2
1
2
1
Reply
+Russell Nelson
I want to refer you to this video before reading my response:
http://youtu.be/UFFTYRWB0Tk?t=20m22s
The thing with systemd is that, as said in the video (and I know this sounds paranoic but at this point I'm over that) the tremendous quantity of bugs that systemd creates could be an excuse for Red Hat to implement backdoors into Linux Kernel. As a matter of fact, right now some people in the Arch community is dealing with something that is relevant to this topic: systemd is starting services without the user's consent.It's been fixed in testing but that kind of things made me wonder about the liability that systemd provides (by the way, all the services that systemd starts are security services like iptables and Kerberos V).
I want to refer you to this video before reading my response:
http://youtu.be/UFFTYRWB0Tk?t=20m22s
The thing with systemd is that, as said in the video (and I know this sounds paranoic but at this point I'm over that) the tremendous quantity of bugs that systemd creates could be an excuse for Red Hat to implement backdoors into Linux Kernel. As a matter of fact, right now some people in the Arch community is dealing with something that is relevant to this topic: systemd is starting services without the user's consent.It's been fixed in testing but that kind of things made me wonder about the liability that systemd provides (by the way, all the services that systemd starts are security services like iptables and Kerberos V).
Add a comment...