OSNews

The reason why I prefer situations with three or more significant players is, that it fosters in the long haul a better discipline wrt open standards. The recent messy state of freedesktop.org
is imho directly correlated to the fact that the two largest contributers were able to declare "standards" unilaterally, without necessarily reaching consensus and pretty much without consequences outside of the relevant mailing lists, simply because having only two major providers of roughly comparable size imposes not the same penalty for failing to develop and adhere to cross-desktop standards as a system with three or more significant players. (Regarding xdg, there have been, fortunately, some promising signs of activity recently, but the initiative was started by one of the two major projects and not by the churning cauldron below).


(Fires up KRunner to do some conversions: hm 4.5 liters / 100km is about the same amount my car uses. It is not a particular unusual mileage for highway/motorway travels, but given that we Europeans still believe by large that every citizen of the USA drives a small assault tank, it is pretty good :-) )

Regarding the rest of your comment:
Given you recently stated on lwn.net that you manage to keep within 50-100 MByte per user in a shared setup for GNOME 2.x, 768 MByte per session can be considered indeed to be a huge jump.

It will be interesting to see how GNOME 2.30 / 3.0 pans out, because, at least in theory, it should be a lot smoother than the KDE 3.5 -> 4.0 process, because

a.) GNOME gives no guarantees wrt to binary compability and is therefore in the position to move their infrastructure forward in a piecemeal fashion
b.) (related to a.) ) the pressure to have the infrastructure ready before applications are ported seems to be smaller, because the GNOME counterparts to amarok, koffice, kaffeine and k3b are already more or less in sync with the "main" schedule
c.) after years of incremental, bi-anual releases, the schedule is deeply entrenched in the development process
d.)They had ample opportunity to learn from the experiences of the KDE 4 release

A year ago, I would have added that less problems are to be expected because the graphics stack should be in a better state, in part thanks to KDE 4 exposing bugs and inefficiences also in the Xorg server related parts of our infrastructure, but the recent major regressions in the performance department during the 1.5 -> 1.6 xserver transition (esp. in combination with intel cards) and similar experiences (NVIDIA taking ages to fix the memory relocation problem for their binary drivers, etc.) have started me worrying about the short- to midterm stability and quality of our infrastructure.

Edited 2009-08-13 08:01 UTC