Slashdot Mirror
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.'"
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?
you've obviously never tried to get Gnome devs to change things back... they're absolutely obsessed with making things as unconfigurable as possible for the end user as they believe what they offer is right and the user is an idiot for wanting to changing some options... Just try configuring the screensaver to use images in a directory OTHER than the one they want you to use... it's impossible without doing some manual editing and diving deep... the options are just not there in the screensaver itself...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
@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.
Did you not read my post? I don't like the way the whole setup of Gnome Shell 3 behaves. Saying that the minimize function was depreciated because it's no longer relevant in Gnome Shell isn't helping the case.
"People who think they know everything are very annoying to those of us who do."-Mark Twain