Now that sys-auth/polkit depends on dev-lang/spidermonkey, because of a terrible decision to replace the configuration with JavaScript, I have masked version 106 and above. The reasons given in the blog post about the change are nonsensical, (and even contradictory, to some degree). My personal hatred for JavaScript aside, I object to the idea of using a full-blown, turing-complete language for configuration, especially for a system that really should be simple (i.e does this user have access to do this?). Nobody wants to write a program to configure another program, especially one that requires all the boilerplate that is necessary for polkit configuration.

Honestly, I wish I could get rid of PolicyKit altogether, but it seems to be a dependency for just about everything these days (xfce4-power-manager and gvfs, on my system). It would be nice if these things could work with traditional authorization mechanisms (i.e group membership), but I suppose that's a pipe dream.

Am I crazy? Is there some magical benefit I am overlooking that would make me want to start writing programs in JavaScript to configure all of my system utilities? I'd like to know what others have to say about this._________________Help the Unanswered

Last edited by AdmiralNemo on Sat Aug 18, 2012 4:36 pm; edited 1 time in total

All the *kit things are conceptually broken and are perfect examples how things should not be done: It is solving problems with ad-hoc solutions (daemons) instead of introducing conceptual changes where they belong (kernel, configure setup etc.)
I have decided to remove everything for which the dependency on *kit cannot be made optional - running a sane system is currently still possible, although you must give up some nice applications.
Unfortunately, getting rid of udev will be harder, since udev is what these kiddies are breaking next. I really hope that somebody will fork it, but who will have that much free time?

All the *kit things are conceptually broken and are perfect examples how things should not be done

In other words, to use a phrase that has become common at my workplace, "Doing It Wrong™"

mv wrote:

running a sane system is currently still possible, although you must give up some nice applications.

Unfortunately, I really need gnome-base/gvfs for mounting CIFS shares, since Samba has changed to disallow normal users to mount shares that are not specified in /etc/fstab, and mounting as root is not an option because I have to use Kerberos authentication._________________Help the Unanswered

The rational given in the above blogpost simply lacks any kind of logical connection: "[it] never really worked well [..] had some serious usability problems [...]", so, "define the problem" which mostly amounts to vague statements, ("[t]here is no one-size-fits-all [...] some admins want [...]"), a wishlist ("[..] It would be good to [...] it would be nice to have [...]"), and digressions ("[..] who is going to end up using this [etc]"), and magically ends with the conclusion "Just embed JavaScript", becuase "[t]he first requirement clearly indicates that we want some kind of programming language".

The statement of the "problem" reaches no futher than we have a problem, and that problem is strictly demarcated by the inital starting point, from here any solution can be proposed.

As far as the wider issue is concerned, what Redhat seems to want is a reigistryKit, it should be so convoluted that only a RHCE (ie: "Enterprise Admin") has the key to the kingdom, and the mythical "user" is cast into the tedium of productivity. The development path should follow one "good idea" after another, never pausing to question its assumptions, shedding past failures at every release cycle.

Like mv, I have strewn off *kit and kaboodle and regard GnomeOS/freedesktop as a farce ... I don't really care for the rational given (via "usability") for making linux safe for this abstracted "user", its based on falacious reasoning. Skill, familarity, etc, is only aquired by doing, and if the "doing" is pre-constrained by an abstracted "usablity", then there is no context for the "user". This is not to say that Linux should remain static, only that it needs to be driven by actual use (and actual users), not the abstraction that is "usability".

I could could probably cite further contentions, but its already been said here and elsewhere ... so I'll leave it at that.

I don't have a problem with the original goal that PolicyKit was trying to achieve, assuming I understand it correctly. The ability to control access to certain resources and opertions by normal users is certainly a real need, and although sudo provides this to a certain extent, it is far from an ideal solution in a true multi-user environment. The trouble that I see is that the solution has far outreached the scope of the original problem. PolicyKit is installed on my computers because it is a hard dependency of the XFCE power management utility, which is needed to allow the computer to sleep after a period of inactivity, and GVFS, which, as I mentioned above, I need in order to mount CIFS shares in a reasonably simple way. In a multi-user environment, some kind of authorization mechanism would be nice, but in this case, I am the only user allowed to log into the machine, so the need is nonexistent, so I should be able to use my system without it. Furthermore, I don't think PolicyKit does a very good job of controlling authorization to these operation anyway, since the default seems to be to allow anybody to do anything, but restricting them requires a fairly working knowledge of JavaScript. I work with other sysadmins on a daily basis, and I can say with almost certainty that none of them know JavaScript and would not be excited about having to learn it just to configure authorization for a few operations.

I think my biggest concern is "where will it stop." Originally, I had no need for PolicyKit, but now I need it for something as trivial as browsing a file share on the network. What's next, I need it to launch Firefox? Check my email? I am afraid the choices I have with regard to installing software will soon be limited to a huge, bloated system, or a console-only setup without a GUI._________________Help the Unanswered

I don't have a problem with the original goal that PolicyKit was trying to achieve, assuming I understand it correctly. The ability to control access to certain resources and opertions by normal users is certainly a real need, and although sudo provides this to a certain extent, it is far from an ideal solution in a true multi-user environment.

AdmiralNemo ... whatever its original goal, it wasn't thought out, and so it follows a rather arbitrary course. I would agree with mv, its "conceptually broken", anything that provides ACL's needs to be simple, flexable, and to a certain degree foolproof. It also needs to be implimented as a fully developed idea, within the complete framework of authentication. Additionally, the seperation of privilages isn't so much a boundary, but a condition, if users need to access resources then someone/something needs to authoirise this, and PolicyKit provides nothing other than an mechanism. In that sense its no different to currently existing ACL's except that its impilmented as a daemon, adds an additonal level of complexity, requires "some kind of programming language", and certain applications can't operate without it.

Now, "the problem", as its being framed, is that users can't do this or that without being superusers, but thats not a problem, its a condtion of the seperation of privilages. What the "solution" proposes is that this superuser is transposed into a mechanism and so, to use your term, "normal users" can go about accessing resources as though that seperation of privilages doesn't exist, but the opertative word here is "transposed", its just relocating the "problem" (or non-problem depending on how you look at it). So all thats happening is the introduction of a mechanism for granting rights/privilages, etc. In this transposition who, or what, does the granting? Well, the mechanism of course, but who, or what, grants the mechanism? This is where the chasm of complexity opens up, because yes, you can alter the mechanics of authentication, but ultimately it has to resolve into an actual figurative authenticator, and as the polkit model has it this authenticator is a javascript wielding, "enterprise admin", or some other abstract personage/provider.

The level of complexity (and I'm not simply speaking of polkit here) works to lock out the user, the bar having been raised to the level of "enterprise admin", its also the kind of model that keeps the user dependent on providers, and creates an environment where users are little more than a captive audience.

AdmiralNemo wrote:

The trouble that I see is that the solution has far outreached the scope of the original problem. PolicyKit is installed on my computers because it is a hard dependency of the XFCE power management utility, which is needed to allow the computer to sleep after a period of inactivity, and GVFS, which, as I mentioned above, I need in order to mount CIFS shares in a reasonably simple way. In a multi-user environment, some kind of authorization mechanism would be nice, but in this case, I am the only user allowed to log into the machine, so the need is nonexistent, so I should be able to use my system without it. Furthermore, I don't think PolicyKit does a very good job of controlling authorization to these operation anyway, since the default seems to be to allow anybody to do anything, but restricting them requires a fairly working knowledge of JavaScript.

Right, so you have ask what kind of authentication would automatically raise the level of privilage, be a requirement of so many applications, etc, and additionally be so opaque as make it difficult to reconfigure.

AdmiralNemo wrote:

I think my biggest concern is "where will it stop." Originally, I had no need for PolicyKit, but now I need it for something as trivial as browsing a file share on the network. What's next, I need it to launch Firefox? Check my email? I am afraid the choices I have with regard to installing software will soon be limited to a huge, bloated system, or a console-only setup without a GUI.

I share your concern, but it probably won't stop until users start rejecting it. Things like polkit will probably be short lived as there is always the next "good idea" that will overturn it all, and this will cause an entire about turn so that the failures of the past can be put behind them. But, yes, it'll no doubt get worse ...

Although essentially I agree with khayyam, I see some details a little bit different, therefore I reply, too:

AdmiralNemo wrote:

The ability to control access to certain resources and opertions by normal users is certainly a real need, and although sudo provides this to a certain extent, it is far from an ideal solution in a true multi-user environment.

sudo is not the only way to achieve this (although sufficient for most purposes). This ability exists in Unix system since ages, and it is used e.g. to start X with root permissions. The "problem" as formulated originally by policykit is that the user logged in to the running X session should have access to all hardware resources.

Despite this is not desired on many systems (e.g., it is not always desired that a guest user can plug in a USB stick and run programs from there; e.g. did the administrator think about forbidding SUID programs?) it may be reasonable for certain desktop-only systems. The reasonable way to do this is to change the permissions for login and again for logout: This could be done with scripts run by the desktop manager (who runs with root permissions anyway), or by pam, or by several other constructions I can think of. Running a daemon for such a trivial task is just a plain misconception, since it permanently hogs resources (memory and runtime) for nothing.

It is actually worse, both for the user and the admin because neither the user can use classical scripts to find out what he is allowed to do (e.g. test -w on a device may return that he is forbidden somethings, although through a policykit library he can do something anyway), nor the admin can easily find out at runtime what the user actually is allowed to do. Of course, this is related with the KISS principle which should be the main principle for all privileged processes: This is broken completely, practically making the default user a privileged user, because it is to be expected that the complex process will have exploits. So, practicaly, you have both disadvantages: The "normal" user might still feel restricted by the permission concept although the malevalent user can do harm anyway (note that every user can become malevalent if he becomes a victim of a browser exploit).

The final thing is of course the defaults: Linux went very well concerning security, because the default was to forbid everything. So users with not much experience who administrate their own system were somewhat safe, because they had to change (and learn) something to do dangerous things. Now, as you say, the default is to allow practically everything, and you need to be a good administrator to forbid things which should have been forbidden from the very beginning. And you need to be a very good administrator to do this in such a way that it cannot be exploited. And even then there is quite a risk that there is an exploit possible through a programming error or through a way the maintainers of *kit did not think about.

Practically, if you use *kit you can as well work as root throughout. This makes the *kit tools of course completely nonsensical, but the "windows desktop experience" ("fast user switching" and other stupid buzzwords) were the declared goal of the development of these tools. Now it is well-known that most windows users run always with administrator rights, because otherwise there are so many troubles getting some things to work. Indeed, it is this experience which the project successfully reached.

Like with pulseaudio: You edit one single line into one config file and it never start. That way, audio programs will use alsa or jack.

*kit look like to be like udev, but much worst.

Before udev:

Code:

/dev/sdg1 /mnt/usb ext3 noatime 0 1

During a few years: writing its own udev rules in order to mount this disk and a few other things.

And now, udev is still there, but no need for udev rules anymore, just:

Code:

UUID=43c35321-bb7a-4d3e-8f6d-d534aa4aa982 /mnt/usb ext3 noatime 0 1

Subsidiary question: Is udev really needed in order to get this UUID identification?

Or, is *kit really needed in order to mount stuff? Answer no for most of us.
And I just don't want to learn JS, not only because my time is spare, but mainly because, even with my computer, I have a lot of more interesting things to do. _________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think it is not fair to compare udev with *kit. The basic idea of udev is very sensible: Instead of doing complex tasks in kernel space, they should be done in user space. This can be seen as a lowering of privileges where possible. One may argue about the implementation and defaults. However, the worst thing about udev is that they couldn't make up their mind what they want and changed fundamental things every few weeks.

Quote:

Before udev:

Code:

/dev/sdg1 /mnt/usb ext3 noatime 0 1

During a few years: writing its own udev rules in order to mount this disk and a few other things.

You can still use something like the above setup (after configuring udev once appropriately). The rules are only "necessary" if you want some special devices mounted on a special place. Or e.g. if you have several video cards and want to have a consistent scheme.

Quote:

Subsidiary question: Is udev really needed in order to get this UUID identification?

Yes, because getting the UUID of various filesystems is complex enough that this should not be in the kernel if not necessary. Giving this task to userspace is correct from the kernel perspective.

Quote:

Or, is *kit really needed in order to mount stuff? Answer no for most of us.

"My OS security model does not allow local privilege escalation desirable in some use cases, so I'm going to build painful-to-configure daemons to get around it, and all my GUI application will be designed to rely on it." This is consolekit/polkit in a nutshell.

This is expedient, but violates at least two principles that have made Unix-like OSes so robust in the real world:

1) separating policy and mechanism

2) making programs small with simple interfaces

Quote:

"To make something simple is one thousand times harder than making something complicated."

I just see than it is a cups-pk-helper package. Cups was not complicated enough to manage, so they added it. I will begin to seriously take a look at the alternatives for GNU/linux, because more time is going on, more it become just like windows: unmanageable for the average joe user.

And this is sad, because a lot of efforts was spending in order to lower the entry level of GNU/linux and made it accessible to the average joe user for its desktop. But at the same time, it is a crazy gang of developers following exactly the inverse path: they are forcing the whole community, even those that just doesn't want to use, what is for them just unnecessary and unmanageable crap. This is unmanageable because I have better things to do with my computer than to learn JS.

If I understand very well the need of large corporations for tools like *kit, what I just don't get is: Why the linux community can be enough naive to accept stuffs like that, programs needed only by large companies which, because of their complexity and opacity, remove the essence of free software - freedom of choice - to the average user!_________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

"My OS security model does not allow local privilege escalation desirable in some use cases, so I'm going to build painful-to-configure daemons to get around it, and all my GUI application will be designed to rely on it." This is consolekit/polkit in a nutshell.

Oh man, that is classic.

Quote:

This is expedient, but violates at least two principles that have made Unix-like OSes so robust in the real world:

1) separating policy and mechanism

2) making programs small with simple interfaces

Exactly, leading to the mess we keep getting into with *kit and "integrated" desktop "solutions" (to problems we never had.)

Quote:

"To make something simple is one thousand times harder than making something complicated."

— Mikhail Kalashnikov

I find it intensely annoying that people who actively turn their noses up at the Unix tradition (KISS) feel free to change everything across the board, and just decide that any inconveniences the discipline causes, mean that the discipline is flawed, since it's getting in their way; not that they need to rethink what they're doing.
This same mess (either polkit or another of its ilk, but the general situation with userland getting trampled on) was being discussed on debian mailing-list, I think it was, and someone came up with this link, which I think sums it up very well:
http://www.anotherpanacea.com/2012/09/chestertons-fence/

AdmiralNemo wrote:

Honestly, I wish I could get rid of PolicyKit altogether, but it seems to be a dependency for just about everything these days (xfce4-power-manager and gvfs, on my system). It would be nice if these things could work with traditional authorization mechanisms (i.e group membership), but I suppose that's a pipe dream.

Yes that's exactly what I'd like. I sincerely don't see what benefit policykit offers over traditional mechanisms. All it does is add a lot of complexity, and looks like a security disaster waiting to happen, providing false reassurance that "something" is managing security, when in fact it's not, because the defaults, that most of the target user-base will never change, are wide-open. In the name of what? Gimmicky fast-user switching that leaves devices open to existing processes, while apparently changing permissions so you think you're in control, interfaces and configuration that are plainly much less transparent than what came before, and a much larger attack vector. (coded by people who seem less interested in their craft, than their public profile.)

Quote:

Am I crazy? Is there some magical benefit I am overlooking that would make me want to start writing programs in JavaScript to configure all of my system utilities? I'd like to know what others have to say about this.

The whole thing makes me laugh; if the whole saga (of the various pieces of rubbish that have come out of that development team) weren't taking up so much developer and user-time, that's all it would be: funny. For instance, after so long denigrating use of sh to configure systems (it's portable, it's very well-known, admins are comfortable with it) and claiming instead that everything should be done by declarative files, no programming involved (since users find it too difficult), now we're full-circle, yet again, with a rediscovery of the existing wheel, made square.

Benefits to having javascript embedded: it's in-process so no doubt they think it's faster, and they can provide access to an object-model that reflects their software. js is quite a nice language, but only if you're very disciplined about how you use it.

Disadvantages: it's in-process, so anything that goes wrong takes down the whole service. (If it's not in-process, then it's not embedded, and if you're forking for reliability, you might as well be using sh and educating your users about how to write robust, efficient scripts, knowledge which will apply everywhere else.)
It's a totally different language to shell, C, awk or anything most admins are used to, though they might know it well enough if they're web developers (ie not serious admins.) So it's going to require an investment of time that most good admins don't have, over a significant retraining period, and in the meantime you're looking at less reliability, and less security, since you're not really sure what the implications of everything you're doing are.
It's insanely easy to mess up, and since it was designed for web browsers, tries its best to accept whatever you give it. That is not such a great property for security-critical code. Nor do I have any great confidence that the polkit developer(s?) will actually make the runtime library anywhere near robust enough in the face of invalid/erroneous input, which is hard, and tedious: my feeling is the blame will be put on the admin (why not sign up for a course in how to work with this, a bargain at $5000, and you get a certificate.)
It's untested and untried tech, which you get to beta-test, not knowing how to administer it with any degree of expertise.

I for one have zero interest in learning what object model they've come up with, which will no doubt change rapidly; at some point I've no doubt the whole project will be thrown away in favour of something bundled with systemd, and then everyone will have to go through another change (along with attendant upgrade problems), and no doubt learn a whole new way (the One True Way, this time we promise) of doing things again. Til the next time.

It just feels like one of those con-tricks where you keep getting information thrown at you, so you're not quite sure where you are, nor what's going on. In the meantime, the real sleight-of-hand is happening elsewhere. In this instance, everyone downstream of RedHat has to devote a large amount of manpower to keeping up with their otherwise bizarre changes, and fixing bugs in their code, or you can't build a distro. Enterprise users feel privileged to get access to the distro that "sets the pace". And keeping things complexified means it's much easier to sell a support-contract (just ask Microsoft.)

Still the recent udev fork is a really positive sign that users can still get together and sort out the software if they need to. I guess what's needed is a replacement client lib, that provides polkit function calls, but uses traditional mechanisms, configured by the admin, instead of talking over the dbus to a central point of failure, er daemon.

I don't know polkit code, but I'll help with C and bug-fixing, if anyone else is interested, or knows more about it.

I don't know polkit code, but I'll help with C and bug-fixing, if anyone else is interested, or knows more about it.

I doubt anyone will fork polkit. Udev was forked because it was really useful and almost impossible to have reasonably easy to use system without it. Since the decision to embed JS I got rid of all *kits and changed WM to xmonad. No regrets.
Maybe I am wrong, but it seems current situation is analogous to facebook: either you are and will be using it or you have already dropped it.

I find it intensely annoying that people who actively turn their noses up at the Unix tradition (KISS) feel free to change everything across the board, and just decide that any inconveniences the discipline causes, mean that the discipline is flawed, since it's getting in their way; not that they need to rethink what they're doing.
This same mess (either polkit or another of its ilk, but the general situation with userland getting trampled on) was being discussed on debian mailing-list, I think it was, and someone came up with this link, which I think sums it up very well:
http://www.anotherpanacea.com/2012/09/chestertons-fence/

steveL ... I don't think Chestertons' Fence is a particularly good analogy, at least if placed within the context of what Chesterton is arguing more widely (and I say that having read the full text which is replete with straw men arguments). In short, tradition, the fence, or what-have-you, never has to justify itself, no "sonambulist" is required (or lunatics for that matter). What Chesterton doesn't account for is "error" which can not be conflated with "purpose", the child (to use Charles S. Peirces' analogy) didn't burn themselves on a hot stove with the purpose of discovering it as a source of harm, but "[...] becomes aware of ignorance [...] error appears, and it can be explained only by supposing a self which is fallible." (Charles S. Peirce Questions Concerning Certain Faculties Claimed for Man). The fence may indeed be purposeless, "unreasonable", etc, even in the absence of sonambulists and lunatics.

That said, another analogy, not based on simple conservatisim or the defense of tradition, is required, and I would suggest down with fancy-pants (which is illustrative of the rational behind KISS). Its not a matter of clinging to a past but to a well honed methodology.

It is a little bit out subject, but this thread on udev and firmware loading is not bad. Linus is a real swede, what make him really upset is not when someone make something wrong, but when he doesn't recognize his mistake, making impossible to take actions.

And I get ride of *kit. That removed pulseaudio in the proccess , which was already completely disabled._________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

steveL ... I don't think Chestertons' Fence is a particularly good analogy, at least if placed within the context of what Chesterton is arguing more widely (and I say that having read the full text which is replete with straw men arguments). In short, tradition, the fence, or what-have-you, never has to justify itself, no "sonambulist" is required (or lunatics for that matter). What Chesterton doesn't account for is "error"

Er, but that's exactly what he does account for in the latter half: "If he knows how it arose, and what purposes it was supposed to serve, he may really be able to say that they were bad purposes, or that they have since become bad purposes, or that they are purposes which are no longer served."

[edit]But then I haven't read the full text. Nonetheless I think the point stands well on its own, and the caution it espouses is useful, especially in the context of software development, where there is a temptation to indulge in what Brooks called "the delight of working in a medium so tractable - pure thought-stuff - which nevertheless exists, moves and works in a way that word-objects do not."

It's what I meant by its easy to get caught up in what you can do, since it appears to come out of nowhere; it can be difficult to restrain yourself from adding extra functionality, or changing other things. That's where the Unix philosophy, and the history of the craft enshrined with in it, comes in so useful: keeping those ideals (of clean, simple, portable code written to be read by other human beings) in one's mind helps one to control oneself, and pare down code to the essentials, while designing programs that work well together and can be replaced without changes in other modules.

Quote:

which can not be conflated with "purpose", the child (to use Charles S. Peirces' analogy) didn't burn themselves on a hot stove with the purpose of discovering it as a source of harm, but "[...] becomes aware of ignorance [...] error appears, and it can be explained only by supposing a self which is fallible." (Charles S. Peirce Questions Concerning Certain Faculties Claimed for Man). The fence may indeed be purposeless, "unreasonable", etc, even in the absence of sonambulists and lunatics.

Yes, but it's only by understanding how it arose, and the context within which it arose, that you can begin to answer whether it is 'purposeless, "unreasonable", etc' or simply 'bad' as Chesterton puts it.
I would add that only looking at supposed purpose (or 'pretext') is not enough: often, the true effect of something is radically different, and that was its true purpose, with a pretext given to sell the concept (eg: patents and copyrights as a supposed protection for "innovation", rather than a legitimised bribe to allow market monopoly.)

Quote:

That said, another analogy, not based on simple conservatisim or the defense of tradition, is required, and I would suggest down with fancy-pants (which is illustrative of the rational behind KISS).

Its not a matter of clinging to a past but to a well honed methodology.

I never said anything about clinging to a past: but where exactly did that "well honed methodology" come from, if not from the past experiences of generations of programmers?

The reason that post resonated with me, was because it summed up exactly what I feel is wrong with the current approach being foisted upon the Linux ecosystem: "restrictions", that are in essence the hard-won lessons of the last 40 years, are seen as inconvenient by people who do not understand them, and make the same mistake Chesterton describes, of assuming that therefore they must be useless and are to be removed.

Still, I think we are in broad agreement on the principles that should be followed, and justifiably suspicious when they are not.

Er, but that's exactly what he does account for in the latter half: "If he knows how it arose, and what purposes it was supposed to serve, he may really be able to say that they were bad purposes, or that they have since become bad purposes, or that they are purposes which are no longer served."

steveL ... no, Chesterton is claiming that their existance implies a purpose, and uses the sonambulist and lunatic to shore up the idea. The argument is not epistemic, but a vague truism "it exists .. therefore it exists for some reason". He conflates purpose with fact so as to provide any existant with a rational, but error can not be accounted for in this way. Why did the ancient Greeks think the sky was the colour gold, what purpose did this asignment serve, were they, in hindsight, wrong to think so?

The problem I have with Chestertons' argument is that howerver seemingly "common sensical" the claim the wider argument is basically a polemic without any basis.

steveL wrote:

[...] it's only by understanding how it arose, and the context within which it arose, that you can begin to answer whether it is 'purposeless, "unreasonable", etc' or simply 'bad' as Chesterton puts it.

No, via Ocham's razor I need know nothing but the hypothesis before judging it unreasonable.

steveL wrote:

Quote:

Its not a matter of clinging to a past but to a well honed methodology.

I never said anything about clinging to a past: but where exactly did that "well honed methodology" come from, if not from the past experiences of generations of programmers?

I was speaking more to Chesterton than your good self, he is an arch social conservative.

Yes, this "well honed methodology" comes from the collective efforts of others, but I was contrasting to 'tradition for traditions sake', we are not simply saying (as is often claimed) "this is the way we've always done it, so its the right way", but that "we do it this way for reasons of x, y, z".

steveL wrote:

The reason that post resonated with me, was because it summed up exactly what I feel is wrong with the current approach being foisted upon the Linux ecosystem: "restrictions", that are in essence the hard-won lessons of the last 40 years, are seen as inconvenient by people who do not understand them, and make the same mistake Chesterton describes, of assuming that therefore they must be useless and are to be removed.

OK, I think here is where we are perhaps misunderstanding each other, my argument is with Chesterton in general (in which I reject Chestertons' conservatism, claims to epistemic wisdom, etc), whereas I think you are reading the above more in terms of "those fences (which to some seem useless) are infact reasonable, and serve a purpose".

steveL wrote:

Still, I think we are in broad agreement on the principles that should be followed, and justifiably suspicious when they are not.

The direction userland development is currently taking has no set direction. This was eventually going to happen eventually to a highly dependent package, but I had no idea it would be because of this radical philosophy. Due to polkit's new direction, I feel the scalability of userland may now compromised due to dependency of other highly regarded packages. This may not threaten the server world, but it sure does diminish desktop and embbed systems. Until there is inter-distro cooperation to stop radical changes like this, whats going to stop redhat and other corporations?

EDIT:

I can conclude that it is current version of polkit is all ignoring any admin additions and this is considered a " bug", and was in fixed release 3. Polkit is broken. What a surprise.

What are the consequences if I rebuild xfce4-power-manager without the policykit USE flag? Will power functions (sleep, hibernate) cease to work, or will they merely require me to enter a password?_________________Personal overlay | Simple backup scheme

What are the consequences if I rebuild xfce4-power-manager without the policykit USE flag? Will power functions (sleep, hibernate) cease to work, or will they merely require me to enter a password?

At least /usr/sbin/xfpm-power-backlight-helper won't be built. And then it will rely on #ifdef's in the code to connect directly to ConsoleKit using DBUS for access to reboot/shutdown...
But I've just scratched the surface, looking at the amount of #ifdef's, disabling polkit will severaly cripple xfce4-power-manager.