the ubuntu devconf

A week or so ago I went along to the Ubuntu Developer Summit at Google HQ. I saw Mirco demo some of his new toys, met up with Christian and Alex from VMware, but more importantly had an interesting hour-long session with the Ubunterians about packaging and third party software - all the usual stuff.

I’ll be doing it all over again in a few weeks at the OSDL summit, as well.

Here are some notes on the result of that chat:

  • It was generally agreed there were problems and it’d be nice to resolve them. Some time was spent talking about the issues that 3rd parties have (eg ELF misdesigns)
  • There was disagreement about the solutions. The Ubuntu guys see themselves as not being Linux but rather something else. “There is a reason it’s not called Ubuntu Linux”, it was said. They don’t want ISVs to write software for Linux but instead write it for Ubuntu (and by implication, either not bother with Red Hat/Novell or “port” apps individually). The fact that Ubuntu doesn’t really have enough market share to justify porting apps to it specifically doesn’t really matter.
  • There was a strong feeling that the goal of standardisation across distributions is inherantly incompatible with the fundamental idea of a distro. The logic goes, what is a distro if not a set of patched packages? Standardisation takes away the ability to modify packages. Therefore we can no longer improve things beyond the base. Therefore we cannot build a distro. Therefore standardisation is a bad thing.
  • There was talk of using virtualisation, efficiency tradeoffs etc - so if the Ubuntu guys want to fork GTK and mess around with some API then patch the apps which break, that’s fine, as long as they provide a “pristine” upstream copy that standardised apps run against. It means less efficiency if you run both upstream binaries and downstream binaries at once but it improves reliability. But they weren’t keen on even this compromise.
  • They were surprised that Inkscape considered itself as an ISV. There wasn’t much awareness of the problems open source projects can have with distributions - like slow updates, odd patches etc. The fact that Inkscape are building autopackages I think was a surprise.
  • I had to leave after an hour for a cap planning meeting, but I asked wasabi (who was present) what the conclusions were afterwards. Apparently it boiled down to “well this sucks but what are we going to do about it?”. Answer: nothing.

This sort of conversation makes me very cynical about the relevance of the OSDL and LSB. It is easy to pick on Ubuntu here but in practice I know this kind of thinking is endemic to the distributions … it would have been exactly the same at a Fedora conference. It was a shame that Mark Shuttleworth didn’t show up - his blog entry is the only reason I went along, as I’ve had similar conversations via email before so knew what to expect. Unfortunately it sounded like he had a lot of pushback on those plans and they are now being watered down to simply being “it’d be nice if source compiled the same on every distro”, which is basically where we are today, sort of, except because there are no ISVs there’s no real incentive to keep it that way and sometimes it breaks.

Nonetheless I’ll be going to the OSDL DAG meeting in Oregon in December, this time representing Google instead of only myself. And I’ll be saying exactly the same things as we always have done.

3 Responses to “the ubuntu devconf”

  1. Sami Tikka Says:

    I work for an ISV that has couple of products that run on Linux. I have followed your work with great enthusiasm. (Almost made autopackages of our software.)

    We support about 20 different Linux “platforms”. We count every version of every distro as another platform, with its own peculiarities and problems we have to sort out. Vmware gsx servers run tests on each platform every night. We are constantly adding new platforms and are rapidly running out of hours in the day to run tests. We build on Red Hat Enterprise Linux 2.1 and use C, Perl and Java. No C++. (Tried it, but found it too difficult to create binaries that just run everywhere.) We have a Perl extension and noticed those are very much tied to the compilation time options of the Perl runtime. So, we ship our own Perl with the product because we cannot be sure our Perl extensions will run with the Perl that is installed on the customer’s system.

    So far we have managed to survive by making one package that installs on every version of every distro (provided they have or can get RPM support). If it should ever happen that we must build packages for each distro, I’m pretty sure our management would shut down Linux products and start thinking about making an appliance where we only need to support one version of one OS.

    I hope you can find the strength to keep talking about this: It should be possible to make a binary that runs on all Linux distros.

  2. Artem Vakhitov Says:

    This is really depressing. People are offered a ready solution, but refuse to accept it citing a set of vague ideological arguments mostly covering their inertia and ignorance.

  3. Joseph Garvin Says:

    I think that perhaps it would help if you reassured distros that they would still have reason to exist. Distros can still differ in default software, usability patches (see SuSe’s patched Gnome and KDE menus), support, and technology choices (Novell AppArmor vs. Redhat SELinux). Listing these and talking to them about what it would mean to be a distro in the theoretical world where installing stuff on Linux is easy. When I brought autopackage up with Ubuntu users, they seemed to be afraid that it would mean there would no longer be an Ubuntu community. I think that’s probably the fear for a lot of distros.

Leave a Reply

You must be logged in to post a comment.