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

[Lin Guo]

Hi Richard,

It's really a good news. I am currently working on porting 
Devicekit-power to Solaris and engaged in replacing udev and sysfs 
related code with Solaris ones that implement the same functionality.


I will start working on the branch to get Solaris supported.

Best Regards,
Lin

On Tue, 2009-07-28 at 08:51 +0100, Richard Hughes wrote:
  

2009/7/24 David Zeuthen :


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.
  

In DeviceKit-power there is a not-just-gudev branch that separates the
linux specific code from the generic daemon code. I doesn't yet
compile (autotools help!), and is only lightly tested, but I'll
probably merge to master after a few weeks testing.

It would be great if FreeBSD/Solaris developers could start hacking on
this branch early, and tell me how hard porting would be. Thanks.

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




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

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

[Brian Cameron]

David:


On Tue, 2009-07-28 at 12:10 -0500, Brian Cameron wrote:

I have pinged the Sun team working on DeviceKit and suggested they
be better about communication with upstream by sending some status
to the devkit-devel mailing list.


Thanks.


I heard from Lin Guo at Sun that he has followed up and sent an email
to devkit-devel about our plans.  He works on the team at Sun which is
responsible for HAL, PolicyKit, and DeviceKit; so I hope this starts a
better dialog between Sun and the upstream community.


Also, Solaris has a security rule that requires that users not be asked
to enter passwords for gaining authorization unless they are in the
trusted path.  To my understanding, PolicyKit does not address this
issue today, perhaps because most Linux distros are not as strict about
this requirement.  This technical issue could be overcome, for example,
by switching to a separate VT in the trusted path to display the
dialog.


Yes, it is entirely possible to easily make PolicyKit use an
Authentication Agent that runs outside the session. If you wanted you
could even make the authentication agent communicate with a separate
device (for example a separate device connected via USB with small
display / big flashy button the user can press to authenticate the
request) or a mobile phone display (using BT for proximity)... or
whatever... e.g. the APIs are in place for such things.


Right.  I was not trying to suggest that this is necessarily a blocker
for integrating PolicyKit in Solaris.  Trusted path is particularly
important in the Trusted Solaris product.  Until the above work is done,
PolicyKit could, I am sure, be configured to do the right thing (e.g.
never pop up dialogs asking for passwords) in this environment.  The
fact that PolicyKit doesn't "just work" with Trusted Path today just
makes the process of integrating it into Solaris and making sure it is
configured properly in various environments, such as Trusted Solaris,
more complicated.


And, sure, for home/consumer usage just having both the screensaver
unlock dialog, the PolicyKit authentication dialogs and other stuff
(such as GMountOperation interaction [1]) running in a trusted sandbox
(e.g. separate Xserver/VT) is probably what we want. That way, nothing
running in the user session can ever snoop on passwords. Of course this
requires a lot of bug fixes in the X.org stack (it is essentially fast
user switching), we need a system compositor (like wayland), ConsoleKit
changes and so on... so blue sky for now.


Jon McCann gave a presentation at the 2007 GUADEC that he was interested
in making GDM manage the screen lock dialog in a separate VT, to better
address lock screen trusted path issues.  I do not think much work has
been done on this yet, but it does not sound too impossible.

If that work is done, perhaps the GDM interfaces could be further
extended so that programs like PolicyKit could call GDM to trigger
a similar authentication dialog.  Thus making GDM a single-point program
to manage authentication dialogs in a secure, trusted path manner.


Btw, I wonder how you implement screen locking (e.g. screen saver) /
connecting to network shares (e.g. gvfs) / ssh (via the terminal) if you
don't want people to enter passwords... seems like a weird backwards
requirement to only require it for gaining authorizations and not for
something like unlocking the screen.


As I mentioned above, for Sun trusted path is more of a concern with
Trusted Solaris.  The Trusted Solaris product locks down the user
environment so that users cannot do things like starting up a terminal
to run ssh or su, where they might enter a password.

Today in Solaris/OpenSolaris, the lock screen does not run in the
Trusted Path, unless you are using Trusted Solaris.  Trusted Solaris
makes use of an Xserver extension written by Sun (not too dissimilar to
SELinux) that forces the screen lock to run in the trusted path.  One
problem with this approach is that the lock screen is not accessible
when using Trusted Solaris.

Ideally it would be better to move away from this solution and use a
lock screen solution that "just worked" with trusted path without
hacking around with Xserver extensions.  For example, if GDM managed the
lock screen and provided a11y similarly as it does today for login, then
this would work better and would provide a more secure trusted path
environment for all users.


There has been some concern expressed about using PolicyKit with an RBAC
backend.  If Solaris ships configuration files for both RBAC and
PolicyKit, then users will likely need to understand and configure both
systems to properly configure their setup.  There is a desire to avoid
adding unnecessary complexity.  Perhaps a GUI that hides this complexity
from the user could help to address this concern.


The only thing you need is to figure out whether an mechanism-defined
action (as defined in the .policy file shipping with the mechanism) is
allowed or not. So you would just have a small 

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

[David Zeuthen]

On Tue, 2009-07-28 at 12:10 -0500, Brian Cameron wrote:
> I have pinged the Sun team working on DeviceKit and suggested they
> be better about communication with upstream by sending some status
> to the devkit-devel mailing list.

Thanks.

> Also, Solaris has a security rule that requires that users not be asked
> to enter passwords for gaining authorization unless they are in the
> trusted path.  To my understanding, PolicyKit does not address this
> issue today, perhaps because most Linux distros are not as strict about
> this requirement.  This technical issue could be overcome, for example,
> by switching to a separate VT in the trusted path to display the
> dialog.

Yes, it is entirely possible to easily make PolicyKit use an
Authentication Agent that runs outside the session. If you wanted you
could even make the authentication agent communicate with a separate
device (for example a separate device connected via USB with small
display / big flashy button the user can press to authenticate the
request) or a mobile phone display (using BT for proximity)... or
whatever... e.g. the APIs are in place for such things.

And, sure, for home/consumer usage just having both the screensaver
unlock dialog, the PolicyKit authentication dialogs and other stuff
(such as GMountOperation interaction [1]) running in a trusted sandbox
(e.g. separate Xserver/VT) is probably what we want. That way, nothing
running in the user session can ever snoop on passwords. Of course this
requires a lot of bug fixes in the X.org stack (it is essentially fast
user switching), we need a system compositor (like wayland), ConsoleKit
changes and so on... so blue sky for now.

Btw, I wonder how you implement screen locking (e.g. screen saver) /
connecting to network shares (e.g. gvfs) / ssh (via the terminal) if you
don't want people to enter passwords... seems like a weird backwards
requirement to only require it for gaining authorizations and not for
something like unlocking the screen.

[1] : See

http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00149.html
http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00169.html

> There has been some concern expressed about using PolicyKit with an RBAC
> backend.  If Solaris ships configuration files for both RBAC and
> PolicyKit, then users will likely need to understand and configure both
> systems to properly configure their setup.  There is a desire to avoid
> adding unnecessary complexity.  Perhaps a GUI that hides this complexity
> from the user could help to address this concern.

The only thing you need is to figure out whether an mechanism-defined
action (as defined in the .policy file shipping with the mechanism) is
allowed or not. So you would just have a small white-list for known
applications _if_ you don't want to trust the defaults provided by the
mechanism vendor.

I think the central problem here has to do with expectations and _who_
you are designing the OS for. Now, PolicyKit allows the mechanism vendor
to ship defaults - we need this because in modern desktop systems
intended for _consumers_ you (as the OS vendor) have zero control of
what is installed by default. Contrast this with the typical mind-set
where security/authorization framework designers happily assume they are
in full control of what is on the box and provide little or no way for
3rd party apps to participate. It just doesn't work in a modern desktop
operating system.


> Regarding RBAC, it has been a NIST standard since 1992.  Sun is just one
> company that implements RBAC, it is not a Sun technology.  

The NIST stuff, last time I checked, is more like a list of abstract
requirements that can apply to a ton of different systems (including
database systems where it is mostly used). Calling RBAC a standard is a
stretch, I mean, there's no well-defined API, file formats or anything. 

Again, PolicyKit is just an _interface_. You can implement almost any
kind of access control (both DAC and MAC) since PolicyKit provides a
wealth of information about what is going on and the actual decision
making happens in a separate trusted process.

The default authority implementation in PolicyKit (dubbed the Local
Authority) basically implements most of the useful bits of RBAC (as per
the NIST requirements). Other PolicyKit authority implementations may
implement other things; for example the Red Hat IPA team wants to
implement an authority that reads authorizations from a centralized
directory server.

   David


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

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

[Joe Marcus Clarke]

On Tue, 2009-07-28 at 22:03 +0100, Richard Hughes wrote:
> 2009/7/28 Joe Marcus Clarke :
> > We need DK first.  Unfortunately, DK doesn't seem to look very portable.
> >  Unlike hal which had directories for platforms backends, everything
> > seems to just be monolithic and udev-based.  I think it would be a bit
> > easier to get a FreeBSD port going if things looked and felt more modular.
> 
> No, DeviceKit-power doesn't depend on DeviceKit anymore. In fact,
> DeviceKit isn't required when you have a new enough udev.

Cool, good to know.  I will have a look at your work.

Joe

> 
> Richard.
> 
-- 
Joe Marcus Clarke
FreeBSD GNOME Team  ::  gn...@freebsd.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Richard Hughes]

2009/7/28 Joe Marcus Clarke :
> We need DK first.  Unfortunately, DK doesn't seem to look very portable.
>  Unlike hal which had directories for platforms backends, everything
> seems to just be monolithic and udev-based.  I think it would be a bit
> easier to get a FreeBSD port going if things looked and felt more modular.

No, DeviceKit-power doesn't depend on DeviceKit anymore. In fact,
DeviceKit isn't required when you have a new enough udev.

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

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

[Brian Cameron]

Colin:


Though, probably the main reason why there has not much of a drive to
add PolicyKit to Solaris is because there has not been much need.  To
date, Sun has not had much of a problem integrating the GNOME stack
without having PolicyKit available.  I am sure there are some features
that Solaris is lacking because of this, but I do not recall any bug
reports or user complaints about this.


I don't have a full feature list to hand, but some concrete examples
are things like:

* shutdown/reboot (the legacy code may still be there)


Yes, Solaris has a hack to workaround this.


* Changing the system time from the clock


We keep planning to hack the clock to launch Visual Panels for doing
this, but that will need to wait until Visual Panels actually fully
integrates.


* PackageKit updater


Solaris does not use PackageKit.


* Doing simple administrative process control in gnome-system-monitor


Not sure about our plans on this one, actually.


I think it makes sense for things like this to be in the default
desktop UI flow, and enabled by default by OS vendors for the
unmanaged case[1], the first three particularly without any
authorization required at all.  Here PolicyKit is just a fancy way for
us to work around the default Unix permissions model which was
designed for timesharing servers, while allowing administrators in the
managed case well-defined control.

This doesn't replace the need for tools targeted for admins, but I
think it is going to be a better experience than firing up Visual
Panels, system-config-date or whatever for the covered cases.


True, there are some features that Solaris lacks because PolicyKit is
not yet integrated.  The question really becomes when are the features
significant enough to warrant the work involved to integrate PolicyKit.

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

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

[Colin Walters]

On Tue, Jul 28, 2009 at 5:10 PM, Brian Cameron wrote:

> Though, probably the main reason why there has not much of a drive to
> add PolicyKit to Solaris is because there has not been much need.  To
> date, Sun has not had much of a problem integrating the GNOME stack
> without having PolicyKit available.  I am sure there are some features
> that Solaris is lacking because of this, but I do not recall any bug
> reports or user complaints about this.

I don't have a full feature list to hand, but some concrete examples
are things like:

* shutdown/reboot (the legacy code may still be there)
* Changing the system time from the clock
* PackageKit updater
* Doing simple administrative process control in gnome-system-monitor

I think it makes sense for things like this to be in the default
desktop UI flow, and enabled by default by OS vendors for the
unmanaged case[1], the first three particularly without any
authorization required at all.  Here PolicyKit is just a fancy way for
us to work around the default Unix permissions model which was
designed for timesharing servers, while allowing administrators in the
managed case well-defined control.

This doesn't replace the need for tools targeted for admins, but I
think it is going to be a better experience than firing up Visual
Panels, system-config-date or whatever for the covered cases.

[1] Where someone downloads a CD from a website on their own
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Joe Marcus Clarke]

Richard Hughes wrote:
> 2009/7/24 David Zeuthen :
>> 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.
> 
> In DeviceKit-power there is a not-just-gudev branch that separates the
> linux specific code from the generic daemon code. I doesn't yet
> compile (autotools help!), and is only lightly tested, but I'll
> probably merge to master after a few weeks testing.
> 
> It would be great if FreeBSD/Solaris developers could start hacking on
> this branch early, and tell me how hard porting would be. Thanks.

We need DK first.  Unfortunately, DK doesn't seem to look very portable.
 Unlike hal which had directories for platforms backends, everything
seems to just be monolithic and udev-based.  I think it would be a bit
easier to get a FreeBSD port going if things looked and felt more modular.

But thanks for doing this in DK-power.  I think with this kind of
modularity, it would be easier to add more platform-specific pieces to
various components.

Joe

-- 
Joe Marcus Clarke
FreeBSD GNOME Team  ::  gn...@freebsd.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Brian Cameron]

David:


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.


I have pinged the Sun team working on DeviceKit and suggested they
be better about communication with upstream by sending some status
to the devkit-devel mailing list.


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.


Myself and Jim Li were the two Sun engineers working to make sure that
PolicyKit works on Solaris.  Much of this work was done in late 2007 and
early 2008.  At that time, there was not an urgent need for integrating
PolicyKit into Solaris, but we wanted to make sure that we were keeping
abreast with the new technologies that were going to have a lot of
impact on the desktop.  We wanted to make sure we were more familiar
with the codebase and start getting fixes for Solaris-specific issues
upstream.  We provided spec-files in the Solaris spec-files-extra
repository so that others in the OpenSolaris community could get
involved with building it if they wanted to further test it out.
If we gave the impression that we were being more aggressive about
integrating PolicyKit, that was not intended.

I can not speak for Sun in general on this matter, but my understanding
is that Sun does not have any problems with integrating a module like
PolicyKit.  In fact, Solaris does already ship a stripped-down version
of PolicyKit that is only used by HAL.  If you look at a recent
OpenSolaris release, you will see libpolkit.so in /usr/lib.  However,
this is a hacked PolicyKit that just works as needed for HAL alone, and
does not provide any configuration for the user to change.  Instead it
works with a RBAC backend.

Since PolicyKit relates so much to security, going through the processes
of review and auditing needed to integrate a more complete PolicyKit
will be cumbersome, though not impossible.  The security team at Sun has
expressed some concerns about the maturity of PolicyKit, since it is
such a new framework.  If some of these concerns were communicated in
childish ways in private emails, then I apologize.

Also, Solaris has a security rule that requires that users not be asked
to enter passwords for gaining authorization unless they are in the
trusted path.  To my understanding, PolicyKit does not address this
issue today, perhaps because most Linux distros are not as strict about
this requirement.  This technical issue could be overcome, for example,
by switching to a separate VT in the trusted path to display the
dialog.

There has been some concern expressed about using PolicyKit with an RBAC
backend.  If Solaris ships configuration files for both RBAC and
PolicyKit, then users will likely need to understand and configure both
systems to properly configure their setup.  There is a desire to avoid
adding unnecessary complexity.  Perhaps a GUI that hides this complexity
from the user could help to address this concern.

Though, probably the main reason why there has not much of a drive to
add PolicyKit to Solaris is because there has not been much need.  To
date, Sun has not had much of a problem integrating the GNOME stack
without having PolicyKit available.  I am sure there are some features
that Solaris is lacking because of this, but I do not recall any bug
reports or user complaints about this.  The lack of specific
need-to-have features that would be solved by adding PolicyKit makes
it easier to not integrate PolicyKit than to address all of the above
issues and concerns.


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.


This does improve things a lot.  As I mention above, HAL already uses
an old version of libpolkit with a hacked RBAC backend.  At the very
least, it seems it would make sense to update to the new version of
PolicyKit to take advantage of the new, more flexible framework for
RBAC integratin.  That is probably the practical next step towards
better integrating PolicyKit into Solaris.


I am not sure what the big deal is here.  N

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

[Calum Benson]

On 24 Jul 2009, at 19:13, Karl Lattimer wrote:


I think we could really benefit from a ux.gnome.org site for

demonstrating new ideas and creating concrete mockups and cataloging
testing data from various organisations who are performing usability
testing or have in the past.


Probably a bit OT here -- at the risk of causing myself some list  
moderation work, setting followups to usabil...@gnome.org :)


FWIW, we do already have , which used to  
redirect to d.g.o/projects/usability, but now redirects to l.g.o/ 
UsabilityProject.


Do we need a separate site outside of l.g.o for what you propose?  Do  
we need to add ux.gnome.org as an alias for usability.gnome.org?  I  
don't know... maybe.  The text-heavy UsabilityProject area could  
certainly do with a more attractive homepage, at least -- I basically  
just shovelled everything over verbatim from the old d.g.o usability  
site as quickly as possible when d.g.o was being deprecated, and  
haven't really had time to do a great deal of remodelling since.



We could even possibly get people grazing through and helping out,
especially people like the gnome-look community which is thriving and
still producing content on their brainstorm pages...
http://gnome-look.org/index.php?xcontentmode=185


Our current equivalent, I guess, is .  It's probably true that we haven't evangelised that enough, and  
of course some of the larger GNOME projects have their own design  
areas on l.g.o so don't use the usability Whiteboard area anyway.


Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer   Sun Microsystems Ireland
mailto:calum.ben...@sun.comOpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

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

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

[Jedy Wang]

Hi Richard,

This is really a good news. I juts tested the build on Solaris and
succeeded after commenting out all code related to Policykit (because
Solaris does not ship Policykit currently). I also CCed the engineer who
is responsible for the porting of Devicekit-power to Solaris.

Regards,

Jedy

On Tue, 2009-07-28 at 08:51 +0100, Richard Hughes wrote:
> 2009/7/24 David Zeuthen :
> > 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.
> 
> In DeviceKit-power there is a not-just-gudev branch that separates the
> linux specific code from the generic daemon code. I doesn't yet
> compile (autotools help!), and is only lightly tested, but I'll
> probably merge to master after a few weeks testing.
> 
> It would be great if FreeBSD/Solaris developers could start hacking on
> this branch early, and tell me how hard porting would be. Thanks.
> 
> Richard.
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list


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

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

[Richard Hughes]

2009/7/24 David Zeuthen :
> 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.

In DeviceKit-power there is a not-just-gudev branch that separates the
linux specific code from the generic daemon code. I doesn't yet
compile (autotools help!), and is only lightly tested, but I'll
probably merge to master after a few weeks testing.

It would be great if FreeBSD/Solaris developers could start hacking on
this branch early, and tell me how hard porting would be. Thanks.

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

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

[Calum Benson]

On 24 Jul 2009, at 18:29, Jason D. Clinton wrote:


Has there been any movement with regard to the mouse-over pop-up menu
criticism that I pointed out--that it breaks the metaphor and  
there's no
precedent for it? There wasn't any response on the blog post[1] from  
the
parties involved with creating the mock-up. Another criticism--not  
mine--was
the 90 degree rotated text for category naming. I didn't see a  
response to

that either. Communication needs to be two-way.


Yep, I asked the designers last week if they'd follow up in the  
comments thread, and they said they would, but so far they haven't.   
I'll ping them again.


Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer   Sun Microsystems Ireland
mailto:calum.ben...@sun.comOpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

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

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

[Andre Klapper]

Am Donnerstag, den 23.07.2009, 10:43 +0100 schrieb Christian Fredrik
Kalager Schaller:
> My hope is that someone like the release team would issue a statement
> with what our guidelines are currently

After the discussion here I don't see a need for this. Anyway, to
summarize what I've read:

GNOME is a desktop system for Unix-like systems. Some {developers,
companies} write code for {Linux, *BSD, Solaris, $whatever} systems but
APIs always offer implementing $functionality for {Linux, *BSD, Solaris,
$whatever} and {developers, companies} are more than welcome to
contribute code implementations for their specific systems.

andre
-- 
 mailto:ak...@gmx.net | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

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

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

[Glynn Foster]

On 22/07/2009, at 3:54 PM, Calum Benson wrote:



On 22 Jul 2009, at 20:06, Jason D. Clinton wrote:

Obviously the alleged pointlessness of something that we are  
arguing about
is relevant. Whether or not there are--you know--actual people  
using said OS
is what this is really about. And apparently even Sun doesn't think  
so since
they no longer invest the same level of resources in it that they  
once did.


FWIW, in relative terms the number of people working on the GNOME  
desktop at Sun compared to say, 5 years ago has probably increased,  
but I'm aware that this isn't necessarily the general community  
perception.


Maybe we just need to rescue Gman from his current marketing role  
and give him back a proper job :)


Harsh! :)

(but thanks all for providing the amusement to waste away a couple of  
hours at SFO)



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

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

[Jason D. Clinton]

On Fri, Jul 24, 2009 at 12:52 PM, William Jon McCann <
william.jon.mcc...@gmail.com> wrote:

> Hey Jason,
>
> On Fri, Jul 24, 2009 at 1:29 PM, Jason D. Clinton
> wrote:
> > On Fri, Jul 24, 2009 at 11:16 AM, Calum Benson 
> wrote:
> >>
> >> So if it turns out that the GNOME community like the general direction
> >> we've suggested for the control center, then sure, I'd certainly like to
> see
> >> us widen out the discussion to visual panels as well.
> >
> > Has there been any movement with regard to the mouse-over pop-up menu
> > criticism that I pointed out--that it breaks the metaphor and there's no
> > precedent for it? There wasn't any response on the blog post[1] from the
> > parties involved with creating the mock-up. Another criticism--not
> mine--was
> > the 90 degree rotated text for category naming. I didn't see a response
> to
> > that either. Communication needs to be two-way.
> >
> > [1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/
>
> This is pretty far off topic.  I think discussing a control center
> design is really important.  But it should probably happen here:
> http://mail.gnome.org/archives/gnomecc-list/2009-July/msg7.html


I am not on gnome-cc and have no desire to be. I didn't bring this topic up
and I think it's entirely relevant since Sun is essentially saying here that
they are offering up some two-way cooperation--the topic of the thread.
Those criticisms need to be addressed--even if it's just saying there's a
good counterargument that will be coming at some later point--if they aren't
going to replied to in the location in which critiques were solicited.

On another note, there are now just as many emails in my GMail view of this
conversation about the thread as there are of the thread itself (many of
them are off-list seething hate mail from current and former Sun and Red Hat
employees). By my count, there would be a 36% less noise in this thread if
people would stop appointing themselves d-d-l police. Incidentally, this is
the same reason that #gnome-hackers is now practically dead--everyone is so
afraid of offending un-written, ambiguous rules of content on #gnome-hackers
(apparently enforced at a whim vis-a-vis the ban of Rupert) that no one
talks at all.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Karl Lattimer]

> [1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/

wow I can't believe I missed this, and didn't read the accompanying wiki
page http://live.gnome.org/UsabilityProject/Whiteboard/ControlCenter

I'm such a bad citizen at times :( 

Thanks for pointing to this work, seems Sun have put quite an effort
behind testing, generating prototypes and alike. It's nice to see
someone's doing this, hiding away in the wiki is bad though :( 

I think we could really benefit from a ux.gnome.org site for
demonstrating new ideas and creating concrete mockups and cataloging
testing data from various organisations who are performing usability
testing or have in the past.

We could even possibly get people grazing through and helping out,
especially people like the gnome-look community which is thriving and
still producing content on their brainstorm pages...
http://gnome-look.org/index.php?xcontentmode=185

Handing all of this untamed talent, mentoring and directing them within
a structured framework could help build a thriving user experience
community. 

Imagine for a moment the litestep and afterstep desktops, people
configured them to crazy extents making whole new user experiences
within nothing but a few hours of dedicated concentration of how they
want things to be. 

Now take a look at GNOME shell, we've basically got something 1,000,000
times more powerful than litestep for hackability, this is next to a
community of willing and dedicated people... 

The thing that gets me is, they don't currently seem to be connected.
Personally I think that ux.gnome.org is the way to go. If we can create
a framework for distilling the good ideas down from multiple sources,
then I believe our user experience will become second to none. 

Any thoughts, flames, rants? 

BR,
 K


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[William Jon McCann]

Hey Jason,

On Fri, Jul 24, 2009 at 1:29 PM, Jason D. Clinton wrote:
> On Fri, Jul 24, 2009 at 11:16 AM, Calum Benson  wrote:
>>
>> So if it turns out that the GNOME community like the general direction
>> we've suggested for the control center, then sure, I'd certainly like to see
>> us widen out the discussion to visual panels as well.
>
> Has there been any movement with regard to the mouse-over pop-up menu
> criticism that I pointed out--that it breaks the metaphor and there's no
> precedent for it? There wasn't any response on the blog post[1] from the
> parties involved with creating the mock-up. Another criticism--not mine--was
> the 90 degree rotated text for category naming. I didn't see a response to
> that either. Communication needs to be two-way.
>
> [1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/

This is pretty far off topic.  I think discussing a control center
design is really important.  But it should probably happen here:
http://mail.gnome.org/archives/gnomecc-list/2009-July/msg7.html

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

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

[Jason D. Clinton]

On Fri, Jul 24, 2009 at 11:16 AM, Calum Benson  wrote:

> So if it turns out that the GNOME community like the general direction
> we've suggested for the control center, then sure, I'd certainly like to see
> us widen out the discussion to visual panels as well.


Has there been any movement with regard to the mouse-over pop-up menu
criticism that I pointed out--that it breaks the metaphor and there's no
precedent for it? There wasn't any response on the blog post[1] from the
parties involved with creating the mock-up. Another criticism--not mine--was
the 90 degree rotated text for category naming. I didn't see a response to
that either. Communication needs to be two-way.

[1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Calum Benson]

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?


I can't speak for RBAC, but re Visual Panels, the control center ideas  
that Sun has been publicly kicking around since GUADEC are actually  
intended a first step along the way towards a migration to Visual  
Panels over time, for OpenSolaris at least.


Whether or not anyone outside of Sun has any interest in VP isn't  
really something we've tested the waters with yet, partly because it  
was initially intended as a project to provide GUI configuration for  
Solaris SMF services (I think the scope has widened a bit since then,  
though), and partly because Visual Panels themselves have mostly been  
written in Java up to now.


Neither of those make it an immediately-obvious candidate for  
widespread adoption, but I'm sure they're not insurmountable either.   
So if it turns out that the GNOME community like the general direction  
we've suggested for the control center, then sure, I'd certainly like  
to see us widen out the discussion to visual panels as well.


Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer   Sun Microsystems Ireland
mailto:calum.ben...@sun.comOpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

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

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

[David Zeuthen]

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

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

[Tristan Van Berkom]

Morning folks ;-)

On Thu, Jul 23, 2009 at 7:08 AM, Andre Klapper wrote:
> Am Mittwoch, den 22.07.2009, 14:21 -0400 schrieb Tristan Van Berkom:
>> 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 ?
>
> bugzilla.gnome.org provides a "portability" keyword and you can set the
> severity of a bug. I don't think that a wikipage is needed.
> If people use these bugzilla options is another question though...

Maybe a query into the GNOME bugzilla database will give
me the impression that GNOME is taking care of my issues
on my system "foo", Maybe the same bugzilla query could be
useful to me as a developer`s roadmap to addressing problems
on system "foo", but I doubt it.

On the other hand people do file these bugs, so there is
evidence that people do care about the bugs - and somebody
might even be interested in volunteering to track them; so
that we could have a report of the status of the platform on a
given system, it might even be useful for us maintainers to
have a clearer picture of what is going on with our code when
distributed in the real world.

Usually in the past Ive had time to go over the buglist before
release time and nail all the blockers I can, this hasnt been the
case this year, and really as far as I am concerned as a maintainer,
its really pretty and nice to set patch status and stuff like that,
but a bug is unconfirmed until its resolved - thats the summit
of interaction with bugzilla I can realistically afford.

Cheers,
 -Tristan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Jason D. Clinton]

On Thu, Jul 23, 2009 at 2:36 AM, Matej Cepl  wrote:

> I think the pointlessness (isn't it a beautiful word? :)) of flaming Sun
> is that the argument was not just about Solaris. Platform independence is
> a good thing for other platforms (*BSD/Mac?/Windows?) in itself.


I agree with you with one small distinction: OpenSolaris and *BSD need a
whole other level of platform independence that OSX and Win32 do not. One
doesn't need a panel/shell/nautilus on OSX and Win32 (from here on in,
application target platforms). Our application target platforms don't need
DeviceKit, PulseAudio or a sound mixer applet with a abstracted mixer
backend. They don't need gnome-settings-daemon running to handle triggering
screen saver or DPMS events. Or to toggle backlights with a
gnome-power-manager. We cover 99.9% of computer users' platforms on the face
of the earth by expending our limited resources on Linux, OSX and Win32 (and
increasingly mobile Linux via G* stack). And we don't sacrifice our free
software principals in the process.

In the (unimportant) module that I maintain, for example, there are #ifdef's
all over the code for Win32 support and I'm happy to accept patches for it.
However, we are in the process of pursuing the re-thinking of some core cool
features and other platforms have likely suffered as a result. There would
be no Clutter port of five games in the module if we had pursued the
strategy of installing seven VM's and testing all our changes on all of
them. It would be years yet, before they were available. No GSoC student
would have the time to do the seven VM's strategy and still achieve their
summer coding goals. There would be no telepathy tubes multiplayer support
on the way. We just don't have those kinds of resources.

David Zeuthen's eloquent explanation of the "don't preclude portability but
leave the back-end work up to those who want it" philosophy is spot-on. On
the other hand, two free software platforms do need this major extra effort
on the part of everyone who maintains a GNOME module: OpenSolaris and *BSD
(here on in, desktop target platforms). These platforms want all of the
things mentioned above. Unfortunately, from the perspective of hands to do
the actual work, the fact of the mater is that neither of the two platforms
have a lot of users.

On the *BSD side of things, the desktop-related driver situation is
lamentable. However, *BSD has a huge thing going for it: vast parts of the
user space are nearly identical to Linux. So with exception given to the
absence of udev, it really isn't all that different. Indeed, there is even a
semi-official *BSD kernel for Debian.

OpenSolaris, however, suffers from a legacy of esoterically cathedral-like
design on some fundamental sub-systems. The work to make all the things
mentioned above work is so, so much more than any other platform for GNOME.

I'm fairly confident in saying that Win32--if it isn't already working in
2.27.x--would be a trivial amount of additional effort for GNOME Games. And
while OSX still looks quite ugly and *BSD lacks good 3D drivers, they too
would continue to be a somewhat minimal amount of effort. As for
OpenSolaris, who knows. I have examined the packaging of GNOME Games in
OpenSolaris in the past and was not encouraged by what I saw.

And I don't even maintain a module that really cares all that much about the
underlying plumbing.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Andre Klapper]

Am Mittwoch, den 22.07.2009, 14:21 -0400 schrieb Tristan Van Berkom:
> 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 ?

bugzilla.gnome.org provides a "portability" keyword and you can set the
severity of a bug. I don't think that a wikipage is needed.
If people use these bugzilla options is another question though...

andre
-- 
 mailto:ak...@gmx.net | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

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

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

[Brian Cameron]

Jason:

Obviously the alleged pointlessness of something that we are arguing 
about is relevant. Whether or not there are--you know--actual people 
using said OS is what this is really about. And apparently even Sun 
doesn't think so since they no longer invest the same level of resources 
in it that they once did. I'm calling a duck a duck here. It's a failure 
and even Sun knows that it is. There's no reason we shouldn't be 
scrambling a few eggs on Solaris to advance the Linux desktop experience.


I didn't realize that Sun was the only company involved with GNOME that
has had resources negatively impacted by this long-standing downturn in
the economy.

Even though, it is true, Sun does have fewer resources working on GNOME
than we did several years ago, there are still several dozen engineers
at Sun working on GNOME and GNOME-related technologies.  Recently Sun
has been focusing a lot of time and energy into making a new accessible
installer, the Time Slider GNOME ZFS integration application, adding
better wireless and printing support, improving the multimedia
experience, and lots of other things.  The latest releases of
OpenSolaris have been well received, I think because we are doing a good
bit of work making GNOME available on Solaris.

  http://blogs.zdnet.com/perlow/?p=10250

Sun is already working to add DeviceKit support to Solaris, GNOME
runs fine on Solaris without PulseAudio.  Sun does not have much of
an interest in shipping modules which have a strong dependency on
PolicyKit (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.

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.

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

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

[Christian Fredrik Kalager Schaller]

Hi,

> 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).

Funny you should mention this cause the GStreamer team had some
discussions with Alexander Larsson among others about having glib
support for device detection. I guess the conclusion is that also the
GStreamer devs agree a cross platform device detection setup would be
nice, but I guess there is still some disagreement on where it
belongs :)

Anyway, I like your suggestion for the 3 tiered stack as it should give
everyone involved a clear idea about what the GNOME community will
undertake to ensure works across all platforms and what the OS
communities themselves need to take care of.

My hope is that someone like the release team would issue a statement
with what our guidelines are currently, in relation to these issues, as
I feel we are in a very freewheeling stage now where the boundaries for
when platform specific stuff is a feature and when its a bug is
constantly changing. Adopting something along the lines of your proposal
would help clarify the situation and people working on Solaris and
FreeBSD for instance would at least have something clear to work from.

Christian

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

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

[Matej Cepl]

Jason D. Clinton, Wed, 22 Jul 2009 14:06:36 -0500:
> Obviously the alleged pointlessness of something that we are arguing
> about is relevant.

I think the pointlessness (isn't it a beautiful word? :)) of flaming Sun 
is that the argument was not just about Solaris. Platform independence is 
a good thing for other platforms (*BSD/Mac?/Windows?) in itself.

Matěj

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

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

[Nirbheek Chauhan]

On Thu, Jul 23, 2009 at 12:10 AM, Jason D. Clinton wrote:
> 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?
>

a) Flamebait
b) Pointless since (Open)Solaris isn't the only non-linux platform.
*BSD are another large group.

Please, let's stay on-topic.

-- 
~Nirbheek Chauhan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[David Zeuthen]

On Wed, 2009-07-22 at 23:29 +0100, Bastien Nocera wrote:
> 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.

Yeah. But right now it is Linux only und so weiter... If someone ports
Bluez to other platforms, or reimplements, then, hey, great, they can
take advantage of all the cool Bluez integration you have written. That
alone should be reason enough for them to do it. But things like this
just don't happen over night. It took 2+ years for a Solaris backend for
HAL to surface and another year or so for the FreeBSD backend.

My main point really is that we need to stop thinking of GNOME as a
whole desktop environment that will run everywhere and solve every
problem known to man. We need to stop bickering about really OS-specific
things such as volume controls. We need to make a distinction between
applications (the thing people actually use) and OS-specific conduits
(audio volume control, formatting a disk).

We need to focus hard on providing a set of rich, but lean and tightly
controlled (e.g. solid maintainers needed), introspectable libraries so
people can write useful _applications_ in their favorite language. And,
ideally, for any target. And, more ideally, so apps are relocatable (cf.
the recent thread on gtk-devel-list).

Further, we need to design these APIs so they are extendable. We want to
provide baseline functionality for the X11/target (GUnixVolumeMonitor)
while at the same time take advantage of the latest and greatest
OS-specific software (DeviceKit-disks monitor).

(And, for those of you still reading, GIO/GVfs is an _excellent_ example
of how to do this. Alex really got this right.)

That set of APIs will provide a good foundation so people can innovate
in areas like GNOME Shell, Sugar, whatever without having to worry about
a lot of things.

(Of course we still need to care about system integration, e.g. the
whole DeviceKit-{disks,power}, PackageKit, Pulseaudio, Bluez story. But
it really shouldn't be anything that affects the G stack except that it
might optionally use parts of it in certain place. And we might use it
in apps that are not pure G apps - e.g. Bluez desktop integration,
Volume Control, Palimpsest and so on.)

 David


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

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

[Calum Benson]

On 22 Jul 2009, at 20:06, Jason D. Clinton wrote:

Obviously the alleged pointlessness of something that we are arguing  
about
is relevant. Whether or not there are--you know--actual people using  
said OS
is what this is really about. And apparently even Sun doesn't think  
so since
they no longer invest the same level of resources in it that they  
once did.


FWIW, in relative terms the number of people working on the GNOME  
desktop at Sun compared to say, 5 years ago has probably increased,  
but I'm aware that this isn't necessarily the general community  
perception.


Maybe we just need to rescue Gman from his current marketing role and  
give him back a proper job :)


Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer   Sun Microsystems Ireland
mailto:calum.ben...@sun.comOpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

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

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

[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. 



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

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

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

[Colin Walters]

On Wed, Jul 22, 2009 at 6:17 PM, David Zeuthen wrote:
>
>> 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.

I think that's what the people involved in this thread want basically
is just some guidance, i.e. a yes or no here.

> [lots of case by case examples]

I agree with this.

> 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.

I agree here too, just with the caveat that it is probably a good idea
if we accept it as a bug if the desktop core (i.e.
gnome-session+beyond) totally falls apart if you don't have one of the
DeviceKit-* running.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[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.





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.ben...@sun.comOpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

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

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

[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?


Everyone: Please refrain from posting to any replies to this email or
anything which followed up on this email. Thanks.


-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[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.

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

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

[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 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


___
desktop-devel-list mailing list
desktop-devel-lis

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

[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.ben...@sun.comOpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

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

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

[Shaun McCance]

On Wed, 2009-07-22 at 17:07 -0400, David Zeuthen wrote:
>  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

http://library.gnome.org/devel/platform-overview/stable/

We have the document.  But it's getting old, and I'm having
trouble updating it because I can't ascertain what our core
platform is.  GLib, GTK+, and GStreamer sounds really nice
and clean, but looking at what people are actually using,
and at some of the hot stuff that's happening, I don't think
that's ever going to cut it.

I send an email to d-d-l in May asking for feedback from the
community on exactly this:

http://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00056.html

There was a small but healthy thread, and I got the impression
that perfect consensus would be difficult to reach.

--
Shaun


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

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

[Colin Walters]

On Wed, Jul 22, 2009 at 5:07 PM, David Zeuthen 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.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Karl Lattimer]

On Wed, 2009-07-22 at 16:08 -0500, Jason D. Clinton wrote:
> On Wed, Jul 22, 2009 at 3:55 PM, Karl Lattimer 
> wrote:
> That's not arrogant, arrogant would be someone making a
> sweeping
> statement like nobody uses solaris so lets just not care about
> it, when
> no evidence is provided to back that up.
> 
> Are you really going to make the argument that Solaris does have a
> non-trivial desktop install user base? What exactly are you getting
> at? Or you decided you'd like to add flames?
> 
> If I'm going to give you the benefit of the doubt that you are not
> giving me (I know quite a lot about Sun, by the way), then my
> suggestion to you--if you are serious about pursuing this line of
> reasoning--would be to Google some Solaris browser statistics.

Giving >ME< the benefit of the doubt? I just stepped in to correct the
insult you threw at Alberto. 

I'm not arguing one way or the other, but you clearly are. Being
argumentative that is... 

BR,
 K


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[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 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

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

[Jason D. Clinton]

On Wed, Jul 22, 2009 at 3:55 PM, Karl Lattimer  wrote:

> That's not arrogant, arrogant would be someone making a sweeping
> statement like nobody uses solaris so lets just not care about it, when
> no evidence is provided to back that up.


Are you really going to make the argument that Solaris does have a
non-trivial desktop install user base? What exactly are you getting at? Or
you decided you'd like to add flames?

If I'm going to give you the benefit of the doubt that you are not giving me
(I know quite a lot about Sun, by the way), then my suggestion to you--if
you are serious about pursuing this line of reasoning--would be to Google
some Solaris browser statistics.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Karl Lattimer]

On Wed, 2009-07-22 at 15:47 -0500, Jason D. Clinton wrote:
> On Wed, Jul 22, 2009 at 3:29 PM, Alberto Ruiz  wrote:
> +1 for Lennart here, 
> 
> What exactly does *your* email add to this discussion?
> 
>  
> you don't even know what you are talking about
> 
> That's a terribly arrogant statement.
> 

I wouldn't say it's terribly arrogant as Alberto used to work for Sun,
I'd say he's probably privy to more information than you and is calling
you out on it.

That's not arrogant, arrogant would be someone making a sweeping
statement like nobody uses solaris so lets just not care about it, when
no evidence is provided to back that up. 

BR,
 K


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Jason D. Clinton]

On Wed, Jul 22, 2009 at 3:29 PM, Alberto Ruiz  wrote:

> +1 for Lennart here,


What exactly does *your* email add to this discussion?



> you don't even know what you are talking about


That's a terribly arrogant statement.



> and the comment is not helping to solve any problem.


What's the problem again? There isn't one. That's the point.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Alberto Ruiz]

2009/7/22 Lennart Poettering :
> On Wed, 22.07.09 13:40, Jason D. Clinton (m...@jasonclinton.com) wrote:
>
>> > 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.
>
> Please don't turn this in pointless and off-topic flamewar about the
> point or pointlessness of Solaris.

+1 for Lennart here, you don't even know what you are talking about
and the comment is not helping to solve any problem.

> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>



-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Matteo Settenvini]

Really, please don't turn this thread to an aggressive flamewar. Sun's
entitled to what they want with their time and money; if they think
OpenSolaris is the way to go, they're free to pursue it, and personally
I wish them good luck. Even if I'm not an OpenSolaris user, I think that
biodiversity in software is a good thing, and contamination across
different platforms can bring us nice ideas as well as we can provide
nice ideas to others.

They've contributed much in the years, and telling them that what they
pursue is a "dead end" is not... well... nice.

Please don't let things slip.
Matteo


On mer, 2009-07-22 at 14:06 -0500, Jason D. Clinton wrote:
> On Wed, Jul 22, 2009 at 1:45 PM, Lennart Poettering
>  wrote:
> 
> 
> Please don't turn this in pointless and off-topic flamewar
> about the
> point or pointlessness of Solaris.
> 
> Obviously the alleged pointlessness of something that we are arguing
> about is relevant. Whether or not there are--you know--actual people
> using said OS is what this is really about. And apparently even Sun
> doesn't think so since they no longer invest the same level of
> resources in it that they once did. I'm calling a duck a duck here.
> It's a failure and even Sun knows that it is. There's no reason we
> shouldn't be scrambling a few eggs on Solaris to advance the Linux
> desktop experience.
> 
> I know you're a veteran of the flame-war (goodness knows you've gotten
> a lot of practice in the past two years) but don't immediately try to
> shoot me down with accusations of triviality. Back off.




signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Dan Winship]

On 07/22/2009 02:21 PM, Tristan Van Berkom wrote:
> On Wed, Jul 22, 2009 at 7:50 AM, 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.
> 
> 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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Colin Walters]

On Wed, Jul 22, 2009 at 3:10 PM, Colin 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.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Colin Walters]

On Wed, Jul 22, 2009 at 10:31 AM, 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.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Jason D. Clinton]

On Wed, Jul 22, 2009 at 1:45 PM, Lennart Poettering wrote:

>
> Please don't turn this in pointless and off-topic flamewar about the
> point or pointlessness of Solaris.


Obviously the alleged pointlessness of something that we are arguing about
is relevant. Whether or not there are--you know--actual people using said OS
is what this is really about. And apparently even Sun doesn't think so since
they no longer invest the same level of resources in it that they once did.
I'm calling a duck a duck here. It's a failure and even Sun knows that it
is. There's no reason we shouldn't be scrambling a few eggs on Solaris to
advance the Linux desktop experience.

I know you're a veteran of the flame-war (goodness knows you've gotten a lot
of practice in the past two years) but don't immediately try to shoot me
down with accusations of triviality. Back off.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Lennart Poettering]

On Wed, 22.07.09 13:40, Jason D. Clinton (m...@jasonclinton.com) wrote:

> > 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.

Please don't turn this in pointless and off-topic flamewar about the
point or pointlessness of Solaris.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Jason D. Clinton]

On Wed, Jul 22, 2009 at 10:27 AM, 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.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[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


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

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

[Tristan Van Berkom]

On Wed, Jul 22, 2009 at 7:50 AM, 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.

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

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

[Matthias Clasen]

On Wed, Jul 22, 2009 at 7:50 AM, 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.
>

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

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

[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.ben...@sun.comOpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

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

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

[Johannes Schmid]

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


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Paul Cutler]

>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  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.ben...@sun.comOpenSolaris Desktop Team
> http://blogs.sun.com/calum +353 1 819 9771
>
> Any opinions are personal and not necessarily those of Sun Microsystems
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[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.ben...@sun.comOpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

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

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

[Vincent Untz]

Le mercredi 22 juillet 2009, à 15:47 +0200, Vincent Untz a écrit :
> AFAIK, we only depend on stuff where it's possible to have a backend on
> non-linux platforms. As Lennart mentioned, it's the case with PA. As
> Andre explains, it's also the case for DK. Are there cases where this is
> not true?

Ah, there might be NM, since it switched to gudev, I believe. I don't
know the details, though, so I don't know if there's a plan there for
non-Linux platforms.

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Vincent Untz]

Le mercredi 22 juillet 2009, à 14:16 +0200, Andre Klapper a écrit :
> Hi,
> 
> Am Mittwoch, den 22.07.2009, 12:50 +0100 schrieb Christian Fredrik
> Kalager Schaller:
> > 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
> 
> "The (D-Bus) interface of the subsystem daemons, that is
> DeviceKit-disks, DeviceKit-power, is not in any way Linux specific. We
> will take patches for other operating systems."[1]

AFAIK, we only depend on stuff where it's possible to have a backend on
non-linux platforms. As Lennart mentioned, it's the case with PA. As
Andre explains, it's also the case for DK. Are there cases where this is
not true?

Also, if I remember correctly, in the early hal days, there was only a
linux backend and people had to step up to provide other backends --
it's a similar situation today (I can understand it's probably annoying
for the people who have to write those backends, btw)

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Andre Klapper]

Hi,

Am Mittwoch, den 22.07.2009, 12:50 +0100 schrieb Christian Fredrik
Kalager Schaller:
> 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

"The (D-Bus) interface of the subsystem daemons, that is
DeviceKit-disks, DeviceKit-power, is not in any way Linux specific. We
will take patches for other operating systems."[1]

So have GNOME distributors of non-linux platforms tried to provide
patches, or is this approach seen as a problem (if so, why)?

Just asking,
andre

[1] http://lists.freedesktop.org/archives/devkit-devel/2009-April/000144.html
-- 
 mailto:ak...@gmx.net | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

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

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

[Lennart Poettering]

On Wed, 22.07.09 12:50, Christian Fredrik Kalager Schaller (ura...@gnome.org) 
wrote:

> 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.

That's not really true. PA has an OSS and a SunAudio backend. It has
also been ported to other systems, including Windows (though that one
isn't up-to-date in the lastest PA versions), and even exotic stuff
like Hurd.

For PA my policy is generally to say that I am happy to merge clean
portability patches, but I don't consider non-Linux systems
release-critical in any way, i.e. I won't delay a release for making
sure PA works on non-Linux systems, and I am happy to break non-Linux
support in the process of adding a new feature somewhere, leaving it
for the folks interested in the other operating systems to fix it
again. Also, I make clear that I write my software focussed on Linux,
and not on any other OS. It might be a good idea to adopt a similar
practice in GNOME, too.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Christian Fredrik Kalager Schaller]

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

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