Alan:
It's difficult to upgrade to new GNOME releases and not be compatible with things like ConsoleKit that they require now, and if that's changed to require systemd in the future, then it makes it that much harder to upgrade to new GNOME releases. That's my concern, not how Linux-like we may or may not be.
I do not think ConsoleKit, by itself, is such a serious concern. Its use outside of the Display Manager is minimal and optional. From a Solaris perspective, the main value that ConsoleKit provides is its better VT switching support in GDM (compared to the old GDM 2.20 and earlier). It also includes some nice-to-have things like ck-list-sessions which gives users access to more useful reporting/status information than the old GDM ever provided. If we had to provide non-systemd mechanisms to provide ongoing support for things that ConsoleKit provides like VT switching, this should not be that much work. In my opinion, a more serious concern from a display management perspective is MultiSeat support. In Solaris 11 we patch GDM to work with MultiSeat. The announcement about ConsoleKit going away suggested they were going to try and solve this problem and it may get solved in a way that could also work well on Solaris. If so, that could be a nice step forward. If not, then it may make more sense to migrate towards a different display manager that can provide better MultiSeat support needed for products like Sun Ray.
I know that so far we've lucked out that Xorg is willing to keep the old HAL interfaces around for non-udev systems, but not all upstream maintainers that depend on things like HAL& ConsoleKit are willing to keep interfaces that the Linux community has declared deprecated.
HAL does provides some nice features to the desktop, like the ability for better removable media support, nautilus automatically noticing when you plug in external USB drives, better CD audio support, camera plug-in detection support, etc. While neat features, probably not all of them are so critical. If Solaris wants to be more compatible with OEL, then perhaps making a more serious effort to try and work with Red Hat to design how kernel/desktop interfaces like this should work makes more sense. Red Hat does, for the most part, try to engineer in the open. That's why we know about their plans about ConsoleKit, for example. If it seems they are too isolated, it is not for a lack of them trying to engage other distros to work with them. Though, I personally think using Solaris native interfaces may just make more sense in this situation. Solaris has neat things like RBAC which make things like PolicyKit redundant. Note the PolicyKit used by HAL on Solaris has been molded into a thin wrapper around RBAC with very limited functionality anyway. It is limited because most PolicyKit features are not useful on Solaris since GNOME already uses RBAC directly for most lockdown features and many Linux programs that use PolicyKit like package management systems are not used on Solaris. While the current HAL-based solution is a bit cobbled together, it does seem to work well enough for now. So I think we have some time to consider how to best solve these problems. Brian _______________________________________________ desktop-discuss mailing list desktop-discuss@opensolaris.org
