Announcement

Collapse
No announcement yet.

Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ryao
    replied
    Originally posted by DrYak View Post
    BTRFS as any other piece of Linux is GPLv2-licensed. GPLv2 (that the main difference from GPLv1) License asks you to also give permission for the patents covering the code that you wrote.
    So if BTRFS is covered by patents that Oracle owns, you're free from lawsuites if you use GPLv2 code provided by Oracle (which is the case of BTRFS).

    The whole point of GPLv2 was avoiding that the freedom to study and tinker code was prevented by patentes.

    (Just like the whole point of GPLv4 is avoiding that the usual free-software freedoms are prevented by DRM).
    I think you have an off by one error in your reasoning. The GPLv3 includes patent grants, but the kernel license is GPLv2. You could always read the license to confirm that.

    Leave a comment:


  • curaga
    replied
    Originally posted by jonnor View Post
    There 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.
    If all the apps specify they need GNOME_57, it is practically the same thing as there only being one runtime. Obviously if the user can override what the apps require this is not an issue, but from the doc it doesn't sound like they can.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by RahulSundaram View Post
    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.
    Well, that then settles my question: obviously the people at BlackBerry are geniuses.
    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:


  • RahulSundaram
    replied
    Originally posted by justmy2cents View Post
    fair 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
    Not really. It is being proposed by the same set of people and they would notice that kind of overlap if it exists Sandboxing doesn't solve the problem since I would be forced to bundle a private copy of the library I need and even if sandboxing is fool proof (and history of such technologies have shown that it isn't), it only solves the security problem and doesn't solve the waste of resources (including but not limited to memory and disk space) problem. In other words, this is sweeping the problem under the rug and pretending that it doesn't exist as opposed to finding a systematic solution.

    Leave a comment:


  • justmy2cents
    replied
    Originally posted by Delgarde View Post
    Problem 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...
    not really, i wouldn't trust them separately. didn't i say they should come to common conclusion without anyone dictating? though Rahul did pose good question as answer to this

    Originally posted by RahulSundaram View Post
    That 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.
    fair 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. they are far more attractive than solution that solves one set of problems by creating other set.

    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:


  • Delgarde
    replied
    Originally posted by justmy2cents View Post
    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.
    Problem 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...

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by justmy2cents View Post
    hmmm, my wish is actually really simple. something without stable API/ABI should not provide runtime snapshot.
    That 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.

    Leave a comment:


  • justmy2cents
    replied
    Originally posted by RahulSundaram View Post
    I 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.
    hmmm, my wish is actually really simple. something without stable API/ABI should not provide runtime snapshot. or at least, that kind of snapshot should not be targeted as dependency. and clear picture what is stable and what is not

    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:


  • RahulSundaram
    replied
    Originally posted by justmy2cents View Post
    hmmm, your "over a period of time" is exactly what i say it should be done before.
    I 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.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by rdnetto View Post
    Ah, 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.
    It doesn't have a hard dependency on systemd - it has a dependency on published interfaces for which systemd is the only provider.

    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:

Working...
X