Announcement

Collapse
No announcement yet.

Flatpak 1.8 Released For This Leading Linux App Sandboxing / Distribution Tech

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

  • #11
    You could always write "hello world" on snap so it can run as root. Update it anytime and the end user won't even know.

    Comment


    • #12
      Originally posted by pal666 View Post
      that's 100%, because flatpak shared runtime is subset of native linux(if you try to be smart and create smaller linux, then you can be even smarter and create smaller flatpak runtime)
      My statement wasn't about the relative size of flatpak vs native Linux. It was about the size of native Linux hello world as such (which was wrongly claimed to be above 0.5 GB), without comparing it with flatpak hello world.
      Last edited by atomsymbol; 06-24-2020, 02:20 PM. Reason: Add 0.5 GB

      Comment


      • #13
        Originally posted by pal666 View Post
        native linux hello world is even larger when you add all linux to it(like you stupidly added shared flatpak runtime)
        Since I need the "native linux" anyway, let's just ditch the Fakepak one entirely.

        Comment


        • #14
          Originally posted by atomsymbol View Post

          My statement wasn't about the relative size of flatpak vs native Linux. It was about the size of native Linux hello world as such (which was wrongly claimed to be above 0.5 GB), without comparing it with flatpak hello world.
          You have to forgive pal666 as they are not well known for paying attention to what is posted.

          As for myself, I understand the analogy that you are using. Here's my "back in the old days" experience with "saving space":

          Way back when I needed a simple utility in DOS (as in DOS on a PC) to send a formfeed signal to the attached printer.

          I first tried to write it in Turbo C, but that ended up being a coding mess for a simple task along with including a large (for those days) standard C library in the output binary EXE.

          Then I wrote it in Turbo Pascal, but that ended up with a binary that was like 3KB (smaller than the Turbo C binary EXE), but it's the early 1990s folks and "size mattered" back then. The default standard Pascal unit was the bulk of the binary EXE.

          Then I pulled out my IBM PC BIOS reference manual and a my rarely used IBM PC assembly language programming book. I figured if I focused on exactly what I needed to do, then the final binary should be a "COM" file and not an "EXE" file.

          For those old enough to know the IBM PC memory loading differences between "COM" and "EXE", no explanation is necessary. For those that learned programming in school but never learned this interesting little distinction, get a refund on your degree(s).

          The final result, written in pure IBM PC assembly language using standard IBM PC BIOS calls, was then compiled & linked. The output was an executable binary "COM" file that was less than 100 BYTES in size that loaded very fast (for those days) and did EXACTLY what I needed (send a FF to the printer port and attached printer).

          Perhaps a simple redirect of some ASCII code to the printer port might have done the same thing, but I wanted a simple binary program that would certainly not mess up the batch files that drove the application.

          Comment


          • #15
            Originally posted by uid313 View Post
            You write a Hello World program and it is 45 bytes, then you package it with Snap or Flatpak and then it is half a gigabyte.
            I don't know anything about snaps so won't comment on that, but for flatpak that statement just isn't true. See here:

            Code:
            $ flatpak list -d | grep Podcasts
            Podcasts    Podcast app for GNOME    org.gnome.Podcasts    0.4.7    stable    x86_64    flathub    system    org.gnome.Podcasts/x86_64/stable    acbd5375f3fe    -    11,8 MB    system,current
            That's 11.8 MB for an application significantly more complex than "Hello World!".

            Comment


            • #16
              Originally posted by NotMine999 View Post
              For those old enough to know the IBM PC memory loading differences between "COM" and "EXE", no explanation is necessary. For those that learned programming in school but never learned this interesting little distinction, get a refund on your degree(s).
              Newsflash most developers don't earn their money with MS DOS low end assembler programming, not even low-end at all.

              I want my money back because nobody teached me about even the existence of lisp not to mention the functionality history or anything about it. Also nobody even mentioned Emacs or Vim, I of course knew that they exist because I use linux for >20 years including before college, but especially Emacs is hard to get, it get's advertised as text editor which is like saying a House is a bed, nobody told me that it's a operating system.

              Would loved to find that gem earlier in my live, and not waste 99.9% productivity by using garbage software outside of emacs.

              Comment


              • #17
                Originally posted by moonlite View Post

                I don't know anything about snaps so won't comment on that, but for flatpak that statement just isn't true. See here:

                Code:
                $ flatpak list -d | grep Podcasts
                Podcasts Podcast app for GNOME org.gnome.Podcasts 0.4.7 stable x86_64 flathub system org.gnome.Podcasts/x86_64/stable acbd5375f3fe - 11,8 MB system,current
                That's 11.8 MB for an application significantly more complex than "Hello World!".
                Yeah, 11.8 MB after you installed all the runtimes and dependencies. If you had a clean system, then installed that it would pull down the half a gigabyte of runtimes.

                Code:
                $ flatpak list -d
                … … … Version Branch Arch Origin Installation Ref Active commit Latest commit Installed size …
                … … 19.08 x86_64 flathub user org.freedesktop.Platform.GL.default/x86_64/19.08 393b8b73a7ed - 243,1 MB …
                … … … 1.6 x86_64 flathub user org.freedesktop.Platform.VAAPI.Intel/x86_64/1.6 82006efc71d3 - 8,7 MB …
                … … 19.08 x86_64 flathub user org.freedesktop.Platform.VAAPI.Intel/x86_64/19.08 c315ea075c13 - 37,0 MB …
                … … … 1.6 x86_64 flathub user org.freedesktop.Platform.ffmpeg/x86_64/1.6 d757f762489e - 7,7 MB …
                … … … 2.1.0 2.0 x86_64 flathub user org.freedesktop.Platform.openh264/x86_64/2.0 73f998362a6f - 778,2 kB …
                … … … 1.6 x86_64 flathub user org.freedesktop.Sdk.Extension.rust-stable/x86_64/1.6 635baaf8e4fe - 481,7 MB …
                … … 18.08 x86_64 flathub user org.freedesktop.Sdk.Extension.rust-stable/x86_64/18.08 4e8ef3c492cc - 686,3 MB …
                … … 19.08 x86_64 flathub user org.freedesktop.Sdk.Extension.rust-stable/x86_64/19.08 c0761410a856 - 505,8 MB …
                … … stable x86_64 flathub user org.gnome.Fractal.Locale/x86_64/stable 3253dbbd5b1e - 512 bytes …
                … … … 3.22 x86_64 gnome user org.gnome.Platform/x86_64/3.22 d44159b609a6 - 681,1 MB …
                … … … 3.26 x86_64 gnome user org.gnome.Platform/x86_64/3.26 1b78d7195d9c 552cd113ef7e 938,1 MB …
                … … … 3.28 x86_64 flathub user org.gnome.Platform/x86_64/3.28 6d1d0ebbd724 - 1,3 GB …
                … … … 3.34 x86_64 flathub user org.gnome.Platform/x86_64/3.34 8d75da77300d - 919,7 MB …
                … … … 3.22 x86_64 gnome user org.gnome.Sdk/x86_64/3.22 dd0de2810a73 7ec9b226b95c 1,5 GB …
                … … … 3.26 x86_64 gnome user org.gnome.Sdk/x86_64/3.26 d7758a43d75e e05fa500f556 1,6 GB …
                … … … 3.28 x86_64 flathub user org.gnome.Sdk/x86_64/3.28 31af0c10f8e4 - 2,2 GB …
                … … … 3.34 x86_64 flathub user org.gnome.Sdk/x86_64/3.34 d1513a628521 - 1,9 GB …
                … … 3.26 x86_64 gnome user org.gnome.Sdk.Docs/x86_64/3.26 1df8797de6da 5822c7bb0da9 141,6 MB …
                … … 3.28 x86_64 flathub user org.gnome.Sdk.Docs/x86_64/3.28 3d5283cbaa32 - 141,9 MB …
                … … stable x86_64 flathub user org.gnome.design.Palette.Locale/x86_64/stable 861ff6f7d38e - 512 bytes …
                … … … 3.22 x86_64 flathub user org.gtk.Gtk3theme.Arc/x86_64/3.22 62abe9abf900 - 513,0 kB …

                Comment


                • #18
                  Originally posted by uid313 View Post
                  You write a Hello World program and it is 45 bytes, then you package it with Snap or Flatpak and then it is half a gigabyte.
                  Then you package it using traditional methods and realize it won't work on other distributions or break after update because dependencies are different.

                  Comment


                  • #19
                    Originally posted by dragon321 View Post

                    Then you package it using traditional methods and realize it won't work on other distributions or break after update because dependencies are different.
                    a) you shouldn't be using abandoned software in first place
                    b) if your software isn't maintained anymore, then it must be worth nothing

                    At least I haven't seen or been using any software, that requires ancient libraries

                    AND

                    The frequency in how many distributions change versioning means - people keep updating their systems for the sake of updating, not for the sake of using old software.

                    AND

                    Nobody knows how long flatpaks guarantees you a running runtime on newer linux installations.

                    So at the end flatpak is just another saussage that is hanging in the air - trying to convince people with the "security" and/or "breaking dependencies" kind of garbage, that no one really gives a flying shit for. Its just all a compendium of meaningless words - trying to catch those, who try to believe.

                    Comment


                    • #20
                      Originally posted by uid313 View Post
                      Code:
                      $ flatpak list -d
                      Interestingly, the sizes printed by "flatpak list -a -d" are in some cases different from "flatpak list -d".

                      Comment

                      Working...
                      X