The interesting thing here is that the unmentioned Mandriva does release around the same time as Canonical release Ubuntu.

It's not about releasing on the same day, it's about using the same version of key parts of the distro, like kernel, GCC and X (for example). Each distro could still use their own criteria for setting a releasedate.

An example could be Ubuntu Hardy using a 2.6.24 kernel and releasing in april and Debian Lenny using their version if the 2.6.24 kernel and releasing in september (or whenever it's ready).

Well said. Shuttleworth's "vision" just won't work. You can't force 10-20 big upstream projects (KDE, GNOME, kernel, OpenOffice.org, Firefox, GCC, etc...) to sync their release schedule. And you wouldn't want to do that either. One of the reasons why FOSS is usually better in terms of quality is that releases, focus and features are typically driven by quality, by developers, not by marketing and competitors. Things are released when it's ready, when it's good enough.
Having a synched release plan for many large and complex projects means a huge burden on upstream.
I can't imagine Mark Shuttleworth could be that clueless about the reality of software development and how the whole ecosystem around a distribution actually works. He isn't. Can't be. So what agenda is he having/endorsing when he pushes that idea so loudly (arguably, even when he whispers, it does resonate a lot ;)) ? I don't know.

Sean, about your wish on "common packaging across distributions":
- PackageKit definitely is a good initiative and project, but it doesn't solve anything wrt that as it's "merely" a frontend to different package management stacks, so it can give users of several distros the same frontends and user experience, but not access to the same packages;
- it isn't about the package format (RPM vs deb vs whatnot), RPM and dpkg are pretty much equal in terms of features, performance, stability anyway; even if everyone was using RPM, it wouldn't help because the real problem is what dependencies packages are built against, especially their respective versions

To explain the latter: take openSUSE, Fedora and Mandriva, they're all using compatible versions of RPM. So, from a packaging format point of view, you can install an RPM package that has been built on one of those three on any of those three (say, a libfoo.rpm built on openSUSE can be installed on Fedora).
Problem is, every single package (except a very, very few) has dependencies against other ones. If you take Firefox as an example, it depends on the GCC C++ runtime libs (libstdc++), gtk2, cairo, freetype, etc... Point is, distros usually don't have compatible (major) versions of those libraries so you won't be able to install openSUSE's 11.0 Firefox package on Fedora 9 because it uses much more recent versions of gtk2/cairo/freetype/GCC/... (just an example).
And then you have different package naming conventions (though softened a bit by relying on file dependencies instead of package names for shared libraries). And different init scripts. And different file/directory locations. Distro A uses sysvinit, distro B uses upstart.

To summarize, what you would like to see is even more restrictive and difficult to implement then what Mark is dreaming of -- it would pretty much boil down to having a single, unique distribution ;)

In order to accomplish that *partially* (which should be feasible in theory, certain dependencies are very stable and have a strong record on backward/forward compatibility, e.g. KDE 3), we'd first need to have everyone or at least the "big players" work together on LSB and actually implement it (Debian/Ubuntu don't), and have LSB evolve at a much faster pace to encompass more standards. If package naming differences and init scripts incompatibilities were addressed and implemented by many distributors, it could be done for a certain amount of packages.

Having major upstream projects follow strong guidelines on SONAMEs and ABI compatibility would be a *lot* more interesting than synching release cycles. But, again, it has a high cost on upstream development, is very complex to accomplish, and clearly takes a lot of fun and """innovation""" out of FOSS development. Not sure we'd want that either.

If you couldn't write about the distros, maybe you could write about something more interesting like extra applications, games, and utilities.

One of the things that keep people tied to Windows is the incredible number of free and shareware programs that are available. Some interesting articles about such stuff for Linux would interest readers, including yours truly.

When you try to united all the packaging system, which many people and many projects try to do. Basically you are also forcing one distribution to agree with another one. Which should not happen at the beginning with, or we'll only get one distribution. For reducing the complexity and confusion of package between different distribution system. You should take a look at openSUSE build service, what it is actually trying to do is creating different packages for all distribution with a single source. Which should be a better way of working with upstream and distribution at the same time. First you are not changing any distribution behavior any more there won't be any need for any distribution to accept it or not. As long as user need or wanted to include that package, you get it. Second you are providing a single ultimate access for user to get any packages. It may seem easy for a lot experience users but still if we need to increase our user base, we need to make every distribution much easier to use, not just Ubuntu or Debian or openSUSE or Fedora. BuildService is really something everyone could/should work on, since it will help everybody. Of course it still missing a lot of functions. But I see that light there.

pascal wrote:

distros usually don't have compatible (major) versions of those libraries so you won't be able to install openSUSE's 11.0 Firefox package on Fedora 9 because it uses much more recent versions of gtk2/cairo/freetype/GCC/...

solving that problem is one of the the goals of synchronizing releases.

work together on LSB and actually implement it (Debian/Ubuntu don't)

they don't?
can you please cite a reference for that?
last i checked, debian and ubuntu did implement LSB in form of a package that would depend on the right versions of libraries and such, so that any application built against LSB would run.

greetings, eMBee.

https://lists.ubuntu.com/archives/sounder/2006-January/003630.html
- "And while we would love that not to be the case, the truth is that the reasons to specialise outweigh the benefits of homogeneity. Much as it may be compelling, the common core idea is ultimately flawed,"

Date : Tue Jan 3 11:19:42 GMT 2006
From : Mark Shuttleworth