Comments on: KDE3, KDE4 and Slackware 13.0 http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/ My thoughts on Slackware, life and everything Tue, 07 Feb 2012 13:55:51 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: winter hats http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-15351 winter hats Fri, 02 Sep 2011 01:41:41 +0000 http://alien.slackbook.org/blog/?p=290#comment-15351 Well, for me KDE4 is simply too heavy. It’s a hog. Well, for me KDE4 is simply too heavy. It’s a hog.

]]> By: MLB Hats http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-13256 MLB Hats Thu, 02 Dec 2010 03:04:06 +0000 http://alien.slackbook.org/blog/?p=290#comment-13256 Nice post.Thank you for taking the time to publish this information very useful! <a>MLB Hats </a> Nice post.Thank you for taking the time to publish this information very useful!
MLB Hats

]]> By: monster energy hat http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-13208 monster energy hat Wed, 01 Dec 2010 01:42:25 +0000 http://alien.slackbook.org/blog/?p=290#comment-13208 Do you want to be more fashion, more charming,just do a little thing. A exciting purchasing is ready to go! Just pay attention to. We are specializing in providing new era hats ,new era caps ,one industries hats,rockstar energy hats,monster energy hats which would be your final choice. Just do what you want alonging with your active heart. Do you want to be more fashion, more charming,just do a little thing. A exciting purchasing is ready to go! Just pay attention to. We are specializing in providing new era hats ,new era caps ,one industries hats,rockstar energy hats,monster energy hats which would be your final choice. Just do what you want alonging with your active heart.

]]> By: oneforall http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-11165 oneforall Mon, 22 Mar 2010 04:21:25 +0000 http://alien.slackbook.org/blog/?p=290#comment-11165 Aaron Seigo The fact is that you released it as known to be broken. I do know its because of udev going to be with out hal and replaced with the known buggy and guaranteed to brake all apps/libs Polkit-1. "Pokit/Pam with or with out Pam its the same". How, the fact that like Pam everything has to be built with it (Polkit-1) . But back to KDE being released broken, as in things that USED to work but break if we don't use Polkit-1. There is nothing hard to understand about how wrong that was and the proof that linux as a whole now has lost respect for all platforms. Its proving that linux now isn't what I thought years ago to work with all platforms. It now shows how it only wants to work with the selected favorites(The bigger platforms )"oh the feel of commercialism". It now has the WHOLE commercial attitude. I and any one else that was in #kde, #Policykit-kde, bug page etc seen wontfix,closed use Pam , Slackware(even though I never said what distro and still don't because its not just Slackware) "eventually will be forced to use Polkit/Pam" and many more ignorant replies. Then later this kauth was added but still it was broken and still released . It show a clear disrepect for the lower number of platforms. Its the fact that these should have been thought out like all the other years but since the lack of respect now it doesn't surprise me at all. But as far as I know udev isn't officially released requiring polkit-1 , but kde is . I also hate the fact that with the patch its still puts that as some one said cancer on my and others system. So everything still has to work threw it and not TOTALLY with out it (PAM and POLKIT). "repeating hear since you fail to remember THIS IS TO HAVE THE FULL FUCTIONS WE HAD" not dropping them with this lame excuse that we can run KDE with out polkit/Pam but loose those fuctions. It's once again you could have still made it work as always and provide them that are stupid enough to use polkit/Pam that ability. But as the commercial attitude, screw those fewer people even though they would repect us( as in we never say keep what we like and lose that other crap) . we don't care. I hated udev but this fuels my hatred of it even more. Anyway it became a huge disappointment. I really wish we didn't have to use polkit-1 at all . I have no doubt the problems KDE had we from all the major platforns that use pam/polkit and the rest have to suffer too . guess the old saying of all good things must come to an end are fitting hear :(. patch or not I have cancer now. Plus no its not paranoia , its a fact that Polkit/Pam are well know for all the bugs and will cause all the app/libs to break. Too well know. I hate it too because it has linux following the path of m$ with Office97, IE, Directx . The security should not be something everything has to be built around and more that the security on your house. It should work for you. Its as stupid as the system loosing functionality because you took out the browser. The authentication should be like all apps separate not embedded "so to speak" . This is to allow for other to make new ones. But this way then theirs would still be owned by Polkit-1(2 what ever) . Its insane . Aaron Seigo
The fact is that you released it as known to be broken. I do know its because of udev going to be with out hal and replaced with the known buggy and guaranteed to brake all apps/libs Polkit-1. “Pokit/Pam with or with out Pam its the same”. How, the fact that like Pam everything has to be built with it (Polkit-1) . But back to KDE being released broken, as in things that USED to work but break if we don’t use Polkit-1. There is nothing hard to understand about how wrong that was and the proof that linux as a whole now has lost respect for all platforms. Its proving that linux now isn’t what I thought years ago to work with all platforms. It now shows how it only wants to work with the selected favorites(The bigger platforms )”oh the feel of commercialism”. It now has the WHOLE commercial attitude. I and any one else that was in #kde, #Policykit-kde, bug page etc seen wontfix,closed use Pam , Slackware(even though I never said what distro and still don’t because its not just Slackware) “eventually will be forced to use Polkit/Pam” and many more ignorant replies. Then later this kauth was added but still it was broken and still released . It show a clear disrepect for the lower number of platforms. Its the fact that these should have been thought out like all the other years but since the lack of respect now it doesn’t surprise me at all. But as far as I know udev isn’t officially released requiring polkit-1 , but kde is . I also hate the fact that with the patch its still puts that as some one said cancer on my and others system. So everything still has to work threw it and not TOTALLY with out it (PAM and POLKIT). “repeating hear since you fail to remember THIS IS TO HAVE THE FULL FUCTIONS WE HAD” not dropping them with this lame excuse that we can run KDE with out polkit/Pam but loose those fuctions. It’s once again you could have still made it work as always and provide them that are stupid enough to use polkit/Pam that ability.
But as the commercial attitude, screw those fewer people even though they would repect us( as in we never say keep what we like and lose that other crap) . we don’t care. I hated udev but this fuels my hatred of it even more.
Anyway it became a huge disappointment. I really wish we didn’t have to use polkit-1 at all . I have no doubt the problems KDE had we from all the major platforns that use pam/polkit and the rest have to suffer too . guess the old saying of all good things must come to an end are fitting hear :( . patch or not I have cancer now. Plus no its not paranoia , its a fact that Polkit/Pam are well know for all the bugs and will cause all the app/libs to break. Too well know. I hate it too because it has linux following the path of m$ with Office97, IE, Directx . The security should not be something everything has to be built around and more that the security on your house. It should work for you. Its as stupid as the system loosing functionality because you took out the browser. The authentication should be like all apps separate not embedded “so to speak” . This is to allow for other to make new ones. But this way then theirs would still be owned by Polkit-1(2 what ever) . Its insane .

]]> By: someoldman http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-10987 someoldman Mon, 15 Feb 2010 05:02:55 +0000 http://alien.slackbook.org/blog/?p=290#comment-10987 Comment from Aaron Seigo "note that you can build KDE without polkit, and there are people on Slackware using KDE with polkit. nobody is frozen out." No we'll just lose functionality as it appears on the roadmaps that I've read. It sounds like you're saying it'll be possible, but from what I've read that doesn't appear to be the case, I hope you're right. --------------------------- Commant from Someoldman “And the push for these technologies are by Corporations, *not* the users, or input from other distro’s” Comment from Aaron Seigo "KAuth was done 100% by volunteers unaffiliated with..." and Comment from Aaron Seigo "it is evident to me that your concerns have arisen from not really understanding the technology" No I understand policykit, pam, $kit, quite well, after all they are requirements now for a full installation of gnome, which has historically been my preferred desktop (but not anymore due to their hard coded requirements of policykit, etc). I have built my own gnome from the ground up for a few years, and reworked all of Slackware to use them. So I know what it means to add these items to a gnu/linux installation, and I can tell you, this is not like asking distributions to include some new 'library'. So others are aware, policykit has been a fedora/redhat invention: Their announcement of policykit into fedora: http://fedoraproject.org/wiki/Releases/FeaturePolicyKit Which references the author of policykit's release statement: http://lists.freedesktop.org/archives/hal/2007-June/008815.html In which (to the best of my knowledge) the author of policykit is a red hat employee. With that said, the author of the policykit has this to say on his site: http://hal.freedesktop.org/docs/PolicyKit/polkit-spec-history.html "Traditionally UNIX-like operating systems have a clear distinction between ordinary unprivileged users and the almight and powerful super user 'root'. However, in order for a user to access and configure hardware additional privileges and rights are needed. Hitherto, this have been done in a number of often OS-specific ways. For example, Red Hat based systems usually grant access to devices to a user if, and only if, the user is logged in at a local console. In contrast, Debian-based systems often relies on group membership, e.g. users in the 'cdrom' group can access optical drives, users in the 'plugdev' group can mount removable media and so on. " And this part is the crux of the matter: "For example, Red Hat based systems usually grant access to devices to a user if, and only if, the user is logged in at a local console. In contrast, Debian-based systems often relies on group membership" There you have it. Since Red Hat doesn't like traditional *nix ways of doing things they made up their own. The reason this concerns me Aaron is, even though I have no intention of using KDE4 on my Slackware boxe's, or for others is I'm stuck having that *cancer* of authentication schema onboard my computer. Becuase many other items have to be re-worked (after hours of testing) to get them to work, but are still needed even if KDE isn't on board. Cracklib, shadow, samba, I could go on all day as to what this requires Slackware dev's todo. This isn't a lib. (side note, the reason I don't use KDE on my computers is KDE's security updates policy, but that's a rant for another day :) --------------------------------------------------------------------------------------- Commant from Someoldman “Yes we just have Fedora shipping policykit that let’s users install applications un-beknownst to the admin of the box as a result of cryptic command/configuration’s embedded in xml files and the like.” Comment from Aaron Seigo "which has nothing to do with KDE, KAuth or even PolicyKit itself. i’m not sure if i’m deaing with someone who is open to reason at this point or who is just ranting. :/" My point to that was, it's *another* thing that administrator's have to micro-manage xml/config files to ensure that the box is setup to how *they* want it, and not predetermined by some dev somewhere. --------------------------------------------------------------------------------------- Comment from Aaron Seigo "i’m sure you’re just looking in from the sidelines of development as a user and are understandably concerned. but your information is incorrect and is leading you to conclusions that bear no resemblance to the realities of the situation. i do hope that we can manage to correct that through discussions such as these." It's OK to flame me, you don't have to be so nice :) But really I've run KDE4 on Slackware --current, and it's done! It's a good desktop, stop adding things now ! :D . My advice, fix the bugs, fix the desktop icons always moving (firefox download to desktop blows out their arrangement - even kde3.5 series), and fix klipper not honoring xterm copy/paste. Get Koffice working, because the FUD in my brain says openoffice won't be free for very long (koffice in 3.5 was sweet). And please please get a MSAccess 95'-ish database functionality with all the wizards, and understands click events to perform sql like querie's and you'd have a winner. Free software (openoffice included) has nothing to offer small business that is on par/equivelant to MS Access 95 ( I'd ask for office 2003, but that's a tall order). Comment from Aaron Seigo
“note that you can build KDE without polkit, and there are people on Slackware using KDE with polkit. nobody is frozen out.”

No we’ll just lose functionality as it appears on the roadmaps that I’ve read. It sounds like you’re saying it’ll be possible, but from what I’ve read that doesn’t appear to be the case, I hope you’re right.

—————————
Commant from Someoldman “And the push for these technologies are by Corporations, *not* the users, or input from other distro’s”
Comment from Aaron Seigo “KAuth was done 100% by volunteers unaffiliated with…”

and

Comment from Aaron Seigo “it is evident to me that your concerns have arisen from not really understanding the technology”

No I understand policykit, pam, $kit, quite well, after all they are requirements now for a full installation of gnome, which has historically been my preferred desktop (but not anymore due to their hard coded requirements of policykit, etc).
I have built my own gnome from the ground up for a few years, and reworked all of Slackware to use them.

So I know what it means to add these items to a gnu/linux installation, and I can tell you, this is not like asking distributions to include some new ‘library’.

So others are aware, policykit has been a fedora/redhat invention:

Their announcement of policykit into fedora:
http://fedoraproject.org/wiki/Releases/FeaturePolicyKit

Which references the author of policykit’s release statement:
http://lists.freedesktop.org/archives/hal/2007-June/008815.html

In which (to the best of my knowledge) the author of policykit is a red hat employee.

With that said, the author of the policykit has this to say on his site:

http://hal.freedesktop.org/docs/PolicyKit/polkit-spec-history.html

“Traditionally UNIX-like operating systems have a clear distinction between ordinary unprivileged users and the almight and powerful super user ‘root’. However, in order for a user to access and configure hardware additional privileges and rights are needed. Hitherto, this have been done in a number of often OS-specific ways. For example, Red Hat based systems usually grant access to devices to a user if, and only if, the user is logged in at a local console. In contrast, Debian-based systems often relies on group membership, e.g. users in the ‘cdrom’ group can access optical drives, users in the ‘plugdev’ group can mount removable media and so on. ”

And this part is the crux of the matter:

“For example, Red Hat based systems usually grant access to devices to a user if, and only if, the user is logged in at a local console. In contrast, Debian-based systems often relies on group membership”

There you have it. Since Red Hat doesn’t like traditional *nix ways of doing things they made up their own.

The reason this concerns me Aaron is, even though I have no intention of using KDE4 on my Slackware boxe’s, or for others is I’m stuck having that *cancer* of authentication schema onboard my computer. Becuase many other items have to be re-worked (after hours of testing) to get them to work, but are still needed even if KDE isn’t on board. Cracklib, shadow, samba, I could go on all day as to what this requires Slackware dev’s todo. This isn’t a lib. (side note, the reason I don’t use KDE on my computers is KDE’s security updates policy, but that’s a rant for another day :)

—————————————————————————————
Commant from Someoldman “Yes we just have Fedora shipping policykit that let’s users install applications un-beknownst to the admin of the box as a result of cryptic command/configuration’s embedded in xml files and the like.”

Comment from Aaron Seigo “which has nothing to do with KDE, KAuth or even PolicyKit itself. i’m not sure if i’m deaing with someone who is open to reason at this point or who is just ranting. :/”

My point to that was, it’s *another* thing that administrator’s have to micro-manage xml/config files to ensure that the box is setup to how *they* want it, and not predetermined by some dev somewhere.

—————————————————————————————

Comment from Aaron Seigo “i’m sure you’re just looking in from the sidelines of development as a user and are understandably concerned. but your information is incorrect and is leading you to conclusions that bear no resemblance to the realities of the situation. i do hope that we can manage to correct that through discussions such as these.”

It’s OK to flame me, you don’t have to be so nice :) But really I’ve run KDE4 on Slackware –current, and it’s done! It’s a good desktop, stop adding things now ! :D . My advice, fix the bugs, fix the desktop icons always moving (firefox download to desktop blows out their arrangement – even kde3.5 series), and fix klipper not honoring xterm copy/paste. Get Koffice working, because the FUD in my brain says openoffice won’t be free for very long (koffice in 3.5 was sweet). And please please get a MSAccess 95′-ish database functionality with all the wizards, and understands click events to perform sql like querie’s and you’d have a winner. Free software (openoffice included) has nothing to offer small business that is on par/equivelant to MS Access 95 ( I’d ask for office 2003, but that’s a tall order).

]]> By: andrew http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-10981 andrew Sun, 14 Feb 2010 02:42:30 +0000 http://alien.slackbook.org/blog/?p=290#comment-10981 Aaron, Sometimes you get very defensive about KDE - and it's your right to do so. However, other times I think you miss the big picture as a result. Currently, the KDE team is making it a /challenge/ to use a full KDE environment. "Migrate to the unstable software, or miss out on features" is such a terrible situation. If the kauth stuff is so fragile and new, items in 4.4 should not blatantly depend on them. I know that I can use 4.4 without policykit, (polkit?), and pam, but you must see what a slippery slope this is. Aaron,
Sometimes you get very defensive about KDE – and it’s your right to do so. However, other times I think you miss the big picture as a result. Currently, the KDE team is making it a /challenge/ to use a full KDE environment. “Migrate to the unstable software, or miss out on features” is such a terrible situation. If the kauth stuff is so fragile and new, items in 4.4 should not blatantly depend on them. I know that I can use 4.4 without policykit, (polkit?), and pam, but you must see what a slippery slope this is.

]]> By: pprkut http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-10971 pprkut Sat, 13 Feb 2010 11:45:02 +0000 http://alien.slackbook.org/blog/?p=290#comment-10971 My personal opinion is, that kauth itself is not really the problem here. Quite the contrary, I think kauth is a good piece of software. I was missing a sort of "root-mode" in the kde sc ever since the switch from kde3 and I'm very happy that this is now taken care of, at least at the foundation level. It might not be perfect yet, as it is the first public release, but that was the case with other components as well. In the early kde4 days there was only one network management backend for solid as well and that was for network-manager, which doesn't have a very good reputation amongst Slackware users either. With 4.3 we got a wicd backend and as far as I can tell it works quite good and I'm pretty sure a lot of Slackware users appreciate that (I do). What's probably worth pointing out here is that the developer of the wicd backend is the same as the developer behind kauth. So with 4.4 the only sensible backend for kauth is polkit. There's policykit as well, as you mentioned, but that isn't really an option as it is already unmaintained/abandoned/deprecated/whatever. And here's the point, this is not really a problem either. Kde chose what looked best for them, and they couldn't have done better imho. The unfortunate thing for us Slackware users is, that the only sensible backend option for kauth is *unstable* software, a moving target. This is as far as I know unprecedented and what I think our community dislikes the most (pure personal opinion). Then there's also the dependency of polkit on PAM, which doesn't help there either. PAM has always been a very controversial topic amongst Slackware users, and it will stay that way for some time. Now I know that at least that is being worked on, which is already a good point, though it's a bit unfortunate that a small distribution like Slackware has to go through the trouble of pushing support for standard unix tools into those frameworks (polkit, consolekit,...) while the big players just don't care (that's where the political issue stems from I guess). Now I know that kde has very little influence there, and I understand that from your perspective there wasn't really an alternative that would have worked better, but the point remains. That leaves us with the point of writing a backend for kauth that is supported by Slackware (so far I could only think of su or sudo, which probably don't fit that well there). Unfortunately this doesn't work either since there are some components in 4.4 that directly depend on polkit, bypassing kauth (the font installer comes to mind here, and I think the printer applet was mentioned as well somewhere, though I cannot remember where). So we would loose functionality even by selecting the fake backend. Taking care of that before the release would have been nice (maybe it can be done for 4.4.1? I don't know if this would fit the description of fixing a bug). Only if those issues are fixed, writing a new backend would become a viable option. My personal opinion is, that kauth itself is not really the problem here. Quite the contrary, I think kauth is a good piece of software. I was missing a sort of “root-mode” in the kde sc ever since the switch from kde3 and I’m very happy that this is now taken care of, at least at the foundation level. It might not be perfect yet, as it is the first public release, but that was the case with other components as well. In the early kde4 days there was only one network management backend for solid as well and that was for network-manager, which doesn’t have a very good reputation amongst Slackware users either. With 4.3 we got a wicd backend and as far as I can tell it works
quite good and I’m pretty sure a lot of Slackware users appreciate that (I do). What’s probably worth pointing out here is that the developer of the wicd backend is the same as the developer behind kauth.
So with 4.4 the only sensible backend for kauth is polkit. There’s policykit as well, as you mentioned, but that isn’t really an option as it is already unmaintained/abandoned/deprecated/whatever. And here’s the point, this is not really a problem either. Kde chose what looked best for them, and they couldn’t have done better imho. The unfortunate thing for us Slackware users is, that the only sensible backend option for kauth is *unstable* software, a moving target. This is as far as I know unprecedented and what I think our community dislikes the most (pure personal opinion). Then there’s also the dependency of polkit on PAM, which doesn’t help there either. PAM has always been a very controversial topic amongst Slackware users, and it will stay that way for some time. Now I know that at least that is being worked on, which is already a good point, though it’s a bit unfortunate that a small distribution like Slackware has to go through the trouble of pushing support for standard unix tools into those frameworks (polkit, consolekit,…) while the big players just don’t care (that’s where the political issue stems from I guess). Now I know that kde has very little influence there, and I understand that from your perspective there wasn’t really an alternative that would have worked better, but the point remains.
That leaves us with the point of writing a backend for kauth that is supported by Slackware (so far I could only think of su or sudo, which probably don’t fit that well there). Unfortunately this doesn’t work either since there are some components in 4.4 that directly depend on polkit, bypassing kauth (the font installer comes to mind here, and I think the printer applet was mentioned as well somewhere, though I cannot remember where). So we would loose functionality even by selecting the fake backend. Taking care of that before the release would have been nice (maybe it can be done for 4.4.1? I don’t know if this would fit the description of fixing a bug). Only if those issues are fixed, writing a new backend would become a viable option.

]]> By: Aaron Seigo http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-10967 Aaron Seigo Fri, 12 Feb 2010 22:43:59 +0000 http://alien.slackbook.org/blog/?p=290#comment-10967 "It does have to do with politics" it was not a decision made for or under the influence of political reasons, it was a decision made for purely technical reasons. "KDE developer’s are not sensitive to these user’s needs, wants, or wishes" KAuth significantly improves things for many of our users, and it sets the stage for doing the same for the rest. until we had KAuth, we had some unresolvable issues. note that you can build KDE without polkit, and there are people on Slackware using KDE with polkit. nobody is frozen out. " KDE appears to be taking a “it’s our way, or the highway” approach" i can understand that that is your interpretation of it, but what we actually have done is invest a large amount of effort to produce something (KAuth) that can work everywhere. we don't have infinite resources, so the time that was available was focused on addressing the needs of the greatest number of our users first. this is not the same as excluding others, as other use cases will be covered in time. "And the push for these technologies are by Corporations, *not* the users, or input from other distro’s" KAuth was done 100% by volunteers unaffiliated with any corporation or distribution behind PolicyKit. moreover, KAuth is not welded to PolicyKit, it's simply the first backend that was written for KAuth. '“and everything to do with providing needed functionality” - What functionality?' the ability to run actions with elevated security privileges in a way that is both safe and can be configured. 'Play a cd, surf the web, check my battery status, hibernate, type a letter? Fluxbox can handle those items, no pam, or policykit required.' KDE4 doesn't require Polkit for any of those things either. just because Slackware devs have decided not to package KDE SC 4.4 does not make that less true. "Yes we just have Fedora shipping policykit that let’s users install applications un-beknownst to the admin of the box as a result of cryptic command/configuration’s embedded in xml files and the like." which has nothing to do with KDE, KAuth or even PolicyKit itself. i'm not sure if i'm deaing with someone who is open to reason at this point or who is just ranting. :/ " I truly doubt you’d see any distro reverse engineering KDE to yank the Policykit" there is no reverse engineering needed. KAuth is a well documented API with a separation between the front end and the back end. writing a different KAuth backend is all that is needed. we've already written 4 of them (Fake, MacOs and ones for 2 different versions of polkit) "KDE is forcing it on them, and they ship it." nobody is forced to do anything, and anyone can add a new backend to KAuth. we'd welcome it upstream, even. the way that new platform integration APIs tend to happen, though, is that the front end API (KAuth) is written, backends that will cover the most people as possible are written with others being prioritized according to time available. which is to say, that not having 100% coverage of all possible platforms on day 0 is not uncommon. and truthfully, in this case, Slackware could ship with KAuth using the "Fake" KAuth backend and it would be like 4.3 without KAuth. "If Redhat wants policykit, then KDE should add a path/extension so that Redhat can have their playtoy’s." we have: KAuth's backends are EXACTLY this. "KDE shouldn’t be using these playtoys as a default and cow-tailing to just one distro." we aren't. we have provided KAuth with lets us back-end onto an authentication system. we support more than one already, and others can rather easily be added. in fact, that is precisely what we want to see happen. it is evident to me that your concerns have arisen from not really understanding the technology very well at all in this case. that is understandable, i'm sure you're just looking in from the sidelines of development as a user and are understandably concerned. but your information is incorrect and is leading you to conclusions that bear no resemblance to the realities of the situation. i do hope that we can manage to correct that through discussions such as these. “It does have to do with politics”

it was not a decision made for or under the influence of political reasons, it was a decision made for purely technical reasons.

“KDE developer’s are not sensitive to these user’s needs, wants, or wishes”

KAuth significantly improves things for many of our users, and it sets the stage for doing the same for the rest. until we had KAuth, we had some unresolvable issues.

note that you can build KDE without polkit, and there are people on Slackware using KDE with polkit. nobody is frozen out.

” KDE appears to be taking a “it’s our way, or the highway” approach”

i can understand that that is your interpretation of it, but what we actually have done is invest a large amount of effort to produce something (KAuth) that can work everywhere.

we don’t have infinite resources, so the time that was available was focused on addressing the needs of the greatest number of our users first. this is not the same as excluding others, as other use cases will be covered in time.

“And the push for these technologies are by Corporations, *not* the users, or input from other distro’s”

KAuth was done 100% by volunteers unaffiliated with any corporation or distribution behind PolicyKit. moreover, KAuth is not welded to PolicyKit, it’s simply the first backend that was written for KAuth.

‘“and everything to do with providing needed functionality”
– What functionality?’

the ability to run actions with elevated security privileges in a way that is both safe and can be configured.

‘Play a cd, surf the web, check my battery status, hibernate, type a letter? Fluxbox can handle those items, no pam, or policykit required.’

KDE4 doesn’t require Polkit for any of those things either. just because Slackware devs have decided not to package KDE SC 4.4 does not make that less true.

“Yes we just have Fedora shipping policykit that let’s users install applications un-beknownst to the admin of the box as a result of cryptic command/configuration’s embedded in xml files and the like.”

which has nothing to do with KDE, KAuth or even PolicyKit itself. i’m not sure if i’m deaing with someone who is open to reason at this point or who is just ranting. :/

” I truly doubt you’d see any distro reverse engineering KDE to yank the Policykit”

there is no reverse engineering needed. KAuth is a well documented API with a separation between the front end and the back end. writing a different KAuth backend is all that is needed. we’ve already written 4 of them (Fake, MacOs and ones for 2 different versions of polkit)

“KDE is forcing it on them, and they ship it.”

nobody is forced to do anything, and anyone can add a new backend to KAuth. we’d welcome it upstream, even.

the way that new platform integration APIs tend to happen, though, is that the front end API (KAuth) is written, backends that will cover the most people as possible are written with others being prioritized according to time available.

which is to say, that not having 100% coverage of all possible platforms on day 0 is not uncommon.

and truthfully, in this case, Slackware could ship with KAuth using the “Fake” KAuth backend and it would be like 4.3 without KAuth.

“If Redhat wants policykit, then KDE should add a path/extension so that Redhat can have their playtoy’s.”

we have: KAuth’s backends are EXACTLY this.

“KDE shouldn’t be using these playtoys as a default and cow-tailing to just one distro.”

we aren’t. we have provided KAuth with lets us back-end onto an authentication system. we support more than one already, and others can rather easily be added. in fact, that is precisely what we want to see happen.

it is evident to me that your concerns have arisen from not really understanding the technology very well at all in this case. that is understandable, i’m sure you’re just looking in from the sidelines of development as a user and are understandably concerned. but your information is incorrect and is leading you to conclusions that bear no resemblance to the realities of the situation. i do hope that we can manage to correct that through discussions such as these.

]]> By: Someoldman http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-10958 Someoldman Thu, 11 Feb 2010 03:52:22 +0000 http://alien.slackbook.org/blog/?p=290#comment-10958 Comment from Aaron Seigo "this has zero to do with politics" - It does have to do with politics, when there are *many* users who do not want or need Pam, or Policykit and the KDE developer's are not sensitive to these user's needs, wants, or wishes. You think they would have learned when GNOME pulled this trick years ago. KDE appears to be taking a "it's our way, or the highway" approach. And the push for these technologies are by Corporations, *not* the users, or input from other distro's "and everything to do with providing needed functionality" - What functionality? Play a cd, surf the web, check my battery status, hibernate, type a letter? Fluxbox can handle those items, no pam, or policykit required. "with KDE 4 we decided to side with a policy of not running GUIs as root" - Yes we just have Fedora shipping policykit that let's users install applications un-beknownst to the admin of the box as a result of cryptic command/configuration's embedded in xml files and the like. Good job /end-rolls-eyes. "PolicyKit is providing features and functionality that several of the mainstream distributions have decided is worth supporting." - While they have a choice to change source code, I truly doubt you'd see any distro reverse engineering KDE to yank the Policykit. KDE is forcing it on them, and they ship it. "i think you have confused a situation driven by simple pragmatism within our logistical limitations with a political one" - He made sense to me. KDE's getting over-engineerd by Corporations who could care less how easy/hard it is to build/maintain a distro as a user thereby forcing people to buy support contracts. Plus, these technologies are *new* and *changing*. Why would you blame anyone for not wanting to run *ALPHAware's*. If Redhat wants policykit, then KDE should add a path/extension so that Redhat can have their playtoy's. KDE shouldn't be using these playtoys as a default and cow-tailing to just one distro. Comment from Aaron Seigo

“this has zero to do with politics”
- It does have to do with politics, when there are *many* users who do not want or need Pam, or Policykit and the KDE developer’s are not sensitive to these user’s needs, wants, or wishes. You think they would have learned when GNOME pulled this trick years ago. KDE appears to be taking a “it’s our way, or the highway” approach. And the push for these technologies are by Corporations, *not* the users, or input from other distro’s

“and everything to do with providing needed functionality”
- What functionality? Play a cd, surf the web, check my battery status, hibernate, type a letter? Fluxbox can handle those items, no pam, or policykit required.

“with KDE 4 we decided to side with a policy of not running GUIs as root”
- Yes we just have Fedora shipping policykit that let’s users install applications un-beknownst to the admin of the box as a result of cryptic command/configuration’s embedded in xml files and the like. Good job /end-rolls-eyes.

“PolicyKit is providing features and functionality that several of the mainstream distributions have decided is worth supporting.”
- While they have a choice to change source code, I truly doubt you’d see any distro reverse engineering KDE to yank the Policykit. KDE is forcing it on them, and they ship it.

“i think you have confused a situation driven by simple pragmatism within our logistical limitations with a political one”
- He made sense to me. KDE’s getting over-engineerd by Corporations who could care less how easy/hard it is to build/maintain a distro as a user thereby forcing people to buy support contracts. Plus, these technologies are *new* and *changing*. Why would you blame anyone for not wanting to run *ALPHAware’s*. If Redhat wants policykit, then KDE should add a path/extension so that Redhat can have their playtoy’s. KDE shouldn’t be using these playtoys as a default and cow-tailing to just one distro.

]]> By: Aaron Seigo http://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/#comment-10941 Aaron Seigo Tue, 09 Feb 2010 17:27:49 +0000 http://alien.slackbook.org/blog/?p=290#comment-10941 "My remark about “politics” was indeed referring to the fact that KDE 4.4 loses functionality if it is compiled while PolicyKit is not present on the system. This is questionable, since KDE4 should be using kauth as an abstraction instead, but as it stands, kauth integration will not be ready until KDE 4.5." this has zero to do with politics and everything to do with providing needed functionality. with KDE 4 we decided to side with a policy of not running GUIs as root. this was not an easy decision since it meant a lot of work for us. probably unsurprising to everyone here who knows anything about security, there aren't many people who are willing to roll up their sleeves and get to this kind of work and have the skill to do so. KDE does not dictate to the operating system vendors, be they Slackware, Red Hat, Novell, Mandriva, FreeBSD, Apple, Microsoft or whomever what is on the system. ergo we create abstraction layers where necessary. this is not the most efficient system for us either as we are sometimes left in "adapt-at-a-scramble" mode ourselves as the OSVs shift and turn with very little upstrea coordination. but we manage. in this case, PolicyKit is providing features and functionality that several of the mainstream distributions have decided is worth supporting. it happens to also support the kind of fine-grained control we'd like to see. the world isn't full of roses, though: during development of 4.4 PolicyKit had a major change in API and a new release and we had to adapt. KAuth itself is able to have different backends. this is actually shown quite clearly as it supports either version of PolicyKit. it could also support non-PolicyKit solutions. we have limited manpower, however, and this stuff takes time. i think you have confused a situation driven by simple pragmatism within our logistical limitations with a political one. what would be great is instead of people inventing stories about "politics getting in the way of things" is to highlight the need for additional work in the backends for KAuth. that way instead of fomenting more arguing and gnashing of teeth, maybe someone who is reading your blog would get inspired and find the motivation to spend some spare time working on KAuth so that it can use some other system, e.g. PAM, as a backend option. i know the developer who works on KAuth personally, and he's generally very open to input and involvement. i know that we (in KDE) would love to expand the support within our various abstraction layers that we must keep up (though we keep those to an absolute minimum; we have no love of wheel reinvention) so that they are more broadly useful. would you care to write a blog entry to your audience about the issue with the hopes of us finding a solution together in the form of a pair of motivated hands? “My remark about “politics” was indeed referring to the fact that KDE 4.4 loses functionality if it is compiled while PolicyKit is not present on the system. This is questionable, since KDE4 should be using kauth as an abstraction instead, but as it stands, kauth integration will not be ready until KDE 4.5.”

this has zero to do with politics and everything to do with providing needed functionality.

with KDE 4 we decided to side with a policy of not running GUIs as root. this was not an easy decision since it meant a lot of work for us.

probably unsurprising to everyone here who knows anything about security, there aren’t many people who are willing to roll up their sleeves and get to this kind of work and have the skill to do so.

KDE does not dictate to the operating system vendors, be they Slackware, Red Hat, Novell, Mandriva, FreeBSD, Apple, Microsoft or whomever what is on the system. ergo we create abstraction layers where necessary. this is not the most efficient system for us either as we are sometimes left in “adapt-at-a-scramble” mode ourselves as the OSVs shift and turn with very little upstrea coordination. but we manage.

in this case, PolicyKit is providing features and functionality that several of the mainstream distributions have decided is worth supporting. it happens to also support the kind of fine-grained control we’d like to see. the world isn’t full of roses, though: during development of 4.4 PolicyKit had a major change in API and a new release and we had to adapt.

KAuth itself is able to have different backends. this is actually shown quite clearly as it supports either version of PolicyKit. it could also support non-PolicyKit solutions. we have limited manpower, however, and this stuff takes time.

i think you have confused a situation driven by simple pragmatism within our logistical limitations with a political one.

what would be great is instead of people inventing stories about “politics getting in the way of things” is to highlight the need for additional work in the backends for KAuth. that way instead of fomenting more arguing and gnashing of teeth, maybe someone who is reading your blog would get inspired and find the motivation to spend some spare time working on KAuth so that it can use some other system, e.g. PAM, as a backend option.

i know the developer who works on KAuth personally, and he’s generally very open to input and involvement. i know that we (in KDE) would love to expand the support within our various abstraction layers that we must keep up (though we keep those to an absolute minimum; we have no love of wheel reinvention) so that they are more broadly useful.

would you care to write a blog entry to your audience about the issue with the hopes of us finding a solution together in the form of a pair of motivated hands?

]]>