LWN: Comments on "GNOME 3.0 release delayed"

GNOME 3.0 release delayed

sylware — Mon, 20 Dec 2010 02:35:59 +0000

was done in chromium 9
:)

GNOME 3.0 release delayed

sylware — Tue, 14 Sep 2010 08:47:02 +0000

Hope chromium will drop its GConf dependency quickly.

GNOME 3.0 release delayed

nye — Mon, 02 Aug 2010 16:09:35 +0000

Whatever you say, mister literal.

GNOME 3.0 release delayed

rahulsundaram — Mon, 02 Aug 2010 11:50:00 +0000

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.

http://library.gnome.org/devel/hig-book/

GNOME 3.0 release delayed

nye — Mon, 02 Aug 2010 10:45:45 +0000

>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

SEMW — Sat, 31 Jul 2010 16:32:02 +0000

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

roblucid — Sat, 31 Jul 2010 11:26:16 +0000

lol very drole!

GNOME 3.0 release delayed

tack — Fri, 30 Jul 2010 19:14:10 +0000

Can you please provide links to your bug reports? I'm interested in trying to reproduce with current GNOME.

OT: Is ORBit still faster than DBus?

hp — Thu, 29 Jul 2010 18:27:17 +0000

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.

OT: Is ORBit still faster than DBus?

debacle — Thu, 29 Jul 2010 18:22:53 +0000

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?

aleXXX — Thu, 29 Jul 2010 18:00:30 +0000

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

GNOME 3.0 release delayed

aleXXX — Thu, 29 Jul 2010 17:57:32 +0000

No KDE 5 in sight.
Also no Qt5 is planned in the forseeable future.

Alex

OT: Is ORBit still faster than DBus?

debacle — Thu, 29 Jul 2010 08:39:14 +0000

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.)

GNOME 3.0 release delayed

Los__D — Thu, 29 Jul 2010 08:25:50 +0000

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

nikanth — Thu, 29 Jul 2010 06:40:20 +0000

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. ;-)

GNOME 3.0 release delayed

haydn — Thu, 29 Jul 2010 04:05:35 +0000

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?

OT: Is ORBit still faster than DBus?

hp — Thu, 29 Jul 2010 03:29:14 +0000

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:
http://lists.freedesktop.org/pipermail/dbus/2004-November...
and that 2004 effort was largely ruined when arbitrary recursive types were added to libdbus later on, which rewrote a bunch of the code.
See also http://log.ometer.com/2006-07.html#21

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:
* don't make blocking round trips where you wait for IPC to complete and lock up the whole app
* design the out-of-process interface to avoid round trips and to avoid "too much" IPC
* use shared memory if you're going to shovel some giant block of data (though unix domain sockets are so fast, this is less important than one might think)

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?

coriordan — Wed, 28 Jul 2010 22:28:41 +0000

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?

njs — Wed, 28 Jul 2010 22:24:51 +0000

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?

debacle — Wed, 28 Jul 2010 19:40:34 +0000

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?

GNOME 3.0 release delayed

j1mc — Wed, 28 Jul 2010 16:52:12 +0000

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

sebas — Wed, 28 Jul 2010 16:29:54 +0000

Thanks for the information, Jason!

GNOME 3.0 release delayed

me@jasonclinton.com — Wed, 28 Jul 2010 16:08:46 +0000

> * 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

miffe — Wed, 28 Jul 2010 15:53:57 +0000

Seems like they have a long way to go http://live.gnome.org/GnomeGoals/GSettingsMigration

GNOME 3.0 release delayed

sebas — Wed, 28 Jul 2010 15:50:27 +0000

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

pebolle — Wed, 28 Jul 2010 14:47:06 +0000

> 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

jpeddicord — Wed, 28 Jul 2010 14:29:18 +0000

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

sylware — Wed, 28 Jul 2010 13:38:00 +0000

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.