Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: David Zeuthen <david <at> fubar.dk>
Subject: Re: GNOME and non-linux platforms (release team please stand up)
Newsgroups: gmane.comp.gnome.desktop
Date: Friday 24th July 2009 14:56:10 UTC (over 8 years ago)
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
 
CD: 24ms