| |||||||||||||
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)Posted May 9, 2012 7:51 UTC (Wed) by cabrilo (guest, #72372)Parent article: Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)
As some commentators above noted: fragmentation is just another word for competition, and competition gives us choices, so it's good.
I do, however, think that there are huge flaws in the open source desktop market. The problem is that distributions trust upstream to provide quality software, and upstream is not to be trusted.
I am not sure why the treatment is different for server and development software. E.g. if was not unheard of that distributions would maintain two packages of Apache (e.g. current 1 and current 2), Python or PHP. Many distributions package several kernels even, so you can choose which one you want.
For desktop software, on the other hand, distributions always seem to make the wrong choice. E.g. they introduced KDE 4 before it was ready for prime time. Most new distributions are just following the development cycle of GNOME without thinking about implications to their users. It's not just about GNOME 3, but I remember when GDM (graphical login) was rewritten - many distributions just packaged despite the fact that it was still missing major features and in most cases we had to rely on third party repositories for the old one. Same goes for PulseAudio, etc.
I don't think this is very sustainable. It's OK for cutting edge distros, like Arch Linux or Fedora, but Ubuntu, Mint, Debian, Slackware and others who want to provide anything resembling LTS versions will have to take much more control and responsibility for what they package.
Ubuntu and Mint see this. Ubuntu provides Unity and as much as I dislike it, I am happy that they are doing actual development. From what I understand, Mint is behind MATE, and that's excellent.
To sum it up: distributions need to take responsibility for the software. They need to be able to patch software when needed, but they also need to be able to take over development when upstream goes bananas. This may not be realistic for a single distribution team and huge projects such as KDE and GNOME, but that's why packagers ought to be well connected with the development community and be able to stir things up when they see things are going badly for their distribution.
(Log in to post comments)
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 8:22 UTC (Wed) by niner (subscriber, #26151) [Link]
Maybe that's why I still stick with openSUSE and never got tempted to try something else. When KDE 4 came out, openSUSE just didn't switch. They offered it for those who wanted to try but otherwise stayed with 3.5. Only when KDE 4.3 came out, they switched and it was a good decision. And even afterwards 3.5 was available for users. Same for PulseAudio: they introduced it when it was usable already but still it was (and is AFAIK) completely optional. It's just one command to turn it off or on.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 8:56 UTC (Wed) by ovitters (subscriber, #27950) [Link]
If distributions lag behind upstream, then upstream will have less feedback and development will be slower. You're going against the "release early, release often" basically.
I do see the need for this though. But IMO there should be less difference between distributions and upstream.
e.g. certain distribution thought it was wise to revert some functionality in gnome-control-center 3.4. The result: non-working functionality and bugs reported upstream. Such bugs will be reported upstream and as a result, upstream has to do the development, but also all track all the modifications done by distributions. This slows down development.
You might say that the bug should always be reported to the distribution. But for one that doesn't happen. Furthermore, for development you need the quick feedback. Else, it'll slow down again (or be more buggy).
I also help out packaging, but my interest is helping upstream; not to be a replacement.
I think what you're actually after is more QA. The more people using the software, the more bugs are found.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 11:34 UTC (Wed) by khim (subscriber, #9252) [Link] If distributions lag behind upstream, then upstream will have less feedback and development will be slower. You're going against the "release early, release often" basically. Does it really matter? Developers usually don't want to talk about distro-supplied options anyway, they ask you to test latest version from git. This is where the whole thing falls apart: typical user of server-side software can build and test top-of-the-tree software: server-side software tend to be simpler (or at least more self-contained) and users are more computer-savvy. Typical user of Linux desktop can not do this (many of them are completely lost when they need to use command line, for example). This breaks "release early, release often" cycle completely: feedback from actual users can only be received when it's way too late to change anything.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 20:34 UTC (Wed) by ovitters (subscriber, #27950) [Link]
Testing the latest version from git for GNOME means trying to get jhbuild to work. That is known to be painful. It can be suggested (if you figured out Bugzilla and where to file the bug, you're already an advanced user IMO), but not required.
You raise a few things where "release early, release often" doesn't work. But it is not really an argument not to still follow the "release early, release often".
Simplifying how to be able to try out a release is the goal. There are certain obstacles, some of which are really difficult to solve and might take a lot of time (talking about GNOME software). With time it hopefully becomes easier.
The small progress we're making is already by trying to release a live cd during GNOME unstable releases. Then other work is also underway (ostree). It is somewhat difficult as GNOME often requires changes other parts of the OS. So you cannot just provide a newer "gnome-boxes" without providing a newer "libosinfo" (it might not even be packaged), etc.
The work is done on different levels. GNOME Boxes is a really simple application to try out a live cd. Once that is in distributions, you can provide yet another (not perfect) option to try out the latest software.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 10, 2012 8:53 UTC (Thu) by Company (guest, #57006) [Link]
There's one thing that we as GNOME botched completely, and that is working together with a distro (not distros, _a_ distro). I still see distros as the QA of a desktop effort (while upstream is the R&D part), and GNOME essentially does not have any QA at all. (To open parentheses a third time, this failure is also what lead to the GNOME OS effort - if we can't get distros to cooperate with us, we'll just do our own!)
What I'd have expected to happen long ago is that a distro provides a build farm that compiles per-commit packages that can be installed and used by anyone alongside the regular packages. I'd have expected these packages to work so seamlessly that they make jhbuild completely obsolete.
All the distros do this to some extend, but they all do this in spite of upstreams, not with them. In particular the GNOME vs Ubuntu story is a good example of this. GNOME tries to do QA these days and fails as much as Ubuntu, which tries to develop code on its own. And worse off are all the people who have to use the resulting product(s).
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 10, 2012 14:37 UTC (Thu) by dgm (subscriber, #49227) [Link]
> GNOME tries to do QA these days and fails as much as Ubuntu, which tries to develop code on its own.
I don't get it. How is Ubuntu developing code a problem for GNOME? It doesn't seem to be a problem for XFCE, so why it is for GNOME?
I think that the notion that a distro is QA for upstream is at fault here. A distro should customize and configure, not fix. If they are forced to fix, then as easily they can write their own code. So, upstream needs its own QA. It's not acceptable to ship garbage and expect that users will pick up the pieces. You can ask for help, but if you rely on them giving it to you then you're doing it wrong.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 10, 2012 14:20 UTC (Thu) by dgm (subscriber, #49227) [Link]
> If distributions lag behind upstream, then upstream will have less feedback and development will be slower. You're going against the "release early, release often" basically.
"Release earlym release often" does not match with final users. It's OK for testers and developers, but not for production.
|
|||||||||||||