Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs

[CrystalGamma]

This is a real problem. I used to have a closed-source printer driver that could only work with a specific version of libc and gtk1. You get the same problems now if you install closed-source software that uses e.g. gtk 3.4 (given that gtk 3.x versions are not parallel-installable.)

Lennart suggests a very elegant solution to this problem: each runtime is self-contained and always parallel-installable. In the aforementioned scenario you could install the correct version of gtk 3.x and have the closed-source application work as long as that version works. This makes things simpler for both the user and the admin.

The user can keep using their closed-source application.

The admin can upgrade the system without holding back for fear of breaking the application. A security-conscious admin will use cgroups to create a jail for the closed-source app and outdated runtime so they cannot connect to the network or access the file system in an insecure fashion.

Looking forward to seeing the results of this work!

So sandboxing is preferable to updating the runtime used in your opinion?
An easier and present-tech-compatible way would be to just use a new package for each new ABI version, just like distros already have parallel package lines for major versions of software like python or gtk, just on a finer level.

[BlackStar]

So sandboxing is preferable to updating the runtime used in your opinion?
An easier and present-tech-compatible way would be to just use a new package for each new ABI version, just like distros already have parallel package lines for major versions of software like python or gtk, just on a finer level.

If I have to run a closed-source application requiring an outdated version of gtk, then yes, I will sandbox the hell out of it. No network access, an isolated view of the filesystem, the whole shebang.

An abandoned runtime or a closed-source application will not update itself. Noone is going to fix security bugs in gtk-1 or gtk-3.0 in 2014, so sandboxing is the only solution that lets you have the cake and eat it too.

[BlackStar]

hmmm, it works for gtk-1, i agree to the point where i would almost agree it also solves worlds hunger. but, he also says gnome-3.x can create runtime for each version without restriction when/how. welcome to the world where 100kb appX can carry 20GB of dependencies otherwise not required by anything else, since that app will never update to new runtime. i'm scared to think something like runtime could be made with unstable api/abi. that is whole point of my concern. anything up to whole distro, no matter how personalized can be declared as runtime

Runtimes have unstable ABIs *right now*. You have the 20GB strawman today. This proposal will not change anything.

You should really listen to what Linus has to say about distributing applications today. The solution he suggests is pretty much what Lennart is doing right now.

[justmy2cents]

Runtimes have unstable ABIs *right now*. You have the 20GB strawman today. This proposal will not change anything.

You should really listen to what Linus has to say about distributing applications today. The solution he suggests is pretty much what Lennart is doing right now.

which runtime has unstable abi/api? i mean one that broke in x.y version, not in x+1. and as runtime i don't mean gtk-3. that is WIP, not runtime. look at Qt, .Net, Java for example. and no, i'm not full 20GB right now, just as much as it takes for that specific lib, with runtime i'm always at 20GB

listened to linus and what he was referring was sandboxing, not this. sandboxing already approaches to solving gtk-1 problem.

[anda_skoa]

it is not about communication, i think i was specific with the fact that i named it as one of worst case scenario examples. if i didn't, then... my bad.

You mentioned clipboard and D-Bus as two things you would consider challening ABI wise, so I pointed out that these are based on socket communication and thus very resilient if not the most resilient against any kind of binary incompatibility.

Cheers,
_

[justmy2cents]

You mentioned clipboard and D-Bus as two things you would consider challening ABI wise, so I pointed out that these are based on socket communication and thus very resilient if not the most resilient against any kind of binary incompatibility.

Cheers,
_

and as always, answering to irrelevant part of the comment

Cheers

[RahulSundaram]

which runtime has unstable abi/api? i mean one that broke in x.y version, not in x+1. and as runtime i don't mean gtk-3. that is WIP, not runtime. look at Qt, .Net, Java for example. and no, i'm not full 20GB right now, just as much as it takes for that specific lib, with runtime i'm always at 20GB

listened to linus and what he was referring was sandboxing, not this. sandboxing already approaches to solving gtk-1 problem.

WIP libraries are still being used widely and hence they are part of the runtime that many apps depend on. You cannot just discount them and pretend that it is not something worth solving. ABI breakage is a VERY widespread problem. Take a look at http://upstream-tracker.org/

Linus wasn't merely referring to sandboxing. He also talked about how much of a pain it is to distribute his own app (dive log application) in linux because there is no distribution neutral binary redistribution model. This is a major problem for any ISV or even local deployments with custom in house apps. Solving this would lead to less distribution lock in because some applications are only certified and supported for specific distributions and if you could just download the runtime and use it, then you can run those ISV supported apps in say Arch or Gentoo and that would be just fine.

[justmy2cents]

WIP libraries are still being used widely and hence they are part of the runtime that many apps depend on. You cannot just discount them and pretend that it is not something worth solving. ABI breakage is a VERY widespread problem. Take a look at http://upstream-tracker.org/

library is not something you call runtime. as soon as it gets runtime definition API/ABI is more or less must. and since you point out linus so fondly, in that talk linus told zillion times API/ABI shouldn't break, which is same thing as i'm saying. runtime should be something you depend on long term, not hope on short term

and what lennart proposes here is exactly opposite of what linus wishes. instead of stable API/ABI let's trash harddrive with all possible versions of API/ABI

Linus wasn't merely referring to sandboxing. He also talked about how much of a pain it is to distribute his own app (dive log application) in linux because there is no distribution neutral binary redistribution model. This is a major problem for any ISV or even local deployments with custom in house apps. Solving this would lead to less distribution lock in because some applications are only certified and supported for specific distributions and if you could just download the runtime and use it, then you can run those ISV supported apps in say Arch or Gentoo and that would be just fine.

actually, he is reffering to "something like that" and guess what. i know many others predate in most features, this was 1st full featured solution like that
Lennart started this http://www.superlectures.com/guadec2...ions-for-gnome
Fedora seems to be first to realize this http://blogs.gnome.org/uraeus/2014/0...e-way-forward/

[anda_skoa]

and as always, answering to irrelevant part of the comment

I clarified a potential misconception on the impact of ABI problems on communication channels that you seemed to be worried about.

I did not comment on anything else you posted that was irrelevant to that topic.

Cheers,
_

[anda_skoa]

He also talked about how much of a pain it is to distribute his own app (dive log application) in linux because there is no distribution neutral binary redistribution model. This is a major problem for any ISV or even local deployments with custom in house apps.

This is brought up a lot, but I've installed really complicated pieces of software, e.g. BlackBerry's BB10 SDK (IDE, cross compiler toolchain, simulator, etc), multiple times on multiple machines, on Linux and on Windows.

So either there is also a major problem for any ISV on Windows, or the people at BlackBerry are just so much more skilled that they managed to do that.

Cheers,
_