Slashdot Mirror
Linux Distributions' Tracking of Upstream Projects Examined
An anonymous reader writes "Linux distributions track upstream projects, releasing a particular version with each official release. But how far behind the latest versions do these releases linger? Scott Shawcroft did an interesting new study into this relationship between distributions and upstream projects. Shawcroft says: 'Over the last 10 months I've been working on Linux evolution research. Similar to distrowatch, I track the current versions of packages in a number of distributions and the current upstream version. Based on that data I then graph a number of metrics to understand the relationship between upstream and downstream.' His presentation on the topic scheduled for [this] week's open source convention, OSCON, should provide an interesting insight into that relationship. Currently he is tracking 20 projects including the Linux kernel, Firefox, GCC, OpenSSH and GNOME on Arch, Debian, Fedora, Gentoo, openSUSE, Sabayon, Slackware, and Ubuntu."
I run Debian you insensitive clod!
In Debian, all software in the repositories is frozen when a release is cut (e.g. Lenny). Only security updates are applied. If the author is going for accuracy, he should track Debian Testing, which gets updated frequently with new releases of various packages. The name "testing" is somewhat misleading. Packages in testing are considered stable enough for everyday use. The stable branch is intended to minimize updates, which is what you'd want for servers.
Labeling the column "%Obsolete" is one way to look at it, sure. Or we could go with 1/X and call it "%NotBleedingEdge". Seriously, the distro maintainers are also looking at their own build packages, compatibility with other packages, internal documentation, etc. Just because the KOffice team (for example) decides to lose monolithic builds and go with package builds, doesn't mean that it doesn't make a hell of a lot of work for the downstream maintainers, and that only starts after the upstream guys release.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
I am not sure if it is fair to compare Ubuntu Jaunty with Fedora, IIRC RHEL is a stable release so is Ubuntu Jaunty, and fedora is more like a dev release that tracks upstream closely. Similarly, Ubuntu Karmic is the dev version that tracks upstream closely before a stable cut of it is released. So probably comparing fedora to Ubuntu Karmic is a fair comparison.
He fails to see that even the upgrading of a simple component like a library can cause all sorts of dependency issues. Not to mention that most distros follow a pattern of release, security updates, release where during the release is the only main changes in packages. This makes it a whole lot easier for maintainers to make sure nothing breaks.
Its no surprise that Arch makes it to the top being a rolling distro, that is, one that doesn't have "releases" like Ubuntu, Debian, etc. but rather upgrades the packages as it goes along. Similarly, Fedora and Ubuntu tend to release pretty often, Ubuntu releases every 6 months and Fedora releases pretty fast. Gentoo/Funtoo are very similar to Arch. Sabyon, Slackware, Debian and SuSE don't release new versions very often. I also find it odd that they are testing Debian stable rather than testing or unstable.
Taxation is legalized theft, no more, no less.
Tracking the projects is one thing. Testing and integration by the top-level distributions can take some time, and it'd defeat the purpose of using them if they didn't take the time to smooth out bumps of using a bunch of different packages together.
To me, a more interesting question is how far behind do the second and third tier distributions that source from Arch, Red Hat, Fedora, Mandriva, Debian, OpenSuse, Ubuntu, Slackware, and Puppy lag behind? Obviously with Yellow Dog, White Box, CentOS, PCLinux OS, MEPIS, NimbleX, ZenWalk, etc out there being based on other distros, some questions arise.
Some distros (notably Slackware, Mandriva, and Sabayon themselves) went from being based on other distros and started at some point doing the package integrations themselves. Which ones still wait for a stable version of another distro and start customizing it before they release? Their packages are often far behind those of the distros upon which they are built. Ones that update direct from the included projects have a huge head start on usability, features, and security updates over distros that depend on the work of another distro upstream.
Tracking the integration time of the first-tier distros answers some important questions, but with the huge number of distros out there depending on those, perhaps the more important questions will have to wait for another study.
I'd be more interested in seeing the statistics for older versions of distributions to see which age best, because I've been running into this problem with Ubuntu Hardy (8.04 LTS) for months now. I don't have the time or the inclination to upgrade my OS every 6 months, but even the LTS release of Ubuntu doesn't get major version upgrades for some packages I end up using a lot. PulseAudio hasn't been updated from the March 2008 version (0.9.10), which likes to crash randomly several times a week. Pidgin. Gimp. Amarok. All have very stable, very mature releases that are at least one major version beyond what's available. Now that I finally have some time I'm in the process of moving my Ubuntu box over to Arch primarily because it does rolling releases. It's going to be more of a pain to set up and keep running, but it's going to be a lot better than having to manually upgrade operating systems every six months to be able to run software that's been around for more than a year.
Yep. They do that.
I was running a version of a big commercial DB on Fedora 11. The latest set of updates mean that the DB won't start. Sigh. That is just one of the perils of bleeding edge distro.
The Same DB runs fine on RHEL/CentOS and even Debian Lenny if I could be bothered to install it.
I personally dislike the Arch release methodology. I prefer fixed releases. Sorta like a stake in the ground, a reference point from which you can build upon.
I have yet to have problems with patches breaking things like Oracle or DB2 on RHEL but maybe I'm lucky but that is really the way it should be.
The comparison in the article is on how quickly the most recent upstream version is incorporated into the distro. As a user I care more about whether bug fixes and new features are incorporated, regardless of upstream version. For example, RHEL may backport new features or drivers into old kernels. Or Fedora may incorporate a bug fix into their perl release without replacing the entire Perl source code. I imagine that other distros do this as well.
Intron: the portion of DNA which expresses nothing useful.
Maybe it's because I'm coming from the Windows world, but since I started using Ubuntu full-time for a year now, the package management and method of keeping software update has been one of my biggest complaints.
.deb file I can install. Getdeb may work, too, but I've had mixed luck with that. Lots of apps have update-checkers built in, but they don't work unless I run the app as superuser. Most of these apps that I use regularly are point releases behind in the repos, and so I'm stuck having to manually muck around with things, or settle with using old software at home when I'm on the newest release at work in Windows.
Don't get me wrong, I *do* like the general idea of package management. It is nice to have the OS take care of keeping everything up to date, and having it Just Work. But there are a handful of software I use every day, (Firefox, Filezilla, Pidgin, Deluge come to mind) that I want to always have the latest released version - and on Ubuntu that is a pain in the ass. Sure, sometimes I can go straight to the website, and there may be a
I don't want to have to compile from source. I don't want to have to periodically run the app as sudo so I can run the included auto-update feature. It's brain dead easy on Windows to try beta software, and uninstall it if it breaks something. What am I missing on Linux?
While the charts are quite nice to look at, they really aren't that meaningful.
.
Ex 1: Debian stable has 95% obsolete packages according to his metrics. For
a rolling release distro that wants to be bleeding edge like eg arch this might
be a bad indication. For a distribution that focuses on stability (like debian
does) this is an (important) design descission. They promise to be rock
solid and they guarantee that no feature changes occur during the support
cycle, and thats exactly what they deliver.
.
Ex 2: Suse is shown to have some 95% outdated packages. What he doesn't
seem to consider is the fact that they do a lot of backporting, especially
in the kde area (kdebase is one of the packages he uses for his analysis).
A Suse version of kde that might seem outdated based on the package
number will probably contain a great number of backported improvements.
.
Another point that I think would be pretty interesting would be security
updates. Not using the latest major release doesn't mean that you don't
have a great security response time (or the other way around). Maybe
he'd be able to track this as well, would be pretty interesting for those
of us who have to rely on stable, tested and secure systems.
.
Anyway, nice thing he started there. If he manages to get some more
metrics this might become a very powerful tool.
Balancing conservative and progressive approaches in ditributions is not as easy task at all. ...). The people who use Linux for fun a hour or two a day have different feelings and needs than those who chose Linux for work 6 to 10 hours a day!
You can jump up a version or two of a package/project (firefox, gcc, kdebase?) and you end up collecting complaints.
You can miss a version upgrade(linux, postgresql, xorg?) and you and up collecting even more complaints.
Whoever talks about "major version bumps" and ".0 versions" is missing the real point: the need to care about features, reliability and effectiveness.
Version numbers and names are just that: numbers and names. A v0.13 of a package can provide better overall results than a v4.2 of a competitor. And the step from 1.2 to 1.3 can provide much more advances than a 8.10 to 9.04!
Distribution managers should thoroughly test in first person the forthcoming releases (alphas, betas, RCs
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
Centos is arguably the biggest used "upstream distro" out there... and it's not even listed!!
What gives?
Bah!
I think labeling gentoo at 75% obsolete is rather crazy. gentoo gives you the choice between the stable, and the latest and greatest, and they can be mixed too. I got the newest kernel just days after it was released, no problem at all.
But Ubuntu doesn't offer many recent app versions (like Firefox 3.5) for an OS that is merely 18 months old. You have to be fairly expert to do the upgrades yourself, downloading and resolving dependencies or finding a source for backports... and both options are often pretty unsatisfactory even to those of us with the know-how (lack of proper testing, subtly botched compiler and integration options, packages that cause headaches on subsequent system updates, etc.).
In the case of upgrading Firefox, you must untar the binaries to somewhere in /bin and then properly re-integrate the plugin directories and other details like DE integration (way, way beyond what an earnest novice will put up with). If you do this for someone else, you'll be left with an app that needs frequent security updates but no way to do them without your personal intervention.
Acknowledging this, the way that 'Linux' has evolved is pretty hostile to desktop applications, even an app as commonly 'tied' to the OS as the web browser.
As I write this, Fedora 11 still does not include Firefox 3.5.1.
Yes, it's in Koji, but grabbing the rpm from Koji goes against the security infrastructure of the Repos.
Yes you can "rpm -Kv " to check the hash against the Firefox from Koji, but I digress.
The fact is, "Average Fedora Users" ( That's another argument for another day ), are still running a version of Firefox with a known security vulnerabilities.
Try ftp://nic.funet.fi/pub/Linux/historical/kernel
Slackware has the slackware-current branch, where everything is upgraded very often and bug reports are accepted in order to vet the next stable release. If there is a security problem, it will be corrected in the stable releases. I'm sure all the other distros have something similar.
Come on. Your proposal leads exactly to the situation in windows, where each app carries with itself a whole little DLL ecosystem around. Sometimes they even tread o one another.
Should be known by now.
Ugh.
There's a problem with Python in there. You shouldn't consider Python 3 as a newer version of Python 2, as it was in LAMPPP. If anything, you should consider Python 2 and Python 3 as separate projects, making it LAMPPPP.
I agree, using "obsolete" is bordering on flamebait. And the meaning of these figures are unclear; at a first guess, I'd think "% obsolete" meant "percentage of programs with a newer upstream version", but then how a figure of 78.94% come about when the sample size is 20 packages? I can't figure out what "Avg # New Rels" means at all, or over what sort of time period.
Installing the newer Firefox (3.5) from repositories was not a problem.
Excuse you, but: .mozilla folder duplicated might not be the best idea, depending on what extensions are being used. Likewise, a user that is uncertain about the tandem Firefoxes might lose data by saving new info in the Firefox profile that doesn't get carried forward.
* Renaming the browser to "Shiretoko" is a problem
* Nor is the icon recognizable to a Firefox user
* Not having it replace 3.0 (and having it run in tandem with 3.0) is a problem
* Pulling in most of the Gnome desktop on a KDE system is a problem
* If you're on a netbook or similarly space-constrained system, having the whole
Installing the newer Firefox was also not a problem from the tarball (just untar and run).
Did you even stop to think about what condition that will leave the browser plugins and file associations?
And what is the user supposed to click on when they untar the upgrade? Who is going to tell them what it is and explain why they lost their icon??
Just stop and look at the broken-ness I've outlined above. These problems are the result of not having a feature-stable platform and I didn't encounter anything like them when upgrading Firefox on Windows and OS X.
Even worse, there is everyone like you in your tiny Linux corner steadfastly glossing over each and every user-hostile pothole on this lovely road that only sysadmins and their grannies ever seem to enjoy.
I might fork OSWS and see what metrics I can add myself. Of course, I only have used ubuntu (couldn't install debian), so I don't know much about how other distros release and stuff... but I have a lot of free time :)