Announcement

Collapse
No announcement yet.

Flatpak 1.5.1 Prepares For Protected/Authenticated Downloads - Future App Purchasing

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

  • #21
    Originally posted by Candy View Post

    Last question:

    Will it be enforced to users the same agressive way as done with GNOME, pulse-audio and systemd ?

    Explaining the word "agressive" here:

    ... by making everything else created by others look as if it's broken or not existing ...
    I should of figured out there'd be no chance of an intellectual conversation.

    Comment


    • #22
      Originally posted by 144Hz View Post
      Volta Snap is not going away. Canonical just added a Trello board dedicated to Snap. Lots of resources goes down this drain.
      Really Canonical is known for putting a lot of resources into projects that long term end up going no where.

      Good question 144Hz is how much work is happening on snap that is does not depend on reaching into Canonical coppers all the time. That Trello board does not have any non Canonical people on it.

      Comment


      • #23
        Originally posted by Candy View Post

        So at the end... we'd better stay with the packages that we get with the distribution...

        a) they are really flat (no need of hundrets of megabytes of runtimes)
        b) no excessive linking and directory creating in /var/lib/flatpak
        c) it simply works and is more convinient even for normal users to grab packages and updates from their distributions rather than entering cryptic command line parameters that usually ends in problems.
        So to run legacy applications we have to go the chroot route by distribution???



        Distribution packages have one form of deduplication. Flappak is using a different one.

        Distributions package management has deduplication between applications and libraries of the current version.

        Flatpak has deduplication between runtimes and applications of different versions.

        The distribution chroot route lead to way more disc usage than the flatpak route.

        Of course you may want to do your distribution on ostree for the deduplication between versions but you will then need a ostree directory hello something like /var/lib/flatpak

        b statement is false. http://docs.flatpak.org/en/latest/fl...k-installation /var/lib/flatpak is a default it is in fact override-able and changeable.

        C statement is also kind of false thinking the current distribution method does not work like when you need the newest firefox and older version of firefox at the same time. Because distribution method say you may only have 1 version of a package installed. Flatpak you have at least 1 version per installation directory and you are allowed many of those as you need. Basically there are limits to current distribution packaging and this is why flatpak/snap/oinstall/nix exist.

        Comment


        • #24
          Originally posted by oiaohm View Post

          Really Canonical is known for putting a lot of resources into projects that long term end up going no where.

          Good question 144Hz is how much work is happening on snap that is does not depend on reaching into Canonical coppers all the time. That Trello board does not have any non Canonical people on it.
          Unfortunately they're pushing Snap a lot harder than their other projects, which is bad because unlike upstart, unity, mir etc, it directly affects other distributions and they're trying to place themselves as the gatekeeper to the Linux app ecosystem.

          Which is bad, super bad.

          You search for "Fedora Spotify" and you get a Fedora-themed Snap page (which is hugely unethical), even though a Fedora user, the Flatpak or RPM will be superior to the Snap. Imho the biggest threat to Linux has never been Microsoft, but Canonical.

          Comment


          • #25
            Originally posted by 144Hz View Post
            Volta Yes, Snap work is down the drain. I guess Canonical also prefers to keep it in-house for now. This way they keep copyright of all work and that might be a smart thing to do if you plan a big IPO in H2 2020.
            Or you're just trying to get your company bought.

            Comment


            • #26
              Originally posted by 144Hz View Post
              Britoid Flatpaked GNOME apps might even come as a single pak for mobile and desktop.

              True convergence at package level.
              How? By compiling the applications to WebAssembly?

              But will the FlatPack WebAssembly executor require PulseAUDIO, System-D and Mutter?

              Comment


              • #27
                Originally posted by archsway View Post

                How? By compiling the applications to WebAssembly?

                But will the FlatPack WebAssembly executor require PulseAUDIO, System-D and Mutter?
                You may think you look clever, but you actually look like an idiot.

                Comment


                • #28
                  Sweeeeeeet. Just in time for us. We're about to start releasing commercial plugins to our open-source product, and this will obviously make it easier for us to manage.

                  Comment


                  • #29
                    Originally posted by starshipeleven View Post
                    It's not a VM, it's all run on the same kernel, they are just pulling libraries from their own runtime instead than taking the system libs.
                    Exactly, which means it wastes 100s of MB of memory because shared objects cannot actually be, you know, shared...

                    Thanks Obama!

                    Comment


                    • #30
                      Originally posted by Britoid View Post

                      You may think you look clever, but you actually look like an idiot.
                      Ok then smartypants, can you give me a detailed analysis on how Flatpaked GNOME apps would be delivered a single pak for mobile and desktop, before the obviously inevitable domination of RISC-V, without requiring even more hundreds of megabytes of space, and without being compiled for a VM or being rewritten in JavaScript?

                      I'd also like to hear why you think that it is idiotic to presume that gNOME developers would not bother thinking the slightest about compatibility for anything they didn't write.

                      Oh, and why do you gNoMe users have to get so upset about the CaPiTilizaTiOn of words?
                      When was the last time you heard anyone complaining about someone writing "QT"?

                      Comment

                      Working...
                      X