4 ms·

Allows you to install software that isn't in the distro's package manager and didn't have to go through some third party maintainer. In particular, developers c

Allows you to install software that isn't in the distro's package manager and didn't have to go through some third party maintainer. In particular, developers can publish to Flathub whenever they want, can run their own FlatPak repo, and can even just distribute FlatPaks directly through whatever means they feel like. This means you can have up to date software the day it is released and don't have to care if it is popular enough to be in your distro's repo. Additionally, FlatPaks can be stored in "installations" that can be in arbitrary locations. This allows users to install FlatPaks without root, put FlatPaks on alternative disks, etc. FlatPaks also make dependency conflicts a thing of the past. Oh yeah, and the whole thing is distro agnostic[0]. [0] Mostly. The extreme fragmentation of Linux distros does cause a few edge-case problems.

dijit 4y ago
Everything is a choice right, and PPA/AUR are pretty cool usability wise. So, I understand what you mean. But the point of package maintainers is: 1) a third party has independently verified and attested to the quality or state of x software. (or there is a responsible person at least) 2) there can be certain guarantees that the package/software integrates with the distro correctly; an example could be bazel vs bazelisk: where both try to write to the /usr/bin/bazel file and would overwrite each other. (same for pipewire-pulse and pulseaudio- they're mutually exclusive). 3) centralises dependencies: if everything depends on the same set of software then you're going to save disk space and memory on every machine, which in aggregate is going to be a lot. Running "Any old shit" from the internet is such a bad idea overall... it's an artefact from people running windows; and every program bundling it's own update framework....
- AnIdiotOnTheNet 4y ago
  > Everything is a choice right, and PPA/AUR are pretty cool usability wise. They're two separate systems for exactly two separate distros and, oh yeah, your PPA needs to have separate repos for every single Ubuntu release. > But the point of package maintainers is Irrelevant to a lot of us. To me, they are useless middle men who ensure that it takes entirely too long to get updated software when I want it or alternatively that I can't even get the software I want[0] because no one has bothered to package it and put it in the repo for this specific distro. For 1), I don't trust random unpaid volunteers to do this anyway. I'd rather either not run applications I don't trust or just containerize them. Guess how Flatpak works? For 2), FlatPak makes this irrelevant for Desktop software. If you eliminate the ability for software to conflict, you eliminate the need for unpaid volunteers to try and deal with that problem. Pulse/Pipewire is system software, it's part of the underlying platform. For 3) FlatPak makes this irrelevant. Using containerization and OSTree, FlatPak can provide each application with the dependencies it needs while also keeping only one copy of each necessary dependency (per installation). Besides which, most dependencies (shared libraries) aren't actually shared: https://drewdevault.com/dynlib https://drewdevault.com/dynlib > Running "Any old shit" from the internet is such a bad idea overall I use a computer to run software. I use a personal computer to run the software I personally want to run. I will decide which software is a good idea to run or not on my personal computer, not some random group of internets. > it's an artefact from people running windows Consider that one of the reasons Windows is still more popular than Linux Desktop is that it doesn't have all the drawbacks of the traditional package manager/repo model Linux has been using for the entirety of its distant-3rd-place-on-the-desktop reign. It's certainly one of the reasons I still use it. The traditional package manager repo model has advantages that mostly only apply to servers and platform software[1], but are in my (and many other people's) opinion a terrible way to manage desktop software. [0] Without all the pain of compiling from source or jumping through other such hoops. We don't have to do this on Windows or Mac, it's exclusively a Linux disease. [1] Which I argue shouldn't need a package manager in the first place and should be handled the way distros like Silverblue handle it. Which is to say as one complete package that is entirely replaced when it is updated.
  - dijit 4y ago
    > I'd rather either not run applications I don't trust or just containerize them. Guess how Flatpak works? Containers are not security isolation, I'm not sure why this has to be repeated so often because it's very obviously not the problem containers try to solve. Maybe you're thinking of Jails or Zones from BSD and Solaris? > I don't trust random unpaid volunteers to do this anyway. But you trust them to produce your kernel, coreutils and the very software you're talking about? > [flatpak] eliminate[s] the ability for software to conflict I can very much think of ways they can still conflict; one would be port bindings for example. But I agree with the sentiment, you're basically arguing in favour of static binaries being shipped... except instead of static binaries it's... a tarball you run in a chroot... which has some kind of value I suppose. > I use a computer to run software. I use a personal computer to run the software I personally want to run. Sure, nobody stops you from downloading random binaries, or an application developer creating their own package repo and allowing you to download directly. There is history with that approach, in fact I consider rpmfusion (third party repo) to be basically essential for desktop fedora/rhel/centos. My major point is: centralising trust to a few maintainers who you can hold accountable for your entire OS experience has value, and you can still opt out. But making flatpaks mandatory decentralises that trust back to application developers, who might not be trustable. One need only look at how many backdoored docker containers exist on dockerhub.. since it's a platform where anyone can publish essentially anything, even if you're aware you should avoid it- it _does_ pose a concern. There's also a minor argument about blast radius', a developer account being compromised: on docker hub this would be disastrous and opaque, but for github it would not be so bad and probably noticable, and for an apt repository it would be much less dangerous (and very noticable).
    - AnIdiotOnTheNet 4y ago
      > Containers are not security isolation, I'm not sure why this has to be repeated so often because it's very obviously not the problem containers try to solve. They aren't a perfect security solution, that doesn't mean they are useless for it. If I were really worried about an application being nefarious I either wouldn't run it or I'd run it in a VM on a dedicated device or something. You have to trust someone, and I choose to trust fewer people (the developer) rather than more (developer plus packagers). > I can very much think of ways they can still conflict; one would be port bindings for example. But I agree with the sentiment, you're basically arguing in favour of static binaries being shipped... except instead of static binaries it's... a tarball you run in a chroot... which has some kind of value I suppose. There are good reasons very few piece of software, let alone desktop software, are distributed as static binaries. And no, it isn't because of dependency size. There are things you just can't do without dynamic linking in Linux, and glibc is especially tricky to deal with as I understand it. > My major point is: centralising trust to a few maintainers who you can hold accountable for your entire OS experience has value, and you can still opt out. But making flatpaks mandatory decentralises that trust back to application developers, who might not be trustable. FlatPak still allows you to have your own repo run by the distro. In fact, Silverblue only pre-installs Fedora's own FlatPak repo, not Flathub. But regardless, I do not see a reason that FlatPaks need be mandatory, any FOSS software can just be packaged up by a distro without FlatPak. And if it isn't FOSS software than none of the advantages you speak of apply anyway. FlatPak just makes my, and a lot of other people's, lives a lot easier and fits how we use a computer better than the traditional package manager/repo model, so we'd appreciate if people would try to understand why. > and for an apt repository it would be much less dangerous (and very noticable) Would it? Heartbleed went unnoticed for years. The debian random number bug went unnoticed for years. An actor could slip in such a bug intentionally at any time and it would likely be not only overlooked, but simply considered a mistake rather than malicious when caught. I'm not convinced of the supposed security benefits of package maintainers.
- microtonal 4y ago
  a third party has independently verified and attested to the quality or state of x software. If I use an application, I enter a trust relationship with the vendor of that application. I don't want a third-party to make random decisions like adding pile of unsupported patches to the software or deciding that I cannot have it because it is `unethical` (which usually means non-FLOSS). Moreover, you are often stuck with old versions that have known bugs, because they refuse to update packages in LTS versions. Moreover, I think the verification is overstated. Most package maintainers do not have the competency and/or time to conduct a security audit or review deltas between releases. I have been involved with some distributions and a lot of maintainers just check whether a new version still builds. If it doesn't, in the best case they know what they are doing, in the worst case they'll take random patches from the internet until it works. I would rather trust whoever made the application. They know their own software well and have a high stake in distributing something that works as expected without large regressions. The Linux distribution model is fundamentally broken for desktop operating systems. The turnaround time is slow, there is no proper isolation between the operating system itself and its applications, and there is a barrier between the user and the application developer (who usually don't support old, patched versions for a reason). The model for a modern desktop Linux would be a stable, reliable core, with desktop applications provided as bundles through a platform where malicious applications can be yanked (something like Flathub or the Mac/iOS app store). Luckily, some distributions are open to newer models. E.g. Fedora Silverblue uses a lean, immutable OS, managed through OSTree and Flatpaks on top.
  - dijit 4y ago
    The issue of trust is duplicitous. I'm not saying every maintainer does a full security review, I used to package applications for fedora and I did check the bug fixes and do a quick review of code, along with some simple tests while packaging updates. Which is something. What I'm rather suggesting is that you already trust your distro maintainers, there will always be some packaged software running on the platform. If you decide to go outside of that, it's obviously not as supported, more prone to breakages. What I'm more concerned of however is that energy gets diverted away from making packaging better and instead running heavy, expensive container processes for everything. Then again, I'm quite fond of the sandboxing in MacOS's .app packages. Not saying it has no place, just saying I wouldn't be so quick to throw away packages, especially not for "trust" reasons.

dijit 4y ago

Everything is a choice right, and PPA/AUR are pretty cool usability wise. So, I understand what you mean. But the point of package maintainers is: 1) a third party has independently verified and attested to the quality or state of x software. (or there is a responsible person at least) 2) there can be certain guarantees that the package/software integrates with the distro correctly; an example could be bazel vs bazelisk: where both try to write to the /usr/bin/bazel file and would overwrite each other. (same for pipewire-pulse and pulseaudio- they're mutually exclusive). 3) centralises dependencies: if everything depends on the same set of software then you're going to save disk space and memory on every machine, which in aggregate is going to be a lot. Running "Any old shit" from the internet is such a bad idea overall... it's an artefact from people running windows; and every program bundling it's own update framework....

AnIdiotOnTheNet 4y ago
> Everything is a choice right, and PPA/AUR are pretty cool usability wise. They're two separate systems for exactly two separate distros and, oh yeah, your PPA needs to have separate repos for every single Ubuntu release. > But the point of package maintainers is Irrelevant to a lot of us. To me, they are useless middle men who ensure that it takes entirely too long to get updated software when I want it or alternatively that I can't even get the software I want[0] because no one has bothered to package it and put it in the repo for this specific distro. For 1), I don't trust random unpaid volunteers to do this anyway. I'd rather either not run applications I don't trust or just containerize them. Guess how Flatpak works? For 2), FlatPak makes this irrelevant for Desktop software. If you eliminate the ability for software to conflict, you eliminate the need for unpaid volunteers to try and deal with that problem. Pulse/Pipewire is system software, it's part of the underlying platform. For 3) FlatPak makes this irrelevant. Using containerization and OSTree, FlatPak can provide each application with the dependencies it needs while also keeping only one copy of each necessary dependency (per installation). Besides which, most dependencies (shared libraries) aren't actually shared: https://drewdevault.com/dynlib https://drewdevault.com/dynlib > Running "Any old shit" from the internet is such a bad idea overall I use a computer to run software. I use a personal computer to run the software I personally want to run. I will decide which software is a good idea to run or not on my personal computer, not some random group of internets. > it's an artefact from people running windows Consider that one of the reasons Windows is still more popular than Linux Desktop is that it doesn't have all the drawbacks of the traditional package manager/repo model Linux has been using for the entirety of its distant-3rd-place-on-the-desktop reign. It's certainly one of the reasons I still use it. The traditional package manager repo model has advantages that mostly only apply to servers and platform software[1], but are in my (and many other people's) opinion a terrible way to manage desktop software. [0] Without all the pain of compiling from source or jumping through other such hoops. We don't have to do this on Windows or Mac, it's exclusively a Linux disease. [1] Which I argue shouldn't need a package manager in the first place and should be handled the way distros like Silverblue handle it. Which is to say as one complete package that is entirely replaced when it is updated.
- dijit 4y ago
  > I'd rather either not run applications I don't trust or just containerize them. Guess how Flatpak works? Containers are not security isolation, I'm not sure why this has to be repeated so often because it's very obviously not the problem containers try to solve. Maybe you're thinking of Jails or Zones from BSD and Solaris? > I don't trust random unpaid volunteers to do this anyway. But you trust them to produce your kernel, coreutils and the very software you're talking about? > [flatpak] eliminate[s] the ability for software to conflict I can very much think of ways they can still conflict; one would be port bindings for example. But I agree with the sentiment, you're basically arguing in favour of static binaries being shipped... except instead of static binaries it's... a tarball you run in a chroot... which has some kind of value I suppose. > I use a computer to run software. I use a personal computer to run the software I personally want to run. Sure, nobody stops you from downloading random binaries, or an application developer creating their own package repo and allowing you to download directly. There is history with that approach, in fact I consider rpmfusion (third party repo) to be basically essential for desktop fedora/rhel/centos. My major point is: centralising trust to a few maintainers who you can hold accountable for your entire OS experience has value, and you can still opt out. But making flatpaks mandatory decentralises that trust back to application developers, who might not be trustable. One need only look at how many backdoored docker containers exist on dockerhub.. since it's a platform where anyone can publish essentially anything, even if you're aware you should avoid it- it _does_ pose a concern. There's also a minor argument about blast radius', a developer account being compromised: on docker hub this would be disastrous and opaque, but for github it would not be so bad and probably noticable, and for an apt repository it would be much less dangerous (and very noticable).
  - AnIdiotOnTheNet 4y ago
    > Containers are not security isolation, I'm not sure why this has to be repeated so often because it's very obviously not the problem containers try to solve. They aren't a perfect security solution, that doesn't mean they are useless for it. If I were really worried about an application being nefarious I either wouldn't run it or I'd run it in a VM on a dedicated device or something. You have to trust someone, and I choose to trust fewer people (the developer) rather than more (developer plus packagers). > I can very much think of ways they can still conflict; one would be port bindings for example. But I agree with the sentiment, you're basically arguing in favour of static binaries being shipped... except instead of static binaries it's... a tarball you run in a chroot... which has some kind of value I suppose. There are good reasons very few piece of software, let alone desktop software, are distributed as static binaries. And no, it isn't because of dependency size. There are things you just can't do without dynamic linking in Linux, and glibc is especially tricky to deal with as I understand it. > My major point is: centralising trust to a few maintainers who you can hold accountable for your entire OS experience has value, and you can still opt out. But making flatpaks mandatory decentralises that trust back to application developers, who might not be trustable. FlatPak still allows you to have your own repo run by the distro. In fact, Silverblue only pre-installs Fedora's own FlatPak repo, not Flathub. But regardless, I do not see a reason that FlatPaks need be mandatory, any FOSS software can just be packaged up by a distro without FlatPak. And if it isn't FOSS software than none of the advantages you speak of apply anyway. FlatPak just makes my, and a lot of other people's, lives a lot easier and fits how we use a computer better than the traditional package manager/repo model, so we'd appreciate if people would try to understand why. > and for an apt repository it would be much less dangerous (and very noticable) Would it? Heartbleed went unnoticed for years. The debian random number bug went unnoticed for years. An actor could slip in such a bug intentionally at any time and it would likely be not only overlooked, but simply considered a mistake rather than malicious when caught. I'm not convinced of the supposed security benefits of package maintainers.
microtonal 4y ago
a third party has independently verified and attested to the quality or state of x software. If I use an application, I enter a trust relationship with the vendor of that application. I don't want a third-party to make random decisions like adding pile of unsupported patches to the software or deciding that I cannot have it because it is `unethical` (which usually means non-FLOSS). Moreover, you are often stuck with old versions that have known bugs, because they refuse to update packages in LTS versions. Moreover, I think the verification is overstated. Most package maintainers do not have the competency and/or time to conduct a security audit or review deltas between releases. I have been involved with some distributions and a lot of maintainers just check whether a new version still builds. If it doesn't, in the best case they know what they are doing, in the worst case they'll take random patches from the internet until it works. I would rather trust whoever made the application. They know their own software well and have a high stake in distributing something that works as expected without large regressions. The Linux distribution model is fundamentally broken for desktop operating systems. The turnaround time is slow, there is no proper isolation between the operating system itself and its applications, and there is a barrier between the user and the application developer (who usually don't support old, patched versions for a reason). The model for a modern desktop Linux would be a stable, reliable core, with desktop applications provided as bundles through a platform where malicious applications can be yanked (something like Flathub or the Mac/iOS app store). Luckily, some distributions are open to newer models. E.g. Fedora Silverblue uses a lean, immutable OS, managed through OSTree and Flatpaks on top.
- dijit 4y ago
  The issue of trust is duplicitous. I'm not saying every maintainer does a full security review, I used to package applications for fedora and I did check the bug fixes and do a quick review of code, along with some simple tests while packaging updates. Which is something. What I'm rather suggesting is that you already trust your distro maintainers, there will always be some packaged software running on the platform. If you decide to go outside of that, it's obviously not as supported, more prone to breakages. What I'm more concerned of however is that energy gets diverted away from making packaging better and instead running heavy, expensive container processes for everything. Then again, I'm quite fond of the sandboxing in MacOS's .app packages. Not saying it has no place, just saying I wouldn't be so quick to throw away packages, especially not for "trust" reasons.