Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Put their upstream contributions in perspective with their downstream work..and it matters. Canonical is doing the work..they just aren't collaborating very effectively.
Neary: GNOME Census
Posted Jul 28, 2010 18:07 UTC (Wed) by evad (subscriber, #60553)
Posted Jul 28, 2010 18:23 UTC (Wed) by jspaleta (subscriber, #50639)
I would also call Shuttleworth's attempt to paint Gnome-shell as not a netbook appropriate user interface to prop up Canonical's choice to work on Unity outside of the GNOME project as actively hostile to GNOME as a project and its roadmap. I've yet to see an active GNOME contributor or a GNOME Foundation board member state that GNOME Shell is not meant nor recommended for netbooks. Shuttleworth is actively undermining the general perception of GNOME Shell's utility to get people interested in Unity. Not the most friendly of actions...and absolutely misleading...deliberately so.
Posted Jul 28, 2010 20:39 UTC (Wed) by gowen (guest, #23914)
Posted Jul 28, 2010 20:41 UTC (Wed) by jspaleta (subscriber, #50639)
Posted Jul 29, 2010 11:17 UTC (Thu) by cortana (subscriber, #24596)
Posted Jul 29, 2010 18:50 UTC (Thu) by foom (subscriber, #14868)
Posted Jul 29, 2010 19:00 UTC (Thu) by jspaleta (subscriber, #50639)
Posted Aug 1, 2010 22:16 UTC (Sun) by drago01 (subscriber, #50715)
We don't require a "high end" NVIDIA or AMD/ATI card with 1TFlop+ of computing power.
If it does not work on your netbook it is either
1) A driver issue / bug
2) A bug in clutter/mutter/gnome-shell which we indeed do _want_ to fix.
So "it does not work on low end hardware and they won't fix it" is just wrong.
Posted Aug 2, 2010 0:14 UTC (Mon) by foom (subscriber, #14868)
Sure, it's there...but in many cases it's unusable with Linux, because there's no working driver. Sure that's a "driver issue", but it's still a problem. It doesn't look to me like it'll be feasible to depend on hardware 3D working on all linux desktops anytime soon.
Of course, so long as clutter/mutter/gnome-shell works at a reasonable speed with software-only unaccelerated 3D, that's great too...
Posted Aug 3, 2010 16:18 UTC (Tue) by drago01 (subscriber, #50715)
Not sure about the "many cases" (cn), but you can't solve problems by running away from them anyway, the solution is to _fix_ 3D, it is not a hardware issue we just need proper drivers.
If nobody uses 3D because it "doesn't work", no one will fix it because "no one uses it".
We can no longer consider 3D as a "nice to have" feature given recent and future hardware developments; we have to take advantage of the hardware we have.
Posted Aug 4, 2010 17:32 UTC (Wed) by nwnk (subscriber, #52271)
Posted Jul 28, 2010 20:52 UTC (Wed) by AlexHudson (subscriber, #41828)
To be honest, it's kinda time to get over it. I don't know how much code they write as an organisation for internal and external consumption, but I'd be staggered if the vast majority of it isn't proprietary. And in a way, who cares? People clamoured for them to open up Launchpad, and how many public instances are there of that around? (only the other week I'm sure mdz was saying virtually all free software was packaged in debian/ubuntu, can you "apt-get install launchpad" yet?) I did a google search and couldn't find any independent installations of it.
Canonical do their repackage/spit/polish thing, other companies do their thing, I'm really not sure that there's much point to a. encourage people to work with Canonical on stuff or b. encourage Canonical to work more with other people on stuff. Aside from bzr and upstart, I can't think of much else which has had traction in either direction. I'm just not sure their goals are particularly well aligned with anyone else's.
(Presumably they play much better with Debian these days, so I suppose that counts).
Posted Jul 28, 2010 21:05 UTC (Wed) by rahulsundaram (subscriber, #21946)
Other distributions like openSUSE seem to be switching in their next release as well. For all Canonical led projects, there is the thorny problem of copyright assignment as covered at
If they stop doing that, perhaps we would see a more diverse base of contributions and more deployments of things like Launchpad.
Posted Jul 28, 2010 21:34 UTC (Wed) by jspaleta (subscriber, #50639)
And since launchpad as a codebase was never designed to federate with a set of peer services (even though bzr clearly knows how), there's very little to gain by producing another public service that launchpad.net provides..and incurring the infrastructure cost. Everyone who loves what it provides will just use launchpad.net with no qualms about its open status. Now that its open, if it every closes again, someone may make a serious stab at forking the available codebase and creating an alternative implementation, but there's no evidence of that being a near term concern for anyone.
Posted Jul 28, 2010 22:16 UTC (Wed) by AlexHudson (subscriber, #41828)
Post-release (it's been out a year now?) you have to say that the release of Launchpad has basically been a damp squib and it's made practically no difference that it's free. People still use bugzilla/whatever, and those who clamoured for the release have made no discernible use of it.
Posted Jul 28, 2010 21:05 UTC (Wed) by SEJeff (subscriber, #51588)
Take a look at notify-osd, their fork of chipx86's libnotify. Granted they didn't create notify-osd until after libnotify upstream was DEAD, but a lot of Gnome-ites are upset about notify-osd and not working with upstream on a solution.
Posted Jul 28, 2010 21:31 UTC (Wed) by gouldtj (subscriber, #48027)
None the less, just for a little factual information: libappindicator is an implementation of the KDE Status Notifier Item specification for GNOME. It has been proposed to FreeDesktop.org. It's implemented as an applet, similar to all the other applets in the system. When it was proposed to GNOME as simply an External Dependency (not even a full project) a bunch of Fedora devs decided it was a good time to bring out the blowtorches and flame away.
Very frustrating experience, and one I'm not too excited to repeat in the future. I probably will because it's the right thing to do, and I'd like to contribute to GNOME in a meaningful way. But the Fedora hate of all things Canonical makes that frustrating and mostly unproductive. I hope that in the future that will change, but it sadly seems to be heading more for entrenchment rather than cooperation.
Posted Jul 28, 2010 22:02 UTC (Wed) by mjg59 (subscriber, #23239)
As a Fedora developer who still puts a certain amount of time into helping out Ubuntu developers, I think you're being a little sweeping in that generalisation.
Posted Jul 28, 2010 22:12 UTC (Wed) by gouldtj (subscriber, #48027)
Posted Jul 28, 2010 22:07 UTC (Wed) by rahulsundaram (subscriber, #21946)
Your attempt to paint it as merely a Fedora or Red Hat conflict with Canonical which is certainly ignoring the larger issues at stake here. The debates in desktop-devel list were technical in nature. GNOME Shell has no support for applets and a proposal to include a applet at that point is obviously going nowhere and besides the decision was made by the release engineering team and unless you are going to accuse them of partisanship, you have to accept the rejection and justification for it.
In the future, I would suggest bringing up ideas and implementation earlier to the upstream communities in question rather than as a finished product after doing the distribution specific integration. Otherwise, all the divergence is going to come back and bite sooner or latter.
Posted Jul 29, 2010 8:51 UTC (Thu) by rhertzog (subscriber, #4671)
So it's difficult to criticize someone else doing things that need to ship now because they don't integrate into something that's not even fully designed and that has not shown how it's going to integrate everything that already exists.
Posted Jul 29, 2010 9:01 UTC (Thu) by rahulsundaram (subscriber, #21946)
Posted Jul 28, 2010 22:10 UTC (Wed) by AlexHudson (subscriber, #41828)
.. it seems one could equally characterise the "bunch of Fedora devs" (well, at least one) being the ones bringing up the libappindicator work in the first place and trying to find out if it was usable within GNOME. Having read through that thread, and the subsequent external module proposal, I had difficulty locating the blowtorches you speak of.
Posted Jul 28, 2010 22:34 UTC (Wed) by gouldtj (subscriber, #48027)
I have never seen a discussion on DDL over API. I have never seen the API of an external dependency taken into account for its acceptance. In general, I've never seen anyone care about the API of an external dependency on DDL. It seems like a pretty exceptional conversation. Obviously the whole development wasn't behind closed doors as, for instance, Collin was aware of it and started the discussion.
In the end, if there is a communication issue let's solve that and not start the discussion with "X doesn't do Y" -- which I realize I was just as guilty of as anyone else. Though, I would like there to be some awareness within Red Hat that, on the other side, it definitely feels like "special" treatment is given to Canonical contributions. I could be entirely wrong about that. I hope I'm entirely wrong about that. I hope that understanding that there are people feeling that way can help to make the situation better.
Posted Jul 29, 2010 7:07 UTC (Thu) by AlexHudson (subscriber, #41828)
Let's be realistic, this same scenario will play out again: either with "Windicators", or with any of the other fundamental UI work that's happening in Ayatana, disconnected from the GNOME stuff. And it's diverging further and further from the vision for GNOME 3. If that's where Canonical wants to go, that's fine though - like I said earlier, I think people need to get over it.
Posted Jul 28, 2010 22:18 UTC (Wed) by jspaleta (subscriber, #50639)
Libappindicator was publicly announced as a consumable codebase when? Dec 2009 on your blog? The plans for GNOME Shell were public when? At least last summer's GUADEC?
Even in your own blog on Dev 16 2009 in a response comment you speak to the GNOME 3 integration issue making it clear you were fully aware that it was diverging from the already existing publicly communicated development roadmap for gnome shell and you thought this was a better way to go. Of course you did, everyone thinks their baby is the cutest. But when did you really sit down and try to have the discussion when it was still early enough to compromise over implementation details?
So what 4 months after GNOME Shell's development intent is publicly communicated you decided to build a competing implementation without public discussion of the short comings of what is planned for GNOME Shell and attempt to get buy in on changing the development roadmap? And once you completed the initial implementation in dev 2009 that people could play with, you waited how long to have a public discussion about how this could be integrated in GNOME Shell?
Remind me, did you find someone to talk about libappindicator at the Gnome UX hackfest at Canonical's London offices prior to submission to the module decisions? Give me a name of the person who you tapped to bring it up for discussion at the UX hackfest. You did sort of say that you were going to find someone to bring it up when the technical discussion about libappindicator came up in the gnome desktop devel list when the technical specifics of libappindicator were being discussed..and well the discussion on the list just sort of died at that point. Seems to me people were expecting someone from Canonical to bring this up for discussion at the hackfest as you stated you couldn't be there in person to finish the conversation.
And well, I didnt see any commentary in any media feeds or lists that I can find that it was brought up by anyone at Canonical at the hackfest. Forget for a moment that Canonical was hosting a hackfast at its own corporate offices and couldn't get you there to make sure this was discussed. Forget for a second how odd that seems if the intention was to make the best effort to get this integrated as a GNOME 3 technology. Did anyone from Canonical try to talk over integrating libappindicator into the GNOME 3 design as part of that hackfest? I can't imagine a more friendly environment to hold that discussion...Canonical's own corporate offices. Did people just forget to communicate that it was discussed because taskpooper was just far more interesting a topic to blog about? (hell ars technica even had a taskpooper column based on the drips and draps of information communicated via blog posts from the Gnome hackfast held at Canonical's offices...but the aforementioned promised discussion about libappindicator integration...nadda)
So yeah, maybe communication from the Canonical side of the fence could haave been better considering that GNOME Shell's roadmap was already public, and you were aware of it, before starting this project, and there were multiple opportunities to interface with people about technical requirements for libappindicator to be suitable for GNOME 3 integration prior to the module submission deadline..and it appears to have failed to occurred.
Posted Jul 29, 2010 2:41 UTC (Thu) by gouldtj (subscriber, #48027)
Sure, why not.
I think that a better date to track the beginnings of GNOME Shell would be to the 2008 GNOME UX Hackfest. I was there, and infact on the shell team that did the original mockups for what would become GNOME Shell eventually. It was discussed at the Boston Hackfest immediately after. Infact, by the time GUADEC came around it was already packaged for Ubuntu.
One of the things that was discussed as a principle at the original UX Hackfest discussing this was the simplification of the panel. Basic menus, not the notification area hell that had been created. It was widely agreed upon then. I would say that this is also the public origin of the work that would become libappindicator -- though I didn't have time to work on it until later.
At the last GNOME UX Hackfest at Canonical's offices I was not there. The big reason is that I felt that too many Canonical employees attending the hackfest would create a "mob" atmosphere since it was already in the Canonical offices. We decided that Canonical would just send the folks already in London as it was less travel costs, and already more than enough people. I asked Matthew Paul Thomas to discuss Application Indicators with John McCann also at the hackfest. I believe that they did have that discussion, and left with an understanding that AppIndicators aligned with many of the same design goals as Shell along with the fact that we were interested in what changes the Shell team was interested in to make it compatible.
This is infact a similar conversation that I had with John and Marriana at the 2009 GUADEC where we discussed the messaging menu and libindicate which is the application side of the messaging menu. I was concerned that we had asked application developers to support a new API, and that was a big ask, it would be good if no one (us or Shell) would have to ask that again. They said that they wanted to do a little more with the messaging aspects of Shell, but they weren't sure yet, so I left it as "we'd like to work together, tell me what changes we need." As I'd like to make changes so that we could all use the same library for messaging tasks.
So, in review, I most certainly know about GNOME Shell, and I still believe that libappindicator is a great GNOME 2 way to get to the design goals of GNOME Shell. Unfortunately the GNOME Shell team has decided that there is no longer alignment there. I haven't seen any rationale for that, or seen updated design documents that change things signficantly enough to say that the libappindicator methodology no longer aligns.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds