GNOME and non-linux platforms (release team please stand up)

[Christian Fredrik Kalager Schaller-3]

A topic that was discussed in the hallways in Gran Canaria is the fact
that GNOME has gone from not letting non-linux platforms hold back
development of features (ie. introduction of HAL) to making choices that
basically means we are abandoning any attempts of allowing GNOME to run
on non-linux platforms.

The switch from HAL to udev is maybe the clearest one, but the push
towards PulseAudio for a lot of things have the same effect, as I think
Lennart has said multiple times that none of the non-linux systems like
Solaris or FreeBSD got a sound system capable of supporting PulseAudio.

Personally I don't necessarily object to this choice, as giving 95% of
our userbase a better and more competitive experience critical for
future growth, and trying to come up with lowest common denominator
abstractions might be a hindrance for that, but I do object to the fact
that we are making this choice without actually having made it.

So I would like to ask the GNOME release team to please come forward
and clearly state that the future of GNOME is to be a linux desktop
system as opposed to a desktop system for any Unix-like system.

Christian

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Calum Benson]

On 22 Jul 2009, at 12:50, Christian Fredrik Kalager Schaller wrote:

> So I would like to ask the GNOME release team to please come forward
> and clearly state that the future of GNOME is to be a linux desktop
> system as opposed to a desktop system for any Unix-like system.

This is by no means an "official Sun response" to this proposal, just  
the thoughts of somebody who's worked on GNOME at Sun for the past 9  
years or so...

It goes without saying that I'd be disappointed if GNOME were to take  
any official Linux-only stance.  Sun has contributed a great deal to  
GNOME both technically and financially over the years, and although  
there aren't nearly as many familiar Sun faces on the GNOME mailing  
lists and IRC channels as there used to be (or, indeed, as I'd like),  
there's still a good-sized team of GNOME development and QA folks  
working here and contributing upstream as and when we can.  (FWIW, in  
addition to sponsoring the event again this year, a dozen or so of us  
made the trip to Gran Canaria this month, which, bar a couple of  
exceptions, is about the same or more as we've sent to every previous  
GUADEC.)

That said, many of the Sun team do seem to spend more time than they  
ought to just to keep GNOME running on OpenSolaris on the various Sun  
platforms these days.  They often have to deal with various Linux-isms  
at a code or conceptual level, or with technologies that are coming  
late to Linux and are implemented completely differently from the  
equivalent used by Sun (e.g. RBAC v PolicyKit, Trusted OpenSolaris v  
SELinux), or with performance or scalability issues that don't affect  
the average Linux desktop or enterprise user, but that would make  
GNOME unusable on the hundreds of thousands[1] of Sun Ray thin clients  
out there.

All that tends to leave us less time to make the larger-scale  
contributions that we used to make to GNOME and its related projects.  
Historically, that included things like implementing multi-head  
support for gtk, designing and implementing the original accessibility  
framework, writing and reviewing large chunks of user documentation,  
collaborating on regular HIG updates, performing UI reviews and  
usability studies, etc.  All these things would probably have been  
gotten around to eventually, but at the very least, I think it's fair  
to say these sorts of contributions from the non-Linux side of the  
fence got GNOME to where it is today a good deal quicker than would  
otherwise have been the case.

Now, there's no denying that until fairly recently, it was hard for  
most non-Sun contributors to even test their stuff on Solaris, so you  
could argue we're reaping what we sowed to some extent on that front.  
Nowadays, though, OpenSolaris comes on a LiveCD and runs in VirtualBox  
or in a dual-boot scenario pretty much as well as any Linux distro.  
So it shouldn't be all that hard to at least check once in a while  
that whatever you're working on is at least going to build, preferably  
run, and ideally function in an OpenSolaris environment[2].

Anyway, if anything, I guess I'd argue that it's time to actually  
reinforce the notion that the GNOME desktop is intended for use on any  
Unix-like system, and to figure out how to better distribute the  
development and QA workload to make that happen, so that non-Linux  
contributors have more chance to make significant contributions  
upstream again instead of spending most of their time treading  
downstream water.

Cheeri,
Calum.

[1] Okay, I don't actually have any idea how many Sun Ray clients are  
out there, but I'm guessing the order of magnitude is roughly  
correct.  If anything, it's probably an underestimate.

[2]  Or indeed any other non-Linux environments that you might wish to  
explore to expand your technological horizons in your copious free  
time :)

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum.benson@...            OpenSolaris Desktop Team
http://blogs.sun.com/calum             [phone]

Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Paul Cutler-3]

From a user perspective, and I know this is a very tiny sample, but out of the 230 responses to the Friends of GNOME survey of those who gave money, 30% indicated that they use GNOME applications on multiple platforms.  That's a significant percent of those who responded to they survey - just something to think about.

Paul

On Wed, Jul 22, 2009 at 9:31 AM, Calum Benson <Calum.Benson@...> wrote:

On 22 Jul 2009, at 12:50, Christian Fredrik Kalager Schaller wrote:

So I would like to ask the GNOME release team to please come forward
and clearly state that the future of GNOME is to be a linux desktop
system as opposed to a desktop system for any Unix-like system.

This is by no means an "official Sun response" to this proposal, just the thoughts of somebody who's worked on GNOME at Sun for the past 9 years or so...

It goes without saying that I'd be disappointed if GNOME were to take any official Linux-only stance.  Sun has contributed a great deal to GNOME both technically and financially over the years, and although there aren't nearly as many familiar Sun faces on the GNOME mailing lists and IRC channels as there used to be (or, indeed, as I'd like), there's still a good-sized team of GNOME development and QA folks working here and contributing upstream as and when we can.  (FWIW, in addition to sponsoring the event again this year, a dozen or so of us made the trip to Gran Canaria this month, which, bar a couple of exceptions, is about the same or more as we've sent to every previous GUADEC.)

That said, many of the Sun team do seem to spend more time than they ought to just to keep GNOME running on OpenSolaris on the various Sun platforms these days.  They often have to deal with various Linux-isms at a code or conceptual level, or with technologies that are coming late to Linux and are implemented completely differently from the equivalent used by Sun (e.g. RBAC v PolicyKit, Trusted OpenSolaris v SELinux), or with performance or scalability issues that don't affect the average Linux desktop or enterprise user, but that would make GNOME unusable on the hundreds of thousands[1] of Sun Ray thin clients out there.

All that tends to leave us less time to make the larger-scale contributions that we used to make to GNOME and its related projects.  Historically, that included things like implementing multi-head support for gtk, designing and implementing the original accessibility framework, writing and reviewing large chunks of user documentation, collaborating on regular HIG updates, performing UI reviews and usability studies, etc.  All these things would probably have been gotten around to eventually, but at the very least, I think it's fair to say these sorts of contributions from the non-Linux side of the fence got GNOME to where it is today a good deal quicker than would otherwise have been the case.

Now, there's no denying that until fairly recently, it was hard for most non-Sun contributors to even test their stuff on Solaris, so you could argue we're reaping what we sowed to some extent on that front.  Nowadays, though, OpenSolaris comes on a LiveCD and runs in VirtualBox or in a dual-boot scenario pretty much as well as any Linux distro.  So it shouldn't be all that hard to at least check once in a while that whatever you're working on is at least going to build, preferably run, and ideally function in an OpenSolaris environment[2].

Anyway, if anything, I guess I'd argue that it's time to actually reinforce the notion that the GNOME desktop is intended for use on any Unix-like system, and to figure out how to better distribute the development and QA workload to make that happen, so that non-Linux contributors have more chance to make significant contributions upstream again instead of spending most of their time treading downstream water.

Cheeri,
Calum.

[1] Okay, I don't actually have any idea how many Sun Ray clients are out there, but I'm guessing the order of magnitude is roughly correct.  If anything, it's probably an underestimate.

[2]  Or indeed any other non-Linux environments that you might wish to explore to expand your technological horizons in your copious free time :)

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum.benson@...            OpenSolaris Desktop Team
http://blogs.sun.com/calum             [phone]

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Johannes Schmid-4]

Hi!

> Now, there's no denying that until fairly recently, it was hard for  
> most non-Sun contributors to even test their stuff on Solaris, so you  
> could argue we're reaping what we sowed to some extent on that front.  
> Nowadays, though, OpenSolaris comes on a LiveCD and runs in VirtualBox  
> or in a dual-boot scenario pretty much as well as any Linux distro.  
> So it shouldn't be all that hard to at least check once in a while  
> that whatever you're working on is at least going to build, preferably  
> run, and ideally function in an OpenSolaris environment[2].

That's not in anyway Sun- or (insert-your-os-here)-specific. Say, I want
to test my module against the most used os/platform, I would at least
have to test (in no particular order):

* Ubuntu (ok, I tend to use that for work)
* Fedora
* OpenSuSE
* Gentoo
* FreeBSD
* OpenBSD
* NetBSD
* OpenSolaris
(to be continued)

OK, I can install all those in a virtual machine but just the amount of
work I had to put in for basic testing cannot be really done in my free
time.

I think downstream contributers simply have to test our alpha and beta
versions and at least file bugs if they don't work. I am sure most
maintainers will happily fix them or apply patches.

In addition, we should start some discussion before introducing a new
technologie with at least *Linux, *BSD and *Solaris if this technologie
works for them or can be made work.

But this shouldn't stop us on the other hand to deliver the user the
latest and best features for her desktop because she simply doesn't care
about the technologies used.

Regards,
Johannes


_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Calum Benson]

On 22 Jul 2009, at 15:56, Johannes Schmid wrote:

> OK, I can install all those in a virtual machine but just the amount  
> of
> work I had to put in for basic testing cannot be really done in my  
> free
> time.

That's certainly true for many individual contributors, which is why I  
also said we ought to "to figure out how to better distribute the  
development and QA workload to make that happen".

However, for people who make their living developing GNOME software,  
IMHO it behooves them as professional open source software engineers  
to respect the requirements of the other people who will be using the  
code they write, insofar as those requirements are known up front.  
And right now, every professional GNOME developer knows up front that  
GNOME isn't confined to running on Linux, so that should figure fairly  
strongly into their design work.

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum.benson@...            OpenSolaris Desktop Team
http://blogs.sun.com/calum             [phone]

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Matthias Clasen-2]

On Wed, Jul 22, 2009 at 7:50 AM, Christian Fredrik Kalager
Schaller<uraeus@...> wrote:

> So I would like to ask the GNOME release team to please come forward
> and clearly state that the future of GNOME is to be a linux desktop
> system as opposed to a desktop system for any Unix-like system.
>

Why would we do that ? This is not a question about exclusion, it is a
question about moving the platform forward that our desktop is
standing on.

A desktop that is based on a stagnant, costly abstraction layer may be
easier to get running on a large number of minority unixoid platforms,
but the cost of that approach is that we are not going to be able to
compete with other desktops that make the changes in the lower layers
which are necessary to provide desktop features of 2010, rather than
2000.

Matthias
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Tristan Van Berkom]

On Wed, Jul 22, 2009 at 7:50 AM, Christian Fredrik Kalager
Schaller<uraeus@...> wrote:
> So I would like to ask the GNOME release team to please come forward
> and clearly state that the future of GNOME is to be a linux desktop
> system as opposed to a desktop system for any Unix-like system.

I dont think anyone wants to do that, as Matthias says we need to
pave the way for a better future, and of course you cant do that without
breaking a few eggs.

On the other hand, its possible we could do better tracking this stuff,
is there a l.g.o. page that I can visit that shows me what are the blocker
bugs in the platform for any given supported system ?

Considering that many people test out the GNOME platform on various
systems already, I wonder how much effort it would cost us to instate
a team responsible for tracking system specific bugs and then publishing
these on a wiki page, pretty much the same way we have translation
teams (a system could possibly only be "supported" when its blockers
are closed ?, while work is done "supporting" that system ?)

Cheers,
               -Tristan
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[David Zeuthen]

On Wed, 2009-07-22 at 16:27 +0100, Calum Benson wrote:

> On 22 Jul 2009, at 15:56, Johannes Schmid wrote:
>
> > OK, I can install all those in a virtual machine but just the amount  
> > of
> > work I had to put in for basic testing cannot be really done in my  
> > free
> > time.
>
> That's certainly true for many individual contributors, which is why I  
> also said we ought to "to figure out how to better distribute the  
> development and QA workload to make that happen".
>
> However, for people who make their living developing GNOME software,  
> IMHO it behooves them as professional open source software engineers  
> to respect the requirements of the other people who will be using the  
> code they write, insofar as those requirements are known up front.  
> And right now, every professional GNOME developer knows up front that  
> GNOME isn't confined to running on Linux, so that should figure fairly  
> strongly into their design work.

You know, maybe if the non-Linux platforms actually participated in
_designing_ and _developing_ the core plumbing bits, threads like this
wouldn't have to happen.

My experiences from GIO, GVfs and HAL and other things pretty much sums
up to this.

 1. We find out we need some new plumbing bits to enable some kind
    of new exciting feature in GNOME.

 2. Someone starts working on a Linux implementation of this. The
    interface is usually designed to be portable, but, hey, who
    knows.

 3. GNOME is ported to using this new plumbing bit. After a while the
    plumbing bit matures and the new feature is being ironed out.
    Much rejoicing.

 4. Someone from SUN finds out that the latest version of some GNOME
    doesn't compile on Solaris or work as advertised. Interesting bugs
    are filed.

 5. Some manager at SUN decides Solaris needs this feature too

 6. The "porting" effort is out-sourced to some group in SUN
    with people that are not really familiar with either a) the
    plumbing bits in question; b) desktop development or GNOME
    development in general

This may be harsh but it's pretty much how I feel it works.

It would be a lot better if non-Linux platforms, like Solaris is in this
respect, actually started participating much earlier. You still have
time for the DeviceKit-disks and DeviceKit-power stuff for example.

Anyway, if SUN started changing this behavior then maybe it would be a
lot easier to not feel incredibly insulted by statements like "it
behooves them as professional open source software engineers to respect
the requirements". Because right now it's the pot calling the kettle
black.

     David


_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Jason D. Clinton]

On Wed, Jul 22, 2009 at 10:27 AM, Calum Benson <Calum.Benson@...> wrote:

On 22 Jul 2009, at 15:56, Johannes Schmid wrote:

OK, I can install all those in a virtual machine but just the amount of
work I had to put in for basic testing cannot be really done in my free
time.

That's certainly true for many individual contributors, which is why I also said we ought to "to figure out how to better distribute the development and QA workload to make that happen".

However, for people who make their living developing GNOME software, IMHO it behooves them as professional open source software engineers to respect the requirements of the other people who will be using the code they write, insofar as those requirements are known up front.  And right now, every professional GNOME developer knows up front that GNOME isn't confined to running on Linux, so that should figure fairly strongly into their design work.

I am extremely grateful for all that Sun has done to move GNOME forward over the years--indeed much of that has benefited everyone including Linux. But, pardon me for pointing out the pink elephant in the room: why doesn't Sun just admit that (Open)Solaris is a dead-end?

I mean, we all understood that Solaris was proprietary until recently. But now that Sun has admitted that wasn't going to work, why not just go the next logical step? ZFS is nice and all but you *do* hold the copyright. If the right managerial decision were to be made--say tomorrow--we wouldn't be having this conversation and Sun wouldn't even be out any business.

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Colin Walters]

On Wed, Jul 22, 2009 at 10:31 AM, Calum Benson<Calum.Benson@...> wrote:
>
> It goes without saying that I'd be disappointed if GNOME were to take any
> official Linux-only stance.  Sun has contributed a great deal to GNOME both
> technically and financially over the years.

Definitely, Sun's contributions have been awesome.

> That said, many of the Sun team do seem to spend more time than they ought
> to just to keep GNOME running on OpenSolaris on the various Sun platforms
> these days.  They often have to deal with various Linux-isms at a code or
> conceptual level, or with technologies that are coming late to Linux and are
> implemented completely differently from the equivalent used by Sun (e.g.
> RBAC v PolicyKit)

This is really the *only* one I can think of.  TSOL vs SELinux isn't
really relevant here since GNOME core doesn't really do much with
SELinux currently.

> Anyway, if anything, I guess I'd argue that it's time to actually reinforce
> the notion that the GNOME desktop is intended for use on any Unix-like
> system,

Here's the fundamental problem as I see it - GNOME filled the "Unix
like system desktop" checkbox over 10 years ago, on top of POSIX, X11,
and some random bits.  A lot of what we've been doing since is filling
in the stuff for a *complete operating system*, because POSIX and X
cover so little. Stuff like having USB devices work, power management,
and networking are hard problems that cross every layer from the
kernel to the desktop UI.  It's hard to build this kind of stuff upon
what I think of as "towers of turtles" i.e. abstractions.

I think it makes sense to continue to have GNOME work in the basic
"POSIX+X11" mode, i.e. gnome-power-manager just calls exit(0) if
devicekit-power isn't running.  But beyond that is hard.
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Colin Walters]

On Wed, Jul 22, 2009 at 3:10 PM, Colin Walters<walters@...> wrote:
>
> I think it makes sense to continue to have GNOME work in the basic
> "POSIX+X11" mode, i.e. gnome-power-manager just calls exit(0) if
> devicekit-power isn't running.  But beyond that is hard.

I should add that despite it being hard, the different interests here
should try to have a constructive conversation about it.

Some of this is more easily divisible than others; nothing directly
depends on nm-applet, and most projects using say
org.freedesktop.NetworkManager already have it conditional, and it's
not hard to do.  For other things like detecting a webcam device and
using it...well...hard.
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Dan Winship-2]

On 07/22/2009 02:21 PM, Tristan Van Berkom wrote:
> On Wed, Jul 22, 2009 at 7:50 AM, Christian Fredrik Kalager
> Schaller<uraeus@...> wrote:
>> So I would like to ask the GNOME release team to please come forward
>> and clearly state that the future of GNOME is to be a linux desktop
>> system as opposed to a desktop system for any Unix-like system.
>
> I dont think anyone wants to do that

I do.

> I wonder how much effort it would cost us to instate
> a team responsible for tracking system specific bugs and then publishing
> these on a wiki page, pretty much the same way we have translation
> teams (a system could possibly only be "supported" when its blockers
> are closed ?, while work is done "supporting" that system ?)

I think l10n in GNOME is a great model for how portability (p9y?) could
work. Module maintainers are responsible for making their apps
translatable, but are not responsible for actually translating them.
Likewise, we could say that module maintainers are expected to make
their modules "portable" (eg, isolating Linux-specific bits behind
#ifdefs or abstractions or external dependencies), but would not be
responsible for any actual *porting*--that would be the responsibility
of the "porting team" for a given platform. And if a module didn't get
ported to a given platform in time for a given release, that would not
be the module maintainer's fault, and it wouldn't delay the release.

-- Dan
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[David Zeuthen]

On Wed, 2009-07-22 at 15:50 -0400, Colin Walters wrote:

> On Wed, Jul 22, 2009 at 3:10 PM, Colin Walters<walters@...> wrote:
> >
> > I think it makes sense to continue to have GNOME work in the basic
> > "POSIX+X11" mode, i.e. gnome-power-manager just calls exit(0) if
> > devicekit-power isn't running.  But beyond that is hard.
>
> I should add that despite it being hard, the different interests here
> should try to have a constructive conversation about it.
>
> Some of this is more easily divisible than others; nothing directly
> depends on nm-applet, and most projects using say
> org.freedesktop.NetworkManager already have it conditional, and it's
> not hard to do.  For other things like detecting a webcam device and
> using it...well...hard.

Exactly.

FWIW, I've been advocating for a while that, for example, GStreamer
should aim to provide everything an application needs - ie. a complete
framework. This came up when Cheese was being ported from HAL to use
libgudev for device discovery. Now, the actual device interaction
already happened in GStreamer, e.g. you use the v4l source and pass it a
device file. But device detection etc. was missing. Having all that in
GStreamer will make Cheese easily portable to Solaris, Windows, OS X and
so on (and AFAICT these changes are happening in GStreamer so kudos to
these guys).

On a more general note, the way I'd like our platform story to end up is
that GLib, GTK+ and GStreamer are the three only (sets of) libraries
that people end up using. We're there already for storage/io devices
(GVolumeMonitor) and networking (the networking/resolving bits that
recently landed in GIO).

The way it works for storage/io is through GIO extension points:

 - The interface library (GIO) provides default implementations
   (GUnixVolumeMonitor, GWin32DirectoryMonitor for example)

 - Modern desktop operating systems can be replace implementations
   with in 3rd party packages. We do this in GVfs - there's a HAL
   based volume monitor that works on Linux, FreeBSD and Solaris.

In fact, thanks to this separation it was relatively straightforward to
just make GIO use DeviceKit-disks instead of HAL. And Solaris and
FreeBSD can keep using the HAL monitor while modern Linux distros switch
to the DeviceKit-disks based on.

(In fact, if the Solaris folks don't want to go through the effort of
porting DeviceKit-disks (it's *hard* to port right now, something I as
the maintainer will need to be involved in fixing), they can simply just
write their own GVolumeMonitor implementation.)

Another benefit of this separation is that we are less dependent on
changes in one particular operating system. This is doubly-plus
important in Linux where our current code depends on certain kernel
API / details that are not stable. A concrete example is the proposed
libata transition from the SCSI layer to the block layer. If each and
every app had to look at sysfs themselves, we'd be in porting hell.

To sum up, I guess I'm trying to say a couple of things here

 1. We need to make our core libraries genuinely useful - e.g. we
    can't have them only do half of what apps need (e.g. Cheese)

 2. We need to actually have some documentation telling app developers
    _what_ the core platform is. We have some of this already but,
    at least in my eyes, there's still too many libraries of varying
    quality.

For 2., my view is very simple.

 a. Our platform is GLib, GTK+ and GStreamer (and probably cool things
    like Clutter when it's 1.0)

 b. Everything in the core platform _needs_ to work on all three major
    platforms:
    - POSIX/X11
    - Windows
    - OS X

 c. Additional desktop integration is welcome (e.g. DeviceKit-disks
    based volume monitor) but things need to work without it

Now, GLib, GTK+ and GStreamer aren't yet complete enough to do a
complete desktop. But if you look at what's going on the past few years
we are definitely going in this direction:

 - GIO landed
 - GNIO landed
 - Discussion/concrete code for GConf replacement (GSettings in GLib)
 - Discussion/concrete code for G-ish D-Bus library in GLib
 - Some people want power management interfaces in GTK+ - again,
   this can already be done with extension points
   - (e.g. the POSIX/X11 would ENOTSUP, Linux would use devkit-power,
      Win32 would use the Win32 API, OS X would use the OS X API)

and so on. Oh, and there are some loose ends here like authorization,
keyring and so on - we'd need to figure out what to do with them. And
someone probably would want a HTML/JS stack too (maybe add WebKit to the
stack, I don't know).

So this is the vision: GLib/GTK+/GStreamer (and Clutter) is the proposed
stack. And the proposal is that this stack runs on at least POSIX/X11,
Win32, OS X. And that the stack is easily extensible so it works well
under Linux, Solaris providing someone writes implementations of
well-defined interfaces.

Again, all this is not really a radical _new_ idea - I mean, most of
this is already happening. But I think it would be good to have a very
clear and simple document saying this is where we are going. That is, if
people agree with this vision (points a. through c. above).

Anyway, my couple of hundred cents on this.

     David


_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Colin Walters]

On Wed, Jul 22, 2009 at 5:07 PM, David Zeuthen<david@...> wrote:

I agree with a lot of what you say, except:

>  b. Everything in the core platform _needs_ to work on all three major
>    platforms:
>    - POSIX/X11

This isn't a platform really.  Which is really the entire debate here.
 They're enough, along with maybe a file monitoring API, to write the
classic "shared Unix server desktop, complete with file manager,
clock, and panel".  But beyond that - enterprise (let alone consumer)
laptops in particular, no way.

If you guys working on DeviceKit-* are willing to have different
backends, then that sounds fine.  It's not a complete answer, but it
fills in the massive gap that removing HAL left.  If not, then we have
to think about the story GNOME is going to tell here.  Maybe it just
ends up being gnome-power-manager isn't even added to the session if
there's no DK-power, and vendors have to fill in that gap on their
own, i.e. it'd be renamed gnome-dk-power-manager, and someone else
could come by and add a different daemon.
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Calum Benson]

On 22 Jul 2009, at 20:10, Colin Walters wrote:

>
> This is really the *only* one I can think of.  TSOL vs SELinux isn't
> really relevant here since GNOME core doesn't really do much with
> SELinux currently.

(It does enough that we've had to patch bits out of the Nautilus file  
properties GUI, in the past... don't know if that's currently the  
case, though.)

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum.benson@...            OpenSolaris Desktop Team
http://blogs.sun.com/calum             [phone]

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[David Zeuthen]

On Wed, 2009-07-22 at 17:36 -0400, Colin Walters wrote:

> On Wed, Jul 22, 2009 at 5:07 PM, David Zeuthen<david@...> wrote:
>
> I agree with a lot of what you say, except:
>
> >  b. Everything in the core platform _needs_ to work on all three major
> >    platforms:
> >    - POSIX/X11
>
> This isn't a platform really.  Which is really the entire debate here.
>  They're enough, along with maybe a file monitoring API, to write the
> classic "shared Unix server desktop, complete with file manager,
> clock, and panel".  But beyond that - enterprise (let alone consumer)
> laptops in particular, no way.

No, but it's a starting point. Just like GUnixVolumeMonitor is a
starting point. And the same way GFileMonitor has a FAM backend (that
FreeBSD is still using as far as I can tell). People can fill in the
blanks with better implementations.

> If you guys working on DeviceKit-* are willing to have different
> backends, then that sounds fine.  It's not a complete answer, but it
> fills in the massive gap that removing HAL left.  If not, then we have
> to think about the story GNOME is going to tell here.  

We might but it's a lot of work. It is probably worth it.

> Maybe it just
> ends up being gnome-power-manager isn't even added to the session if
> there's no DK-power, and vendors have to fill in that gap on their
> own, i.e. it'd be renamed gnome-dk-power-manager, and someone else
> could come by and add a different daemon.

It's important to make a clear distinction between apps and the G stack.
For something like storage handling, every app needs it for the file
chooser. And for things being able to implement a file manager. So we
implement just enough of it in the G stack so it is useful.

For example, Nautilus basically (that's a big basically, but...) only
depends on GLib and GTK+ right now. But we don't offer enough API in the
G stack to write e.g. Palimpsest Disk Utility - e.g. if you want to
write a formatting tool, partitioning utility, whatever you need to
depend on something outside the platform. It just means that ISVs can
only write file managers and not advanced disk utilities. And that's
fine.

For power management, maybe we only offer basic API in the G stack to do
what apps need: E.g. inhibit system suspend / inhibit screensaver. And,
again, that's completely fine. We don't expect ISVs to be able to
implement complete desktop environments.

For Bluetooth, another Linux only thing for now, the answer is the same;
we probably don't need Bluetooth specific APIs - mostly because we
already abstract the useful Bluetooth stuff in GVfs and PulseAudio.

For Audio, it is basically the same. Apps don't really *need* to care
about whether it's Pulse/OSSv4 or whatever. They are supposed to be
using GStreamer *anyway*. So we probably don't need to provide any API
in the G stack except for things things like libcanberra which is
already portable to whatever.

Anyway, my main point is this: the POSIX/X11 target isn't so much about
making "GNOME, the desktop" run on POSIX/X11. It's about making apps
*built* for "GNOME, the desktop", e.g. apps using only the G stack (e.g.
GLib / GTK+ / GStreamer / Clutter / Webkit / whatever) run on any random
POSIX/X11 system. Or any random Win32 or OS X system.

In *addition* we could require that the basic desktop shell (core apps
such as Nautilus, gnome-panel - gnome-shell in the future) needs to be
pure apps - e.g. only rely on the G stack. We'd probably want that even
if it means the basic desktop shell would run in degraded mode (e.g.
missing functionality).

This would of course also means that some apps that people think of as
"core GNOME apps", such as gnome-power-manager wouldn't really be pure
apps (only using the G stack) insofar they would have strong deps on
things outside the G stack (e.g. devkit-power). Again, that's completely
fine.

It's all about how we *frame* it

 - G Stack (runs on any target)
   - gtk+/glib/gstreamer/clutter/webkit/whatever
 - G apps (can only depend on the G stack)
   - panel, file manager, desktop shell
 - Value add apps (may be OS specific)
   - disk utility / formatting / etc.
   - power manager
   - volume control (highly OS specific)

In my view this is very close to how things actually work. If we made
something like this official we wouldn't have to waste time arguing
whether the volume control is depending on PulseAudio or not.... of
course it would leave vendors not shipping PulseAudio in the cold, but
then again, these vendors can just work on their own volume control (or
take the GStreamer one) and do whatever they want. That's completely
fine.

So all in all, this is basically proposing shifting more responsibility
to the OS vendor. e.g. it would make it more difficult to get GNOME
working out of the box unless you are willing to ship the latest bits.
I, for one, think that is a *good* thing. Either you swim or you sink.

      David


_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Bastien Nocera]

On Wed, 2009-07-22 at 18:17 -0400, David Zeuthen wrote:
>
> For Bluetooth, another Linux only thing for now, the answer is the
> same;
> we probably don't need Bluetooth specific APIs - mostly because we
> already abstract the useful Bluetooth stuff in GVfs and PulseAudio.

Actually, not quite. The BlueZ D-Bus API is already an abstraction of
the Bluetooth specs. You could implement that same API in another daemon
for use on other Bluetooth stacks.

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Olav Vitters]

On Wed, Jul 22, 2009 at 01:40:51PM -0500, Jason D. Clinton wrote:
> pardon me for pointing out the pink elephant in the room: why doesn't Sun
> just admit that (Open)Solaris is a dead-end?

<moderator hat on>
Everyone: Please refrain from posting to any replies to this email or
anything which followed up on this email. Thanks.
</moderator hat on>

--
Regards,
Olav
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Calum Benson]

On 22 Jul 2009, at 19:30, David Zeuthen wrote:

> You know, maybe if the non-Linux platforms actually participated in
> _designing_ and _developing_ the core plumbing bits, threads like this
> wouldn't have to happen.

<snip>

> Anyway, if SUN started changing this behavior then maybe it would be a
> lot easier to not feel incredibly insulted by statements like "it
> behooves them as professional open source software engineers to  
> respect
> the requirements". Because right now it's the pot calling the kettle
> black.

Oh, there's no doubt Sun and our ilk have to do much better as well--  
no argument at all there (although obviously Sun has indeed made  
significant contributions to various core plumbing bits in the past,  
and is still doing so in some areas).

But even still, Sun engineers working on GNOME for OpenSolaris can't  
really avoid the fact that whatever they do contribute upstream has to  
work on Linux first and foremost, so those contributions have usually  
seen at least some cursory Linux testing before they get that far.  
Whereas IMHO it's considerably easier for other contributors to  
overlook the fact, usually quite innocently, that they could increase  
the value of their contributions just by ensuring that they work with  
minimal effort on the other platforms that GNOME embraces.

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum.benson@...            OpenSolaris Desktop Team
http://blogs.sun.com/calum             [phone]

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

[Artem Kachitchkine]

Hi David,

> You know, maybe if the non-Linux platforms actually participated in
> _designing_ and _developing_ the core plumbing bits, threads like this
> wouldn't have to happen.
<snip>
> It would be a lot better if non-Linux platforms, like Solaris is in this
> respect, actually started participating much earlier. You still have
> time for the DeviceKit-disks and DeviceKit-power stuff for example.
>
> Anyway, if SUN started changing this behavior then maybe it would be a
> lot easier to not feel incredibly insulted by statements like "it
> behooves them as professional open source software engineers to respect
> the requirements". Because right now it's the pot calling the kettle
> black.

[Standard boilerplate, speaking for myself, not my employer.]

I did the initial HAL port to Solaris (but long since moved to other
stuff), you might remember me. With respect to benefits of early
participation, I agree with you completely - I learned the hard way and
have been trying to convince folks here not to repeat that mistake with
PolicyKit, ConsoleKit and DeviceKit - as you can witness, with little
success.

There is no single reason or person to be blamed: there's organizational
fragmentation and inertia; lack of funding; differences in engineering
culture; etc. I am getting a positive vibe from engineers slowly warming
up to the agile, iterative development style, so hopefully things are
moving in the right direction.

I wouldn't get too offended with what Calum said, I think it's the right
idea, though perhaps the proposed implementation isn't optimal in that
the testing cost distribution is lopsided. To give a simplified example,
what we had during HAL development sometimes, say, 0.x.y was released
based on Linux exclusively and we had to follow that up with a 0.x.y.1
release to fix FreeBSD/Solaris issues. With an established N-way
commitment from all interested platforms, I believe such issues could be
resolved upfront, leading to higher quality releases (less iterations)
and a more even cost distribution, with little effect on schedule.

So from a bystander's point of view, maintaining GNOME's platform
neutrality requires effort from both sides: from the ideological
leaders, maintaining portability as a core requirement, built in not
screwed on; and from interested platforms, continuous participation and
timely response.

-Artem

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers