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

  • #31
    stillbirth

    This is a stillbirth. It doesn't solve any problems from a admin view. It basically destroys distributions itself. AND it is a hell to maintain from distribution and admin view.

    What he basically approaches is a chroot with it's own environment for everything. Guess what, that is already possible. just install the os your program was tested with into a folder and chroot into it. So the problem comes here. If there is a ssl update (again) and you install it, it is not updated for container x, which runs app y. Simply because that container/subvolume needs to be updated. It's INSANE DUMP! If i want and need an environment for app x, i'm going to create such environment. I actually do this for many programs/environment, i have to develop for.

    TL;DR: You have many distributions installed parallel on your harddrive and you have to maintain everyone of it! FUN!

    Comment


    • #32
      i doubt thats can be working. Because of this:

      It doesn't matter anymore which distribution you run, and which distribution the vendor prefers.
      Its like "United Atheist Alliance" vs. "Allied Atheist Allegiance" vs. "Unified Atheist League"

      The Distributions don't want unity()!

      Comment


      • #33
        Originally posted by mythos View Post
        If there is a ssl update (again) and you install it, it is not updated for container x, which runs app y. Simply because that container/subvolume needs to be updated.
        And where is your Problem? You can Patch it.

        Well, btrfs has a feature they call "send-and-receive". It basically allows you do "diff" two file system versions, and generate a binary delta.
        The Benefit is bigger.

        Comment


        • #34
          Originally posted by Awesomeness View Post
          Then they stop the madness and become Fedora and CentOS remixes.
          Wasn't that the agenda they had all along? To unite distros and and remove meaningless differences? Once there, why bother build different distros in the first place? It will be same thing anyway and you could as well just go with Fedora or RedHat. Its about killing the (redhat/fedora) competition.

          And what happens with the BSDs, that does not have btrfs?

          Comment


          • #35
            Originally posted by Nille View Post
            And where is your Problem? You can Patch it.



            The Benefit is bigger.
            That's the point. You have to update every distribution/subvolume.

            Your quote from the blog doesn't references any benefit at all. how much space it uses on the physical device is not something that matters.

            Comment


            • #36
              Originally posted by mythos View Post
              That's the point. You have to update every distribution/subvolume.
              And where is the problem? The current "Blob" of a Distribution is pain in the ass if you want to distribute a application.

              And you see the benefit if you think some time about it.

              By the Way, you can use for your libarys a own snapshot. so you can patch that one an all other that depent on this one are fixed too. so you don't lose it.
              Last edited by Nille; 01 September 2014, 03:13 AM.

              Comment


              • #37
                yay, snapshot dependencies!

                Comment


                • #38
                  Originally posted by garegin View Post
                  1) One of them is the fact that unless you go with rolling releases you are stuck with the versions of the applications that are shipped with the release.
                  Which is why far more desktop users should use rolling releases... (one of my bigger gripes with trying to help Linux users is that their issue has already been solved upstream.)

                  Comment


                  • #39
                    Originally posted by Awesomeness View Post
                    You apparently don't know that he works for Red Hat and therefore already builds his own distro.
                    Nobody from Debian, Arch, Mageia, etc. has ever been forced to accept code from Red Hat. It's just that those other distributors would then have to work on such technology on their own instead of freeloading Red Hat code which is far more work and probably less fun than flaming on mailing lists.
                    The software is meant to be free and the developers want you to use it and do not despise you for using it. So stop judging others as freeloaders. You only become one, too, and there is no point unless you suddenly want to protest against open source.

                    On the topic: Let us first see where it leads to. If it does become a nightmare as some people fear then it will get dropped again, but at least allow them to try.

                    Comment


                    • #40
                      I read the post, and unlike most Lennart ideas, it actually has some sense in it, at least from the $BIG_VENDOR perspective.

                      I see some unanswered issues in it, mainly those of control. If there is only one GNOME_FOO runtime, who creates it? How can the entire linux world trust that entity to do their job correctly, without backdoors, bugs, or accidental breakage? It would become a single point of failure, and if I were to target malware, that's exactly where I would do so.

                      Secondly, the issue of patches. Say I'm an app vendor. I target the GNOME_56 runtime. During development I discover I need to patch a bug in one of the libs in that runtime. Do I
                      a) wait until $ALMIGHTY_RUNTIME_VENDOR gets off its ass and releases a GNOME_57 runtime? That may not be an option, it may take far too long on their part, or if they do it in time, requiring all users to get it.
                      b) I package a version of it in my app's area. Running afoul of "no bundled libs" policies, depriving other apps of the fix in a shared place.

                      Third, the difference in build options. Since there is only one $ALMIGHTY_RUNTIME_VENDOR, the one runtime clearly cannot be all at once fast, small, supporting old cpus, requiring new cpus, without extra checks, with extra checks, compiled for various stack and security protections, and without those.

                      Comment

                      Working...
                      X