Has GNOME Rejected Canonical Help? Shuttleworth Responds
akgraner writes "When Canonical made the decision to make Unity the default desktop, some questioned the GNOME/Canonical relationship. Adding fuel to this fire was the recent distribution split of revenue generated by Banshee. These decisions caused the Ubuntu, GNOME and even Fedora community members to ask why these things were done. In Dave Neary's 'Has GNOME rejected Canonical help?' post, he states, 'I have repeatedly read Canonical & Ubuntu people say, "We offered our help to GNOME, and they didn't want it."' Neary gives examples in his post of what others have said to back up the 'they didn't want it' claim by Canonical and Ubuntu people. Today, though, Shuttleworth responds on his blog. 'Competition is tough on the contestants, but it gets great results for everyone else.'"
Some of us disabled users are looking for an alternative operating system for our Windows XP netbooks. The compiz magnifier is great, but GNOME is the _only_ desktop environment that has a screen reader. The GNOME screen reader performs _very_ slowly on a netbook though. It even runs slow on a modern system sometimes.
My point? Can we stop with the political issues and try to just produce the best, stable, reliable system we possibly can? Can we stop changing the underlying components every two years? Can we stop changing things that don't make the system any better (like notification bubbles that require more daemons) and fix what we do have?
also, this is not an odd "oops, we just didn't get around to it" event on the part of GNOME: how's that job D-Bus implementation in GNOME 3 coming? you know, the one that needlessly duplicates the one KDE implements, which we actually designed with thought of cross-project use including getting some feedback from non-KDE devs? or how about the screensaver D-Bus API which we implemented specifically with collaboration with GNOME devs at SUSE, only later to have GNOME not implement it and then complain to us that it used the org.freedesktop namespace? or how about how GNOME devs specifically blocked the formation of a common git repository for fd.o specs, and then when there was finally agreement (after an in-person meeting) insist on implementing it themselves, ignoring that repo had already been started but by people with @kde.org email addresses, and then after taking months to eventually duplicate that effort not implement the most critical part of it: the metadata?
Shuttleworth suggests that building development around FreeDesktop.org specs (as suggested by Aaron Seigo) is probably a good route to take, especially since Ubuntu is NOT just GNOME, but also KDE (Kubuntu), etc.
I heartily agree with that. I want to see Unity come out and kick butt, and it sounds like as good as GNOME Shell might be, GNOME people are forcing this into a you-vs.-us fight.
(It doesn't help to see Jeff Waugh being all complainy on Mark's blog, either.)
It's pretty clear that there are some massive egos/control-freaks within those running the GNOME project.
As far as user interfaces go, it is Havoc Pennington's way or the highway. Havoc has this crazy "usability comes from crippling" approach that dumbs down GNOME for entry-level users but makes it wholly unusable for power users.
Whereas KDE keeps "entry level" defaults and makes some of the niche/advanced configuration options (such as edge flipping) harder to find, GNOME's approach is to outright remove the feature. There are only so many features you can remove before your approach becomes unusable for many.
That's why I used to be a staunch GNOME supporter and fairly anti-KDE (I'm still not a fan of how they handled the Qt/GPL license incompatibilities, the issue didn't get resolved until Qt was effectively forced to change their license. The KDE developers had a consistent attitude that there was no problem and refused to take any approach to address), but have now pretty much changed over entirely to KDE. Around the same time the KDE license incompatibility issue was resolved is when Havoc began his reign of "cripple it in the name of usability" terror. Not only did the GNOME team remove edge flipping, they made it as difficult as possible to add it in after the fact (Brightside effectively broke after every GNOME release, and eventually GNOME broke the interfaces Brightside used to the point where the Brightside maintainer gave up.) It's always been there in KDE.
Yes, the KDE team has gotten a bad rep from KDE 4.0 getting shipped too early. I don't think there was any graceful way to do things here - there always comes a time when a project has to do a major rearchitecture, and sometimes that can't be done without some user pain. Later KDE4 releases are excellent. The key here is - KDE went through some pain in order to greatly improve the flexibility of the platform and leave them room to grow. GNOME didn't - in the short term that was good for GNOME, but in the long term that inflexibility is going to hurt.
retrorocket.o not found, launch anyway?
Shuttleworth notes to that end, "Weâ(TM)ve failed." He adds, "Much of the language, and much of the decision making Iâ(TM)ve observed within Gnome, is based on the idea that Unity is competition WITH Gnome, rather than WITHIN Gnome."
There was a story on The Register today on why Nokia failed. They had the exact same problem - teams that should be working together are fighting against each other and in the end just losing together. That seems to be a large problem in OSS community too, and it's no wonder Nokia had it too (they had many Linux developers). But when a software company, usually proprietary, is ran good, it doesn't suffer such problems as management makes good decisions and gives orders. That is why Windows works good and why the quality is consistent.
Infighting in Microsoft is why we didn't get clear-type for over 10 years after it was available... (Clear-type is the software that gives fonts 3 times the horizontal resolution on LCDs) The Office Suite devs wanted it for their own -- to boost their own team's importance, and refused to fix the the MS Office font system to work with clear-type unless the clear-type devs were placed under the Office Suite team's umbrella.
This is just one small example of MS infighting stifling innovation. Please take your closed source software down from the pedestal. Management is the problem -- That, and a "not invented here" mentality. It can happen anywhere.
Ubuntu and Gnome are diverging because they each have their own goals and any interference with one's goals is not tolerated -- I've found that true collaboration basically requires an alignment of our goals -- Seems to me like human nature.
The difference is that when Canonical and Gnome bicker, I can still use the features that they independently develop... I'm not stuck waiting for 10 years (like for Windows clear-type).
@Lennart: "If you list this notifier spec, then I can list you the sound theming/naming specs which KDE has shown no interest in."
:)
... simply to provide compatibility. would GNOME devs do that today? doubtful, because our priorities, as you point out, are indeed different.
that's an incorrect comparison.
if we (KDE) had offered a bunch of critique on the sound theme spec, had someone come to us with an implementation in Qt and then still gone off and done our own thing instead, then it would be an adequate comparison. but that isn't what happened, is it?
we (KDE) simply haven't gotten around to implementing the sound theming spec. why? as you note, it's not a high priority for us. but i guarantee you that if someone stepped up to do some work on the event sounds infra in kdelibs, stop #1 would be that naming spec.
also, this is not an odd "oops, we just didn't get around to it" event on the part of GNOME: how's that job D-Bus implementation in GNOME 3 coming? you know, the one that needlessly duplicates the one KDE implements, which we actually designed with thought of cross-project use including getting some feedback from non-KDE devs? or how about the screensaver D-Bus API which we implemented specifically with collaboration with GNOME devs at SUSE, only later to have GNOME not implement it and then complain to us that it used the org.freedesktop namespace? or how about how GNOME devs specifically blocked the formation of a common git repository for fd.o specs, and then when there was finally agreement (after an in-person meeting) insist on implementing it themselves, ignoring that repo had already been started but by people with @kde.org email addresses, and then after taking months to eventually duplicate that effort not implement the most critical part of it: the metadata?
in contrast, we could see how KDE implemented support for the visual notificatons D-Bus protocol as implemented in GNOME, even though it has evident limitations and is a 100% subset of something we already have in the form of KNotify
what GNOME needs is not more apologists making excuses for poor behavior but people who will stand up and take ownership of their actions.
Jesus had a UNIX beard.
The main problem with OS X 10.0 was performance, and this wasn't due to adopting OPENSTEP (not OpenStep - OpenStep is a specification, OPENSTEP is an operating system), but due to replacing code. One of the biggest changes between OPENSTEP 4.2 and OS X 10.0 was replacing Display PostScript with Quartz. This moved to a compositing model, rather than a direct drawing model. This gives a significant performance advantage on modern machines. If you drag a window across the screen on OPENSTEP, every application underneath gets a load of redraw events and has to run some quite processor-intensive code to update the display. With OS X, the GPU just draws a few textured rectangles. With 10.0, however, this was all done in software, and on a 266MHz PowerPC was very slow. Especially since the software paths weren't very well optimised (10.0 was the 'make it work' release, 10.1 was the first 'make it fast' release).
I am TheRaven on Soylent News
It's ridiculous to run a distribution that doesn't have package signing. Especially one that pushes out updates as frequently as Arch does. Arch's complete disregard for basic security measures is truly amazing.