?? I manage flatpaks exclusively in the terminal
deleted by creator
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.
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.
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…
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.
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 good, especially compared to snap.
The future is atomic OS’s like silverblue, which will make heavy use of things like flatpak.
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?
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!
The thread is about snap and why it’s worse than flatpak.
We’re talking about snaps in contrast.
My bad. Thank you for clarifying!
And also the fact that the store backend is proprietary
Mostly start up time for me. It just takes the programs longer to launch.
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.
They have their place, but they can’t really completely replace traditional distros.
As it stands, I kinda agree. But I truly wonder to what extent we might be able to close the current gap.
deleted by creator
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.
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.
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. https://en.opensuse.org/openSUSE:One_Click_Install
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
deleted by creator
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.
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
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.
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.
Installing flatpaks via the terminal is so much faster for some reason, so I always do it that way.
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
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.
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.
This all leaves us with one King:
And it is Flatpak.
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.
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.
More precisely, it almost never does.
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
I don’t mind other solutions, as long as they have the key features Flatpak offers, namely:
- Being open-source
- Having app permission system
- Having bundled dependencies
- Integrating decently with the system
Times are changing, and memory constraints for most programs are generally not relevant anymore.
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…
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.
-
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.
Changed my mind. Thanks.
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: https://flathub.org/apps/org.gimp.GIMP
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.
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.
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
Ого, то есть примерно когда я сам здесь очутился. Никогда не слышал о ру инстансах, хоть и искал. Теперь, кажется, нашёл)
Берёте человечка на борт? Не обещаю сделать Рекабу главным инстансом, но всегда полезно быть по обе стороны Чебурнета, а то последнее время с забугорными беды бывают.
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.
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.
Not true lmfao
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…
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.
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.
OBS worked pretty well for me last time I used it, using the basic package Debian provided.
works perfectly with my Arch Linux
btw
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).
But why is that?
Because the OBS developers say so.
And since I’m not on Ubuntu, I use the Flatpak version to get OBS as intended bey the OBS developers.
So its not the package formats issue, but your distribution packaging it wrong. Right?
Exactly. Most distributions fail hard when it comes to packaging OBS correctly. The OBS devs even threatened to sue Fedora over this.
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/39#note_2344970813
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”?
The quoted image does not say so
It does exactly say so. Flatpak is the only supported and official method of installation when you’re not using Ubuntu.
As for the Fedora issue, that is a completely different thing. That is also Flatpak, so its not the package format itself the issue.
Exactly. And the Flatpak version from Fedora was unusable.
So where does the developers say that anything that is not their official Flatpak package is “borderline 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…
Flatpaks are great for situations where installing software is unnecessary complex or complicated.
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.
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.
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”
Worst case scenario there’s still the option of letting it escape the sandbox. This is how I made my CAD software integrate nicely with my slicer.
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.
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.
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.
Would you mind elaborating?
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 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.
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’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.
cool, thanks
deleted by creator
