Weekly Edition
Return to the Announcements page
| |||||||||||||
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation)
In this two
page article on Datamation, Bruce Byfield looks at the history and the
current state of the Linux desktop. From the second page: "In studying this transformation of the Linux desktop, you can easily see possible turning points. What would have happened if the KDE 4.0 release had been delayed until it had more features? If Ubuntu had been more patient about its changes getting into GNOME? If GNOME 3 had been less radical, or user complaints addressed? If some or all of these events had occurred, then maybe GNOME and KDE would have remained as dominant as ever.
However, I doubt it. More likely, other incidents would have caused a similar fragmentation sooner or later, no matter how anyone acted."
(Log in to post comments)
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 8, 2012 19:18 UTC (Tue) by hummassa (subscriber, #307) [Link]
It is my opinion, based on 25+ years experience on the programming field, that fragmentation is both inevitable and Good. Without fragmentation, we would be stuck with the implications of monoculture, wrt security and hindering of inovation.
Programmers push for monoculture, but thankfully each one wants their own culture to prevail. :-D
Must ... Not ... Have ... Choice Posted May 8, 2012 23:52 UTC (Tue) by ldo (subscriber, #40946) [Link]
“Fragmentation” seems to be the new term for “competition” and “choice”. Why is it bad?
Must ... Not ... Have ... Choice Posted May 9, 2012 2:07 UTC (Wed) by Company (guest, #57006) [Link]
Lemme think... Ah, yes, the people that claim the Linux desktop will never get anywhere bcause you need to decide between 25 distros or DEB vs RPM. Oh, and there's the people that claim it's bad if you need to write your apps twice, once for KDE and once for GNOME.
And then there's http://www.islinuxaboutchoice.com/
Must ... Not ... Have ... Choice Posted May 9, 2012 9:44 UTC (Wed) by robert_s (subscriber, #42402) [Link]
"the people that claim the Linux desktop will never get anywhere bcause you need to decide between 25 distros or DEB vs RPM. Oh, and there's the people that claim it's bad if you need to write your apps twice, once for KDE and once for GNOME."
Well these people clearly don't know what they're talking about so I'm not worried.
Must ... Not ... Have ... Choice Posted May 9, 2012 16:57 UTC (Wed) by drag (subscriber, #31333) [Link]
The biggest issue is that right now dealing with dependencies is a huge pain in the ass. There is no formal API that people can depend on. There is no effective documentation or rules that people can learn what to use. A programmer has to depend on guessing, experience, and personal preferences. Sometimes they choose correctly, other times they get burned.
The traditional work around is to have distributions put a lot of manual effort into plotting out dependencies and careful package creation. This makes it easy for end users. Unfortunately this is crippled by the massive amount of duplicate work each distribution must perform combined with the lack of manpower.
Effectively it's people throwing lots of hours and effort to work around technical limitations that people don't want to address in the platform.
The upstream application programmer knows most about the requirements of his application so, ideally, he should be the one building the packages and outlining dependencies. And users should be able to go out and download packages from different sources and be able to use them without fear of breaking their systems. Distributions should still collect packages and present them, also and work with upstream to correct packaging issues and bugs and such.
But all of this requires doing things like establishing 'layers' in the platform, cooperation between distributions, formal set of API requirements, and testing and so on and so forth. Nobody wants to do that, I guess.
Must ... Not ... Have ... Choice Posted May 9, 2012 17:54 UTC (Wed) by jedidiah (guest, #20319) [Link]
> The biggest issue is that right now dealing with dependencies is a huge pain in the ass.
Nonsense. Package management pretty much eliminates that completely. It's not 1998 anymore. Even if I decide to build something from scratch, it's pretty trivial to resolve dependencies with the available tools.
Must ... Not ... Have ... Choice Posted May 9, 2012 19:01 UTC (Wed) by drag (subscriber, #31333) [Link]
> Nonsense. Package management pretty much eliminates that completely.
It's NOT a solved problem. It's barely even addressed by Linux systems.
Because if I want to install a application binary and it's not pre-packaged by a distribution then I still have to go in there and read the documentation , run 'ldd' on the binaries and jump through a bunch of hoops to get anything done.
Must ... Not ... Have ... Choice Posted May 9, 2012 19:53 UTC (Wed) by job (guest, #670) [Link]
The problem with installing third party applications are far wider than that. You might even find that your release doesn't offer the required version of some library, or that it is mutually exclusive with another one (as in, "you may have pulseaudio, but not together with the old version of glibc").
Must ... Not ... Have ... Choice Posted May 9, 2012 20:50 UTC (Wed) by drag (subscriber, #31333) [Link]
Yes it can be very irritating. It's enough of a problem that it's really rare that I will bother installing anything that is not packaged by my distribution (or from repositories made specifically for my distribution) because of the difficulties.
I spent many unfortunate evenings struggling with doing things like trying to use python bindings for Orge3D or something like that. Many hours trying to figure out the magic combination of compile options and dependencies. Many dependencies needed to be compiled and copied to the system. What made it terrible was that I was just trying to learn this stuff.. I had no idea what to expect when it worked so I had no idea if what I was doing was correct. When a test failed, was it because I did something wrong or was it just because it is using something that isn't supported yet?
Meanwhile if I was using Windows XP I could of had everything installed and running correctly with about 15 minutes of effort.
It was maddening that open source software developed by people who believed in open source software most of whom used and programed in Linux... was pretty much unusable in Linux, but trivial to use in closed source operating systems.
I saw this again and again and again. Mostly with games or game libraries and such, but it is very common problem with all software on Linux.
It's a bit amazing to me that people in the community can easily see the wisdom of having a strong Linux API/ABI for userspace and can see the wisdom of having POSIX and adhering to standards and whatnot... but totally balk at the idea that Linux desktop should need anything higher level then that. That all problems can be solved by distribution using brute force labor to conform software to their very specific implementation decisions.
Must ... Not ... Have ... Choice Posted May 10, 2012 7:10 UTC (Thu) by ssmith32 (subscriber, #72404) [Link]
> Meanwhile if I was using Windows XP I could of had everything installed and running correctly with about 15 minutes of effort.
That's not Linux, that's Ogre3D: they have packaged their library for windows, but not for Linux.
Which it not surprising, given the Ogre3D community has a strong windows preference. Which again is not surprising, given the gaming community has one as well.
And, yes, I have used Ogre3D on Linux - it wasn't so bad, but it does come with a strong windows community around it, and not a Linux one.
I've actually had the opposite problem: I just wanted to play a song at a certain time in the morning: since the tools needed (mpg123 and crontab) are trivially available on linux, it took only a few minutes there. On windows it took HOURS of searching around (no I'm not downloading random spyware junk from download.com) on the microsoft site, downloading a WGA application, having it break, fixing it, finding an alarm clock program, fixing it...
So it's not really a "linux" problem: just a problem with the software you want to use. It could go either way.
[OT] windows task scheduler Posted May 10, 2012 9:51 UTC (Thu) by cortana (subscriber, #24596) [Link]
Out of interest, what was wrong with using the Windows Task Scheduler to open the MP3 file at the desired time?
[OT] windows task scheduler Posted May 10, 2012 19:46 UTC (Thu) by JanC_ (guest, #34940) [Link]
I suppose what is "easy" largely depends on what you are used to... ;)
But even better: Windows includes an "at" commandline tool to schedule this (if one prefers that over a GUI).
Must ... Not ... Have ... Choice Posted May 10, 2012 7:02 UTC (Thu) by ssmith32 (subscriber, #72404) [Link]
I wouldn't say "barely" addressed.
If you want to install an application binary that hasn't been packaged, that's like wanting to run an executable for some large application in windows without an installer, or a random Mac binary that hasn't been packaged up.
So you'd have the same problem on all platforms, not just Linux.
Essentially, wanting to run an executable file the has dependencies and hasn't been packaged in some way, and expecting it to "just work" is just silly on any platform.
Must ... Not ... Have ... Choice Posted May 10, 2012 9:46 UTC (Thu) by cortana (subscriber, #24596) [Link]
The two are not equivalent. As a developer, if I want to "package" my application for Windows I can do *one* lot of work to create an MSI that any user can run to install my program on any supported version of Windows.
I cannot do this for Linux; I have to build the program on a Debian system to create a Debian package and just hope that Debian-derived distributions don't stray far enough from the latest Debian stable release to break my package; I have to create a separate RPM for Red Hat, Fedora, Mandriva, OpenSUSE, etc. Slackware users are out in the cold unless they don't mind extracting the contents of the deb and installing the libraries that it requires themselves. :)
Must ... Not ... Have ... Choice Posted May 10, 2012 11:38 UTC (Thu) by ean5533 (subscriber, #69480) [Link]
>>Slackware users are out in the cold unless they don't mind extracting the contents of the deb and installing the libraries that it requires themselves. :)
Yeah, but let's be honest: for a Slackware user, extracting a deb is like opening a Christmas present. They really don't mind.
Must ... Not ... Have ... Choice Posted May 14, 2012 2:19 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
or they just use alien to convert the package
Must ... Not ... Have ... Choice Posted May 10, 2012 13:48 UTC (Thu) by smokeing (guest, #53685) [Link]
If I, a developer, want my application reach interested users, I find package maintainers for it, or become one. Debian folks have gone to great lengths making it as simple as possible (but not simpler than that).
No sane Linux user will want anything that hasn't been properly examined, passed QA wrt all dependencies, and packaged by someone competent.
If you want something that's not in your distro, maybe your choice of distro is suboptimal. If you can't find it in any current distro, either you or program author are doing it wrong. Distribution tier exist for a reason.
Gentoo people have a very disparaging word for it: slackwarization. Also, no bug reports will be looked at if your kernel is tainted (notably by nvidia drivers).
Must ... Not ... Have ... Choice Posted May 10, 2012 14:10 UTC (Thu) by cortana (subscriber, #24596) [Link]
And that strategy works fine if you are producing (1) free software (2) that does not need to be kept up to date.
In the real world people need to sell proprietary software for a living, and the lack of a decent way to package that up for end users to buy, install and use, has kept Linux on the desktop back all these years.
Must ... Not ... Have ... Choice Posted May 10, 2012 17:31 UTC (Thu) by pboddie (subscriber, #50784) [Link]
And why is that? For years, all we heard from Miguel de Icaza and the GNOME top table was "ISV, ISV, ISV!" We also heard it from other projects who favoured inferior permissive or weak-copyleft libraries to superior copyleft libraries (I'm thinking of OSAF's Chandler product) because of all the ISVs who would be building proprietary software on their work.
So why didn't all those people championing this lucrative ISV ecosystem get something done to make packaging and deployment easier? It's not as if those people had no skills, influence or money to do the work.
Must ... Not ... Have ... Choice Posted May 10, 2012 22:00 UTC (Thu) by smokeing (guest, #53685) [Link] works fine if you are producing (1) free software In point of fact, this is precisely what I am busy with: produce free software (johnhommer.com/academic/code/aghermann). And so also do countless people small and large, for the common good. (2) that does not need to be kept up to date Maintainers will do it, for some considerable time even after upstream goes AWOL. If there is a sustained demand, they will try really hard; eventually it will be adopted, or someone forks/starts from scratch an alternative, better package serving the same purpose (the story with stow/xstow comes to mind). If in all appearances, a project dies and no one seems to care, then perhaps the purpose is no longer valid, or has never been in the first place (think sundry 'ext2 defragmenters' of around 2000). In the real world people need to sell proprietary software I do programming full time for a living. The single big product we do, has one big university for a single customer, such that we not so much sell the *product* as, rather, sell our time and expertise to please this single customer. Barring idiocyncrasies of certain middlemen in my case, this model works remarkably well. You seem to advocate the proprietary, closed-source model instead. Why do it here? I give you some people do closed source, some even meet with success (Angry Birds?). I, for one, in this same real world, don't, neither in my capacity as user nor as a developer, and I don't feel obliged to accommodate the (inferior) alternative. the lack of a decent way to package that up for end users to buy, install and use Skype is shipped as a deb file in two flavours, statically linked with Qt and standalone. Just don't tell me it's hard to install a deb. The essential problem, again, is this is not distribution done right. has kept Linux on the desktop back all these years I smell slashdot here, thank you.
Must ... Not ... Have ... Choice Posted May 11, 2012 8:21 UTC (Fri) by jschrod (subscriber, #1646) [Link]
Or you can get an openSUSE Build Service account and let OBS do it for you. It will produce packages from the same source not only for openSUSE, but for Fedora, Debian, Ubuntu, and other distributions, too, see http://en.opensuse.org/openSUSE:Build_Service_supported_b...
OBS is one of the most under-reported good services in FOSS land ever.
Must ... Not ... Have ... Choice Posted May 9, 2012 20:21 UTC (Wed) by ovitters (subscriber, #27950) [Link]
Try packaging GNOME boxes. The dependency adding is all manual.
I packaged it for Mageia. Noticed missing dependencies because I looked at the proposed Fedora spec file. However, even the Fedora spec file missed some dependencies.
The GNOME boxes maintainers knew about these dependencies of course. But only some is automatically generated.
Must ... Not ... Have ... Choice Posted May 9, 2012 17:51 UTC (Wed) by jedidiah (guest, #20319) [Link]
If not for "fragmentation" we would all be stuck with some gawd awful CDE desktop. Some of the early X interfaces were truely hideous and it's a good and great thing that someone else was able to step up and offer alternatives.
Must ... Not ... Have ... Choice Posted May 9, 2012 9:57 UTC (Wed) by nhippi (subscriber, #34640) [Link]
1) because having one good implementation is better than having multiple implementations of varying quality.
One implementation gets many eyes reviewing, testing and writing documentation. With many implementations this works gets scattered around.
People just google "best email server for linux", seing a forum post from 2004 where second answer suggests qmail or sendmail. Good luck newbie!
Meanwhile, someone who wants to make linux fileserver for windows machines will only find leads to samba.
3) when each of the layer allows multiple choices, the amount of permutations gets rather extreme, many of the combinations being untested and thus potentially unworking.
Fragmentation orients from the fact that it is often more satisfying to write your own NIH solution instead of collaborating with others as a team.
Must ... Not ... Have ... Choice Posted May 9, 2012 10:24 UTC (Wed) by ldo (subscriber, #40946) [Link]
Because central planning is better than leaving it to free competition...
Must ... Not ... Have ... Choice Posted May 9, 2012 10:35 UTC (Wed) by slashdot (guest, #22014) [Link]
Yes, if the central planner has the best possible plan.
The whole point of open source software is that anyone can submit patches and ideas, and thus the plan gets corrected to be the best possible (assuming the maintainers are open to them).
Or you can also see it as competition on small patches and ideas, which is much more efficient than competition on whole implementations, which requires a ton of wasted work.
Again, the whole point of open source is that this model is more efficient than a traditional proprietary free market, as long as there is something that motivates people to contribute despite the inability to sell the software (such as need to use personally, or need to have good software to sell hardware or services).
Must ... Not ... Have ... Choice Posted May 9, 2012 11:12 UTC (Wed) by spaetz (subscriber, #32870) [Link]
> 1) because having one good implementation is better than having multiple implementations of varying quality.
Ahh, that is why Linus started to contribute to the BSDs in 1991 rather than founding a new competing offspring, I see :-)
> 2) because most users are unable to make fact-based decisions between the choices and just end up choosing based on anecdotal hearsay.
You'll be happy to hear then that they mostly have no choice anyway when buying a new computer. Problem solved.
> People just google "best email server for linux", seing a forum post from 2004
If this is your best approach to fact-based decision making, I am happy that you are not making fact-based decisions for me :)
> Meanwhile, someone who wants to make linux fileserver for windows machines will only find leads to samba.
And they should be using alternatives (if there are any?) exactly why? Remember we should all help to improve the "one true codebase" rather than exploring alternatives according to you.
People do have different preferences and use cases. Emacs works great for me, but I don't think it will necessarily be the best tool for you.
Must ... Not ... Have ... Choice Posted May 9, 2012 11:22 UTC (Wed) by cortana (subscriber, #24596) [Link]
Well, paranoid GPL-haters might choose to use smbx...
Must ... Not ... Have ... Choice Posted May 9, 2012 23:33 UTC (Wed) by jjs (guest, #10315) [Link]
You realize that one reason Linus created his own was that BSD (as in without the lawsuits) didn't exist in 1991?
http://gondwanaland.com/meta/history/interview.html (interview with Linus in 1993):
Meta: What is your opinion of 386BSD?
Linus: Actually, I have never even checked 386BSD out; when I started on Linux it wast available (although Bill Jolitz series on it in Dr. Dobbs Journal had started and were interesting), and when 386BSD finally came out, Linux was already in a state where it was so usable that I never really thought about switching. If 386BSD had been available when I started on Linux, Linux would probably never had happened.
Must ... Not ... Have ... Choice Posted May 10, 2012 5:48 UTC (Thu) by cmccabe (guest, #60281) [Link]
Let's take a look at one of the original newsgroup postings by Linus, announcing Linux.
> I'm doing a (free) operating system (just a hobby, won't be big and
Just the first paragraph mentions two competitors, "gnu" (which would later become Hurd) and Minix, by Andrew Tannenbaum.
Oh nos! Fragmentation! If only Linus had left it to the all-knowing central planning overlords to decide everything.
Must ... Not ... Have ... Choice Posted May 10, 2012 7:57 UTC (Thu) by anselm (subscriber, #2796) [Link] Just the first paragraph mentions two competitors, "gnu" (which would later become Hurd) and Minix, by Andrew Tannenbaum. Let's have a look at those »competitors«:
Must ... Not ... Have ... Choice Posted May 11, 2012 1:04 UTC (Fri) by cmccabe (guest, #60281) [Link]
Linus had a different philosophy than GNU Hurd and Minix. So it was entirely appropriate that he create his own project to express that philosophy.
Similarly, ngnix has a different philosophy than the apache web server (raw speed vs. features). Xfce has a different philosophy than GNOME3. And so on, and so forth. Debian focuses on different goals than Red Hat, or Slackware. Dismissing all of this as undesirable "fragmentation" is just stupid, and that's my whole point.
Must ... Not ... Have ... Choice Posted May 10, 2012 15:58 UTC (Thu) by Corkscrew (subscriber, #65853) [Link] One implementation gets many eyes reviewing, testing and writing documentation. With many implementations this works gets scattered around. You're assuming the total amount of labour stays constant. My (very vague, unsupported) impression is that labour in open source is proportional to enthusiasm. With the exception of the big prestige projects (Linux kernel, LibreOffice etc), people seem to get most enthusiastic over projects when they feel they're a significant contributor. That's easier in small groups. Having a competitor is also a great boost to productivity, even if the competition is friendly. It keeps people focused very nicely. So, basically, even if there was a central planner of the entire open source ecosystem, I think it would be sensible of them to allow multiple implementations. Finding the level of fragmentation that maximises overall productivity is left as an exercise for the interested reader.
Choice to experiment Posted May 11, 2012 8:16 UTC (Fri) by man_ls (subscriber, #15091) [Link] Also, smaller projects are better for experimentation. The big projects are less likely to try out completely new features, but they can (and often do) copy them from the competition once they have matured.
Must ... Not ... Have ... Choice Posted May 11, 2012 8:53 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> Having a competitor is also a great boost to productivity, even if the competition is friendly. It keeps people focused very nicely.
Actually I think it's better if the competition is friendly. Unfriendly competition leads to obstruction, lock-in wars etc.
> So, basically, even if there was a central planner of the entire open source ecosystem, I think it would be sensible of them to allow multiple implementations. Finding the level of fragmentation that maximises overall productivity is left as an exercise for the interested reader.
That's something that is done in software engineering at times: two (or more) teams get the same spec and implement it independently. This is supposed to test all the ideas that many people could have without them going down in design flamewars, and also to have several different implementation with different bugs in them ;) (As a test of interoperability, among other things.)
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 7:07 UTC (Wed) by cmccabe (guest, #60281) [Link]
Yes, it's normal. Take two aspirin and call me in the morning.
Seriously, though, people need to stop obsessing over "fragmentation" in the open source world. Most infrastructure projects are natural monopolies or oligopolies where a small number of competitors quickly become entrenched, and nobody has the resources or motivation to build something different. On the other hand, in the cases where there are lots of options, it's usually because each of those options offers something different that different groups of people actually want.
For example, you could imagine writing a different version control system than git, or a different web browser library than WebKit, but would it really be worth your time? Once a project gets big enough, the natural laziness of programmers prevents other alternatives from arising unless there's a real need for them. Do we really need to stay awake at night obsessing over the possibility of someone writing another competitor to RPM?
Having two different choices is a small price to pay for motivating people to actually make their project competitive. That is why the U.S. has a two-party system, after all.
In the cases where there are lots of choices, it's usually because users have different opinions about what they want. For example, I've seen lots of posts on this site praising GNOME3, lots of posts praising Xfce, and lots of posts praising KDE. These projects all have different philosophies, and clearly, there is an audience for each.
And no, just because you write a program using KDE or GNOME libraries doesn't make it un-runnable on other desktop environments. So calm down, and just focus on working on the projects you like, rather than trashing other people or railing against the evils of choice.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 7:51 UTC (Wed) by cabrilo (guest, #72372) [Link]
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.
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.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 9:48 UTC (Wed) by slashdot (guest, #22014) [Link]
No, it's not normal, it's caused by the actions of several dickheads who put their own "personal glory" before the advancement of free software overall.
The ideal outcome is one fully configurable implementation, not multiple competing ones that all something well but many other things horribly.
Example success story: the Linux kernel.
Example disaster stories: desktop environments, distributions.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 10:55 UTC (Wed) by nmav (subscriber, #34036) [Link]
> The ideal outcome is one fully configurable implementation, not multiple
> competing ones that all something well but many other things horribly. > Example success story: the Linux kernel.
Actually based on your definition the Linux kernel is an example disaster story. I remember when Linus started his kernel there were several competing kernel projects (386bsd, hurd). Nevertheless, he started his own instead of thinking the advancement of free software as you pose it.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 11:12 UTC (Wed) by slashdot (guest, #22014) [Link]
The problem is not necessarily starting a new project if a full rewrite is needed, but rather the persistence of multiple redundant implementations.
In the case of Linux, it has no competition as an open source kernel.
On the other hand, there's no reason to have multiple packaging standards, yet .rpm and .deb persist with significant market share each.
The fact that the dpkg and RPM maintainers don't get together and kill at least one of them is a true disgrace, and is one of the things that holds back GNU/Linux from being more popular (note that they could always flip a coin if they can't do anything better).
That's just one of the most glaring examples, and there are many others like upstart vs systemd, gtk vs Qt, desktop environments, gecko vs webkit and so on.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 11:55 UTC (Wed) by pboddie (subscriber, #50784) [Link] If you are convinced that RPM and dpkg could be merged into one thing and - here's the important part - support the distribution policies that rest on each of those solutions, then why not share the insights into how it could be done. Herding the maintainers in a room and shouting "Think! Think!" isn't going to do it. I'm not saying that there couldn't be more sharing when it comes to competing solutions, but sharing is indeed the best way to bring projects together, instead of just getting people to abandon their work for something else. The latter approach is doomed to failure because the people who "jump ship" have to be really enthusiastic to work on another project, so you lose any momentum that their work had in their old project as they struggle to apply their work and knowledge to their new environment (and many of them will just give up and do something else, as seems to be the case with the KDE 3 to KDE 4 transition), and you'll always get a bunch of other people taking over that abandoned work, so you'll only end up shouting at a bunch of different people to "Stop doing that, you're killing Linux!" What I think is missing from the Free Software desktop is the stamina to make a complete and coherent environment. Some people might call that attention to detail, but that label has been repurposed by the kind of people who regurgitate commentaries about Apple and who obsess about pixel counts, gradients, button placement, transition effects, and the like. The major environments have emulated Microsoft and Apple without questioning the quality of their inspirational material; poor design originating from Apple, particularly, is waved through because no-one dares to question the "accepted" quality of the work. People need to assess whether the interfaces really do their job, and not just in a number of narrow use-cases that potentially reflect the lifestyles and limited imaginations of the developers, before signing off on them.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 13:48 UTC (Wed) by renox (subscriber, #23785) [Link]
>In the case of Linux, it has no competition as an open source kernel.
False, the FreeBSD kernel has several interesting features that Linux doesn't have (Capsicum for example), so Linux has competition.
That said, I agree with you that I see no advantage of the .rpm and .deb divide and only disadvantages, IMHO this is the result of inertia + the "distribution war".
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 16:39 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
seccomp2, cgroups and LSMs provide similar functionality in Linux.
FreeBSD is not a serious competitor anymore. It's way behind in device support and general functionality.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 19:51 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
> FreeBSD is not a serious competitor anymore.
Are you just referring to desktop usage or in general? I use FreeBSD on my server because jails are a breeze. Is there any work on getting LXC to have anything that makes it as easy to manage them as ezjail-admin does for jails?
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 23:37 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
OpenVZ/Virtuozzo.
It's just that it's not a 'hot item' anymore.
Deb -> Rpm? Posted May 13, 2012 15:34 UTC (Sun) by kleptog (subscriber, #1183) [Link]
If you think the only difference between rpm and deb is the packaging format then you've completely missed the point. What makes Debian great is not its packaging format (which is just an ar file) but the Debian packaging policy.
The policy that ensures that files end up in predictable places. The policy that ensures your package will not be broken randomly by other installed packages. The policy that ensures the each package can be reliably rebuilt by anybody on any system. That they don't clash in user names, program names, port numbers, etc...
It's the policy that allows you to take a system and install tens of thousands of packages and have them ALL work. Simultaneously.
Distributing files was a solved problem long ago (.tar.gz). Today, a .deb is a sign that someone put effort into it. A mark of quality. Changing deb files to look like rpms would be technically feasible but pointless without everyone following the same policy. Rpms have their own policy and unless they align, nothing will go anywhere.
If you don't care about policy, use alien to convert the packages.
Deb -> Rpm? Posted May 14, 2012 1:03 UTC (Mon) by vonbrand (subscriber, #4458) [Link] What you describe is exactly what I see on Fedora (with RPM). And I'm sure SUSE, and Mandriva, and all the other "large" distributions do the same. This is a distribution policy, not something $PKG_FORMAT related at all; I'm quite capable of building an RPM violating any and all (sanity) rules, which on installation will create havoc; and I'm sure somebody with some deb-fu can do the same for Debian. But don't forget that the base rules are distribution rules, installing the files from a Fedora RPM on your Debian system might get you into a lot of pain, and viceversa.
Deb -> Rpm? Posted May 14, 2012 7:58 UTC (Mon) by renox (subscriber, #23785) [Link]
> What makes Debian great is not its packaging format (which is just an ar file) but the Debian packaging policy.
So? Those who want to distribute software must learn both to use a different tool (the LSB has selected RPM) and to respect a policy.
If Debian developpers doesn't care that much about the .deb format why do they stick with it?
Deb -> Rpm? Posted May 14, 2012 13:34 UTC (Mon) by dgm (subscriber, #49227) [Link]
You missed the point. The packaging format difference is not that important when policies do not align. Debian could be using RPM but packages would still be incompatible, possibly creating more confusion.
First you would have to converge policies, then you could unify formants.
Deb -> Rpm? Posted May 14, 2012 14:53 UTC (Mon) by renox (subscriber, #23785) [Link]
You're wrong: there are already this potential issue for the various distributions which use RPM and this isn't a big issue: users select the packages which correspond to their distribution, using a RPM from the wrong distribution can break your distribution.
So the policy issue is a weak excuse for using different tools.
Deb -> Rpm? Posted May 14, 2012 15:53 UTC (Mon) by apoelstra (subscriber, #75205) [Link]
But if "using a RPM from the wrong distribution can break your distribution", why on earth would anyone bother to spend the time and energy switching formats? It would accomplish nothing except make it easier for people to goof up their systems.
Deb -> Rpm? Posted May 14, 2012 16:41 UTC (Mon) by renox (subscriber, #23785) [Link]
A basic tenant of good design is separation of policy and mechanism(s).
The mechanisms here are the packaging tools and format used. The policy is the distribution policy on how to create the package using the tools.
It would allow the packager to learn only one set of packaging tools.
As for the users, as I already said, there is no new issue: you can already have a lot a problem if you force the installation of a Suse RPM on a Mandriva distribution for example or if you jump in the stairs, the answer is easy: don't do that.
Deb -> Rpm? Posted May 14, 2012 16:11 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
RPM is also missing a few features that DEB supports, specifically the multiple levels of dependencies (required, recommended, suggested)
personally, I also like the control directory with it's different files for different purposes rather than having everything mashed together into one spec file.
Deb -> Rpm? Posted May 14, 2012 16:43 UTC (Mon) by renox (subscriber, #23785) [Link]
> RPM is also missing a few features that DEB supports, specifically the multiple levels of dependencies (required, recommended, suggested)
Well, it doesn't seem too hard to add this feature to RPM, no?
Deb -> Rpm? Posted May 14, 2012 18:23 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
no it wouldn't, it also wouldn't be that hard to switch a distro to use .deb instead of .rpm either.
Another feature that .deb supports is the multilib capability (as opposed to the /lib /lib32 approach)
the RPM folks are welcome to implement these features (as they have copied other features from .deb, resulting in things like yum in the past), but since they haven't, it precludes rpm from being the 'universal' packaging tool that some people want it to be.
And this completely ignores other possible packaging tools and requirements that source-based distros like gentoo have
Deb -> Rpm? Posted May 14, 2012 18:48 UTC (Mon) by boudewijn (subscriber, #14185) [Link]
And as long as deb fans will ask rpm fans to convert, and rpm fans ask deb fans to convert, people like me will have to continue to try to build tarballs that, together with some scripts, provide something that nearly works on every system but doesn't integrate and contains way too much junk.
I hate creating debs, I hate creating rpms, I hate creating tarballs or bitrock installers -- but most of all I hate having to do essentially the same job twice.
I don't give a damn about the package format, not as a Linux user, not as a software developer. Rpm and deb both just work, and I just don't like the fact that there are two of them, and that people actually can bring up the enthusiasm to defend one against the other.
Deb -> Rpm? Posted May 14, 2012 19:25 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
so you need to use tools that build both for you without you having to do either one manually.
I understand that the Suse buildforge does this for you, and I believe that the code to do this is available.
plus there is the alien program that will take a .deb and convert it to a .rpm (and vice-versa)
so the cost of creating both formats (if you don't care about the distro specific policies) looks like one line in a build script. hardly a crushing load.
Deb -> Rpm? Posted May 14, 2012 17:00 UTC (Mon) by dgm (subscriber, #49227) [Link]
> You're wrong
More often than I would admit, yes.
> So the policy issue is a weak excuse for using different tools.
No. It's an excuse for avoid _changing_ tools. Big difference.
BUT what would really solve droping dpkg? Imagine if you wish that tomorrow Debian ditches the .deb format and converts overnight to RPM. Now what? Packagers still would have to make different packages for Debian (and maybe Ubuntu), SuSE, Fedora, RedHat, Mageia, etc. It's even worse, because ISVs have to package for every _release_ of the distro they target. What do have we won? Nothing. Maybe that is the reason it hasn't happened yet. Will it happen in the future? I doubt it. Look at SuSE: same RPM, just different. The tendency is to fragmentation, not convergence, in RPM land. There are even 2 different forks of the RPM format.
So, at the end of the day, the package format is not that important. And probably that's the reason why we haven't seen unification even after so many years of pushing in that direction.
Deb -> Rpm? Posted May 14, 2012 17:18 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Sure, switching Debian to RPM wouldn't cause world peace overnight but it would remove a significant technical barrier to cross-distribution coordination of packaging guidelines. I think there'd be a lot more societal/peer pressure to standardize packaging guidelines once there were no technical barriers to doing so. ISV pressure would be more effective in this case as well.
Deb -> Rpm? Posted May 14, 2012 17:19 UTC (Mon) by renox (subscriber, #23785) [Link]
>> So the policy issue is a weak excuse for using different tools.
>No. It's an excuse for avoid _changing_ tools. Big difference.
Sure this adds some work to Debian in the short term for the migration and less work for every ISV after the change because now they have to only learn one set of tool instead of two.
> It's even worse, because ISVs have to package for every _release_ of the distro they target.
Same situation as today then.
> What do have we won?
As already said, it makes ISV lives simpler as they can now use only one set of tools instead of two.
> The tendency is to fragmentation, not convergence,
Yes, I've noticed, Linux: ~1.5% of desktop share.
Deb -> Rpm? Posted May 15, 2012 9:02 UTC (Tue) by dgm (subscriber, #49227) [Link]
> Yes, I've noticed, Linux: ~1.5% of desktop share.
Non sequitur. As easily I could say: Linux: ZERO viruses in the wild.
So what?
Deb -> Rpm? Posted May 15, 2012 9:19 UTC (Tue) by renox (subscriber, #23785) [Link]
>> Yes, I've noticed, Linux: ~1.5% of desktop share.
> Non sequitur. As easily I could say: Linux: ZERO viruses in the wild.
Well, not really 'non sequitur': making the life hard for ISV surely don't help Linux's market share, but I agree that the packaging format is not enough, but it would be a start (not that I believe that it can happen: for whatever reason packaging tools seems to be a topic that triggers emotional reaction..).
As for ZERO viruses in the wild, Haiku has no virus too: nobody cares about it..
Deb -> Rpm? Posted May 15, 2012 15:58 UTC (Tue) by dgm (subscriber, #49227) [Link]
But Haiku doesn't seem to have millions of users (it didn't last time I looked, correct me if I'm wrong).
As for ISV's lifes: packaging format is the _least_ of their problems, really. It's something that just requires installing a few tools and can be greatly automated. The real problems are supporting the horde of Linux versions out there -each with it's own library versions, configuration files and general idiosyncrasies- and, of course, getting Linux users to pay for software...
Deb -> Rpm? Posted May 20, 2012 0:55 UTC (Sun) by steffen780 (guest, #68142) [Link]
And package format is one of those idiosyncrasies. If conversion is trivial to automate as some people claim, why not do it? It's one (small) issue less. That's how progress generally happens in software, especially free software - one small issue at a time. Unite .deb and .rpm since the differences are cosmetic, then go onto the next one. Why not? Distro policies and library versions will still differ, of course, but there are real reasons for that. Fedora has newer library versions than RHEL for a reason. I cannot see why Fedora and Debian have to use different formats for packaging.
As for your [citation needed] claim that Linux users don't pay for software, have a look at RH's balance sheets or the humble indie games bundle - RH covers the enterprise market, whilst the games bundle covers the private (well, presumably it is mostly private) desktop end users. And guess what? Linux end users (those that bought the humble bundle at least) pay MORE than Windows or OSX users. Maybe because they aren't being ripped off ridiculously by Microsoft on the Windows license or by Apple's simply obscene prices for hardware? Maybe they're better people? Maybe they just wanted to put an end to claims like yours? Maybe they just have more money? Who knows, fact is, Linux users do pay, generously - even when they don't have to.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 11:32 UTC (Wed) by ovitters (subscriber, #27950) [Link]
"Dickheads", "personal glory" ?
It is really obvious you believe in what you think. However, the way you phrase things makes me think not much more than "meh, troll, go away". Please tone it down a little.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 12:26 UTC (Wed) by slashdot (guest, #22014) [Link]
That's an interesting proposal, but after careful examination it seems to me that it would reduce the intensity of the flamewars produced, and thus diminish the amusement derived from the whole thing, which is clearly an undesirable outcome.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 16:48 UTC (Wed) by ean5533 (subscriber, #69480) [Link]
You readily admit that you like to start flamewars for the sake of your own enjoyment -- the very definition of a troll.
You're being added to my filter list. I encourage others to do the same.
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 13, 2012 16:43 UTC (Sun) by viro (subscriber, #7872) [Link]
> However, the way you phrase things makes me think not much more than "meh, troll, go away".
And the username alone doesn't? Might as well have been "National Enquirer" or any other supermarket tabloid...
Fragmentation on the Linux Desktop (Is it Normal?) (Datamation) Posted May 9, 2012 18:09 UTC (Wed) by pyellman (guest, #4997) [Link]
The problem isn't confined just to Linux Desktops.
Here in my midsize town, the local soccer club fields travel teams that have to play against teams from significantly larger communities. Unfortunately, our teams are often at a significant disadvantage in that the other teams just seem to have better athletes, to put it bluntly.
I've concluded that we could field competitive teams if it were not for the fact that many of the best athletes are drawn away by other sports, particularly lacrosse, which is quite popular in this town. If lacrosse were removed as an option, I'm confident many of those players would take up soccer, and our teams would match up against the "big boys".
So I would fully support some kind of "benevolent dictator", who would determine what is the "best" sport for the community to support, as long as that dictator agreed with me.
|
|||||||||||||