| |||||||||||||
Neary: GNOME CensusNeary: GNOME CensusPosted Jul 28, 2010 17:01 UTC (Wed) by evad (subscriber, #60553)In reply to: Neary: GNOME Census by me@jasonclinton.com Parent article: Neary: GNOME Census
I don't see how the end-user mind share and how many people Canonical employs to work on upstream projects are at all connected. So Red Hat happens to employ a lot of people who are core GNOME developers and Canonical doesn't (mainly because the older Linux companies already employ most of them!). That makes no difference to who uses the final product of each company.
(Log in to post comments)
Neary: GNOME Census Posted Jul 28, 2010 17:07 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
The fact that Canonical is very delibrately and very purposefully actively forking existing GNOME technologies in very noticable ways matters.
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.
-jef
Neary: GNOME Census Posted Jul 28, 2010 18:07 UTC (Wed) by evad (subscriber, #60553) [Link]
Just out of interest, what projects are Canonical doing that with?
Neary: GNOME Census Posted Jul 28, 2010 18:23 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
I would call the libappindicator work..the most obvious example of deliberate technology divergence from Gnome upstream in a an important framework technology standpoint.
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.
-jef
Neary: GNOME Census Posted Jul 28, 2010 20:39 UTC (Wed) by gowen (guest, #23914) [Link]
Gnome-shell won't work on unaccelerated video hardware. The Gnome devs have said this bug will not be fixed. That makes it unsuitable for much low end hardware, including very many netbooks.
Neary: GNOME Census Posted Jul 28, 2010 20:41 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Have you looked at Unity it has the same problem as its also based on clutter.
-jef
Neary: GNOME Census Posted Jul 29, 2010 11:17 UTC (Thu) by cortana (subscriber, #24596) [Link]
Hmph. So much for continuing to use GNOME in my virtual machine.
Neary: GNOME Census Posted Jul 29, 2010 18:50 UTC (Thu) by foom (subscriber, #14868) [Link]
It seems like it probably will be fixed sometime soon, by the work people are doing to make Mesa's software rendering stack not suck.
Neary: GNOME Census Posted Jul 29, 2010 19:00 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
Anyone do the commit analysis for mesa yet? Wouldn't it be great to find out Which corporate entities are actively working on making mesa not suck? Considering that both gnome-shell and unity are relying on the same hardware requirements as mandated by clutter.
-jef
Neary: GNOME Census Posted Aug 1, 2010 22:16 UTC (Sun) by drago01 (subscriber, #50715) [Link]
OK, this might be a bit late but your comment does not make any sense.
Being "low end" hardware does not imply no hardware acceleration, in fact any recent pc hardware (as in produced in the last 5 years; which includes netbooks), does have a GPU capable of hardware acceleration.
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
So "it does not work on low end hardware and they won't fix it" is just wrong.
Neary: GNOME Census Posted Aug 2, 2010 0:14 UTC (Mon) by foom (subscriber, #14868) [Link]
> in fact any recent pc hardware (as in produced in the last 5 years; which includes netbooks), does have a GPU capable of hardware acceleration.
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...
Neary: GNOME Census Posted Aug 3, 2010 16:18 UTC (Tue) by drago01 (subscriber, #50715) [Link]
> 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.
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.
Neary: GNOME Census Posted Aug 4, 2010 17:32 UTC (Wed) by nwnk (subscriber, #52271) [Link]
I'm curious what netbooks you think exist that don't have 3D hardware.
Neary: GNOME Census Posted Jul 28, 2010 20:52 UTC (Wed) by AlexHudson (subscriber, #41828) [Link]
Eh, you have to feel sorry for them, though. They put effort into Baz/Bazaar, then git came along. They did that netbook UI thing, and then the 'light' interface, meanwhile gnome-shell is arriving. They wander seemingly alone down alleyways like Storm and Quickly, though I suppose upstart has been pretty successful.
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).
Neary: GNOME Census Posted Jul 28, 2010 21:05 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
FWIW, Fedora 14 is planning on replacing Upstart with systemd and Rawhide now has made the switch already
http://lwn.net/Articles/397382/
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
http://lwn.net/Articles/359013/
If they stop doing that, perhaps we would see a more diverse base of contributions and more deployments of things like Launchpad.
Neary: GNOME Census Posted Jul 28, 2010 21:34 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Opening launchpad wasn't about creating competing public services. It was about making it possible for the technically proficient Ubuntu contributors to be able to stop _just_ filing bug and start filing patches to improve the tools they are required to use to do their work. It is possible to (and I'm sure people have) followed the instructions on running a toy development launchpad instance in order to poke at it without making the infrastructure investment of running it as a public service.
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.
-jef
Neary: GNOME Census Posted Jul 28, 2010 22:16 UTC (Wed) by AlexHudson (subscriber, #41828) [Link]
Whatever Canonical's reason for releasing Launchpad, that's beside the point I was making: there was a lot of criticism that a supposed "open source" company was using a proprietary and centralised app and not walking the walk.
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.
Neary: GNOME Census Posted Jul 28, 2010 21:05 UTC (Wed) by SEJeff (subscriber, #51588) [Link]
Wow jef, for once we agree :)
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.
Neary: GNOME Census Posted Jul 28, 2010 21:31 UTC (Wed) by gouldtj (subscriber, #48027) [Link]
I hate to feed the trolls, but I'd have to say that I'm frustrated that the Red Hat/Fedora FUD has switched from "Canonical doesn't contribute" to "Canonical doesn't communicate."
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.
Neary: GNOME Census Posted Jul 28, 2010 22:02 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Ted,
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.
Neary: GNOME Census Posted Jul 28, 2010 22:12 UTC (Wed) by gouldtj (subscriber, #48027) [Link]
You are certainly correct. I'm just frustrated, but that's not a good excuse. I feel that in general "distro wars" are silly, and unproductive, and I get pulled into them more than I'd like. Personally, I don't care, I'd just love to see lots of Free Software users.
Neary: GNOME Census Posted Jul 28, 2010 22:07 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Ted Gould,
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.
Neary: GNOME Census Posted Jul 29, 2010 8:51 UTC (Thu) by rhertzog (subscriber, #4671) [Link]
The lack of applet support in Gnome-Shell is a problem. How are we supposed to use hamster in Gnome 3.0 for example ?
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.
Neary: GNOME Census Posted Jul 29, 2010 9:01 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
GNOME Shell wont have applets and this has been announced and explained a long time back. Regardless of the justification of that decision, it is no surprise to anyone. I don't have a problem with distributions shipping custom applets and patching applications to support a different API but if it is going to be part of an upstream community like GNOME, it requires more upfront discussions or the distribution will have to pay the cost (and reap the benefits) of the divergence.
Neary: GNOME Census Posted Jul 28, 2010 22:10 UTC (Wed) by AlexHudson (subscriber, #41828) [Link]
Given the discussion here:
http://mail.gnome.org/archives/desktop-devel-list/2010-Fe...
.. 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.
Neary: GNOME Census Posted Jul 28, 2010 22:34 UTC (Wed) by gouldtj (subscriber, #48027) [Link]
Alex,
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.
Ted
Neary: GNOME Census Posted Jul 29, 2010 7:07 UTC (Thu) by AlexHudson (subscriber, #41828) [Link]
Sure, but hang on, the API was in the discussion but the reasons it was rejected was that it didn't integrate with gnome-shell for gnome 3, nothing in gnome 2 uses it and there was an open question about how it could/should integrate with Gtk+.
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.
Neary: GNOME Census Posted Jul 28, 2010 22:18 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Shall we cover the timeline here.
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?
http://gnome.mirocommunity.org/video/239/guadec-2009-owen...
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.
-jef
Neary: GNOME Census Posted Jul 29, 2010 2:41 UTC (Thu) by gouldtj (subscriber, #48027) [Link]
> Shall we cover the timeline here.
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.
Thanks,
Neary: GNOME Census Posted Jul 28, 2010 17:28 UTC (Wed) by coriordan (guest, #7544) [Link] Maybe the point is that for a major distro who's focus is on the interface, it's surprising they don't have more upstream commits to that interface.
Neary: GNOME Census Posted Jul 28, 2010 17:39 UTC (Wed) by alexl (subscriber, #19068) [Link]
It doesn't matter for the bits, you could get them anywhere. But if you're say, buying support for a long term stable release, would an end user get best support if the company doing the support wrote and maintain large parts of the software base they are to support. Probably.
|
|||||||||||||