[HN Gopher] Flatpak Is Not the Future
___________________________________________________________________
Flatpak Is Not the Future
Author : Thin_icE
Score : 329 points
Date : 2021-11-23 09:25 UTC (13 hours ago)
(HTM) web link (ludocode.com)
(TXT) w3m dump (ludocode.com)
| PaulHoule wrote:
| Nice to see some effort to stop the Docker insanity. It's a great
| way to download 2GB on a slow interest so you can use a 200kb
| piece of software.
| hermitcrab wrote:
| I write commercial applications in Qt/C++ for Windows and Mac.
| People do ask me about Linux versions. It would be relatively
| straightforward to port the code to Linux. But the mess of
| different distributions and libraries really puts me off.
|
| Is anyone here distributing a commercial Qt/C++ app on Linux? Are
| you using Flatpak or something else?
| jcelerier wrote:
| Vouching for AppImage too, I ship https://ossia.io like that
| hermitcrab wrote:
| Ossia looks impressive. Does it use Qt or some other GUI
| library?
| jcelerier wrote:
| Yes, it uses Qt for the GUI. Thanks ^_^
| hermitcrab wrote:
| I am very out-of-the-loop on Linux. Your download page
| says:
|
| "Your system must have at least glibc-2.17, as well as
| X11, ALSA, libGL, librt, libdbus."
|
| What rough percentage of modern Linux computers would you
| say that covers? 99%, 90%, 50%?
| jcelerier wrote:
| Should be very close from 90%. Anything >= Ubuntu 14.04
| (just tested it quickly through docker) or CentOS 7 (on
| which the builds are done) should work
| cromka wrote:
| Just use AppImage. They can download it as-is from your website
| and simply run locally. No need to deal with distributions and
| their package managers.
|
| EDIT: if you use CMake, which I guess you do, you can
| integrated it using CPack and an external generator:
| https://github.com/AppImage/AppImageKit/issues/160#issuecomm...
| hermitcrab wrote:
| I will put AppImage on my todo list to check out. Thanks.
|
| I still use qmake (old school!).
| yyyk wrote:
| >They should... Build a fine-grained user-interactive runtime
| permission system that requires the app to make Flatpak-specific
| API calls to activate permission dialogs
|
| What the article wants is useless without fixing Linux's security
| modules. Very few people know how to use SELinux or AppArmor,
| there's no standardization between distros and apparently even
| RedHat has given up.
|
| Flatpak and Snap do containerization because they have no good
| alternative.
|
| P.S.
|
| >If I ship an app for Windows I don't have to include the entire
| Win32 or .NET runtimes with my app.
|
| Note that Microsoft has been moving away from that with .NET
| Core/.NET. The new runtime does not come with the OS. It's still
| possible to create a package and have .NET installed separately,
| but as far as I can tell, most people prefer to package with the
| runtime.
| smallerfish wrote:
| I agree that the implementation is lacking. Snap has the
| abysmally named "--classic" parameter to allow installs to "run
| without confinement". Flatpak can request permission changes at
| install time (albeit declaring them), where users are likely to
| just click OK/OK/OK. The sandboxing needs to be tightened up.
|
| Flathub is a strange beast. There's no mention of security on
| their wiki. They stopped publishing minutes (or moved them
| elsewhere?) in 2017 (https://github.com/flathub/flathub/wiki).
| They have a buildbot for automated updates from developers, but
| they accept binaries anyway (e.g.
| https://github.com/flathub/us.zoom.Zoom/blob/master/us.zoom....),
| so what's the point? It appears to be a fairly amateur effort,
| and yet is at the center of the infrastructure Red Hat and Gnome
| are pushing. I'd love to see some white hat activity targeted at
| compromising it, to demonstrate the shaky foundations.
|
| But on the other hand, it's nice that I can run Zoom sandboxed
| (apparently - it's not obvious what the granted permissions are:
| https://www.flathub.org/apps/details/us.zoom.Zoom). It's nice
| that Jetbrains and Zoom have a way to publish apps that can run
| on all distros. It's nice that I could rollback a version of
| IntelliJ that was buggy with a single snap command that took 5
| seconds. The goals are good.
|
| I wish Linus took more of a BDFL approach to the desktop
| occasionally. Ubuntu & Red Hat need to sit down in a room and
| have a constructive conversation to converge Snap and Flatpak
| into something new, deprecating the infrastructure built to date,
| and fixing some of the glaring problems. There's room for both to
| make money without further diverging the ecosystem.
| bboozzoo wrote:
| > Snap has the abysmally named "--classic" parameter to allow
| installs to "run without confinement".
|
| Only if the snap was built with classic confinemnt in mind.
| Otherwise, just slapping --classic on a random snap does
| nothing, there's even a warning display about that. Classic is
| very much the same as a random 3rd party vendor app built and
| unpacked under /opt. Unfortunately some software, especially
| IDEs and languages are unsuitable for running under confinement
| and need to be distributed this way. By passing --classic you
| give your consent to use an app package in this sub-par way.
|
| FWIW, perhaps you meant --devmode, which as the name implies is
| mostly for developing a snap? snap install --help describes
| that as: --devmode Put snap in development
| mode and disable security confinement
| smallerfish wrote:
| > especially IDEs and languages are unsuitable for running
| under confinement and need to be distributed this way
|
| I think the solution to that should be something other than
| removing the sandbox. I see "portals" referred to elsewhere
| in this thread w.r.t. flatpak; does snap not have similarly?
|
| > By passing --classic you give your consent to use an app
| package in this sub-par way.
|
| Sure, but it's a terrible name. It should be --unsandboxed or
| --fullaccess. "Classic" sounds like a mode you'd want.
| bboozzoo wrote:
| > I think the solution to that should be something other
| than removing the sandbox. I see "portals" referred to
| elsewhere in this thread w.r.t. flatpak; does snap not have
| similarly?
|
| Snaps use portals like flatpaks do. The problem is more
| about frameworks you build applications with not being
| ready to consume portals. Turns out only some reasonably
| recent Qt versions can work with portals. IIRC Electron
| only landed support couple of months ago. Back on the host
| side of confinement, you need to run a reasonably recent
| xdg-desktop-portal (and a maching GUI integration bit).
| Some old distros do not provide any of those packages or
| ship version that don't work, so things are DOA.
| IiydAbITMvJkqKf wrote:
| the flatpak sandbox UX is bleak. right now, you have to check
| the JSON file you linked to check how much access a flatpak
| program gets. i disagree with the --own-name and --talk-name
| flags (i think this is for screensharing; zoom should use the
| screensharing portal instead. letting zoom talk to gnome shell
| directly could be bad.).
|
| --socket=x11 is a massive hole in the sandbox, since x11 does
| not have a security model - any client can observe and
| manipulate any other client. for x11, a viable solution would
| be running flatpak apps in xephyr, but flatpak doesn't do that.
| long-term, wayland is a better solution.
| teddyfrozevelt wrote:
| It's not really that bad. You are told the permissions
| requested by an app on installation: $
| flatpak install flathub com.microsoft.Teams
| com.microsoft.Teams permissions: ipc network
| pcsc pulseaudio x11 devices file access [1]
| dbus access [2] tags [3] [1] xdg-
| download [2] org.freedesktop.Notifications,
| org.freedesktop.secrets, org.gnome.SessionManager,
| org.kde.StatusNotifierWatcher [3] proprietary
| ID Branch Op
| Remote Download 1. com.microsoft.Teams
| stable i flathub < 86.0 MB
| Proceed with these changes to the system installation? [Y/n]:
|
| and you can query an apps permissions at any time:
| $ flatpak info --show-permissions com.discordapp.Discord
| [Context] shared=network;ipc;
| sockets=x11;pulseaudio; devices=all;
| filesystems=xdg-download;xdg-pictures:ro;xdg-videos:ro;home;
| [Session Bus Policy] org.kde.StatusNotifierWatcher=talk
| org.freedesktop.Notifications=talk
| com.canonical.AppMenu.Registrar=talk
| com.canonical.indicator.application=talk
| com.canonical.Unity.LauncherEntry=talk
|
| GNOME Software in GNOME 41 also has a much better list of
| permissions than the version shown in this article.
|
| https://blogs.gnome.org/tbernard/2021/09/09/software-41-cont.
| ..
| esarbe wrote:
| Try this to manage application permissions:
| https://flathub.org/apps/details/com.github.tchx84.Flatseal
| kirbyfan64sos wrote:
| > right now, you have to check the JSON file you linked to
| check how much access a flatpak program gets
|
| In general, GUI package managers w/ Flatpak support show you
| the permissions, as does the CLI upon an attempted install.
| asoneth wrote:
| A good illustration of why easy wins every time.
|
| In my experience, Flatpack and their ilk make it easier for end-
| users to install applications and for developers to distribute
| them.
|
| Alternatives may be orders of magnitude better from a
| performance, size, and/or complexity standpoint but until they're
| at least as easy for both end-users and developers they'll never
| reach critical mass.
| kiryin wrote:
| I dunno. I had my doubts for the longest time but recently I've
| started, little by little, placing my bets on Flatpak. Snap can
| go to hell, for reasons exhaustively discussed here and
| elsewhere, but Flatpak is reasonably solid, open and performant
| technology that fits the problem it's trying to solve. I wouldn't
| mind if it takes over the distribution of big, GUI desktop apps
| on linux.
| 1_player wrote:
| The fact that Valve ships the Steam Deck with a read only root
| managed by ostree and user apps installable via Flatpak to me
| shows the direction of future Linux desktop, and I welcome it
| wholeheartedly. I am done with distro managed packages for
| desktop apps, custom patches and the impossibility to ship
| closed source software on Linux because it's a mess.
|
| Flatpak in my book rocks, and it's ahead of macOS DMG files and
| light years ahead of the Windows .exe downloaded from the
| Internet strategy.
| boudin wrote:
| There quite a few things I don't agree with in regard of this
| article.
|
| First, the suggestion that permission should be prompted when
| running the app, the app using some sort of API. This would mean
| that Linux app should become tightly coupled to Flatpak. I have
| no idea how it would be possible to convince all developers,
| distributions, vendor to adopt Flatpak. I think it would be
| largely ignored so an ineffective way to bring those change to
| the Linux ecosystem in the end.
|
| Then, I don't have the real answer, but prompting users with
| questions when they use the app is the worst approach to
| security. Being tech literate helps understanding what's
| happening, but people with less understanding answer those out of
| annoyance because they're trying to do something and, all of a
| sudden, the operating system gets in the way. The choice is not
| driven by security concerns but by frustration or urgency.
|
| I can't think of any operating system that found the right
| solution yet, but I do think that the Flatpak approach is by far
| the smartest. Just naturally give access to things by following
| user choices (just give access to the select file once the file
| is selected, just give access to the screen the user choose to
| share once the user choose to share it). No more stupid prompt
| that gets in the way of things.
|
| Speaking of runtimes, it's exactly the same problem. For Flatpak
| to be adopted, it would require all distribution to invest a lot
| in it. How would it work for Gentoo and its use flags for
| example? How to deal with different versions of dependencies?
|
| What would happen would likely be for distribution to build the
| equivalent of runtimes, but on their side, allowing to have
| several versions in parallel. So in the end, it would be a
| similar situation, but much more messy as each distribution would
| have to do the job. Is having those runtimes an actual problem or
| the solution that Flatpak came up with to the problem of
| fragmentation in distributions? In my opinion it's the second.
| Edwar wrote:
| Thanks for sharing such a helpful instruction, really appreciate
| for your article.
|
| https://www.garagebandapp.net/
| exikyut wrote:
| Put me in the screenshot sideways!
|
| (For clarification, this is bot spam, and in a couple minutes
| this will be [dead] and unrepliable. So... hi, world, while I
| can. :P)
| faho wrote:
| > How much progress could we make if Steam deprecated their
| runtimes, abandoned containerization for new games, and let all
| new games just use the native system libraries? How loudly do you
| think gamers would complain if a distribution upgrade broke their
| favourite game?
|
| If the steam runtime didn't exist, most gamedevs would only
| target the most popular distro - probably the current Ubuntu LTS,
| and you would have to recreate the runtime on your distro of
| choice.
|
| And once there's a new Ubuntu release you would also have to
| recreate it there (or the game updates and now you'll have to
| recreate it on the now-old version).
|
| The choice isn't between steam runtime and a utopia, the choice
| is between the steam runtime and something much _worse_. Linux
| libraries simply aren 't stable enough in API and ABI.
| southerntofu wrote:
| Yet the steam runtime could be maintained/distributed using a
| more robust and explicit mechanism such as guix or nix, don't
| you think?
| bogwog wrote:
| Guix is a great solution to this problem. It's a shame that
| there aren't any distributions based on it (afaik) besides
| the official GNU one, which is not very practical outside of
| a VM due to their aversion to anything proprietary.
| dxuh wrote:
| And realistically if they could only target a single distro,
| they would likely not bother making Linux builds at all.
| sandGorgon wrote:
| The short (but polite) rebuttal to this is - OSX. DMG files are
| similar sized and proven to be very successful.
|
| For e.g. - firefox (https://www.mozilla.org/en-
| US/firefox/all/#product-desktop-r...). Win64 installer is 50mb.
| MacOS installer is 130mb. Linux 64-bit is 70mb.
|
| Same is the case with Chrome -
| https://chromeenterprise.google/intl/en_US/browser/download/... .
| Windows MSI is 79mb. OSX PKG for the same is 195mb.
|
| So by that measure - OSX has already lost right ? The entire
| package-everything-together has won in probably one of the
| largest OS ecosystem that exists today. Size does not matter...
| mom-proof experience does matter.
|
| > _How much progress could we make if Steam deprecated their
| runtimes, abandoned containerization for new games, and let all
| new games just use the native system libraries? How loudly do you
| think gamers would complain if a distribution upgrade broke their
| favourite game?_
|
| This OTOH does not exist. Linux gamers are 1% of either the
| gaming market or the desktop computing market. All gamers either
| dual boot windows...or android. Even for those who game on Linux,
| they do it on an abstraction layer like Wine. Which is what Valve
| maintains - https://github.com/ValveSoftware/wine and
| https://github.com/ValveSoftware/Proton
|
| Valve only needs to maintain wine & proton for a distribution.
| The games themselves ? well, they are windows only. Nobody
| compiles for Linux.
| AnIdiotOnTheNet wrote:
| Yeah, really. OSX DMG's contain AppBundles, a concept OSX
| inherited from NeXT. NeXT wasn't the first implementation of
| the idea either, in fact pretty much every non-unix desktop OS
| ever released used some variation of the concept including DOS
| and the original Mac.
|
| Sadly, it seems the Linux world just can't wrap its head around
| the idea of managing applications with the same simple
| mechanisms we use to manage regular every day files. It would
| seem that Linux Desktop users just love having inflexible
| management tools do it instead. Well, there is AppImage, but
| unfortunately its use is not wide spread.
| thereddaikon wrote:
| "Sadly, it seems the Linux world just can't wrap its head
| around the idea of managing applications with the same simple
| mechanisms we use to manage regular every day files. It would
| seem that Linux Desktop users just love having inflexible
| management tools do it instead. Well, there is AppImage, but
| unfortunately its use is not wide spread."
|
| Seems to me they love treating application management like
| one manages dependencies in a software project. There are a
| lot of parallels with the paradigm. Its clear where the
| notion came from. And I think in the context of unix/linux
| history it makes sense. If I were an MIT grad student in 1978
| there probably isn't much difference between a library and an
| application practically.
|
| But that was over 40 years ago. There is a clear distinction
| now and the overwhelming majority of PC users are not MIT
| grad students. Applications should be easy to install. People
| don't care that there is more than one version of some
| dependency. They don't care that your repro doesn't have what
| they want. They have work to do.
| wink wrote:
| osx can do this because "osx" is about as specific as "Ubuntu
| 20.04 LTS", so 90% of the problems that were described in the
| article wouldn't happen because there aren't many osxes.
|
| I personally don't use it, so I can't tell how good the story
| is with 2 different versions. I've heard lots of upgrade
| troubles from mac users when a new OS release comes out, but
| maybe the authors are usually better in keeping a version for
| current-1 around, or the latest version compatible with
| current-1? Then it's still only 2 versions and not 10 distros.
| guerrilla wrote:
| > Valve only needs to maintain wine & proton for a
| distribution. The games themselves ? well, they are windows
| only. Nobody compiles for Linux. All gamers either dual boot
| windows...or android. Even for those who game on Linux, they do
| it on an abstraction layer like Wine
|
| This isn't true at all. I'm afraid you've misunderstood the
| situation. Get on steam and check for yourself. There are many
| games compiled for Linux specifically (in addition to other
| platforms) that do not require proton. They use some ubuntu or
| debian packages for their libraries and have no linkage to
| anything windows.
| hules wrote:
| Firefox is larger on macOS because it contains 2 archs (x86_64
| and arm64), not because it bundles of full runtime -- also the
| compression algo of dmg files is typically quite bad (zlib or
| bzip2), which is not helping.
| argsnd wrote:
| I didn't think that binaries would take up so much space, but
| Firefox 83 (the last x86-only release) is 73MB vs Firefox 84
| (the first universal release) which is 126MB. Wow, I guess
| that makes sense then.
| Gigachad wrote:
| Firefox would be a bigger codebase than the whole Linux
| kernel so it makes sense.
| addicted wrote:
| That still does not change the argument that file size does
| not matter.
|
| In fact, this reinforces it. OSX believes file size matters
| so little they're willing to double file size simply so users
| don't have to pick x64 or x86 when downloading the app (and
| if they're using the App Store the App Store could do it for
| them, but even that Apple thinks is too much complexity).
| yoz-y wrote:
| Not sure about MacApp Store, but on iOS they do trim archs
| and assets as needed.
| plorkyeran wrote:
| That's a surprisingly recent addition on iOS, and it
| appears to not have made it to macOS.
| pas wrote:
| Folks who have the money for Apple stuff have money for
| large SSDs and fast unmetered Internet.
|
| Aaaand folks who live in the Apple universe have been
| accustomed to accept that they are holding it wrong, and
| that there's someone whose job is to figure out what's the
| official best way to do things. If it involves downloading
| 130 megs it's 130 megs. No problem. The UX and end result
| is worth it for them.
| asoneth wrote:
| I have used Monolingual[1] on past laptops to remove
| unnecessary architectures from installed OS X applications
| when disk space was running low.
|
| Having said that, I never bothered installing it on my
| current laptop which sort of reinforces the point others are
| making about being less concerned with application size.
|
| [1] https://ingmarstein.github.io/Monolingual/
| pfranz wrote:
| Thanks for that! I quickly poked around at my Firefox install
| on MacOS. Firefox.app is 353M. The largest single file in
| there is Firefox.app/Contents/MacOS/XUL (binary) and that's
| 258M. Of that, lipo says 136165680 is x86_64 and 134106096 is
| arm64. My Firefox folder in Windows is 208M.
| galcerte wrote:
| > This OTOH does not exist. Linux gamers are 1% of either the
| gaming market or the desktop computing market. All gamers
| either dual boot windows...or android. Even for those who game
| on Linux, they do it on an abstraction layer like Wine. Which
| is what Valve maintains
|
| First off, 1.13% of _Steam_ users are on Linux [1], and given
| how many users Steam has, just 1% of that population should be
| able to make quite a fuss. Secondly, Valve does need those
| containerized runtimes even if most games run on Proton, since
| Proton also depends on those libraries, so not sure why you 're
| dismissive...
|
| [1]: https://www.phoronix.com/scan.php?page=news_item&px=Steam-
| Li...
| andrepd wrote:
| That just not true. "All Linux users dual boot" where's your
| data to say that? "Nobody compiles for Linux" factually false,
| many of the most-played games on steam are Linux-native, and
| most others run flawlessly on Proton.
|
| And 1.2% is slightly more than half the mac market share on
| steam. Should mac users also be ignored?
| faho wrote:
| >"Nobody compiles for Linux" factually false, many of the
| most-played games on steam are Linux-native, and most others
| run flawlessly on Proton.
|
| The games that run on proton have _not_ been compiled for
| linux.
| gnulinux wrote:
| E.g. factorio is compiled for linux.
| faho wrote:
| Yes, linux-native games exist.
|
| But games that run on linux via proton have _not_ been
| compiled for linux, so mentioning them as a counter-
| argument to games not being compiled for linux makes no
| sense.
|
| The broader context here is TFA rejecting the "steam
| runtime" idea, and for proton-based games proton _is_
| that runtime! They don 't need anything from the system
| because proton/wine provides it.
| homarp wrote:
| linux native + proton means "some compiles for Linux[1],
| the rest either tests on proton (steamdeck should increase
| that segment at least) or does not care"
|
| [1] https://news.ycombinator.com/item?id=28978086
| panick21_ wrote:
| > If you are a Linux distribution maintainer, please understand
| what all of these solutions are trying to accomplish. All your
| hard work in building your software repository, maintaining your
| libraries, testing countless system configurations, designing a
| consistent user experience... they are trying to throw all of
| that away. Every single one of these runtime packaging mechanisms
| is trying to subvert the operating system, replacing as much as
| they can with their own. Why would you support this?
|
| This sound like a luddite that is against machines. How about
| embrace the revolution and then you can save a huge amount of
| work and focus on other things. There are enough things distor
| people could focus on instead.
|
| I don't buy any of the technical arguments here and it sounds
| mostly like moralizing argument rather then anything else.
| ltbarcly3 wrote:
| The whole point is that this is technically worse and only
| being used to try to bootstrap a walled garden where they
| (RedHat, Canonical for flatpack or snap) get paid a fee due to
| a monopoly on app distribution to their users. This is not 'the
| revolution' we should support. I encourage you to study the
| technical arguments until you understand them well enough that
| they become convincing.
| panick21_ wrote:
| > monopoly on app distribution to their users
|
| And the argument that it is a walled garden is simply
| nonsense. Its not monopoly any more then any default
| repository is.
|
| > I encourage you to study the technical arguments until you
| understand them well enough that they become convincing.
|
| I have been using flatpak since it came out and many other
| people in this thread have already pointed out the failure of
| the technical arguments, no need to do that again.
| southerntofu wrote:
| > This sound like a luddite that is against machines.
|
| The luddites were not anti-tech from a moral perspective, but
| understood mechanization of work to profit the bosses and go
| against the interests of workers (artisans) and therefore
| practiced sabotage. Despite this initial mischaracterization, i
| believe the metaphor holds and the author is against this
| application of this technology precisely because they believe
| it produces a net negative impact across the ecosystem.
| panick21_ wrote:
| Sure, I agree with your interpretation of luddites
| historically.
|
| However I still think moral is the right word. The
| consequences are consider amoral. So its is very much a moral
| perspective.
|
| And I think the argument that it is bad for the ecosystem is
| fundamentally wrong.
| edent wrote:
| I agree with all of this and... I just don't care.
|
| I download a Flatpak from the Pop OS store and it works. It
| installs only in my profile, so another user on the same machine
| doesn't have access. You can't do that with a .deb!
|
| I've never got into dependency hell where I need to apt-get a
| specific version of a library from a dodgy PPA.
|
| If I uninstall it, Flatpak doesn't leave acres of cruft strewn
| around my disk.
|
| I don't see how randomly installing a Flatpak is any worse for
| security than compiling the source myself. The permission model
| on Linux is far worse than Android - so I just hope for the best
| anyway.
|
| Snaps never worked right for me - and seemed to frequently break.
| But all my Flatpaks have run fine and at full speed.
|
| Does it take up more disk space? Sure. But that's a trade-off I'm
| willing to make in order to just download and run with no extra
| work.
|
| Sure, there are some efficiency and security gains to be made.
| But I'm much happier with a Flatpak world than the alternative.
| capableweb wrote:
| > You can't do that with a .deb!
|
| Pretty sure you can by doing "dpkg --root=$HOME -i
| mypackage.deb" or something like that, long time ago I used
| dpkg, but it should be possible with some flag.
|
| Otherwise I agree, Flatpak is a breath of fresh air!
| kirbyfan64sos wrote:
| This often doesn't really work in practice on its own at
| least, since packages tend to hardcode their in installation
| directories. (You could try using an overlayfs, but at that
| point it's becoming pretty cumbersome.)
| goohle wrote:
| You can recompile package from source to support
| installation into `~/.local` (see `man 7 file-hierarchy`),
| but burden to support this will be on you, including
| updates, protection from malware and viruses, firewalling,
| and so on.
|
| For example, rust's cargo can compile and install
| applications into `~/.local`, but it's pain to keep them up
| to date, so I prefer to use same tools from my OS (Fedora)
| distribution repo instead.
| johnchristopher wrote:
| Where does that put the Deb files ?
|
| edit: should have written "where does dpkg put the files of
| the package ?" or "where does that put the Deb's files ?",
| sorry.
| capableweb wrote:
| The .deb file should remain where it was when you
| downloaded it, dpkg just installs the contents of the .deb
| file.
| johnchristopher wrote:
| Where is the contents of the .deb files put?
| adwn wrote:
| Is there a point you're trying to make, or are you asking
| for technical information which would be better answered
| by _man dpkg_ or a quick Internet search?
| johnchristopher wrote:
| I am not trying to make any point, I am genuinely curious
| where dpkg is going to put those files since its the
| first time I read you can dot `dpkg --root=$HOME -i
| mypackage.deb`.
|
| For instance I always do `python3 -m pip install --user
| wormhole` or `pip install --user wormhole` instead of
| sudoing my way to permissions hell. Python apps get
| installed in $HOME/.local/bin, so no cruft for other
| users.
|
| But stuff installed with deb packages often have hard
| coded pathways and assumptions of where and how their
| files are run.
|
| So I think it's fair to ask in reply to someone implying
| that `dpkg --root=$HOME -i mypackage.deb` is as
| clean/same as a flatpack behaviour _" It installs only in
| my profile, so another user on the same machine doesn't
| have access. You can't do that with a .deb!"_... It's
| fair to ask "where do those files in the deb package go
| ?" because if it works as implied (no pollution of the
| OS) I am certainly going to start testing installing
| things that way.
| foxfluff wrote:
| --root=dir Set the root directory to
| directory, which sets the installation
| directory to <<dir>> and the administrative
| directory to <<dir/usr/local/var/lib/dpkg>>.
| jasode wrote:
| _> Pretty sure you can by doing "dpkg --root=$HOME -i
| mypackage.deb" or something like that, _
|
| As a sibling comment already noted, using _" --root"_ doesn't
| always work and a q&a mentions the problems:
|
| https://askubuntu.com/questions/28619/how-do-i-install-an-
| ap...
|
| https://serverfault.com/questions/23734/is-there-any-way-
| to-...
| enriquto wrote:
| > it works
|
| No. It doesn't. You still need to trust the people who package
| the thing.
|
| A working packaging system would give the user ultimate power
| to manage access to resources by each app. Overriding or
| mocking, if the user so decides, whatever access does the app
| believe to need. Flatpack does not give you such power, it
| removes this power from you and assigns it to the packagers.
| Thus, not only it doesn't work: it works _against_ you!
|
| EDIT: The "dependency hell" issue is separate, and is solved
| more easily by distributing static binaries.
| Gigachad wrote:
| There is a tool called flatseal which gives you a bunch of
| toggles so you can turn on or off any permission for a
| flatpak app.
| curt15 wrote:
| Flatseal gives users a GUI to manage the permissions of each
| app. Would that address your concern?
| southerntofu wrote:
| I think it's great, but we're still far off from an ideal
| solution because it's not exactly fine-grained. For
| example, flatpak portals enable me to grant/block access to
| my home folder, but don't enable me to allowlist a specific
| folder in my home. So i'm stuck with the possibility that a
| vulnerability in the app can take over my entire system
| (eg. by rewriting ~/.profile), or with my app not accessing
| my home folder at all.
|
| As a user, I'd like to give Krita/Libreoffice permissions
| for ~/Documents and Tor Browser permissions for
| ~/Downloads. I don't know yet of a user-friendly method to
| achieve that.
| circularfoyers wrote:
| They already do with filesystem access. You can specify
| XDG folders or any specific folder you like[1].
|
| [1] https://docs.flatpak.org/en/latest/sandbox-
| permissions.html#...
| curt15 wrote:
| >As a user, I'd like to give Krita/Libreoffice
| permissions for ~/Documents and Tor Browser permissions
| for ~/Downloads. I don't know yet of a user-friendly
| method to achieve that.
|
| The filesystem permissions are a bit more fine-grained
| than "all of home or nothing". Your two examples are
| already possible to achieve by granting filesystem access
| to xdg-documents or xdg-downloads.
| brnt wrote:
| So many flatpaks do this incorrectly though. For Browser
| by default saves in the flatpaks home/Downloads directory
| (which is 15 layers deep from ~). You just gotta know to
| navigate up.
|
| Signal let's you save attachments anywhere on disk, but
| only if you manually navigate to ~/Downloads, does it
| actually save (in a way visible and accessible outside of
| the app). You just gotta know.
|
| I forgot what exactly the problem was with Vscode(/ium),
| but it also has a catch like that. You just gotta know.
|
| Flatpak turns out to be the best compromise between
| distribution and cross distro compatibility, but there's
| still some low hanging fruit that could be improved.
| AnonCoward4 wrote:
| You can override permissions (there is even a GUI called
| Flatseal for that). You are also not able to do any of that
| with distro package managers like apt or dnf. Ultimately you
| need to trust either.
| enriquto wrote:
| What I mean is that permissions and accesses concern the
| operating system, not the software packaging. I don't
| understand why flatpack needs to deal with those, providing
| a false (and pernicious) aura of protection. I already run
| third-party software inside containers or virtual machines.
| No need for a GUI nor a flatpack-only solution like
| flatseal. It just looks pointless.
| alkonaut wrote:
| Is there any difference in trust between package maintainers
| and flatpack packagers?
|
| If anything, isn't the flatpack situation better in that
| regard because the end user is more likely to have a sandbox?
| drran wrote:
| Maintainers are not developers, they are users, so the
| developer cannot push unwelcome changes, such as ads,
| trackers, trojans, backdoors, keyloggers, etc. directly to
| users because the maintainer will refuse to accept that.
| AnIdiotOnTheNet wrote:
| On the other hand, maintainers can and have inserted
| (accidentally or not) vulnerabilities in software, and
| ignore developer wishes (like "please stop distributing
| this ancient unmaintained software without this warning
| that says it is ancient and unmaintained"), which
| reflects poorly on the developer in the mind of the user.
|
| I personally see no upside to shoving an unpaid third
| party between user and developer.
| southerntofu wrote:
| > I personally see no upside to shoving an unpaid third
| party between user and developer.
|
| I think F-Droid is a good example of striking a balance
| between those two extreme models. Their existence
| enforces community vetting of apps as well as somewhat-
| reproducible thanks to their standardized build infra,
| which are two major wins.
|
| I personally have much more trust in such schemes (such
| as guix/nix) because i don't necessarily trust all of the
| developers of apps i use not to get hacked, and i believe
| enabling one-click updates to every user of an app
| without review is a dangerous pattern for security.
| goohle wrote:
| > On the other hand, maintainers can and have inserted
| (accidentally or not) vulnerabilities in software,
|
| Such maintainer will be kicked off from distribution.
|
| > and ignore developer wishes (like "please stop
| distributing this ancient unmaintained software without
| this warning that says it is ancient and unmaintained")
|
| Developer wishes are developer wishes. User wishes are
| more important. If package has a maintainer, then it IS
| maintained.
|
| You can use any distribution developed by developers (do
| you know any?) if you dislike maintained distributions
| and share experience with us.
| TingPing wrote:
| > Such maintainer will be kicked off from distribution.
|
| Debian did this, they said oops and moved on. Packagers
| suck as developers, they apply patches they don't fully
| understand to solve problems they don't understand on
| codebases they don't understand.
| AnIdiotOnTheNet wrote:
| > Such maintainer will be kicked off from distribution.
|
| ORLY? What's Kurt Roeckx[0] up to these days? Oh right,
| he's the Debian Project secretary, despite famously
| crippling RNG in OpenSSL.
|
| > Developer wishes are developer wishes. User wishes are
| more important.
|
| You mean like the wish to get up to date software
| directly from the developer without waiting for some
| third-party middleman to get around to updating the repo?
|
| > You can use any distribution developed by developers
| (do you know any?) if you dislike maintained
| distributions and share experience with us.
|
| Such a beast doesn't seem to exist in the Linux world, so
| I just don't use Linux. Linux Desktop's abysmally low
| market share may or may not be related.
|
| [0] To be fair to Kurt, he wasn't the only one who didn't
| see a problem removing those lines and he did ask around
| first. It is an understandable mistake and I don't mean
| to crucify him.
| enriquto wrote:
| > Is there any difference in trust between package
| maintainers and flatpack packagers?
|
| You shouldn't need to trust either. Just the sandboxing
| system of your OS.
| simiones wrote:
| That's only true for the simplest of apps. The whole
| point of desktop OSs is that programs can integrate with
| each other, but that necessarily discards the notion of a
| sandbox almost entirely.
| gizdan wrote:
| This is an inherent limitation of the way OSs are built.
| Linux, Windows, macOS are all like this. macOS is
| currently the furthest ahead in this since they're
| sharing code with iOS, but it's still not where it should
| be.
|
| The Linux kernel is not at a point of allowing this kind
| of fine grained sandboxing or mocking of APIs. I'm
| guessing because it's a significant undertaking. I'm sure
| as more features become available in the Kernel w.r.t.
| sandboxing Snap and Flatpak will definitely utilise them.
| drran wrote:
| Yeah, proper use of Flatpack requires antivirus, reverse
| firewall, hardware isolation (separate CPU core per
| application), user education, etc.
| goodpoint wrote:
| > Is there any difference in trust between package
| maintainers and flatpack packagers?
|
| Yes, and very big: Debian maintainers need to build a
| reputation for years to gain upload rights, meet in person,
| sign keys, and the packages are peer reviewed my multiple
| persons.
|
| Plus, packages spend time in release freeze being tested by
| a large userbase before a distro is released.
| fullstop wrote:
| > No. It doesn't. You still need to trust the people who
| package the thing.
|
| How is this any different than sudo apt install foo?
| enriquto wrote:
| apt is not misleadingly advertised as a sandboxing
| environment. Flatpack is:
|
| "Flatpak: Linux application sandboxing and distribution
| framework " [0]
|
| "It is advertised as offering a sandbox environment in
| which users can run application software in isolation from
| the rest of the system." [1]
|
| The whole point of a sandboxing environment is that you can
| run applications that do not want to be sandboxed. The
| flatpack proposition is directly contradictory with this
| basic requirement, in that it requires the application to
| be flatpacked to begin with.
|
| [0] https://github.com/flatpak/flatpak
|
| [1] https://en.wikipedia.org/wiki/Flatpak
| fullstop wrote:
| Trust of the packager is still involved, no?
| silon42 wrote:
| Yes, but only for things you give access to (data files,
| internet)... sandboxing by default, it should not be able
| to do anything except consume CPU (memory needs to be
| limited also, which might be an issue in practice).
| goohle wrote:
| When I use something from a distribution, I trust the
| distribution as organization. When I use something
| packaged by a developer, I trust the developer. I cannot
| verify thousands of developers, so I must trust the
| distribution and I can trust few developers or packagers
| outside of distribution.
| gizdan wrote:
| > No. It doesn't. You still need to trust the people who
| package the thing.
|
| Flatpak and Snap have never claimed to solve the trust issue
| though. Flatpak allows you to add your own repositories and
| thus developers can package their own applications. So if you
| trust the developer enough to run their software, you should
| be able to trust them to package their own app with.
| unsungNovelty wrote:
| You are right. But with the marketing of them with
| sandboxing and whatnot, they create the impression and
| illusion that it is safe. Cos most of them install it from
| Flathub or Snapcraft. The assumption is that they go
| through all of it and that it is safe. Just like Play store
| and App store. I am pretty sure Flatpak folks now this. It
| is like... we won't lie. But we are not also gonna tell the
| truth.
|
| To make things worse, Flathub changed the way they display
| "Publisher" field for a flatpak. Which says whether a
| package was published by Flathub maintainers, Upstream
| developer or somebody else in Flathub. Now instead of
| saying who, they just say a "See details" link under
| Publisher field in flathub.org for a flatpak. That link
| which in turn directs me to a github page and I am still
| unsure who the hell uploaded that flatpak.
|
| Before, they used to say Upstream developer's name or say
| "Flathub maintainers" which means Flathub team uploaded the
| flatpak making it easier verify who uploaded the flatpak.
| But now it is making it more difficult. This has been the
| most pissing thing about Flatpak other than the security
| issues and problems which keeps coming up about Flathub
| every now and then. Why would you change something that is
| so crucial when it is working?
|
| Cos now, I could package a software which is not in Flathub
| and it would just say "See details" instead of my name.
| This provides the illusion of trust. Cos if it were to show
| my name there, more people would've been like.. who the
| hell is this guy and do a check on me (I used to do that).
| But now, If I could slip through Flathub checks and provide
| malicious flatpak, majority of the folks will still install
| cos most of them are using Flatpak for convenience. Not
| security and performance.
|
| Want proof? Just scroll up and you will see someone saying
| he don't care even though agrees to the things in the blog
| post. He just don't care. :shrug:
| blntechie wrote:
| I was thinking about this the other day and a wasteful
| solution to the packaging problem in open source is the
| decentralized build solution on a blockchain like
| platform. Either with PoW or PoS. In PoS, a node builds
| the code pulled from source control, multiple other nodes
| validate the build and its hash and add to the blockchain
| and to the repository. Now the builds are relatively
| trustable. Of course need to figure out an incentive
| structure for miners/validators to do this expensive
| work.
| southerntofu wrote:
| I don't entirely disagree with this point, but i'd like to
| point out that running a program as a tarball/appimage
| downloaded from the dev's website places entire trust in
| the project's infrastructure, where on the other side of
| the spectrum distro packaging relies on strong vetting from
| a distro's community.
|
| Flatpak/snap is somewhere in between where on the main
| repos (eg. flathub.org) anyone can publish a package for
| anything without being affiliated with upstream. It
| incentivizes users to just search for the app name and
| download whatever comes up as a result. That's a pattern
| we've known to be broken for years: from Windows users
| downloading the first link Google suggests (usually a
| sponsored link bundled with spyware/adware) to Android
| users downloading anything the Play Store suggests (usually
| spyware, see how many flashlight apps there are and what
| permissions they require). F-Droid in the Android ecosystem
| strikes a balance because there is strong community vetting
| for all packages published, so it's like a distro-agnostic
| repository following the distro packaging threat model.
|
| I believe there are ways to mitigate those issues (eg.
| namespace enforcement on flatpak) but i don't think
| downplaying them is doing any good.
| akkartik wrote:
| _" I don't see how randomly installing a Flatpak is any worse
| for security than compiling the source myself."_
|
| It's worse because you're likely to install more packages using
| something like Flatpak than you would by downloading random
| binaries or building from source. That wantonness isn't
| justified given the current state of security on Linux.
|
| (I'm just regurgitating OP: _" Flatpak and Snap apologists
| claim that some security is better than nothing. This is not
| true. From a purely technical perspective, for apps with
| filesystem access the security is exactly equal to nothing. In
| reality it's actually worse than nothing because it leads
| people to place more trust than they should in random apps they
| find on the internet."_)
| jcelerier wrote:
| > It's worse because you're likely to install more packages
| using something like Flatpak than you would by downloading
| random binaries or building from source.
|
| ... what makes you say that ? if I want to run something,
| it'll run one way or another no matter how hard the "system"
| wants to prevent that. Even if it's patch.exe downloaded from
| a 2004 russian website.
| faichai wrote:
| Feel like we've really missed an intermediate solution based
| around tree-shaken statically compiled code. A lot of the goals
| achieved by docker et al could be met with some kind of multi-elf
| file format that is basically a collection of statically linked
| executables combined with a way to read built-in configuration
| files. Maybe this already exists / works.
| southerntofu wrote:
| Not exactly what you're suggesting, but nix/guix addresses most
| of the problems around dynamic linking.
| xtracto wrote:
| Meh... i used to install tarballz, hunting for .so files, then
| RPMs hunting dealing with circular RPM dependencies, then DEBs
| dealing with unmet dependencies. As I age all that got boring. I
| hate Snaps because of how intrusive is with the system.
|
| Flatpak brings Linux to what OSX had like 10 years ago. It just
| works
|
| Regarding download size? Even I, living in a third world country,
| have an internet connection good enough to not care about
| download sizes...
|
| Regarding file redundancy. If that is much of a problem for
| anyone, I'm sure that could be dealt with at the file system
| layer: hash/detect duplicate files and compact them, then copy on
| write. Personally, HDD space hasn't been an issue for me on PC or
| laptops in a long time.
|
| Flatpak finally just work and we have the technology to make it
| usable. Moreover I argue that flatpak IS the future as those 2
| previous points will become more irrelevant as time goes by.
| marcodiego wrote:
| Don't know if it is the future, but has been making my present
| much better.
|
| I can finally have a stable distro with released yesterday
| packages. As a test I tried installing GIMP on raspberry pi, a
| x86 bits ubuntu 18.04 machine a x64 bits ubuntu 16.04 machine and
| x86 bits ubuntu 20.04. Three architectures, 4 distros, 4
| machines: 1 command, the same software. It took a bit long to
| install on the raspi but it worked.
|
| Flatpaks, snaps and appimages finally blurs the lines between
| distros. If there are problems, they should be improved, not
| abandoned.
| necovek wrote:
| The most important takeaway from this is, to me, the need to
| separate sandboxing from dependency management.
|
| However, as can be seen with AppImage, which seems to be strictly
| focused on dependency management, that results in bloat.
|
| It would be great if we could have a sandboxing solution that
| ignores the dependency management altogether.
|
| The problem is not with Flatpak or Snaps (or Docker). The problem
| is that the fragmentation in the actual, live-deployed Linux
| system runtime is huge. At one point, I know Canonical suggested
| a common, shared baseline for all LTS editions of all
| distributions at some point, but there was no interest from Red
| Hat in particular (the other "largest" player). It's not too
| surprising, since Red Hat is the biggest contributor to the base
| GNU/Linux system, so it can decide how it deals with it and push
| it onto others.
|
| Backwards compatibility is hard in software in general, but I
| think simple extensions of tools like apt and apt archives (like
| Launchpad PPAs) would have allowed binary distribution of
| software in an already familiar way where dependency management
| is not a solved problem per se, but has all the familiar gotchas.
|
| As for app stores, that's surely an effort to extract some
| profits, but it's also what big customers are asking for for
| their IoT solutions.
| pabs3 wrote:
| The tool that flatpak uses for sandboxing is bubblewrap, that
| can be used to sandbox distro packages fairly easily. None of
| the desktops do that though.
| necovek wrote:
| Thanks: bubblewrap seems to have been extracted from flatpak.
|
| The documentation seems to focus on filesystem access
| sandboxing. Is there something with practical suggestions on
| how to sandbox things like webcam access, clipboard, screen
| (for screen sharing/recording apps), networking... with
| bubblewrap?
|
| (I know some of that is visible in the filesystem, but not
| all of it is)
| AnIdiotOnTheNet wrote:
| > Backwards compatibility is hard in software in general
|
| I disagree. Pretty much every desktop OS in the world manages
| to get quite a lot of backwards compatibility without a whole
| lot of trouble, except for Linux Desktop.
|
| That suggests the problem isn't hard, it's just that the
| culture of Linux Desktop is incompatible with the concept.
| necovek wrote:
| You must have missed all the articles on the huge effort
| Microsoft went to to maintain backwards compatibility (like
| that famous SimCity story).
|
| I can't find the original article anymore, but you can find
| references to it on Joel Spolsky's blog:
|
| - https://www.joelonsoftware.com/2000/05/24/strategy-letter-
| ii...
|
| - https://www.joelonsoftware.com/2004/06/13/how-microsoft-
| lost...
|
| Referenced posts probably live somewhere on
| https://devblogs.microsoft.com/oldnewthing/ today, but the
| quoted snippets should tell you that it's not that easy at
| all, and that Microsoft is investing heavily in maintaining
| it.
| AnIdiotOnTheNet wrote:
| Yes, in order to increase their backwards compatibility
| Microsoft has, historically at least, done things like
| that. However, mostly they achieve backwards compatibility
| by just not breaking ABIs all the goddamned time.
|
| Windows backcompat isn't perfect, true, but largely the
| stories of where it fails are exceptions to the rule. Where
| as you can't even have backward compatibility in a Linux
| Desktop with applications compiled for the previous version
| of the same distribution in many cases.
| necovek wrote:
| You started off by disagreeing that backwards
| compatibility is hard, because other platforms (like
| Windows or MacOS) can do it.
|
| When given evidence that it's at huge cost and investment
| that they manage to do that (basically an admission from
| them that it is _hard_ -- you may have a different
| definition of "hard" than I do), you seem to suggest
| that either they are not doing a lot of work towards
| compatibility or that they are wasting all that money
| because they could have simply maintained backwards ABI
| compatibility while developing new features "easy-peasy".
|
| Why did they choose not to take the easy way out and made
| it hard for themselves?
|
| From my software development experience, maintaining API
| backwards compatibility is "hard" (requires significant
| extra effort to achieve compared to just not doing it),
| not to mention ABI complexities on top.
| AnIdiotOnTheNet wrote:
| You misunderstand. I am saying that all that effort was
| spent chasing the long tail of compatibility, which _is_
| valuable if compatibility is one of your big selling
| points.
|
| However, one need not go to such extremes to get a good
| amount of compatibility, just don't have a policy of
| breaking ABIs constantly the way Linux Desktop does.
| southerntofu wrote:
| > Pretty much every desktop OS in the world manages to get
| quite a lot of backwards compatibility without a whole lot of
| trouble, except for Linux Desktop.
|
| That's not at all my experience with Windows or MacOS. Sure
| _some_ older apps work fine, but certainly not all of them.
| AnIdiotOnTheNet wrote:
| The vast majority of them do, in my experience. Especially
| if you take into consideration how badly it _doesn 't_ work
| in Linux Desktop. You cannot usually even run a binary
| compiled for the previous version of your distro on the
| latest one!
| david_draco wrote:
| Re security: This is probably best fixed by packaging apps with
| SELinux rules, which are enforced and cannot be disabled, plus
| responsive maintainers. There could be more than one app version
| to allow different SELinux rule strengths, per-app.
|
| Re disk space: no mention of Nix? That also solves updateability
| for security issues. Another solution is Gentoo's -- deliver the
| sources and recipes, (re)build as needed. That could also work in
| userspace.
|
| It would be nice to be able to 1) distribute Linux GUIs 2) let
| friends install them easily 3) have the friend edit the GUI app
| logic and run the modified version. AFAIK, this is currently only
| possible with apps based on interpreted languages (e.g.,
| Python+GTK), but even there you'd need to guide your friend to
| install the required packages.
|
| Re "the state of software complexity in 2021": Ignore complex
| software, and just don't include it on your system. Start with a
| subset, and add only what you need. That's how OpenBSD remains
| manageable. If people want to extend, they can go ahead. But you
| don't have to fix the world.
| kirbyfan64sos wrote:
| Making LSM-based rules for desktop applications is relatively
| complex and inflexible (what if the user wants to grant access
| to a file for a short amount of time? Portals let you do that).
| Are you rebuilding policies on the fly?
| southerntofu wrote:
| Is there a reason SELinux/AppArmor policies couldn't be live
| edited for that kind of purpose? As it is it would require
| root, but wouldn't it be possible to extend security rules
| with user rules which could add restrictions but not lift
| system-wide restrictions? This (hypothetical) way we'd
| package eg. GIMP with a user profile restricting it to
| ~/Documents and /media/USERNAME, but you could then grant it
| additional permissions (eg. to ~/Pictures).
| tonetheman wrote:
| End users do not care about this. If the download works then they
| are happy.
|
| A non-flatpak example is Electron. No one cares how big it is. It
| works.
|
| I download huge games from Steam all the time and have never
| looked at the size of a game even a single time... in years. Disk
| space is still cheap on end users machines.
|
| As long as the calculator works I do not care how much disk space
| it takes up.
| southerntofu wrote:
| > No one cares how big it is.
|
| As someone who's helped many friends/neighbors struggling with
| limited disk space (whether on desktop or Android), i don't
| think this is true at all. I mean, end-users are usually not
| conscious what a reasonable size is for an app and will often
| uninstall one app to install another one instead of complaining
| of app bloat. They're still very much suffering the problem and
| care for it.
| odc wrote:
| > No one cares how big it is.
|
| A lot of people care, especially Linux users.
|
| > Disk space is still cheap on end users machines.
|
| Not cheap for everyone.
| mwcampbell wrote:
| > The state of software development is downright miserable in
| 2021.
|
| This tired refrain shows an obscene lack of gratitude for all the
| things that just work. Yesterday evening I participated in a
| Twitter Space on gratitude for all the great things we have as
| software developers, and I will repost the recording here when
| it's available.
|
| Edit: My mistake; the recording was already posted:
| https://www.youtube.com/watch?v=U10SuAHV8kQ
| isaiahg wrote:
| I usually steer clear of these types of discussions because I
| find the arguments ultimately pointless in the end. The users
| pick the winner based on their experience regardless of the
| merits of the systems available. Also I'm certain I'll come out
| of this worse for wear, as is the experience whenever one crashes
| a heated debate among engineers arguing over which is the better
| standard. So I'm going to hastily step into this den of wolves
| and jump out again.
|
| The fundamental issue I find with all these distribution systems
| is that they always seem more designed to justify a computer
| science degree rather than solving the problem in a user friendly
| way. And that applies to debs and rpms as well. All the solutions
| seem so over-engineered to the point that only engineers have a
| hope to get any kind of consistent usable experience out of it.
| Certainly you can try to hide all that complexity behind a nice
| GUI with icons and layouts, but that only works so well until
| something goes wrong. And then the user is stuck juggling a
| broken system and waiting for a reply on a support forum that may
| never come. That also mirrors my views on why Linux has yet to
| break into the mainstream desktop market.
|
| But lets go even further, another fundamental issue. Sometimes it
| feels like these systems are working to justify a basic design
| choice of Linux that's overstayed its welcome. The idea to
| separate libraries and binaries was a fabulously beautiful
| engineering idea to fix a problem that stopped being an issue a
| decade ago. When your system has 32mb of storage, it makes sense,
| but less so when you can buy a 2tb solid state drive for $120 on
| Amazon. Counter to the argument in the article, storage is cheap
| and becoming cheaper at such a rate that continuing this
| philosophy will appear more odd by the day. And now we've
| officially come full circle and engineered it away with flatpak
| and appimage.
|
| In an ideal world, these perfect systems should work beautifully.
| But users aren't perfect and neither are developers. That's why I
| now value software not by the novelty of how it solves a problem
| but in how few parts it can do it. For all Elon Musk's personal
| issues, he was letter perfect about one thing. The best system is
| no system. The best process is no process. For every additional
| step of complexity you add when solving a problem, you gain three
| additional problems. 1. You have to maintain it across the half-
| lifes of developer interests. 2. You have to teach users and
| developers how to use it the right way, a nearly impossible task.
| 3. All the systems that rely on it become more complex,
| duplicating problems 1 and 2 ad nauseam.
|
| For me part of the answer was missed 12 years ago with AppImage.
| It works so well that I find myself breathing a sigh of relief
| whenever I find an application I want that uses it. That's
| because I know it'll just work. It's a testament to the usability
| of AppImages that it's still in use years later even without
| support from major distros. I think the linux community at large
| is at risk of missing something very good there. At least for
| user facing programs, it works wonderfully.
| thereddaikon wrote:
| "Software has gotten so much slower and more bloated that
| operating systems no longer run acceptably on spinning rust."
|
| I'd argue they never did. Hard drives have always been slow and
| when they were the primary means of storage on the PC, people
| were always trying to find ways to speed things up. Now it takes
| seconds to boot rather than minutes.
|
| "Laptop manufacturers are switching to smaller flash drives to
| improve performance while preserving margins. Budget laptops
| circa 2015 shipped with 256 GB or larger mechanical drives. Now
| in 2021 they ship with 120 GB flash. "
|
| This is outdated information. I just checked Lenovo's store and
| while they do have a super low end machine at $200 with 64Gb of
| EMMC, their real budget model laptops start with a 256Gb SSD. The
| standard ThinkPad we order this year for users had a 1Tb SSD. Is
| it budget? No. But building towards the lowest common denominator
| is rarely worthwhile without good reason.
|
| "Chromebooks are even smaller as they push everything onto cloud
| storage. Smartphones are starting to run full-fledged Linux
| distributions. The Raspberry Pi 4 and 400 use an SD card as root
| device and have such fantastic performance that we're on the
| verge of a revolution in low-cost computing. "
|
| Chromebooks and RPi's are not PCs. Yes, some enthusiasts use them
| that way but that is a niche and done by people who know what
| they are doing. They can easily enough avoid flatpacks.
|
| Linux is a big place and its versatility allows for designing
| distros around multiple use cases. Flatpack and Snaps are meant
| to make software distribution easier. Constraints such as storage
| are not a primary concern for most users. Most machines have
| enough. Their mere existence does not mean other methods of
| deploying software aren't available so if storage is a
| constraint, then simply don't use them.
|
| A lot of the arguments against Flatpack and Snap seem to be based
| around "it's not good for my usecase" ok. Then don't use it.
|
| "Each app with a new runtime adds another hundred megs or more of
| RAM usage. This adds up fast. Most computers don't have enough
| RAM to run all their apps with alternate runtimes. The Raspberry
| Pi 400 has only 4 GB of RAM. Low-end Chromebooks have only 2 GB.
| Budget laptops tend to have 8 GB, mostly thanks to the bloat of
| Windows 10, but these app packaging solutions are catching up to
| it."
|
| My case in point. Still referencing niche machines. Most RPi's
| are used for a dedicated purpose. 99% of Chromebooks never exist
| Google's ecosystem for it. And their concept for what qualifies
| as a lot of memory is, I think, out of touch. 8GB is the base for
| an x86 PC. Not a Chromebook but a real PC. Many have 16 gigs and
| its not uncommon to see up to 32 in laptops and even more in
| workstations.
|
| "Why shouldn't storage shrink anyway? Software should be getting
| more efficient, not less."
|
| My knee jerk response is "why?". My more thoughtful one is that
| efficiency can be measured in many ways. Resource usage becomes
| inefficient when the user determines it is. And everyone has a
| different idea of where that lies. Nobody is multitasking more
| than a couple of applications at any one time on a PC. Servers
| are different but Servers aren't an intended use case for
| Flatpack and Snaps. If I can run the software I want at
| acceptable performance then its resource consumption is efficient
| enough. But you know what Flatpacks are more efficient with?
| Time. I don't have to deal with dependencies. I just tell it to
| install and it works. Given how awful the application management
| experience is in Linux traditionally, I am willing to take the
| downsides for that massive upside.
|
| "Such an app can drop a malware executable anywhere in your home
| folder and add a line to your ~/.profile or a desktop entry to
| ~/.config/autostart/ to have it auto-started on your next login.
| Not only will it run outside of any container, it will even
| persist after the app is uninstalled."
|
| I think he has a point with security. Permissions can be vague
| and misleading. And they do have a supply chain attack
| vulnerability. But that's true of any software you get from the
| repository, store etc. If the official Fedora's official
| Flatpacks can have malware then so can their official Repo.
|
| His section about identifies clashes is not an inherent problem
| with Flatpack but rather a procedural problem with Fedora and
| Flathub. I think its weird he brought it up when he started the
| article saying he wouldn't include easily solvable issues. Yet
| here we are.
|
| "You would think that these packaging mechanisms would embrace
| simplicity if they want to attract software developers. In fact
| they are doing the opposite. "
|
| This is the efficiency problem again. Define simplicity. What is
| simple in one area is complex in another. The fact is nothing as
| complex as software on a computer can be simple everywhere. If it
| were it would be useless. So the question is not how to make it
| simple. It is where are you placing your complexity. Traditional
| package management places the complexity on the user while
| keeping the software simple. Flatpacks place the simplicity on
| the UX while making the software complex. None is inherently
| superior. Its all about design goals.
|
| "All of these app packaging systems require that the user have
| some service installed on their PC before any packages can be
| installed."
|
| And? All software has dependencies and a lot requires some kind
| of run time. Does he also consider all Java software problematic
| because they require a JVM first? What about all web based
| applications requiring a compliant browser? This is a non issue
| in context of how everything else works in the 21st century.
|
| "A major goal of most of these technologies is to support an "app
| store" experience: Docker Hub, Flathub, the Steam Store,
| Snapcraft, and AppImageHub (but not AppImageHub?) These
| technologies are all designed around this model because the
| owners want a cut of sales revenue or fees for enterprise
| distribution. (Flathub only says they don't process payments at
| present. It's coming.)"
|
| Conceptually there is no difference between an app store and
| repository. They are the same thing. App stores are just repos
| that are more user friendly.
|
| "This is very far from the traditional Windows experience of just
| downloading an installer, clicking Next a few times, and having
| your app installed with complete desktop integration. This is
| true freedom. There are no requirements, no other steps, no hoops
| to jump through to install an app. This is why the Windows Store
| and to some extent even the macOS App Store are failing. They
| can't compete with the freedom their own platforms provide."
|
| I didn't expect him to advocate for the windows model. And I
| actually agree. Windows handles application management the best.
| However a lot of the criticisms he gives Flatpack would apply to
| windows too though. You are guaranteed to end up with multiple
| copies of certain dependencies because Microsoft's answer to
| dependency hell was to let developers ship their dependencies
| with their product and not have to care what everyone else had.
| This is extremely space inefficient and can make for ugly under
| the hood management but it works very well. The author misses
| that in his article because he just measures the size of an
| installer, often Windows software ships not as one file but as
| many and the install.exe merely orchestrates the process. Again,
| its all about where you place your complexity. In Windows world
| the complexity is rarely encountered. Apps get to bring their
| baggage with them and decide where it all goes. This means
| program files can get ugly and inconsistent and you may have to
| learn the behavior or individual software but it usually works
| the first time.
|
| "The Current State of Backwards Compatibility"
|
| I have news for you. Linux's biggest problem here isn't that new
| revisions break compatibility. Its that old versions can become
| unavailable. The repo model of software distribution lends itself
| to "link rot" Load up an older version of Ubuntu and it cant talk
| to the repos anymore. The servers are gone. And since until
| recently almost all software was distributed this way and managed
| by a package manager you effectively can't get software working
| in old Linux. Software preservation becomes monumental if not
| impossible. With older windows versions, if I have the install
| media whatever form it may take then I can install and use the
| software because it shipped with all of its dependencies
| included. No nebulous server required. DRM notwithstanding of
| course.
| esarbe wrote:
| Don't know what to think about this blog post; it's not a very
| coherent critique, since it throws together various issues of
| user-packaging-formats that mostly specific to only one of the
| formats. And these don't seem to be 'inherent' in their design.
| Well, one is.
|
| Let's go through some of the issues:
|
| > Size
|
| My /var/lib/flatpak is 13 GB in size. That's a lot of space. On
| the other hand; that's about one game with content and textures,
| so I'm not sure that is too much of an issue. With more and more
| applications agreeing on the base systems, I expect this to get
| smaller
|
| > Memory Usage, Startup times
|
| Snap is ungodly slow at starting up applications and that's
| broken and that _is_ a fundamental design flaw. This issue,
| however, is not at hand with Flatpak; it doesn 't have a startup
| problem.
|
| Neither Flatpak nor Snap have increased memory usage because of
| containerization.
|
| > Drivers
|
| Yes, Nvidia sucks. Do you hear, Nvidia? Mainline your driver
| already.
|
| > Security
|
| > "Flatpack and Snap apologists claim that some security is
| better than nothing. This is not true."
|
| That's debatable. The same argument was made against seatbelts,
| child-proof pill bottles or guard-rails on cliff streets and I
| don't think it holds up. Even if seatbelts don't protect you from
| any harm, they protect you against some harm.
|
| Currently, Linux desktop software offers no security against
| malicious code. The only protection the 'traditional' Linux
| desktop offers against malicious code is user separation, which
| is no protection at all. Before full security can be offered,
| applications need to be migrated to safer practices.
|
| > Permissions and Portals
|
| This doesn't seem to be a critique of any user-packaging-format
| but rather of how GTK implements interactions with Portals.
|
| > Identifier Clashes
|
| That's a problem that arises from Flatpaks decentralized nature;
| everyone can create a repo and add packages of any names there. I
| agree that it would be nice to not have these clashes. Notice
| that this is not an issue with Snaps, since with Snaps there's a
| central authority assigning the identifiers.
|
| > Complexity
|
| Some of the complexity cannot be avoided. Either for backward
| compatibility or for security. I pretty much doubt that Flatpak
| this will be reason that civilization collapses. (That would be
| shortsighted greed and NIMBYism)
|
| > All of these app packaging systems require the user have some
| service installed on their PC before any packages can be
| installed
|
| All app packaging systems require at least _some_ installed
| component. There 's no way you can make a software run on all
| systems without requiring at least _some_ infrastructure. Do you
| want your 64-bit AppImage to install everywhere? To bad! it
| requires 64-bit glib to be installed.
|
| > App stores
|
| > [...] This is the reason Ubuntu wants everyone to use Snap
| [...]
|
| This seems to limited to Snap. Again, not a fundamental design
| issue.
|
| > Backward compatibility
|
| > Forcing Distributions to Maintain Compatibility
|
| > I believe this is partly due to a militant position on free
| software.
|
| This sounds like he wants to dictate FOSS developers how to
| develop their software? See, I understand your frustration - but
| that's not how FOSS works. You cannot force anyone to spend time
| on stuff they don't _want_ to do.
|
| There's some valid criticism in there, but it just reads like an
| angry rant. I think the author could do better by making
| individual articles about the shortcomings of both Snap and
| Flatpak, instead of just lumping them together. Snap and Flatpak
| are just too different.
|
| In the end, Flatpak _is_ the future. No one is going to package
| their software for the nth minor distribution and I rather have a
| slightly (size)-inefficient system of packaging software rather
| than not have access to that software. Distributions have started
| to recognize that they cannot package everything and have started
| to reduce focus to a smaller set of core packages that work well
| together.
| smallerfish wrote:
| > Currently, Linux desktop software offers no security against
| malicious code. The only protection the 'traditional' Linux
| desktop offers against malicious code is user separation, which
| is no protection at all. Before full security can be offered,
| applications need to be migrated to safer practices.
|
| To be fair, he appears to be arguing for the current model,
| where armies of distro volunteers review and manually package
| up debs and rpms (granted that on smaller distro teams, this
| may be less thorough). There is an actual third party involved
| in this explicit review step. With flatpak the developer has a
| direct route to the user without any intermediary or checks.
| esarbe wrote:
| > There is an actual third party involved in this explicit
| review step. With flatpak the developer has a direct route to
| the user without any intermediary or checks.
|
| I think your reading of the author's argument is correct. To
| that I would counter that you can have just the same with
| Flatpak, it just depends on the Repository you are pulling
| your packages from.
|
| It would be awesome if Flathub were to offer some kind of
| process to validate the packaged applications.
| odc wrote:
| > Neither Flatpak nor Snap have increased memory usage because
| of containerization.
|
| Yes it does, because you end up loading multiple versions of
| the shared libraries.
|
| There is also the memory used by the flatpack/snap daemons.
| Snapd is quite big since it is written in Go.
| esarbe wrote:
| > Yes it does, because you end up loading multiple versions
| of the shared libraries.
|
| Given that not all applications necessarily use the same
| libraries and versions, that's an issue you cannot avoid even
| with shared libraries.
|
| So, yes are right; it could be an issue. But it doesn't
| strictly have to do with the containerization.
|
| To be thorough, let me qualify my statement:
|
| Neither Flatpak nor Snap do necessarily result in an
| increased memory usage because of containerization.
|
| > Snapd is quite big since it is written in Go.
|
| Yes, that's true. Go probably wasn't the best idea for a
| system daemon.
| kirbyfan64sos wrote:
| IME, all running portal services add up to around 30MB RAM
| usage, and the two processes that need to run with each
| Flatpak are around 1MB each. (XDG portals aren't Flatpak-
| specific and can be used by host applications for some cross-
| desktop APIs as well.)
| AnIdiotOnTheNet wrote:
| > There's no way you can make a software run on all systems
| without requiring at least some infrastructure. Do you want
| your 64-bit AppImage to install everywhere? To bad! it requires
| 64-bit glib to be installed.
|
| Distributing applications with multiple architecture binaries
| and the correct one selected at run time is a solved problem.
| The original MacOS did it as far back as the 68k/PPC transition
| and the concept has been supported by NeXT/MacOSX Application
| Bundles since the beginning.
| esarbe wrote:
| And then you want to run it on Alpine which isn't even
| compiled with glib and everything falls apart.
|
| I _think_ I know what you want to say (please correct me if I
| 'm wrong); you can always provide more formats or reduce
| dependencies and go _deeper_.
|
| But to me there's no reason to do that. _Some_ infrastructure
| is always required, even if you just reduce it to the kernel.
| Demanding that a piece of software be installable without any
| (p)requirements whatsoever seems not something that is
| demanded from anything besides Flatpak (or Snap). So to
| complain that Flatpaks require a specific service is not a
| valid complaint.
|
| Given how common Flatpak nowadays is - almost all distros
| support it out of the box - I would even say that this
| complaint is not even valid with regards to Flatpaks.
| tored wrote:
| In my opinion the article was well written and well researched
| (many sources), and to separate different topics but relatable
| it used different sections.
|
| > Size
|
| As the author mentions, many users uses budget computers or
| something like a raspberry pi and not a big gaming rig, but you
| also have to consider the network usage, all that data needs to
| be downloaded, that in it self is a cost for the network for
| every computer running that distro.
|
| I work from my laptop when I'm traveling, I use my phone as
| wifi hotspot, download gigabytes of data for installing some
| small app is not feasible.
|
| And you also have to consider poor countries, in poor countries
| you don't have infinite downloads nor the largest drives.
|
| I remember the old days of the critique against Windows from
| the Linux community, Windows forces you to constantly upgrade
| hardware even though that old machine still works fine. I guess
| this is now true for Linux too.
| esarbe wrote:
| Flatpaks (and Snaps) _do_ require more space.
|
| However; when compared to other operating systems - like
| Windows - these space requirements are negligible: a full
| installation of Window 11 takes north of 30GB, so even with
| five years of accumulated flatpak runtimes, this is still
| less than a third of a Windows installation.
|
| Even budget computers can satisfy this. And once the runtimes
| are installed, your mostly good - there are only so many
| runtimes[0].
|
| With regards to raspberry pi; yes, that's not what Flatpaks
| are aimed at, at least not now.
|
| [0] https://docs.flatpak.org/en/latest/available-
| runtimes.html
| anothernewdude wrote:
| Snap certainly isn't. But flatpak might be
| icarusmad wrote:
| Colour me surprised that Canonical and RedHat funded initiatives
| cause bad things to happen in the desktop space.
| riidom wrote:
| From my subjective (user) point of view, flatpak is pretty fine.
| Yes, I do get annoyed whenever I run flatpak update and see 5-10
| updates to drivers or runtimes in the range of ~100MB each. But I
| also want applications to be "just working".
|
| What kinda annoys me though is that file dialogs open in the
| background. Now I am used to check for it, but when the main
| window is still in front, yet blocked, because focus is in the
| file dialog modal, that can get confusing for a moment.
|
| AppImage is ok for me too, the application needs to be "complex"
| enough to justify the download size though. Precisely what the
| KCalc example from the article does not do. I didn't even know
| there is a daemon thingy that auto-integrates them, usually I put
| them in a folder, grab an icon somewhere and place it next to it
| with same name, then add an entry in OS manually, so it appears
| in app starter, can be placed on task bar, etc.
|
| It's just a few clicks and if I ever get annoyed by it because I
| find myself doing it several times a day, I should ask myself if
| I am maybe just installing way too much stuff? :)
|
| Edit:
|
| Wanted to mention there is an application called "FlatSeal" that
| lets you view and (to a degree) edit permissions of Ftatpak Apps.
| https://github.com/tchx84/flatseal (I use it for spectating only
| on occasion, because too much fiddling will probably break the
| app at some point).
| wander_homer wrote:
| > From my subjective (user) point of view, flatpak is pretty
| fine. Yes, I do get annoyed whenever I run flatpak update and
| see 5-10 updates to drivers or runtimes in the range of ~100MB
| each. But I also want applications to be "just working".
|
| For most updates those download sizes are not really
| representative for the actual update size. For example right
| now I had two updates available with a total size of 336.5 MB +
| 275.2 MB. However `flatpak update` actually only had to fetch
| 17.4 kB + 4.4 kB and was done in a few seconds.
| kirbyfan64sos wrote:
| The file dialog issue is fixed in xdg-desktop-portal-gtk 1.10:
| https://github.com/flatpak/xdg-desktop-portal-gtk/pull/347
| southerntofu wrote:
| > usually I put them in a folder, grab an icon somewhere and
| place it next to it with same name, then add an entry in OS
| manually
|
| I'm also familiar with this approach, but that's unfortunately
| something i can't easily teach my friends. AppImageLauncher is
| arguably more user-friendly, and i wish it were more commonly
| distributed as a distro default.
| The_rationalist wrote:
| windowes exes/msi have solved this since the down of time, why
| can't linux replicate this?
| JohnFen wrote:
| After giving flatpacks and the like a good, solid try, I have
| come to truly detest them. This article hits on most of the
| reasons why. If I can only get software in flatpack form, that
| software does not exist for me.
| incrudible wrote:
| I have had the least issues with AppImage. It does not fit every
| use case. It does not need to. If you can ship an AppImage,
| please consider doing so.
| antihero wrote:
| > This is uncompetitive with Windows on its face. If I ship an
| app for Windows I don't have to include the entire Win32 or .NET
| runtimes with my app. I just use what's already on the user's
| system.
|
| What about the gargantuan WinSXS folder?
| ectopod wrote:
| This is legacy now. The latest .Net stuff (whatever they're
| calling it this week) bundles its dependencies, so it's no
| better than flatpak in that regard.
| sdfghderwg wrote:
| > I implore you, do not use these packaging tools. Don't add
| their services to your Linux distributions, don't use apps
| packaged this way, and don't ship apps that use them. Mass
| containerization and alternate runtimes cannot possibly be the
| future of desktop apps on Linux. If this is really the direction
| it's going, the future will be so shitty that we'll all end up
| back on macOS or Windows.
|
| As a long time desktop user, I've dropped Ubuntu for Debian
| because of this. At some point in the past Ubuntu seemed like it
| was going all in on snaps. I don't know what they're doing now,
| but I don't care any more.
| awill wrote:
| This article is full of either errors, or at least misleading
| statements. It comes across as trying to say something
| controversial to get attention.
|
| Just one obvious glaring issue with the article:
|
| >Note that the app package itself is only 4.4 MB. The rest is all
| redundant libraries that are already on my system
|
| Um, no. It's not redundant. Your system might get updated,
| replacing the needed libraries with backwards incompatible
| libraries, and then your app would break.
|
| I do agree with the general idea that not limiting possible
| runtimes to an approved list means essentially infinite runtimes,
| which can balloon disk space. I think you need choice to prevent
| stifling innovation. At least at first. But hopefully the
| community will end up doing the right thing here over time.
| apexalpha wrote:
| As a linux user, but not a developer, I've always been surprised
| by the backlash against Flatpack and Snap.
|
| For me they work wonderfully. On Ubuntu I usually go for the Snap
| since it just works. Solving multiple dependency issues before I
| can use a tool always cost me time before. Now, not so much. Even
| AppImage is nice.
|
| The fact that most software is even _available_ on Linux now is
| due to the fact that developers can create _one_ app for Linux,
| in stead of multiple.
|
| Maybe I'm not familiar enough with GNU/Linux to see the
| drawbacks, but if it's just disk space I'll happily make that
| trade.
| anothernewdude wrote:
| > If I ship an app for Windows I don't have to include the entire
| Win32 or .NET runtimes with my app. I just use what's already on
| the user's system.
|
| No, you just trigger the download on install to get the 15th
| version of the runtime
| LinAGKar wrote:
| >Note that the app package itself is only 4.4 MB. The rest is all
| redundant libraries that are already on my system.
|
| The author promotes avoiding this redundancy by using the
| libraries on the host. But maybe we should go the other way, by
| having only the bare necessities to run the OS installed on the
| host, and install all applications as Flatpak.
|
| I agree with some things though. Different versions of the
| runtimes should share as much as possible, so as to consume as
| little space as possible, and libraries retaining backwards
| compatibility would help with this. And applications should
| target the regular Freedesktop/GNOME/KDE runtimes if possible,
| Fedora shouldn't be doing their own thing completely separate
| from Flathub. And we need to get applications to use portals and
| not allow them to declare file system access on install time.
| oleg_antonyan wrote:
| As Linux user and app developer (shameless plug
| https://github.com/olegantonyan/mpz/) I deliberately avoid
| snap/flatpak/appimage/etc.
|
| Instead, I suffer with Open Build Service
| https://build.opensuse.org/. It's kind of cool, free and can
| build for multiple distros, but making it actually do so is a
| pain. But I still prefer this over flatpak&co both as user and as
| developer.
|
| It just doesn't look like "the future of application
| distribution", https://nixos.org/ does.
| southerntofu wrote:
| > Open Build Service
|
| I heard about that before, but never tried. How in practice do
| you deal with conflicting library versions?
|
| > It just doesn't look like "the future of application
| distribution", https://nixos.org/ does.
|
| Strongly agree. I just find it sad that nix/guix doesn't have
| proper desktop integration (to my knowledge), and that nix
| requires nixGL hacks to start any GUI on foreign distros.
| oleg_antonyan wrote:
| Basically you write spec file for rpm (or debian/control for
| deb) and put your dependencies there as usual. But for each
| supported distro you can override packages names in OBS
| project config, so if the same package called differently in
| another distro you substitute it without modifying spec-file.
| Here's how it looks: https://build.opensuse.org/projects/home
| :oleg_antonyan/prjco...
|
| It's a mess, without meaningful documentation and lots of
| bugs I've spent hours digging the source code to get any idea
| of how to use it.
|
| I build everything static except Qt. My project is small
| enough with only 4 external libraries, so it's ok atm.
| AnIdiotOnTheNet wrote:
| If the future of application distribution looks like learning a
| new language just get things installed, count me out. Linux is
| obtuse enough as it is.
| zohch wrote:
| Why would you rather install some random rpm from someone you
| don't know as opposed to a flatpak?
| oleg_antonyan wrote:
| This works both ways: Why would you rather install some
| random flatpak from someone you don't know as opposed to a
| rpm?
|
| The trust is outside of the scope of package managers
| zohch wrote:
| Because installing an rpm allows you to run arbitrary code
| as root. Installing a flatpak does not. I mean there are
| many more reasons but that should be en.
| oleg_antonyan wrote:
| It's explained in the article, security section: b/c
| installing flatpak can also run arbitrary code as a user.
| And I won't argue that running malicious code as a user
| is always harmless. Regardless of root access if you're
| installing flatpak and its author want to pwn you - they
| can do it even without root access
| lobstrosity420 wrote:
| Unfortunately, Flatpaks are the new SystemD. As in, a solid
| technology which solves real world problems but will face immense
| resistance from a community filled with splinter groups that have
| their own pet technology on the same niche, and will accept
| absolutely nothing else as an alternative. There is simply no
| path to standardization in this community other than big players
| like Red Hat and Canonical strong arming their pet technologies
| in, much to the disdain of everybody else.
|
| As for me I'll keep using Flatpaks as they work great and have
| wide support. Alternatives are either obnoxious to use (Nix and
| Guix) or lacking in basic functionality (Appimages).
| fanatic2pope wrote:
| For me both systemd and flatpak have made using Linux better,
| so I use them and basically ignore the political debates. If
| something better comes along, I'll use those too!
| goodpoint wrote:
| SystemD is not harmful for distributions. Flatpak replaces
| high-granularity, properly managed dependencies and security
| updates with huge blobs.
| lobstrosity420 wrote:
| Flatpaks are not meant to replace established package
| managers, but to act as a supplement to them. Flatapak's
| design decisions go to huge lengths to ensure they are a
| side-by-side system with default package managers e.g. the
| notion that Flatpak packages have a different XDG_CONFIG
| directory so as not to conflict with applications installed
| via the main package manager. Therefore the argument that
| they are harmful to distributions is absurd, as there is no
| aim to replace your precious "properly" managed dependencies
| and the option to never opt-in will be always available.
| nickelpro wrote:
| If flatpaks weren't in competition with packages repos they
| would serve no purpose. They are explicitly in competition
| with package repos. They exist so that app developers can
| get their work out to users without cooperating with
| downstream packagers.
| lobstrosity420 wrote:
| Overlap in functionality does not equal competition. They
| exist so that app developers can get their work out to
| users without cooperating with downstream packagers yes,
| but that does not keep anyone from packaging applications
| using the traditional methods.
| ayushnix wrote:
| > Flatpaks are not meant to replace established package
| managers, but to act as a supplement to them.
|
| I'd be genuinely surprised if distributions like Fedora
| still use, or actively maintain, RPMs for any GUI software
| after a few years.
| bogwog wrote:
| This gave me an idea: how about shipping an installer with an
| embedded appimage. The installer will check the system libraries
| for compatibility, and if compatible, it will install the
| application so that it uses the system libraries. If not
| compatible, it will install the appimage (and do the desktop
| integration stuff).
|
| I actually really like appimages for distributing games and small
| apps. The user experience is a lot like executables on Windows,
| where you can just download any exe from anywhere and expect it
| to just work. Sure, the large size can be a problem, but not
| every appimage will necessarily end up that huge.
|
| The lack of sandboxing isn't a big deal in my eyes because as the
| author mentioned with Flatpaks, most apps end up with too many
| permissions anyways. Proper sandboxing needs some kind of gate
| keeper/moderator to pressure developers into following the rules.
| This can be done with app stores, but the only working app store
| for Linux desktops is Steam, and that's only for games. (to be
| fair, KDE Discover works, but it's a very poor user experience)
| lobstrosity420 wrote:
| In this scenario, what would be the point of deferring to the
| system libraries if you already shipped and made the user
| download the built in ones? As far as desktop integration goes,
| there is already a tool available that will setup the .desktop
| file for you when you first run an Appimage.
|
| >The lack of sandboxing isn't a big deal in my eyes
|
| It should be, executing random Appimages you've downloaded
| online is a huge security liability.
|
| >Proper sandboxing needs some kind of gate keeper/moderator to
| pressure developers into following the rules
|
| You make a good point in that a good moderation in the store is
| very important, but even lacking that you can still tweak the
| sandbox permissions yourself (very easily in fact with
| Flatseal) and it rocks to have that feature available to you.
| bogwog wrote:
| > In this scenario, what would be the point of deferring to
| the system libraries if you already shipped and made the user
| download the built in ones?
|
| Presumably you'd delete the installer after you finished
| installing the app, the same way people do on Windows. Also,
| the appimage could be compressed in the installer to reduce
| the size. I haven't worked out all the implementation
| details, but I'm sure it's doable in a user friendly way.
|
| > It should be, executing random Appimages you've downloaded
| online is a huge security liability.
|
| That's FUD, nobody is downloading and executing "random"
| software from the internet (if a trusted developer gives you
| malware, that's another story). Checksums and/or code signing
| can add peace of mind. Windows and MacOS have done just fine
| without any sandboxing whatsoever.
|
| I'm all for sandboxing, but if it isn't being implemented
| properly, it's just an extra layer of headache on the
| frustration cake that is Linux software distribution.
|
| > you can still tweak the sandbox permissions yourself
|
| You and I maybe, but the average user who just wants to
| install GIMP isn't going to understand why they'd want to do
| that. Why should I be suspicious of this app? Is the
| developer is shady? Who even is the developer? Is the
| distributor shady? Who even is the distributor? Is my wifi
| password not strong enough? etc
| kalium-xyz wrote:
| Flaptak? I'm going to call flatpak from that now.
|
| OP might want to edit this.
| Thin_icE wrote:
| Thank you for the heads up!
| bayesian_horse wrote:
| Very valid points. But the average open source app developer or
| even a developer of a commercial application for linux just
| doesn't have the time, energy or money to keep installation
| instructions up to date and support those both with development
| time and by responding to issues.
| Damogran6 wrote:
| Sighs at the next 229Gb required update to Flight Simulator 2020
| spaniard89277 wrote:
| I don't know about others, but I use snap basically for apps that
| are not in the repository, and I can avoid the PPA mess.
|
| Currently the only app in my laptop with snap is Brave. I
| remember when I wrote the apt install brave, there was a line in
| the console suggestig to use snap.
|
| So for me, as long is anecdotal, it's fine. I agree with the
| author, it's too much bloat, it doesn't matter that disk space is
| cheap.
| anotherhue wrote:
| If you find these sort of problems interesting, I couldn't
| recommend checking out NixOS more. IMO it's the next generation
| solution.
| bogwog wrote:
| or GNU Guix
| xvilka wrote:
| Right! Time to pushback against these developers who uses
| Flatpaks, Appimages, Snaps, Electron, etc. We are no longer in
| the world of doubling performance and memory size. Even more,
| nowadays people are conscious of the power usage. Time to fight
| the bloat!
| OneTimePetes wrote:
| Should have performance indicators with every app - the kids
| who grew up on the performancelandfill slopes of the Mount
| Moore would have a hard time explaining away there whatsapp
| clone needing the same % as a major application.
|
| Yeeh, who enter the plateau, abandon all hope you will get away
| with leaky abstractions.
|
| Wish the lazy bloat-load was build as architectural pattern
| into apps. It only installs when you actually use it.
| exikyut wrote:
| Doubling performance, no. But doubling memory size... kinda.
| 8-16GB is kind of the baseline now. Laptops with 64GB are
| increasingly common in certain niches.
|
| This being said, I do see these systems that basically just
| double down on adding layers for layers' sake as more
| disruptive than systemd.
| dxuh wrote:
| Fight it yourself. Find a solution that's easy for developers
| and users and everyone will use it. It's very simple, actually
| (though not easy).
| [deleted]
| cardanome wrote:
| Higher memory consumption as a trade off for developer
| convenience might be questionable in many cases but here it is
| to increase USER convenience.
|
| What are developers supposed to ship their apps with? Make
| packages for every Linux distribution under the sun? Flaktpaks
| and Appimages solve a real problem. The current alternative is
| NOT being able to use the specific software at all because you
| don't have the right version of Ubuntu.
|
| Maybe Guix/Nix are solutions for some of the pain points of
| traditional package management. And yes, libraries really need
| to focus on backwards compatibility. In the meantime,
| AppImage/Flatpack gets the job done. I am not out of luck when
| my distro does not offer the right package with the right
| version.
| xvilka wrote:
| Static linking is always an option. It even can benefit from
| LTO and PGO this way.
| 0x0nyandesu wrote:
| Agreed
| mrweasel wrote:
| My main complaint about solutions, like Flatpak or Snap, is that
| they add another package manager. Now I have to manage two sets
| of packages.
|
| The baseline tools, like all the GNU standard Unix tools, and
| other command line tools are still managed by DNF, APT, whatever,
| and then another set of apps are managed by Snap. It's pretty
| confusing, especially if you never use the "app stores"
| otherwise. You quickly end up with: apt install <some command
| line tool> and apt install gimp, but now that's a different Gimp
| than the one in App Store. You also can't really remove Gimp from
| apt, because it's weird that apt can't install everything.
|
| I haven't really used Flatpaks, but Snaps is confusing (to me at
| least), because it's doesn't actually replace APT and pollute the
| output of "df" and "mount".
|
| I'm also concerned that some packages will never be updated, or
| stuck on a library with security issues. Perhaps that me, but I'd
| rather that that one application breaks.
| pfranz wrote:
| You should point the finger at package managers. They never
| really addressed needs outside of system administration (to be
| fair, that's the problem _they_ were trying to solve).
| Scripting languages came up with their own package system
| because package managers didn 't fit their needs, I often found
| myself building from source and installing into my homedir
| because package managers wouldn't accommodate, industries (like
| the one I work in) came up with their own package management
| outside of the OS.
|
| Nix/Guix seems like the only one that's trying something
| different enough to address some of those other use-cases, but
| the cat's out of the bag for most people.
| southerntofu wrote:
| > Nix/Guix seems like the only one that's trying something
| different enough to address some of those other use-cases,
| but the cat's out of the bag for most people.
|
| Maybe that's because nix and guix don't interop despite
| having rather similar principles, and because we mostly don't
| have GUI for it (like GNOME Software has integration for
| flatpak) nor desktop integration (like AppImageLauncher). Are
| you aware of work being done in this space?
| pfranz wrote:
| I wasn't knocking their success! I think both have a change
| of being successful in their own domains.
|
| All I was saying is that if a new package manager address
| all of the issues scripting languages had, scripting
| languages would still use their own package managers.
| Because the culture is now set, even new scripting
| languages would write their own package managers.
| cycomanic wrote:
| >You should point the finger at package managers. They never
| really addressed needs outside of system administration (to
| be fair, that's the problem they were trying to solve).
| Scripting languages came up with their own package system
| because package managers didn't fit their needs
|
| I argue that's simply not true. Scripting languages came up
| with package managers because the largest platform (Windows)
| does not have a package manager. Actually that scripting
| languages implement package managers is a very good argument
| that their functionality is desired. As a side note, every
| language package manager is much worse in my experience than
| all of the system package managers I ever used.
| pfranz wrote:
| Right. Windows support is a feature outside of the scope of
| Linux package managers. If they weren't tethered to
| specific distros I don't see why one couldn't support
| multiple platforms. It hasn't historically, but Windows has
| a bunch of package managers, even one supported by
| Microsoft.
|
| I think "largest" is quite an exaggeration since
| historically scripting languages packaging has been rather
| terrible on Windows. While Windows was a consideration for
| languages like Python (I've read they avoided Make because
| of Windows), for me cygwin always coming up along with it
| until recently.
| post-it wrote:
| Package managers that integrate apt, flatpak, and (potentially)
| snap are a nice solution. Unfortunately, the one that happens
| to be on my system (Pop!_Shop) is _awful_.
| southerntofu wrote:
| Could you maybe elaborate, or link to more detailed criticism
| of Pop! Shop? I've also found that GNOME Software did a
| rather poor (though not that bad) job of exposing the
| multiple sources for a given package, but i believe this can
| be fixed with better UX (though i'm unaware of work being
| done in this space).
| post-it wrote:
| Pop!_Shop's UI frequently freezes when installing,
| searching, or even just opening an app's store page from
| the Gnome app menu. It also has some UI bugs, like the
| search bar being visible but un-interactable when on an
| app's page. It's definitely something that can be fixed
| with better UX. The actual selecting whether I want the apt
| version or flatpak version of a package works fine.
| jaclaz wrote:
| This clearly shows how old I am (or have become), it is a
| (crappy) calculator:
|
| >Note that the app package itself is only 4.4 MB.
|
| Calc 98 is huge at 495 KB:
|
| http://www.calculator.org/download.html
|
| Xcalc (RPN) is around 200-240 KB:
|
| http://www.tordivel.no/xcalc/
| ddtaylor wrote:
| > Flatpak and Snap apologists claim that some security is better
| than nothing. This is not true.
|
| Oh no we're all doomed.
| siwatanejo wrote:
| "There will still be occasional differences between
| distributions. These are things you can work around. It may be
| painful at first but it will be worth it: you will provide a much
| superior user experience by working around the issues with your
| users' libraries rather than attempting to replace them."
|
| Sure, like it was happening 20 years ago, and we still had apps
| break ALL THE TIME when the user just upgraded to a new distro
| version or when she changed her distro. It's simply not scalable.
| It has already been tried. Sure, the flatpak world is not
| perfect, and I would never choose this option (maybe I like snap
| better), but it's a step in the right direction.
| zimbatm wrote:
| There is a deep trend happening in software development.
|
| As the number of dependencies for building an application grows,
| it becomes exponentially harder to shake the tree. This used to
| be the role of Linux distributions, they were acting as a push-
| back force, asking projects to support multiple versions of C
| libraries. This was acceptable because there is not C package
| manager.
|
| Now that each language has their own package manager, the role of
| distributions have faded. They are even viewed as a form of
| nuisance by some developers. It's easier to support one fixed set
| of dependencies and not have to worry about backward-
| compatibility. This is something all distributions have been
| struggling with for a while now, especially with NodeJS.
|
| This trend is happening on all platforms, but is more pronounced
| in Linux because of the diversity of the system libraries
| ecosystem. On Windows and macOS, there are some SDKs the
| application can lean on. On Linux, the only stable "SDK" is the
| Linux kernel API.
| southerntofu wrote:
| > Now that each language has their own package manager, the
| role of distributions have faded.
|
| Yet most language-specific package managers are deeply flawed
| compared to distro package managers. But i agree with your
| sentiment that beyond LTS for enterprise, the deb/rpm packaging
| paradigm is becoming obsolete. I believe nix/guix form an
| interesting new paradigm for packaging where there is still a
| trusted third party (the nix/guix community and repo) but where
| packaging doesn't get in the way of app developers.
|
| I'm especially interested in how these declarative package
| managers could "export" to more widely-used packaging schemes.
| guix can already export to .deb, but there's no reason it
| couldn't produce an AppImage or a flatpak.
| simiones wrote:
| > On Windows and macOS, there are some SDKs the application can
| lean on. On Linux, the only stable "SDK" is the Linux kernel
| API.
|
| This is a very good observation I think. Basically, what Linux
| distributions have failed to do is to create a higher level SDK
| for their platforms - instead, they rely on a soup of libraries
| and on the package maintainer model to know which of these is
| which.
|
| Basically, they are failing to provide a true OS: there is only
| a Kernel + various user space apps, from systemd to KDevelop,
| with no explicit line in the sand between what is the system
| SDK and what is a simple app bundled with the OS.
| WastingMyTime89 wrote:
| > This is a very good observation I think. Basically, what
| Linux distributions have failed to do is to create a higher
| level SDK for their platforms - instead, they rely on a soup
| of libraries and on the package maintainer model to know
| which of these is which.
|
| Not really no. It's both simpler and more complicated.
|
| At the very low level, everyone expects to get a POSIX
| system. At the user level, most users use either Gnome or KDE
| (well mostly Gnome to be honest but let's pretend) which
| provides what could be called a highlevel SDK for
| applications.
|
| That leaves the layer inbetween which used to be somewhat
| distribution specific but is seeing more and more
| consolidation with the advent of systemd and flatpak.
| dylan-m wrote:
| > Basically, what Linux distributions have failed to do is to
| create a higher level SDK for their platforms - instead, they
| rely on a soup of libraries and on the package maintainer
| model to know which of these is which.
|
| At the same time, the tools which solve this really shine.
| You inevitably run into these issues with random third party
| dependencies on other platforms, too, but it's further from
| the norm, so you end up with awful bespoke toolchains that
| contain instructions like "download Egub35.3.zip and extract
| it to C:\Users\brian\libs."
|
| Developers on GNOME deal with this regularly, partially
| because of our lack of a high level SDK. So one of the tools
| we have to solve this is first class support for flatpak
| runtimes in GNOME Builder: plop a flatpak manifest in your
| project directory (including whatever base runtime you choose
| and all your weird extra libraries) and Builder will use that
| as an environment to build and run the thing for development.
| This is why pretty much everything under
| https://gitlab.gnome.org/GNOME has a flatpak runtime
| attached. It's a young IDE, but that feature alone makes it
| incredible to work with.
| oynqr wrote:
| It also makes some software under the Gnome umbrella
| incredibly hard to package for distributions.
| nonameiguess wrote:
| I don't think this is really true. There is a fairly stable
| core set of C libraries present on virtually any Linux distro
| with a desktop environment that does most of what any
| application needs in terms of system services. The basic
| problem is more what the parent was discussing: these are C
| libraries, and rather than using the FFI for their app
| language of choice and using these pre-installed libraries,
| developers would rather rewrite all functionality in the same
| language as their applications, and the Rust crate, Go mod,
| or Node package you find when Googling whether something
| exists in your language of choice is likely to be much less
| stable than something like libcurl.
|
| Mac and Windows solve this by creating their own languages
| for app development and then porting the system services to
| be provided in Swift and C# or whatever in addition to the
| original C implementation. There is no corporation behind
| most Linux distros willing to do that other than Canonical
| and Redhat, but they're perfectly happy to just stick with C,
| as is Gnome (KDE being perfectly happy to stick with C++).
| Most app developers are not, however.
|
| For what it's worth, Redhat did kind of solve this problem
| for the Linux container ecosystem with libcontainer,
| rewriting all of the core functionality in Go, in recognition
| of the fact that this is the direction the ecosystem was
| moving in thanks to Docker and Kubernetes using Go, and now
| app developers for the CNCF ecosystem can just use that
| single set of core dependencies that stays pretty stable.
| cpuguy83 wrote:
| There is no common/stable set of c libs. libc on one distro
| is different than libc on another (even just within glibc).
| It's why you generally can't run an app compiled on one
| distro on different one. You also at times cannot do this
| on a newer version of a distro and run it on an older
| version. When a piece of software lists an rpm targeting
| Fedora or a deb targeting Debian, these are not just
| repackaging of the same binaries (unless they are providing
| statically linked binaries).
|
| RedHat did _not_ create libcontainer and it was never
| rewritten to go (it was always go). libcontainer was
| started by Michael Crosby at Docker as a replacement to
| execing out to (at the time unstable) LXC, later donated to
| OCI (not CNCF) as a piece of tooling called "runc", which
| is still in use today. As part of OCI RedHat and others
| have certainly contributed to its development. libcontainer
| lives in runc, and is actively discouraged to use directly
| because go is really quite bad at this case (primarily due
| to no control of real threads), and runc's exec API is the
| stable API here. Side note: much of runc is written in C
| and imported as cgo and initialized before the go runtime
| has spun up. That is not to say libcontainer is bad, just
| that it is considered an internal api for runc.
|
| RedHat did end up creating an alternative to runc called
| "crun", which is essentially runc in C with the goal of
| being smaller and faster.
|
| -- edit to add more context on development in OCI
| goohle wrote:
| You are making it backward. Linux distribution is a
| distribution, not a vendor. If you will write a higher level
| SDK, and then will write an application using the SDK, and
| then this application will be requested by users, then your
| application and your SDK will be included into the
| distribution. UNIX has CDE[0], but nobody uses it, so no
| distribution includes CDE by default.
|
| [0]: https://en.wikipedia.org/wiki/Common_Desktop_Environment
| vetinari wrote:
| > On Windows and macOS, there are some SDKs the application can
| lean on. On Linux, the only stable "SDK" is the Linux kernel
| API.
|
| Now, with Flatpak, each runtime is an SDK on its own. However,
| unlike Windows and macOS, specific runtime is not being bound
| to a specific OS release, but to the app requirement.
| zimbatm wrote:
| That's right, it makes the problem worse.
|
| The first time I noticed that trend was on macOS, where
| applications bundle most of their libraries, and binaries
| compiled for multiple architectures.
|
| Then we had Electron apps that ship with their own full copy
| of a browser and dependent libraries.
|
| When NPM was designed, they observed that resolving colliding
| versions of the same dependency was sometimes difficult.
| Their answer was to remove that restriction and allow
| multiple versions of the same library in a project. Nowadays,
| it's not uncommon to have 1000+ dependencies in a simple
| hello world npm project.
|
| Our industry is moving away from that feedback force that was
| forcing developers to agree on interfaces and release stable
| APIs.
| mschuster91 wrote:
| > Our industry is moving away from that feedback force that
| was forcing developers to agree on interfaces and release
| stable APIs.
|
| And parts of the industry are beginning to move back and
| favor stability, as a result of
|
| - _numerous_ NPM packages being taken over by coin miners
| and other malware - at the scale of some of them, even a
| ten minute takeover window were millions of installs, and
| source chain audits are almost impossible
|
| - framework churn being an actual liability for large
| enterprises - many were burned when AngularJS fell out of
| love and now they were stuck with a tech stack widely
| considered "out of date". Most new projects these days seem
| to be ReactJS where Facebook's heavy involvement promises
| at least some long term support
|
| - developer / tooling churn - same as above, the constant
| amount of training to keep up with breaking changes may be
| tolerable at startup, money-burn phase, but once your
| company achieves a certain size it becomes untenable
| maccolgan wrote:
| Dynamic linking is a creation of the devil.
| jcelerier wrote:
| > On Windows and macOS, there are some SDKs the application can
| lean on. On Linux, the only stable "SDK" is the Linux kernel
| API.
|
| In practice I don't really see a difference, I link against Qt
| on all platforms, win, mac, linux, wasm, android... and that's
| it.
| danShumway wrote:
| Lots of other debate (both pro and con) that I'm not going to get
| into. I like the effort going into Flatpak, but I don't like
| everything it's doing.
|
| Is Flatpak really secure, is it's permission system good, how
| does resource sharing work, whatever. I'm not going to comment on
| any of that in either direction.
|
| But I do want to call out this specific paragraph:
|
| > Apparently, developing client APIs for apps themselves is
| antithetical to Flatpak's mission. They want the apps running on
| Flatpak to be unaware of Flatpak. They would rather modify the
| core libraries like GTK to integrate with Flatpak. So for example
| if you want to open a file, you don't call a Flatpak API function
| to get a file or request permissions. Instead, you call for an
| ordinary GTK file open dialog and your Flatpak runtime's GTK
| internally does the portal interaction with the Flatpak service
| (using all sorts of hacks to let you access the file "normally"
| and pretend you're not sandboxed.)
|
| Heck client APIs. This is the _correct_ way to do sandboxing, for
| two reasons:
|
| ----
|
| First, this is not something that's immediately obvious, but over
| time with both phone platforms and on the web have been starting
| to learn that applications should not be able to change their
| behavior or monitor whether or not they are sandboxed. This
| closes an important hole in app security where application
| developers either change/block behavior, or try to "trick" users
| into granting unnecessary permissions.
|
| For a filesystem, an application should not be aware of whether
| it has access to every file, it shouldn't be aware of whether or
| not it's running on a temporary filesystem. And while it should
| be able to ask the user to grant it access to a directory, it
| should have no easily way of validating whether or not the user
| granted that permission -- it should just get a folder pointer
| back, regardless of whether that pointer is real, a different
| folder, or a virtual/temporary location.
|
| A lot of existing sandboxing doesn't follow this rule. The web is
| normally pretty good at sandboxing, but in this regard it's
| honestly pretty bad. We can't follow this ideal with everything,
| there are some permissions that are impossible to fake. But in
| general, we don't want to make things too easy for malicious
| developers.
|
| > If I want file access permissions on Android, I don't just try
| to open a file with the Java File API and expect it to magically
| prompt the user. I have to call Android-specific APIs to request
| permissions first. iOS is the same. So why shouldn't I be able to
| just call flatpak_request_permission(PERMISSION) and get a
| callback when the user approves or declines?
|
| In this regard, Android and iOS are _wrong_. Not as a matter of
| opinion, I will make a medium-to-high confidence claim that they
| are just flat-out approaching sandboxing security incorrectly. It
| 's not their fault, I wouldn't have done a better job. This is
| something that we've become more aware of as we've seen how
| sandboxing has evolved, and as it's become more obvious how apps
| try to circumvent sandboxes. And this could be a longer
| conversation, yes there are tradeoffs, but the benefits of this
| approach far outweigh them, and I think in the future that more
| platforms (including iOS/Android) are likely to move towards
| seamless permissions that are hidden from applications
| themselves.
|
| Remember we sandbox applications in part _because we don 't trust
| developers._ And while it's not the only reason for hiding user
| controls from apps, it is a good enough reason on its own. Don't
| give attackers unnecessary information if you can help it, this
| is security 101.
|
| And the author is right, this approach is genuinely more brittle
| because it requires building mocked/sandboxed API access rather
| than just throwing an error. But hey, sandboxing itself is more
| brittle. We deal with it for the UX/safety improvements.
|
| ---
|
| Second, for the reason that the author hints at:
|
| > Fedora is auto-converting all of their rpm apps to Flatpak. In
| order for this to work, they need the Flatpak permission system
| and Flatpak in general to require no app changes whatsoever.
|
| There are substantial advantages to having sandboxes that work
| with existing apps. This is always a give-and-take process, but
| in general we don't want to force updates of a large portion of
| user-facing apps. And we want them to be easy to get into
| Flatpak.
|
| The core libraries, user portals, distros themselves -- it is a
| pain to update them, but they have more eyes on them, they are
| more likely to be updated securely, and they have more resources
| available to them. I think it would be a mistake to shift that
| burden entirely onto application developers. Linux has a habit of
| doing this kind of thing sometimes, and it's a bad habit. We want
| Flatpak (or any sandboxing system) to be something that can be
| wrapped around applications without a lot of work. Ideally, a
| 3rd-party maintainer might even be able to bundle an app
| themselves.
|
| There is also a sort of future-proofing built into this, which is
| that there is no such thing as a sandboxing system that's secure
| from day 1. We've seen this pop up on the web, which (for all of
| its general criticism about expanding capabilities) still has a
| much smaller attack surface than most native apps. Web standard
| developers are very careful, but there are still breaking changes
| sometimes when new security measures/permissions need to be
| added.
|
| It would be very good if (as much as is possible), introducing
| additional new privileges and sandboxing capabilities to Flatpak
| did not require code updates for every single app using those
| capabilities that was built for an older version of Flatpak. If
| it's at all possible to avoid that scenario, avoiding it is the
| correct move to make.
|
| And finally, touching on burdens for maintainers again, different
| people may prefer different permission systems. If at all
| possible, we want to avoid forcing individual app developers to
| fragment their codebase and maintain different branches for
| different security sandboxes. Flatpak should run the "base"
| version of your app with little to no changes. This also benefits
| users, because fragmentation and forcing users to install
| multiple simultaneous sandboxes on their machine is heckin awful.
|
| So for all of those reasons, minimizing code changes for
| individual apps is a really good goal to have, even if it
| admittedly makes Flatpak more complicated and a bit harder on
| core platforms like GTK.
|
| ----
|
| Other criticisms, whatever, I have some thoughts but it's not
| important for me to give them.
|
| But the sandboxing criticisms I see in this article betray (to
| me) a lack of understanding about what the current problems are
| with phone/web security and what the next "generation" of
| sandboxing problems are that we're going to face. And I think
| that Flatpak is at the _very_ least approaching sandboxing
| through a more mature /modern lens than the one we were using X
| years ago in early smart phones.
| trollied wrote:
| My experience with these is terrible. I install a JetBrains IDE
| via a package. I spent a very long time trying to debug a CMake
| problem that I assumed was my inexperience with CMake. After
| attacking various processes with strace, it dawned on me that the
| problems were caused by the IDE not being able to see files in
| /usr/local. A sandboxed dev environment! Lost for words... A
| relatively inexperienced dev would have a terrible time with such
| a thing - it couldn't even see dev headers & libs installed with
| apt.
| Const-me wrote:
| Very similar experience with .NET runtime on Linux. Microsoft
| ships .NET runtime as a Snap package
| https://docs.microsoft.com/en-us/dotnet/core/install/linux
|
| One time I didn't paid attention, installed Snap package
| instead of the native binaries, and then I spent several hours
| debugging "access denied" status returned by mq_open
| https://man7.org/linux/man-pages/man3/mq_open.3.html kernel API
| in my program which only happened when called from a C#
| program, but not C++ program running under the same user
| account.
| tored wrote:
| This is the biggest problem with these containers at the
| moment, you don't get any feedback what permissions are
| missing, first you need to understand this is a permission
| problem with the container itself and then to understand what
| permissions are missing and then apply them correctly.
|
| For flatpak there is an api you can use to change permissions
| but for snap what I can remember that is not something you, the
| user, can change, that is up to the maintainer to enable them.
|
| Applications like an IDE uses a lot of different resources so I
| gave up on using that as a flatpak, luckily Jetbrains ships
| their IDEs as tar.gz binary package you can use instead.
|
| Flatpak works best when the application is very self contained,
| like Spotify, it streams music from an internet service, it
| doesn't require any special permissions.
|
| I used Bitwarden as a flatpak, it had limited file access with
| one granted directory (Downloads), I was going to download an
| attachment from the Bitwarden application, the file saving
| dialog started one directory up from Downloads, you had to pick
| and open the Downloads directory first before saving, however I
| managed to save my attachment in that starting location outside
| of Downloads, some void directory that I never found.
| bennyp101 wrote:
| Yea, a while back I tried out a flatpak for filezilla, but
| because it was sandboxed I couldn't set the default editor to
| anything on my actual machine, so uninstalled that and went
| with a deb which worked just fine
| curioussavage wrote:
| You discovered the one area that doesn't work well yet. Dev
| tools don't work great because they typically need access to
| just about everything. They either ask for very broad
| permissions or the app has to add support for portals - of
| which there may not be some that they need yet.
| southerntofu wrote:
| Can't upvote this enough. As other commenters have pointed out,
| understanding why certain features/patterns don't work in a
| given app due to sandboxing is a major hurdle.
| post-it wrote:
| The (unofficial) JetBrains flatpaks have never worked for me
| for that reason, I don't know why flatpak keeps them around. I
| recommend JetBrains Toolbox[0] for managing their IDEs.
|
| [0] https://www.jetbrains.com/toolbox-app/
| xet7 wrote:
| It seems that Flatpak, Snap and AppImage are the present and
| future of packages that work on multiple distros. There are no
| other new alternatives in the article.
| southerntofu wrote:
| You may be interested to check out nix/guix. They're certainly
| not perfect either, but they represent a radically-different
| paradigm which can be worth researching.
| freebuju wrote:
| Flatpak is the future of Linux desktop applications for so many
| reasons, but among them it allows users not to be caught up in
| the dependancy mess that plagues Linux distributions. Some of the
| criticism here does not belong to Flatpak. E.g Fedora's weird
| duplication of repositories is exclusively a Fedora problem. Has
| absolutely nothing to do with Flatpak.
|
| Applications such as VLC and GIMP which 'ship' with access to
| whole filesystem permission is an eternal dilemma. Would you
| rather the authors ship without access to this permission and
| break app functionality ? Or let them ship with restrictive
| permission and allow users to manually enable respective
| permissions to regain function when the software breaks? It is
| easy to see the feasible decision here that works for all parties
| here. The permission on the different accessibility store however
| has confusing labels on sandboxing, I agree with the point that
| the store should make this as clear as possible.
|
| I think the bigger point the article misses is the ability to
| control these permissions at this level. Even if the software
| author ships 'dangerous' default permissions, the user can always
| revert this decision and sandbox it effectively if they so wish.
|
| Flatpak is a crucial needed fix for the Linux package
| distribution problems highlighted elaborately by this article but
| in my humble assessment, the benefits to this solution massively
| outweigh the nuances such as the one the author mentioned about
| package sizes.
| smoldesu wrote:
| Counterpoint: Flatpak doesn't really solve anything, and I have
| no reason to use a Flatpak'd version of a software when there's
| a native version in my system repos. A lot of people feel this
| way: they see it when Flatpak doesn't adopt their native system
| theme, they see it when they try opening a filepicker and it
| starts in some esoteric location, they see it when they want to
| edit files of a Flatpak'd app and need to spend the afternoon
| locating it's binary. There are so many papercuts, bugs,
| regressions and failures on Flatpak's behalf that I don't think
| anyone would really want to adopt it unless they were forced
| to.
|
| I speak only for myself, but I will never enable Flatpak on any
| of my devices. A lot of other Linux users share the sentiment.
| oynqr wrote:
| Apps not adopting to your theme is a feature, at least when
| you ask some Gnome devs.
| smoldesu wrote:
| It's a regression, when you ask the other 95% of Linux
| users who aren't "enjoying" stock GNOME.
| jcelerier wrote:
| > Applications such as VLC and GIMP which 'ship' with access to
| whole filesystem permission is an eternal dilemma. Would you
| rather the authors ship without access to this permission and
| break app functionality ?
|
| to give a data point, I work with a lot of artists who use Macs
| and none of them use mac app store apps because of endless
| issues when accessing the file system
| viraptor wrote:
| > If I ship an app for Windows I don't have to include the entire
| Win32 or .NET runtimes with my app.
|
| That's not the case anymore. If you're aiming higher than .net
| framework 4.x, you have the option of either self-contained
| package (your app + .net core - min 70MB - appimage approach), or
| framework dependent (requires .net version at installation -
| flatpak approach).
|
| I find the "things are not shared" section a bit weird though.
| Yes, not everything uses the same base and that's sad. But I've
| got 8 flatpak apps and 7 of them do share the runtime. We'll
| never get 100% unified and deduplicated approach here - in the
| same way we'll never unify Gtk/qt/tk/wx/...
|
| > Flatpak allows apps to declare that they need full access to
| your filesystem or your home folder, yet graphical software
| stores still claim such apps are sandboxed.
|
| Yes, distros really need to start talking about permissions /
| capabilities rather than some generic "sandbox". Some apps need
| to effectively read the whole disk. But maybe they don't need to
| write to home. Or maybe they don't need internet access. We'll
| have to get mobile-phone-like permission descriptions at some
| point, because a single label just doesn't describe the reality.
| pjmlp wrote:
| Since Windows 3.0 it has only been the case when using OS APIs,
| without depending on C runtime library, C++ runtime library and
| respective frameworks, COM or DLLs from other SDK or third
| parties, xcopy installs and installers exist for a reason.
| legulere wrote:
| Even with .net framework 4.x you need to bring the framework
| with you, if you want to use the newest frameworks, as your
| customers might not have the most current version installed.
| alkonaut wrote:
| The point as formulated still stands though. You don't _have
| to_ because you can always guarantee that your end users will
| have a Win32 runtima and a .NET runtime.
|
| There is a choice, and it's between using a later framework,
| and relying on the OS one.
| pjmlp wrote:
| The choice being stuck with what a specific Windows version
| has available and using OS APIs directly instead of C ones,
| e.g. ZeroMemory() instead of memset(), as the C runtime
| library isn't part of the OS.
| alkonaut wrote:
| Yes, I was only talking about Win32 and .NET, which is
| always bundled in windows (Obviously newer versions of
| the OS may have newer versions of them).
|
| How C libraries work has never been a problem I have
| encountered (I do deploy C++ libraries with apps though,
| and the tendency to move to "all apps deploy a full copy
| of whatever runtimes they need" is a much better
| situation for all 3 parties involved (developers, users
| and hackers...).
|
| I get the point of memset (although that particular
| example I believe is now an intrinsic).
| pdimitar wrote:
| Flatpak very likely is not the future indeed but it seems like a
| good step towards it.
|
| Of all the arguments of the author I only agree with the RAM
| usage part. It's true that having containerized apps will lead to
| much more CPU L-cache trashing which can dramatically reduce
| performance if you are regularly starting and stopping programs.
| This is indeed a problem that needs solving. I can envision a
| NextFlatpak that keeps a global cache of versioned libraries
| (kind of like Apple does in macOS) so as to try and reduce RAM
| usage as much as possible.
|
| And I agree with the author on the startup time (which is also
| related to memory usage and CPU cache trashing). That too is a
| problem that needs solving.
|
| The rest of the arguments though, meh. Are you seriously arguing
| the case that we need to respect 120GB NVMe SSDs because they are
| "expensive"? Really? I spent 255 EUR (288 USD) on a 2TB NVMe SSD
| (and it has 3210 TBW of endurance, one of the very highest of all
| NVMe SSDs!) for a _spare dev laptop_ and I am convinced most devs
| would have no trouble making that purchase any time they get the
| whim about it. And even people in my poor country, people who are
| mind-blown by their new 1300 EUR salary, can _still_ plan
| financially well enough to afford a new iPhone 3-6 months later.
| So again, not convinced here. As much as NVMe SSDs are expensive
| _per GB_ , they are still well within the grasp of most users
| _who actually need them_.
|
| As for security, it seems the author overstates the efforts of
| distro maintainers. They do an admirable job, this is well-known,
| but they really can't be everywhere so him praising them so much
| might be a bit misguided (as do other posters here). Flatpaks
| don't change the game in almost no measure there, especially if
| they get properly isolated (as another poster alluded to: I want
| to be able to stop all internet access to an app; just one
| example). And none of what the author states will stop a
| malicious app that's not in a container so really, what's his
| point there? That the Debian maintainers inspect 100% of all apps
| and will spot a malicious calculator? Come on now.
|
| And the rest of the post is just ranting and having a beef with a
| few things, which is clearly visible by his change of tone. Call
| me crazy but such an article can't be called convincing.
| -\\_(tsu)_/-
| la6471 wrote:
| So Linux desktop is dead and MS wins it after all?
| pjmlp wrote:
| It hardly had a chance thanks fragmentation and hard core
| beliefs in compiling everything from source, up to around 2005
| I was still a believer, nowadays I don't care.
| AnIdiotOnTheNet wrote:
| "Why do people continue to not use our glorious FOSS Desktop
| solution that can't even handle simple application management
| without a hundred different tools?"
|
| People who desire to see more widespread Linux Desktop usage
| will some day have to come to terms with the original
| conception of the phrase "The customer is always right". If you
| continue to ignore what people want, don't be surprised when
| they don't show up.
| cunidev wrote:
| To be fair, as a daily user and (to some extent) app developer,
| in my experience Flatpaks have solved the problem of library
| fragmentation and app distribution on Linux.
|
| While my experience on Snaps was mostly negative (due to bugs,
| virtual "loop disks" per every app affecting the system
| performance, etc.), I found that Flatpak finally lets me install
| essentially any app on any distro.
|
| For example, the Elementary OS "AppCenter" apps are now available
| in any other distribution, thanks to the Flatpak remote. Testing
| daily GNOME apps has become as easy as installing their Flatpak
| reference, and letting them update automatically.
|
| Regarding memory, storage and power consumption:
|
| - The base runtimes (which are the heaviest bit) are downloaded
| only once per system, e.g., one for the KDE Plasma ecosystem, one
| for Elementary, and so on. The first app you install will pull
| them, so I do not see it as much more bloaty than having an
| enormous bundle of system-wide dependencies (e.g. if you install
| a KDE app in a primarily GNOME environment) as would happen
| otherwise.
|
| - Memory and CPU-wise, Flatpaks are very light containers (which
| do not require loop disks, or anything else) which should have
| almost no overhead. I never witnessed any loss of performance, at
| least.
|
| - Bug and crash-wise, I experienced a tremendously stable and
| "flat" experience on Flatpaks. That is, if there is a bug in one
| app on one distribution, the bug will exist on all, or vice
| versa. This is not as common as it should be in containerized app
| install tools, and makes debugging overall much easier.
|
| The only drawback are updates taking longer than on other
| platforms, probably because compressed deltas are not yet
| available unlike in other major package managers.
|
| With this, I don't want to describe Flatpak as a panacea in
| everything, but at least for GUI apps, it solved a _lot_ of
| distribution fragmentation issues in my case.
| sebow wrote:
| My experience was exactly the opposite: snaps usually feel more
| polished and take less space than "flatpaks", at least when you
| compare the first time you install a flatpak.It's true that
| over time flatpaks take less space because they use what's
| already there.
|
| However the conclusion still holds imo, both are bad.Not
| necessarily because they haven't partially solved what they
| tried to achieve, but because they are being pushed instead of
| provided as alternatives to good-old package managers or
| binaries.
|
| Though technically older than both, AppImage is more recent in
| adoption compared to both Flatpak & Snap, and yet 95% of the
| time i had absolutely no problem using AppImage(with the small
| caveat that desktop integration is less polished, and i use a
| neat tool called AppImageLauncher to 'install' them). I know
| it's an apples to oranges comparison and AppImage is not a
| package manager, but the point still stands.
| dylan-m wrote:
| > Memory and CPU-wise, Flatpaks are very light containers
|
| Adding to that: it's really worth noting, on "Memory Usage,
| Startup Time," the author of this article went straight into
| Snap ("the slowest of all") and doesn't mention Flatpak _once_.
| Could it be ... it isn 't a big deal? Nah, let's move on,
| Flatpak bad.
|
| They also conveniently use an old version of GNOME Software
| which predates the recent rework of how it displays
| permissions, age ratings, and other details. In Fedora 35, GIMP
| most definitely has a worrisome "Unsafe" message. It's very
| shiny and new so it would be excusable to miss that if you
| weren't pretending to be a well-researched hatchet job.
| Barrin92 wrote:
| I also can't replicate that snap apps take the same long
| amount of boot time every single time. Snaps generally take a
| few seconds on the first startup but then for me start more
| or less as fast as any other app.
| dylan-m wrote:
| Yep, as I understand it the Snap thing is also obsolete
| information. Older snaps are still slow, but new snaps are
| more efficient to start, and that has been the case for a
| while now.
| goodpoint wrote:
| There are plenty of drawbacks:
|
| - Security: you are trusting random developers on the Internet
| to handle security of all the dependencies in a flatpack,
| forever. Most do not provide security updates at all.
|
| - Privacy: distros like Debian spot and patch out trackers,
| telemetries and similar things.
|
| - Long term maintenability: your desktop becomes a random
| mashup of applications with increasing complexity that you have
| to maintain yourself.
|
| - Licensing issues: distros review licenses (and find plenty of
| copyright violations while doing so). A flatpak puts you or
| your company at risk.
|
| - Impact on the ecosystem: the more users switch to opaque
| blobs the less testing and review is done for proper packages.
| The whole ecosystem become more vulnerable to supply chain
| attacks.
| pas wrote:
| Debian could provide their packages as flatpacks too. Not to
| mention that container images are still mostly built by using
| regular packages, aren't they? (So they are not as opaque,
| nor the regular packages go untested.)
| goodpoint wrote:
| > Debian could provide their packages as flatpacks too.
|
| That would provide no benefits.
|
| > Not to mention that container images are still mostly
| built by using regular packages
|
| Yes, and because of the bundling they are a security
| disaster, as proven by many researchers:
|
| e.g. https://www.infoq.com/news/2020/12/dockerhub-image-
| vulnerabi... https://www.darkreading.com/threat-
| intelligence/malicious-or...
| tremon wrote:
| _So they are not as opaque_
|
| Ok, say a wild CVE appears and it says libblip versions 1.3
| through 2.0.4 have a severity-10 RCE vulnerability and
| should be patched ASAP. If the container images and
| flatpaks are not opaque, I presume you have a simple
| command that lists all vulnerable library versions that are
| present on all the machines you administer? And,
| subsequently, that you have an easy procedure to patch them
| all?
| pas wrote:
| If Debian (or whatever org/group/project/initiative that)
| provides the images has a security policy, they can
| extend that to the images too.
|
| Users don't run CVE checkers [0], at best they
| reluctantly click on the update button. Of course the
| authoritarian evergreen auto-update thing is what
| actually works in practice.
|
| For example as much as snap's UX sucks it does auto
| update by default.
|
| [0] Though they could, as files in container images are
| trivially accessible, after all it's their purpose. Plus
| there are metadata based approaches:
| https://github.com/TingPing/flatpak-cve-checker (plus the
| Flatpak project already spends some energy on ensuring
| that the base image is chechekd against CVEs
| https://gitlab.com/freedesktop-sdk/freedesktop-
| sdk/-/jobs/18... ) of course duplicating this effort, and
| building a parallel world besides packages is not ideal
| Spivak wrote:
| No because that's not the model of Flatpak. If that
| library is in a runtime then that runtime is patched and
| updated. If that library is is part of the application
| then the app is patched and updated.
|
| Just pretend that all Flatpak apps were statically
| linked. Would you have the same complaints? Or would you
| say that version $x of this app is also affected by the
| CVE?
|
| In one situation you run apt update and another you run
| flatpak update.
| goodpoint wrote:
| > Just pretend that all Flatpak apps were statically
| linked. Would you have the same complaints?
|
| Yes. The work required to backport and test security
| fixes in any library or any other component in every
| stable release train of a flatpak (or a fat binary) is
| simply not being done.
|
| Most upstreams barely handle vulnerabilities affecting
| #head.
| fsflover wrote:
| So basically all the same drawbacks as in Windows, when you
| install third-party software?
| ahartmetz wrote:
| Of course, it's basically the same distribution model.
| Everything but the kernel and a very basic set of runtime
| libraries are shipped with the application. Except, I
| guess, that the basic Windows runtime libraries cover more
| security-relevant functionality than the same with Flatpak.
| I'm thinking of SSL, for example.
| rattlesnakedave wrote:
| > - Security: you are trusting random developers on the
| Internet to handle security of all the dependencies in a
| flatpack, forever. Most do not provide security updates at
| all.
|
| As opposed to what? Dynamic linking does not solve this
| problem, contrary to popular belief.
|
| >- Long term maintenability: your desktop becomes a random
| mashup of applications with increasing complexity that you
| have to maintain yourself.
|
| Again, as opposed to what?
|
| >- Licensing issues: distros review licenses (and find plenty
| of copyright violations while doing so). A flatpak puts you
| or your company at risk.
|
| Sounds like a good way for a proprietary software to be
| distributed...
|
| >- Impact on the ecosystem: the more users switch to opaque
| blobs the less testing and review is done for proper
| packages. The whole ecosystem become more vulnerable to
| supply chain attacks.
|
| I don't see how one follows the other.
| goodpoint wrote:
| >> - Security: you are trusting random developers on the
| Internet to handle security of all the dependencies in a
| flatpack, forever. Most do not provide security updates at
| all.
|
| > As opposed to what?
|
| Opposed to distributions providing targeted updates to each
| package.
|
| > Dynamic linking does not solve this problem, contrary to
| popular belief.
|
| On the contrary it provably works very well for
| distributions.
|
| >>- Long term maintenability: your desktop becomes a random
| mashup of applications with increasing complexity that you
| have to maintain yourself.
|
| >Again, as opposed to what?
|
| Opposed to distributions that do the huge work of
| packaging, testing, backporting etc.
|
| >>- Licensing issues: distros review licenses (and find
| plenty of copyright violations while doing so). A flatpak
| puts you or your company at risk.
|
| >Sounds like a good way for a proprietary software to be
| distributed...
|
| This is unrelated to the lack of licensing review.
|
| >>- Impact on the ecosystem: the more users switch to
| opaque blobs the less testing and review is done for proper
| packages. The whole ecosystem become more vulnerable to
| supply chain attacks.
|
| >I don't see how one follows the other.
|
| Supply chain attacks are strongly mitigated by maintainers
| doing vetting and packaging, and by distribution doing
| release freezing.
| jcelerier wrote:
| > On the contrary it provably works very well for
| distributions.
|
| if it worked very well there wouldn't be a need for
| flatpak / snap / appimage / etc. How do I install an
| older or newer inkscape / ardour / krita in the latest
| debian stable / ubuntu / fedora / whatever without
| recompiling stuff ?
| CRConrad wrote:
| > if it worked very well there wouldn't be a need for
| flatpak / snap / appimage / etc.
|
| Exactly: There isn't.
|
| > How do I install an older or newer inkscape / ardour /
| krita in the latest debian stable / ubuntu / fedora /
| whatever without recompiling stuff ?
|
| You don't. Or if you have to, do it on Gobo (or perhaps
| Guix or NixOS?).
| joconde wrote:
| The sentence you're answering was about security. I don't
| think "fixing vulnerabilities faster" is something
| Flatpaks were created to solve. It was more of a solution
| to dependency hell, that makes vulnerabilities harder to
| fix and audit.
|
| I see the same issue with Docker services I deploy: how
| am I supposed to check that the latest Nginx security
| update is included in all my docker-compose deployments?
| With shared libraries, it's as simple as "apt-get
| upgrade" then restarting the services. In Docker, I'd
| have to check that the latest versions of all images
| include the correct versions of all dependencies.
| Mikeb85 wrote:
| > Opposed to distributions providing targeted updates to
| each package.
|
| Except distributions can manage their own flatpak repo.
| Using flatpaks as a format != using Flathub.
|
| This is what Fedora does, for example.
| danShumway wrote:
| Worth noting that nothing about Flatpak necessitates that
| distro maintainers can't compile their own Flatpak apps the
| same way they currently do. Debian can still compile Firefox
| from source and patch out trackers and update dependencies,
| even if at the end of the day it bundles the changes back
| into another Flatpak app.
|
| In fact, the lack of interdependence between apps makes this
| considerably easier, because a Debian upstream that sits in
| the middle and custom-compiles it's "official" software can
| release security updates immediately for critical apps with
| critical security flaws -- without waiting to make sure that
| the security fixes don't break some other app.
|
| Flatpak does not require you to have a separate upstream for
| every app, or to get your updates straight from the
| developer. Debian can still be a middleperson and they can
| still do all of the same moderation/customization/legal
| analysis.
|
| ----
|
| Very importantly, on security, Flatpak is a paradigm shift
| away from the existing model of needing complete trust for
| the entire app:
|
| > Security: you are trusting random developers on the
| Internet to handle security of all the dependencies in a
| flatpack, forever. Most do not provide security updates at
| all.
|
| A big part of this is that you _don 't_ trust random
| developers with Flatpak, or even your own distro maintainers.
| Most applications do not need the level of access they have
| by default. The end goal of Flatpak (it is debatable whether
| it is achieving this, but the goal at least) is to
| significantly shrink the attack surface of your app.
|
| If your calculator app doesn't have file access, or network
| access, or process forking, or any of these things because
| _the runtime_ blocks them (and honestly, why on earth would
| it ever need those things), then it is a lot less dangerous
| for your dependencies to go out of date. A calculator should
| not need to worry about updating its dependencies, because it
| should not have access to anything that could be abused.
|
| Now, that's an extreme example. Many apps will not be in the
| position of needing _no_ privileges, but many of them will
| still be able to have their attack surfaces shrunk. Firefox
| for example really shouldn 't have that much access to my
| filesystem. Apps should not (in general) share parts of the
| filesystem except in user-defined contexts. Many of them
| don't need Internet access at all.
|
| Flatpak makes it easier for dependencies to go out of date,
| but it also (ideally) drastically reduces the number of
| potential security flaws you can have in the first place, and
| drastically reduces the ability of apps to exfiltrate data
| from other apps (again, this is the ideal, see X11
| vulnerabilities + Wayland for how much of an ongoing process
| fixing Linux security is).
|
| ----
|
| I would question a few things:
|
| - Is the reduction in attack surface big enough to balance
| out the extra attention users/devs need to pay to updating
| dependencies?
|
| - How many security vulnerabilities are due to dependency
| issues vs data exfiltration from the home folder, or from
| other apps that they have no need to access? Linux security
| is kind of a disaster in this area, how many vulnerabilities
| would we fix immediately _just_ by sandboxing filesystem
| access so /home wasn't a free for all?
|
| - Is this actually blocking maintainers from releasing
| security patches or making it harder for them to do so? I
| would argue no, I think the maintainers can do the exact same
| things they're doing today, and that their job may be even
| easier when they don't need to hold up an entire house of
| cards with every release.
|
| - Is it better to trust Debian to try and patch out every
| tracker/telemetry, or is there an improvement to having apps
| that don't require Internet access just be flat-out unable to
| call home or send telemetry in the first place? I don't think
| this blocks maintainers from doing their jobs, and it means I
| just don't have to worry about trackers at all in my
| calculator app, even if I download it from a 3rd-party
| source.
|
| ----
|
| The weak point here is other Linux vulnerabilities (gotta get
| off X11!), UX (an eternally hard problem to solve), and
| Flatpak immaturity/mistakes (I don't like that manifests are
| still a thing, portals are still being built, I think
| permissions could be better). But the fundamental concept
| here isn't bad. People rely on shared libraries/runtimes for
| a lot of things that they don't _need_ shared runtimes to
| get.
|
| And I can't stress enough: distros can still moderate and
| compile custom versions of Flatpak apps.
| joconde wrote:
| > Debian can still compile Firefox from source and patch
| out trackers and update dependencies, even if at the end of
| the day it bundles the changes back into another Flatpak
| app.
|
| Does that mean I'll download one copy of libThatWasUpdated
| for every app that uses it?
|
| Seems like this is exactly like iOS and Android work. I see
| the appeal (they are definitely more secure against
| malicious apps than Linux with apt-get), but the waste of
| space still bothers me. Docker has the same issue, and
| didn't really solve it with its layered filesystem (you
| always need several dependencies, but you can't merge
| images, so you'll need to install a new copy of some of
| them).
|
| These packages also make it hard to audit the versions of
| security-critical code installed on my system. It's good
| that they can be updated separately by the OS, but at least
| when apt-get was upgrading shared libraries, I could be
| sure that all programs had the fix. Now I'll need to go
| dive into each package to know if it should be allowed to
| run, or if I should wait for the upgrade.
| [deleted]
| danShumway wrote:
| > These packages also make it hard to audit the versions
| of security-critical code installed on my system.
|
| I think someone else has mentioned this somewhere, but
| Flatpak exposes information about the runtime it's using
| -- you can use metadata tools to iterate over the
| packages installed and check to see if any of them are
| outdated. I suppose the tooling in that area could be
| improved, but I suspect that's something that would
| happen in parallel with more maintainers getting involved
| in validating/moderating packages. I could easily see a
| world where you specify a set of minimum runtime versions
| (or pin an exact runtime version) and set up some rules
| about what packages you'll allow to run.
|
| Importantly, if you do have a critical vulnerability, you
| can make a list of the packages in your system that would
| be affected, and if you're willing to re-bundle them you
| can update the runtime for _just them_ , which means if
| you're a maintainer you can push that update out
| immediately for those programs to everyone; you don't
| have to wait until somebody has finished checking to see
| if the update breaks a calculator app that doesn't have
| Internet or file access anyway.
|
| I don't think there's anything about Flatpak that blocks
| this kind of auditing (and the core technology may end up
| making it easier in the long run). So I do get the
| criticism, but it seems like the criticism here is more,
| "we need some more focus given to better userland tools"
| and not "this is the wrong technical/architectural
| direction to go."
|
| ----
|
| > at least when apt-get was upgrading shared libraries, I
| could be sure that all programs had the fix
|
| Ironically, this is kind of the same behavior that the
| linked article calls out. You really _couldn 't_ be sure
| about that back then. Plenty of packages embed critical
| libraries like libsodium and don't use the shared
| versions. It is very common advice in the Linux world
| (particularly with games) to embed as many system
| libraries as reasonably possible, and regardless of
| whether or not that's good advice, developers do it.
|
| So right now, you're trusting package maintainers to
| catch that stuff and make sure that the dependencies are
| updated across the board (or converted into calls to
| shared libraries) even if the source code isn't using
| shared libraries by default. And after Flatpak, you'll
| still to some degree be trusting maintainers to do that,
| and you'll still be trusting maintainers to say that
| "updating libsodium" means updating every package that
| depends on it. The difference with Flatpak is that this
| is now very explicit and obvious to you, which may be a
| good thing because (in the article's words) it seems that
| the single shared runtime model "leads people to place
| more trust than they should" in their ability to ensure
| that applications are actually using system libraries.
|
| ----
|
| > but the waste of space still bothers me
|
| I don't have too much to say here, it's a legit worry.
|
| I think this mostly comes down to how much space will
| actually be wasted in practice. Docker seems to be
| relatively inefficient about this, I'm not sure if
| Flatpak is better or not. But yeah, it would be good to
| minimize size as much as possible, I do understand that
| concern.
| goodpoint wrote:
| > they are definitely more secure against malicious apps
| than Linux with apt-get
|
| Not at all.
| danShumway wrote:
| Unless you're running something like Firejail on your
| system, yes they are.
|
| There are a metric ton of holes to plug in the Linux
| security model, Linux security is a dumpster fire. But...
| run Wayland, use Flatpak (and check your permissions),
| check file access/network access -- these are steps in
| the right direction, they are security improvements over
| apt-get. We know that isolation/sandboxing (and in
| particular filesystem isolation) is going to be an
| important part of security moving forward.
|
| And if you're comparing this to Android/iOS, it's not
| even a contest, Android/iOS's model of app isolation is
| unambiguously more secure than an apt-get free-for-all;
| and repositories like FDroid allow you to set upstream
| maintainers the same way that you would in desktop Linux
| environments.
|
| If you compare this to the web, it becomes even more
| obvious that resource/runtime isolation between sites
| improves security. Increasingly we're looking at not even
| sharing browser caches between domains, which is even
| more strict than Flatpak's shared runtimes. Isolation is
| a failsafe -- it means if something breaks or gets
| infected, it can't affect everything. It means that
| remote code injection into a properly sandboxed app can
| only compromise one app, and not overwrite your bashrc
| and insert random keyloggers into everything you do.
|
| Improvements still to be made, I would not today assume
| that Flatpak is secure or battle-tested, and it
| definitely can't do much about X11. But we fix these
| things piece by piece, and the basic idea itself is still
| sound.
| user0123895264 wrote:
| I might be imagining it, and there might be another cause, but
| I stopped using Elementary after the latest release after many
| things moved to Flatpaks because I kept running out of memory.
| (On Endeavour/Arch, installing everything natively, I no longer
| have the problem.)
| kirbyfan64sos wrote:
| If I had to guess, the update might have just introduced a
| memory leak somewhere else in the system?
| gens wrote:
| I recommend just shipping everything you need with your app,
| either manually or using AppImage.
|
| Flatpack is, more or less, just a bad package management..
| technology.
| [deleted]
| tapoxi wrote:
| My experience with AppImages is fine, but I prefer Flatpaks
| because they can be updated with a remote.
|
| My installs of Signal and Firefox are with Flatpaks and GNOME
| Software transparently handles updating both.
| mceachen wrote:
| FWIW, PhotoStructure has an AppImage edition and it can
| upgrade automatically in-place.
|
| (There's also a docker image, a macOS DMG, a Windows
| installer, and other editions as well--and yes, you can
| configure any edition to _not_ upgrade automatically if you
| prefer).
| tapoxi wrote:
| I'm less knowledgeable about AppImages, but your download
| link implies it's for Ubuntu only? I'm a Fedora user.
| Scramblejams wrote:
| I often avoid Flatpaks because the permissions are so
| frequently wrong or not what I need.
|
| For example, you mentioned Signal. I stopped using the
| Flatpak because of this:
| https://github.com/flathub/org.signal.Signal/issues/181
| tapoxi wrote:
| It looks like that problem is fixed with Flatpak override
| and not installing the Flatpak with root?
|
| This is also probably because the Signal Flatpak is
| community developed on Flathub from Signal's .deb,
| they're not building Signal with Flatpak in mind. Mozilla
| provides an official Flatpak release of Firefox.
| kaba0 wrote:
| Nah, AppImage still won't run on all distros.
|
| The only thing I think actually solves packaging is nix.
| [deleted]
| alvarlagerlof wrote:
| And AppImage integrates poorly with desktops.
| southerntofu wrote:
| How so? Double-clicking an AppImage from a specific
| folder is not user-hostile (that's a common pattern
| across desktop systems), and the blogpost specifically
| points to appimaged and AppImageLauncher as solutions for
| full desktop integration.
| gens wrote:
| Desktops integrate poorly with desktops.
| ahartmetz wrote:
| What do you mean? When I think of "...integrate poorly
| with desktops", I think of Electron apps. These also have
| a Flatpak-like distribution (but not security) model. And
| a "best effort" integration model. Basically, whatever is
| possible without lifting too much of a finger.
| gens wrote:
| When i think of "desktop integration", i think about drag
| and drop not working between `ark` (a QT program) and
| `thunar` (a GTK program), and i think of folk writing
| blog posts about window theming. (there's also
| notifications, icons, etc, blablabla, that keeps getting
| worse (freedesktop is, that is))
|
| To be honest, i don't care much about how programs look.
| But i do know many people do care.
| krkoch wrote:
| Hm, I've some problems with nix and desktop apps that needs
| opengl or similar machine-specific libraries. There are
| some hacks, and I also think nix comes very close to a good
| solution, but it's not 100% yet.
| kaba0 wrote:
| That's mostly due to video drivers not being under nix's
| control deliberately (if packages would depend on them as
| well, instead of a stub, there would be exponentially
| more build for each driver). On nixos this is solved by a
| specifically-placed stub, while it will be distro
| specific elsewhere, so it may not work for a random
| distro (that's where "hacks" come into the picture,
| choosing a non-nixos distro specific lib as the stub and
| it will work just fine)
| WastingMyTime89 wrote:
| You are replying to a comment explaining to you why Flatpak
| actually works with a dismissive sentence implying it's just
| a bad technology. Do you have anything substantive justifying
| your opinion?
|
| From what I have seen, most of the opposition to Flatpak
| comes from the same place that the one to systemd: fear of
| change. Despite being centered around technology, a very
| vocal part of the Linux community seems to be extremely
| conservative.
| gens wrote:
| I never said it doesn't work. And yes, i do have "anything
| substantive" against it. The fact that, as i mentioned, it
| is just a package manager. And a bad one.
|
| > From what I have seen, most of the opposition to Flatpak
| comes from the same place that the one to systemd: fear of
| change.
|
| This is what pisses me off. You, nor anyone else, can tell
| everyone else what >I< think or feel. It's not fear, nor
| fear of change, nor any other dumb ass reason people who
| think like you think it is. I hate it because it's just a
| package manager. I hate it because, when all the reasons
| against it are brought up, something nebulous like
| "security" or something quazi-psychological like "fear of
| change" are brought up in defense of it.
|
| The real problem with flatpacks is that they don't solve
| the real problem, and they do it poorly.
|
| Want to solve the problem of your program not running on
| multiple distros, or not running in 5 years ? Then look at
| why that is. For example; it's not that the zip file format
| will change, so why must i recompile my program every time
| libzip changes ? Or X11 to wayland transition; why does my
| program have to even care about that when all i want is a
| window and an opengl context ? (bdw the solution to the
| latter is SDL2)
|
| Let's look back when flatpack started. Why did it start ?
| Maybe because GTK3 changed it's API ever so often ?
|
| Linux doesn't have a good GUI toolkit. THAT is the biggest
| problem here.
|
| I just fucking hate the "ohh, you just don't like change"
| people. That dismisses all further discussion. That is the
| real "hate" that people like you blame others of.
| WastingMyTime89 wrote:
| > The fact that, as i mentioned, it is just a package
| manager. And a bad one.
|
| If you don't mind me asking again, why is it bad? Because
| the rest of your post certainly doesn't answer that
| question.
|
| I understood that you don't personally like that
| libraries change. Unfortunately, they most definitely do
| and no, preventing everyone on earth from ever releasing
| an incompatible library is not a realistic solution.
|
| > I just fucking hate the "ohh, you just don't like
| change" people.
|
| Well, you definitely are complaining about change a lot
| in a very impassioned way.
| joconde wrote:
| >> I just fucking hate the "ohh, you just don't like
| change" people.
|
| > Well, you definitely are complaining about change a lot
| in a very impassioned way.
|
| They are complaining about people who assumed an
| irrational reason for their opposition to something,
| while they have a rational one. I find that kind of
| assumption condescending ("let me, the rational one,
| explain to you how to get rid of your insecurities so you
| can appreciate how right I am") and kind of infuriating
| too.
|
| > I understood that you don't personally like that
| libraries change.
|
| If you add breaking changes without maintaining the
| backward-compatible version for a reasonable amount of
| time, I'd argue your library isn't fit to be a dependency
| for anything important. I definitely wouldn't use it.
|
| The Python package ecosystem may be a mess, but I still
| manage to use dozens of shared packages daily with quite
| rare breaking changes, even in libraries that see a lot
| of developments. I would prefer that we focus on
| improving API stability for shared libraries, instead of
| giving up and duplicating dependencies everywhere.
| gopher_space wrote:
| > Despite being centered around technology, a very vocal
| part of the Linux community seems to be extremely
| conservative.
|
| A working system calls for a conservative viewpoint. I'm
| only looking to introduce change if my needs aren't being
| met.
| derefr wrote:
| My understanding is that, by volume, most people using
| Linux "in anger" (whose needs mostly dictate the
| direction of Linux development) aren't the SREs
| maintaining living systems for years at a time; rather,
| they're the DevOps people with constant streams of
| greenfield projects, involving half-baked third-party
| components, that in turn need all sorts of random
| bleeding-edge dependencies.
| whoknowswhat11 wrote:
| And a lot of the complaints about both are very
| generalized. "Flatpack is bad package management
| technology" tells you very little about what is wrong with
| it.
|
| Systemd was such an improvement over the existing speghetti
| for folks selling / supporting linux that it was a pretty
| clear takeoff.
|
| Flatpack seems a bit more focused than snaps. The usability
| issues with snaps kind of surprising given ubuntu has
| usually had a good user focus. One thing, Fedora has their
| silverblue / ostree type distribution initiative, which may
| reduce their use case for using things like flatpack for
| printer subsystems etc (snaps seem more flexible). I moved
| off linux desktop a year ago though so not at all current
| unfortunatly.
| kayodelycaon wrote:
| > Despite being centered around technology, a very vocal
| part of the Linux community seems to be extremely
| conservative.
|
| A lot of the vocal people who pick linux are people who
| want complete control over their systems. Things like
| wayland, systemd, and flatpak take away some of that
| control.
| derefr wrote:
| How so? I feel like this is just unfamiliarity /
| resistance to learning. It's not like these new tools
| _prevent_ you from accessing their internals. The
| internals are all still "right there." They just have
| internals that have been engineered for efficiency over
| composability or observability.
|
| For example, journald. People know and understand
| "rotated-gzipped text .log files in a /var/log
| directory." People don't know, but more importantly, _don
| 't want to learn_, this:
| https://systemd.io/JOURNAL_FILE_FORMAT/. It's a simple
| format, that makes perfect _engineering_ sense as a
| format optimized for the goals it 's trying to
| accomplish. But it's not text -- not the thing a
| greybeard sysadmin has spent the last 40 years working
| with -- so it's "hard."
|
| Instead of just _learning this format and writing tools
| to interface with it_ , people instead think of this data
| as being _impossible_ to access, somehow "locked away"
| behind journald / journalctl, as if there were some kind
| of DRM put into your OS prevent you from accessing your
| own log data.
|
| As it happens, though, journalctl already _builds in_
| support for manipulating this data with POSIXy text-based
| tools -- getting your journal as JSON is one `journalctl
| -o export` away.
|
| But nobody knows about these features (I only just
| learned about it now, from the link above!), because
| nobody _talks_ about these features, because the tooling
| already solves 99% of the real-world problems people
| encounter, and so it 's very rare to actually _need_ to
| script against the journal.
|
| And if you _are_ in that 1% use-case, maybe you 're e.g.
| engineering a distributed log-ingest system for
| efficiency; in which case you wouldn't use `journalctl -o
| export` anyway, but would rather link to journald's C API
| to parse the journal directly, because that's what's most
| efficient, even if it's less convenient/UNIXy.
|
| -----
|
| This is similar to e.g. how people pushed back against
| SPDY/HTTP2.0 for being a "less debuggable" protocol, just
| because it's binary rather than text-based.
|
| Of course, it's extremely rare that anyone needs to
| actually debug _the transport_ , rather than debugging
| their own application-layer protocol they've built _on_
| the transport. And because every server and client that
| speaks HTTP2 still _also_ speaks HTTP1, every
| application-layer protocol flowing over these links can
| just be debugged using HTTP1 messages.
|
| But even if you have that 1% use-case where you need to
| debug the transport, there _are_ simple POSIX-pipeline-y
| tools to bijectively map the binary wire representation
| to a text-based one.
|
| But again, when you hit that 1% of use-cases, you're
| probably a professional doing something weird, such that
| you probably want to pull out WireShark to analyze the
| complete nested app-in-HTTP2-in-TLS-in-TCP-in-IP-in-
| Ethernet packet capture in its original binary form.
|
| And so, even though those bijective HTTP2-to-HTTP1
| observability tools _do exist_ , nobody _thinks_ they do,
| because nobody talks about them, because everybody with
| the 1% use-case is likely solving a large-scope problem
| for which the simple UNIXy solution is "underpowered."
| kayodelycaon wrote:
| Yup. It's that the formats are less transparent and less
| familiar. Binary data doesn't play well with the
| traditional unix tools.
| GekkePrutser wrote:
| Is it really surprising that we're conservative? Most of
| what comes out of big tech right now is focused on
| monetisation and control and when it comes to FOSS a lot of
| companies are trying to get their IP on the map.
|
| For example Ubuntu is trying very hard to push snaps. In
| contrast to flatpaks only they can run the store for it so
| there's clearly a motivation of vendor lock-in.
|
| This kind of thing makes me suspicious and more critical of
| new tech. I'd first want to see if it offers me any value.
| In this case I don't see the big benefit even though
| flatpak doesn't seem to carry the lock-in that snap does.
| But I like the optimisation of dynamic libraries and the
| way I can update openssl once and have all the apps patched
| that use it.
|
| Systemd is a different story. It's open enough but a bit
| too heavy and complex for my liking. It's not bad though
| and I use it on some of my boxes. Alpine is working on an
| alternative based on s6 and I'll probably end up using that
| when it matures.
|
| Anyway I didn't choose Linux/BSD because I cared about
| having the same as everyone else :) Being able to deviate
| from the beaten track is one of the benefits of these. I
| currently use FreeBSD because it has the least corporate
| meddling right now.
| 0x0nyandesu wrote:
| Nah they take up too much disk space. Rather use Gentoo
| capableweb wrote:
| Not sure if you misunderstand what Flatpak is or if you are
| really suggesting to ship a entire distribution for your
| users to install if they want to use the application you're
| delivering to them.
| 0x0nyandesu wrote:
| A typical system will end up with 10 versions of some .so
| library on disk. Sometimes more. Disk usage waste
| everywhere. You're better off having a package manager that
| can link multiple versions at the same time to the programs
| that need it instead of bundling.
| thereddaikon wrote:
| Is that bad because you don't have the space to store it
| or is it bad because you don't like it in principle?
|
| If its the former then its a non issue. Storage is cheap
| and plentiful and code takes up little space relative to
| other assets such as multimedia content.
|
| If its the latter then I don't know what to tell you
| other than practical issues are more important than style
| ones when making practical software. The community has
| voted and decided that classic package management doesn't
| cut it and easy of installing software is important.
|
| And I have to agree with them. Time and time again we've
| been shown that friction to users doing whatever it is
| they want is the biggest barrier to adoption. Its easy
| for tech types like ourselves to get stuck in the weeds
| of the computer. But to most its a means to an end and if
| it isn't facilitating that then they will find another.
| nextaccountic wrote:
| Just use a deduplicating filesystem. Both btrfs and xfs
| can deduplicate identical files.
| sho_hn wrote:
| This is misleading. While btrfs and xfs have some dedup
| functionality, it must be invoked explicitly (e.g. by
| using `cp` with the `--reflink` argument). For
| application installation to benefit from this, business
| logic would have to pre-identify identical files and make
| such references.
|
| There have been some experiments in btrfs to enable
| inband dedup on arbitrary writes, but nothing that made
| it in there as yet.
|
| Note however that the discussion misses on the fact that
| Flatpak itself does perform dedup by using ostree for on-
| disk storage. ostree implements data structures and ideas
| very similar to git sans the version control.
| nextaccountic wrote:
| Dedup can be run periodically, with crontab or systemd
| timers. Here's an example of that:
| https://aur.archlinux.org/packages/duperemove-service
| Gigachad wrote:
| it's been tested and almost all library packages are only
| used by one other package on the system. And almost all
| of the sharing comes down to a very limited set of
| libraries.
|
| Flatpak solves this with platforms. You can base a
| package on the gnome platform for example and get a whole
| bunch of the most used libraries.
|
| But even without platforms, disk space is one of the most
| abundant resources right now. You could install millions
| of libraries in the space of a single AAA game.
| m4rtink wrote:
| IIRC Flatpak actually deduplicates _all_ platform runtime
| _and_ apps on file level automatically due to the backing
| storage being an ostree. The same thing also gives
| flatpak efficient diff updates for apps and platform
| runtime.
| josefx wrote:
| > it's been tested and almost all library packages are
| only used by one other package on the system.
|
| I have a KDE desktop, are you trying to imply that only
| one of the dozens of applications provided by it actually
| use Qt? That only one of the dozens of image related
| programs use libpng, libtiff,libjpeg, etc. ? Or are you
| just citing a highly misleading statistic?
| Gigachad wrote:
| GTK, QT and the core C stuff make up almost all of the
| shared library usage. Some obscure png cropping library
| will basically never end up shared even with dynamic
| linking. Flatpak does a great job of sharing the 1% that
| make up the 99% of usages while allowing version locking
| and bundling of that 1mb binary used by only one program.
| lucian1900 wrote:
| Qt in your case is one of the exceptions, just like GTK
| for Gnome users.
| josefx wrote:
| Any application that depends on either of those
| indirectly depends on libpng and dozens of others. Its a
| dependency tree, just cutting it of after the first
| dependency does not make sense in any context and even
| less so in a context that claims to measure package
| reuse.
| capableweb wrote:
| But you're confusing what sides of the developer/user
| aisle you're on.
|
| Yes, there are probably a better distribution for the
| user to use if they want to save disk space. But Flatpak
| is not a distribution, it's a delivery mechanism. Are you
| really gonna tell people "Hey, don't use $YOUR-CURRENT-
| DIST, use Gentoo instead if you want to use my
| application" if your goal is to provide value for as many
| users as possible?
|
| It's simply not possible to ask people to change their
| distribution because you as a developer prefers a
| different one. Flatpak is for all distributions, and
| doesn't require someone to change from what they know and
| use already, it'll work for everyone equally.
| handrous wrote:
| Ex-(long time)-Gentoo user here. Linux packaging is
| insane without resorting to something like this. The
| problem could be fixed but it would require coordinating
| long-term-stable (like: 5 years, minimum) versions of an
| entire, fairly large _set_ of basic libraries, across (at
| least) every distro that matters. For desktops this would
| probably have to extend to long-term-stable versions of X
| /Wayland and their related libs, plus QT and GTK.
| ddtaylor wrote:
| The article bashes Flatpak portals as complex but otherwise
| doesn't make any solid arguments against them. That's important
| because it's easily the most important remaining problem to solve
| to get an effective sandbox.
|
| I actually like that for apps that have no business reading any
| files on my system they simply cannot do so. Sure, you can point
| to apps like GIMP and such that have chosen to give access to the
| file system by default to make it easier for users while portals
| get polished. If that bothers you then simply use Flatseal to
| change those permissions. Meanwhile apps like Spotify are
| entirely restricted from accessing any of my filesystem. Likewise
| Discord can only access files from a specific directory or a
| youtube-dl style tool like VideoDownloader also cannot access any
| of my files and always includes the latest version of ffmpeg and
| youtube-dl regardless of distro politics.
| yyyk wrote:
| The article's main opposition is to containerization and not
| portals - the author would like having an API for portals (a
| stable libportal?), but likes that approach overall.
|
| The problem is that we still need a solution to stop hacked
| apps from calling fopen() on unrelated files. The article
| ignores how bad the native runtime security solutions are -
| SELinux is nigh unusable, no distro has many apparmor profiles,
| etc.
|
| Flatpak and snap use containerization because Linux's security
| modules aren't common across distros and aren't very usable.
| Iolaum wrote:
| It took android years and billions of dollars to get to the
| state it is at.
|
| Flatpaks and portals are moving towards that direction
| (according to my non expert opinion).
|
| All this friction and complaints, is just normal for such a
| big transition in how desktop apps should be written. I
| remember android devs going up in arms when there were
| significant API changes in past android versions. The
| situation for linux looks similar to me (aside from the fact
| the ecosystem doesn't have money to throw at the problem).
| zdragnar wrote:
| The annoying thing with android is that- even in the J2ME
| days, blackberry had a more sophisticated, fine grained
| per-app permission system that was easy to find and adjust
| at any time.
|
| Android and iOS have been playing catchup ever since...
| Linux I at least will cut some slack, given its age and
| origins, though it would really have been nice had they
| addressed security by now. The situation can only get
| worse, but sooner or later something will happen that will
| encourage breaking backwards compatibility, I hope.
|
| All that said, I praise the sun every day that I'm not
| writing BB apps or j2me anymore, so there's that at least.
| smoldesu wrote:
| I'll keep this short and sweet, because I could complain about
| Flatpaks for hours:
|
| If you distribute your software via Flatpak, you can forget about
| me ever using it. Every computer I own has Flatpak disabled, and
| I will use system repos until the day I die. Plan accordingly!
| mikewhy wrote:
| And you're totally free to do that. Maintainers should also be
| free to ignore support requests when people choose to use
| outdated versions of their software.
| Zardoz84 wrote:
| And nobody talks about Slax modules. Too many years ago, they had
| some basic containerization (only at filesystem level). If it got
| some kind of dependency managment, it would be really great.
| AnIdiotOnTheNet wrote:
| As I recall, Slax used aufs-based filesystem overlays.
| mike_hock wrote:
| To be fair most of that is a result of an ecosystem of idiots and
| not of the fundamental design itself.
|
| It _has_ a namespacing feature, so f-ck 'n use it. Instead, they
| intentionally produce collisions.
|
| Providing and sharing common runtimes could have worked pretty
| well if developers actually used a small set of common runtimes
| instead of picking from one of a gazillion slightly different
| rebuilds.
|
| As a replacement for "native" package management? No. Flatpak
| makes sense if you have a small number (< 5) packages that you
| want to run from upstream so you can always have the latest
| version while continuing to use your distro's native packages for
| everything else.
|
| Unfortunately (and ironically) it's ill-suited for games, which
| need to have the latest GPU drivers available, which is
| antithetical to the whole idea of a stable, universal base
| system.
| pjmlp wrote:
| Game consoles are a stable universal base system, hence why
| game studios prefer them to regular home computers.
| kirbyfan64sos wrote:
| > if developers actually used a small set of common runtimes
| instead of picking from one of a gazillion slightly different
| rebuilds
|
| All the runtimes on Flathub are built on top of the standard
| fd.o runtime, so the OSTree-level dedup should generally work
| for them.
|
| > Unfortunately (and ironically) it's ill-suited for games,
| which need to have the latest GPU drivers available, which is
| antithetical to the whole idea of a stable, universal base
| system.
|
| I believe there's an extension available for the latest Mesa
| builds, so you can opt for the bleeding edge and then just
| remove the extension if things break.
| dylan-m wrote:
| > As a replacement for "native" package management? No. Flatpak
| makes sense if you have a small number (< 5) packages that you
| want to run from upstream so you can always have the latest
| version while continuing to use your distro's native packages
| for everything else.
|
| There are several "Linux" operating systems that use an
| immutable base image: Fedora Silverblue, Endless OS,
| purportedly Steam OS 3. The idea here is the distro packages
| are great for composing your base system, but once that is
| done, the entire `/usr` filesystem is frozen. You can upgrade
| it or roll it back atomically, and in some cases you can do
| some magic to apply smaller changes (Silverblue has a nice
| implementation with `rpm-ostree`), but distro packages are
| intentionally _not_ a typical end user thing. In this kind of
| OS, the best way to install apps is using something like
| Flatpak. And that 's very much what Flatpak is designed for.
|
| So...
|
| $ flatpak list --app | wc -l
|
| 94
|
| And it works well :)
| mjg59 wrote:
| People have tried to provide a packaging format that would allow
| apps to declare their depencies in a distribution neutral
| manner[1]. It was, uh, not a huge success.
|
| Let's take an extreme example. If I build an app on Ubuntu and
| then try to run it against the system libraries on Alpine, it'll
| fail, because Alpine is built against a different libc. We can
| simply declare Alpine out of scope and only support glibc based
| distributions, but if we want good cross-distribution support
| we're still going to be limited to what's shipping in the oldest
| supported version of RHEL. So let's skip that problem by
| declaring LTS distros out of scope and only target things shipped
| in the last 3 years - and now apps can't target any functionality
| newer than 3 years old, or alternatively have to declare a
| complicated support matrix of distributions that they'll work
| with, which kind of misses the point of portability.
|
| In an ideal world distributions would provide a consistent
| runtime that had all the functionality apps needed, but we've
| spent the past 20 years failing to do that and there's no reason
| to believe we're suddenly going to get better at it now. The
| Flatpak approach of shipping runtimes isn't aesthetically
| pleasing, but it solves the problem in a way that's realistically
| achievable rather than one that's technically plausible but
| socially utterly impossible.
|
| Flatpak is a pragmatic solution for an imperfect world - just
| like most good engineering is.
|
| Edit to add: one of the other complexities is that dependencies
| aren't as easy to express as you'd like. You can't just declare a
| dependency on a library SONAME - the binary may rely on symbols
| that were introduced in later minor versions. But you then have
| to take into account that a distribution may have backported
| something that added that symbol to an older version, and the
| logical conclusion is that you have to expose every symbol you
| require in the dependencies and then have the distribution
| resolve those into appropriate binary package dependencies, and
| that metadata simply doesn't exist in every distribution.
|
| [1] http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-
| gene...
| renonce wrote:
| > People have tried to provide a packaging format that would
| allow apps to declare their depencies in a distribution neutral
| manner[1]. It was, uh, not a huge success.
|
| Have you looked into Nix?
| mjg59 wrote:
| Doesn't Nix ship its own version of every library dependency
| rather than using system libraries?
| the_duke wrote:
| Nix allows each package to use a specific version of a
| library and let's them co-exist via unique paths.
|
| In NixOS the whole system works this way, so there aren't
| really any global system libraries, except for the graphics
| system.
| CMCDragonkai wrote:
| NixOS is the only sane Linux distro on the planet now. At
| the end of the day every distro wants their own app
| store.
| rgoulter wrote:
| Nix itself is more focused on "distribute from this host with
| nix, to this other host with nix".
|
| Though, here is e.g. https://github.com/matthewbauer/nix-
| bundle, which is supported as an experimental command in nix
| 2.4.
| account42 wrote:
| > and now apps can't target any functionality newer than 3
| years old
|
| You can optionally support newer functionality with a single
| binary by dynamically loading libraries resolving functions at
| runtime using dlsym or API-specific mechanisms (e.g
| glxGetProcAddress).
| mjg59 wrote:
| Sure, you could dlopen() different SONAMEs until you find one
| that works, and now you just have to somehow deal with the
| structs having changed between versions, and the prototypes
| of functions not being compatible, so yes it's technically
| possible but nobody is going to bother
| nousermane wrote:
| That was a very good summary of where flatpak (and snap, et
| al.) come from, thank you. Not a particularly convincing
| conclusion, though.
|
| Same problem that flatpak is solving (shiping binaries that
| would work across many distros) already have at least two
| solutions - static binaries (where possible, golang is great
| here), or shell wrappers that point dynamic linker to
| appropriate private /lib directory.
|
| Among the 3 solutions here flatpak is the most complex, and
| least compatible with what advanced user might do - run stuff
| in private containers, with different init, etc.
| account42 wrote:
| > or shell wrappers that point dynamic linker to appropriate
| private /lib directory.
|
| You haven't needed shell wrappers to do that for a long time,
| just link with
| -Wl,-rpath,\$ORIGIN/whatever/relative/path/you/want where
| $ORIGIN at the start resolves to the directory containing the
| binary at runtime.
|
| Of course other things like selecting between different
| binaries based on architecture or operating system still
| requires a shell script.
| mjg59 wrote:
| If reducing duplication is a goal, static linking or shipping
| private copies of libraries works against that. Building
| against standardised runtimes works much better in that
| respect.
| rkeene2 wrote:
| AppFS [0] solves this by just providing every file any package
| needs, including libc.
|
| AppFS lazy fetch self-certifying system with end-to-end
| signature checks way to distribute packages over HTTP
| (including from static servers) so it's federated.
|
| Since all packages are just a collection of files, AppFS
| focuses on files within a package. This means if you're on
| Alpine Linux and want to run ALPINE from Ubuntu (assuming
| Ubuntu used AppFS) then it would use Ubuntu's libc. This is
| pretty similar to static linking, except with some of the
| benefits from dynamic linking.
|
| CERN has a similar, but more limited system called CernVM-FS
| [1]. AppFS isn't based on that and I only learned about it
| after writing AppFS.
|
| AppFS is based (in spirit, not in code) on 0install's LazyFS.
| Around the turn of the century I was trying to write a Linux
| distribution that ONLY used 0install, but due to limitations it
| wasn't feasible.
|
| This is possible to do with AppFS and how the docker container
| "rkeene/appfs" works.
|
| [0] https://appfs.net/
|
| [1] https://cernvm.cern.ch/fs/
| mwcampbell wrote:
| > but if we want good cross-distribution support we're still
| going to be limited to what's shipping in the oldest supported
| version of RHEL.
|
| Why should that requirement be considered so extreme when, in
| the Windows world, applications are often required to work as
| far back as Windows 7 (or were until a year or two ago)?
| nousermane wrote:
| On Windows, .dll files are automatically searched in quite a
| few places, including current directory, directory where .exe
| was launched from, and PATH environment variable. Meaning it
| is far easier for apps to ship private libraries.
|
| Plus, when linux apps try to ship private libraries, as
| official chrome packages do, that gets quite some backlash
| from distro maintainers.
| Joker_vD wrote:
| And on Windows the default way to bundle an application is
| "make a separate directory for that application, put
| everything you need inside it" which is kinda equivalent to
| Linux "/opt" packages, IIRC? Anyway, that neatly combines
| with the lookup rules for .dlls (they're first searched
| next to the executable file itself) so that shipping mostly
| self-contained applications is sorta easy: the applications
| by default use their packaged libraries, and if those are
| missing, the system libraries or libraries from PATH are
| used.
| account42 wrote:
| > On Windows, .dll files are automatically searched in
| quite a few places, including current directory, directory
| where .exe was launched from, and PATH environment
| variable. Meaning it is far easier for apps to ship private
| libraries.
|
| You can get the same behavior on Linux by linking with
| -Wl,-rpath,\$ORIGIN (minus the PATH env var, use
| LD_LIBRARY_PATH for that).
| mjg59 wrote:
| I'm trying to scope the "Just use system libraries" approach
| into one that's realistically achievable. I agree that this
| shouldn't be an extreme requirement, but it turns out that
| most app authors aren't terribly interested in restricting
| themselves to the libraries shipped in RHEL 7, so.
| yoz-y wrote:
| But on Windows most applications bring in copies of all of
| their dependencies. And ask for a 20th version of VC
| redistributable to be installes.
| jcelerier wrote:
| > Let's take an extreme example. If I build an app on Ubuntu
| and then try to run it against the system libraries on Alpine,
| it'll fail, because Alpine is built against a different libc.
|
| I mean, on windows if I use a given libc, say msvcrt or ucrt
| (or heck, newlib with cygwin) I have to ship it anyways with my
| app. Linux makes that harder but in practice there's no way
| around this.
| dxuh wrote:
| I think this article is not providing adequate alternatives.
|
| Most programs link against quite a bit more than libstdc++ and
| you clearly can't expect users to install a bunch of packages to
| get their program running. Those extra libraries usually take up
| most of the space in a package. If you include all the shared
| libraries you need, apart from the system libraries in your
| distribution, you pretty much have an AppImage already, just as a
| tarball instead of a squashfs image.
|
| I think GOGs path is not horrible, but it is much less effective
| at making Linux a viable alternative as a gaming platform. They
| literally only support Ubuntu 16.04 and 18.04.
|
| It also struck me as odd, that the author was complaining about
| the complexity introduced by Proton. What is Valve supposed to
| do?
| southerntofu wrote:
| > you pretty much have an AppImage already
|
| That's not wrong, but AppImage is focused on the UX of the
| application as single file, which you can move/copy around and
| can be integrated with the desktop launcher, which i personally
| don't know of standard solutions for with a classic tarball.
| For example, Tor Browser is a classic tarball and works great,
| but the .desktop generation relies on some hacks rather than a
| properly-defined mechanism.
|
| > the author was complaining about the complexity introduced by
| Proton
|
| That's not what i understood from the article. I mean
| wine/proton makes sense on its own to run Windows apps, i think
| the author was criticizing that their specific approach relies
| on steam-specific runtimes instead of using system libraries.
| betwixthewires wrote:
| So I love linux. Particularly, as a desktop system, I like Arch
| and derivatives of it, mainly for the pacman package manager and
| the Arch user repository.
|
| But I have trouble finding packages, and I hate to compile. So I
| use Debian instead.
|
| I would rather just use a distro that isn't ideal for me than
| start using flatpak and snap and all this other stuff. I really
| don't like how fragmented packaging is in the Linux world, but I
| will not use these prepackaged containers that have all
| dependencies included. They're worse.
| comma_at wrote:
| This is all good and true, but it's looking at the problem from
| the Linux distribution's perspective. The user wants a working
| application. Something like AppImage allows a small team to
| distribute a working package for every distro. Now imagine that
| team of 5, working on their app, packaging it for ubuntu, fedora,
| arch, rhel, ... It's just not possible.
|
| What would solve this issue? A common package manager and central
| repository, across all Linux distributions. Then the small team
| only needs to package and ship to one repository, in 1 format.
| hauntedestimate wrote:
| Snaps and Flatpaks are bloated, slow, and a downgrade on user
| experience at all levels. I use linux because it is lean, fast
| and has great package managment (apt). I'd rather go back to
| using Windows than use Flatpaks or Snaps.
| Joker_vD wrote:
| If you are a Linux distribution maintainer, please understand
| what all of these solutions are trying to accomplish. All
| your hard work in building your software repository,
| maintaining your libraries, testing countless system
| configurations, designing a consistent user experience... they
| are trying to throw all of that away. Every single one of
| these runtime packaging mechanisms is trying to subvert
| the operating system, replacing as much as they can with
| their own. Why would you support this?
|
| Uh, because User Freedom(tm)? Or are we supposed to consume Linux
| applications exclusively via the maintainer-supplied packages?
| Also, is this part: "testing countless system configurations,
| designing a consistent user experience", -- something that
| actually happens? Given the example in this very article about
| Fedora going to auto-convert all its rpm packages to Flatpak it
| sounds, as the youth says nowadays, "kinda sus".
| compsciphd wrote:
| All of these things aped by dissertation
|
| see:
| https://www.usenix.org/legacy/events/atc10/tech/full_papers/...
| and
| http://www.usenix.org/events/lisa11/tech/full_papers/Potter....
|
| what I did differently was basically say that it should be a
| linux distribution. each layer should be equivalent to a
| debian/redhat package, with full dependency information between
| them. therefore it be easy to a) create an image (just pick the
| highest level things you want and the rest get resolved
| automatically, much like calling yum/apt-get in a Dockerfile) b)
| upgrade an image when you want to (i.e. similiar to upgrading an
| existing redhat/debian system, it just creates a new image
| artifact that can be tested and deployed)
|
| you also don't have much hiding in the system as opposed to
| today. Yes, they might be built on debian, ubuntu or redhat, but
| you really can't verify easily what changes they made in the
| middle with ease. In my system, imagine there's a "Debian" layer
| repository, in general, you would end up with a bunch of easily
| verifiable debian layers and a small set of "user defined" layers
| (and when an image is deployed, the actual container layer). the
| user defined layers would be much harder to hide things in, i.e.
| it be very visible if one is overriding binaries or configuration
| files that you expect to come from a controlled package.
|
| considering the amount of language and implementation that docker
| seems to share with mine that predates it, one has to wonder if
| they saw my talks / read my papers (though yes, its very possible
| they came up with it totally independently as well). They were
| active in the usenix and lisa communities (at least when they
| were more alive).
| ikt wrote:
| Snap startup speeds have increased considerably since
| https://ubuntu.com/blog/why-lzo-was-chosen-as-the-new-compre...
|
| Spotify and telegram open up pretty much instantly for me. Ubuntu
| 20.04
| southerntofu wrote:
| I think the author's point was that snapd requires mounting
| apps at boot time which can take a while. That's a tradeoff i'm
| personally not willing to make, as someone who starts and stops
| machines several times per day.
___________________________________________________________________
(page generated 2021-11-23 23:02 UTC)