Some unreliable predictions for 2015

Posted Jan 11, 2015 20:07 UTC (Sun) by viro (subscriber, #7872)
In reply to: Some unreliable predictions for 2015 by HIGHGuY
Parent article: Some unreliable predictions for 2015

Er... So you trust $BIGNUM app duhvelopers to deal with e.g. security fixes? Including such things as "the version of a library it's currently using has a hole"? Really?

Some unreliable predictions for 2015

Posted Jan 11, 2015 21:23 UTC (Sun) by HIGHGuY (subscriber, #62277) [Link]

Unfortunately, no ;)

But if anything, I think this is _the_ big problem to overcome for those new deployment schemes.
Also, I'm not saying app packaging will cease to exist. Instead, I think that such schemes may lower the duplication that goes into many distro's doing the same thing equally or slightly differently.

But of course, they'll first need to see daylight and we'll surely learn a lot on the way there.

Some unreliable predictions for 2015

Posted Jan 11, 2015 22:08 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

The problem is, I also don't trust OpenSource developers not to break an ABI during a security update.

Some unreliable predictions for 2015

Posted Jan 12, 2015 4:14 UTC (Mon) by viro (subscriber, #7872) [Link] (4 responses)

And your point is...? Other than "library authors have atrocious habits", that is (in other news: sudden loud noises in the vicinity of Mephitis mephitis might be inadvisable).

There is no easy solution; the whole point is that it's a bloody hard work that has to be done. And no, "just leave the libraries as app authors shipped" is not a solution either.

If somebody is trying to claim that this will be the year when said library writers will suddenly acquire a less stinky attitude towards compatibility (and better interface design - which is *also* a bloody hard work), well... there's a nice bridge in NY they might want to buy.

Some unreliable predictions for 2015

Posted Jan 12, 2015 4:28 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> And your point is...?
Just stop pretending that libraries are secure and stable. Package everything and then provide strong isolation (using containers, seccomp, SELinux or whatever) for as much stuff as you can.

Perhaps, ultra-important urgent bugfixes can be provided in an ad-hoc manner by patching the affected libraries.

Some unreliable predictions for 2015

Posted Jan 12, 2015 4:32 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

it's this packaging that is the hard work that the distros do.

depending on every app developer to package things sanely and blindly running whatever combination they happen to have used at the time of release is even less sane.

Some unreliable predictions for 2015

Posted Jan 12, 2015 20:23 UTC (Mon) by HIGHGuY (subscriber, #62277) [Link] (1 responses)

Actually, that's not what I'm saying in my comment.
I'm saying that we might see the redundant work going away if a good deployment solution is found. I don't think we'll see packaging go away, I think we'll see less of it because there's no 30 flavors of distro each using their own packaging system.

And going one step further, I think it could make sense to let a package 'container' be updated with ABI-stable backports and fixes. i.e. You first make a container with app X and lib Y and Z, then provide stable updates to each through incremental regular intra-container updates that keep ABI stable. Packaging is then no longer a client-side app, but just a means of updating an app-container server-side and offering these incremental updates to us, users.

Or, maybe I'm just dreaming and this will all fade away by 2016 ;)

Some unreliable predictions for 2015

Posted Jan 13, 2015 0:56 UTC (Tue) by dlang (guest, #313) [Link]

I don't think that there are 30 different packaging systems in use. The difference between distros is less in the packaging system used and more in the choices related to how each package is created.

Tools like alien can mechanically convert packages from one packaging system to with pretty good reliability, but that makes no impact on the work the different distros do.