Atomic distros are cool, and I’m sure they will only get more popular, but I don’t buy the idea that they’re “The” future. They have their place, but they can’t really completely replace traditional distros. Not every new thing needs to kill everything that came before it.
For me, it’s the unrenameable, unmoveable, non-hidden snap directory in my home directory’s root that doesn’t even follow the naming convention of the other directories in there.
SpaceNoodle@lemmy.world
on 07 Jul 04:06
nextcollapse
What everyone else has already said, plus sudden updates that nuke active applications.
> plus sudden updates that nuke active applications.
This is not what’s supposed to happen. If an app installed through flatpak is active while it’s receiving an update, then the update is not supposed to affect the running application until it’s closed/restarted.
Edit: Somehow I didn’t realize the concern was raised against Snap and not Flatpak.
joeldebruijn@lemmy.ml
on 07 Jul 05:13
nextcollapse
Snap is not all bad if you’re on a Ubuntu based distro, I just don’t like the way it’s pushed and that it comes from Ubuntu mostly. Startup time is a major issue for me also, but all in all it works.
I’m still sitting on the fence, heavily prefer flatpak but when Ubuntu is going to package nvidia drivers in a snap it’s a thing I’m up for trying.
My understanding is that if I’m on Ubuntu and the snap uses the same underlying Ubuntu version as my distro it should be fast but I haven’t seen it.
Immutable OSes are difficult to use for coding or other tasks that include installing many terminal utilities and for that reason, I don’t recommend them and certainly don’t want them to be the future of Linux distros. And if I’m going to create a container running a different distro to install and run the apps I want to use, then I may as well use that distro on my host.
You just move to user directory installation of most tools via brew on Linux. It’s not difficult. The Bazzite distro handles all this incredibly well via brew, flatpaks, and distrobox.
bad_news@lemmy.billiam.net
on 07 Jul 01:52
nextcollapse
I would be, but the promise is just broken. Let’s say you want to do the new cool thing and run Bazzite on your console gaming PC on your TV. Now you also want to watch videos that are any normal format these days or (GASP) HEVC like you could on an XBox. You install flatpak VLC because it “just plays everything” in your experience. Your experience is ruptured for both VLC and flatpak now. Flatpaks run on system .so’s actually sometimes and installing a Flatpak doesn’t mean an app “just works” like Mac or Windows…
I get the convenience, I really do, and works on every linux distro which is a plus, but I usually stay clear of them because of the bloat. Maybe that is a misconception on my part. I should preference that with the fact I use Arch (btw)…so AUR usually has everything I need.
bad_news@lemmy.billiam.net
on 07 Jul 02:02
nextcollapse
It doesn’t even produce convenience versus just doing AUR package install, though! Nor does it actually containerize for security well! It is bloat alone with shit user experience!
Edit: to be fair I should note that VLC in Fedora recently came into conflict with Fedora nonfree blocking all updates via some 1997-level RPM jank, idk whose fault it was, but Flatpak gets you around that so it is not without use
Edit on edit: it runs and doesn’t preclude install but current VLC does not work on Fedora out of the box with ANY nonfree codecs
cupcakezealot@piefed.blahaj.zone
on 07 Jul 02:05
nextcollapse
i had a hard time getting used to them but now i love them in mint i can switch between the package version and flatpak version and usually the fp one is more updated
On the other hand each flatpak uses >1Gb of disk where deb packages rarely require more than 100Mb
SnotFlickerman@lemmy.blahaj.zone
on 07 Jul 02:52
nextcollapse
See, I only use flatpaks sparingly for this reason, but in some cases they’re indispensable when you don’t want an application to access certain parts of your system. The sandboxing is what makes them useful, in my opinion. For everything else, there’s the deb packages.
That’s not really true. It lists all the flatpak dependencies in that disk use, but a lot of those are shared, so they don’t actually use that much each if you install more than one, and the deb dependencies aren’t included at all. Flatpaks really do use more space, especially if you only have a small number of them, but it’s not as bad as that.
No you weren’t. That would be ridiculous. The deb dependencies are most of your Linux install. Maybe counting just the new dependencies being installed alongside a typical deb install, but that’s still not an apples to apples comparison to 100% of all the flatpak dependencies, even ones shared with other flatpaks, and even that’s still very rarely over 1GB.
That’s certainly a concern for some, but I’m using like 30 GB for all the things I’ve installed, which is a lot (12 (flatpak-system), 76 (flatpak-user)) but that’s on a 2 TB drive, which amounts to like 1½% of the total available space. I don’t think that’s a bad trade.
Compared to a pure install that can run on an electric toothbrush it’s a massive pill to swallow for some.
Thorned_Rose@sh.itjust.works
on 07 Jul 07:10
collapse
And not many consider the environmental impact of this either. Sure storage might be cheap (not in my country but I digress) but more space still requires more storage and across thousands of computers and then millions of computers that’s not an insignificant increase. We should be increasing technological efficiency not what were doing at the moment which seems to be just throwing more power and resources at the problems.
Plus I found on my install flatpak wasn’t cleaning up the flatpaks autoinstalled for older versions of nvidia drivers, they were all still listed as dependencies. Not sure who’s to blame but that was taking up a few much needed GBs.
I agree that flatpak should just invoke flatpak uninstall --unused right after uninstalling a flatpak. I don’t get why it doesn’t do this automatically. Granted, some distro package managers (used to) operate somewhat similarly in that they required the autoremove option.
I actually tried flatpak uninstall --unused and it didn’t remove these ones. So there’s something odd going on there. My guess is maybe Mint manually installed them through the driver manager program? That’s a wild guess, I don’t know how it works.
I’ve packaged a CLI that I made as a flatpak. It works just fine. Nothing weird was required to make it work.
The only thing is that if you want to use a CLI flatpak, you probably want to set an alias in your shell to make running it easier.
I’m not sure why more CLIs aren’t offered as flatpaks. Maybe because static linking them is so easy? I know people focus on flatpak sandboxing as a primary benefit, but I can’t help but think of static linking was easier for bigger applications, it wouldn’t be needed as much.
IDK why you’re being so rage baity. Its easy to avoid flatpaks if you dont like them. Only thing I’ve ever found as an obstacle was adding the binaries to my PATH so I can launch it with dmenu_run. Otherwise my package manager works well enough.
Bonus points: Write a PKGBUILD that installs flatpaks to /opt and symlink out binaries as needed.
KDE Discover and GNOME Software can install from FlatHub (or other Flatpak repos, if you add those).
cmgvd3lw@discuss.tchncs.de
on 07 Jul 02:49
nextcollapse
There are merits to using flatpaks. With flatseal application, you can fine-tune the permissions given to a certain flatpak application. The best thing is restricting internet usage.
I love installing things from the CLI and prefer to only do it that way but Linux needs a single click install method for applications if it’s ever going to become a mainstream OS. The average person just wants to Google a program, hit download and install. If not that then they want to use a mobile-like App Store.
Flatpak is kind of perfect at achieving both those things
SpaceNoodle@lemmy.world
on 07 Jul 03:08
nextcollapse
Oh 100% but have you tried to explain how to use one to a computer novice? Like yes, the answer is usually “they should just…” but novice users will never. With flatpak, they get an experience similar to how MacOS works and a bit like how .exes work and it Just Works™️
Edit: like I’ve had trouble showing people how to use the GNOME App Store which could not be any more simple. Anyone who has been convinced to install Linux already feels way out of their element so making everything feel as natural as possible is essential (and I mean, flatpaks are awesome anyway)
Wait how do you install flatpaks? I add the remote (if necessary) and then install it from there. That is nothing like I have ever seen on Windows (though apparently there are package managers).
That just displays the command or is there a browser extension that runs it for you too? Most Windows apps certainly don’t run by just clicking a button either.
Edit: and if you happen to download an rpm, you just double click it in the filemanager (or single click if that is your setting) and it launces the install GUI.
Its similar to how MSI file install looks…just next next finish kind of thing
For sure and I agree that should be enough but the average person is not good with computers and they don’t want to learn. They won’t understand the nuances of different distributions of Linux. Like try explaining the difference between a .deb, a .tar.gz, and a .rpm to a person who’s already hésitent about using Linux. Flatpak solves that by just having one download that any Linux install can use
thingsiplay@beehaw.org
on 07 Jul 04:15
nextcollapse
Those mystical average people would probably stay on Windows, if they don’t care or cannot learn basics of other systems. Its really not hard to explain and understand, even for “average person” that there is an universal source for applications and there are packages designed and managed by your operating system. I think its important for people to learn basics and we should teach them, not dumb them down like on Windows. Soon people won’t be able to eat themselves anymore…
Just go to the package manager, type in the name of the program, install.
That’s easier than on windows: go to the browser, search for the program, avoid the ads, search for the download button, follow the install wizard, avoid the toolbar
corsicanguppy@lemmy.ca
on 07 Jul 02:58
nextcollapse
Former OS security here (I worked at an OS vendor who sold an OS or two and my job involved keeping it secure).
Fuck no.
Sorry if that makes you downvote, but it doesn’t make them safer.
giacomo@lemmy.dbzer0.com
on 07 Jul 03:06
nextcollapse
A few reasons security people can have to hesitate on Flatpak:
In comparison to sticking with strictly vetted repos from the big distros like Debian, RHEL, etc., using Flathub and other sources means normalizing installing software that isn’t so strongly vetted. Flathub does at least have a review process but it’s by necessity fairly lax.
Bundling libraries with an application means you can still be vulnerable to an exploit in some library, even if your OS vendor has already rolled out the fix, because of using Flatpak software that still loads the vulnerable version. The freedesktop runtimes at least help limit the scope of this issue but don’t eliminate it.
The sandboxing isn’t as secure as many users might expect, which can further encourage installing untrusted software.
By a typical home user’s perspective this probably seems like nothing; in terms of security you’re still usually better off with Flatpak than installing random AUR packages, adding random PPA repos, using AppImage programs, installing a bunch of Steam games, blindly building an unfamiliar project you cloned from github, or running bash scripts you find online. But in many contexts none of that is acceptable.
I mean, they added “bash scripts you find online”, which are only a problem if you don’t look them over or cannot understand them first… Their post is very much cemented in the paranoid camp of security.
Not that they’re wrong. That’s the big thing about security once you go deep enough: the computer has to work for someone, and being able to execute much at all opens up some avenues of abuse. Like securing a web based service. It has to work for someone, so of course everything is still vulnerable at some point. Usually when private keys or passwords are compromised if they’re doing things remotely correctly, but they’re still technically vulnerable at some point.
The parent comment mentions working on security for a paid OS, so looking at the perspective of something like the users of RHEL and SUSE: supply chain “paranoia” absolutely does matter a lot to enterprise users, many of which are bound by contract to specific security standards (especially when governments are involved). I noted that concerns at that level are rather meaningless to home users.
On a personal system, people generally do whatever they need to in order to get the software they want. Those things I listed are very common options for installing software outside of your distro’s repos, and all of them offer less inherent vetting than Flathub while also tampering with your system more substantially. Though most of them at least use system libraries.
they added “bash scripts you find online”, which are only a problem if you don’t look them over or cannot understand them
I would honestly expect that the vast majority of people who see installation steps including curl […] | sh (so common that even reputable projects like cargo/rust recommend it) simply run the command as-is without checking the downloaded script, and likewise do the same even if it’s sudo sh. That can still be more or less fine if you trust the vendor/host, its SSL certificate, and your ability to type/copy the domain without error. Even if you look at the script, that might not get you far if it happens to be a self-extracting one unless you also check its payload.
They always seem to have some critical limitation. Handbrake is too slow via flatpak to work. Flatpak Zoom had no camera access. Flatpak-only Zen browser can’t use passkeys. Zen browser asks to be my default browser every time I open it, even though it is and I always say yes; is this a flatpak limitation? I don’t know, and I’d prefer not to have to figure it out just for some theoretical benefits and more overhead.
Is there no other way on your system to see what the default browser is? On Gnome you can see a few of your default applications in the settings. And what happens if you open an html file for example? Does it open in Zen? If yes then it appears that Zen is set as your default browser, what more is there to check?
I used them for some things, but other things still don’t work quite right. Take Steam for example. I do love flatpaks for testing out apps, things with really finicky dependencies, or pinning a specific version of a software that I want to continue to work in the future. However, for most things, Arch + AUR just covers all my needs without any hiccups.
To me flatpaks are sort of like NixOS. All the benefits they provide aren’t something I need on a daily basis. Rolling back works just fine 99% of the time with downgrade. I already have system backups. Despite what some articles might insist, things don’t just break all the time. I’m not running untrusted software.
Basically no solution is perfect, but they don’t need to be. If the benefits I gain can be recreated through other methods without the tradeoffs they introduce, then I will go with that. Of course, that isn’t to say they don’t have their place, but sometimes I feel like some people think that “being designed from the ground up” to handle certain use cases is always better than whatever “cobbled together” thing we currently have and that isn’t always the case. I’m specifically quoting those two phrases because these are the exact phrases you will hear projects using to justify their existence. In fact, I would go so far as to say that some people have outright confused modularity for “cobbled together”.
One last example I want to make is that I make use of projects like the fish shell and helix editor. In these cases, I find the features they introduce to be worth the tradeoffs and work better because of being designed “from the ground up” to do what they do. However, I don’t make use of immutable systems, containers such as docker, or say filesystems such as btrfs. The features they provide are not useful enough to me compared to the problems they introduce.
thingsiplay@beehaw.org
on 07 Jul 03:58
nextcollapse
Flatpak have their own set of issues. One thing is, that Flatpak applications do not integrate that easily and perfect like a native package. Either rights are to given, you need to know what rights are needed and how to set it up. Theming can be an issue, because it uses its own libraries in the Flatpak eco system instead your current distributions theme and desktop environment.
But on the other hand, they have actually a permission system and are a little bit sandbox compared to normal applications. Packages often are distributed quickly and are up to date directly from the developers, and usually are not installed with root rights.
I’m pretty much a CLI guy as well and prefer native packages (Arch based, plus the AUR). But I also use Flatpaks for various reasons, alongside with AppImages.
DrunkAnRoot@sh.itjust.works
on 07 Jul 04:09
nextcollapse
my issue with all of these gui tools ut never forces you to learn the cli to fix things just use guis
Don’t AppImages also have a similar requirement just with stuff that is already installed on many popular distros so many people just don’t notice it? I think I read somewhere that running AppImages on systems that even slightly differ from the big popular distros is a pain since you still have to ship this stuff with them but it is more cumbersome than with flatpaks.
Flatpaks together with “immutable” distributions, Wayland and systemd are a heresy, a crime against the UNIX principles, a disgrace in the eyes of of SED and AWK. REPENT! Save your immortal core dumps and return to the one true /home !
theyre whatever, they have their place in my system, but inprefer installing debs from the repo
BrianTheeBiscuiteer@lemmy.world
on 07 Jul 05:08
nextcollapse
If it’s a mostly self-contained app, like a game or a utility, then Flatpak is just fine. If a Flatpak needs to interact with other apps on the host or, worst case, another Flatpak it gets tricky or even impossible. From what I’ve seen though, AppImage and Snap are even worse at this.
Flatpak doesn’t support dev device access no matter what I use flatseal and all the shabang, so bottles is useless to me for a lot of the wine applications I would like to “not emulate”
data1701d@startrek.website
on 07 Jul 05:17
nextcollapse
I’d take a well-maintained native package for my distro over a Flatpak, but sometimes, a Flatpak is just the the easiest way to get the latest version of an application working on Debian without too much tinkering - not always no tinkering, but better than nothing.
This is especially true of GIMP - Flatpak GIMP + Resynthesizer feels like the easiest way to experience GIMP these days. Same with OBS - although I have to weather the Flatpak directory structure, plugins otherwise feel easier to get working than the native package. The bundled runtimes are somewhat annoying, but I’m also not exactly hurting for storage at the moment - I could probaby do to put more of my 2 TB main SSD to use.
I usually just manage Flatpaks from the terminal, though I often have to refresh myself on application URLs. I somewhat wish one could set nicknames so they need not remember the full name.
sovietknuckles@hexbear.net
on 07 Jul 05:36
nextcollapse
I prefer Arch Linux’s use of flatpaks, which is none at all ever
underscores@lemmy.zip
on 07 Jul 07:23
nextcollapse
Me pretty much only ever using arch Linux: “what the fuck is a flatpak”
I once had to install Firefox into wsl (Ubuntu) and I wanted the kms on the spot.
But maybe it’s not that bad for newer people to get started with Linux.
Which ones? Everything in the arch main repos are compiled for your system, and most things in the AUR can either be built from source, or have -bin installs.
aleph one from the AUR refused to run properly, often crashing on startup so i just grabbed the flatpak
the weirdest one was ghostwriter from the official repos, for some reason one day the preview window showed heavily corrupted output and tinkering with it on and off for a week did nothing, including a complete purge and reinstall of the program
the flatpak was the only version of it that worked after that
Mostly because of detailed and easy permissions, and also because I have other distibutions on my other computers and want my programs to be consistent everywhere - same programs, same version.
chicken@lemmy.dbzer0.com
on 07 Jul 05:49
nextcollapse
When I open my task manager I see flatpak-session-helper near the top of the list for ram usage and am suspicious
Default_Defect@midwest.social
on 07 Jul 05:49
nextcollapse
My favorite part of the linux experience is the FREEDOM, but also being talked down to for not using my freedom correctly, I should only do things a specific way or I might as well just use windows.
Jankatarch@lemmy.world
on 07 Jul 06:49
nextcollapse
You don’t have to do as they say but doing so lets you talk down to others who aren’t. So it’s a fair trade.
Because using your freedom to promote options that restrict freedom means helping to remove your freedom. But hey, what do the Linux elders know? Clearly the new people into Linux are far smarter…
gravitas_deficiency@sh.itjust.works
on 07 Jul 18:37
nextcollapse
It’s extremely context-dependent.
If we’re talking about enterprise-grade, five-nines reliability: I want the absolute simplest, bare-bones, stripped down, optimized infra I can get my hands on.
If we’re talking about my homelab or whatever else non-critical system: I’m gonna fuck around and play with whatever I feel like.
You are mixing different ideas of freedom.
Software freedom is not the same as freedom of choice of software.
You don’t need Linux to have choices of what software to use, you have that in most (all?) proprietary systems, in some you might even have more choices than in Linux… even if it includes proprietary software.
This is analogous to how being a free person (not a slave) is not the same as having freedom to choose who to work for, even if some of them are slavers (ie. having freedom to choose your master).
Lettuceeatlettuce@lemmy.ml
on 07 Jul 06:36
nextcollapse
Flatpaks are pretty great for getting the latest software without having to have a cutting edge rolling release distro or installing special repos and making sure stuff doesn’t break down the line.
I use Flatpaks for my software that I need the latest and greatest version of, and my distros native package for CLI apps and older software that I don’t care about being super up to date.
My updater script handles all of it in one action anyways, so no biggie on that either.
Flatpaks are the best all-in-one solution when compared to Appimages or Snaps imo.
without having to have a cutting edge rolling release distro
Oh, that explains why they’re completely bloated & useless to me. Arch btw
The_Grinch@hexbear.net
on 07 Jul 06:39
nextcollapse
I don’t like how so many distros ship with discover configured to install flatpaks by default. It’s a huge newbie trap when you click “open file” and uh where are all my files??
You should only install a flatpak if the program is not available for your OS, or if the native version doesn’t work for some reason.
Core_of_Arden@lemmy.ml
on 07 Jul 06:56
nextcollapse
Not a fan. There’s often trouble, and some settings is hassle, and sometimes not even working.
juipeltje@lemmy.world
on 07 Jul 07:47
nextcollapse
I’m starting to think that in terms of features and possiblities, nix might truly be the best third party package manager of all. But the downside is that especially when using it the way it’s recommended, combined with home manager, it has the steepest learning curve. Also graphical apps can be problematic. There is a tool called nixgl that tries to solve this, but it’s a wrapper, so when a nix application opens a child process that needs to use the native system drivers, that childprocess is also wrapped in nixgl and it breaks. I recently found a neat workaround on github to solve this in a better way, which is to create a driver package manually with home manager, and symlink it to /run/, which is also where the drivers are linked on NixOS. This is a gamechanger to me because with no driver problems anymore, you can install almost everything through nix on pretty much any distro, except maybe for some programs that need system level access to run. You can install graphical programs, cli programs, and even entire window managers with it. I’m using full NixOS at the moment, but i’m seriously debating moving back to void linux with nix on top. Currently messing with it in a vm to test my configs.
I kinda like flatpaks being an option, not sure when they are the only option though.
Commiunism@beehaw.org
on 07 Jul 08:13
nextcollapse
I like them as an option, there are some programs like Bottles or specific game launchers that work under flatpak better than the versions available via native package manager (with Bottles in particular, you can use various built-in sandbox features via flatpak which makes things a bit more secure), but it’s also a bit of a pain because it’s an additional package manager you have to update separately now, or tweak if things go wrong.
Certainly a fan, and I don’t understand the hate towards it.
Flatpaks are my preferred way of installing Linux apps, unless it is a system package, or something that genuinely requires extensive permissions like a VPN client, or something many other apps depend on like Wine.
The commonly cited issues with Flatpaks are:
Performance. Honestly, do you even care if your Pomodoro timer app takes up 1 more megabyte of RAM? Do you actually notice?
Bloat. Oh, yes, an app now takes 20 MB instead of 10 MB. Again, does anybody care?
Slower and larger updates. Could be an issue for someone on a metered traffic, or with very little time to do updates. Flatpaks update in the background, though, and you typically won’t notice the difference unless you need something newest now (in which case you’ll have to wait an extra minute)
Having to check permissions. This is a feature, not a bug. For common proponents of privacy and security, Linuxheads grew insanely comfortable granting literally every maintainer full access to their system. Flatpaks intentionally limit apps functionality to what is allowed, and if in some case defaults aren’t good for your use case - just toggle a switch in Flatseal, c’mon, you don’t need any expertise to change it.
What you gain for it? Everything.
Full control over app’s permissions. Your mail client doesn’t need full system permissions, and neither do your messengers. Hell, even your backup client only needs to access what it backs up.
All dependencies built in. You’ll never have to face dependency hell, ever, no matter what. And you can be absolutely sure the app is fully featured and you won’t have to look for missing nonessential dependencies.
Fully distro-agnostic. If something works on my EndeavourOS, it will work on my OpenSUSE Slowroll, and on my Debian 12. And it will be exactly the same thing, same version, same features. It’s beautiful.
Stability. Flatpaks are sandboxed, so they don’t affect your system and cannot harm it in any way. This is why immutable distros feature Flatpaks as the main application source. Using them with mutable distributions will also greatly enhance stability.
Alternatives?
AppImages don’t need an installation, so they are nice to see what the program is about. But for other uses, they are garbage-tier. Somehow they manage both not to integrate with the system and not be sandboxed, you need manual intervention or additional tools to at least update them/add to application menu, and ultimately, they depend on one file somewhere. This is extremely unreliable and one should likely never use AppImages for anything but “use and delete”.
Snaps…aside from all the controversy about Snap Store being proprietary and Ubuntu shoving snaps down people’s throats, they were just never originally developed with desktop applications in mind. As a result, Snaps are commonly so much slower and bulkier that it actually starts getting very noticeable. Permissions are also way less detailed, meaning you can’t set apps up with minimum permissions for your use case.
Flatpaks, appimages, snaps, etc: why download dependencies once when you can download them every time and bloat your system? Also, heaving to list installed flatpaks and run them is dumb too, why aren’t they proper executables? “flatpak run com.thisIsDumb.fuckinEh” instead of just ./fuckinEh
No thanks. I’ll stick to repos and manually compiling software before I seek out a flatpak or the like.
This shit is why hobbies and things should be gatekept. Just look at how shit PC design is these days. Now they’re coming after the OS.
As I said, dependencies typically don’t take that much space. We’re not in the '80s, I can spare some megabytes to ensure my system runs smoothly and is managed well.
As per naming, I agree, but barely anyone uses command line to install Flatpaks, as they are primarily meant for desktop use. In GUI, Flatpaks are shown as any other package, and all it takes is to push “Install” button.
If you want to enjoy your chad geeky Linux, you still can. Go for CachyOS, or anything more obscure, never to use Flatpaks again. At the same time, let others use what is good and convenient to them.
It’s not the 80s, and I can save a few megabytes to keep my system running smoothly and well-managed.
And then it turns out that you have 18 libssl libraries in diffirent fpatpacks, and half of them contain a critical vulnerability that any website on the Internet can use to hack your PC. How much do you trust the limitations of flatpack apps? are you sure that a random hacker won’t hack your OBS web plugin and encrypt your entire fpatpack partition (which some “very smart” distributions even stuff office into, and your work files will be hidden there). People have come up with external dependencies for a reason.
However, the extent of the damage is limited by flatpak and whatever permissions you have set, and, if I understand it correctly, you cannot attack one flatpak through the other unless they share access to some files.
Also, I haven’t seen this kind of attack in the wild (maybe I’m not informed enough?) as opposed to rogue maintainers injecting malware into packages.
On an unrelated note: apparently, there is finally some Russian Lemmy instance? That’s a welcome change.
However, the extent of the damage is limited by flatpak and whatever permissions you have set, and, if I understand it correctly, you cannot attack one flatpak through the other unless they share access to some files.
there is a problem here that permissions are also set by the packages developers. User in most cases click accept all and alll done.
On an unrelated note: apparently, there is finally some Russian Lemmy instance? That’s a welcome change.
Well… Appeared 2 years ago. It’s just that practically no one needs it. =)
Permissions are also set by the packages developers
True, and I don’t think it is healthy not to let them to. But it would be nice to either have some vetting on the matter, or ask user about which permissions they agree for when they install Flatpak.
Appeared 2 years ago
Ого, то есть примерно когда я сам здесь очутился. Никогда не слышал о ру инстансах, хоть и искал. Теперь, кажется, нашёл)
Берёте человечка на борт? Не обещаю сделать Рекабу главным инстансом, но всегда полезно быть по обе стороны Чебурнета, а то последнее время с забугорными беды бывают.
Eyck_of_denesle@lemmy.zip
on 07 Jul 14:40
collapse
Do all laptops users have this option? Also you keep saying megabytes when it’s never just a few megabytes. It downloads atleast a few gbs worth of data just for one gui app.
Jakeroxs@sh.itjust.works
on 07 Jul 14:48
nextcollapse
Please clarify, what option do you mean? Flatpaks are supported on any Linux system, it doesn’t matter what distro or hardware. Or if you mean sparing some megabytes - typically yes as well. The smallest amount of memory I’ve seen on a laptop is 32gb, and typically it’s no less than 250gb.
If it’s not present in you distributions’ app store, you can either enable it somewhere or download another app manager like Discover, GNOME Software, or pamac if you’re on Arch.
If installation of some app incurs a few gbs of downloads, it is likely that your system updates packages alongside installing your app. Typical Flatpak app takes 10-150 megabytes.
Eyck_of_denesle@lemmy.zip
on 07 Jul 19:41
collapse
I’ve been working on Linux for 15 years now and I perfectly remember the origin of many concepts. If you look at it through time, what would it be like:
We can build applications with external dependencies or a single binary, what should we choose?
The community is abandoning a single binary due to the increased weight of applications and memory consumption and libraries problems
Dependency hell is coming
…
Snap, flatpack, appimage and other strange solutions are inventing something, which are essentially a single binary, but with an overlay (if the developer has hands from the right place, which is often not the case)
Someone on lemmy says that he literally doesn’t care if the application is built in a single binary, consumes extra memory and have libraries problems. Just close all permissions for that application…
Well, all I can say about this is just assemble a single binary for all applications, stop doing nonsense with a flatpack/snap/etc.
UPD: or if you really want to break all the conventions, just use nixos. You don’t need snap/flatpack/etc.
Times are changing, and memory constraints for most programs are generally not relevant anymore.
But there are gaps in the libraries that, unlike distributions with dependencies, can no longer be managed. And all the security of your system depends on a small flatpack access control, which 99% of users do not understand at all and, with any problems simply opens access to the entire home directory.
I’m not saying Flatpak is perfect, but it appears to be the best we have.
I absolutely agree more needs to be done to explain permissions and have sane defaults. Flatseal in particular could introduce more warnings, and this is where non-technical users set their permissions.
In my experience, most Flatpaks do not request full home folder access by default, and making Flatpak access everything everywhere typically requires user intervention.
Native apps, meanwhile, just run with full system-wide access; I get it that they’re more vetted and more properly updated, but this is an unhealthy and insecure arrangement.
this is a system for work tasks. Of course, I understand what the developers are going for. that is Android. And it’s really nice to read the Internet on android. But try to do something more complicated than that and you’ll realize that it’s hell. However, I don’t mind if such distributions appear. Why not? I just don’t understand people who voluntarily limit their abilities. And why you don’t just install Android 64?
The flatpack approach automatically remove everything low-level from the equation. Do you want to write directly to the graphics card buffer? Read the input? Do I set the fan rotation parameters directly in the /proc? All these applications will never work in flat pack.
On the other hand, flatpack is superfluous and for convenience. You can simply build an executable file without dependencies and configure firejail for it yourself… That’s all. Or run the file from another user. That is so popular exactly bacause RedHat pushed them. Literaly like Canonical pushed snap.
All these applications will never work in flat pack.
They don’t have to! Flatpak doesn’t remove all other ways to install software. But for 95% of use cases, it will do just fine.
Firejail is good, but it only solves sandboxing part of the equation, and there’s so much more to Flatpaks than that. Also, it’s more painful to configure and is more sysadmin-oriented.
They don’t have to! Flat pack doesn’t remove all other ways to install software. But for 95% of use cases, it will do just fine.
Tell this to canonical, they even firefox put in the snap. You know that when choosing “quickly compile something for a flatpack” and “support 10+ distributions”, the developers will choose a flatpack. Which in general looks fine, until you realize that everything is just scored on the mainline of libraries and molded on anything. The most striking example of this is Linphone. just try to compile it…
Snap is cancer, and what Canonical does is insane.
In any case, it is unlikely someone will make an exclusive Flatpak for what doesn’t work inside Flatpak. But I understand it means a lot for user choice and ability to compile programs they way you want, so I fully support shipping Flatpaks alongside classical packages and source code.
Provided that flatpack has a common parent container, which is not always the case. More precisely, it almost never does. Because someone updates flatpack to new versions of the parent containers, and someone else does not.
runtime have versions too. If one runtime version use only one flatpack than exactly same as just static linking binary. Flatpack have just docker layeredfs and firejail in base.
In the initial stage of shared library support, everything was exactly the same. Let’s look at it in 5 years… When some soft will archived and die, some stop maintaining, some new crated and brakes old dependencies…
Old guy here too, used un*x before linux existed in the 90s. I still use a Debian based distro (MX) without systemd and no snap/flatpak/whatever. Just build/compile or install .deb and dependencies. Lastly unfortunately I had to install a flatpak to test “deskflow”, the first time I installed one, I feel dirty now :-(
JustEnoughDucks@feddit.nl
on 07 Jul 08:37
nextcollapse
The few things I don’t like about flatpaks (which become a problem on atomic distros that use almost all flatpak by design):
Some types of embedded development is essentially impossible with flatpaks. Try getting the J-link software connected with nrftools and then everything linked to VScodium/codeoss
Digital signing simply doesn’t work, won’t work for the foreseeable future, and is not planned to get working,
Flatpaks sometimes have bugs for no reasons when their package-manager counterparts don’t (e.g. in KiCAD 8.0, the upper 20% or so of dialog boxes were unclickable with the mouse, but I could select and modify them with the keyboard, only the flatpak version)
The status on whether it is still being actively developed or not (at least I hear a fair amount of drama surrounding it)
But besides those small things, it seem great to me.
Thanks for the input! Yes, there are still certain issues with Flatpaks (for me it was aforementioned VPNs which also don’t work through Distrobox, and it would be quite odd anyway). But overall, they manage most apps well, just as you say.
Either it did something it shouldn’t, or the system updated Nvidia drivers every time for no apparent reason. I have an Nvidia GPU, running proprietary drivers, and haven’t ever witnessed anything of the kind.
Idk how, but one time I tried installing something as a flatpak and it took like 300+MB and a very long time. I figured something was wrong, found a way to install it normally and it took like 10MB and installed quickly. Idk what went wrong, but I’ll never touch this garbage again
Edit: oh they’re not for arch. Maybe they should have told me before the 300mb slog
If i got it right, flatpacks gather all of the dependencies of the package and bundles them with tha package. Maybe those extra 290mb were from dependencies that you already had installed but that flatpak wanted to install another copy.
I wonder why they don’t just stuff them inside, like an appimage, so I can see the size when I download the program
HexesofVexes@lemmy.world
on 07 Jul 09:28
nextcollapse
Honestly, I am a little scarred from snap.
Otherwise I’m agnostic on flatpaks - I’ve used a couple and they’re ok? They just remind me of old windows games that dump all their libraries in a folder with them.
On a modern system the extra space and loss of optimisation is ok, but on older hardware or when you’re really trying to push your system to run something it technically shouldn’t, I can see it being an issue.
I’ve heard Flatpaks aren’t great at CLI tools, is that true ?
As a Nix user, I’m glad Flatpaks exist for other people, but I only ever use them when a package is not available from Nix directly. Seeing as Nix is literally the biggest package manager out there, it’s a pretty rare occurrence.
I posted this in another thread, but reposting here because a lot of people, including myself up until very recently, were under that impression:
I’ve packaged a CLI that I made as a flatpak. It works just fine. Nothing weird was required to make it work.
The only thing is that if you want to use a CLI flatpak, you probably want to set an alias in your shell to make running it easier.
I’m not sure why more CLIs aren’t offered as flatpaks. Maybe because static linking them is so easy? I know people focus on flatpak sandboxing as a primary benefit, but I can’t help but think that if static linking was easier for bigger applications, it wouldn’t be needed as much.
BudgetBandit@sh.itjust.works
on 07 Jul 10:08
nextcollapse
About the image: The joke’s on you, I install my flatpaks via the terminal.
I’ve started using flatpaks more after starting using Bazzite and I liked them more than I expected. As a dev, I still need my work tools to be native, but most of my other needs are well covered by flatpaks.
Tip: Flatseal is a great config manager for flatpaks’ permissions.
Outwit1294@lemmy.today
on 07 Jul 10:28
nextcollapse
I installed flatseal but I never understand what is essential and what is not.
I replaced Firefox system package with Flatpak because I think browser is the most used and vulnerable thing in my system. And the size seemed reasonable.
I did not replace Thunderbird because its size is almost 10 times.
DanWolfstone@leminal.space
on 07 Jul 22:40
collapse
The person you’re replying to is talking about the permissions manager flatseal, not flatpaks
Installing them is not difficult. It’s the same as any other flatpak.
The problem is when running them (actually, when running any flatpak, not just CLI tools) you need to type out the whole backwards domain thingy that flatpaks use as identifier, instead of having a proper typical and simple executable name like they would have if they were installed normally.
I end up adding either symlinks or aliases for all my flatpaks because of this reason. After doing that it’s ok… but it’s just an extra step that’s annoying and that the flatpak devs have no interest on fixing apparently.
I am definitely a fan. A lot of people say that flatpaks are bad because of sandboxing but I haven’t seemed to have any issues with it.
Although I do try to use dnf when a dnf package is available (I use fedora)
bvoigtlaender@feddit.org
on 07 Jul 11:43
nextcollapse
iit: nerds unable to comprehend that building a piece of software from source in not something every person can do.
EDIT: or doesn’t want to do
jwmgregory@lemmy.dbzer0.com
on 07 Jul 11:58
nextcollapse
one of my least favorite things about arch and other rolling distros is that yay/pacman will try and recompile shit like electron/chromium from source every few days unless you give it very specific instructions not to - which is annoying as shit bc compiling the entirety of chrome from source takes hours even with decent hardware.
granted, i fucking hate google products too but if you’re doing any web dev it’s necessary sometimes.
idk im definitely willing to admit i might be the idiot here. managing your packages with pacman might just be routine to some people. to me arch is the epitome of classic bad UX in an open source project. it’s like they got too focused on being cmatrix-style terminal nerds and forgot to make their software efficiently useable outside of 5 very specific people’s workflows. it’s not even the terminal usage that is bad about arch. plenty of things are focused on that and… don’t do it shittily? idk…
edit: yes to all the arch fanboy’s points in response to me. i used to be super into arch and am aware of the fact that this isn’t explicit behavior but to act like it doesn’t happen in a typical arch user experience is disingenuous. i also disagree with the take that arch doesn’t endorse this outright with its design philosophy, bc it does. the comparison of the AUR to other, similar things like PPAs doesn’t land for me bc PPAs aren’t integrated into the ecosystem nearly as much as AUR is with arch. you can’t tell people to just grab the binaries or not use AUR whenever it’s convenient to blame the user, when arch explicitly endorses a philosophy amicable to self-compilation and also heavily uses the AUR even in their own arch-wiki tutorials for fairly basic use cases. arch wants to have its cake and eat it too and be a great DIY build it yourself toolkit while also catering to daily driver use and more generalist users. don’t get me wrong, it’s the best attempt at such a thing i’ve seen - but at a certain point you have to ask if the premise makes sense anymore. in the case of arch, it doesn’t and it causes several facets of the ecosystem to flounder from a user perspective. the arch community’s habit of shouting “skill issue” at people when they point out legitimate issues with the design philosophy bugs the fuck out of me. this whole OS is a camel.
ahoneybun@lemmy.world
on 07 Jul 12:03
nextcollapse
I get that with NixOS even if I use a tablet as my release. It’s pretty annoying if it is too new and not cached yet.
I’ve been on Garuda for 4 years or so, not once has this happenoed to me
jwmgregory@lemmy.dbzer0.com
on 07 Jul 12:09
collapse
is garuda like endeavorOS or manjaro where it’s technically still an arch-based rolling release distro but the OS maintainers hold packages from upstream mainline arch?
i don’t hate that model, it’s more fun to use as an end user for sure, but i feel like it kind of defeats the point of arch’s entire ethos lmao.
Is there no -bin version available for those packages?
jwmgregory@lemmy.dbzer0.com
on 07 Jul 12:35
collapse
sometimes you’re working with particular releases or builds that don’t, but like i said i might be the idiot lol.
i like the concept of arch. i don’t like the way i need to come up with a new solution for how im managing my packages virtually every few days that often requires novel information. shit, half the time you boot up an arch system if you have sufficient # of packages there is 9/10 times a conflict when trying to just update things naively. like i said it’s cool on paper and im sure once you use it as a daily driver for awhile it just becomes routine but it’s more the principle of the user experience and its design philosophy that i think might be poor.
arch is for techies in the middle of the bell curve imo… people on the left and the right, when it comes to something as simple as managing all my packages and versions, want something that just works^TM^ - unless i specifically want to fuck with the minutiae.
conflict when trying to just update things naively
Sounds like AUR problems. IMO using AUR helpers that tie AUR packages to your full system update command is a trap. AUR never professed to be a stable repository (in fact it’s the opposite). AUR has a place, but it should be used sparingly and thoughtfully.
jwmgregory@lemmy.dbzer0.com
on 08 Jul 01:16
collapse
i agree with this but this isn’t the reality of the arch ecosystem. AUR is explicitly promoted on the wiki for a large amount of tasks the average user is going to do. it feels skeevy to acknowledge the problems with the AUR and then abscond arch’s responsibility for them, because the AUR is not like PPAs or anything. it is significantly more integrated into the ecosystem.
specifically says that packages are not thoroughly vetted
does not recommend using yay or another AUR helper (which is the primary thing I recommend against)
has a frequently asked question section that is fairly technical and should indicate that it is not for the faint of heart
The aur helper wiki has a fun red disclaimer at the top that no one reads
jwmgregory@lemmy.dbzer0.com
on 08 Jul 01:39
collapse
you (rhetorical you, not you) can recommend not using the AUR officially all you want. it doesn’t mean anything if a large number of tasks the average user is going to do require AUR packages. i’m kind of drunk rn but i’ll go find specific pages of the wiki that demonstrate what i’m talking about, i stg this isn’t nothing. the core system itself can entirely be managed with pacman, yes, but the average user is going to be doing a lot more than just that. there is a certain discord in the messaging of arch as a whole.
this is exactly my point. arch can either be a nuts and bolts distro or it can be made for normies. it can’t be both.
To reiterate, I don’t think there is anything wrong with using the AUR. I think that using an AUR helper that ties updating AUR packages to your pacman -Syu is a trap that people keep falling into despite the warnings in the wiki.
All of the normal Arch packages are pre-built, so the only way you’d be compiling things that often is if you installed a large amount of things from the AUR. Make sure you get the bin versions instead of git versions.
The google-chrome and chromium packages are already a binaries so my guess is you need ungoogled-chromium-bin. You can also use the Chaotic AUR repo to get pre-built binaries of a lot of the most common AUR packages. But ideally you should avoid using the AUR when it’s not necessary.
While using the AUR is common, it’s a bit frustrating you are blaming Arch for your experience. If you only use pacman you would never compile anything, or have very many conflicts. It’s like if you added 20 different PPAs on Ubuntu and then complained about the problems that arose from that.
one of my least favorite things about arch and other rolling distros is that yay/pacman will try and recompile shit like electron/chromium from source every few days unless you give it very specific instructions not to
My understanding is that constantly triggering compiling like that shouldn’t be happening in any typical arch + pacman situation. But it can happen in AUR. If it does, I think it’s a special case where you should be squinting and figuring out what’s going on and stopping the behavior; it’s by no means philosophically endorsed as the usual case scenario for packages on arch.
There’s certainly stuff about Arch that’s Different™ but nothing about the package manager process is especially different from, say, apt-get or rpm in most cases.
jwmgregory@lemmy.dbzer0.com
on 07 Jul 18:54
collapse
saying it can happen in the AUR feels disingenuous to me when you consider how integrated the AUR is to the arch ecosystem. this is a genuine complaint from a user perspective and is an issue with the design philosophy imo. it is a special case but it’s so frequent as to be annoying, is my point.
not sure why everyone is replying like i’m unaware and totally ignoring the actual grievance i have. im very well aware of pacman and yay’s intended behaviors, i just think they’re shit in some cases. idk if people who say this have never tried to daily drive arch before or something but the AUR is absolutely not optional unless you want to constantly hand roll your own shit. see my edit to the original comment.
Feyd did a pretty good job of outlining the AUR disclaimers in a different comment so I won’t do that here. It’s true that Arch won’t stop you from shooting yourself in the foot, but again it’s nuts to claim that routine compiling is the usual case for all rolling distros and belies your claim that you’re familiar with usual case experience. There’s absolutely no routine experience where you’re regularly compiling.
I’ve used debian and apt-get most of my life, I’ve used arch on a pinetab 2 for about 6 months, regularly playing with pacman and yay and someone who’s never met me is saying I’m a fanboy for being familiar with linux package management. 🤷♂️
iit: nerds unable to comprehend that building a piece of software from source in not something every person can do
huh? Using package managers almost never involves compiling. It’s there as a capability, but the point is to distribute pre-compiled packages and skip that step in the vast majority of cases.
ICastFist@programming.dev
on 07 Jul 11:51
nextcollapse
I have used rpms, AppImages, Flatpaks, and source. I have even used a snap or two when I had no other choice.
If you can’t work with them all, can you even say you Linux Bro?
AnIntenseMoist@lemmy.world
on 07 Jul 13:01
nextcollapse
Bro, TRUTH. I have preferences but when you gotta get something done, it doesn’t matter how the app comes bundled. I’d run .exe’s through Wine if I needed to.
Diplomjodler3@lemmy.world
on 07 Jul 15:27
collapse
If you don’t compile everything from source, you may as well get a Chromebook!
never tried flatpak, snaps were so bad as to never consider non-native installs or just use docker instances when I need to run something weird. so dunno.
whats the use case for a flatpak exactly? maybe im not the target audience???
squaresinger@lemmy.world
on 07 Jul 13:00
nextcollapse
Flatpaks mean you don’t have to compile everything from scratch and solve dependency conflicts if you want a newer version of a program than what’s available in your distro’s repo, of if it’s something that doesn’t have a native version at all.
lemmyknow@lemmy.today
on 07 Jul 13:03
nextcollapse
Honestly, i’m not entirely sure what Flatpaks are all about. Not sure I could explain them. But I use them. I’ve used apt. I’ve even used Pacman and Yay in Manjaro for a few years. Now, I also Flatpak (no longer on Manjaro, though. I no longer boot to a blank screen every 6 months or so! Very nice!)
Flatpaks are basically containers, allowing applications to maintain their own dependencies separate from your system. It’s similar to a Windows program shipping with its own precompiled DLLs, helping prevent dependenct conflicts when you go to update something you installed with pacman or yay.
Flatpaks are great for situations where installing software is unnecessary complex or complicated.
I have Steam installed for some games, and since this is a 32 bits application it would install a metric shit-don of 32 bit dependencies I do not use for anything else except Steam, so I use the Flatpak version.
Or Kdenlive for video editing. Kdenlive is the only KDE software I use but when installing it, it feels like due to dependencies I also get pretty much all of the KDE desktop’s applications I do not need nor use nor want on my machine. So Flatpak it is.
And then there is software like OBS, which is known for being borderline unusable when not using the only officially supported way to use it on Linux outside of Ubuntu – which is Flatpak.
And then there is software like OBS, which is known for being borderline unusable when not using the only officially supported way to use it on Linux outside of Ubuntu – which is Flatpak.
But why is that? I mean just because it is packaged by someone else does not mean its unusable. So its not the package formats issue, but your distribution packaging it wrong. Right? In installed the Flatpak version, because they developers recommended it to me. I’m not sure why the Archlinux package should be unusable (and I don’t want to mess around with it, because I don’t know what part is unusable).
thingsiplay@beehaw.org
on 07 Jul 21:12
nextcollapse
The quoted image does not say so, they do not say the native packaging from your distribution is borderline unusable. That judgement was added by YOU. The devs just state the package on Archlinux is not officially supported, without making a judgement (at least in the quoted image).
As for the Fedora issue, that is a completely different thing. That is also Flatpak, so its not the package format itself the issue. Fedora did package the application in Flatpak their own way and presented it as the official product. That is a complete different issue! That has nothing to do with Archlinux packaging their own native format. Archlinux never said or presented it as the official package either and it does not look like the official Flatpak version.
So where does the developers say that anything that is not their official Flatpak package is “borderline unusable”?
It just doesnt work half the time. I avoid them as much as possible.
NauticalNoodle@lemmy.ml
on 07 Jul 13:29
nextcollapse
I spent my time fighting AppImages until Canonical started to force Snap on me. I hated Snap so bad it forced me to switch distros. Now I appreciate Flatpak as a result and I don’t find AppImages all that bad, either. Also, I haven’t found myself in dependency-hell nor have I crashed my distro from unofficial Repos in well over a decade.
-It’s a long way of saying It works for me and it’s not Snap.
There’s a lot to dislike about Canonical, but snaps is still relatively easy to purge and just get on with your underlying Debian package support…
Andrzej3K@hexbear.net
on 07 Jul 13:48
nextcollapse
Cursed solution to a cursed problem 🤷
The_Walkening@hexbear.net
on 07 Jul 13:59
nextcollapse
I like the idea of them because I don’t like dealing with dependencies changing and breaking stuff and I don’t really care too much about disk space in the context of non-game desktop apps, as I don’t tend to install lots of them.
That being said I absolutely hate that permissions are all over the place and flatpak doesn’t ship a GUI to manage them by default, nor do you get any indication as to what permissions a program has until you try some functionality (like filesystem or camera access) only to find out it doesn’t work out of the box.
I’ve never heard anyone say that Flatpaks could result in losing access to the terminal.
My only problem with Flatpaks are the lack of digital signature, neither from the repository nor the uploader. Other major package managers do use digital signatures, and Flatpaks should too.
buttnugget@lemmy.world
on 07 Jul 15:42
nextcollapse
I was just wondering the connection between flatpaks and the terminal because I’ve never heard of flatpaks before and Wikipedia says they’re a sandboxed package management system or something?
As someone who uses Flatpak you can still use the terminal to install, uninstall and do maintenance, not sure why people believe terminal is useless with Flatpak 😞
Flatpaks are containers, same as Snaps, I personally prefer Flatpaks over Snaps, but just my personal choice. I use Flatsweep and Flatseal apps to help administrate Flatpak apps, but use terminal as well 🙂
BeardedGingerWonder@feddit.uk
on 07 Jul 22:07
collapse
I’ve no real preference so long as my PC starts stuff. The reason I avoid flatpaks is because I have at some point acquired the habit of anything I install that’s not an appimage I pretty much launch from the terminal and I remember trying flatpaks and them having names like package.package.nameofapp-somethingelse and I can’t keep that in my head.
I’ve actually been discussing the idea of Flatpaks offering “terminal aliases”, similar to what Snaps do, with some people involved in Flatpak. It’s something that could happen in the future, but for now, you can totally create an alias to run a Flatpak from a single word, it’s just a PITA.
Nah, it’s the same as with systemd, docker, immutable distros etc. Some people just don’t appreciate the added complexity for features they don’t need/use and prefer to opt out. Then the advocates come, take not using their favorite software as a personal insult and make up straw-men to ridicule and argue against. Then the less enlightened of those opting out will get defensive and let themselves get dragged into the argument. 90% that’s the way these flame wars get started and not the other way around.
For the record, I use flatpak on all my desktops, it’s great, and all of the other mentioned things in some capacity, but I get why someone might want to not use them. Let’s not make software choice a tribalism thing please. Love thy neighbor as thyself, unless they use Windows, in which case, kill the bastard. /s
Can someone explain why flatpak isn’t necessary for distros that have proper OS dependency management like Arch-based distros or Nix?
Seems like flatpak is solving a problem for OS’s that don’t have proper dependency management.
BlameTheAntifa@lemmy.world
on 07 Jul 15:47
nextcollapse
You answered your own question. Arch and Nix solve the same problem Flatpak solves, but by using better dependency management. Flatpak’s main proposition is built-in sandboxing and convenience, but if you’re on an “expert” oriented distro like Arch (btw), you probably don’t care as much about those “freebies.”
In that case flatpak is basically a hack for OS’s with broken or improper dependency manangement systems. Either those OS’s should fix their broken systems, or ppl should move to OS’s that do it properly, as that’s one of the most important functions of your OS anyway.
frozenspinach@lemmy.ml
on 07 Jul 17:18
nextcollapse
Also pretty much everywhere you’re using flatpaks (or snaps or…), you are doing it on top of a Linux system that’s still getting its core system updates via traditional dependency management. And flatpaks, despite trying not to, make assumptions about your kernel, your glibc version, architecture, ability to access parts of your filesystem or your devices, that can break things, and doesn’t bother to track it.
And the closer you get you tracking that stuff (like Snap tries to), you hilariously just get back to where you started, with traditional dependency management that already exists and has existed for decades.
BlameTheAntifa@lemmy.world
on 07 Jul 19:14
collapse
Flatpaks make sense for atomic distros, too. It’s not always a matter of there being one right way to do things.
main selling points are isolation and having the latest version directly from developers without having to wait for your distro to package/update it.
both are debatable since they are not as good as promoted (isolation doesn’t always work correctly and it’s a mess to configure it once you use anything different than the more mainstream distros) or goes against the historical preference (using bundled everything instead of cooperating with your distro packages and trusting every individual over trusting your distro as a whole) but having the latest version on any distro without having to wait is a popular need so they gained traction quite fast. this might make little sense for rolling release distros (arch, nix) but it’s helpful if you have a stable base (years old debian) but need the latest feature on an specific application or have to use very specific libraries that are not packaged on the main distro and would require complex upgrades
I’m not a huge fan of Flatpaks, they’re a lot harder to distribute offline versus something like AppImage. Seriously, you have to like create an offline repository, then create a bundle, and it’s like 6 or 7 steps, it’s honestly kind of ridiculous lol but other than that they seem fine, and they’re easy enough to update (but so are apt packages)
I know some people may say “oh why do you need that”, but Linux has taught me that my computer is my own, and I should be able to use it the way I want to. I shouldn’t have to fight with my package manager to get it to do what I want. So I guess you could say, no I’m not really a fan of Flatpaks.
Personally, I didn’t mind Snaps, but I’m getting kind of really fed up with especially for-profit companies etc so I don’t like Snap that much now either.
Apt packages are nice, but the more of them you have installed, especially if you’re using Ubuntu-based distros and have lots of PPAs, the more annoying upgrading your distro version can be because of all the dependencies and cross-dependencies.
AppImage tends to just work for me, as long as it’s not compiled with a newer libc-bin version than the distro I’m currently using has, and I really enjoy that it’s just one file I can copy and run pretty much anywhere.
I seem to have constant issues with AppImages. Every single one I have currently won’t open. I get an error message relating to either qT or GTK. Tried searching for the error and get a bunch of old forum threads talking about either not being compatible with Wayland at all, or comments stating that the one specific AppImage in question must have been “packaged badly”. Thankfully, nothing ‘mission critical’ for me is an AppImage currently, but it is quite upsetting that I have the most problems with the supposed “just works” app packaging/distribution option.
Yes, Flatpak is overall a better approach when compared to AppImages, since being dependent on a known runtime ensures the program will run whenever the runtime is available.
What I wish they would add is a way to run the flatpak in a portable way. Because as it stands, AppImages is the only option for that. Flatpak doesn’t really allow to have a portable installation in a pendrive, for example. At the moment there’s no replacement for AppImage in such use cases, which is a pity.
But there’s no fundamental technical design roadblock in flatpak that would prevent it from supporting this in the future, imho. theoretically one could create a program that mounts the flatpak file into a ramfs layered with the runtime and run it.
Yeah that’s why I’m a bit weary of switching to Wayland, so many apps still seem unsupported, or have issues, whereas on X11 everything for me just works. Plus, the two DE’s I’d actually consider using either don’t have Wayland support at all or have very early experimental support (Cinnamon and Xfce) so it’ll still be a while for me before I am able to consider switching to Wayland, assuming everything else works.
I don’t actually know if it is a Wayland issue - most of those forum posts are like 3 years old… And I have definitely used these same AppImages in the past on Wayland without issue. I think the AppImages are expecting some specific dependency to be installed on my system that is no longer installed due to updates. (which I thought was counter to the entire point of an AppImage? I thought it was supposed to be kinda like Flatpak where it has it’s dependencies in the image? Maybe I just misunderstood AppImage…)
To give you some hope, my Distro switched to Wayland as default a little over a year ago (i think) and I have not been running into problems (outside this AppImage problem, if it is indeed a Wayland issue, which I cannot confirm or deny).
kadaverin0@lemmy.dbzer0.com
on 07 Jul 15:55
nextcollapse
I’m relatively new to Linux. I honestly don’t see what the problem is.
It destroys the beautiful and carefully cultivated ecosystem of distributed packages that has been the bedrock of Linux for decades. They’re bloated, often not quite as sandboxed as claimed, have created packaging chaos, and assume availability of system services that may not be there.
The one “good” thing about containers is that you keep your DLL-like mess localized. Just one or a few related apps run in the container and if they want / need some weird library version, they can have it without breaking other things.
Yeah but that’s a huge benefit already. I am not savvy enough in the development side to know whether that’s a reward that justifies any of the frustrations people have. Personally I don’t really mind varying methods to do any one job, as long as it’s well-documented, easily managed, and does not create a higher load on the system in any respect.
I view the delays during launch and the extra time spent during updates as a “load on the system.”
Also, it entirely depends on your deployment environment. I develop system images that go out on thousands of devices deployed in “Cybersecuity Sensitive” environments, meaning: we have to document what’s on the system and justify when anything in the SBOM (list of every software package installed on the machine) is identified as having any applicable CVEs… soooo… keeping old versions of software anywhere on the machine is a problem (significant additional documentation load) for those security audits. Don’t argue with logic, these are our customers and they have established their own procedures, so if we want their money, we will provide them with the documentation they demand, and that documentation is simplest when EVERYTHING on the system has ALL the latest patches.
The most secure systems are those that don’t do anything at all. You can’t hack a brick.
Hey, like I said, great info for me to learn because I don’t know. I was only saying that I don’t mind because my situation is fine with it. Thanks for the info, it’s interesting. I’m sure for any situation there’s a better and worse solution and I’m sure that for any solution, there’s a situation that either likes or dislikes the approach.
Yeah, I agree. Canonical seems to think “snaps are for everyone” so, for both my personal and professional applications they have decided: “Canonical is not for me.”
i mostly use them for proprietary stuff or for software that is incredible painful to package (mostly electron apps). i will probably never use them for anything that actually matters but i also use rolling release distros everywhere so latest release is never too far. for testing latest version of any software i prefer appimages since they are simpler and don’t need a messy setup as flatpak, but i also won’t use them pass the testing phase and i prefer packaging the software if possible.
snaps, on the other hand, will never go near any of my systems. not even by accident
mayako@lemmy.blahaj.zone
on 07 Jul 18:19
nextcollapse
Personally I am okay with them actually. I use several on my system and having each app allowed to have different permissions is super useful.
But also I like things that are directly installed cause they seem just a tad faster performance wise.
The thing that grinds my gears is when I’m doing an apt update and then it goes off to check on the snaps and drags the process out a lot longer. It doesn’t help that they’re slower to load the apps too. Then there’s the additional attack surfaces to accumulate more CVE reports (and more out of date library versions on your system begging for a security patch…) Mostly, I just purge snap support from Ubuntu these days - but for people who don’t notice / mind such things, you do you - maybe they’ll eventually improve the lightweight container system until the rest of us don’t notice it either.
Ohhh I’m not a huge fan of snap packages, tho to be fair I haven’t used them recently so it might just be just biases
MystValkyrie@lemmy.blahaj.zone
on 07 Jul 18:35
nextcollapse
There was a few years where I pretty much only used Flatpaks because I was scared of the terminal. But now that I’ve learned how to use the terminal, it’s so much more convenient because I can quickly update all my applications all in one place without having to open a separate app. Plus, some Flatpaks can fall really behind on software updates.
There might be a Linux userbase someday where no one other than developers actually knows how to use the terminal, because users can run everything they want without a command line, but maybe that’s actually a good thing because it’ll drive up how many people use a Linux distro.
With Windows and Mac, there’s a shareholder incentive to enshittify. With Linux, if a distro goes bad and gets commercialized, there’s always another distro people can move to, not to mention there’s no financial incentive. The more people get on Linux, the less power these tech companies have. Personally, that and privacy are what drew me to Linux much more so than being able to tinker or fine-tune my experience.
otacon239@lemmy.world
on 07 Jul 19:03
nextcollapse
There might be a Linux userbase someday where no one other than developers actually knows how to use the terminal, because users can run everything they want without a command line
Ideally, all the essential terminal commands could be replicated in a user-friendly GUI-applicable manner. Don’t ever have to remove the terminal for those that enjoy it, but if we could have a magic world where even the failure states could be navigated with little to no prior knowledge required and it gets everyone away from Windows and Mac for good, I’m all for it.
captainlezbian@lemmy.world
on 08 Jul 02:28
collapse
Yeah I just wanted off mr corporation’s wild ride
NostraDavid@programming.dev
on 07 Jul 18:35
nextcollapse
What’s a flatpak? Is that like a worse NixOS package? I prefer NixOS, BTW.
sandboxed application bundle installed from a flathub-compatible store or a local source (github etc)
LovableSidekick@lemmy.world
on 07 Jul 18:51
nextcollapse
Could things like this go in linuxmemes? Memes are fun but it would be nice to keep this a place for actual information. And no, this is not a comment on what it’s saying, I’m just tired of so many memes.
ztwhixsemhwldvka@lemmy.world
on 07 Jul 19:23
nextcollapse
I use SystemD binary Gentoo with Flatpaks. Sue me.
geneva_convenience@lemmy.ml
on 07 Jul 20:02
nextcollapse
I wouldn’t say I have had a problem with snaps or flatpacks either. I uninstall all snaps first thing when I install recent Ubuntu versions, and I have never messed with flatpacks, so… no problems.
Flatpaks aim to be a middle ground between dependency hell and “let’s pull in the universe” bloat.
Applications packaged as Flatpaks can reference runtimes to share “bases” with other applications, and then provide their own libraries if they need anything bespoke on top of that.
And they are still, in my experience, slow to load, a cumbersome addition to the update process, and often un-necessary.
Don’t get me wrong, if you’re in a tight spot and can’t make two significant software packages work in a distribution due to conflicting library version requirements… some kind of lightweight container solution is attractive, expedient, and better than just not supporting one of the packages. But, my impression is that a lot of stuff has been moved into flatpak / snap / etc. just because they can. I don’t think it’s the best, or even preferred, way to maintain software - for the desktop environment.
(Returns to checking on his Docker containers full of server apps on the R-Pi farm…)
I’m running an immutable distro at the moment (GNOME OS), and I felt no loss of performance due to Flatpaks. Snaps, on the other hand, do have a perceivably longer launch time.
Given that it’s an immutable distro, everything I need needs to be either a Flatpak, a Snap, an Appimage or an extracted tarball, otherwise it runs in a container. The advantage of this system is stability and making the host incorruptible, as well as the ability to very easily roll back updates or failed systemd-sysext layers.
Not everything can run in a Flatpak at the moment, but we’re hoping the evolution in Flatpak, XDG portals as well as encouraging developers to use the available XDG portals can make this a possibility someday. Namely, IDEs don’t run that well in a Flatpak, but GNOME Builder has proven that it’s 100% possible with the currently available XDG portals as well as connecting your IDE or editor to a container.
Ubuntu Core, based on Snaps, is very much not ready for prime time IMO. It’s kind of a mess outside of server use.
Look instead at Fedora Silverblue, Vanilla OS, and for the bleeding edge of immutable systems, GNOME OS.
KDE is about to launch their analogue to GNOME OS relatively shortly, named “Project Banana”. These two are not exactly distros as they do not distribute the kernel, they are simply platforms that layer a bunch of images together to create a stable, reproducible system. There’s also OpenSuSE Aeon, but I don’t like its style of immutability as it’s immutable by rootfs lock-out rather than immutable by image.
As for advice, learn how to use Distrobox / Toolbx containers. If you’re a developer, this is where you will be working.
Immutable Linux is still young, and a lot of software isn’t written with it in mind, so expect some growing pains.
beastlykings@sh.itjust.works
on 08 Jul 01:09
nextcollapse
Thanks. In the past I have worked in Slackware, and even had Gentoo on my home system for a couple of years, but otherwise I’ve been fully saturated in Debian and its children - so that’s my “comfort zone.” I used to like KDE, but drifted away from it when I got a 4K screen notebook and KDE hadn’t figured out resolution scaling yet, while Ubuntu/Unity had. I never quite warmed up to GNOME, but definitely have done my time with it. XFCE has matured enough for me to daily drive it without too much pain now, and I love the ways it can be de-featured (don’t want a launcher bar? Don’t run it, nothing else breaks.)
Server-side, I have been filling my Raspberry Pis with Docker containers for a while now… it’s not completely alien, but I do kind of tend to “set it and forget it” when it comes to container deployments.
Toribor@corndog.social
on 08 Jul 12:21
nextcollapse
Fast storage is one of the cheapest components of modern PCs so I’m always surprised when Flatpak file size is brought up. It’s not something I worry about very much.
SpiceDealer@lemmy.dbzer0.com
on 08 Jul 01:13
nextcollapse
It’s a neat concept. The distro-agnostic aspect is definitely a plus for some people but I still prefer distro-specific installation methods. The only time I would seek out the Flatpak version of a particular software is when it’s the only version available.
flatpaks are fine and useful, i just wish we didn’t move into a scenario where applications that used to be easily available in distro repos start moving away from them and are only available through flatpaks. distro packages are just so much more efficient in every way. flatpaks are easier on maintainers and developers but that comes at a cost to the user. i have about a dozen or less flatpak apps installed and already i have to download at least 2 gigs of updates each week. i run debian
Flatpacks a fucking insult to people with limited bandwidth.
fatur0000new@lemmy.ml
on 08 Jul 03:27
nextcollapse
I like flatpak, but I can’t download Flathub flatpak applications and (specially) Flathub flatpak runtimes from my phone. I hope Flathub learns from F-Droid
commander@lemmy.world
on 08 Jul 03:39
nextcollapse
I’m happy to use Flatpaks but the annoyances I’ve had are like when one application says to use you’ll need to point to the binary of another application that it depends on but very understandably doesn’t package together, figuring that out to me can be annoying so I’ll switch to a regular installation and it all just works together no fuss, no flatseal, no thinking about it really. Also some applications where it’s really nice to launch from the terminal especially with arguments or just like the current working directory and with Flatpaks instead of just right off the bat it’s application name and hit enter, Flatpak hope you remember the whole package name
As long as software is available in the Software Manager to be installed that way… I don’t care what format it’s in.
But don’t make normies go to the terminal. It’s inhumane, and really does not help the masses get away from big tech - which is a worthier goal than keeping your software terminal-only.
While I wouldn’t want flakpak going deep into the OS I think the advantage of using them on the desktop is obvious. Developers can release to multiple dists from a single build and end users get updates and versions immediately rather than waiting for the dist to update its packages. Plus the ability to lock the software down with sandboxes.
The tradeoff is disk consumption but it’s not really that big of a deal. Flatpaks are layered so apps can share dependencies. e.g. if the app is GNOME it can share the GNOME runtime with other apps and doesn’t need to ship with its own.
RheumatoidArthritis@mander.xyz
on 08 Jul 13:23
collapse
FTFY: Flatpaks are layered so apps can share dependencies. e.g. if the app is GNOME 4.2.11.3 it can share the GNOME 4.2.11.3 runtime with other apps and doesn’t need to ship with its own, but every app requires a different GNOME version anyway
MoondropLight@thelemmy.club
on 08 Jul 08:13
nextcollapse
Perhaps ironically, this is mocking a strawman. Flatpacks can be installed and managed using the terminal! Not only that but Linux-Distros have had graphical package managers for decades.
The primary reason that distros have embraced flatpack / snap / appimage is that they promise to lower the burden of managing software repositories. The primary reason that some users are mad is that these often don’t provide a good experience:
they are often slower to install/start/run
they have trouble integrating with the rest of the system (ignoring gtk/qt themes for example)
they take a lot more space and bandwidth
Theoretically they are also more secure… But reality of that has also been questioned. Fine grained permissions are nice, but bundling libraries makes it hard to know what outdated libraries are running on the systems.
As far as I know, I’ve only installed Flatpaks using the terminal. The most annoying thing about them for me is having to type out the fully-qualified name of the software (e.g. org.mozilla.firefox instead of just firefox), which is a very terminal-specific issue, LOL!
nullpotential@lemmy.dbzer0.com
on 08 Jul 10:28
nextcollapse
Size and gnome/GTK dependencies are main reasons why I don’t use Flatpaks (I have nothing against gnome though, it just pulls in too much and KDE is worse in this regards, which is why I use Sway and River)
Flatpak being securely sandboxed by default is both its biggest strength and its worst point of contention. The XDG is still scrambling to replicate the permission requests paradigm from Android on the Linux desktop.
beyond@linkage.ds8.zone
on 08 Jul 18:48
nextcollapse
Not a fan for a few reasons. Flathub (as far as I know) works on the app store model where developers offer their own builds to users, which is probably appealing to people coming from the Windows world who view distros as unnecessary middlemen, but in the GNU/Linux world the distro serves an important role as a sort of union of users; they make sure the software works in the distro environment, resolve breakages, and remove any anti-features placed in there by the upstream developers.
The sandboxing is annoying too, but understandable.
Despite this I will resort to a flatpak if I’m too lazy to figure out how to package something myself.
I’m a big fan of the idea of sandboxed apps. Flatpak is not great as it compromises sandboxing for compatibility (both with distros and apps) and also it’s quite stagnant now. But there are no other options anyway, so I use it.
muusemuuse@sh.itjust.works
on 08 Jul 21:40
nextcollapse
War with who? I’m posting this from Kubuntu and I’d happily agree with you that Snap should fuck off and die. (In particular, the backend being controlled by Canonical makes it objectively bad compared to Flatpak.) Even among people like me who tolerate Snap (for now…), I really don’t think you’re gonna find anybody who actually likes it, let alone enough to champion it.
Oh, hi! I also use Kubuntu, but I love Snaps! I use them for everything. I even tried to use a Snap-version of the kernel, but it completely destroyed my system so I had to reinstall… but other than that, they’re great.
limelight79@lemmy.world
on 08 Jul 21:58
nextcollapse
I “grew up” with Slackware, so I definitely understand the dependency issue.
I like flatpaks (and similar) for certain “atomic” pieces of software, like makemkv. For more “basic” software, like, say, KDE, I want it installed natively.
I use Aurora DX so most of my apps are flatpaks. Its fine.
Bronstein_Tardigrade@lemmygrad.ml
on 08 Jul 23:37
nextcollapse
Just another tool in the toolbox. Use it or not, up to the user. I’ve even seen Slackware users who say they use Flatpak to ward off dependency rabbit holes.
Don’t like it for one simple reason: no integration with the distribution. Flatpak is this sort universal solution that works, but doesn’t necessarily work hand-in-hand with the distro, unlike package managers.
threaded - newest
Flatpaks are good, especially compared to snap.
The future is atomic OS’s like silverblue, which will make heavy use of things like flatpak.
This Snap comparison is the soft bigotry of low expectations
Atomic distros are cool, and I’m sure they will only get more popular, but I don’t buy the idea that they’re “The” future. They have their place, but they can’t really completely replace traditional distros. Not every new thing needs to kill everything that came before it.
As it stands, I kinda agree. But I truly wonder to what extent we might be able to close the current gap.
Having nails driven into my testicles is better than snap. It’s not a high bar.
Haven’t had much opportunity to use snap, what’s the problem with them?
Mostly start up time for me. It just takes the programs longer to launch.
Haven’t had much opportunity to have nails driven into my testicles.
Wanna meet? /s
For me, it’s the unrenameable, unmoveable, non-hidden snap directory in my home directory’s root that doesn’t even follow the naming convention of the other directories in there.
What everyone else has already said, plus sudden updates that nuke active applications.
> plus sudden updates that nuke active applications.This is not what’s supposed to happen. If an app installed through flatpak is active while it’s receiving an update, then the update is not supposed to affect the running application until it’s closed/restarted.Edit: Somehow I didn’t realize the concern was raised against Snap and not Flatpak.
Luckily this was about Snap.
My bad. Thank you for clarifying!
We’re talking about snaps in contrast.
My bad. Thank you for clarifying!
The thread is about snap and why it’s worse than flatpak.
And also the fact that the store backend is proprietary
Snap is not all bad if you’re on a Ubuntu based distro, I just don’t like the way it’s pushed and that it comes from Ubuntu mostly. Startup time is a major issue for me also, but all in all it works.
I’m still sitting on the fence, heavily prefer flatpak but when Ubuntu is going to package nvidia drivers in a snap it’s a thing I’m up for trying.
My understanding is that if I’m on Ubuntu and the snap uses the same underlying Ubuntu version as my distro it should be fast but I haven’t seen it.
Immutable OSes are difficult to use for coding or other tasks that include installing many terminal utilities and for that reason, I don’t recommend them and certainly don’t want them to be the future of Linux distros. And if I’m going to create a container running a different distro to install and run the apps I want to use, then I may as well use that distro on my host.
You just move to user directory installation of most tools via brew on Linux. It’s not difficult. The Bazzite distro handles all this incredibly well via brew, flatpaks, and distrobox.
I would be, but the promise is just broken. Let’s say you want to do the new cool thing and run Bazzite on your console gaming PC on your TV. Now you also want to watch videos that are any normal format these days or (GASP) HEVC like you could on an XBox. You install flatpak VLC because it “just plays everything” in your experience. Your experience is ruptured for both VLC and flatpak now. Flatpaks run on system .so’s actually sometimes and installing a Flatpak doesn’t mean an app “just works” like Mac or Windows…
I get the convenience, I really do, and works on every linux distro which is a plus, but I usually stay clear of them because of the bloat. Maybe that is a misconception on my part. I should preference that with the fact I use Arch (btw)…so AUR usually has everything I need.
It doesn’t even produce convenience versus just doing AUR package install, though! Nor does it actually containerize for security well! It is bloat alone with shit user experience!
Edit: to be fair I should note that VLC in Fedora recently came into conflict with Fedora nonfree blocking all updates via some 1997-level RPM jank, idk whose fault it was, but Flatpak gets you around that so it is not without use
Edit on edit: it runs and doesn’t preclude install but current VLC does not work on Fedora out of the box with ANY nonfree codecs
FP and Electron both are brutal on limited storage, so being able to pick and choose where needed can be helpful.
?? I manage flatpaks exclusively in the terminal
.
i had a hard time getting used to them but now i love them in mint i can switch between the package version and flatpak version and usually the fp one is more updated
On the other hand each flatpak uses >1Gb of disk where deb packages rarely require more than 100Mb
See, I only use flatpaks sparingly for this reason, but in some cases they’re indispensable when you don’t want an application to access certain parts of your system. The sandboxing is what makes them useful, in my opinion. For everything else, there’s the deb packages.
That’s not really true. It lists all the flatpak dependencies in that disk use, but a lot of those are shared, so they don’t actually use that much each if you install more than one, and the deb dependencies aren’t included at all. Flatpaks really do use more space, especially if you only have a small number of them, but it’s not as bad as that.
Nope, I was counting all dependencies, both for flatpak and apk installations.
No you weren’t. That would be ridiculous. The deb dependencies are most of your Linux install. Maybe counting just the new dependencies being installed alongside a typical deb install, but that’s still not an apples to apples comparison to 100% of all the flatpak dependencies, even ones shared with other flatpaks, and even that’s still very rarely over 1GB.
That’s certainly a concern for some, but I’m using like 30 GB for all the things I’ve installed, which is a lot (12 (flatpak-system), 76 (flatpak-user)) but that’s on a 2 TB drive, which amounts to like 1½% of the total available space. I don’t think that’s a bad trade.
Compared to a pure install that can run on an electric toothbrush it’s a massive pill to swallow for some.
And not many consider the environmental impact of this either. Sure storage might be cheap (not in my country but I digress) but more space still requires more storage and across thousands of computers and then millions of computers that’s not an insignificant increase. We should be increasing technological efficiency not what were doing at the moment which seems to be just throwing more power and resources at the problems.
Lucky you. My laptop has a small HD, and all that space is a problem.
Plus I found on my install flatpak wasn’t cleaning up the flatpaks autoinstalled for older versions of nvidia drivers, they were all still listed as dependencies. Not sure who’s to blame but that was taking up a few much needed GBs.
I agree that flatpak should just invoke
flatpak uninstall --unusedright after uninstalling a flatpak. I don’t get why it doesn’t do this automatically. Granted, some distro package managers (used to) operate somewhat similarly in that they required theautoremoveoption.I actually tried
flatpak uninstall --unusedand it didn’t remove these ones. So there’s something odd going on there. My guess is maybe Mint manually installed them through the driver manager program? That’s a wild guess, I don’t know how it works.Mint took a while to handle flatpak decently in the update manager, and now it’s a nice experience.
That reminds me, is Flatpak packaging CLI tools already?
AFAIK, no
Neovim as flatpak
Helix as flatpak
Looks like it does? Or at least could?
unix.stackexchange.com/…/does-flatpak-support-com…
I’ve never seen one so far though
I’ve packaged a CLI that I made as a flatpak. It works just fine. Nothing weird was required to make it work.
The only thing is that if you want to use a CLI flatpak, you probably want to set an alias in your shell to make running it easier.
I’m not sure why more CLIs aren’t offered as flatpaks. Maybe because static linking them is so easy? I know people focus on flatpak sandboxing as a primary benefit, but I can’t help but think of static linking was easier for bigger applications, it wouldn’t be needed as much.
IDK why you’re being so rage baity. Its easy to avoid flatpaks if you dont like them. Only thing I’ve ever found as an obstacle was adding the binaries to my PATH so I can launch it with dmenu_run. Otherwise my package manager works well enough.
Bonus points: Write a PKGBUILD that installs flatpaks to /opt and symlink out binaries as needed.
Just a conversation opener, relax. Only one here shaking a fist in the air is you.
You don’t have to use a meme insulting some side to just start a conversation.
Well, I heard that people who use flatpacks are libs. True?
Sorry, I just think it’s funny that Linux users get so defensive about this stuff. You really felt insulted by this?
It was clearly trying to be insulting. I don’t understand why anyone would try to start a flamewar over flatpaks.
there’s a gui for flatpaks?
No gui’s to my knowledge, but there are package managers that can install them, such as Bauh.
KDE Discover and GNOME Software can install from FlatHub (or other Flatpak repos, if you add those).
There are merits to using flatpaks. With flatseal application, you can fine-tune the permissions given to a certain flatpak application. The best thing is restricting internet usage.
I love installing things from the CLI and prefer to only do it that way but Linux needs a single click install method for applications if it’s ever going to become a mainstream OS. The average person just wants to Google a program, hit download and install. If not that then they want to use a mobile-like App Store.
Flatpak is kind of perfect at achieving both those things
There have been GUI package managers for decades.
Oh 100% but have you tried to explain how to use one to a computer novice? Like yes, the answer is usually “they should just…” but novice users will never. With flatpak, they get an experience similar to how MacOS works and a bit like how .exes work and it Just Works™️
Edit: like I’ve had trouble showing people how to use the GNOME App Store which could not be any more simple. Anyone who has been convinced to install Linux already feels way out of their element so making everything feel as natural as possible is essential (and I mean, flatpaks are awesome anyway)
Wait how do you install flatpaks? I add the remote (if necessary) and then install it from there. That is nothing like I have ever seen on Windows (though apparently there are package managers).
I think he’s referencing the flathub install button where you can just hit install.
That just displays the command or is there a browser extension that runs it for you too? Most Windows apps certainly don’t run by just clicking a button either.
It’s a flatpak://url that opens the app store on the computer where you do a one click install. So technically it’s two clicks.
Ah, I don’t have an app store. That would explain why I have never seen it.
.
OpenSUSE has OneClick install for RPMs. en.opensuse.org/openSUSE:One_Click_Install
<img alt="" src="https://lemmy.ca/pictrs/image/46ba70d5-c9aa-4dfb-8847-e63a07678f2f.jpeg">
Edit: and if you happen to download an rpm, you just double click it in the filemanager (or single click if that is your setting) and it launces the install GUI.
Its similar to how MSI file install looks…just next next finish kind of thing
For sure and I agree that should be enough but the average person is not good with computers and they don’t want to learn. They won’t understand the nuances of different distributions of Linux. Like try explaining the difference between a .deb, a .tar.gz, and a .rpm to a person who’s already hésitent about using Linux. Flatpak solves that by just having one download that any Linux install can use
Those mystical average people would probably stay on Windows, if they don’t care or cannot learn basics of other systems. Its really not hard to explain and understand, even for “average person” that there is an universal source for applications and there are packages designed and managed by your operating system. I think its important for people to learn basics and we should teach them, not dumb them down like on Windows. Soon people won’t be able to eat themselves anymore…
Appimage
Ah, that’s actually what I was thinking of in my previous comment
Just go to the package manager, type in the name of the program, install.
That’s easier than on windows: go to the browser, search for the program, avoid the ads, search for the download button, follow the install wizard, avoid the toolbar
Former OS security here (I worked at an OS vendor who sold an OS or two and my job involved keeping it secure).
Fuck no.
Sorry if that makes you downvote, but it doesn’t make them safer.
cool, thanks
Would you mind elaborating?
A few reasons security people can have to hesitate on Flatpak:
By a typical home user’s perspective this probably seems like nothing; in terms of security you’re still usually better off with Flatpak than installing random AUR packages, adding random PPA repos, using AppImage programs, installing a bunch of Steam games, blindly building an unfamiliar project you cloned from github, or running bash scripts you find online. But in many contexts none of that is acceptable.
I thought flatpaks were created to make packaging easier, not to solve all security issues. Still sounds like a win to me.
I mean, they added “bash scripts you find online”, which are only a problem if you don’t look them over or cannot understand them first… Their post is very much cemented in the paranoid camp of security.
Not that they’re wrong. That’s the big thing about security once you go deep enough: the computer has to work for someone, and being able to execute much at all opens up some avenues of abuse. Like securing a web based service. It has to work for someone, so of course everything is still vulnerable at some point. Usually when private keys or passwords are compromised if they’re doing things remotely correctly, but they’re still technically vulnerable at some point.
The parent comment mentions working on security for a paid OS, so looking at the perspective of something like the users of RHEL and SUSE: supply chain “paranoia” absolutely does matter a lot to enterprise users, many of which are bound by contract to specific security standards (especially when governments are involved). I noted that concerns at that level are rather meaningless to home users.
On a personal system, people generally do whatever they need to in order to get the software they want. Those things I listed are very common options for installing software outside of your distro’s repos, and all of them offer less inherent vetting than Flathub while also tampering with your system more substantially. Though most of them at least use system libraries.
I would honestly expect that the vast majority of people who see installation steps including
curl […] | sh(so common that even reputable projects like cargo/rust recommend it) simply run the command as-is without checking the downloaded script, and likewise do the same even if it’ssudo sh. That can still be more or less fine if you trust the vendor/host, its SSL certificate, and your ability to type/copy the domain without error. Even if you look at the script, that might not get you far if it happens to be a self-extracting one unless you also check its payload.Yea, that’s why I added the, “not that they’re wrong…” part. Interesting how no one actually understands what those simple words mean.
They always seem to have some critical limitation. Handbrake is too slow via flatpak to work. Flatpak Zoom had no camera access. Flatpak-only Zen browser can’t use passkeys. Zen browser asks to be my default browser every time I open it, even though it is and I always say yes; is this a flatpak limitation? I don’t know, and I’d prefer not to have to figure it out just for some theoretical benefits and more overhead.
I used Flatpak Zoom for all my job interviews recently. Camera and mic worked flawlessly.
Well that’s frustrating. I may need to check that again.
Same
Flatpak Zen Browser is never asking me to be the default. Maybe it did in the beginning but I don’t remember.
Flatpak Firefox does that for me
Maybe you checked “stop asking”?
Probably but I think if the original comment wanted the message to disappear they would also have done that.
No, I wouldn’t. It’s how I can tell if the setting actually took!
Is there no other way on your system to see what the default browser is? On Gnome you can see a few of your default applications in the settings. And what happens if you open an html file for example? Does it open in Zen? If yes then it appears that Zen is set as your default browser, what more is there to check?
Functionally, it’s the default because links do open in it, but why isn’t it able to tell that it’s already set?
I used them for some things, but other things still don’t work quite right. Take Steam for example. I do love flatpaks for testing out apps, things with really finicky dependencies, or pinning a specific version of a software that I want to continue to work in the future. However, for most things, Arch + AUR just covers all my needs without any hiccups.
To me flatpaks are sort of like NixOS. All the benefits they provide aren’t something I need on a daily basis. Rolling back works just fine 99% of the time with
downgrade. I already have system backups. Despite what some articles might insist, things don’t just break all the time. I’m not running untrusted software.Basically no solution is perfect, but they don’t need to be. If the benefits I gain can be recreated through other methods without the tradeoffs they introduce, then I will go with that. Of course, that isn’t to say they don’t have their place, but sometimes I feel like some people think that “being designed from the ground up” to handle certain use cases is always better than whatever “cobbled together” thing we currently have and that isn’t always the case. I’m specifically quoting those two phrases because these are the exact phrases you will hear projects using to justify their existence. In fact, I would go so far as to say that some people have outright confused modularity for “cobbled together”.
One last example I want to make is that I make use of projects like the fish shell and helix editor. In these cases, I find the features they introduce to be worth the tradeoffs and work better because of being designed “from the ground up” to do what they do. However, I don’t make use of immutable systems, containers such as docker, or say filesystems such as btrfs. The features they provide are not useful enough to me compared to the problems they introduce.
Flatpak have their own set of issues. One thing is, that Flatpak applications do not integrate that easily and perfect like a native package. Either rights are to given, you need to know what rights are needed and how to set it up. Theming can be an issue, because it uses its own libraries in the Flatpak eco system instead your current distributions theme and desktop environment.
But on the other hand, they have actually a permission system and are a little bit sandbox compared to normal applications. Packages often are distributed quickly and are up to date directly from the developers, and usually are not installed with root rights.
I’m pretty much a CLI guy as well and prefer native packages (Arch based, plus the AUR). But I also use Flatpaks for various reasons, alongside with AppImages.
my issue with all of these gui tools ut never forces you to learn the cli to fix things just use guis
I like the sandboxing of Flatpak, but I prefer AppImage as I don't like having the Flatpak runtime requirement.
Don’t AppImages also have a similar requirement just with stuff that is already installed on many popular distros so many people just don’t notice it? I think I read somewhere that running AppImages on systems that even slightly differ from the big popular distros is a pain since you still have to ship this stuff with them but it is more cumbersome than with flatpaks.
That is technically true with things like glibc, but I've never seen a system that did not already include baseline packages.
It’s not my fault they make running apps from the cli so irritating. Broken by design. Even snaps work better.
Write name of program
Enter
i like it. they are very convenient, work every time, and solves the distribution problem.
Flatpaks together with “immutable” distributions, Wayland and systemd are a heresy, a crime against the UNIX principles, a disgrace in the eyes of of SED and AWK. REPENT! Save your immortal core dumps and return to the one true /home !
theyre whatever, they have their place in my system, but inprefer installing debs from the repo
If it’s a mostly self-contained app, like a game or a utility, then Flatpak is just fine. If a Flatpak needs to interact with other apps on the host or, worst case, another Flatpak it gets tricky or even impossible. From what I’ve seen though, AppImage and Snap are even worse at this.
Flatpak doesn’t support dev device access no matter what I use flatseal and all the shabang, so bottles is useless to me for a lot of the wine applications I would like to “not emulate”
I’d take a well-maintained native package for my distro over a Flatpak, but sometimes, a Flatpak is just the the easiest way to get the latest version of an application working on Debian without too much tinkering - not always no tinkering, but better than nothing.
This is especially true of GIMP - Flatpak GIMP + Resynthesizer feels like the easiest way to experience GIMP these days. Same with OBS - although I have to weather the Flatpak directory structure, plugins otherwise feel easier to get working than the native package. The bundled runtimes are somewhat annoying, but I’m also not exactly hurting for storage at the moment - I could probaby do to put more of my 2 TB main SSD to use.
I usually just manage Flatpaks from the terminal, though I often have to refresh myself on application URLs. I somewhat wish one could set nicknames so they need not remember the full name.
I prefer Arch Linux’s use of flatpaks, which is none at all ever
Me pretty much only ever using arch Linux: “what the fuck is a flatpak”
I once had to install Firefox into wsl (Ubuntu) and I wanted the kms on the spot.
But maybe it’s not that bad for newer people to get started with Linux.
Joke’s on you, I use Flatpaks on Arch
Why, it’s totally unnecessary.
i have a couple on arch also, mostly because of dependency issues breaking the program and it being a pain in the ass to fix
Which ones? Everything in the arch main repos are compiled for your system, and most things in the AUR can either be built from source, or have -bin installs.
aleph one from the AUR refused to run properly, often crashing on startup so i just grabbed the flatpak
the weirdest one was ghostwriter from the official repos, for some reason one day the preview window showed heavily corrupted output and tinkering with it on and off for a week did nothing, including a complete purge and reinstall of the program
the flatpak was the only version of it that worked after that
Mostly because of detailed and easy permissions, and also because I have other distibutions on my other computers and want my programs to be consistent everywhere - same programs, same version.
When I open my task manager I see flatpak-session-helper near the top of the list for ram usage and am suspicious
My favorite part of the linux experience is the FREEDOM, but also being talked down to for not using my freedom correctly, I should only do things a specific way or I might as well just use windows.
You don’t have to do as they say but doing so lets you talk down to others who aren’t. So it’s a fair trade.
Because using your freedom to promote options that restrict freedom means helping to remove your freedom. But hey, what do the Linux elders know? Clearly the new people into Linux are far smarter…
It’s extremely context-dependent.
If we’re talking about enterprise-grade, five-nines reliability: I want the absolute simplest, bare-bones, stripped down, optimized infra I can get my hands on.
If we’re talking about my homelab or whatever else non-critical system: I’m gonna fuck around and play with whatever I feel like.
You are mixing different ideas of freedom. Software freedom is not the same as freedom of choice of software.
You don’t need Linux to have choices of what software to use, you have that in most (all?) proprietary systems, in some you might even have more choices than in Linux… even if it includes proprietary software.
This is analogous to how being a free person (not a slave) is not the same as having freedom to choose who to work for, even if some of them are slavers (ie. having freedom to choose your master).
Flatpaks are pretty great for getting the latest software without having to have a cutting edge rolling release distro or installing special repos and making sure stuff doesn’t break down the line.
I use Flatpaks for my software that I need the latest and greatest version of, and my distros native package for CLI apps and older software that I don’t care about being super up to date.
My updater script handles all of it in one action anyways, so no biggie on that either.
Flatpaks are the best all-in-one solution when compared to Appimages or Snaps imo.
Oh, that explains why they’re completely bloated & useless to me. Arch btw
I don’t like how so many distros ship with discover configured to install flatpaks by default. It’s a huge newbie trap when you click “open file” and uh where are all my files?? You should only install a flatpak if the program is not available for your OS, or if the native version doesn’t work for some reason.
Not a fan. There’s often trouble, and some settings is hassle, and sometimes not even working.
I’m starting to think that in terms of features and possiblities, nix might truly be the best third party package manager of all. But the downside is that especially when using it the way it’s recommended, combined with home manager, it has the steepest learning curve. Also graphical apps can be problematic. There is a tool called nixgl that tries to solve this, but it’s a wrapper, so when a nix application opens a child process that needs to use the native system drivers, that childprocess is also wrapped in nixgl and it breaks. I recently found a neat workaround on github to solve this in a better way, which is to create a driver package manually with home manager, and symlink it to /run/, which is also where the drivers are linked on NixOS. This is a gamechanger to me because with no driver problems anymore, you can install almost everything through nix on pretty much any distro, except maybe for some programs that need system level access to run. You can install graphical programs, cli programs, and even entire window managers with it. I’m using full NixOS at the moment, but i’m seriously debating moving back to void linux with nix on top. Currently messing with it in a vm to test my configs.
I kinda like flatpaks being an option, not sure when they are the only option though.
I like them as an option, there are some programs like Bottles or specific game launchers that work under flatpak better than the versions available via native package manager (with Bottles in particular, you can use various built-in sandbox features via flatpak which makes things a bit more secure), but it’s also a bit of a pain because it’s an additional package manager you have to update separately now, or tweak if things go wrong.
Certainly a fan, and I don’t understand the hate towards it.
Flatpaks are my preferred way of installing Linux apps, unless it is a system package, or something that genuinely requires extensive permissions like a VPN client, or something many other apps depend on like Wine.
The commonly cited issues with Flatpaks are:
What you gain for it? Everything.
Alternatives?
AppImages don’t need an installation, so they are nice to see what the program is about. But for other uses, they are garbage-tier. Somehow they manage both not to integrate with the system and not be sandboxed, you need manual intervention or additional tools to at least update them/add to application menu, and ultimately, they depend on one file somewhere. This is extremely unreliable and one should likely never use AppImages for anything but “use and delete”.
Snaps…aside from all the controversy about Snap Store being proprietary and Ubuntu shoving snaps down people’s throats, they were just never originally developed with desktop applications in mind. As a result, Snaps are commonly so much slower and bulkier that it actually starts getting very noticeable. Permissions are also way less detailed, meaning you can’t set apps up with minimum permissions for your use case.
This all leaves us with one King:
And it is Flatpak.
Flatpaks, appimages, snaps, etc: why download dependencies once when you can download them every time and bloat your system? Also, heaving to list installed flatpaks and run them is dumb too, why aren’t they proper executables? “flatpak run com.thisIsDumb.fuckinEh” instead of just ./fuckinEh
No thanks. I’ll stick to repos and manually compiling software before I seek out a flatpak or the like.
This shit is why hobbies and things should be gatekept. Just look at how shit PC design is these days. Now they’re coming after the OS.
As I said, dependencies typically don’t take that much space. We’re not in the '80s, I can spare some megabytes to ensure my system runs smoothly and is managed well.
As per naming, I agree, but barely anyone uses command line to install Flatpaks, as they are primarily meant for desktop use. In GUI, Flatpaks are shown as any other package, and all it takes is to push “Install” button.
If you want to enjoy your chad geeky Linux, you still can. Go for CachyOS, or anything more obscure, never to use Flatpaks again. At the same time, let others use what is good and convenient to them.
And then it turns out that you have 18 libssl libraries in diffirent fpatpacks, and half of them contain a critical vulnerability that any website on the Internet can use to hack your PC. How much do you trust the limitations of flatpack apps? are you sure that a random hacker won’t hack your OBS web plugin and encrypt your entire fpatpack partition (which some “very smart” distributions even stuff office into, and your work files will be hidden there). People have come up with external dependencies for a reason.
Fair criticism!
However, the extent of the damage is limited by flatpak and whatever permissions you have set, and, if I understand it correctly, you cannot attack one flatpak through the other unless they share access to some files.
Also, I haven’t seen this kind of attack in the wild (maybe I’m not informed enough?) as opposed to rogue maintainers injecting malware into packages.
On an unrelated note: apparently, there is finally some Russian Lemmy instance? That’s a welcome change.
there is a problem here that permissions are also set by the packages developers. User in most cases click accept all and alll done.
Well… Appeared 2 years ago. It’s just that practically no one needs it. =)
True, and I don’t think it is healthy not to let them to. But it would be nice to either have some vetting on the matter, or ask user about which permissions they agree for when they install Flatpak.
Ого, то есть примерно когда я сам здесь очутился. Никогда не слышал о ру инстансах, хоть и искал. Теперь, кажется, нашёл)
Берёте человечка на борт? Не обещаю сделать Рекабу главным инстансом, но всегда полезно быть по обе стороны Чебурнета, а то последнее время с забугорными беды бывают.
Do all laptops users have this option? Also you keep saying megabytes when it’s never just a few megabytes. It downloads atleast a few gbs worth of data just for one gui app.
Not true lmfao
Please clarify, what option do you mean? Flatpaks are supported on any Linux system, it doesn’t matter what distro or hardware. Or if you mean sparing some megabytes - typically yes as well. The smallest amount of memory I’ve seen on a laptop is 32gb, and typically it’s no less than 250gb.
If it’s not present in you distributions’ app store, you can either enable it somewhere or download another app manager like Discover, GNOME Software, or pamac if you’re on Arch.
If installation of some app incurs a few gbs of downloads, it is likely that your system updates packages alongside installing your app. Typical Flatpak app takes 10-150 megabytes.
Every gb matters on a 250gb laptop lol
Gigabyte - sure, but it’s not typical for a flatpak to bring so many heavy dependencies.
I’ve been working on Linux for 15 years now and I perfectly remember the origin of many concepts. If you look at it through time, what would it be like:
Well, all I can say about this is just assemble a single binary for all applications, stop doing nonsense with a flatpack/snap/etc.
UPD: or if you really want to break all the conventions, just use nixos. You don’t need snap/flatpack/etc.
I don’t mind other solutions, as long as they have the key features Flatpak offers, namely:
Times are changing, and memory constraints for most programs are generally not relevant anymore.
But there are gaps in the libraries that, unlike distributions with dependencies, can no longer be managed. And all the security of your system depends on a small flatpack access control, which 99% of users do not understand at all and, with any problems simply opens access to the entire home directory.
I’m not saying Flatpak is perfect, but it appears to be the best we have.
I absolutely agree more needs to be done to explain permissions and have sane defaults. Flatseal in particular could introduce more warnings, and this is where non-technical users set their permissions.
In my experience, most Flatpaks do not request full home folder access by default, and making Flatpak access everything everywhere typically requires user intervention.
Native apps, meanwhile, just run with full system-wide access; I get it that they’re more vetted and more properly updated, but this is an unhealthy and insecure arrangement.
this is a system for work tasks. Of course, I understand what the developers are going for. that is Android. And it’s really nice to read the Internet on android. But try to do something more complicated than that and you’ll realize that it’s hell. However, I don’t mind if such distributions appear. Why not? I just don’t understand people who voluntarily limit their abilities. And why you don’t just install Android 64?
The flatpack approach automatically remove everything low-level from the equation. Do you want to write directly to the graphics card buffer? Read the input? Do I set the fan rotation parameters directly in the /proc? All these applications will never work in flat pack.
On the other hand, flatpack is superfluous and for convenience. You can simply build an executable file without dependencies and configure firejail for it yourself… That’s all. Or run the file from another user. That is so popular exactly bacause RedHat pushed them. Literaly like Canonical pushed snap.
They don’t have to! Flatpak doesn’t remove all other ways to install software. But for 95% of use cases, it will do just fine.
Firejail is good, but it only solves sandboxing part of the equation, and there’s so much more to Flatpaks than that. Also, it’s more painful to configure and is more sysadmin-oriented.
Tell this to canonical, they even firefox put in the snap. You know that when choosing “quickly compile something for a flatpack” and “support 10+ distributions”, the developers will choose a flatpack. Which in general looks fine, until you realize that everything is just scored on the mainline of libraries and molded on anything. The most striking example of this is Linphone. just try to compile it…
Snap is cancer, and what Canonical does is insane.
In any case, it is unlikely someone will make an exclusive Flatpak for what doesn’t work inside Flatpak. But I understand it means a lot for user choice and ability to compile programs they way you want, so I fully support shipping Flatpaks alongside classical packages and source code.
Flatpak is not single binary, Flatpaks have shared runtime (For example Freedesktop, GNOME, KDE runtimes)
Provided that flatpack has a common parent container, which is not always the case. More precisely, it almost never does. Because someone updates flatpack to new versions of the parent containers, and someone else does not.
I don’t know any flatpak in my system that don’t use runtime (I have around 50 flatpak apps installed), or am I misunderstanding your point
runtime have versions too. If one runtime version use only one flatpack than exactly same as just static linking binary. Flatpack have just docker layeredfs and firejail in base.
id: org.gnome.Dictionary runtime: org.gnome.Platform runtime-version: ‘45’ <- here sdk: org.gnome.Sdk command: gnome-dictionaryI see problem in that only in unmaintained apps (like org.gnome.Dictionary), I have only GNOME 47 & 48 for example and both of them still updating
In the initial stage of shared library support, everything was exactly the same. Let’s look at it in 5 years… When some soft will archived and die, some stop maintaining, some new crated and brakes old dependencies…
for some reason, i have both gnome platform 46 and gnome platform 47 installed in my system. that’s probably it
Old guy here too, used un*x before linux existed in the 90s. I still use a Debian based distro (MX) without systemd and no snap/flatpak/whatever. Just build/compile or install .deb and dependencies. Lastly unfortunately I had to install a flatpak to test “deskflow”, the first time I installed one, I feel dirty now :-(
The few things I don’t like about flatpaks (which become a problem on atomic distros that use almost all flatpak by design):
Some types of embedded development is essentially impossible with flatpaks. Try getting the J-link software connected with nrftools and then everything linked to VScodium/codeoss
Digital signing simply doesn’t work, won’t work for the foreseeable future, and is not planned to get working,
Flatpaks sometimes have bugs for no reasons when their package-manager counterparts don’t (e.g. in KiCAD 8.0, the upper 20% or so of dialog boxes were unclickable with the mouse, but I could select and modify them with the keyboard, only the flatpak version)
The status on whether it is still being actively developed or not (at least I hear a fair amount of drama surrounding it)
But besides those small things, it seem great to me.
Thanks for the input! Yes, there are still certain issues with Flatpaks (for me it was aforementioned VPNs which also don’t work through Distrobox, and it would be quite odd anyway). But overall, they manage most apps well, just as you say.
Changed my mind. Thanks.
Well a 10mb app could take 20 but what about a 1gb one?
It would take 1,01gb
Dependencies typically take 5-80 megabytes of space.
That’s just not true. I used to use flatpak and it would download nvidia drivers for each one.
Huh?
Either it did something it shouldn’t, or the system updated Nvidia drivers every time for no apparent reason. I have an Nvidia GPU, running proprietary drivers, and haven’t ever witnessed anything of the kind.
Gimp is a gigabyte larger as a flatpak
Wow that’s actually big difference, thanks for bringing it up!
Good news, though, is that you are free to install Gimp as a native package, and use Flatpaks for the rest.
That’s made up, GIMP is like 90MB you can see it listed on the website and confirm it by installing it: flathub.org/apps/org.gimp.GIMP
Idk how, but one time I tried installing something as a flatpak and it took like 300+MB and a very long time. I figured something was wrong, found a way to install it normally and it took like 10MB and installed quickly. Idk what went wrong, but I’ll never touch this garbage again
Edit: oh they’re not for arch. Maybe they should have told me before the 300mb slog
If i got it right, flatpacks gather all of the dependencies of the package and bundles them with tha package. Maybe those extra 290mb were from dependencies that you already had installed but that flatpak wanted to install another copy.
I wonder why they don’t just stuff them inside, like an appimage, so I can see the size when I download the program
Honestly, I am a little scarred from snap.
Otherwise I’m agnostic on flatpaks - I’ve used a couple and they’re ok? They just remind me of old windows games that dump all their libraries in a folder with them.
On a modern system the extra space and loss of optimisation is ok, but on older hardware or when you’re really trying to push your system to run something it technically shouldn’t, I can see it being an issue.
I’ve heard Flatpaks aren’t great at CLI tools, is that true ?
As a Nix user, I’m glad Flatpaks exist for other people, but I only ever use them when a package is not available from Nix directly. Seeing as Nix is literally the biggest package manager out there, it’s a pretty rare occurrence.
Yes it is true. Flatpak is for gui apps only, at least as far as I know.
I posted this in another thread, but reposting here because a lot of people, including myself up until very recently, were under that impression:
I’ve packaged a CLI that I made as a flatpak. It works just fine. Nothing weird was required to make it work.
The only thing is that if you want to use a CLI flatpak, you probably want to set an alias in your shell to make running it easier.
I’m not sure why more CLIs aren’t offered as flatpaks. Maybe because static linking them is so easy? I know people focus on flatpak sandboxing as a primary benefit, but I can’t help but think that if static linking was easier for bigger applications, it wouldn’t be needed as much.
Most of us refugees just want windows but cool.
About the image: The joke’s on you, I install my flatpaks via the terminal.
I’ve started using flatpaks more after starting using Bazzite and I liked them more than I expected. As a dev, I still need my work tools to be native, but most of my other needs are well covered by flatpaks.
Tip: Flatseal is a great config manager for flatpaks’ permissions.
I installed flatseal but I never understand what is essential and what is not.
It is mostly trial and error. I use it mostly to set envvars.
As an example, I add the ~/.themes folder and the GTK_THEME to allow some apps to get the themes I downloaded.
Oh, so flatpaks cannot automatically get system themes?
If it is trial and error, is it really useful for a normal user?
System themes, probably most of them work. But most of them don’t bother watching the user themes or icons folder.
I don’t think Flatseal is that useful for the majority of users, no. But it is a good tool to have in mind when the need arises.
Why do you think it is not useful?
I replaced Firefox system package with Flatpak because I think browser is the most used and vulnerable thing in my system. And the size seemed reasonable.
I did not replace Thunderbird because its size is almost 10 times.
The person you’re replying to is talking about the permissions manager flatseal, not flatpaks
Oops. I got confused
Installing flatpaks via the terminal is so much faster for some reason, so I always do it that way.
My guess was the point is that it’s difficult to install CLI tools using Flatpak
Installing them is not difficult. It’s the same as any other flatpak.
The problem is when running them (actually, when running any flatpak, not just CLI tools) you need to type out the whole backwards domain thingy that flatpaks use as identifier, instead of having a proper typical and simple executable name like they would have if they were installed normally.
I end up adding either symlinks or aliases for all my flatpaks because of this reason. After doing that it’s ok… but it’s just an extra step that’s annoying and that the flatpak devs have no interest on fixing apparently.
I am definitely a fan. A lot of people say that flatpaks are bad because of sandboxing but I haven’t seemed to have any issues with it.
Although I do try to use dnf when a dnf package is available (I use fedora)
iit: nerds unable to comprehend that building a piece of software from source in not something every person can do.
EDIT: or doesn’t want to do
one of my least favorite things about arch and other rolling distros is that yay/pacman will try and recompile shit like electron/chromium from source every few days unless you give it very specific instructions not to - which is annoying as shit bc compiling the entirety of chrome from source takes hours even with decent hardware.
granted, i fucking hate google products too but if you’re doing any web dev it’s necessary sometimes.
idk im definitely willing to admit i might be the idiot here. managing your packages with pacman might just be routine to some people. to me arch is the epitome of classic bad UX in an open source project. it’s like they got too focused on being cmatrix-style terminal nerds and forgot to make their software efficiently useable outside of 5 very specific people’s workflows. it’s not even the terminal usage that is bad about arch. plenty of things are focused on that and… don’t do it shittily? idk…
edit: yes to all the arch fanboy’s points in response to me. i used to be super into arch and am aware of the fact that this isn’t explicit behavior but to act like it doesn’t happen in a typical arch user experience is disingenuous. i also disagree with the take that arch doesn’t endorse this outright with its design philosophy, bc it does. the comparison of the AUR to other, similar things like PPAs doesn’t land for me bc PPAs aren’t integrated into the ecosystem nearly as much as AUR is with arch. you can’t tell people to just grab the binaries or not use AUR whenever it’s convenient to blame the user, when arch explicitly endorses a philosophy amicable to self-compilation and also heavily uses the AUR even in their own arch-wiki tutorials for fairly basic use cases. arch wants to have its cake and eat it too and be a great DIY build it yourself toolkit while also catering to daily driver use and more generalist users. don’t get me wrong, it’s the best attempt at such a thing i’ve seen - but at a certain point you have to ask if the premise makes sense anymore. in the case of arch, it doesn’t and it causes several facets of the ecosystem to flounder from a user perspective. the arch community’s habit of shouting “skill issue” at people when they point out legitimate issues with the design philosophy bugs the fuck out of me. this whole OS is a camel.
I get that with NixOS even if I use a tablet as my release. It’s pretty annoying if it is too new and not cached yet.
I’ve been on Garuda for 4 years or so, not once has this happenoed to me
is garuda like endeavorOS or manjaro where it’s technically still an arch-based rolling release distro but the OS maintainers hold packages from upstream mainline arch?
i don’t hate that model, it’s more fun to use as an end user for sure, but i feel like it kind of defeats the point of arch’s entire ethos lmao.
Is there no -bin version available for those packages?
sometimes you’re working with particular releases or builds that don’t, but like i said i might be the idiot lol.
i like the concept of arch. i don’t like the way i need to come up with a new solution for how im managing my packages virtually every few days that often requires novel information. shit, half the time you boot up an arch system if you have sufficient # of packages there is 9/10 times a conflict when trying to just update things naively. like i said it’s cool on paper and im sure once you use it as a daily driver for awhile it just becomes routine but it’s more the principle of the user experience and its design philosophy that i think might be poor.
arch is for techies in the middle of the bell curve imo… people on the left and the right, when it comes to something as simple as managing all my packages and versions, want something that just works^TM^ - unless i specifically want to fuck with the minutiae.
Sounds like AUR problems. IMO using AUR helpers that tie AUR packages to your full system update command is a trap. AUR never professed to be a stable repository (in fact it’s the opposite). AUR has a place, but it should be used sparingly and thoughtfully.
i agree with this but this isn’t the reality of the arch ecosystem. AUR is explicitly promoted on the wiki for a large amount of tasks the average user is going to do. it feels skeevy to acknowledge the problems with the AUR and then abscond arch’s responsibility for them, because the AUR is not like PPAs or anything. it is significantly more integrated into the ecosystem.
The wiki article :
The aur helper wiki has a fun red disclaimer at the top that no one reads
you (rhetorical you, not you) can recommend not using the AUR officially all you want. it doesn’t mean anything if a large number of tasks the average user is going to do require AUR packages. i’m kind of drunk rn but i’ll go find specific pages of the wiki that demonstrate what i’m talking about, i stg this isn’t nothing. the core system itself can entirely be managed with pacman, yes, but the average user is going to be doing a lot more than just that. there is a certain discord in the messaging of arch as a whole.
this is exactly my point. arch can either be a nuts and bolts distro or it can be made for normies. it can’t be both.
To reiterate, I don’t think there is anything wrong with using the AUR. I think that using an AUR helper that ties updating AUR packages to your pacman -Syu is a trap that people keep falling into despite the warnings in the wiki.
You keep saying this but can you give any concrete examples? I don’t recall coming across anything like this.
All of the normal Arch packages are pre-built, so the only way you’d be compiling things that often is if you installed a large amount of things from the AUR. Make sure you get the bin versions instead of git versions.
The
google-chromeandchromiumpackages are already a binaries so my guess is you needungoogled-chromium-bin. You can also use the Chaotic AUR repo to get pre-built binaries of a lot of the most common AUR packages. But ideally you should avoid using the AUR when it’s not necessary.While using the AUR is common, it’s a bit frustrating you are blaming Arch for your experience. If you only use pacman you would never compile anything, or have very many conflicts. It’s like if you added 20 different PPAs on Ubuntu and then complained about the problems that arose from that.
My understanding is that constantly triggering compiling like that shouldn’t be happening in any typical arch + pacman situation. But it can happen in AUR. If it does, I think it’s a special case where you should be squinting and figuring out what’s going on and stopping the behavior; it’s by no means philosophically endorsed as the usual case scenario for packages on arch.
There’s certainly stuff about Arch that’s Different™ but nothing about the package manager process is especially different from, say, apt-get or rpm in most cases.
.
saying it can happen in the AUR feels disingenuous to me when you consider how integrated the AUR is to the arch ecosystem. this is a genuine complaint from a user perspective and is an issue with the design philosophy imo. it is a special case but it’s so frequent as to be annoying, is my point.
not sure why everyone is replying like i’m unaware and totally ignoring the actual grievance i have. im very well aware of pacman and yay’s intended behaviors, i just think they’re shit in some cases. idk if people who say this have never tried to daily drive arch before or something but the AUR is absolutely not optional unless you want to constantly hand roll your own shit. see my edit to the original comment.
Feyd did a pretty good job of outlining the AUR disclaimers in a different comment so I won’t do that here. It’s true that Arch won’t stop you from shooting yourself in the foot, but again it’s nuts to claim that routine compiling is the usual case for all rolling distros and belies your claim that you’re familiar with usual case experience. There’s absolutely no routine experience where you’re regularly compiling.
I’ve used debian and apt-get most of my life, I’ve used arch on a pinetab 2 for about 6 months, regularly playing with pacman and yay and someone who’s never met me is saying I’m a fanboy for being familiar with linux package management. 🤷♂️
Learn
huh? Using package managers almost never involves compiling. It’s there as a capability, but the point is to distribute pre-compiled packages and skip that step in the vast majority of cases.
Speaking of terminal emulators! - arcan-fe.com/…/sunsetting-cursed-terminal-emulati…
I have used rpms, AppImages, Flatpaks, and source. I have even used a snap or two when I had no other choice.
If you can’t work with them all, can you even say you Linux Bro?
Bro, TRUTH. I have preferences but when you gotta get something done, it doesn’t matter how the app comes bundled. I’d run .exe’s through Wine if I needed to.
If you don’t compile everything from source, you may as well get a Chromebook!
Never, ever, ever do more effort than is required.
Flatpaks suck
Ubuntu has turned to dogshit
i agree ubuntu is corpo drivel now but flatpaks are actually quite useful for some applications.
the sandboxing is nice to not have to setup manually for every little thing, and i say that as someone who avoids flatpaks generally.
sometimes you just wanna get things up and running, not everything needs to be a unix circlejerk.
Ubuntu is using Snaps though…
never tried flatpak, snaps were so bad as to never consider non-native installs or just use docker instances when I need to run something weird. so dunno.
whats the use case for a flatpak exactly? maybe im not the target audience???
Flatpaks mean you don’t have to compile everything from scratch and solve dependency conflicts if you want a newer version of a program than what’s available in your distro’s repo, of if it’s something that doesn’t have a native version at all.
./configure make make install
Missisng
&&?Honestly, i’m not entirely sure what Flatpaks are all about. Not sure I could explain them. But I use them. I’ve used apt. I’ve even used Pacman and Yay in Manjaro for a few years. Now, I also Flatpak (no longer on Manjaro, though. I no longer boot to a blank screen every 6 months or so! Very nice!)
Flatpaks are basically containers, allowing applications to maintain their own dependencies separate from your system. It’s similar to a Windows program shipping with its own precompiled DLLs, helping prevent dependenct conflicts when you go to update something you installed with pacman or yay.
Flatpaks are great for situations where installing software is unnecessary complex or complicated.
I have Steam installed for some games, and since this is a 32 bits application it would install a metric shit-don of 32 bit dependencies I do not use for anything else except Steam, so I use the Flatpak version.
Or Kdenlive for video editing. Kdenlive is the only KDE software I use but when installing it, it feels like due to dependencies I also get pretty much all of the KDE desktop’s applications I do not need nor use nor want on my machine. So Flatpak it is.
And then there is software like OBS, which is known for being borderline unusable when not using the only officially supported way to use it on Linux outside of Ubuntu – which is Flatpak.
works perfectly with my Arch Linux
btw
This is the main benefit. However, i’m finding the software I use requires less dependencies and libraries these days.
I barely even use flatpaks anymore. Almost everything is in official repos. I couldn’t tell you the last time I had a dependency conflict.
OBS worked pretty well for me last time I used it, using the basic package Debian provided.
That’s my main use for flatpaks too. Add to that any and all closed source software, because you can’t trust that without a sandbox around it.
Recently I’ve moved from using flatpak for electron apps and instead have a single flatpak ungoogled chromium instance I use for PWAs.
But why is that? I mean just because it is packaged by someone else does not mean its unusable. So its not the package formats issue, but your distribution packaging it wrong. Right? In installed the Flatpak version, because they developers recommended it to me. I’m not sure why the Archlinux package should be unusable (and I don’t want to mess around with it, because I don’t know what part is unusable).
Because the OBS developers say so.
<img alt="" src="https://lemmy.ml/pictrs/image/902a06ae-9def-4131-bc5d-2a6e755189d4.png">
And since I’m not on Ubuntu, I use the Flatpak version to get OBS as intended bey the OBS developers.
Exactly. Most distributions fail hard when it comes to packaging OBS correctly. The OBS devs even threatened to sue Fedora over this.
gitlab.com/fedora/sigs/flatpak/…/39#note_23449708…
The quoted image does not say so, they do not say the native packaging from your distribution is borderline unusable. That judgement was added by YOU. The devs just state the package on Archlinux is not officially supported, without making a judgement (at least in the quoted image).
As for the Fedora issue, that is a completely different thing. That is also Flatpak, so its not the package format itself the issue. Fedora did package the application in Flatpak their own way and presented it as the official product. That is a complete different issue! That has nothing to do with Archlinux packaging their own native format. Archlinux never said or presented it as the official package either and it does not look like the official Flatpak version.
So where does the developers say that anything that is not their official Flatpak package is “borderline unusable”?
It does exactly say so. Flatpak is the only supported and official method of installation when you’re not using Ubuntu.
Exactly. And the Flatpak version from Fedora was unusable.
They don’t. It’s just unsupported.
I don’t know what you are smoking, I’ve used OBS for years installed from the AUR with zero problems…
It just doesnt work half the time. I avoid them as much as possible.
I spent my time fighting AppImages until Canonical started to force Snap on me. I hated Snap so bad it forced me to switch distros. Now I appreciate Flatpak as a result and I don’t find AppImages all that bad, either. Also, I haven’t found myself in dependency-hell nor have I crashed my distro from unofficial Repos in well over a decade.
-It’s a long way of saying It works for me and it’s not Snap.
Appimages are ok, bloated but ok. Unless a library inside is old and won’t work.
Flatpak is annoying and I don’t like it at all, so I don’t use it. Easy solution.
Fuck snap though.
There’s a lot to dislike about Canonical, but snaps is still relatively easy to purge and just get on with your underlying Debian package support…
Cursed solution to a cursed problem 🤷
I like the idea of them because I don’t like dealing with dependencies changing and breaking stuff and I don’t really care too much about disk space in the context of non-game desktop apps, as I don’t tend to install lots of them.
That being said I absolutely hate that permissions are all over the place and flatpak doesn’t ship a GUI to manage them by default, nor do you get any indication as to what permissions a program has until you try some functionality (like filesystem or camera access) only to find out it doesn’t work out of the box.
Flatpaks are awesome. Flathub is awesome. :)
<img alt="" src="https://lemmy.ml/pictrs/image/74c4b40a-31df-4584-9ffe-c00cb9e5ef9f.png">
I’ve never heard anyone say that Flatpaks could result in losing access to the terminal.
My only problem with Flatpaks are the lack of digital signature, neither from the repository nor the uploader. Other major package managers do use digital signatures, and Flatpaks should too.
I was just wondering the connection between flatpaks and the terminal because I’ve never heard of flatpaks before and Wikipedia says they’re a sandboxed package management system or something?
As someone who uses Flatpak you can still use the terminal to install, uninstall and do maintenance, not sure why people believe terminal is useless with Flatpak 😞
Flatpaks are containers, same as Snaps, I personally prefer Flatpaks over Snaps, but just my personal choice. I use Flatsweep and Flatseal apps to help administrate Flatpak apps, but use terminal as well 🙂
I’ve no real preference so long as my PC starts stuff. The reason I avoid flatpaks is because I have at some point acquired the habit of anything I install that’s not an appimage I pretty much launch from the terminal and I remember trying flatpaks and them having names like package.package.nameofapp-somethingelse and I can’t keep that in my head.
I’ve actually been discussing the idea of Flatpaks offering “terminal aliases”, similar to what Snaps do, with some people involved in Flatpak. It’s something that could happen in the future, but for now, you can totally create an alias to run a Flatpak from a single word, it’s just a PITA.
Nah, it’s the same as with systemd, docker, immutable distros etc. Some people just don’t appreciate the added complexity for features they don’t need/use and prefer to opt out. Then the advocates come, take not using their favorite software as a personal insult and make up straw-men to ridicule and argue against. Then the less enlightened of those opting out will get defensive and let themselves get dragged into the argument. 90% that’s the way these flame wars get started and not the other way around.
For the record, I use flatpak on all my desktops, it’s great, and all of the other mentioned things in some capacity, but I get why someone might want to not use them. Let’s not make software choice a tribalism thing please. Love thy neighbor as thyself, unless they use Windows, in which case, kill the bastard. /s
Can someone explain why flatpak isn’t necessary for distros that have proper OS dependency management like Arch-based distros or Nix?
Seems like flatpak is solving a problem for OS’s that don’t have proper dependency management.
You answered your own question. Arch and Nix solve the same problem Flatpak solves, but by using better dependency management. Flatpak’s main proposition is built-in sandboxing and convenience, but if you’re on an “expert” oriented distro like Arch (btw), you probably don’t care as much about those “freebies.”
In that case flatpak is basically a hack for OS’s with broken or improper dependency manangement systems. Either those OS’s should fix their broken systems, or ppl should move to OS’s that do it properly, as that’s one of the most important functions of your OS anyway.
Also pretty much everywhere you’re using flatpaks (or snaps or…), you are doing it on top of a Linux system that’s still getting its core system updates via traditional dependency management. And flatpaks, despite trying not to, make assumptions about your kernel, your glibc version, architecture, ability to access parts of your filesystem or your devices, that can break things, and doesn’t bother to track it.
And the closer you get you tracking that stuff (like Snap tries to), you hilariously just get back to where you started, with traditional dependency management that already exists and has existed for decades.
Flatpaks make sense for atomic distros, too. It’s not always a matter of there being one right way to do things.
main selling points are isolation and having the latest version directly from developers without having to wait for your distro to package/update it.
both are debatable since they are not as good as promoted (isolation doesn’t always work correctly and it’s a mess to configure it once you use anything different than the more mainstream distros) or goes against the historical preference (using bundled everything instead of cooperating with your distro packages and trusting every individual over trusting your distro as a whole) but having the latest version on any distro without having to wait is a popular need so they gained traction quite fast. this might make little sense for rolling release distros (arch, nix) but it’s helpful if you have a stable base (years old debian) but need the latest feature on an specific application or have to use very specific libraries that are not packaged on the main distro and would require complex upgrades
I’m not a huge fan of Flatpaks, they’re a lot harder to distribute offline versus something like AppImage. Seriously, you have to like create an offline repository, then create a bundle, and it’s like 6 or 7 steps, it’s honestly kind of ridiculous lol but other than that they seem fine, and they’re easy enough to update (but so are apt packages)
I know some people may say “oh why do you need that”, but Linux has taught me that my computer is my own, and I should be able to use it the way I want to. I shouldn’t have to fight with my package manager to get it to do what I want. So I guess you could say, no I’m not really a fan of Flatpaks.
Personally, I didn’t mind Snaps, but I’m getting kind of really fed up with especially for-profit companies etc so I don’t like Snap that much now either.
Apt packages are nice, but the more of them you have installed, especially if you’re using Ubuntu-based distros and have lots of PPAs, the more annoying upgrading your distro version can be because of all the dependencies and cross-dependencies.
AppImage tends to just work for me, as long as it’s not compiled with a newer libc-bin version than the distro I’m currently using has, and I really enjoy that it’s just one file I can copy and run pretty much anywhere.
I seem to have constant issues with AppImages. Every single one I have currently won’t open. I get an error message relating to either qT or GTK. Tried searching for the error and get a bunch of old forum threads talking about either not being compatible with Wayland at all, or comments stating that the one specific AppImage in question must have been “packaged badly”. Thankfully, nothing ‘mission critical’ for me is an AppImage currently, but it is quite upsetting that I have the most problems with the supposed “just works” app packaging/distribution option.
Yes, Flatpak is overall a better approach when compared to AppImages, since being dependent on a known runtime ensures the program will run whenever the runtime is available.
What I wish they would add is a way to run the flatpak in a portable way. Because as it stands, AppImages is the only option for that. Flatpak doesn’t really allow to have a portable installation in a pendrive, for example. At the moment there’s no replacement for AppImage in such use cases, which is a pity.
But there’s no fundamental technical design roadblock in flatpak that would prevent it from supporting this in the future, imho. theoretically one could create a program that mounts the flatpak file into a ramfs layered with the runtime and run it.
Yeah that’s why I’m a bit weary of switching to Wayland, so many apps still seem unsupported, or have issues, whereas on X11 everything for me just works. Plus, the two DE’s I’d actually consider using either don’t have Wayland support at all or have very early experimental support (Cinnamon and Xfce) so it’ll still be a while for me before I am able to consider switching to Wayland, assuming everything else works.
I don’t actually know if it is a Wayland issue - most of those forum posts are like 3 years old… And I have definitely used these same AppImages in the past on Wayland without issue. I think the AppImages are expecting some specific dependency to be installed on my system that is no longer installed due to updates. (which I thought was counter to the entire point of an AppImage? I thought it was supposed to be kinda like Flatpak where it has it’s dependencies in the image? Maybe I just misunderstood AppImage…)
To give you some hope, my Distro switched to Wayland as default a little over a year ago (i think) and I have not been running into problems (outside this AppImage problem, if it is indeed a Wayland issue, which I cannot confirm or deny).
I’m relatively new to Linux. I honestly don’t see what the problem is.
It destroys the beautiful and carefully cultivated ecosystem of distributed packages that has been the bedrock of Linux for decades. They’re bloated, often not quite as sandboxed as claimed, have created packaging chaos, and assume availability of system services that may not be there.
All of this is true and precisely zero normies care about any of it.
The fact that I can put my
idiotsfamily on any modern distro and tell them to use the app store alone makes flatpaks king of the app managementI don’t really care about all these different things, as long as none of them become a crazy confusing mess, like Windows DLLs.
The one “good” thing about containers is that you keep your DLL-like mess localized. Just one or a few related apps run in the container and if they want / need some weird library version, they can have it without breaking other things.
Yeah but that’s a huge benefit already. I am not savvy enough in the development side to know whether that’s a reward that justifies any of the frustrations people have. Personally I don’t really mind varying methods to do any one job, as long as it’s well-documented, easily managed, and does not create a higher load on the system in any respect.
I view the delays during launch and the extra time spent during updates as a “load on the system.”
Also, it entirely depends on your deployment environment. I develop system images that go out on thousands of devices deployed in “Cybersecuity Sensitive” environments, meaning: we have to document what’s on the system and justify when anything in the SBOM (list of every software package installed on the machine) is identified as having any applicable CVEs… soooo… keeping old versions of software anywhere on the machine is a problem (significant additional documentation load) for those security audits. Don’t argue with logic, these are our customers and they have established their own procedures, so if we want their money, we will provide them with the documentation they demand, and that documentation is simplest when EVERYTHING on the system has ALL the latest patches.
The most secure systems are those that don’t do anything at all. You can’t hack a brick.
Hey, like I said, great info for me to learn because I don’t know. I was only saying that I don’t mind because my situation is fine with it. Thanks for the info, it’s interesting. I’m sure for any situation there’s a better and worse solution and I’m sure that for any solution, there’s a situation that either likes or dislikes the approach.
Yeah, I agree. Canonical seems to think “snaps are for everyone” so, for both my personal and professional applications they have decided: “Canonical is not for me.”
i mostly use them for proprietary stuff or for software that is incredible painful to package (mostly electron apps). i will probably never use them for anything that actually matters but i also use rolling release distros everywhere so latest release is never too far. for testing latest version of any software i prefer appimages since they are simpler and don’t need a messy setup as flatpak, but i also won’t use them pass the testing phase and i prefer packaging the software if possible.
snaps, on the other hand, will never go near any of my systems. not even by accident
Personally I am okay with them actually. I use several on my system and having each app allowed to have different permissions is super useful.
But also I like things that are directly installed cause they seem just a tad faster performance wise.
The thing that grinds my gears is when I’m doing an apt update and then it goes off to check on the snaps and drags the process out a lot longer. It doesn’t help that they’re slower to load the apps too. Then there’s the additional attack surfaces to accumulate more CVE reports (and more out of date library versions on your system begging for a security patch…) Mostly, I just purge snap support from Ubuntu these days - but for people who don’t notice / mind such things, you do you - maybe they’ll eventually improve the lightweight container system until the rest of us don’t notice it either.
Ohhh I’m not a huge fan of snap packages, tho to be fair I haven’t used them recently so it might just be just biases
There was a few years where I pretty much only used Flatpaks because I was scared of the terminal. But now that I’ve learned how to use the terminal, it’s so much more convenient because I can quickly update all my applications all in one place without having to open a separate app. Plus, some Flatpaks can fall really behind on software updates.
There might be a Linux userbase someday where no one other than developers actually knows how to use the terminal, because users can run everything they want without a command line, but maybe that’s actually a good thing because it’ll drive up how many people use a Linux distro.
With Windows and Mac, there’s a shareholder incentive to enshittify. With Linux, if a distro goes bad and gets commercialized, there’s always another distro people can move to, not to mention there’s no financial incentive. The more people get on Linux, the less power these tech companies have. Personally, that and privacy are what drew me to Linux much more so than being able to tinker or fine-tune my experience.
Ideally, all the essential terminal commands could be replicated in a user-friendly GUI-applicable manner. Don’t ever have to remove the terminal for those that enjoy it, but if we could have a magic world where even the failure states could be navigated with little to no prior knowledge required and it gets everyone away from Windows and Mac for good, I’m all for it.
Yeah I just wanted off mr corporation’s wild ride
What’s a flatpak? Is that like a worse NixOS package? I prefer NixOS, BTW.
sandboxed application bundle installed from a flathub-compatible store or a local source (github etc)
Could things like this go in linuxmemes? Memes are fun but it would be nice to keep this a place for actual information. And no, this is not a comment on what it’s saying, I’m just tired of so many memes.
I use SystemD binary Gentoo with Flatpaks. Sue me.
Watch out we’ve got a flatass over here
✋😕🤚
Absolute Dogshit
I’ve never had a problem with flatpaks or snaps.
I wouldn’t say I have had a problem with snaps or flatpacks either. I uninstall all snaps first thing when I install recent Ubuntu versions, and I have never messed with flatpacks, so… no problems.
I think people who dislike flatpaks or similar aren’t having “problems”. They work, but they’re using using a sledgehammer to drive a nail.
The issue I have with flatpaks is the size for most applications. It just doesn’t make sense for me. Not that it’s not useful and has it’s purposes.
Flatpaks aim to be a middle ground between dependency hell and “let’s pull in the universe” bloat.
Applications packaged as Flatpaks can reference runtimes to share “bases” with other applications, and then provide their own libraries if they need anything bespoke on top of that.
And they are still, in my experience, slow to load, a cumbersome addition to the update process, and often un-necessary.
Don’t get me wrong, if you’re in a tight spot and can’t make two significant software packages work in a distribution due to conflicting library version requirements… some kind of lightweight container solution is attractive, expedient, and better than just not supporting one of the packages. But, my impression is that a lot of stuff has been moved into flatpak / snap / etc. just because they can. I don’t think it’s the best, or even preferred, way to maintain software - for the desktop environment.
(Returns to checking on his Docker containers full of server apps on the R-Pi farm…)
I’m running an immutable distro at the moment (GNOME OS), and I felt no loss of performance due to Flatpaks. Snaps, on the other hand, do have a perceivably longer launch time.
Given that it’s an immutable distro, everything I need needs to be either a Flatpak, a Snap, an Appimage or an extracted tarball, otherwise it runs in a container. The advantage of this system is stability and making the host incorruptible, as well as the ability to very easily roll back updates or failed systemd-sysext layers.
Not everything can run in a Flatpak at the moment, but we’re hoping the evolution in Flatpak, XDG portals as well as encouraging developers to use the available XDG portals can make this a possibility someday. Namely, IDEs don’t run that well in a Flatpak, but GNOME Builder has proven that it’s 100% possible with the currently available XDG portals as well as connecting your IDE or editor to a container.
Not mocking: can you share any good guides to practical immutable systems?
What I observed of Ubuntu Core made a strong “not ready for prime time, and even if it was I don’t want it” impression on me.
Ubuntu Core, based on Snaps, is very much not ready for prime time IMO. It’s kind of a mess outside of server use.
Look instead at Fedora Silverblue, Vanilla OS, and for the bleeding edge of immutable systems, GNOME OS.
KDE is about to launch their analogue to GNOME OS relatively shortly, named “Project Banana”. These two are not exactly distros as they do not distribute the kernel, they are simply platforms that layer a bunch of images together to create a stable, reproducible system. There’s also OpenSuSE Aeon, but I don’t like its style of immutability as it’s immutable by rootfs lock-out rather than immutable by image.
As for advice, learn how to use Distrobox / Toolbx containers. If you’re a developer, this is where you will be working.
Immutable Linux is still young, and a lot of software isn’t written with it in mind, so expect some growing pains.
I’m on silverblue, well, bluefin, specifically.
So far so happy 🤷♂️
Thanks. In the past I have worked in Slackware, and even had Gentoo on my home system for a couple of years, but otherwise I’ve been fully saturated in Debian and its children - so that’s my “comfort zone.” I used to like KDE, but drifted away from it when I got a 4K screen notebook and KDE hadn’t figured out resolution scaling yet, while Ubuntu/Unity had. I never quite warmed up to GNOME, but definitely have done my time with it. XFCE has matured enough for me to daily drive it without too much pain now, and I love the ways it can be de-featured (don’t want a launcher bar? Don’t run it, nothing else breaks.)
Server-side, I have been filling my Raspberry Pis with Docker containers for a while now… it’s not completely alien, but I do kind of tend to “set it and forget it” when it comes to container deployments.
Fast storage is one of the cheapest components of modern PCs so I’m always surprised when Flatpak file size is brought up. It’s not something I worry about very much.
Unlike that apostrophe.
I’m 2 months into my Linux journey and I don’t use flatpak. I’ve had the odd problem with it. I stick to pacman and yay now.
Is that supposed to be Ed Norton, or just an uncanny coincidence?
Furniture? Integrated circuit packaging?
It’s a neat concept. The distro-agnostic aspect is definitely a plus for some people but I still prefer distro-specific installation methods. The only time I would seek out the Flatpak version of a particular software is when it’s the only version available.
flatpaks are fine and useful, i just wish we didn’t move into a scenario where applications that used to be easily available in distro repos start moving away from them and are only available through flatpaks. distro packages are just so much more efficient in every way. flatpaks are easier on maintainers and developers but that comes at a cost to the user. i have about a dozen or less flatpak apps installed and already i have to download at least 2 gigs of updates each week. i run debian
Flatpacks a fucking insult to people with limited bandwidth.
I like flatpak, but I can’t download Flathub flatpak applications and (specially) Flathub flatpak runtimes from my phone. I hope Flathub learns from F-Droid
I’m happy to use Flatpaks but the annoyances I’ve had are like when one application says to use you’ll need to point to the binary of another application that it depends on but very understandably doesn’t package together, figuring that out to me can be annoying so I’ll switch to a regular installation and it all just works together no fuss, no flatseal, no thinking about it really. Also some applications where it’s really nice to launch from the terminal especially with arguments or just like the current working directory and with Flatpaks instead of just right off the bat it’s application name and hit enter, Flatpak hope you remember the whole package name
org.wilson.spalding.runner.knife.ApplicationName …
Ya alias but got to remember to do that. So far anything I’d ever want to run from terminal, no Flatpak
As long as software is available in the Software Manager to be installed that way… I don’t care what format it’s in.
But don’t make normies go to the terminal. It’s inhumane, and really does not help the masses get away from big tech - which is a worthier goal than keeping your software terminal-only.
While I wouldn’t want flakpak going deep into the OS I think the advantage of using them on the desktop is obvious. Developers can release to multiple dists from a single build and end users get updates and versions immediately rather than waiting for the dist to update its packages. Plus the ability to lock the software down with sandboxes.
The tradeoff is disk consumption but it’s not really that big of a deal. Flatpaks are layered so apps can share dependencies. e.g. if the app is GNOME it can share the GNOME runtime with other apps and doesn’t need to ship with its own.
FTFY: Flatpaks are layered so apps can share dependencies. e.g. if the app is GNOME 4.2.11.3 it can share the GNOME 4.2.11.3 runtime with other apps and doesn’t need to ship with its own, but every app requires a different GNOME version anyway
Perhaps ironically, this is mocking a strawman. Flatpacks can be installed and managed using the terminal! Not only that but Linux-Distros have had graphical package managers for decades.
The primary reason that distros have embraced flatpack / snap / appimage is that they promise to lower the burden of managing software repositories. The primary reason that some users are mad is that these often don’t provide a good experience:
Theoretically they are also more secure… But reality of that has also been questioned. Fine grained permissions are nice, but bundling libraries makes it hard to know what outdated libraries are running on the systems.
As far as I know, I’ve only installed Flatpaks using the terminal. The most annoying thing about them for me is having to type out the fully-qualified name of the software (e.g.
org.mozilla.firefoxinstead of justfirefox), which is a very terminal-specific issue, LOL!Not.
Size and gnome/GTK dependencies are main reasons why I don’t use Flatpaks (I have nothing against gnome though, it just pulls in too much and KDE is worse in this regards, which is why I use Sway and River)
Naw fuck gnome and fuck GTK. Over invasive and controlling crapware.
I need OBS on this new computer!
Let’s install the flatpack!
V4l problems
Plugins Problems
Wayland Problems
I’m just going back to the .deb, thanks.
Flatpak being securely sandboxed by default is both its biggest strength and its worst point of contention. The XDG is still scrambling to replicate the permission requests paradigm from Android on the Linux desktop.
Not a fan for a few reasons. Flathub (as far as I know) works on the app store model where developers offer their own builds to users, which is probably appealing to people coming from the Windows world who view distros as unnecessary middlemen, but in the GNU/Linux world the distro serves an important role as a sort of union of users; they make sure the software works in the distro environment, resolve breakages, and remove any anti-features placed in there by the upstream developers.
The sandboxing is annoying too, but understandable.
Despite this I will resort to a flatpak if I’m too lazy to figure out how to package something myself.
The sandboxing is part of the point, having a permissions model that puts the user in control of what programs are allowed to do is critical.
I’m a big fan of the idea of sandboxed apps. Flatpak is not great as it compromises sandboxing for compatibility (both with distros and apps) and also it’s quite stagnant now. But there are no other options anyway, so I use it.
Enter the calm and quiet room
Pass out torches and pitchforks, guns and knives
“Snaps exist”
War erupts.
SNAP BAD
War with who? I’m posting this from Kubuntu and I’d happily agree with you that Snap should fuck off and die. (In particular, the backend being controlled by Canonical makes it objectively bad compared to Flatpak.) Even among people like me who tolerate Snap (for now…), I really don’t think you’re gonna find anybody who actually likes it, let alone enough to champion it.
Can’t start a war when there’s a consensus!
Oh, hi! I also use Kubuntu, but I love Snaps! I use them for everything. I even tried to use a Snap-version of the kernel, but it completely destroyed my system so I had to reinstall… but other than that, they’re great.
I “grew up” with Slackware, so I definitely understand the dependency issue.
I like flatpaks (and similar) for certain “atomic” pieces of software, like makemkv. For more “basic” software, like, say, KDE, I want it installed natively.
I use Aurora DX so most of my apps are flatpaks. Its fine.
Just another tool in the toolbox. Use it or not, up to the user. I’ve even seen Slackware users who say they use Flatpak to ward off dependency rabbit holes.
Don’t like it for one simple reason: no integration with the distribution. Flatpak is this sort universal solution that works, but doesn’t necessarily work hand-in-hand with the distro, unlike package managers.