On platforms

[mjg59]

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.

Comments

Bad Science?

[(Anonymous)]

I'm by no means saying that your conclusions are incorrect yet to extrapolate so much from a single example is...well...bad science. Are there more cases you might offer that would corroborate your conclusions?

Re: Bad Science?

[mjg59]

Take an infrastructure project (ie, things like bluez, upower, dbus, gstreamer, udisks, networkmanager, X). Look at the number of active KDE developers involved. Now do the same for active Gnome developers. KDE tends to focus on layers like Solid and Phonon, projects that seek to abstract the underlying infrastructure and which make KDE more platform independent. Since Gnome lacks these kinds of layers, Gnome developers tend to work directly on the underlying infrastructure.

Re: Bad Science?

[(Anonymous)]

Another things I have to wonder about... are other differences between the GNOME and the KDE developers. For example, and I'm just guessing here... are most of the GNOME developers who are doing underlying infrastructure commits also Red Hat employees who are more closely linked to the underlying stuff already? My guess would be yes. If true, that is not a criticism of anyone... just another potential explanation.

Also, from their experience with KDE 1, 2, and 3... they used to have some lower level stuff and then they suffered from having trouble maintaining it. I'm thinking here mainly of their soundserver that I can't seem to remember the name of. One of their ideas with 4.0 was that they wanted to abstract more in the underlying KDE libs so that those developing KDE apps would have a stable, unchanging foundation to develop on... and wouldn't have to worry about if the underlying sound system changed or some other underlying piece changed. KDE decided to manage the damage in their abstraction layer... making it easier for the app developers. There seems to be a certain validity to that. With GNOME, if the underlying stuff changes, as if often does, all of those apps have to be fixed. App developers already have the big task of refactoring for widget set changes (gtk2 to gtk3, qt3 to qt4)... why not make something easier for them?

So, my guess is if you asked the designers of the KDE libs why they aren't doing what some of the GNOME devs are, they'd tell you that they learned from previous mistakes. :)

Again, not criticism of anyone... just an unproven set of assumptions and comments! hehe

Scott Dowdle
dowdle@montanalinux.org

Re: Bad Science?

[mjg59]

I think a lot of that's true. Like I said, I'm not trying to criticise KDE here - just give some insight into why the projects make different decisions.

Re: Bad Science?

[misc.id.fedoraproject.org]

The name you seek is arts. ( ex kde sound server ).

Re: Bad Science?

[(Anonymous)]

KDE also runs on more than one operating system. We have these abstraction layers for that very reason, not because we don't want to work with upstream.
ryan rix

Re: Bad Science?

[(Anonymous)]

What platforms does KDE run on that GNOME doesn't? Not many I'd imagine. With Linux having essentially taken over the world now, the future is architecture support, and I wouldn't think there's a lot between KDE and GNOME there either.

- Chris

Re: Bad Science?

[mjg59]

There's ports to Windows and MacOS, at least. I don't know what level of completion they're at, but one of the purposes of Phonon was to allow abstraction of the platform's native media implementation.

(Of course, we've then ended up with phonon implementations for xine, vlc and gstreamer with varying degrees of leakiness in the abstraction. I'm not sure that one's an amazingly strong argument, but people still seem to be using it so I guess they're happy enough)

Meh

[(Anonymous)]

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 =/

Re: Meh

[mjg59]

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.

Re: Meh

[(Anonymous)]

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.

Re: Meh

[mjg59]

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.

Re: Meh

[mgraesslin.myopenid.com]

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.

Re: Meh

[mjg59]

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.

Re: Meh

[mgraesslin.myopenid.com]

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.

Re: Meh

[mjg59]

You appear to be saying you disagree with me, and then agreeing with me at length.

[(Anonymous)]

I'm sceptical that this is a deliberate result of "the GNOME mentality" as it were rather than simply an inevitable outcome of many of the movers and shakers in the modern desktop stack being employed by companies who have chosen to throw their weight behind GNOME, most notably Red Hat / Novell (and Sun before them). Nokia and Trolltech invested in vertical integration on the KDE side of things back in the day.

- Chris Cunningham

[mjg59]

That probably contributes, and I wouldn't deny that the mentality is influenced by the greater degree of corporate involvement. But I see pushback against hacking around infrastructural issues across the Gnome community, to a much stronger extent than I see it in KDE.

[(Anonymous)]

Right, but the point is that if you're employed by a company who are active further down the stack (such as Red Hat) then it's far easier to assume that you can get things changed down there. So if there is an attitude split it's between the "cans" and "cannots" in that sense, in that folk hacking on KDE desktop components don't really have any recourse to pushing things down the stack other than fd.o. So it's a sort of resignation rather than a deliberate bid for abstraction.

- Chris

[mjg59]

I was actively working on components lower down the stack long before I was employed by Red Hat. I'd strongly disagree with any characterisation of it being "cans" and "cannots".

[(Anonymous)]

I wasn't meaning to cast aspersions on you (indeed I'd already replied once or twice before remembering you were a Red Hat employee). However, I'd suggest you're a somewhat atypical example. Most desktop hackers don't dive deep into the stack themselves; the big framework pushes of late have (or at least have the appearance of having) been possible because they've been endorsed by major vendors paying people to accommodate them. If you work for a company who can do that (or hack on a desktop supported by a company that can do that) you're obviously going to be bolder in proposing deeper changes to the stack.

- Chris

[mjg59]

It's certainly the case that it's easier to work on infrastructure if someone's throwing money at you to do so, but you seemed to be implying that it was pretty much impossible if that's not the case. I may be an atypical example, but I'm proof that it's very much possible :)

[(Anonymous)]

Cause and effect? Red Hat presumably hires people *because* they're comfortable with working throughout the stack, not just in the kernel or just in the desktop layer.

platform definition problems

[https://www.community-id.org/identity/fche]

It may be fair to mention one potential (and some would argue "actual") consequences of the gnome approach of "defining the platform" and dragging the lower layers along. That is the problem of overreach: when the platform ideology is far beyond mundane matters such as hardware capability or user expectations.

Re: platform definition problems

[mjg59]

I think the gnome definition of platform effectively stretches down to the kernel now. Some people are going to find that to be overreaching, and others are going to see it as being necessary to produce a competitive desktop.

Re: platform definition problems

[(Anonymous)]

My question is... where are the OEMs in terms of philosphy? I'm not sure OEMs have figured out how to interface with either approach that you are comparing and contrasting. And if the end goal is "competitive desktop/whatever" then these projects need to have some open lines of communication with OEMs so OEM product development culture can figure out how to work _inside_ the project philosophy instead just being _consumers_ of the project labor.

[(Anonymous)]

That could be true about Gnome vs KDE. But when we talk about GTK vs QT, it's a completely different story...GTK is so behind that it's not even funny (most of the "features" in GTK 3.0 are mostly design bugs that QT did right several years ago and GTK people were happy to work around all that time)

[mjg59]

I think that's probably heavily influenced by QT having a significant existence outside of the KDE world, which GTK doesn't really. have you got any idea how much QT development is driven by KDE people, compared to how much KDE development is driven by QT?

[(Anonymous)]

This (http://www.oreillynet.com/onlamp/blog/2005/03/gnome_vs_kde_in_45_words_or_le.html) always springs to my mind every time someone brings up the Gnome vs. KDE subject... :)

[(Anonymous)]

Which is a pretty dumb summary, considering KDE code contains hardly any use of the STL ;).

[(Anonymous)]

I think looking at this problem only from the desktops doesn't look far enough. Every "big" software project has to answer the question about how much time to spend on integration vs just working with the surrounding software. And you will find a lot of projects that do it the "work with" way, such as Mozilla, LibreOffice or Inkscape. And you'd have avoided singling out the KDE developers.

In fact, the "fix shortcomings" approach is a very rare approach and in my opinion it's one of the great success stories of the GNOME community[1]. Though I'm not entirely sure how much of this can be attributed to GNOME and how much of it should be attributed to the corporate sponsors (read: Red Hat).
But I suppose you'd have to think hard to find another project that participates in the development of surrounding software as much as GNOME does. Maybe around the kernel there's a bunch of projects that do?

[1]: another big success story is i10n.

[mjg59]

The apps you name also attempt to be cross-platform, which necessarily has a strong influence on the level of platform work that will be carried out. With respect to other projects: there's some level of equivalence with the infrastructural projects that develop their underlying infrastructure (ie, the kernel) - we typically see X developers doing kernel work as well now, although I'll accept that that's at a somewhat different level.

[(Anonymous)]

I guess the cross-platformness also counts for KDE to some extent (at least for Qt), although I guess it's not as important for them as for the projects I listed.

But I'm not a fan of the cross-platform argument. If you want to be cross-platform, the same argument applies, just that there's more platforms you should cooperate with. (Which then leads to the question of why GNOME only targets/integrates with one platform. But I guess that's a different topic and the answer is the same as the one or Xorg.)

Sponsoring issues

[(Anonymous)]

I fully agree with the point mentioned above. Many times the low-level stuff was done by GNOME people because Red Hat sponsored them for doing exactly that.

[reddragdiva]

Don't forget the influence of "Not Invented Here" and "Not Invented Yet". Mozilla invented its own damn toolkit (XUL) because there was nothing usable and cross-platform, though they later made the Unix backend of XUL just GTK. OpenOffice did much the same, though I suspect more from NIH, given that NIH was an ongoing theme of OOo core development (which is what first led to the Ximian, later Novell, patchset which became the base for LibreOffice).

Ironic

[(Anonymous)]

It's ironic you refer to a post from a KWin developer about KDE not working with upstreams on fixing issues, given that KDE developer Fredrik Höglund has had several patches recently committed to low-level radeon chipset code in Mesa. (Feel free to browse the fd.o cgit for mesa/mesa if you don't believe me). Thiago Macieira contributes to D-Bus. The Okular developers contribute to Poppler.

In addition I know of at least one KDE dev finding difficulty getting patches accepted into Wayland. But it's easier to say you're working with upstream when you *are* the upstream, isn't it? :)

Re: Ironic

[(Anonymous)]

> The Okular developers contribute to Poppler.

The poppler maintainer is a KDE guy, in fact.

[https://www.google.com/accounts/o8/id?id=AItOawmYoHhjrYGWSn_ODG4dQ3ZamGwNcO2dxhQ]

I think this is a pretty fair assessment, though one can only speculate on the actual reasons.

Two things that might have contributed to KDE's choice of handling things.

For one until recently it has been very hard to get changes/improvements/additions into Qt, thus requiring a kind of duplication in KDE libs. If it is hard to influence your most important upstream you might not feel trying with one you are not as connected with.

A second one would be (mostly politically motivated) opposition to choices of technology. E.g. using GObject based libraries in runtime infrastructure such as NetworkManager will not be considered an issue for any KDE frontend, while doing the same on QtCore based libraries can very likely be one on the GNOME side.

[http://openid.fraglimit.net/sorpigal]

A contributing factor might be that a lot of the platform is written in C, not C++. It's easier for a C guy (GNOME) to hack up something else in C than for a C++ guy, who is really a Qt Framework guy, to do the same thing.

Akademy 2006

[jr [launchpad.net]]

Akademy 2006 was in Dublin. I don't remember Matthew being there, nor did we have rain or ice cream. I do remember lots of sun and pizza.

Re: Akademy 2006

[(Anonymous)]

Perhaps mjg is thinking of http://en.opensuse.org/Icecream

Re: Akademy 2006

[mjg59]

I was in Dublin. The ice cream appeared the night at the Pavilion bar in Trinity, and I remember walking through the rain at about 3AM to get back to the hostel.

[(Anonymous)]

Haha nice post, but do not search problems in other DE, when you have enough yours (unity fork of gnome). I hope that you and others gnoms will se that soon enough.

Not quite...

[(Anonymous)]

It seems you may have jumped too quickly to your conclusion. Its not that gnome likes to work with upstream to fix things. Its that they become upstream by creating new system level components. Unfortunately they don't ever seem to get it right. For example: Pulse Audio, was broken for a very long time, Network Manager, also broken on a lot of machines, the NM developers like to claim its the wifi driver's fault that it doesn't work, but really, I had my laptop almost two years before NM started working on it (yet both wicd and straight wpa_supplicant worked just fine), hal was also started in the gnome world, now its been split into all the u* packages.

I don't know if its just that a lot of gnome developers happen to also be major distro contributors, or work at the various commercial distros that make these sorts of decisions, but it seems every time the gnome crowd thinks up a fancy new toy, it gets accepted without a lot of testing or forethought, to the ultimate annoyance and frustration of users everywhere.

Of course the same thing happened with KDE 4, distros jumped the gun way too fast in including 4.0 as the default KDE version. At the time I recall the KDE project saying "DO NOT MAKE 4.0.0 the default" fairly loudly, yet it happened anyhow. And it seems the same thing is happening with Gnome 3, and things like Unity.

Maybe I'm being overly critical, but its just the pattern that seems to be playing out. It's happened over and over, and people just don't seem to be learning from their mistakes. We don't need new stuff just because its new. It should fit a need, and work reliably, then be transitioned to be a core component, not before.

Re: Not quite...

[mjg59]

I think this is entirely consistent. Network Manager assumes that drivers support wireless extensions or conf80211 properly, and a lot of drivers didn't. wicd and wpa_supplicant didn't. Dan spent a significant period of time helping people fix up their drivers such that they actually worked, and now the future is significantly better than it would have otherwise been. A lot of the issues with Pulse were also driver related, and again Lennart helped get those fixed.

Like I said, if you assume that you're targeting a fixed platform then you'll make compromises in order to workaround driver bugs and shortcomings. That gets things working, but can result in issues in the long term. If you assume that you're targeting a "correct" platform and then work on ensuring that correctness, you spend more time with things not working but end up without any of those compromises.

Re: Not quite...

[(Anonymous)]

Pulse is still broken, and it's more than just driver-side -- it's also application-side.

I think the problems here come from trying to do a complete architecture shift, which never works quickly. Basically very little works correctly with Pulse from *either* the driver *or* the application end. I suppose this has to do with none of the users of Pulse understanding the interface they should be programming to, but it makes for a big pain.

That said, KDE managed to make exactly the same mess with Phonon! Apparently you can screw people's desktops with *either* approach.

3D

[gaute.vetsj.com]

But does not GNOME assume 3D?

Re: 3D

[mjg59]

Shell assumes functional texture from pixmap support, which isn't the same thing as assuming hardware 3D. If that's not present then it'll fall back to the Gnome 2-derived UI. However, there's no checking other than that the server asserts that it supports texture from pixmap.

Reasons for KDE vs Gnome

[(Anonymous)]

There does seem to be some truth to what mjg says. I suspect that it mostly derives from two things: first, QT was developed to be more cross-platform than GTK. For a long time, GTK didn't support Win32 well, and its support on OSX is still immature.

Second, much Gnome development, and essentially all GTK development, is done in C, the language of the underlying platform. It's not surprising that someone who prefers C will be more comfortable hacking X than someone who prefers C++ like most KDE hackers.