Originally posted by DrYak
View Post
Announcement
Collapse
No announcement yet.
Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
Collapse
X
-
-
Originally posted by jonnor View PostThere could be several GNOME_FOO_X runtimes, or runtime named MY_HOBBIT_Y which would contain roughly the same software but repackaged by to be more awesome. However each application (version) must chose one runtime they use. It is of course likely that the runtime released by official upstream developers would be more used.
...
As explained above, there is not one runtime vendor. Targetting old/new cpus can be done with different architectures (just like i486 versus i686 now). Also, we don't need less-secure runtimes. There are very few apps for which the extra couple of % is critical. If you have such an app, bundle the libraries which must be built with special flags.
Leave a comment:
-
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.
Not only have they a working installer for a whole set of programs, they even managed without static linking.
Unfortunately it is likely that they'll guard this knowledge fiercly as it is apparently nowhere else to be found and gives them great advantage over all other ISVs
Cheers,
_
Leave a comment:
-
Originally posted by justmy2cents View Postfair enough. though, i'll answer the math lib question. this is perfectly sound in the sandboxed applications which solve a lot of same things as this
Leave a comment:
-
Originally posted by Delgarde View PostProblem is, the "community" is all the people you've just said you don't trust, among others. The "community" is all the people who are currently working contrary to your version...
Originally posted by RahulSundaram View PostThat isn't a simple wish at all when hundreds of open source components depend on libraries which don't have a stable ABI and then you followup with wanting yet another LSB when the first one failed to do the job. No developer is going to abide by the wishes of some distributions when they have requirements that distributions don't meet. If I write an application that requires a math processing library and one isn't provided by the common runtimes, what do you expect me to do? Your entire proposal reeks of wishful thinking. The only model that works well in open source is rough consensus and tools that can cope up with changes. If you believe otherwise, go ahead and write code and show the rest of us how to do it better.
Sun Tzu ?If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.?
Leave a comment:
-
Originally posted by justmy2cents View Postwhom do i trust? as first... NOT ME!!!!!, not lennart or his cabal, not fedora, not redhat, not debian, not ubuntu... i trust in community.
Leave a comment:
-
Originally posted by justmy2cents View Posthmmm, my wish is actually really simple. something without stable API/ABI should not provide runtime snapshot.
Leave a comment:
-
Originally posted by RahulSundaram View PostI get that but so far all I can see in that is idealism. I haven't heard a single solid proposal that says shows how it can be realistically be done and how you will enforce that. For example, who do you want trust in Linux to approve a specific list of runtimes? If you believe it is feasible, write it up. That will be interesting.
it is also basically the same thing i would like gtk to move to. separation in 2 parts, stable and unstable. gtk-3 has done some awesome work in last 2 releases, they basically succeeded in fixing 95% of my gripes with gtk it self. now there is only one major gripe, no gtk-4 means no stable bindings for it or clear development process how to use it. and since they put scenegraph as part of goal for 4, gtk-4 was lost somewhere in the foggy distance again. if they released gtk-4 with smaller goals and put scenegraph as unstable to be moved to 4. that would give clear picture what is stable and what is declared as "use it on your own risk". gtk having development version as long as it has is not really good for project. sooner or later you have to say "ok, this is good enough"
i'll take gnome as example here. and to your question who... they know best what is stable in their project and what is not
gnome-3 where only API/ABI stable things in gnome-3.x are present. say to developers "this is stable and this you can rely on for whole 3 era, new features will be added when they are ready"
gnome-unstable-3.x and moving parts to gnome-3 whenever unstable thing becomes stable and with that extending stable and reliable part. it should also be discouraged in every way possible to depend on this "use it on your own risk"
i can say for sure that this would be not only my dream come true, most developers would love this scheme
whom do i trust? as first... NOT ME!!!!!, not lennart or his cabal, not fedora, not redhat, not debian, not ubuntu... i trust in community. that is something RH, debian.... should put their heads together and define at least few base runtimes for typical application cases where they find common ground they need or expect from another. as soon as one party tries to define something for another there will be people feeling left out and there would be resistance. you could as well try calling it LSB "the 2nd try", except LSB v.1 more or less fails miserably
Leave a comment:
-
Originally posted by justmy2cents View Posthmmm, your "over a period of time" is exactly what i say it should be done before.
Leave a comment:
-
Originally posted by rdnetto View PostAh, you're right - I got the facts slightly wrong. logind was always a systemd project, but only in systemd v205 did the systemd (the init daemon) become a hard dependency. In that context, systemd becoming a hard dependency is much less unsurprising, though I stand by my point that if it were a non-systemd project, they would have looked at supporting other init daemons as well.
Some of the Debian people did put some work into providing a shim that would allow newer logind to work without systemd, but I think that went by the wayside when Debian and Ubuntu decided to adopt systemd... something similar would be required to run Gnome on non-Linux kernels though...
Leave a comment:
Leave a comment: