You are not logged in.
i just wondered if arch will use policykit and consolekit or if the devs decided not to due to some KISS or whatever? i mean, it would be a nice addition and other distros already use it too.
i haven't seen any kind of "official" announcement concerning that move, so i finally just ask...
Offline
hope devs never force arch users to use this crap (as option ok, but please not as required dependency)
and yes policykit and consoliekit <> KISS
Lenovo G50 | LXQT-git | compton | conky
Offline
I can not remember seeing anything mentioned anywhere about including these in Arch. I also haven't seen any user requests/contributions getting these into Arch either so the demand seems low... In fact, I had to look these up again to remember what they did!
Offline
... it would be a nice addition and other distros already use it too...
That's the most dumb reason I can think of. If you want to convince anybody, give a practical reason.
Offline
baze wrote:... it would be a nice addition and other distros already use it too...
That's the most dumb reason I can think of. If you want to convince anybody, give a practical reason.
well, it's just that desktops and things like networkmanager for example are configuring their dbus services to use consolekit and arch has to change those configurations for every package, so it just seems to me it would be better to just use the default instead of having to patch around everywhere.
and i didn't really try to "convince anybody" but just wanted to know if there were any plans to use it.
Offline
Are those truly evil and that far away from KISS? After doing some minor research it appears to me they add some usability benefits without that much additional complexity. I'm pretty sure FreeBSD uses policykit - and you can't call it an OS far from KISS.
Just to be clear, I couldn't care less whether they make it into Arch that way or another, it's just that that "kits <> KISS" opinion made me curious.
Last edited by lucke (2008-04-26 13:50:08)
Offline
Are those truly evil and that far away from KISS? After doing some minor research it appears to me they add some usability benefits without that much additional complexity. I'm pretty sure FreeBSD uses policykit - and you can't call it an OS far from KISS.
Just to be clear, I couldn't care less whether they make it into Arch that way or another, it's just that that "kits <> KISS" opinion made me curious.
FreeBSD is a complete OS and you will not find policykit within the system. You can install it of course, if you like it - as you can install anything in your system.
http://www.freshports.org/sysutils/policykit/
So this is a huge difference.
Use UNIX or die.
Offline
Let's keep a generally friendlier tone in this thread. No reason to get upset over the OP's question.
Offline
There are some packages in AUR for policykit :
http://aur.archlinux.org/packages.php?ID=16369
http://aur.archlinux.org/packages.php?ID=16371
I think they have been made for packagekit, a generic frontend for many package manager including pacman (partially supported thought) :
http://aur.archlinux.org/packages.php?ID=16370
http://aur.archlinux.org/packages.php?ID=16372
I am not interested in packagekit, because I like using pacman in the console.
But I am very interested in policykit and consolekit.
Policykit will allow me, to use some gnome configuration tools without using gksu or sudo and without entering a password.
This has a relatively small interest, if you considere that you do not configure things every day... But it may have a lot of interest for a desktop station in a college or a company where many people are using the computer and have different rights.
To make it (very) short : Policykit is to desktop applications what sudo is to console applications.
ConsoleKit (which depends on Policykit) has a much bigger interest for me :
I have one computer shared with my wife and my son. We all use Gnome + gdm + fast-user-switch applet.
Without ConsoleKit the one who owns your peripheral (USB key ...) is the last logged in, even if its session is not the current one.
ConsoleKit support activated in gdm,fast-user-switch applet and hal, will make sure the one who owns the peripheral is the one whose session is active : If I plugin my USB key I will be allowed to remove some files from it, even If my wife logged in after me and I switch back to my session.
ConsoleKit and PolicyKit are young projects. Finding documentation about them is hard, and they might be complex to people not used to hal, dbus or other freedesktop technologies. But I see no reason to say they are not KISS or any other flam about them.
I hope I helped on this subject, and I have a good news to all of you : *Kit are 100% Free Software technologies. If you are exited about them they will be soon all available to Archlinux users, there is no doubt. PolicyKit is already here, and ConsoleKit will be here soon, if I have enought time to work on it.
If you do not like them just do not use them, this is all what Arch is about : 100% Freedom
Offline
Very informative and interesting post, chicha.
ConsoleKit sounds very interesting. I also shared my computer with my father and have run into similar issue with peripherals permission. I'll check it out.
If you do not like them just do not use them, this is all what Arch is about : 100% Freedom
Well said.
EDIT: ...and even if ConsoleKit, PolicyKit and PackageKit all become available for Arch Linux, I'm sure no one will "force" us users to use them. So no need to worry.
Last edited by zodmaner (2008-04-26 19:06:55)
Offline
Ya I some times wonder why people immediately bring in KISS philosophy etc. etc. when someone just asks a question out of curiosity.
I enjoyed the explanation provided by chicha.
I believe everything needs to evolve and same is true for Arch. I see no reason to shoot down discussions about some new tool just because it stretches somebody's definition of KISS
I totally agree with Misfit
Acer Aspire V5-573P Antergos KDE
Offline
Policykit and consolekit are the future, but as long as they're stated as experimental not for production use in the README and as long as no software hard-depends on it, I won't package it.
The whole point of consolekit is to detect console logins in a cross-distribution way. Right now, there's several pam modules, some redhatism stuff and in our case, a lazy check to see if $DISPLAY starts with a ":" sign. Consolekit brings in a generic solution that works on every distribution.
Policykit is something else that will be useful in the future: right now we have these stupid groups: optical, storage, network, floppy, power... when you're member of these groups, you can burn CDs, mount USB sticks, setup networking using networkmanager, format a floppy or suspend your machine. With policykit & consolekit combined, you don't need membership of these groups to perform these jobs.
For the end user, this becomes even more KISS: packages that support policykit will detect policykit at buildtime and setup dbus rules to utilize policykit. No need to configure anything, the only thing you have to do is starting this policykit daemon.
Offline
lucke wrote:Are those truly evil and that far away from KISS? After doing some minor research it appears to me they add some usability benefits without that much additional complexity. I'm pretty sure FreeBSD uses policykit - and you can't call it an OS far from KISS.
Just to be clear, I couldn't care less whether they make it into Arch that way or another, it's just that that "kits <> KISS" opinion made me curious.
FreeBSD is a complete OS and you will not find policykit within the system. You can install it of course, if you like it - as you can install anything in your system.
http://www.freshports.org/sysutils/policykit/
So this is a huge difference.
The thing is, you need to have policykit daemon running in order to use media mounting through HAL in KDE in FreeBSD (perhaps in GNOME too) - thus you need to have it to have a pretty basic desktop feature, and it proves that it's embraced by FreeBSD in some way.
As I see, JGC supported my point of doubting its non-KISSiness.
Last edited by lucke (2008-04-27 01:59:03)
Offline
Policykit and consolekit are the future, but as long as they're stated as experimental not for production use in the README and as long as no software hard-depends on it, I won't package it.
The whole point of consolekit is to detect console logins in a cross-distribution way. Right now, there's several pam modules, some redhatism stuff and in our case, a lazy check to see if $DISPLAY starts with a ":" sign. Consolekit brings in a generic solution that works on every distribution.
Policykit is something else that will be useful in the future: right now we have these stupid groups: optical, storage, network, floppy, power... when you're member of these groups, you can burn CDs, mount USB sticks, setup networking using networkmanager, format a floppy or suspend your machine. With policykit & consolekit combined, you don't need membership of these groups to perform these jobs.
For the end user, this becomes even more KISS: packages that support policykit will detect policykit at buildtime and setup dbus rules to utilize policykit. No need to configure anything, the only thing you have to do is starting this policykit daemon.
thank you! that was what i meant using groups in arch and such. good to hear from a package maintainer on this one.
Offline
Policykit and consolekit are the future, but as long as they're stated as experimental not for production use in the README and as long as no software hard-depends on it, I won't package it.
The whole point of consolekit is to detect console logins in a cross-distribution way. Right now, there's several pam modules, some redhatism stuff and in our case, a lazy check to see if $DISPLAY starts with a ":" sign. Consolekit brings in a generic solution that works on every distribution.
Policykit is something else that will be useful in the future: right now we have these stupid groups: optical, storage, network, floppy, power... when you're member of these groups, you can burn CDs, mount USB sticks, setup networking using networkmanager, format a floppy or suspend your machine. With policykit & consolekit combined, you don't need membership of these groups to perform these jobs.
For the end user, this becomes even more KISS: packages that support policykit will detect policykit at buildtime and setup dbus rules to utilize policykit. No need to configure anything, the only thing you have to do is starting this policykit daemon.
The so called future is a moving target, especially in opensource. KISS isn't about doing all sorts of things automatically, if so we could all use Debian and would be happy.
Use UNIX or die.
Offline
I know this is dumb, but I tend to be skeptical of things that need a diagram in their explanation
Offline
I don't think KISS philosophy have anything to do with this issue. It's just a matter of personal preferences and choices. Just like in the case of HAL, if you don't want to use it, then don't! There's nobody stopping you from manually mounting and unmounting devices using command line yourself. So why should there be any problem if someone chooses to do it automatically?
If there's one thing that Arch Linux is good at, it is in providing users with choices. We can freely choose which DE/WM we want to use, we can freely choose if we want to use only command line applications or go all GUI, etc. ConsoleKit, PolicyKit and PackageKit, from what I understand, are just another set of tools that provide another way to manage your system. What is wrong with providing people with more choice on how they can manage their own system?
The bottom line is this: I'm sure there won't be anyone forcing you to use ConsoleKit, PolicyKit or PackageKit if you don't want to. I haven't seen anyone mentioned that they will come preinstalled with Arch or that Arch will depends on any of them to function. JGC have even said that he won't package them unless they are 1.) stable enough 2.) there is a software that's depends on one of them. Thus it looks like it will still be quite sometime until any of them become available in our main repositories, let alone if Arch will depends on one of them. So why worry about it?
Offline
I'm confused now. Will policykit, consolekit & packagekit be available in the repos or no?
cause if there will be, i don't know whats the hype.
Arch is a bare bones system and everything else is on the user.
If it ain't broke, broke it then fix it.
Offline
KISS isn't about doing all sorts of things automatically
KISS isn't about doing all sorts of things manually either. This isn't really a discussion about KISS, it's a discussion about *Kit. Like so many have said, if the software becomes available, we're not going to shove it down your throat, so I don't see what the big hubbub is about.
Offline
how about the unified package management gui, packagekit - http://www.packagekit.org/index.html ?
it depends on policykit and that would be needed before, but i think that having one program across multiple distros and package managers is a great idea. is there any work in this direction?
Offline
is there any work in this direction?
Yes. I am the current maintainer of alpm backend in PackageKit - you can try out git version to see what's done since 0.1.11.
I also support chicha, JGC and Cerebral positions, and I don't think that usage of *Kits will affect Arch's KISS nature.
Offline
Is arch going to use consolekit and policykit?
Correct me if I'm wrong, but I guess the right topic would be:
Is arch going to provide consolekit and policykit packages on the repos?
OR
Are you going to use consolekit and policykit?
Arch doesn't do anything, it just provides packages. And even when it doesn't, there's AUR anyway. Use whatever you like.
Offline
So, any changes in this subject? I see policykit in aur, I see some repos with policykit gnome packages, how's that coming along? I'd believe moving the official gnome desktop in official archlinux repos to a policykit enabled one would be a wise move.
It's not a very big dep, and it doesn't "cost" a lot, meaning, it provides interesting usability without being a hog.
How's KDE with policykit coming along for that matter?
Also, regarding the "stability" of things, we see KDE 4.1 in main repos, and as arch is a rolling release system, I don't see why not use policykit-enabled gnome and friends.
a nail that sticks out, is hammered down.
aha.
Offline
Ok, this is very very weird:
(dave is a user)
dave@dellazoid ~ $ yaourt -Ss policykit | grep installed
extra/policykit 0.9-5 [installed]
aur/policykit 0.9-1 [0.9-5 installed]
root@dellazoid:~# pacman -Rd policykit
(1/1) removing policykit [####################################################] 100%
dave@dellazoid ~ $ yaourt -Ss policykit | grep installed
(blank, no result)
root@dellazoid:~# pacman -S policykit
resolving dependencies...
looking for inter-conflicts...
Targets (1): policykit-0.9-5
Total Download Size: 0.00 MB
Total Installed Size: 1.94 MB
Proceed with installation? [Y/n] y
checking package integrity...
(1/1) checking for file conflicts [####################################################] 100%
(1/1) installing policykit [####################################################] 100%
dave@dellazoid ~ $ yaourt -Ss policykit | grep installed
extra/policykit 0.9-5 [installed]
aur/policykit 0.9-1 [0.9-5 installed]
1) So, both the extra and aur policykit were installed here.
2) removing policykit using pacman uninstalls both somehow
3) installing policykit using pacman installs both somehow
4) I don't know how to fix this, and if I don't find out its time to reinstall
WTF? Yeah, I know now, don't use AUR and yaourt.
BTW, I have had worse problems occur with apt-get
Last edited by archdave (2008-10-23 07:06:24)
Running GNU/Linux Arch (Core Dump) x86_64 on System Dell-a-zoid
on Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz
Offline
You didn't actually have both version installed only the on from extra. The problem is that both packages were named the same in aur and extra and as such pacman listed them both as beeing installed, when in fact only one was.
Last edited by WhiteMagic (2008-10-23 07:22:56)
Offline