Re: systemd as external dependency

[Brian Cameron <brian cameron oracle com>]

To give some perspective from Oracle.  I think those who work on the
Desktop at Oracle have worked on GNOME for years, and love it.  Over
the years, Oracle has worked hard to contribute in positive ways to our
shared efforts of providing a great, free desktop accessible to all
users.  We plan for this to continue, and we hope that systemd nor
anything else will turn into any sort of roadblock to non-GNU/Linux
participation in the community.

In my discussions with people at Oracle, there is some concern about
how interfaces like systemd are being managed.  Interface management is
something that Sun (and now Oracle) obsesses about, as many of you who
have heard about our "ARC" process know.  Many people at Oracle ask me
questions about what is going on, but I myself have trouble following
the evolution from HAL to systemd or how exactly this impacts GNOME on
non-Linux systems.  I am still digesting the fact that ConsoleKit is
going away.  Is there a clear big picture, timeline, or roadmap yet?

I know that people in the GNOME community understand how important good
documentation is, but there is probably more that could be done to get
the systemd message out there in an inviting manner, especially if
there is a serious interest to get wider, especially non-Linux,
involvement.

That said, I think everybody in the free software community understands
that in order to make a competitive free software desktop, it needs to
evolve rapidly.  There are 900 pound gorillas in the room (Windows and
Apple) and new smaller, smarter devices to consider.  I applaud those
who are working on projects like systemd that can make a real
difference.  Sometimes code needs to be written and thrown away as a
prototype.  If it turns out that ConsoleKit, DeviceKit, or even systemd
continues to evolve in volatile ways, then such is the way of rapid
development.  I think the developers at Oracle are excited to figure
out how to get GNOME 3 working well on Solaris.

At the very least, I hope we can design a desktop so that if systemd is
not present this just disables those parts of the desktop that require
it.  Not having systemd may disable support for things like removeable
media, power management, etc.  There should not be a reason why not
having systemd should prevent GNOME from being used at all.

Note that much of the functionality that systemd, PolicyKit, or HAL
(just some examples) provide are lost for Sun Ray users, who are a main
focus of the Oracle desktop.  Sun Ray devices tend to use tightly
controlled desktop environments with no administrative GUI programs
facing the user.  Those programs which do interact with devices and the
kernel tend to be supported by Oracle-specific programs already (IPS
package manager, NWAM network admin, etc.).  The average Solaris desktop
user is quite different from the average Linux desktop user, you see.
So I do not think Solaris really needs much of systemd functionality
anyway.  In other words, systemd may not impact Solaris as much as you
might think.

The only thing HAL is currently used for in Solaris is removeable
media (e.g. USB) support.  Sun Ray client devices do have USB jacks, so
it would be neat to have better removeable media support for them.
Sadly, HAL on Solaris today only supports the desktop on the console,
so there really is not any removeable media support in GNOME for Sun
Ray users.  We need to rework all this code anyway.  Perhaps it makes
sense to solve this problem together via systemd?

Although Sun Ray users are a major focus, many people do use Solaris on
laptop and desktop computers.  Oracle obviously wants to provide them
with a great experience.  So a transition to GNOME 3 for Oracle seems
like it could be rather clear.  Providing a GNOME 3 desktop for
desktop/laptop users and Sun Ray users would use the fallback mode.
This seems a sensible approach as long as GNOME continues to embrace
non-Linux systems.

I think developers at Oracle would be very interested in helping
resource a project like systemd if there is an interest to put together
a design that could support multiple back-ends.  At least for those
interfaces needed to support HAL-like removeable media features.

Brian


On 05/18/11 10:33 AM, Paul Cutler wrote:
> On Wed, May 18, 2011 at 10:15 AM, Luca Ferretti<lferrett gnome org>  wrote:
> > Il giorno mer, 18/05/2011 alle 10.40 -0400, William Jon McCann ha
> > scritto:
> >
> > > > Having optional Linux-only functionalities is OK;
> > > > requiring Linux is not.
> > >
> > > For Debian perhaps.  However, I don't think this is true for GNOME.
> > > The future of GNOME is as a Linux based OS.
> >
> > What's the official position adopted by GNOME Foundation about this
> > statement?
> >
> > And was this statement communicated in a neat and undoubtful way to
> > GNOME contributors and third parties? I mean stuff like: "What is GNOME
> > OS", "Relationship between future GNOME OS and currently existing
> > distro", and so on...
> >
> >
> > Cheers, Luca
>
> Without talking to the whole board (yet), we have supported the
> Release Team's direction of defining GNOME core and a broader
> definition of GNOME applications.
>
> When talking to partners, we continue to talk about GNOME as two
> things:  the GNOME desktop (which constitutes GNOME core +
> applications) and the GNOME Developer Platform, which allows partners
> to build on and extend GNOME technologies.  Unity, MeeGo, Sugar and
> more are built on the GNOME Developer Platform and we're proud GNOME
> technologies can be used in other areas.
>
> Longer term, I personally believe there will be opportunities to
> define GNOME core as GNOME OS, which could also lead to some
> interesting decisions to be made about the GNOME brand.
>
> I will be adding this as an agenda topic in future Board meetings and
> I look forward to discussing this more at the Desktop Summit this year
> with Foundation members in person.
>
> Paul
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list