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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list