Matthew Garrett ([personal profile] mjg59) wrote,
@ 2011-04-27 12:35 pm UTC
  • Previous Entry
  • Add to Memories
  • Tell someone about this!
  • Next Entry
Entry tags:advogato, fedora
At some stage the seminal KDE vs Gnome paper vanished from its original home, and while it's still available in a few places (such as here) it set me thinking. What are the fundamental differences between Gnome and KDE development? There's lots of little differences (2006: Gnome parties on a beach. Akademy has melted ice cream in the rain) but they're both basically communities made up of people who are interested in developing a functional and interesting desktop experience. So why do the end results have so little in common?

Then I read this and something that had been floating around in my mind began to solidify. KDE assumes a platform and attempts to work around its shortcomings. Gnome helps define the platform and works on fixing its shortcomings.

It's pretty easy to see this across the platform. The developer of the Gnome Bluetooth support has multiple commits to the underlying Bluetooth stack, while nobody who's committed to bluedevil appears to. The main developer of the Gnome Networkmanager support is Networkmanager upstream, with the same applying to the Gnome power management infrastructure. And when Gnome developers find limitations in graphics drivers, those tend to be fixed in the graphics drivers rather than worked around in the UI code. KDE builds on top of what's already there, while Gnome is happy to flatten some mountains first.

I should emphasise that I'm not criticising KDE here[1]. These are both rational development models. One optimises for making things work and will compromise on functionality in order to be more portable to different underlying operating systems. The other optimises for additional functionality at the cost of being tied to a much smaller number of underlying operating systems that have to be completely up to date. But understanding that this distinction exists is key to understanding fundamental differences between the projects, and any argument about which is better or about how there should be more collaboration has to take these fundamentally different approaches into consideration. My personal belief is that a tightly integrated platform is going to produce a more compelling product in the long run than one built on top a series of abstraction layers, but we'll see what happens in the long run.

And then, of course, there's Unity and Canonical's gradual effort to turn Ubuntu into a platform distinct from either Gnome or KDE. But that's a separate post.

[1] Well, except for the melted ice cream at Akademy 2006. But I think that's fair.


(Read 49 comments) - (Post a new comment)
(Flat) (Top-level comments only)

Meh


(Anonymous)
2011-04-27 06:38 pm UTC (link)
Yeah, like the notification stuff or using broken standards instead of the ones that were accepted by the freedesktop.org, right? this kind of blogpost is bad for Gnome and for KDE. the criticism on the K post that you linked was that a graphics driver broke the BC in a minor release, and you are saying that G's ok with that? come on =/

(Reply to this)  (Thread


Re: Meh


[personal profile] mjg59
2011-04-27 06:50 pm UTC (link)
Freedesktop.org generates specifications, not standards, but I'm guessing you're referring to the Status Notifier specification? It's currently listed under "Specifications currently in the planning/requirements-gathering stages", which seems to be some distance from "accepted by the freedesktop.org". Specifications are useful to define interoperability - they're not sticks to beat projects with, especially if there's rational disagreement between projects on the usefulness of that specification.

But anyway.

The graphics driver changed in a minor release, yes. It changed in a way that should have broken nothing, because nothing should have been trying to identify version-specific bugs by parsing meaningless vendor strings. KDE took the pragmatic approach of doing so because it was the easiest way to work around a bug. Gnome simply asserts that drivers must have a certain level of functionality and works with the X developers to ensure that that's the case. The outcome is that KDE works better with older drivers, while Gnome doesn't get broken by changes like this. Deciding which approach is better depends on what your aims are.

(Reply to this)  (Thread from start)  (Parent)  (Thread


Re: Meh


(Anonymous)
2011-04-27 11:05 pm UTC (link)
You are missing something important on KDE's approach to graphics drivers: drivers lie. On KDE SC 4.5 many people suffered freezes and crashes when drivers claimed support for features they did not actually support. If you cannot trust what the drivers claim via standard API, the only way to have workable desktop is to do ugly hacks like these.

(Reply to this)  (Thread from start)  (Parent)  (Thread


Re: Meh


[personal profile] mjg59
2011-04-27 11:28 pm UTC (link)
No, the alternative is to work with the driver vendors and ensure that the drivers work correctly. This avoids the need for hacks and means there's no chance of unexpected breakage when things change. The downside is that you need to aim at future releases rather than what currently exists, and that may be difficult if release schedules don't line up. But there's still a choice.

(Reply to this)  (Thread from start)  (Parent)  (Thread


Re: Meh


[identity profile] mgraesslin.myopenid.com
2011-04-28 09:33 am UTC (link)
Sorry, but I have to disagree. Of course working with the driver developers is the better choice, but that would not have fixed our problems we had at the release of 4.5. We need to support the drivers our users are using. We had no other option than to workaround - we really evaluated the options and not shipping the features would not have solved our problems, but even more would have taken away features for users on working platforms such as NVIDIA.

If you want to fully understand the situation around 4.5 please read my lengthy mail to the mesa developer list. It is that long as it explains the situation and is required to understand each other which I think is a prerequisite to work together in the end.

(Reply to this)  (Thread from start)  (Parent)  (Thread


Re: Meh


[personal profile] mjg59
2011-04-28 12:44 pm UTC (link)
We need to support the drivers our users are using.

Yes, and that's exactly the difference I'm describing. Gnome's approach is to require working drivers. KDE's is to work with the drivers that exist.

(Reply to this)  (Thread from start)  (Parent)  (Thread


Re: Meh


[identity profile] mgraesslin.myopenid.com
2011-04-28 02:56 pm UTC (link)
No, it isn't. We also require working drivers. When we developed 4.5 the drivers (Mesa 7.6/7.7) were working. When we released 4.5 the drivers (Mesa 7.8) were partially not working. This was completely unknown to us during development and it seems like also for the driver developers. Of course we could have said we need working drivers requiring the distributions to either not upgrade the drivers or to disable features which worked before. Both is unlikely to succeed.

Gnome has so far not been in such a situation with the graphics drivers as they were able to develop Gnome Shell against future driver releases. I wish Gnome to never face such a situation. But really it is not like "we require working drivers and will work with the driver developers", reality might differ from the ideal world. I really think that it is difficult to judge this without having ever been in such a situation and maintaining an OpenGL compositor.

All this "platform thinking" you derive from my decisions, is just a wrong conclusion. We did not have an easy decision on how to handle the situation and in the end decided for an approach we believed as the most suitable for KDE, the drivers and most important our users.

(Reply to this)  (Thread from start)  (Parent)  (Thread


Re: Meh


[personal profile] mjg59
2011-04-28 03:03 pm UTC (link)
You appear to be saying you disagree with me, and then agreeing with me at length.

(Reply to this)  (Thread from start)  (Parent



(Read 49 comments) - (Post a new comment)
(Flat) (Top-level comments only)