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."

Comments

Potayto potahto

[$RANDOMLUSER]

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.

Re:Potayto potahto

[Burz]

And all of that work should be done by the application authors, not people who work on the OS who don't know what they are doing. I repeat: Ability to work on an operating system doesn't mean you know squat about sanely-coded and presented applications.

This dynamic is why Firefox on FOSS systems is slow and feature-poor: A party that can't possibly take responsibility for all the apps being offered is inserting themselves between the application users and the authors, degrading what is otherwise a top-notch effort (Firefox).

Think about that the next time radio buttons disappear after selecting (only on Linux Firefox for years), self-update keeps prompting when it couldn't even work, users are urged to "get the latest!" while they are forced to wait weeks (or forever) after their Mac and PC colleagues have upgraded, and when you click on a link and get prompted to "select application" to open with... and the dialog doesn't show applications but the Unix filesystem instead.

Self-updating applications is an application feature, not an OS feature. People need approachable ways to install new and updated apps on OSes that are older than a few months! No one should be forced to the bleeding edge of OS releases every 6 months just to upgrade their apps.

It all speaks of an OS that isn't feature-stable enough to give app developers a chance to properly target and integrate with the system. This problem of poor testing and integration arising from poor targetability is repeated over the whole spectrum of available applications.

Stop releasing every 6 months and get the distro managers out of the applications.

PS- I would also like to state what a POS the Slashdot editor has become.

Re:Potayto potahto

[Kjella]

Distro/package maintainers tend to be the only thing keeping Linux sane with the endless dependencies on libraries that again rely on other libraries with turtles all the way down. It's might work poorly for the five applications that are basically big enough to roll their own framework but for all the Gnome/KDE apps that would be just terrible.

I don't know why firefox is bugging me but my guess it's because the developers are lazy... there's a little perl app called apt-show-versions:

kjella@kjella-desktop:~$ apt-show-versions firefox
firefox/jaunty-security uptodate 3.0.11+build2+nobinonly-0ubuntu0.9.04.1

See that? It is up to date, and stop bloody bugging me about it. I'm sure the same could be done with an #ifdef LINUX and a few lines in C if anyone would bother, it doesn't even take a sudo. Do you know that when I go in Opera, right-click a file in the transfer window I do get a list of my Linux applications to open it with? They got sub-percent market share and do it right, but Firefox can't be arsed to do it. Why should I think it's the maintainer's fault when the developers can't be arsed to do the things they can do? Face it, Linux is maybe 5% of the total Firefox userbase now and we're getting the same shit we are with closed source apps.

Re:What's Firefox?

[Anonymous Coward]

Who says she wants to marry you? This is Slashdot, nobody gets married.

He fails to see....

[Darkness404]

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.

Re:He fails to see....

[xlotlu]

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.

I run Debian testing. It's very much a rolling release, and you're somewhat protected against obvious bugs by the nice policy. Of course, you can get more rolling than that and go full unstable. And throw in some experimental if you're feeling brave.

The nice thing is you can mix-and-match. Most of my packages are testing, some are unstable, and right now i have a touch of experimental. With some APT pinning, you get a rolling release where you can decide per-package how bleeding edge you want to be.

This is my laptop/desktop. For servers I mostly stick to stable, and if i really need a newer package I can pin it from testing, or look for it on backports.org.

Re:What's Firefox?

[Anonymous Coward]

Close, but no cigar. Marriage and sex are two different things.

Obsolete vs Stable

[Anonymous Coward]

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.

Distributing is not easy, anyway!

[VincenzoRomano]

Balancing conservative and progressive approaches in ditributions is not as easy task at all.
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 ...). 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!

Re:fair comparison ?

[Kjella]

Who wants fair? There was plenty missing here, for example RHEL, SLES, Ubuntu LTS and Debian are probably in the same class but only Debian was in the survey. This was more like a sample with a spread, showing the spread between bleeding edge distros and stable distros. That said, my impression is that they picked a very round-about way of figuring out the age. Ubuntu has a release every six months, so the average age is close to 6mo/2 = ~13 weeks. Debian has 18 months, so 18mo/2 = ~39 weeks. Unless you're doing significant amounts of backporting that won't change and the number of releases behind will be a fairly linear equation with time. There's some better metrics to pull out here like "How bleeding edge are they when released" but I don't see him doing any of that.

Re:Similar with Ubuntu LTS

[jedidiah]

Are you kidding? Are you confusing Debian and Ubuntu?

Installing the newer Firefox (3.5) from repositories was not a problem.

Installing the newer Firefox was also not a problem from the tarball (just untar and run).

Stuff like "backports" are a part of the standard set of repositories.

Using discrete packages is also pretty easy (skype) as are discrete installers (penumbra,vmware,oracle,word perfect).

The WHOLE POINT of debian (and children) is the fact that dependencies are automatically dealt with.

apt-get even makes resolving dependencies at compile time fairly trivial. Nevermind binary packages.