Changes and complaints [LWN.net]

Changes and complaints

Posted Feb 23, 2012 16:47 UTC (Thu) by khim (subscriber, #9252)
In reply to: Changes and complaints by michaeljt
Parent article: Changes and complaints

I've been wondering quite a bit about how this would be achievable on a modern Linux.

Modern Linux is fine. Modern GLibC is fine. Modern Xlib and few other pieces are fine. Even dpkg/rpm are fine!

They system breaks apart at the next level: sadly it was not a design goal for all these fancy repos to give you choice. They are designed with "everything must be of the latest version" approach.

Nonetheless, there is a lot of infrastructure that you really want to share, like graphical tool kit plug-ins and configuration, which might get rather painful if you were using different static versions of the tool kit libraries in different applications.

Right. That's why you should design you plugin systems to be upgradeable and side-by-side installable. This is not that hard, but it must be an explicit design goal. As long as answer to "how can I install some program" is "it should come from your distribution repo" we are stuck with all these problems.

P.S. The funny thing is that while developers are hurt by distributors they often depend on them, too: they provide new versions of things which are not compatible with older ones and not parallel-installable, simultaneously! This only works because distributor repos make it possible.

(Log in to post comments)

Changes and complaints

Posted Feb 23, 2012 16:57 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

> Modern Linux is fine. Modern GLibC is fine. Modern Xlib and few other pieces are fine. Even dpkg/rpm are fine!

> They system breaks apart at the next level: sadly it was not a design goal for all these fancy repos to give you choice. They are designed with "everything must be of the latest version" approach.

Quite agree. I was including your "next level" in my vague "modern Linux".

> Right. That's why you should design you plugin systems to be upgradeable and side-by-side installable. This is not that hard, but it must be an explicit design goal. As long as answer to "how can I install some program" is "it should come from your distribution repo" we are stuck with all these problems.

Again, I agree, but my musings were/are about how to force what we have now into working with applications taken from other sources without things becoming too fragile. Not saying my evil thought above falls into that category!

Changes and complaints

Posted Feb 23, 2012 19:29 UTC (Thu) by lacos (subscriber, #70616) [Link]

"Another question: a bug in libpng is discovered and fixed. What packages should be rebuilt?"

The base system's provider would rebuild the shared lib and push the update. All dependent base system apps would benefit.

The vendor providing the extra package (statically linked with a specific version of libpng) should monitor all libs they link statically into the app. When there's a security advisory for libpng, they should backport the fix (or grab the new upstream release if appropriate), rebuild their app with the fixed lib, and push the product via a separate channel.

I have the impression this is how Firefox works on Windows. (Except they may not link statically, just maintain their private set of DLLs.)

Changes and complaints

Posted Feb 24, 2012 9:37 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

> The vendor providing the extra package (statically linked with a specific version of libpng) should monitor all libs they link statically into the app. When there's a security advisory for libpng, they should backport the fix (or grab the new upstream release if appropriate), rebuild their app with the fixed lib, and push the product via a separate channel.

I don't even see why they need to do this manually. Linux distributions today handle security updates almost transparently to the system user, and this could be pushed up a level so that the statically linked "extra" package is automatically rebuilt and re-downloaded by its users. Granted, it ought to be tested first, but that doesn't really happen now in the dynamically linked situation we have.

Changes and complaints

Posted Feb 23, 2012 19:35 UTC (Thu) by khim (subscriber, #9252) [Link]

It works because there's a dedicated Debian packager maintaining this. But hey, the packages from Mozilla.com only work because of dedicated packagers, right?

Right. But there are a difference: you need one packager for Windows (90% of market), one packager for MacOS (7% of market) and one packager for iOS and one packager for Android (which are already significantly more popular then Linux) - yet you need dozen of packagers for Linux.

Another question: a bug in libpng is discovered and fixed. What packages should be rebuilt?

Ah, the infamous "security" strawman. Yes, all packages must be rebuilt in MacOS and Windows case but only one package in Linux case. Except it's not true: Firefox bundles it's own fork of libpng anyway thus it must be rebuilt, too.

The problem with this approach is that it just does not work. If users are not using your platform then it does not really matter how secure it is. Sure, if we are discussing some kind of military OS then it may make some sense… except it fails there, too: military starts from most popular OS, not from the most secure one.

Changes and complaints

Posted Feb 24, 2012 0:51 UTC (Fri) by jengelh (subscriber, #33263) [Link]

>one packager for Windows, yet you need dozen of packagers for Linux.

Judging from the fact that VMware, NVIDIA and ATI do not seem to give a damn about organized distro integration and instead produce self-extracting sh archives that spew untracked files into one's system, it seems more like there is just one person responsible for the Linux package, and the remaining 10 members of the team know how to edit the Windows MSI.

Meanwhile, it would not be all that hard to use [an own instance of] a potent cross-distro build system like Open Build Service to cater for a number of distros in two swoops.

Changes and complaints

Posted Feb 24, 2012 12:17 UTC (Fri) by khim (subscriber, #9252) [Link]

Judging from the fact that VMware, NVIDIA and ATI do not seem to give a damn about organized distro integration and instead produce self-extracting sh archives that spew untracked files into one's system, it seems more like there is just one person responsible for the Linux package, and the remaining 10 members of the team know how to edit the Windows MSI.

Well, that's certainly sensible choice: this about how much marketshares differ thus it's prudent allocation of resources.

Meanwhile, it would not be all that hard to use [an own instance of] a potent cross-distro build system like Open Build Service to cater for a number of distros in two swoops.

Yes, it's possible, but it does not solve the whole problem. It's not as hard to build your package (well, this is a problem, too, but a [relatively] minor one). It's the fact that you need to [test] it. Single self-extracting sh archive solves this problem to some degree, cross-distro build system does not. And even single self-extracting sh archive requires a lot of distro-specific code to handle [supposedly] trivial things (like the ability to run per-machine or per-session background process).

All these things are just a band-aids and don't solve the core problem.

Changes and complaints

Posted Feb 23, 2012 22:46 UTC (Thu) by misc (subscriber, #73730) [Link]

> They are designed with "everything must be of the latest version" approach.

No, that's designed of "everything must be of a specific version", which is the only sane way of designing it without having a combinatorial explosion.
( ie, how to test that you installation is good for kde 3 and 4, for gnome 2 and 3, with and without specific part, be it new and old xorg, with or without pulseaudio ).

Sure, someone could do a distribution with everything "old" except firefox. Still, some people would complain, because there is the new kde, etc. And if this was so easy, someone would have done it already.

The truth is that the only way to do it is to use something like gentoo ( DIY distribution ), and I see few people doing it. So either the drawbacks of gentoo are not enough to convince people to use it, even if binary one do not satisfy them, or the vocal minority is just that, a minority.

Changes and complaints

Posted Feb 24, 2012 0:11 UTC (Fri) by khim (subscriber, #9252) [Link]

No, that's designed of "everything must be of a specific version", which is the only sane way of designing it without having a combinatorial explosion.

Well, there are another way: actually build interchangeable components. Create some kind of "core OS" and make sure other subsystems don't share anything. This is how it's done in other OSes, after all.

ie, how to test that you installation is good for kde 3 and 4, for gnome 2 and 3, with and without specific part, be it new and old xorg, with or without pulseaudio

Well, OS exist to give users the ability to run the software of their choice. If it can not provide this capability even for small subset of the available software then something is most definitely rotten in the state of Denmark.

Sure, someone could do a distribution with everything "old" except firefox. Still, some people would complain, because there is the new kde, etc. And if this was so easy, someone would have done it already.

True. It's not easy. Does not make the problem any smaller. Either you need the ability to "pick and choose" or you need to actually make upgrades smooth and unnoticeable. No GNOME3 or KDE4 "revolutions".

The truth is that the only way to do it is to use something like gentoo ( DIY distribution ), and I see few people doing it.

Does not work either. Gentoo allows you to toggle different knobs. But different version? Nope. You can push some packages back and forth - but to very limited extent. Even mix of x86 and ~x86 is often problematic!