Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs

[RahulSundaram]

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

You need a transition path to get from where you are now to where you want it to be. Merely wishing that ABI breakage would stop isn't going to help. All proposed solutions are essentially about paving the way for us to move forward. Containers don't magically solve the problem either. They often bundle libraries instead.

[RahulSundaram]

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,
_

To illustrate the problem, lets us think about a simple app - I write say a PDF viewer with fancy transitions using a graphics library. I can provide an executable that will work across Mac and OS X but doing so in Linux (in a distribution neutral way) essentially requires static linking everything. This is the problem and there are no good solutions that is widely used.

[justmy2cents]

You need a transition path to get from where you are now to where you want it to be. Merely wishing that ABI breakage would stop isn't going to help. All proposed solutions are essentially about paving the way for us to move forward. Containers don't magically solve the problem either. They often bundle libraries instead.

couldn't agree more with 1st part. but, to clean your flat, you won't bring trash from whole neighbourhood inside your flat first. and sadly that is exactly what lennart is doing by not specifying what qualifies as runtime snapshot and what does not or better what it shouldn't.

as partially commercial developer, runtime is something i depend on to be available and maintained long term. at the same time i want to know it won't be short lived and obsolete in 6 months, because that kind of runtime would only create problems for me, not solutions. and as soon as you enable unstable API/ABI to get status of runtime snapshot, you did just that. developers can't even know wtf is stable and what is not long term. that is why i never upgraded to gtk-3, all my apps are gtk-2 (which was one of most awesome and reliable runtimes in providing stability) while i'm now moving them to qt, since gtk-2 doesn't evolve, while gtk-4 seems to be new duke nukem forever.

To illustrate the problem, lets us think about a simple app - I write say a PDF viewer with fancy transitions using a graphics library. I can provide an executable that will work across Mac and OS X but doing so in Linux (in a distribution neutral way) essentially requires static linking everything. This is the problem and there are no good solutions that is widely used.

and if what runtime is would be defined with more care, not only you could still deploy your app. you'd also have way less confusing target for development.

[RahulSundaram]

couldn't agree more with 1st part. but, to clean your flat, you won't bring trash from whole neighbourhood inside your flat first. and sadly that is exactly what lennart is doing by not specifying what qualifies as runtime snapshot and what does not or better what it shouldn't

Other than the weird analogies, it seems to me that you are jumping the gun and not waiting for the details to be flushed out based on other input.

[justmy2cents]

Other than the weird analogies, it seems to me that you are jumping the gun and not waiting for the details to be flushed out based on other input.

hmmm, not really if you look at example. i usually really like lennarts suggestions (love systemd, can't wait for kdbus, loved his snapshots idea), this one popped my eyes out though, especially since i'm partially commercial developer and it goes completely against what is deemed runtime. also, i said it few times now, i love this idea, i just hate the shallow restrictions

pasted from lennarts proposal

runtimerg.gnome.GNOME3_20:x86_64:3.20.1
runtimerg.gnome.GNOME3_20:x86_64:3.20.4
runtimerg.gnome.GNOME3_20:x86_64:3.20.5
runtimerg.gnome.GNOME3_22:x86_64:3.22.0

if something like 3.20.4 can become runtime... wtf is the limit? also, if applications can target such narrow target as 3.20.4 just how much dependencies does this put on applications. download full 3.20.4 for 1 app?

mind me, if this is in a way that MS kept directx in check by only providing a,b,c,d,e,f... extension dll to same runtime, that wouldn't be half wrong. but, that would mean 3.20.5 would need to only contain ABI/API differences from 3.20.4 and 3.20.4 would need to be updated to suit this need.

2nd thing that troubles me is the fact that something not being major version could in fact be considered as runtime. runtime in commercial development is a sacred word which translates into "until you see same major version, it will work"

[RahulSundaram]

if something like 3.20.4 can become runtime... wtf is the limit? also, if applications can target such narrow target as 3.20.4 just how much dependencies does this put on applications. download full 3.20.4 for 1 app?

This is pretty similar to the way Android or OS X can target very specific versions but in this case, you wouldn't downloading a whole new runtime if you already have a ABI compatible runtime and even if the runtime ABI is changed, any shared files wouldn't be retained because of the way btrfs snapshot diffs work.

[justmy2cents]

This is pretty similar to the way Android or OS X can target very specific versions but in this case, you wouldn't downloading a whole new runtime if you already have a ABI compatible runtime and even if the runtime ABI is changed, any shared files wouldn't be retained because of the way btrfs snapshot diffs work.

well, you forget one important fact. in OSX or android case, there is only one entity that creates and approves runtimes which sadly does not exists on linux. at the same time, neither it is presented in lennarts proposal. at that point my linux from scratch image i made after really drunken night could constitute as runtime i impose as dependency for my applications. this just switches package mess for snapshot mess.

lennarts proposal would be awesome if he touched 2 subjects
- what is runtime snapshot requirement? is it stable API/ABI or is it just random working snapshot? later would be unholly mess
- what is the restriction when one is building snapshots? one wouldn't like to have someone stucking him with complete distro as working runtime

[RahulSundaram]

well, you forget one important fact. in OSX or android case, there is only one entity that creates and approves runtimes

That is just not true. There are some runtimes that come from a commercial vendor but there is nothing stopping an arbitrary application from depending on something entirely external and many do especially in Android where one can side load applications even if Google doesn't approve them not to mention parallel market places in China and Amazon. There is simply no way to impose a specific set of runtimes for all of Linux. Over a period of time, we should aim to cut down the commonly used runtimes to a smaller subset but we certainly need the flexibility to pull in something custom for special needs. Even OS X allows that.

[waxhead]

While I think that systemd is big and ugly in many ways it is still very useful. I am not so sure about Lennart's suggestion here tough. However I must admit that it would be nice to have a uniform package format where packages work across distros and without worrying too much about dependencies. For some reason this reminds be about the good old assign command from the Amiga. You could refer to a device like DF0: and also use FLOPPY: or SOMEPROGRAM: , LIBS: ENV: , sort of like a label. That scheme worked quite well. I also liked the idea about datatypes on the Amiga or XPK library for those who remember that. e.g. you only needed datatypes/plugins for a spesiffic dataformat and all programs could magically open it. So why am I talking about these old things , well they where very convenient. I am sure this is what Lennart is aiming for, but sometimes things can get too convenient and you end up with a overminimalistic do it everything for you that does not give you choices and limit what you are doing. if Lennarts suggestion will expand or restrict your options remains to be seen.

[justmy2cents]

That is just not true. There are some runtimes that come from a commercial vendor but there is nothing stopping an arbitrary application from depending on something entirely external and many do especially in Android where one can side load applications even if Google doesn't approve them not to mention parallel market places in China and Amazon. There is simply no way to impose a specific set of runtimes for all of Linux. Over a period of time, we should aim to cut down the commonly used runtimes to a smaller subset but we certainly need the flexibility to pull in something custom for special needs. Even OS X allows that.

hmmm, your "over a period of time" is exactly what i say it should be done before. unless you think that starting with mess just to support every single whim is better than clean slate. also, in both cases special requirements constitute as upper layer, since Cocoa... is firmly under OSX control. Linux doesn't have so much firm ground as OSX has.

i don't know about you, but i prefer strict rules since those guarantee me more stability. but, i also never take path with least resistance when developing

linux also has way more cooks than OSX and you can't apply same recipe that worked on OSX. same as each desktop should have its HIG, snapshots should definitely have guidelines. it should also have clear vision how to minimize number of basic snapshots. not only it works better, it provides clear development target. it is enough to know commercial vendors won't abide by those, no need for FOSS to create its own share of mess

personally, as developer i'd be much more content if i could target gtk-3, gnome-3, qt-5 with smaller repertoire of features that get extended with every new gnome-3 snapshot, but at the same time knowing that when gnome releases 3.56 my app that targeted gnome-3 in time of 3.16 works with 3.56 gnome-3 snapshot while being updated to 3.56. at the same time as user i'd again be more content since my hdd only contains one gnome-3 runtime. this is also exactly what i was able to do with gtk-2 and now with qt-5. game developers have it really easy here, target steam runtime and screw the others, problem solved since it is obvious that if steam-runtime breaks compatibility, there will be steam-runtime2

btw, i know what i say is lot harder to achieve, but it is also something that would bring stability where there is none