Will Flatpak and Snap replace desktop Linux native apps? : linux

[–] Alexmitter@kbin.social 17 points 1 year ago* (last edited 1 year ago) (2 children)

Snap? It is fundamentally broken and Canonical shows zero interest in fixing that. Instead they try to patch applications to not be as awful when running via Snap.
Firefox is the best example, its a big application and suffers greatly from taking forever to start on Snap because of course the filesystem image is compressed, so it needs to be uncompressed, mounted and then firefox can start which is still slowed greatly due to snaps poor I/O performance.

A unpatched firefox took 30 seconds to start on Snap, they patched it to load only one language pack and some other small things, and now it starts in incredible 15 seconds.

Which is shit poor compared to the native firefox starting in one second and the flatpak starting in also one second. All on the same machine.

Snap is by far the most cruel joke out of canonical.

Flatpak has no such problems.

[–] atmur@kbin.social 4 points 1 year ago (1 children)

100% agree. Snaps are kind of neat for server stuff (easiest setup of Nextcloud I've ever done, even though I switched to Docker in the end), but man the desktop experience is god awful.

I had to setup an Ubuntu VM at work to run something I couldn't do on the Windows host, I tried to open Firefox and it took ages to start. I literally began trying to troubleshoot why it wasn't opening before it finally started. Completely unusable and I have no idea why Canonical thinks this is an actual competitor to Flatpak.

[–] Alexmitter@kbin.social 7 points 1 year ago

Snaps are kind of neat for server stuff

Theoretically yes, until you find out that Snap will force update your server snaps without any way to disable it. Best you can do is pause it. This is absolutely unacceptable for anyone serious about server stuff.

[–] softpboy@kbin.social 1 points 1 year ago

Can't tell how's snap today. I refused to use it when snap vlc couldn't access an external drive, and it wasn't by mistake, snap couldn't (and I'm nos sure if it can today) access external drives. I looked how to fix it and apparently canonical knew it and was ok with that, they said it was a feature of snap packages so, bye bye ubuntu, hello manjaro (back then, now I use debian)

[–] PabloDiscobar@kbin.social 16 points 1 year ago* (last edited 1 year ago) (1 children)

If you want to keep building Linux and its apps with stone knives and bearskins, you can – more power to you. But, the future of the Linux desktop is here, and it's going to be containerized.

Nice job antagonizing your readers. This is insulting and totally uncalled for. I know that his job is to sell clicks but he has completely lost credibility with this one.

[–] stevecrox@kbin.social 1 points 1 year ago

Its the register, their tag line is "biting the hand that feeds IT".

For a while they would produce playmobil scenes of stories, they covered Paris Hilton alot because she is clearly IT related.

They used to refer to Google as "The Chocolate Factory", so clearly everyone who worked there was an oompa lumpa.

There is usually some insightful analysis buried under the biting satire, jokes and general sillyness.

Personally I am still hurt the suggested DxC Corporate Slogan "we're not happy, until you're not happy" didn't win the poll.

[–] chuso@kbin.social 8 points 1 year ago (1 children)

Probably unpopular opinion: I hope that happens sooner than later.

I always saw packaging every piece of software for every distribution as a lot of duplicate work that could be better used somewhere else.

As an example, Gentoo's default repository has ~18k packages (not to mention the many other packages in additional repositories), each one of them with its own building script, maintainers and tests.
Most of those packages are also present in other Linux distributions, again with their own maintainers, different building scripts and having passed their own tests.

Doesn't that sound like a lot of duplicated work for each distribution that could be used instead on improving the core system and pushing the burden of packaging applications upstream as flatpaks?

Also, since flatpak packages dependencies with the application, they could fix the dependency hell problem in a big part because the developer will determine what dependencies your package runs with, instead of relying on whatever version of the dependencies may be installed in your system.

And it could also solve the quick death of Linux applications. I'm sure most of you saw how quickly applications get unusable in Linux. You find an application you like, but because it was developed for an older version of some library (like OpenAL or GTK+2) you cannot use it anymore.
Have you seen that in Windows? You can still use most of the applications developed for Windows XP in Windows 10.

That of course has its drawbacks. Because you are packaging dependencies with the application, you will have duplicates of the same library for each application, but I think that's a fair price to pay for more stable and durable applications. That's very similar to what Windows applications do.

I'm talking about flatpak. Like most of the people here, my experiences with snap were bad, I am not interested in it and I think it's Cannonical going their own way.

[–] dm_me_your_secrets@kbin.social 2 points 1 year ago

I couldn't have said it better myself. The wasted space because of duplicate dependencies is negligible and worth it.

[–] key@lemmy.keychat.org 6 points 1 year ago (1 children)

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.

[–] moon_matter@kbin.social 2 points 1 year ago (1 children)

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.

[–] AnonTwo@kbin.social 1 points 1 year ago (2 children)

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.

[–] stevecrox@kbin.social 1 points 1 year ago

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 install
npm build --if-present
npm test --if-present
npm publish

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.

[–] TGRush@forum.fail 1 points 1 year ago (1 children)

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.

[–] PabloDiscobar@kbin.social 1 points 1 year ago (1 children)

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.

[–] TGRush@forum.fail 0 points 1 year ago (1 children)

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

[–] PabloDiscobar@kbin.social 2 points 1 year ago

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.

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

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.

[–] Badabinski@kbin.social 6 points 1 year ago

I want both. Flatpak has saved me some heartburn a couple of times, but the distro I'm using dramatically reduces the need for it. I like native applications running with the shared libraries present on my system. I use flatpak as an escape hatch for when that breaks, meaning I've used it twice.

[–] userdata0@kbin.social 6 points 1 year ago (1 children)

Man, the experience with firefox in Ubuntu right now is kinda painful with the snaps. Updating in the background causes the browser to crash or become unresponsive.

[–] Alexmitter@kbin.social 2 points 1 year ago

Snap is fundamentally broken to the core. Just use flatpak.

[–] thingsiplay@kbin.social 5 points 1 year ago

There is no need for. Flatpak as an additional format is nice to have, but I don't want to trust 200 independent sources. I want to trust my distribution who test and bring those stuff together into a native packaging format, specialized for the distribution. I don't want to fiddle with every Flatpak application until it gets the correct rights for my setup or try to make it look like any other native package. Flatpak does not even work with CLI programs (but could be extended to in the future).

Flatpak is great for big and complicated programs, such as Firefox and LibreOffice. Especially if they get a lot of updates and need to be as fast as possible distributed, such as any web browser.

[–] phi1997@kbin.social 4 points 1 year ago

I like Flatpak, but I do not want it to be the only option. My experience with Firefox as a Flatpak hasn't been smooth

[–] atmur@kbin.social 4 points 1 year ago* (last edited 1 year ago) (1 children)

I'm in the camp of thinking Flatpaks are definitely the future for GUI applications. While there are definitely cons...

CLI applications are not feasible as Flatpaks. This isn't what Flatpak is designed for, standard package management will still be needed here.
Dependency duplication wastes storage space, but I'm personally willing to give up a couple GBs for the benefits I get.
Developers might package their application incorrectly. This is possible, but it hasn't caused any notable issues for me in the 2 years that I've been primarily using Flatpaks.
As far as I'm aware, Flatpak doesn't have a way to allow applications to set udev rules. This generally doesn't matter, but for something like Steam Input, you will need to install the steam-devices package or setup udev rules manually so it can manage your controllers. Google's Android Flash Tool also doesn't work out of the box in the Chrome Flatpak last I checked.

...The pros more than outweigh these (in my opinion at least).

Non-distro-specific packaging means you can use Flatpaks on whatever distro you want. You can have more up-to-date applications on stable distros like Debian, or on smaller distros that don't have the resources to package every application possible. Rather than Red Hat spending a significant amount of time packaging LibreOffice for RHEL/Fedora, they can just rely on the Flatpak and spend time on more important elements of the distro itself. There's also Bottles, which enters dependency hell if packaged incorrectly, they had a blog post about this a while ago.
Application files are stored in one place in ~/.var/app. For some apps this doesn't matter, but it keeps applications like Steam from cluttering up your home directory with random game saves and other garbage. This also makes backups easier since you already know where all applications keep their files.
It makes immutable distros actually usable, which I believe will be the future for some use cases.
Permissions management. Even if no one is setting privileges for their applications correctly right now, having the groundwork for this in place will be important if more proprietary applications are going to be ported to Linux in the future.

[–] Alexmitter@kbin.social 2 points 1 year ago (2 children)

CLI applications are not feasible as Flatpaks.

Simply wrong, there are already lots of CLI applications on flatpak.

[–] atmur@kbin.social 4 points 1 year ago

Having to prefix commands with "flatpak run org.whoever.whatever..." gets old quickly, and setting aliases to get around it isn't user friendly. It's certainly possible, it's just not practical (which may have been a better word to use than "feasable" in my first comment).

[–] TGRush@forum.fail 1 points 1 year ago

Let's paraphrase to "CLI applications are quite cumbersome to use under Flatpak as per the current implementation".

Unless you set up your own aliases, you'll have to write out commands like flatpak run ..., and if you don't know the package name yet you'll need to run flatpak list --app first as well

I hope that in the future, Flatpak gets some improvements for exporting CLI utilities into the user's environment.

[–] cjerrington@kbin.social 3 points 1 year ago

Ubuntu is already looking to All-Snap Ubuntu Desktop Will Be Available Next Year

[–] priapus@lemmy.one 3 points 1 year ago

I like flatpak for gui apps, especially proprietary ones. For all open source apps i'll be sticking with Nixpkgs.

[–] ozoned 3 points 1 year ago

I'm hoping on Flatpak personally. I like ostree distros with constantlt updated end user applications.

[–] binboupan@lemmy.kagura.eu 2 points 1 year ago

I wonder how many loopback mounts would a full snap system have. Oh god no.

[–] gnuplusmatt@kbin.social 2 points 1 year ago (1 children)

Kinoite user here, the majority of my desktop apps are in flatpaks already. I have a couple of things in toolbox/distrobox containers

[–] eltimablo@kbin.social 2 points 1 year ago

I've also been on immutable Fedora for a while, and the biggest complaint I have is that I need to reboot after removing software from the base system. Otherwise I quite like Flatpak for the ability to set granular permissions per app. KDE even has Flatseal built into the settings app now, which is super nice.

[–] orcrist@lemm.ee 0 points 1 year ago (2 children)

Why should that happen at all? I'm quite happy using one of the major distributions. The software that I want to work works, and it's reasonably reliable.

[–] Glome@kbin.social 3 points 1 year ago

Immutable OS's like fedora silverblue tend to prefer flatpaks due to the read only nature of system files. Yes, you can rebuild the image and layer the rpm package over the rest of the system, but that's really supposed to be kept to a minimum.

[–] staticlifetime@kbin.social 3 points 1 year ago (1 children)

Sandboxing and greater flexibility in using older or conflicting packages/libraries.

[–] PabloDiscobar@kbin.social 5 points 1 year ago (2 children)

Sandboxing is a buzzword here. Look at the flatpaks, people don't sandbox, they apply the maximum permissions until the application stops making errors at startup. This is not sandboxing.

And don't expect for a second that the security will be enforced on older libraries.

[–] TGRush@forum.fail 1 points 1 year ago

Users upping permissions is not something that Flatpak is to blame for.

Flatpak has set the groundwork for sandboxing of desktop apps with a runtime permission system. People dont yet know how to properly use it.

[–] staticlifetime@kbin.social 1 points 1 year ago* (last edited 1 year ago)

people don't sandbox

Yes they do. Do they all sandbox all things? No. Does it require sandboxing? No. But these are moot points. If you need it, you can have it. These are not available with traditional packages. Whether or not something works properly when sandboxed is sort of a side point, because it simply means that stuff needs to be worked-out. Since when do we have perfect stuff out of the box in FOSS though?

You're holding it to greater standards, IMO.