Originally posted by justmy2cents
View Post
Announcement
Collapse
No announcement yet.
Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
Collapse
X
-
-
Originally posted by anda_skoa View PostThis 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,
_
Comment
-
Originally posted by RahulSundaram View PostYou 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.
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.
Originally posted by RahulSundaram View PostTo 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.Last edited by justmy2cents; 02 September 2014, 03:18 PM.
Comment
-
Originally posted by justmy2cents View Postcouldn'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
Comment
-
Originally posted by RahulSundaram View PostOther 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.
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
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"
Comment
-
Originally posted by justmy2cents View Postif 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?
Comment
-
Originally posted by RahulSundaram View PostThis 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.
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
Comment
-
Originally posted by justmy2cents View Postwell, you forget one important fact. in OSX or android case, there is only one entity that creates and approves runtimes
Comment
-
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.
http://www.dirtcellar.net
Comment
-
Originally posted by RahulSundaram View PostThat 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.
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
Comment
Comment