• tony@lemmy.hoyle.me.uk
      link
      fedilink
      arrow-up
      177
      arrow-down
      12
      ·
      1 year ago

      Or actually do anything useful? No network, no filesystem… it’s a hello world app isn’t it…

      • cheer@lemmy.world
        link
        fedilink
        arrow-up
        125
        ·
        1 year ago

        No filesystem access for a flatpak app just means it cant read host system files on its own, without user permission. You can still give it files or directories of files through the file explorer for the app to work with, just that it’s much safer since it can only otherwise view files in its sandbox.

          • FooBarrington@lemmy.world
            link
            fedilink
            arrow-up
            19
            arrow-down
            2
            ·
            1 year ago

            Why does an IDE need unfettered access to my whole FS? Access to the project directory, and maybe the runtime directory, have to be enough.

          • null@slrpnk.net
            link
            fedilink
            arrow-up
            27
            ·
            1 year ago

            As if sandboxes are some brand new concept…

            Of course people want them for some use-cases. No one here is saying that every application in the world should be restricted that way, grandpa.

            • kautau@lemmy.world
              link
              fedilink
              arrow-up
              7
              ·
              1 year ago

              Yeah things like selinux and apparmor have been around for a long time, sandboxing is just an evolution of that

            • grue@lemmy.world
              link
              fedilink
              English
              arrow-up
              5
              ·
              1 year ago

              No one here is saying that every application in the world should be restricted that way, grandpa.

              Maybe not here in this thread, but aren’t there some folks who want flatpak/snap/appimage to basically replace traditional package managers?

              • null@slrpnk.net
                link
                fedilink
                arrow-up
                3
                ·
                1 year ago

                Doesn’t make it a prevailing attitude worthy of whatever nonsense that other guy is spouting.

              • Chewy@discuss.tchncs.de
                link
                fedilink
                arrow-up
                2
                ·
                1 year ago

                […] aren’t there some folks who want flatpak/snap/appimage to basically replace traditional package managers?

                There might be people who think that, but that isn’t realistic. Flatpak is a package manager for user facing apps, mostly gui apps.

                The core system apps will still be installed by a system package manager. I.e rpm-ostree on immutable Fedora or transactional-update/zypper on OpenSUSE MicroOS.

                Snap can do system apps and user facing apps and fully snap-based Ubuntu might come in the future.

                But this won’t force people to use them. Traditional package managers will keep existing for system apps and maintainers will proabably keep their gui packages in the repos.

      • IverCoder@lemm.eeOP
        link
        fedilink
        English
        arrow-up
        24
        ·
        1 year ago

        There’s Obfuscate, an image redactor, and Metadata Cleaner which is self-descriptive. Both works properly without any filesystem access at all, because they use the file picker portal to ask the user for the files to be processed.

    • Empricorn@feddit.nl
      link
      fedilink
      English
      arrow-up
      42
      arrow-down
      5
      ·
      1 year ago

      Oh come on, what modern program actually needs to communicate or access the file system?

    • IverCoder@lemm.eeOP
      link
      fedilink
      English
      arrow-up
      24
      ·
      1 year ago

      The app can then declare the network permission and it will still be marked as safe.