Re: GNOME and non-linux platforms (release team please stand up)
- From: David Zeuthen <david fubar dk>
- To: Brian Cameron <Brian Cameron Sun COM>
- Cc: desktop-devel-list gnome org
- Subject: Re: GNOME and non-linux platforms (release team please stand up)
- Date: Fri, 24 Jul 2009 10:56:10 -0400
On Thu, 2009-07-23 at 04:58 -0500, Brian Cameron wrote:
> Sun is already working to add DeviceKit support to Solaris
It would be good to the devkit-devel mailing list know about this.
Because if this is so, we need to change some of our plans; in
particular move the "make porting easier" up the priority list. Also, I
hope you guys know that PolicyKit is a not an optional dependency.
Either way, even if you didn't want to contribute to DeviceKit-disks or
DeviceKit-power, you can always just ship your own GVolumeMonitor
implementation in a GIO module [1] and patch/reimplement g-p-m to use
whatever. As I said in other mails, I don't think we ever want the core
G stack to depend on something that only exists for Linux.
[1] : This GVolumeMonitor implementation could probably use the same
codebase as your excellent Fishworks product.
> Sun does not have much of
> an interest in shipping modules which have a strong dependency on
> PolicyKit
No-one ever explained to me why Sun is suddenly not interested in this -
and SUN did send patches to PolicyKit earlier on. The only explanations
I've seen (in private mails) included childish statements like claiming
PolicyKit is "rubbish" and that the author, me, didn't know what I was
doing.
Anyway, maybe you should ask someone at Sun out the latest polkit
version
http://hal.freedesktop.org/docs/polkit/
which is a complete rewrite of the old code. PolicyKit, by itself, is
now merely an interface to interface to the authorization system -
adding support for a Solaris RBAC backend amounts to subclassing a
single class, implementing two methods and drop that code in an .so in
$libdir/polkit-1/extensions. Yes, you're welcome that it is now this
easy.
> (e.g. Sun is moving to use VisualPanels instead of wanting
> to ship GNOME system tools), and it typically isn't hard to make those
> few programs that use PolicyKit that we do want to ship use RBAC
> instead.
Uh, RBAC just _doesn't_ do what a modern desktop needs. At least not
last time I checked. The problem with Solaris RBAC, like many other
authorization frameworks out there (I did an extensive analysis of many
different authz frameworks some time ago), is that they really are not
designed with the modern desktop in mind.
Case in point, last time I checked out OpenSolaris (about a year ago so
things might have changed) the whole package manager UI was a single
process running as uid 0. Not only does this violate very fundamental
security principles (least privilege etc.), it also messes up the user
interface (theming, file chooser (root's home) etc.). And if you want
a11y to work with such programs, then you effectively just extended uid
0 privileges to the rest of the desktop session.
> I am not sure what the big deal is here. Nobody from Sun has been
> complaining about GNOME being too Linux-ey, have they? Sun has always
> had a good relationship with the GNOME community, and it has never been
> particularly hard to get patches upstream to support things needed for
> GNOME to work well on Solaris or OpenSolaris.
The perception, at least from me personally, is that Sun isn't doing a
very good job at *working* with the GNOME community. Case in point, if
RBAC or Visual Panels are oh-so-much-better, why the heck are you guys
not trying to push it for non-Linux? And actually do the integration
work inside GNOME instead of bolting your work on after the fact? That
would benefit both Sun, the rest of the GNOME community and it would
make you guys look a lot better. At least in my eyes.
Btw, if you look at the Linux kernel community, behavior like this is
frowned upon. So I don't think you should be too surprised that this is
how some of us feels.
Anyway, didn't mean to sound rude or too harsh, hope you guys will take
this as constructive criticism.
David
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]