this post was submitted on 19 Jun 2023
18 points (100.0% liked)
Linux
2 readers
1 users here now
founded 2 years ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
God I hope not. Especially not snap, it's so painful and slow. AppImage works fine enough I guess. I don't want an ecosystem where more and more developers go with these only and neglect being able to install at a system level.
That is unfortunately the future because maintaining packages for a million different distros is painful to say the least. The best you can hope for is native packages for the top 10 distros. Everyone else will have to deal with flatpak.
Doesn't that just depend on whether or not the people maintaining are happy with the flatpak experience? If they're not, they'd probably keep maintaining their packages.
There are a limited number of build systems and most build systems have some form of dependency management built into them.
Upstreaming modifications so projects can be built using standard build commands is a more monotonous than difficult.
Doing that lets distributions reuse build pipelines accross multiple projects, which simplifies their support burden.
Similarly there are also a limited number of packaging formats and 3 main distributions which most things branch from. Configuring a project to produce an aur, deb & rpm for their base OS layout (e.g. Arch, Debian & RHEL) is again monotonous but helpful to have upstream.
Take an Electron App, this is based on Node.js and will use NPM or Yarn to build and retrieve dependencies.
While both support script extensions, the convention for NPM building and releasing is:
NPM provides libraries to create, aur, rpm and deb artefacts. You would add them as additional scripts, which are called as part of prepublish script (which gets called as part of publish).
There is no reason that can't live upstream.
The problem here is that most packages aren't maintained by developers, but rather by independent package maintainers from respective distributions.
In my eyes, this adds another potential point of failure outside the control of the developer of a given tool.
On the contrary. The Fedora maintainers saved all their Audacity users when audacity introduced a spyware in their build. The flatpak had the spyware for months while the Fedora release of audacity was made secure by the maintainers. I value this, if you remove the people doing it then you remove value for everyone. It all comes down to how much you value your privacy.
Windows has a fantastic model where every software just work. It's great! The result is an abomination of devs stealing your data or doing whatever mess on your computer. "Free software" was synonymous of red alerts and we used programs like Adaware or whatever cleaner software. Each months there was another new cleaner utility. When was the last time you cleaned your distro?
Try to expand the scale of flatpak and you'll see that you will hit the same problems that any other distro.
I don't really see Fedora maintainting a patched version of audacity as a fault of Flatpak, though.
Flathub is designed to allow developers to publish their own software in the way they intended. So Flathub and Flatpak are doing exactly what they're designed to do
Well, I can't give you a better example of the effect of auditing softwares for your desktop. One source, Fedora, had the app patched, while the other, official on flathub, published the flawed version on purpose.
You'd prefer to run the flatpak version of audacity with the spyware on? I don't buy that.
Okay, so it's another way to phrase that you really preferred the version of flatpak with the spyware, since it's the version intended by Audacity. With flatpak and flathub you are alone.
Fedora and their maintainers offer you a layer of no-nonsense, you should think twice before writing it off. I don't think that you fully realize the quality of what you have right now in your hands in term of desktop. Popularity has a price and Windows users paid the price for it.