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.
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.
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]
The point in ubuntu is being always a couple of months late. You probably want to use a more up to date distribution such as debian unstable (note: unstable does not mean will crash after a reboot, just that they may contain bug).
it is also possible to keep a mixed system, that is to say, use mainly debian stable but borrow some packages from unstable. It uses teh preferences options of APT and you can find information on the debian website http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html
BTW, there exist an even more closer to upstream distribution of debian which is called experimental. I would not recommend a non debian developer to use that but it can be useful sometimes.
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.
Then use a different distro that has the flexibility you want. I use Gentoo myself and while most of my system is stable, I have about 70 packages set to use the latest versions of (gcc, the kernel, nvidia drivers, pidgin, etc). It's easy with Gentoo since all of that is compiled against the libraries which exist on your system. On binary distros, there can be incompatibilities between library versions (especially as you start adding more and more unstable packages to the mix), so it's hard to keep just a few packages up to date.
In fact, it was that very problem which originally caused me to drop RedHat Linux back in the late 90s and go to compiling everything from scratch (I then migrated to Gentoo to automate things). And despite the memes, it doesn't take nearly as long to compile everything on modern hardware as some would have you believe. A full rebuild of my system takes about 24 hours (AMD64 X2 4400+, 1002 packages installed), but I do that maybe once a year. It usually amounts to 10-20 minutes a day.
Stop Koolaid Politics
There are PPA repositories for those masochistic enough to want to work with nightly builds. For instance the following repo has nightly builds of Firefox.
deb http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main
It's also possible to add Debian unstable or testing to your repositories, but set the preferred distribution to Jaunty (Package>Preferences>Distribution in synaptic). Then you can selectively install certain packages from unstable.
"Knowledge is the only instrument of production that is not subject to diminishing returns" -Journal of Political Econom
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.
A Pirate and a Puritan look the same on a balance sheet.
It's brain dead easy on Windows to try beta software, and uninstall it if it breaks something. What am I missing on Linux?
/opt
seriously in a worst-case scenario linux package management becomes the same as windows package managment (you install and maintain all versions yourself).
that I want to always have the latest released version
You are on the wrong disto then, /opt and maintaining them yourself (as you would under windows)
If you want the latest version of everything, you definetly want a rolling release distro (sid/arch) of those if you want cutting edge i suggest arch.
If you just want the latest stable version of a few apps, then:
AUR, PPA, (other people compile them and host them, then apt updates them, most distros have these but they are particularly prevevalent on ARCH)
grokk apt/yum and figure out how to safely use package from a cutting edge release (e.g sid/F12) alongside your stable release.
Ideally all projects would host their own cutting-edge/stable repo, however while most of the time the same binary will run across most distros: :(
1) packaging it up and providing the correct metadata for each release is a PITA, although opensuse have a tool that will do this for you, but nobody seams to bother
2) testing against all distos is a major PITA, its much easier to let somebody familiar with the distro do it (hence PPAs/AUR are quite good)
3) bug spam, not to be too harsh, but if a newbie can't figure out how to install the vanilla version of your releases, they are probably not going to understand enough about their system to understand when something is/isn't your fault and you end up with bugs opened against the wrong projects.
IranAir Flight 655 never forget!
This research is ongoing. Email me (on the website) and we can add code to collect data from more distros.
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.
I could be wrong, but I believe Sabayon still uses portage and the Gentoo portage repository directly. They potentially have their own packages in their overlay, but AFAIK you can't really say they do the package integrations themselves. They still very much rely on upstream Gentoo.
This author takes full ownership and responsibility for the unpopular opinions outlined above.