Re: Requiring systemd for the gnome-settings-daemon power plugin
- From: Brian Cameron <brian cameron oracle com>
- To: Sebastien Bacher <seb128 ubuntu com>
- Cc: release-team <release-team gnome org>, "desktop-devel-list gnome org" <desktop-devel-list gnome org>, Bastien Nocera <hadess hadess net>
- Subject: Re: Requiring systemd for the gnome-settings-daemon power plugin
- Date: Fri, 19 Oct 2012 13:33:19 -0500
Some perspective about this issue from a Solaris perspective.
On non-Linux systems like Solaris there is little value in using
upstream GNOME code for some features. Power management is a
good example. On Solaris, power management uses Solaris-specific
interfaces and supports Solaris specific features. Solaris GNOME would
never see much value in a general-purpose GUI for power management.
Enterprise computing systems and clusters have unique power management
needs compared to a laptop or desktop, and any upstream power
management code is not going to consider how Solaris-specific
virtualization features like zones (or Solaris Containers) affects
power management. Most Solaris users use the desktop in a Sun Ray
environment where they typically should not be setting the power
management settings on their Sun Ray server anyway.
So, Solaris probably does not care about this plugin much as long
as it is possible to build GNOME without the feature and allows
custom power management solutions to be integrated in some other
reasonable way. Maybe BSD or other non-Linux distros cares about power
management more? There is probably some cross-over between Solaris and
BSD, and some differences like perhaps power management.
There certainty are some systemd features that probably need to be made
to work across all non-Linux systems to make GNOME work well. The
systemd interfaces needed to make display management and the user
session work, for example.
Since the GNOME community seems disinterested in defining standard
FreeDesktop interfaces for these features, perhaps it is necessary
to develop some sort of bridge to make needed systemd functions
work across non-Linux systems.
The GNOME community provides little guidance about what systemd
interfaces are actually needed for various GNOME features to work
properly. Maybe nobody really knows yet, but non-Linux distros will
likely make slow progress as long as there is so little good
I do understand that the non-Linux GNOME community has to figure
out the solutions to these problems by pulling themselves up by
their bootstraps to a degree. That said, is it just me, or does it
seem there is a harshly discouraging attitude about this amongst the
community? Perhaps I am just reading too much into what seems a
general lack of discussion about systemd decisions or interface
migration? It seems I keep finding out about decisions after they
seem to pretty much decided upon already. We might make better
progress if we were even just a bit better about a more open and
inclusive design process.
I do know that amongst Solaris engineers there is an exhaustion
of having to adopt, rewrite, and throw-away interfaces as often as the
GNOME community seems to do. This does create resistance towards
adopting the latest features. I do not mean to complain, though.
Perhaps this sort of development style is just what is needed to
compete in the vibrant and ever-shifting desktop market we face
today. Not sure...
On 10/19/12 12:20 PM, Sebastien Bacher wrote:
Le 19/10/2012 15:41, Matthias Clasen a écrit :
I don't think that is a very productive way to have a discussion. What
are you hoping to achieve ?
The discussion went this way:
1: "g-s-d will drop non systemd support"
2: could we define standard interface that are up to the distributor to
implement rather than depends on systemd? an hard depends would mean
those choices for non systemd distributors: <list of options I could see>
1: "no, I don't intend to spend any time on that, if you don't want to
use systemd you need to work with systemd upstream"
2: "ok, well I guess we need to think what to do then, but it's limiting
our options to get GNOME shipped"
I'm not sure how "unproductive" it has been, it's merely stating intends
and sharing concerns...
What I'm hoping to achieve? I guess letting know GNOME, as a project,
know in what position this choice put some of the distributors and what
might be the outcome. It's sharing information and communicating ... is
there any issue with that?
desktop-devel-list mailing list
desktop-devel-list gnome org
] [Thread Prev