Rendered at 20:03:16 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
orowith2os 12 hours ago [-]
I posted this article three years ago, and some of it is likely due for a rework. Why is it getting brought up again now?
Balinares 11 hours ago [-]
Possibly because the Gnome project has announced a Flatpak-based distribution (if I got that right anyway), which would have brought Flatpak prominently to people's minds again.
ThatMedicIsASpy 10 hours ago [-]
Haven't taken a look (gnome sucks) but to me flatpak based just means its an atomic/immutable distro.
atrokhymchuk 10 hours ago [-]
well, that distribution is for a gnome-devs only, isn't it? it does not have a normal package manager at all as I understood
Vinnl 9 hours ago [-]
It was announced a while back that they were going to look at making it an end-user OS as well. The actual, new announcement [1] says that they've produced the first Preview release for it, with the caveat:
> In all likelihood, GNOME OS Preview will be with us for a few years. However, we are explicitly not promising updates in perpetuity. If you’re not OK with re-installing your OS in a few years to switch to GNOME OS Stable, this is not for you yet. But if you’ve already been curious about giving GNOME OS a try, this is the moment!
I'm sceptical that that brought Flatpak top-of-mind however.
I have no knowledge on the subject, but developing and testing on a distribution only Gnome developers will ever use does seem very on brand for modern Gnome
edg5000 12 hours ago [-]
Every time I tried Flatpak it did not work, always some other problem. Maybe this got fixed nowadays. I did not find it user friendly either, but this could be addressed by the distro.
AppImage actually works and is simple, so I use that.
Snap is trash because autoupdate cannot be disabled without code changes (what?!) last time I checked.
shock 10 hours ago [-]
$ sudo snap refresh --hold=forever
Auto-refresh of all snaps held indefinitely
should work since around April 2025.
atrokhymchuk 10 hours ago [-]
for me flatpak worked _way_ better than snap, after some snap update on arch apparamor or some other _thing_ blocked start of the electron-based snaps (like spotify)
flatpak does have some quirks but (as I see) it works most of the time and it definitely saves time for the developer to package an application
pennomi 8 hours ago [-]
Snap apps also have preposterous security settings, like Inkscape only being able to load SVGs from certain paths on my system. It’s a file editor, it should be able to edit files, period.
Tooster 9 hours ago [-]
AppImage works in the same way downloading a binary from the web and running it with `./program` works. It is dumb simple, but it has really poor integration with the system. I've been using AppImages for several years but the manual churn got to tedious — auto updates, system integration, background services, keeping it tidy. I contributed AppImage packaging workflow to some apps — mechanism itself is messy, supporting other systems is a pain (e.g. core libs between major ubuntu versions can pose a big problem, python apps as well),documentation is poor; even original proponents now advise against this format (citation needed). For some of the AppImages I still have to use (when authors don't distribute anything else), I use GearLever, but it itself is... a flatpak app (and we tried to port it to snap and it was dumb). Bottom line — they are ok-ish but you trade one kind of convenience for other and there is a lot more work on author's side. And a lot of the things about them are messy.
I did full circle of deb -> snap -> flatpak -> app image -> flatpak -> snap + deb + nix nowadays. Flatpak was overwhelming, required flatseal and often theming broke. FS sandboxing and permissions UX was annoying. Ultimately debs are the most convenient ones for now. Snaps get there but the cold boot time and occasional errors annoy me AF (ghostty as snap on fresh boot/after a while opens in several seconds vs miliseconds for deb, which becomes annoying day to day). I wish we had something like perms and portability of .apk + speed of .deb + compression and auto-updates/channels like snap + ease of distribution like AppImage + something from flatpak.
Ultimately on linux(es) I have a everlasting problem of "where shit/problems comes from" and tracking what comes from what and is where.
arcanemachiner 10 hours ago [-]
Basically my thoughts as well. I have used Snap successfully for some projects that are annoying to set up manually (e.g. Nextcloud), but these days, I would probably just use Docker for that.
amelius 11 hours ago [-]
I have similar experiences.
Balinares 10 hours ago [-]
I do like Flatpak, for the most part, though I wish that the distribution and the sandboxing parts of it were not tied at the hip.
The sandboxing would be an easier sell if it allowed interconnections between apps as appropriate. Yes, I do want KeepassXC to be exposed to the KeepassXC extension in Firefox. Yes, I do want yabridge to expose VST instruments to BitWig. We don't want to be hardcoding support for individual pairs of apps either, so the mechanism would have to be generic.
Abstracting away filesystems also only goes so far. Running Filelight sandboxed for instance is just too slow to be useful.
And the distribution would be an easier sell if it allowed for standalone app downloads without going through a centralized hub with dedicated download tools.
Hopefully these are things we'll eventually see solved. Until then, it's still pretty damn good to be able to install many common apps regardless of distro specifics. An easy thing to take for granted, that. Used to be the answer to installation woes was "what's so hard about tracking down every dev dependency and compiling it yourself?" and it's nice that we're firmly moving on from that.
bjoli 3 hours ago [-]
Its amazing they still have emacs on there. The flatpak version is useless for any kind of dev work.
bityard 8 hours ago [-]
> For over 20 years, Linux has been used everywhere, from servers to embedded devices. One area it has been lacking in, however, is the desktop space.
You know, I think I prefer it this way. Things that go mainstream tend to attract the kind of people who think they can improve a product by removing most of the features that made it powerful to begin with. They'll say that simplifying the UX by way of reducing the number of choices the user can make will ease user confusion and make the app easier to maintain as a side benefit. And don't forget, you have to chase the latest UI aesthetic trends coming from big players like Apple, Google, and Microsoft if you want people to think you're still relevant.
I love using Linux on the desktop and dearly hope it never, ever goes mainstream.
pjmlp 12 hours ago [-]
The thing with being around Linux since its early days (Slackware 2.0 in 1996), is that this kind of content regarding Linux Desktop fragmentation and fixes just around the corner gets tiresome.
KDE and GNOME in the 2000's already had everything in place, for vertical application development, frameworks and co, the only part missing was having OEM support for selling ready made systems, instead of reverse engineering hardware all the time.
Instead rebooting the experience, incompatible Gtk+ versions, multiple sound systems, a X Windows replacement that is yet to be widely available,....
Eventually the peace of mind is to use it the headless, time sharing approach that UNIX was developed for, and leave it at it, ssh and Web instead of telnet and X Windows of yore, into servers where OEMs actually care to support their hardware.
oflebbe 10 hours ago [-]
Flatpak is now an indispensible part of my linux setup on debian or an older ubuntu LTS:
Running up-to-date desktop apps like synology-drive, prusa slicer, keepassxc, kdenlive or even Steam at the same time without any conflicting dependencies and configurations tainting the distribution. And if you do not want to use it any more, you can simply remove it with little or even no traces left behind. I love the experience to get these -- including updates -- from within discover (KDE) or gnome-software.
And don't mix flatpak with snap. Different technology, I share mixed feelings about snaps.
eru 9 hours ago [-]
Seems like flatpak helps solve a problem that LTS caused?
oflebbe 9 hours ago [-]
yep
gitowiec 6 hours ago [-]
Yesterday I wanted to download small utility to change Fans Curve in my Lenovo Legion laptop. There was an option to download it with flatpack. When I saw the summary:
- small utility 100kB
- libraries needed to sandbox small utility 1GB
I just $##@#$@&$¡! And I searched more for *.deb package
manvel_hn 12 hours ago [-]
I actually prefer flatpak over snaps if it has been made by original authors of software. Snaps get unusable really fast and have a lot of unexpected problems and inconveniences around the seams.
renegat0x0 12 hours ago [-]
Snaps are centralized, provided by one company. Sorry, but no. It can be 'better' for some reasons, but free software should not be limited to one or few app stores.
0x073 11 hours ago [-]
Snaps are no flatpak.
renegat0x0 10 hours ago [-]
We can analyse if flatpack are security nightmare, but what are alternatives? That was my line of thinking. Complaining without comparing to other solution may not be honest.
Arch-TK 10 hours ago [-]
The article is not critical of Flatpack, it is an endorsement of Flatpack.
jasonvorhe 11 hours ago [-]
From 2023 - is any of this still relevant?
aucisson_masque 13 hours ago [-]
I don’t think the issue is really that api aren’t mature enough or that some developers refuse to use flatpak sandboxing correctly and instead use static permissions.
Linux, Unix and most computers were designed from the ground up as open system where everything can access everything.
It’s absolutely not secure, but that’s not what flatpak is supposed to fix.
Flatpak is supposed to make installations of apps easier by sharing common dependencies across all distributions. That’s all. And in a way, it works.
It has downside even on that, people who have slow internet connection will require hours to download a simple calculator app whereas it took a few seconds before, but it works.
Now on the sandboxing part, you can’t fix a sinking ship with a chewing gum in the hole. The whole structure is not designed to work this way.
It has to come from yet another distribution where permission are enforced at the operating system level, like on macOS. It’s a lot of work, and then you got to get developers on board, so it will never happen and it’s fine. Linux is not macOS, it doesn’t have a trillion dollar company backing it up and it’s not unified.
You got to play with your strength, not your weaknesses.
MattPalmer1086 12 hours ago [-]
Actually, most operating systems were designed as multi-user systems where users cannot access each other's data. Trusted administrators installed software. This made sense in a world of expensive computers that needed to be shared.
In the modern world we do not share our computers with other users, and allow untrusted software to run on our machines from the internet. Without further sandboxing, it would execute as the user with access to everything for that user - which in practice means mostly everything.
throwawayffffas 11 hours ago [-]
> Without further sandboxing, it would execute as the user with access to everything for that user - which in practice means mostly everything.
Which is fine and the reason behind qubes OS decision to have passwordless sudo enabled on qubes.
blablabla123 9 hours ago [-]
Most system installed software can normally not access everything because of the filesystem permissions. It works surprisingly well.
I think the problem is the trend of installing everything in the home directory. Ruby with rvm, Node with nvm/asdf/..., Rust with rustup, ... the list is long and of course related to rapidly changing ecosystems. If the underlying technologies were to strive for more stable designs, you could as well install them in /usr through the distribution's semi-outdated packaging system. In the past this was considered a hallmark of stability, now it's considered a limiting factor.
Of course all these innovations were mostly developed with servers in mind but not so much with Desktop usage.
The other problem with containers on Linux is that they are only sandboxes when configured correctly. Otherwise they can be even worse than no container.
bpfrh 9 hours ago [-]
The security issue has not really anything to do with where you install something, but that when you run something it has access to everything you have.
Linux needs fine grained easy to use permissions, on desktop _and_ servers, there is a reason there is a high investment in container technologies and there is selinux and apparmor.
throwawayffffas 11 hours ago [-]
Just use qubes OS.
jwrallie 11 hours ago [-]
I share the same feelings of other comments.
The only case where I do find Flatpak useful is to install proprietary electron based applications that do not interact with the rest of the system so much, but I try my best to avoid using those in the first place.
vintermann 8 hours ago [-]
Heh, Prism Launcher, the author's example, is the main app I use flatpak for currently. And it works OK, except that I can get some very strange graphical bugs if the NVidia driver updates and I forget to update the flatpak Nvidia runtime.
jauntywundrkind 13 hours ago [-]
I wish I could care less about Flatpak. But they inject themselves into every protocol discussion on Wayland and loudly insist only the flatpak solution is acceptable. That we have to keep using their dbus or whatever they do thinh. They drove off a xfce maintainer in record time who was just trying to discuss how to help their users, with terrible behavior. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
Everyone else is getting off dbus, is working to let the compositor have power, have authority. Dbus is this other system that has some security options but that rarely is well locked down.
And it's just wild to me that there's such ongoing protest against using Wayland protocol development that's so insistent, and it's especially annoying and frustrating seeing it from biased folk like Flatpak who want to make sure there is no discrete source of authority, who want to make sure they can own a chunk of the UX. DBus and their protocols make sure Wayland doesn't become the one way to run a good desktop, that you have to keep having multiple totally different messaging systems going. Fine, I don't begrudge you that as an option, but don't keep road blocking those who want to develop Wayland, please!
madduci 11 hours ago [-]
Alternative to Flatpak and to the counterless adhoc Repositories, what's the most reliable source for getting apps installed under Debian?
roenxi 10 hours ago [-]
The Debian repositories. Debian isn't really trying to lead the charge on making it possible to install arbitrary apps. In fact they're mildly hostile to the idea. The project is trying to build an integrated deb-based operating system.
Joker_vD 9 hours ago [-]
> Debian isn't really trying to lead the charge on making it possible to install arbitrary apps. In fact they're mildly hostile to the idea.
I, for one, welcome our Debian overlords, taking care of stupid users such as myself to protect them from both "arbitrary" applications and from non-obsolete versions of non-arbitrary applications.
And yes-yes, this curated walled-off garden is fine, unlike all others walled-off gardens, because its maintained by "the community" (of Debian maintainers, that is).
iamnothere 7 hours ago [-]
Nix, which works very well under Debian and gives you instant access to the huge nixpkgs repository.
You can also design your own simplified Flatpak-style sandboxing for it using nixpak. There’s other approaches but it’s easy. https://github.com/nixpak/nixpak
flohofwoe 10 hours ago [-]
> We have Android, macOS, and iOS, all with limited access to the system, requiring end-user intervention to access certain resources. But what about the Linux desktop?
The author forgot Windows Vista which started this whole shitshow of granular permission popups ;)
But am I the only one who fundamentally does not want this permission popup crap on a desktop operating system? I explicitly want applications to access the data of other applications or even remote-control other apps, that's the base for building automated workflows where the result is more than the sum of its parts.
Let me define sandbox boundaries for whole groups of applications and special safe locations for actually sensitive data, not require each application to live in its own isolated sandbox.
PennRobotics 9 hours ago [-]
Agreed! I don't want an aggressively locked-down system. I don't want every application sandboxed as the only well-supported offering. I don't want to learn a new paradigm for letting a browser configure an HID device. I don't want to buy a Mac just to have working DAW plugins. I want to have wmctrl scripts (or, on Windows, AHK) at work so that I don't need to manually drag every window for a specific workflow across multiple computers into it's proper position and size.
The Android security model, FWIW, is also annoying as hell to me. You used to be able to translate inline without an always-onscreen "bubble". Most Android implementations will auto-revoke permissions on unused apps. Older apps (like the Neumann microphone app) were feature complete and have no obvious mechanism for remote exploits (it's a special purpose calculator) but will no longer run on modern Android versions "for security reasons". (You can still install the hard way via adb incantations or retargeting the APK to a supported SDK version.) If I use Dmytro Ponomarenko's audio recorder, I can't access recordings using Files, the "easy way" is to click Share and then email files to myself or install a third-party file manager and give it broader access permissions. It's hit-or-miss if password managers detect the entry field in a browser. It took way longer than necessary to figure out how to get an app to read/write an HID device using the Android Developer documentation, and even after specifically targetting one VID/PID in the source code, you still need to verify you want to access your connected device every time you plug it in. Now, signs point toward Android further restricting APK publication and installation?
jillesvangurp 10 hours ago [-]
I'm currently traveling with my spare laptop (a cheap old Samsung). I have Manjaro installed on it. I normally use a mac for work. But I don't like leaving 5K worth of laptop around in random hotels or airbnbs.
I have about 30 years of experience with running Linux. Rarely as my main system (though I did use this particular laptop for a few months in between two macs at some point).
I got rid of both snap and flatpak. I like the idea of those two. But they are just too much of a PITA to deal with. I'd like this stuff to work how it works on my mac: mount .app image, drag the app to the Applications folder and done. On Manjaro, if I want something, I just 'yay <package>' it.
I find it very telling how commercial application developers that actually do explicitly support Linux advertise their Linux support on their websites. Mostly it does not involve the words flatpak or snap. Just not a thing. Generally you'll find some link to a deb, rpm, or tar ball (in that order). And good luck with that. Yay does a fairly good job of converting deb files for use with arch based systems. It's how I installed Chat GPT Desktop on this thing before traveling, for example.
Basically the status quo for commercial application developers targeting Linux is to: 1) ignore distros repackaging other people's software 2) ignore niche package management solutions 3) just cover the basics which is Ubuntu (deb) first and then everything else. Which means you get a deb file, maybe an rpm, and not much else typically. What they typically don't do is work with half dozen app stores, distribution specific repositories, package managers, and other walled gardens to bend over backwards to distribute their software. None of them are large enough to be worth the overhead.
This system kind of works. There's no need for OpenAI to support Manjaro with a Manjaro specific package. Yay can work with a simple deb. All the developers have to do is make sure to statically link the essentials and not make too many distribution specific assumptions.
Ragnarork 8 hours ago [-]
> What they typically don't do is work with [...], package managers
Well they do since they provide a Deb package. One can wonder why this one and not another, and the answer is probably Ubuntu being one of the most widespread distro out there and especially for beginners.
> Mostly it does not involve the words flatpak or snap. Just not a thing.
I think you're underestimating this a bit. Not saying it's a standard or a default, far from it, but commercial applications are sometimes released as flatpaks first and maybe a .deb package second (Geforce Now as a flatpak only, Slack as a snap first, deb second)
philips 13 hours ago [-]
If the author is reading the sidebar covers all content on my iPhone 13
orowith2os 12 hours ago [-]
There is a button along the headerbar that can be used to toggle the sidebar. One of these days I'll get around to making it actually swipe.
aucisson_masque 13 hours ago [-]
Same, just scroll and it dismiss it.
ChocolateGod 10 hours ago [-]
What's stopping Flatpak from using a LSM to allow on-demand permissions like macOS?
VCFundedGenYer 3 hours ago [-]
Flatseal is the answer.
This article is too wordy and too rambling. The resolution is there.
Panzerschrek 10 hours ago [-]
I once tried packaging my application using Flatpack. But I saw no benefits of using it. I can as well just link all my dependencies statically (which I eventually ended using).
grommz 9 hours ago [-]
Now your app comes with embedded vulnerabilities and no sandbox.
Panzerschrek 7 hours ago [-]
My app doesn't require sandboxing. And vulnerabilities aren't important, since it's not intended to work with untrusted data and/or use network.
idonotcare 12 hours ago [-]
This post is 1. deprecated news 2023?!? 2. Wrong 3. Snaps?!?! not on my machine
smitty1e 9 hours ago [-]
My chief grief with flatpak had more to do with the composition policy than the mechanism.
If one's use case for a tool (e.g. QGIS) requires extensions that sit outside of how the flatpak was composed, well, sorry.
> In all likelihood, GNOME OS Preview will be with us for a few years. However, we are explicitly not promising updates in perpetuity. If you’re not OK with re-installing your OS in a few years to switch to GNOME OS Stable, this is not for you yet. But if you’ve already been curious about giving GNOME OS a try, this is the moment!
I'm sceptical that that brought Flatpak top-of-mind however.
[1] https://blogs.gnome.org/adrianvovk/2026/10/16/gnome-os-previ...
flatpak does have some quirks but (as I see) it works most of the time and it definitely saves time for the developer to package an application
I did full circle of deb -> snap -> flatpak -> app image -> flatpak -> snap + deb + nix nowadays. Flatpak was overwhelming, required flatseal and often theming broke. FS sandboxing and permissions UX was annoying. Ultimately debs are the most convenient ones for now. Snaps get there but the cold boot time and occasional errors annoy me AF (ghostty as snap on fresh boot/after a while opens in several seconds vs miliseconds for deb, which becomes annoying day to day). I wish we had something like perms and portability of .apk + speed of .deb + compression and auto-updates/channels like snap + ease of distribution like AppImage + something from flatpak.
Ultimately on linux(es) I have a everlasting problem of "where shit/problems comes from" and tracking what comes from what and is where.
The sandboxing would be an easier sell if it allowed interconnections between apps as appropriate. Yes, I do want KeepassXC to be exposed to the KeepassXC extension in Firefox. Yes, I do want yabridge to expose VST instruments to BitWig. We don't want to be hardcoding support for individual pairs of apps either, so the mechanism would have to be generic.
Abstracting away filesystems also only goes so far. Running Filelight sandboxed for instance is just too slow to be useful.
And the distribution would be an easier sell if it allowed for standalone app downloads without going through a centralized hub with dedicated download tools.
Hopefully these are things we'll eventually see solved. Until then, it's still pretty damn good to be able to install many common apps regardless of distro specifics. An easy thing to take for granted, that. Used to be the answer to installation woes was "what's so hard about tracking down every dev dependency and compiling it yourself?" and it's nice that we're firmly moving on from that.
You know, I think I prefer it this way. Things that go mainstream tend to attract the kind of people who think they can improve a product by removing most of the features that made it powerful to begin with. They'll say that simplifying the UX by way of reducing the number of choices the user can make will ease user confusion and make the app easier to maintain as a side benefit. And don't forget, you have to chase the latest UI aesthetic trends coming from big players like Apple, Google, and Microsoft if you want people to think you're still relevant.
I love using Linux on the desktop and dearly hope it never, ever goes mainstream.
KDE and GNOME in the 2000's already had everything in place, for vertical application development, frameworks and co, the only part missing was having OEM support for selling ready made systems, instead of reverse engineering hardware all the time.
Instead rebooting the experience, incompatible Gtk+ versions, multiple sound systems, a X Windows replacement that is yet to be widely available,....
Eventually the peace of mind is to use it the headless, time sharing approach that UNIX was developed for, and leave it at it, ssh and Web instead of telnet and X Windows of yore, into servers where OEMs actually care to support their hardware.
Running up-to-date desktop apps like synology-drive, prusa slicer, keepassxc, kdenlive or even Steam at the same time without any conflicting dependencies and configurations tainting the distribution. And if you do not want to use it any more, you can simply remove it with little or even no traces left behind. I love the experience to get these -- including updates -- from within discover (KDE) or gnome-software.
And don't mix flatpak with snap. Different technology, I share mixed feelings about snaps.
- small utility 100kB
- libraries needed to sandbox small utility 1GB
I just $##@#$@&$¡! And I searched more for *.deb package
Linux, Unix and most computers were designed from the ground up as open system where everything can access everything.
It’s absolutely not secure, but that’s not what flatpak is supposed to fix.
Flatpak is supposed to make installations of apps easier by sharing common dependencies across all distributions. That’s all. And in a way, it works.
It has downside even on that, people who have slow internet connection will require hours to download a simple calculator app whereas it took a few seconds before, but it works.
Now on the sandboxing part, you can’t fix a sinking ship with a chewing gum in the hole. The whole structure is not designed to work this way.
It has to come from yet another distribution where permission are enforced at the operating system level, like on macOS. It’s a lot of work, and then you got to get developers on board, so it will never happen and it’s fine. Linux is not macOS, it doesn’t have a trillion dollar company backing it up and it’s not unified.
You got to play with your strength, not your weaknesses.
In the modern world we do not share our computers with other users, and allow untrusted software to run on our machines from the internet. Without further sandboxing, it would execute as the user with access to everything for that user - which in practice means mostly everything.
Which is fine and the reason behind qubes OS decision to have passwordless sudo enabled on qubes.
I think the problem is the trend of installing everything in the home directory. Ruby with rvm, Node with nvm/asdf/..., Rust with rustup, ... the list is long and of course related to rapidly changing ecosystems. If the underlying technologies were to strive for more stable designs, you could as well install them in /usr through the distribution's semi-outdated packaging system. In the past this was considered a hallmark of stability, now it's considered a limiting factor.
Of course all these innovations were mostly developed with servers in mind but not so much with Desktop usage.
The other problem with containers on Linux is that they are only sandboxes when configured correctly. Otherwise they can be even worse than no container.
Linux needs fine grained easy to use permissions, on desktop _and_ servers, there is a reason there is a high investment in container technologies and there is selinux and apparmor.
The only case where I do find Flatpak useful is to install proprietary electron based applications that do not interact with the rest of the system so much, but I try my best to avoid using those in the first place.
Everyone else is getting off dbus, is working to let the compositor have power, have authority. Dbus is this other system that has some security options but that rarely is well locked down.
And it's just wild to me that there's such ongoing protest against using Wayland protocol development that's so insistent, and it's especially annoying and frustrating seeing it from biased folk like Flatpak who want to make sure there is no discrete source of authority, who want to make sure they can own a chunk of the UX. DBus and their protocols make sure Wayland doesn't become the one way to run a good desktop, that you have to keep having multiple totally different messaging systems going. Fine, I don't begrudge you that as an option, but don't keep road blocking those who want to develop Wayland, please!
I, for one, welcome our Debian overlords, taking care of stupid users such as myself to protect them from both "arbitrary" applications and from non-obsolete versions of non-arbitrary applications.
And yes-yes, this curated walled-off garden is fine, unlike all others walled-off gardens, because its maintained by "the community" (of Debian maintainers, that is).
You can also design your own simplified Flatpak-style sandboxing for it using nixpak. There’s other approaches but it’s easy. https://github.com/nixpak/nixpak
The author forgot Windows Vista which started this whole shitshow of granular permission popups ;)
But am I the only one who fundamentally does not want this permission popup crap on a desktop operating system? I explicitly want applications to access the data of other applications or even remote-control other apps, that's the base for building automated workflows where the result is more than the sum of its parts.
Let me define sandbox boundaries for whole groups of applications and special safe locations for actually sensitive data, not require each application to live in its own isolated sandbox.
The Android security model, FWIW, is also annoying as hell to me. You used to be able to translate inline without an always-onscreen "bubble". Most Android implementations will auto-revoke permissions on unused apps. Older apps (like the Neumann microphone app) were feature complete and have no obvious mechanism for remote exploits (it's a special purpose calculator) but will no longer run on modern Android versions "for security reasons". (You can still install the hard way via adb incantations or retargeting the APK to a supported SDK version.) If I use Dmytro Ponomarenko's audio recorder, I can't access recordings using Files, the "easy way" is to click Share and then email files to myself or install a third-party file manager and give it broader access permissions. It's hit-or-miss if password managers detect the entry field in a browser. It took way longer than necessary to figure out how to get an app to read/write an HID device using the Android Developer documentation, and even after specifically targetting one VID/PID in the source code, you still need to verify you want to access your connected device every time you plug it in. Now, signs point toward Android further restricting APK publication and installation?
I have about 30 years of experience with running Linux. Rarely as my main system (though I did use this particular laptop for a few months in between two macs at some point).
I got rid of both snap and flatpak. I like the idea of those two. But they are just too much of a PITA to deal with. I'd like this stuff to work how it works on my mac: mount .app image, drag the app to the Applications folder and done. On Manjaro, if I want something, I just 'yay <package>' it.
I find it very telling how commercial application developers that actually do explicitly support Linux advertise their Linux support on their websites. Mostly it does not involve the words flatpak or snap. Just not a thing. Generally you'll find some link to a deb, rpm, or tar ball (in that order). And good luck with that. Yay does a fairly good job of converting deb files for use with arch based systems. It's how I installed Chat GPT Desktop on this thing before traveling, for example.
Basically the status quo for commercial application developers targeting Linux is to: 1) ignore distros repackaging other people's software 2) ignore niche package management solutions 3) just cover the basics which is Ubuntu (deb) first and then everything else. Which means you get a deb file, maybe an rpm, and not much else typically. What they typically don't do is work with half dozen app stores, distribution specific repositories, package managers, and other walled gardens to bend over backwards to distribute their software. None of them are large enough to be worth the overhead.
This system kind of works. There's no need for OpenAI to support Manjaro with a Manjaro specific package. Yay can work with a simple deb. All the developers have to do is make sure to statically link the essentials and not make too many distribution specific assumptions.
Well they do since they provide a Deb package. One can wonder why this one and not another, and the answer is probably Ubuntu being one of the most widespread distro out there and especially for beginners.
> Mostly it does not involve the words flatpak or snap. Just not a thing.
I think you're underestimating this a bit. Not saying it's a standard or a default, far from it, but commercial applications are sometimes released as flatpaks first and maybe a .deb package second (Geforce Now as a flatpak only, Slack as a snap first, deb second)
This article is too wordy and too rambling. The resolution is there.
If one's use case for a tool (e.g. QGIS) requires extensions that sit outside of how the flatpak was composed, well, sorry.