Plus old school so is Pam so lets drop that too and policykit and it new flavors , Because weather it has newer flavors so does Pam/shadow since they are still actively developed. This crap of modern is the best thisng is just that a load of crap. There are old libs and apps still used. If we drop em cauise they are old shool there wouldn't be much left. ---------------------------------------- > From: kay.sievers@xxxxxxxx > Date: Tue, 30 Mar 2010 12:01:09 +0200 > Subject: Re: Polkit/Consolekit cancer stick? > To: greg@xxxxxxxxx > CC: oneforall59@xxxxxxxxxxx; linux-hotplug@xxxxxxxxxxxxxxx > > On Tue, Mar 30, 2010 at 00:29, Greg KH wrote: >> On Mon, Mar 29, 2010 at 10:10:05PM +0000, oneforall immortal wrote: >>> >>> I had given the specifics: >>> 1) kde 4 has moved to using polkit for authentication and the reason they say is because of udev . >> >> Then ask the kde developers about this. > > Anyone who would say that has no idea what he's talking. Polkit has > absolutely no connection to udev, nor the other way around. > >>> 2) Udev is dropping hal and using polkit. >> >> udev never used HAL. HAL is now no longer being developed. > > Right, and HAL uses udev, not the other way around. Polkit is > completely unrelated to udev. > >>> 3) Polkit requires Consolekit and pam.? Some one made a patch for that . But it still wants Consolekit which is just as bad as Pam. >> >> Ok, but that has nothing to do with udev. > > Right, nothing. :) > >>> 4) As far as distros, so far all since last year they are just as stuck as I am . >> >> What is "stuck"? > > Stuck in trying to understand how things work today, I guess. :) > >> For some reason you do not like consolekit, which is fine. But then go >> talk to the developers of consolekit about this, not the udev >> developers, who have nothing to do with it. > > I doubt that there is much to discuss. :) > > Authorizations on the modern multi-user desktop care about if users > are locally logged-in or from remote, and need to associate requesting > processes with user sessions -- hence we absolutely need ConsoleKit. > It's part of the core technologies. If people don't want a modern > desktop, they should use an old one. There is plenty of old-school > stuff to install around. > >>> 5) I have my own cross compiled 64 bit >> >> cross compiled what? >> >>> 6) most are trying to get polkit(no pam)patced to use shadow still consolkit etc to work >> >> Again, go discuss this with those developers. > > And again, there are plenty of old-school desktops around to use. Just > avoid a desktop which needs it, if you don't like it. > >>> 7) from the last oen here that explains more than enought of how this >>> 1 type of authentication is making the other chioce a pain. So thats >>> why I'm not impress\ed with the disregard to other platforms and users >>> even if we are just a small group and a few platforms. This stuff >>> worked but is being cut off purposely. >> >> Again, I don't see anything "cut off". > > It's all free software, update your platform/system yourself, if > nobody else is doing it, or watch the platforms who don't care start > to bitrot. It's your choice. But don't blame the people who do the > work, that it does not fit your taste, that's not how things will work > out for you. > >>> 8)? Maybe with this --disable-extras will be the way , But I duno yet >>> and maybe we have been lead up the garden path so to speak. >> >> Again, specifics? >> >>> now some one said to use --disable-extras >> >> Yes, and you should be fine. > > That's not even needed. Udev does not care about ConsoleKit. There is > tiny extra in udev which can manage device ACLs with the information > ConsoleKit provides. If ConsoleKit is not there, it will just do > nothing. No need to disable anything, just ignore it. > > Kay _________________________________________________________________ IM on the go with Messenger on your phone http://go.microsoft.com/?linkid=9712960-- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html