Weekly Edition
Return to the Development page
| |||||||||||||
GNOME 3.0 release delayed
The much-anticipated release of GNOME 3.0—scheduled for
September—has been pushed back to March 2011 due to quality issues in
the code. The announcement was made at GUADEC (GNOME users'
and developers' European conference), which is being held July 26-30 in The
Hague, Netherlands. There will be a GNOME 2.32 release in September along
with GNOME 3 beta. GNOME 2.32 will have the usual
performance enhancements and bug fixes along with a new control
center design, UPnP, and color management support. The extra time will be used to improve GNOME
Accessibility support, GNOME Shell, and documentation for GNOME
3.0. There should be a press release on the GNOME web site before
too long, stay tuned.
(Log in to post comments)
GNOME 3.0 release delayed Posted Jul 28, 2010 13:38 UTC (Wed) by sylware (guest, #35259) [Link]
I have not checked, but I wonder how the migration to dconf/GSettings is going. Hope, we will actually have gnome 3 free of gconf/orbit as it was planned.
GNOME 3.0 release delayed Posted Jul 28, 2010 14:29 UTC (Wed) by jpeddicord (subscriber, #57393) [Link]
There are a few modules that have been ported to dconf, but by the looks of it I can't see everything being ported by September. It's sad to see it delayed, but it's for the best. And we all knew it was coming.
GNOME 3.0 release delayed Posted Jul 28, 2010 16:52 UTC (Wed) by j1mc (guest, #56848) [Link]
I think this is a good thing, too. Plus, getting Gnome-Shell into testing for more users will be a good thing, I think.
GNOME 3.0 release delayed Posted Jul 28, 2010 15:53 UTC (Wed) by miffe (subscriber, #24478) [Link] Seems like they have a long way to go http://live.gnome.org/GnomeGoals/GSettingsMigration
GNOME 3.0 release delayed Posted Jul 28, 2010 14:47 UTC (Wed) by pebolle (guest, #35204) [Link]
> There should be a press release on the GNOME web site before too long,
> stay tuned.
http://www.gnome.org/press/releases/2010-07-gnome-3.0-res...
GNOME 3.0 release delayed Posted Jul 28, 2010 15:50 UTC (Wed) by sebas (subscriber, #51660) [Link]
Following GNOME3 development a bit from the sidelines, it would be interesting to know more details, for example:
* Will the Spring 2011 GNOME 3 be based on GTK3?
* Will it include Zeitgeist, which was deemed not ready for a Fall 2010 release?
I'm sure these topics have been part of the decision to move the release forward, but the information that is available online doesn't mention it.
GNOME 3.0 release delayed Posted Jul 28, 2010 16:08 UTC (Wed) by me@jasonclinton.com (subscriber, #52701) [Link]
> * Will the Spring 2011 GNOME 3 be based on GTK3?
Largely. Many modules have already been "ported" (removed use of deprecated functions) but a little more work will be needed after Benjamin Otte's rendering clean up branch lands (especially in GNOME Games).
> * Will it include Zeitgeist, which was deemed not ready for a Fall 2010 release?
If they resubmit their module application and address the issues that got them rejected last time, then yes.
GNOME 3.0 release delayed Posted Jul 28, 2010 16:29 UTC (Wed) by sebas (subscriber, #51660) [Link]
Thanks for the information, Jason!
OT: Is ORBit still faster than DBus? Posted Jul 28, 2010 19:40 UTC (Wed) by debacle (subscriber, #7114) [Link]
Some time back, when GNOME started to move from ORBit (CORBA) to DBus, I read an interesting article claiming that DBus is much slower (was it 17×?) than the ORBit incarnation of CORBA. If this ever was true (I didn't test), is this still the case?
OT: Is ORBit still faster than DBus? Posted Jul 28, 2010 22:24 UTC (Wed) by njs (guest, #40338) [Link]
I don't know, but it doesn't matter -- DBus provides different functionality, so a comparison isn't really meaningful in the first place (safety and simplicity have their costs, etc.), and anyway, neither is the bottleneck in any reasonable usage. Which means their speed will have no affect on end-users anyway.
OT: Is ORBit still faster than DBus? Posted Jul 28, 2010 22:28 UTC (Wed) by coriordan (guest, #7544) [Link]
I'd be interested to hear more about that too.
I remember when they choose to make a CORBA-base system, there were a lot of complaints that CORBA systems would always be unnecessarily slow. IIRC, one of the reasons the Orbit (CORBA) proposal won was that OpenOffice.org was using CORBA ("Uno"), and it would make integration easier, but I don't remember this really happening.
OT: Is ORBit still faster than DBus? Posted Jul 29, 2010 3:29 UTC (Thu) by hp (subscriber, #5220) [Link]
while I don't think 17x is accurate, libdbus is certainly slower than orbit. it's inherently slower by 2x, because of the bus - all apps go to a bus process then to other apps, so messages go over two sockets - of course, this also adds a lot of features, so it is worth it. but libdbus is also just plain slower even if you ignore that. it's coded with priorities other than speed.
however, gnome 3 will mostly use the new gdbus implementation in glib, which may well be faster than libdbus. however, it's still unlikely to be faster than orbit. orbit was fast, but didn't have the right features.
all this said, afaik libdbus has never been seriously optimized (or at all optimized) since this effort in 2004:
gdbus may still need profiling and tuning, or someone may have already done it, I have no idea.
I think the reason libdbus hasn't been seriously optimized is that it rarely shows up in profiles unless someone is doing something idiotic. It's common on Slashdot or whatever to assume that X is slow due to IPC, or GNOME is slow due to CORBA, or whatever, but the reality is that I've never seen IPC near the top of a profile for a desktop app, unless the app was doing something fundamentally bad that experienced desktop programmers know to avoid these days.
The rules are pretty simple for both X and dbus, for example:
If you plan things so you have dozens or a hundred IPC calls instead of thousands, and don't have to block for call 1's result in order to make call 2, you'll be fine. One advantage of dbus is that it has a lot of features designed to *avoid* the need to block in a round trip, and the new gdbus API has some nice features to help apps avoid this.
I think server-side programmers often have the wrong intuition here, because of course IPC is going to be a bottleneck for server apps that are mostly about handling network requests. But desktop apps mostly spend their time drawing pixels or waiting for mouse events or waiting on the filesystem or any number of things, while their use of IPC is just a few messages here and there. Also, desktop IPC is unix domain sockets, which are just elaborate cross-process memory copies. This is pretty different from TCP.
A historical issue was the idea of using IPC for a "component system" so that an app could be made up of a swarm of different processes; that architecture would indeed tend to bottleneck on IPC. However, it was a bad idea and a lot of the design of dbus was done with this use-case specifically excluded. The modern GNOME equivalent of "component system" in this sense would be GObject plus gobject-introspection, an in-process setup.
I'm sure profiling (and optimizing based on said profile) libdbus and gdbus would be a fun project, and welcome. But I don't know if there's anything that would be user-visibly faster in GNOME afterward.
OT: Is ORBit still faster than DBus? Posted Jul 29, 2010 8:39 UTC (Thu) by debacle (subscriber, #7114) [Link]
Many thanks for your insightful explanation! I have to learn about gdbus...
(My question was really off-topic, because I will use DBus in an embedded, non-graphical, non-Gnome application. We will use DBus, not CORBA, because we have to communicate with dbus apps like Network Manager etc. anyway, so it's just easier to stay with DBus, even if it's slower.)
OT: Is ORBit still faster than DBus? Posted Jul 29, 2010 18:00 UTC (Thu) by aleXXX (subscriber, #2742) [Link]
It would really be a good idea if somebody (you ?) would try to optimize libdbus.
Especially embedded developers often report bad performance numbers, e.g. when running on a 200 MHz ARM or so.
One thing you can do is to use libdbus in peer-to-peer mode, this avoids visiting the bus daemon and by this one receive, deserialize, serialize, send combination. But it's more work. AFAIK no binding supports this mode currently, so you have to do it using libdbus directly.
Alex
OT: Is ORBit still faster than DBus? Posted Jul 29, 2010 18:22 UTC (Thu) by debacle (subscriber, #7114) [Link]
ARM@200MHz is exactly our platform and we already feel the pain. Our solution will be probably the same as I would do with CORBA: Reduce the number of IPC calls. The idea of using peer-to-peer DBus sounds nice, too. In CORBA world this is the common way, using e.g. event services is the exception. Many thanks for the suggestion!
OT: Is ORBit still faster than DBus? Posted Jul 29, 2010 18:27 UTC (Thu) by hp (subscriber, #5220) [Link]
dbus was designed for the desktop... I think when people try to repurpose it for embedded or other purposes, they have to be prepared to go in and make it actually work in those scenarios. I don't know anything about these use-cases, and they just were never thought about when creating dbus.
minimizing IPC and going peer-to-peer instead of through the bus are both good suggestions.
if you have simple needs just using a raw unix socket instead of a whole IPC "system" might be a good option too. for peer-to-peer the "XMLSocket" protocol that Flash uses is a nice simple one: bidirectional stream of nul-separated strings. Not a lot of code to write for that.
anyway, anyone is welcome to improve libdbus or gdbus or any of the other implementations of dbus, of course! make it do what you need. that's what open source is about.
GNOME 3.0 release delayed Posted Jul 29, 2010 4:05 UTC (Thu) by haydn (guest, #69224) [Link]
GNOME IS BROKEN BY DESIGN
As a long-time Linux user and computer science student, I must comment that Gnome is broken by design.
I've been using Linux since around 2000, and have watched Gnome and KDE closely.
While KDE broke itself with 4.0, Gnome intentionally switches buttons back and forth (OK/CANCEL) while Miguel De Icaza works on Moonlight?
Gnome is a mess by design and it's really obvious over 10 years. I'm sure Microsoft can pay to break Gnome (Icaza/Novell)?
Just try the latest Nautilus 2.28 and watch your files disappear. My bug reports were ignored in 2008 and are still ignored.
Come on Gnome, let's switch the OK/CANCEL buttons back and forth again. Maybe you can promote your Accessibility some more?
GNOME 3.0 release delayed Posted Jul 29, 2010 8:25 UTC (Thu) by Los__D (guest, #15263) [Link]
Let's see.... Now two posts on LWN.net, both pure trolls.
Do you have anything constructive to say, at all?
GNOME 3.0 release delayed Posted Jul 30, 2010 19:14 UTC (Fri) by tack (subscriber, #12542) [Link]
Can you please provide links to your bug reports? I'm interested in trying to reproduce with current GNOME.
GNOME 3.0 release delayed Posted Jul 31, 2010 16:32 UTC (Sat) by SEMW (guest, #52697) [Link]
The button order on OK/Cancel dialogues is quite clearly an arbitrary convention -- whichever one you are used to will seem right, whichever one you aren't will seem wrong. MacOS and Gnome have standardised on one convention; KDE and Windows have standardised on the other.
So your implication that the Gnome/MacOS convention is somehow objectively the wrong, and less accessible, one is just not true (or, at least, unsubstantiated). For Gnome to switch to the other convention now would be the real accessibility fail, since that would break with the convention that their users are used to.
If that's your primary evidence that it's "broken by design", they would seem to be doing pretty well...
GNOME 3.0 release delayed Posted Aug 2, 2010 10:45 UTC (Mon) by nye (guest, #51576) [Link]
>The button order on OK/Cancel dialogues is quite clearly an arbitrary convention
There is a tiny bit more to it than that - in English-speaking cultures, questions requiring a binary answer are 'yes or no', not 'no or yes', so having the 'no' button first creates some minor cognitive dissonance.
GNOME 3.0 release delayed Posted Aug 2, 2010 11:50 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
HIG doesn't just toss up yes/no buttons and simply changing the order wouldn't meet the guidelines. It is a little more detailed than that.
GNOME 3.0 release delayed Posted Aug 2, 2010 16:09 UTC (Mon) by nye (guest, #51576) [Link]
Whatever you say, mister literal.
GNOME 3.0 release delayed Posted Jul 29, 2010 6:40 UTC (Thu) by nikanth (guest, #50093) [Link]
So people will have to wait till March 2011 to switch back to KDE! Hmm... when is KDE5 scheduled to release, so that people will try GNOME 3. ;-)
|
|||||||||||||