How does it stack up against traditional package management and others like AUR and Nix?
Best of the three major agnostic package formats. If it brings more focus to Linux development, I don't see how it can be a bad thing. A bit more space needed but for most setups this is a non-issue
Plus, being able to sandbox user space applications, which previously had free reign, is nice.
Sandboxing isn’t 100% there yet, but it’s come along way.
Yeah duplication of running libraries is also a RAM/CPU resource issue but for modern well resourced machines probably not noticable. It is an issue when scaling down to low powered / old devices though. Like, running a web browser which runs in it's own sandbox with duplicate libraries running is going to have noticable performance differences compared to a non-sandboxed program running native libraries on a low RAM or low CPU system.
That's not to say Flatpak isn't a good solution; and all the agnostic package formats have the same issue compared to non-sandboxed apps. Plus the added security issues and stability on bleeding edge systems is good.
I love flatpak. It makes it easier for Linux to become mainstream.
As a non-technical user: fucking love it.
As a semi-technical user: I also fucking love it. It gets out of the way so I can focus my time on my work and not OS maintenance.
@tet its great because you can listen to people whine about it now instead of systemd
The two whines are not mutually exclusive. ¯\_(ツ)_/¯
@kingmongoose7877 until someone tells me another way to run 2 python apps one which requires python 2 and one which requires python 3, on the same system, which is EASIER than installing a flatpak, im gonna maintain that they have a use case, even if they aren't idealized package management as we dreamed of
Easy, tiger. I think you misinterpreted my original reply.
I meant the whining about the two (systemd and flatpak) isn't strictly OR but may be AND. Have a nice day.
I think pyenv would be the appropriate tool for doing a native install. And of course when it comes to CLI, Flatpak isn't really for that.
@pingveno i think that two things get conflated. 1. flatpaks and appimages, snaps, have some niche uses for obsolete software and maybe some other edge cases 2. because the two major standards are backed by dumbass corporate entities, they have been promoted as the universal solution to everything that will revolutionize linux 3. the real thing everyone hates, is these stupid companies trying to get rid of a beautiful package management architechture so they can enshittify linux like windows
I think their uses extend beyond obsolete software. In particular, trying to get updates out to a wide variety of Linux distros has generally meant a tradeoff between "move fast, break things" and "move slow, never change". Flatpak gives you a stable set of libraries to work with and the ability to run multiple versions of those libraries at once. Linux package managers have a place, but their sheer proliferation means that for most applications to reach all desktop Linux users, they have to go through something like Flatpak for distribution.
Uh. Python is like the worst example for this, conda/mamba?
Cheese with your whines?
You should use WINE only through Flatpak btw
🤦♂️
Speaking of which, didja hear that for the upcoming Easter holiday, Amazon is offering a special gift basket of northern Israeli cheeses.
They're calling it Cheeses of Nazareth.
You have received the Dad Joke Gold Star
Are you trying to start a war? Hopefully no one mentions wayland vs xorg else it might go nuclear
@squid_slime let me install this flatpak of kde wayland on my oracle unbreakable kernel running under redhat enterprise
That's like two keystrokes in emacs.
It's fantastic, for two reasons:
There's so much great software available through it, and I can always get the latest version regardless of my distro - or an older version if it hasn't kept up with its dependencies.
It's part of the tooling that allows me to update my operating system without risk of it breaking (i.e. I can use an atomic distro because of it).
I really like the idea of a universal app format and flatpak seems the best for it. And flathub has been great as a repo.
The idea of separate system layer (with traditional packages) and user app layer with flatpaks seems like the way to go. Perhaps even immutable system layer.
I think it's a good way for people to release software for Linux without having to deal with specific distro stuff (which historically has pretty much been "just provide a .deb for Ubuntu and a .tar.gz for other people to figure out").
I'm hoping that it pushes for more people porting stuff to Linux because it's a single target that gives you access to Steam Decks, Chromebooks and desktops.
I don't think it makes sense for things that aren't desktop applications such as servers or libraries, just because those tend to be open source, don't need to be that up to date and benefit from tighter system integration. I see it as something that sits on top of other package managers rather than replacing them.
For Flathub? Eh, if they turn out to be bad we can just all move to another server, we're not snap. :P I'm willing to bet that someone has already made a flatpak repo for Citra and Yuzu.
I personally prefer to use Flatpaks over traditional packages because of the added security, sandboxing, and overall convenience of not having to deal with dependency hell. It's especially nice being able to have proprietary applications sandboxed from the rest of my system without worrying that Steam is snooping on my 'super-important-tax-documents'.
Flatpaks are also very useful for having up-to-date packages on distros like Debian, and it's derivatives. People can still use their preferred distro without having to worry about not getting a certain update, feature, bug fix, etc, for their applications.
Being able to restrict what applications have access to is a game-changer for me. A lot of times Flatpaks, by default, have very lenient permissions, and with the use of Flatseal I can restrict it to my liking. Worried about Audacity's telemetry?? Turn network permissions off.
Now, not all applications will work well (or at all) without internet connectivity, but for applications like Audacity, it works great!!
Flatpaks can also be very useful for developers.
That's not to say that Flatpaks are without their fair share of issues. Are they bloated?? Yeah, and although it's not an issue for me, it may be for some people. Desktop integration is, meh. Themes, and fonts don't always integrate the best. (A while back there were issues with Flatpak's sandbox, but I won't touch on that because I need to refresh my mind on it, and it was actively being developed to fix those issues so it possibly isn't even an issue anymore.)
Overall I think Flatpaks are absolutely wonderful.
People need to realize that before Flatpak, distributing a small-time Linux app was a nightmare. Appimages were your best option if you wanted to avoid distro specific builds, PPAs and AUR, etc. Ever since packaging 2009scape on Flathub I haven't looked back. It auto updates. People can find it from software centers. It works on all distros. It connects straight to upstream's CICD. It even forced us to adopt XDG compliance so we could sandbox it better.
Yes, Flatpak has downsides like the download size (on disk it doesn't matter because it gets compressed and the runtimes are shared, same as literally any other package manager). But overall, I hugely welcome it over the options we had before. Much love to the Flatpak and Flathub devs!
Ever since packaging 2009scape on Flathub I haven’t looked back.
So YOU are the one to blame for my latest Runescape addiction relapse! I only learned of the project because I stumbled on it while browsing flathub
LOL
Flatpak shooould just download the diffs
They should, actually. Google released a tool for downloading only the diffs on binaries a few years ago
They use ostree afaik, so "they should" as in "I think they do"
And they did, with bsdiff, an algorithm invented awhile ago. I wish system package managers carried this/weren’t actively dropping their implementations :(
As a generalist I have to learn many concepts and dont have time to delve into any one that deep. Flatpak works and isnt proprietary like snap so I enjoy that. My recent debian+kde installation works well with if. Open discover and install flatpaks as much as you wish.
The Snap Store is run and controlled by Canonical and is not open source. The rest of Snap is open source, meaning the daemon and core software. [emphasis mine] How threatening this is depends on you POV and has been the subject of much discussion.
Exactly, proprietary.
if the only way to use the open source client, is with a closed source server, is it really open source at all? The platform is the server.
This isn't threatening in a way that Canonical would hack my computer with it. It's threatening the Linux ecosystem. They created a distro agnostic package manager which is solely controlled by them. In other words they want everyone to use Snap and then vendor lock in everyone into it. "embrace, extend, extinguish"
I honestly wouldn't care if snap was both Canonical proprietary and Ubuntu proprietary but this M$ like strategy sucks.
I definitely prefer it over Snaps or appimages. Straight-forward to update, and Flatseal provides a nice GUI to control permissions (if needed). Themes may not work properly, but whatever, not a big deal for me.
The distro's repo is always my go-to. If it's not available there, then flatpak, and I'll use appimage under duress. If that doesn't work, I'll figure out a different solution.
Yeah I'm not a huge fan of Appimages because I don't like that to update it you usually have to go find and download the file again, instead of just getting it from a repository. They feel too Windows-y to me in that way.
I use them for some things and I think they are fine. Mostly apps that are kinda messy and I want to keep them and their atrocious dependency tree away from my base system. I also like to use them for proprietary apps or apps where I actually want to use the sandbox. Other than that I prefer native packages 99% of the time.
Flatpak is slower to update than pacman, the cli interface just doesn't feel good to use. There is the weird naming, no real way to get a dependency tree, can't hide those annoying eol messages even for apps that I specifically don't want to update. Another thing is that not every app was made to run in a sandbox or it is just more difficult to use sometimes.
A lot of people tend to cite ide's, but in my case I was having issues with the steam flatpak. Running games with steam was fine, but anytime I wanted to hook up something third party eg: mods, cheat engine, etc. Doing so in the flatpak either required some tinkering around the sandbox or straight up didn't work.
I feel like that last sentence sums up the whole experience. If you just need to point and click and have it work. Flatpak does that amazingly. If you need any kind of integration with other things, expect problems.
Edit: just wanted to add that, the whole point and click and work is fine for 99% of people which is why I and many others choose to use it.
Yeah, I also had apps like Steam native break once or twice due to library updates (such as Mesa) - the downside to rolling distros. However, the Flatpak version continued to work so now I only use that. I don't use mods though.
I'm now gravitating towards treating my rolling distro a bit like an immutable; more Flatpaks, avoid user repositories.
While I don't think flatpak shouldn't replace traditional packages, I still like it.
Flatpak apps just work most of the time, they work without issues and are often very up to date. The sandboxing does have benefits because no apps interfere with it, the problem is that it doesn't work super well with other apps, sometimes the theming is off, and it doesn't work well with other apps, installing apps takes much longer, and it isn't as easily started from the command line.
Edit: typo
In my opinion, with a debian style distro as the example, apt-get should be used for syatemwide stuff. Individual users can go for flatpak.
Flatpak is fantastic for end-user GUI applications
Flathub is also great, but the fact that it's really the only repo that flatpak maintainers are using concerns me. I know I'm dreaming, but I would love to see some sort of federated or P2P hosting
Its a solution to one of the typical Linux issues. Its a step toward overcaming the fragmentation of Linux package managers.
I don't personally like it too much, I prefer the distro package stuff, but I understand the app developers cannot manage a plethora of different package formats.
Distro maintainters should, but its clearly more and more a massive task for different distros to keep up with the amount of apps out there.
Also, npm, pip and the various "packaging" ways existing add to the chaos.
I see distro package managers converge toward providing basic packages for the general system and some other solution like flatpack to provide additional stuff.
I think it would be wrong for flatpack/containers to replace package managers as well, it's not their scope.
I see distro package managers converge toward providing basic packages for the general system and some other solution like flatpack to provide additional stuff.
IMHO doing this would be suicide for most distros.
There are only so many ways you can make a basic system and the distro scene is already saturated by various interpretations of "basic".
A distro needs to offer more than the basic system and a huge part of that added value lies in its packages (and by extension package manager).
I love them. They make the immutable distributions possible.
We need to stop with the idea of shared libraries, it's nice on the paper but in practice you only save a bit of disk space and it's a pain for developers to package for different distributions.
Distribution packages are great for core components of the system, or utilities everyone needs, but for end users applications something like flatpak makes more sense. This way it can be packaged by the upstream developer for all distributions, and sandboxing adds a layer of security. You wouldn't install an app that have all permissions on mobile, why do it on desktop?
As a guix/nix user
Please, no more copies of the same dependencies 10 times over. My hard drive is tired.
Lol this ^
Some of the under-the-hood implementation of Flatpak irritates me, like why the hell are we installing software in /var? Using it with the terminal is a pain because of the org.something.SomeThing shit it does, and I think Flatpak gives you all the drawbacks of app sandboxing with none of the benefits. It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn't see anywhere I wanted to put my games library. That needs to be fixed.
That said, I think it's the better of the three all-distro package managers, it's got a central repository and package manager unlike Appimage so it's a place to publish and get stuff, and it's not tied to Canonical so it's obviously better than Snap.
if you want to change app permissions, use Flatseal and add the needed directory. This is very easy. If it is something all users generally need, open a bug on their repo.
Installing a separate program to make the first program work the way it should in the first place, and opening bugs in repos, is abolutely 100% things end users are willing to do.
KDE has flatpak settings included, GNOME is doing their thing with unix philosophy and all. Flatseal works fine.
As I said, you should not need to edit those settings, maybe you need to, and if it generally makes sense (for example GNUmeric only has documents access, nothing else) this needs to be fixed.
The state of flatpak permissions currently is like that. They can never read each others storage, much like on Android with /storage/emulated/0/Android/data. So it you keep stuff stored inside these apps its safe.
Until they can use portals, many have permissions to read/write everything
It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn't see anywhere I wanted to put my games library. That needs to be fixed.
I use it as the primary way of installing apps on my Steam Deck, as well as my Ubuntu PC (I also use Snap over there). The apps installed via Flatpak just work, so I have nothing to complain about.
I prefer Flatpaks because it's a nice easy way of getting software without the chance of broken or missing dependencies for a program.
Much better than Snaps, snaps is flatpaks but MUCH worse and slower.
They have their uses. In particular they're useful for easily getting applications your system repositories don't have or getting more up to date version of applications. Downsides are certainly the space all the redundant dependencies take up and the sandboxing can be a PITA especially if you have an application that needs to run another application. Overall I think they're the best "third party" package system available but they're not great.
👍
I got sick and tired of the AUR for the simple packages so I started using it for most things I would use the AUR for, and I'm very happy with it. I think some packages have issues with default permissions - I was wondering why 86Box would forget my hard drive images but then I realised the permissions on my home folder weren't set properly - but that can be sorted anyway.
very cool and awesome
Great to me. My personal favorite piece is the portals system built to make permission access easier but transparent to the user. It also helps more pieces of the desktop space interoperate (for example use the system defined file picker instead of needing to ship your own).
My main problem with Flatpak is that it hands temporary /var/run/1000 file links to programs instead of real filenames. That would almost be bearable, if Flatpak also took responsibility for keeping those links from breaking sometime after your next reboot.
If I say "here is a path that an app is allowed to use", flatpak should just allow an open() in there to work. It should not lie about the name of files in there. An app should be able to open a file there, remember that name, and count on being able to access it again in the future.
Other than that, Flatpaks are the bees knees. I love finding something I want to do, finding a solution in the flatpak store, and click-click I'm already doing shit. Finding Windows software is absolute garbage next to this.
Thats basically persistent portals. Would be possible if Distro portals had a button to give the app permanent (static) permission to that dir.
Would indeed be useful and not hard to implement. In the portal window just add a button "permanent" which does
flatpak override --filesystem=$PWD org.app.name
Want to open a discussion or Feature request for your desktops portal?
How does it stack up against traditional package management and others like AUR and Nix?
I only used AUR for a few packages (<5 at a time). It's to be avoided and only used if the other options are a massive pain (unless it's an official package).
Then I left Arch and eventually landed on MX. During that time Nix with home-manager has slowly replaced flatpak, and I don't even have it installed anymore. Nix is better in every way, except for ease of use.
Flatpak has great gui integration (for gui tools). You can click through everything, and the updates are unified. It usually works perfectly fine if you just need to install a few programs.
With nix, there's a lot more setup, but there are many benefits. You end up with a list of packages, and that's really useful because you can take a fresh install, install nix and home manager, and then run a single line to reinstall everything. You can rollback updates, pin specific versions, install packages from a repo (if it has a flake.nix with outputs), and also configure them. I'm using the unstable branch, and it's giving me bleeding edge packages on Debian. And there's no risk of outdated system libraries, like with flatpak, because it provides everything.
That all sounds great, thanks!
Do you have any tips for an "easy" start, where everything is already pre-configured?
Nope, and that's the worst part of nix. I'm actually planning on writing a short startup guide, but I need to solve a few more issues first.
But, this should help you out until then:
installation commands (per user installations, no sudo needed for using nix or home-manager)
~/.config/nix/nix.conf ( you might need to add this before installing home-manager, i'm not 100% sure)
The home.nix should be automatically generated, and that's where you put all of your packages. I left a few as an example.
NixGL is needed to use openGL (nixGL lutris for example). It works in most cases, but I couldn't get alacritty or kitty to work. There are some ways to have packages automatically use it, but I still haven't tried them out.
Flake allows you to select the correct nix repo (stable/unstable), appropriate home-manager version, and add outside packages like nixgl. It's technically not necessary, but I wouldn't go without it. Here I'm using the unstable repository, check the relevant docs if you want to go with releases instead.
The equivalent of apt update && apt upgrade is nix flake update && home-manager switch --impure. I like cd-ing into the nix dotfile directory (all of the files are in there and symlinked to ~/.config/ locations), but you can also use command line arguments to point to the flake.
nix flake update updates the package definitions to what's in the repo
home-manager switch install them, and also updates any configs it's managing. The --impure is only needed if you're using nixgl (bad build commands depend on system time).
nix-collect-garbage to force a clean up of unused packages
update: removed nixGL from flake and home, installed it through nix-channel in order to not use --impure during home-manager switch
Thanks! I saved the comment for later.
What advantage do you see in Nix compared to Distrobox?
I personally enjoy DB because of its simplicity.
I just open BoxBuddy, create a new container from the dropdown-list, and then just start using my Debian or Arch container on top of Fedora Atomic for example.
The two main benefits I see in Nix are the reproducibility and the big repo. But in case of the repository size, Debian and Arch (+ AUR) are extremely big aswell.
Are there any other big benefits, that I can't get with Distrobox, but with Nix?
Just as a small side note, I'm no power user and tend to use my PC more like a casual guy.
I haven't used distrobox, so take this with a grain of salt:
reproducibility: if you copy my nix files, the flake.lock will ensure you have the exact same results as me
declarative package management: you make a list of packages and the declarative nature forces you to keep it up to date at all times, that's how you install/remove them. On arch you need to -Syu the package and remember to add it to an installation script (I never did). This also allows for easier maintenance because you don't need to go through random dependencies to find an unused package you've installed (~100 packages on the list == almost 2000 packages installed). If there's a distrobox version of a Dockerfile, you can do the same but it will most likely have the same disadvantages.
home-manager allows you to configure packages (usually not worth it though)
no need to export packages, when you install them they're immediately available in your main distro
combine these and you have an extremely simple setup to distrohop, or work on multiple devices. You can also for example break off certain packages in a separate module, and only install them on a certain machine.
I'm guessing updates are easier, and if it breaks something, you can easily rollback to a previous generation. It will not only revert to the exact same packages you used previously, but it will also revert any package configs it controls. And on top of that it lets you pin a package to a specific version, and upgrade everything else.
cross-platform: you can take your list and install the same packages on win/mac natively. They don't need to run linux in a vm like a container would
less storage used?
temporary package installs. For example I only needed arandr for 30 seconds to set up a new monitor, so I just nix shell nixpkgs#arandr and it created a shell with that package. When I was done I just closed the terminal, and didn't need to think about it anymore. The package was completely removed the next time I ran nix-collect-garbage.
you need a package that's in no repository, but it has a flake with all of the compilation dependencies? You just cd into the repo, nix develop, and you've got a temporary environment with everything you need to start following the compilation instructions
But in case of the repository size, Debian and Arch (+ AUR) are extremely big aswell.
Arch has a lot of packages, but there are some that I had to install through aur which I don't like. Nixpkgs have so far had everything I needed, except for nixgl (although I couldn't get a few of them to work). Also, you can chose between "stable" and unstable repos. Arch doesn't have a frozen version with updates every ~6 weeks, and no other release based distro comes even close in either quantity or freshness.
That's what I can think of for a casual user. There are a lot more benefits for professionals to be honest, and I wouldn't suggest nix at all if home-manager didn't massively simplify the whole process. Getting to those few simple files from above was a massive pain, and it's made even worse by the official nix guide suggesting outdated methods, and most of the support threads being for nixos. With them, you can get going in like 10 minutes even if you don't know anything.
Thanks for your great explanation!
How up-to-date are the packages, compared to Flatpaks?
IIRC, I used Nix a while ago to install a program, which was supposedly hard to build for Linux and crashed all the time as Flatpak. Sadly, the Nix version was almost a year old and also not great.
But I think I'll take a look into it again. I began using terminal apps a lot more and also became a huge fan of image based distros, and I think Nix packages have similar benefits as immutable distros.
How up-to-date are the packages, compared to Flatpaks?
Same or more up to date. It's up there with arch, but some packages are purposely separated. For example the go package is 1.21.7, but there's also a go_1_22 package that's 1.22.1. I'm guessing they're waiting for it to be fully tested, while arch replaced it immediately.
Sadly, the Nix version was almost a year old and also not great.
check here , set the channel to unstable to see the freshest packages
I think Nix packages have similar benefits as immutable distros.
Nix as an external pm has most of the benefits, but almost none of the downsides. It creates an immutable package store, but doesn't cause FHS compliance related issues.
Banned at both my jobs; one for security and the other for breaking consistency.
That last point is often under-appreciated in its importance, especially when dealing with hundreds of servers.
Flatpak is very nice. Flathub is very nice. Flathub’s developer documentation is shit covered shit.
good enough, still prefer the system package manager for most things though
I use it but I hate how much space it uses and I hate when I update flatpaks I have no idea how much is going to download.
And it should only download the diffs, not everything.
@tet@linux Fundamentally, I'm just not interested in containerizing applications on my host computer. If I needed to do that, I'd use docker, so Flatpaks and such feel redundant.
I also don't like that distros like Ubuntu increasingly force snaps via apt, because it results in an unknown factor in case I ever need to troubleshoot.
AUR works for me best in cases when something isn't in the package manager. it's easier to make a custom aur package as opposed to a .deb
"I use Arch btw"
I still prefer traditional packages, but I get why devs of complicated graphical apps with lots of dependencies hate them. As for Flatpak specifically, I'm not super impressed. It's just going to get more annoying over time having more old versions of all their libraries and more and more apps that aren't updating to the latest version so they eat up a ton of drive space and give constant notices to harass the devs, but out of all the major distro agnostic options they suck the least and they're getting better the fastest, which is why I think they've pretty much won at this point. I'm not currently using them, but it's pretty much inevitable that I'll have to at some point, and overall that's probably more good than bad. I think AppImages could have been better if the lead dev wasn't a walking, talking collection of weird hills to die on, but I'm afraid that ship has already sailed.
I mean if the apps are not maintained, they wouldnt work well as distro packages too, would they?
Not really. It's actually pretty common for simpler, unmaintained apps to get small changes in each distro made by the distro maintainers to stay compatible with their current library versions. There's nobody doing that on Flathub.
Probably, but I guess thats the lack of "it has to be updated". Just as distro maintainers do, flatpak maintainers or contributors can do as well, as its often pretty easy.
Sure, they can, and yeah it is pretty easy, but people have lives. They move on. A distro always has someone checking to make sure things aren't broken. On Flathub it won't even break. It'll just waste drive space and start giving users annoying error messages, and there if the maintainer isn't interested in maintaining it anymore the only option for doing anything about it is to fork the whole project, and who's going to do that for something that isn't even really broken?
you dont need to fork a project to update its manifest on github flathub. I think the packaging is very easy and accessible, in comparison to maintaining some Debian repo package etc. Also there are way more officially supported apps on Flathub, so I dont think the lack of pressure to upgrade an app is such a big problem.
But for sure, Onionshare was one of them, and different parts of the community took care of it.
How exactly do you update the github of a flathub package with no one actively maintaining it? Not sarcastic. That is an actual question.
And I'm not worried about big officially supported apps. A better example of the kind of thing I'm talking about is older open source games. Flatpak could be great for games. No distro out there is maintaining a current version of every open source game that has ever been released, but Flathub can, and it could be great. Unfortunately anything that's not being actively maintained is rapidly going to become a 200MB download that whines about security every time you update your flatpaks, even if it doesn't connect to the internet at all. Even if it's possible for any random person to update it, who will?
Of course, this doesn't just have to be about games. There are lots of open source programs out there that just kind of get completed and abandoned. And that's not even bringing up all the closed source software on flathub that definitely won't be updated eventually. These aren't unsolvable problems, of course, but I don't even think anybody working on flatpak even cares.
I dont know who manages "who can maintain", if its only a single person thats bad of course. Good point that should be addressed to the flathub people. There should always be administrative access to some form of elected bunch of people that can then merge PRs or make new people admins.
True about the EOL runtime error messages, I mean they are important but should be possible to mute per app, especially when its offline. This will then just consume more disk space, which is probably fine.
Don't like it, I try to avoid it wherever I can.
purely as an end user i hate how much it downloads with each update and how much it uses the disk space although that's much less of an issue. i know it's solving a real problem and relieving a lot of the headaches of developers maintaing packages for each distro's specific package standard, but it's simply not the software distribution solution for people without at least well enough internet.
i wouldn't use any distro with flatpaks as its main way of delivering software and i would in almost all cases always choose alternatives even if it's outdated. i don't necessarily hate flatpak itself but for me i don't want to spend money on extra data cap and wait 30 minutes for a small update for my game launcher to finish.
the appimage of one of the applications i was interested in was 3 times less than the average flatpak update so redownloading the appimage every time would be better. if i installed more packages yeah the math would be better but it's still wasted data per update no matter how small it actually is. i found out after a while of using flatpak that i wouldn't just update and was stuck with outdated software anyway.
Does anyone know how they handle spoofed malware? I can never figure out whether I can trust the packages from flathub. I always have to check the official website of the particular software first.
Flathub maintainers do not upload anything, they just write a manifest pointing to the official source and flathub does the rest. They also cannot modify it freely, approval is required.
Flathub verifies you have permission from upstream before accepting it. Other than that, sandbox.
I'll always prefer the repositories, but Flatpak comes in handy for applications with weird dependencies where you need to compile everything needed on your own - or outdated 32 bits software.
Ambivalent. I like the consistency between distros and the idea of sandboxing, in practice sandboxing is a pain in the ass and Flatpaks use up an inordinate amount of space for different library versions. However, if I have to use a proprietary application I do appreciate the sandboxing and Flatpak is my preferred install method.
Mostly positive. My encoding utility Aviator can be shipped with a custom community-backed SVT-AV1 fork in the background without anyone noticing any issues like they would if I linked to system SVT-AV1. Flatpak makes this kind of thing easy, and users don't have to think about it.
I usually install Debian Linux on old Chromebooks that have only 16 GB SSD, and then gift them to my cousins or their kids. Flatpacks are out of the question, since pretty much every app I checked is between 500 and 1 GB of size. I only have 7.5 GB of free space in there after the base XFce Debian installation is done, plus 2 GB of swap. I find flatpacks to be space eaters, and I avoid them even on my normal, higher SSD size laptops.
You can probably reclaim at least 1 GB of that swap, maybe even a few hundred megabytes more. I've been running with a 512 MB swap for a while now and the most I've seen occupied was about 150 MB.
Haven’t had issues, elementary uses them for system apps
I really like them. They give us a reliable application that doesn't depend the distro building a version for specific platform. For example if the newest versions are compiled for Ubuntu 24.04 but you're on 22.04 it might take a while to get the update.
It does come at a cost though, it'll have to package all the dependencies for 24.04 in a layer of the package so it'll take a long time to start up and take a lot more memory than necessary.
This is mitigated by flatpaks using same base for their application (like Ubuntu with Electron) but it still isn't the same as just starting up a proper apt program.
I really like it since we can have a modern version of a program for small distros and in general the barrier to entry so much lower so companies can't just say "oh we can't support all Linux distros, not feasible".
Aur you compile yourself for your own distro instead of it being done already by apt and the like.
Nix is a super cool since you can just setup and configure pretty much everything so that you just press "install" and you'll have your Gimp, VPN and whatever apps all done for you. You'll have to do some heavy configuration so programming knowledge is not necessary but really helps.
I wish more apps where officially supported, instead of saying it supports Linux and providing a .deb. Good thing the community provides unofficial flatpaks at least.
A lot of people seem to complain about them, but I really like them. I've even started using them over the AUR for some things now. I like that they keep certain things like Steam a lot tidier, and I like being able to see and control permissions and settings for everything all in Flatseal. The main downside I guess is that they use up more space by downloading dependencies for each app individually which is kind of redundant, but for me I've got a pretty big SSD in my laptop so it's never caused me any trouble. I could see how it could be a problem for someone with limited space on their system though.
Generally I tend to go Flatpak/AUR as a first choice, Appimage if I really need to, and Snaps never lol.
Get Job done but remember don't use it for Browser and Text Editor. It will make you suffer.
I'm using it for my browser on Steam Deck and it's fine. You just have to give it the right permissions.
Yea, I know but still some time it doesn't interact with system.
Sure, if you don't give it filesystem permissions it won't be able to download files and save them to disk.
Wow Cool
Edit: NVM and Sorry bro, I was feeling kinda annoyed that's why I comment this but actually my problem was GNOME extensions integration.
It is awesome
Doesn't work properly, apps are bigger and don't always apply GTK themes. I also can't easily edit the desktop file to edit the icons. I therefore only use it as a backup when I can't find an app on the AUR or office repositories, which is very rare.
"Dont ask yourself if it works, but how it works"
For editing desktop entries, copy it fron this strange directory ~/.local/share/flatpak/exports/share/applications/ to your normal ~/.local/share/applications which will always override the others.
Flatpaks are great. I install my core os and gui with the base package management. All my user side packages are Flatpaks. I then use Flatseal to lock down and modify Flatpaks as needed. What's great is running programs like wine without installing a ton of dependencies and then locking the install from parts of my computer I don't want it to have access to.
What package manager do you currently use?
Depends. Ha ha
RPMs at work, Debs for my RaspberryPi devices. PacMan (Arch) and Flatpaks for home.
AUR is similar to flathub in that most packages aren't thoroughly checked. Except for the packaging guidelines which usually have to be followed. I'm not sure how in depth nixpkgs or other distros check the source of packages of new maintainers.
Flatpak runs on all distros and supports sandboxing, which makes it a great addition to all distro repos. AUR can cause issues with dependencies and unmaintained packages, and the make file should be read since it's run with root privileges. Additionally the AUR only works on Arch Linux. Breakage isn't a risk with Nix and it's seamless rollback, but has to be installed deeply into the system (/nix)
My personally preferred package manager for most GUI apps is flatpak. Nix is great because it allows to install packages declaratively.
Edit: NixOS -> Nix
Except on NixOS, where it's possible to install packages declaratively.
Why only use nix on nixos?
You're right. I've never tried installing a wm with Nix on another distro, but it should be possible.
Half of the packages on my system are debian, the other half is nix. It's a really good combo, and home-manager makes it easy.
Flatpak is why i moved to Debian, Running a Stable OS with the latest packages have made my Linux Desktop a full replacement for Windows, MacOS and Rolling releases.
On the one hand I like the basic idea, on the other hand I think that some fundamental problems aren't fully solved yet. There big use case are passkeys and direct password manager integration – neither mesh well with the idea of software that isn't allowed to talk to most of the system.
I'm certain that this will be resolved at some point but for now I don't think Flatpak and its brethren are quite there yet.
passkeys
Dont know, may already work? Keyword adaption
direct password manager integration
Not sure what that means, but probably native messaging, a biig missing portal.
Flatpak has an Inter-process-communication permission, so software could absolutely be opt-in allowed to talk, while keeping security for the rest. Apps cant see each others ~/.var/app/org.app.name/ storage though, never.
The problem with Flatpak is that for me I would only use it to sandbox propietary apps, and most of these are not officially supported, so there is almost always something broken, like screen sharing, etc.
The sandbox can be very cumbersome when there is not a way to break out. I'm thinking specifically of command line tools for developers. You can poke holes in the sandbox to access the filesystem, but the moment you want to run an executable it won't let you.
Flathub doesn't accept CLI tools (unlike the Snap store)
Other way around, accessing command line tools. As far as I know, there is no sandbox setting to allow access to execute commands directly on the host system.
I never ever will use a flatpak or snap or whatever "application". I'm using good old .deb package.
I love the idea and the philosophy behind ! I have no trouble with them for now, one click install perfect.
However I’ll never use it for programming and I don’t understand why people use vs code flatpak or other coding app, because the app is contained and cannot interact with your system.
I installed PyCharm via flatpak. I don’t appreciate that I can’t access vim via the IDE’s terminal, and so far that’s all I really have to say about it. I like that things are sandboxed, and I think maybe this wasn’t the kind of thing I ought to have used flatpak for.
I have to agree. I tried some of the JetBrains IDEs from Flathub, and I switched back to the regular JetBrains Toolbox versions.
Have you tried granting additional permissions via Flatseal?
I haven’t, and prior to this post I wasn’t even aware of flatseal. I haven’t been doing too much dev work on my home machine lately, so fixing this gripe is kinda low on my priority list, but I’ll keep that in mind as an option if I ever get around to it. Most likely, though, I’ll probably just go back to the tarball. I really do think that I picked a less-than-ideal use case for flatpak on this one.
I didn’t want to containerize every installed app. Switched to Arch and don’t have to worry about it.
It's alright
I like it but I would prefer it to be more restrictive out of the box. Such as have apps declare a list of urls the are permitted to contact , a browser could have * .
I'd like a more granular filesystem list too more akin to apparmors were each file path needed is explicitly defined, in some cases you would need a wildcard or a directory but for most apps this could be done.
I like it, it's good for desktop apps but I LOVEEEEEE nix, if there was a graphical box distro I think it would beat everything else out of the water. Full reproducible builds is not something to sneeze at
I usually prefer not to use them, but they flatpak for Prism Launcher comes with all versions of Java preinstalled which is convenient because I play verious versions of Minecraf, other than that I try to use xbps as much as possible
I think Flatpaks are great for applications like Firefox, Steam, etc. where dependencies or delay in package distribution due to building multiple versions can be a problem.
However, there are many situations where Flatpak's sandbox can be more detriment than helpful, if the application wasn't developed with that in mind. It's not a silver bullet for everything.
I dont use insecure tools to install software
I click install, app launches and I don't need to deal with dependency hell for it. (I like them)
I personally think it is trash..
Just putting "personally" in front of an unfounded statement doesnt make it better
Why it is unfounded?? The sandbox is still a lie (flatseal is impractical security since it makes you become a security researcher overnight), apps are not properly filesystem-unveiled. But a new level of complexity.
Could you explain "filesystem-unveiled"?
Apps are not updated to support portals for "compatibility" or just lack of maintenance. Flatpak needs to follow their approach if they want to have many apps being supported.
Desktop Linux doesnt have the marketshare to dictate that all apps need to adopt portals. In the meantime, flathub.org has a rating system and verified checks, this is simply not well shown in KDE Discover and not sure about GNOME software.
Could you explain “filesystem-unveiled”?
Means its filesystem access is restricted.
For example, chromium on OpenBSD use the unveil(2) system call to restrict itself to /tmp and $HOME/Downloads .
Many popular flatpak applications have filesystem=host. This is equal to restrict all filesystem access and then unveil the whole filesystem.
Apps are not updated to support portals for “compatibility” or just lack of maintenance. Flatpak needs to follow their approach if they want to have many apps being supported.
Desktop Linux doesnt have the marketshare to dictate that all apps need to adopt portals. In the meantime, flathub.org has a rating system and verified checks, this is simply not well shown in KDE Discover and not sure about GNOME software.
If they can't even enforce portals, flatpak is a new level of complexity.
So I said it is trash.
Good that Chromium does that, but this means if it doesnt use portals many things will be broken.
These directories are blacklisted: /lib, /lib32, /lib64, /bin, /sbin, /usr, /boot, /root, /tmp, /etc, /app, /run, /proc, /sys, /dev, /var
Exceptions from the blacklist: /run/media
These directories are mounted under /var/run/host: /etc, /usr
Portals need a change in the app code that is not huge but differs from other packaging formats on any distro and OS. So it sucks that its so slow but that has a reason.
The host access is not actually everything
Not as restrictive as chromium's unveil.
For home it even restrict to the downloads folder, not accessing the whole home directory.
Yes that only works for browsers and would completely break image viewers, document editors etc
They’re great on certain desktops, like Fedora’s Atomic Desktops, but you usually have to work around Flatpak specific issues. On NixOS there doesn’t seem to be a declarative way to install them.
I love flatpaks and flathub. They're amazing for GUI apps, though there are still a couple of wrinkles that needs to be ironed out.
I would really love if it was better with regards to cli apps and developer tooling though. As someone that uses a lot of TUI apps that seriously limit how much I can use flatpak.
Thicchub
I like them sonce they're easy to install and you can update all Flatpaks at once.
But I don't likke the paths and run commands. Very unintuitive.
Flatpak works most of the time. Nix works almost all the time (except when stuff happens like the download fails)
Flatpak is free to assume anything about your system which is sometimes not compatible with NixOS
It's pretty good for desktop apps, but it doesn't provide CLI applications, so I still have to rely on the AUR. There are some issues with it, but overall I think it's the best solution we currently have. And it's very easy to use, which is great for new users and it will become important if Linux continues growing like this.
It's the easiest solution to packaging software for Linux that doesn't mean it's good, In fact fhe way no dependencies are shared absolutely wrecks my hard drive and makes everything super long (downloading, updating, etc...).
Where it shines is security but to be honest do you really need an open source app to be in it's own secure sandbox?
I vastly prefer nix and I wish packaging stuff for it was easier.
It still takes forever to update compared to more traditional package managers
I never notice any update times, as the default in Fedora is to auto-update (I think?). Everything is just always up to date.
Edit: coming from ten years of Arch, this has significantly reduced my time fixing things related to an update 😆
Yeah I disabled those because my Internet is shit. I'm also on fedora and when I update, the 3 flatpak apps that I have installed take as long as my entire system to update. But I get it doesn't make much of a difference if it just happens in the background
As other have pointed out, saying that "no dependencies are shared" is a very missinformed take, given that sharing dependencies as runtimes is an integral part of Flatpak's structure. But what makes it even funnier and more obvious that you don't know what your talking about, is that you than cite Nix as something you "vastly prefer" when Nix actually deals with dependencies in a very similar way to Flatpak. From the official site:
You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”.
In both Flatpak and Nix, apps will only download a different version of a dependency when they need it. This ensure that, instead of breaking, the app will work the same on any system (be it an old stable Debian or a bleeding edge Arch system), without requiring devs to create monkey patches that they have to maintain as things evolve. It has the potential to immensely reduce the burden on app devs and maintainers, and make it a lot easier to make apps for Linux.
The picture is too big.
Where's that Chris Pratt meme? --
I don't know what that is and at this point I'm afraid to ask
Flatpak is a project trying to fix many things at once
make apps that work on every distro
thus have apps officially supported by the devs, unlike distro packages mostly
sandbox apps with an android-like permission system with a rating system
use modern standards like delta-downloads, deduplication and BTRFS compression to save storage space
make everything nice and user friendly
What's not to Ike? These systems' development has been long overdue.
They are awesome but personally I don't use them. I have an obsession with memory management. Flatpak apps don't share libraries so they get chunky at times. This shouldn't be a problem for most people. It's a personal problem.
Man this Missinformationen is hard to squash. Yes Flatpaks absolutely share libraries. These are called runtimes and are shared between all the Flatpak apps that use the same version of it. You will only get more than one version of a given runtime if some apps need this other version. For most runtimes that I know of, most only have 2 currently maintained versions, so I almost never get more than that on my system (and when I do, app devs tend to update their apps shortly after so that they're using a maintained runtime). For example on my system where I mostly use GTK apps, I only have two versions of the Gnome runtime (44 and 45). And even when you have more than one version of a runtime, they get deduplicated, so even runtimes share parts between them.
It’s bloated. Not as bad as snap though.
xbps for the win
Everything I've gotten as a flatpak has been borked in one way or another. I only use it if there is literally no other option available.
I'm a bit "eh" on flatpak. The only benefit I see is that it's sometimes more up-to-date than what I can get from an LTS package repository. As a heavy CLI user they force me to find and click icons which is irritating (yeah - I know about flatpak run something.I.always.forget but that's even worse somehow).
I've hit occasional issues with applications being too locked-down. Like with Darktable only being able to see things in $HOME/Pictures. But I keep my photography work in a different location so it can't see it. I had to jump through some odd hoops to fix that. Not a problem of flatpak itself per se but something you can expect when dealing with package makers.
I fall back on flatpak if the version available through the standard package manager is too out-of-date for my liking. Other than that I can't be bothered.
EDIT: Okay - for people who think they're being "helpful" by telling me that "aliases are a thing" just stop. I'm not going to workaround a broken system. I'm going to use another one that isn't broken (or less broken).
If you're going to use flatpak from the command line you're definitely going to need to start aliasing those flatpak run commands. It's still annoying, but at least that way it's only annoying once.
No. I'll use snaps before I start maintaining a bunch of aliases that I shouldn't have to. It's a flaw in flatpak.
Well okay. I agree that it's a flaw in Flatpak, but if you think adding a single line to your .bashrc is some kind of unbearable burden that you shouldn't have to endure and you're willing to make your own experience far worse just to avoid it, then I think you're being a bit silly. I mean, be as silly as you want. Don't let me tell you what to do. You are being silly though.
if you think adding a single line to your .bashrc is some kind of unbearable burden that you shouldn’t have to endure and you’re willing to make your own experience far worse just to avoid it, then I think you’re being a bit silly.
I'm making my experience much better actually? Stop justifying flatpak's flaws because you like flatpak. It's flawed. Deal with it.
I don't even like flatpak very much, I'm not currently using it at all, and I already agreed it was flawed right at the very start of the quote you cut off there. I was just trying to be helpful. Sorry. Won't happen again. If you want to make things hard for yourself and no one else as a weird self-defeating protest then don't let me stop you. Don't pretend I didn't do the thing I just did and you had to edit out of the quote though. That's a real dick move, frankly.
If you want to make things hard for yourself
I'm sorry - but WTF? What part of me "doing something that is easier for me" also "making things hard for myself?" Talk about a "dick move"...
No snaps are insecure on other distros that Ubuntu, as they are only isolated using apparmor. Also they are nonfree by design, just no.
They're not insecure. No more so than when I install a package via apt. No more so than when I download some code and compile it. This is propaganda.
They are less secure than flatpaks and there was malware on that store
You think the unverified flatpaks which choose their own permissions are "safe"?
You have the option to add the verified subset only, and you can always check permissions before starting an installed app, and it will not start before.
I'm sure everyone does that.
Yeah with Snaps you also have unofficial packages, no apparmor at all and a mix of foss and nonfoss apps.
But with flatpak these things are accessible and Flatseal is very commonly used.
"Already perfect" vs. "Has the foundation to fix it easily" distros could easily allow to add the subset or improve the permission system.
Do... Do you think I'm claiming snaps are better or something? I'm saying they're much easier to use and I don't give a shit about walled-garden BS. I don't want my laptop to be like my phone. I want to install an application and I want it to work. Flatpaks are fine - they just made a really stupid decision about how to run them from the CLI which is 90% of the time where I launch programs from.
Do you have a better approach for running from CLI? Apps need exact names I guess, and the system is exact.
regarding the sandboxing, all the negatives are present with none of the benefits, wish they'd just rip that shit out
if you want to run software you don't trust, firejail it or get it's snap
My totally unscientific opinion (with a double-your-money-back guarantee!):
I'm not crazy about either Flatpak or Snap for that matter as there's so much backend baggage for both as well as certain hurdles regarding privileges and access to the file system (somebody please correct me if I'm wrong or working with dated information.)
My other completely prejudiced, unfounded bias against Flatpak is that it appears to have been adopted by RedHat as "the one true way," and what with IBM's/RedHat's behaviour anti-FOSS behaviour lately, plus I've almost always have been an apt user, I find it a pill hard to swallow.
Me, say what you will about the security issues and its other flaws, but I like AppImage.
AppImages are actually more secure than flatpak. At least it has a way for devs to sign them and users to verify them.
Flatpaks follow the concept "losen the sandbox as much as needed to make apps work". This sucks, in constrast to android, but its needed.
So you shouldnt need to edit anything via Flatseal/KDEs settings, if you want to make apps work.
Flatpak is default on OpenSuse too, even more as they use Flathub instead of the Fedora Flatpaks repo. RHEL is just trying to get some money and stop people from using their work, as they need to make money.
Honestly it should be normalized that people on FOSS do weird things to make money. Fedora is RHEL upstream, so RHEL is not stealing any code, just take what Fedora does and wait a bit until its stable.
Appimages are completely flawed and as an apt user you should not like to use them, at all. This post of min may give some infos, I will update it soon.
And speaking of completely flawed, your link doesn't work.
Anyway, thanks for berating informing me about AppImage but it's the closest thing on Linux to app bundles which IM
Thats a lemmy problem, copy the link and remove the lemmy part
Thats a lemmy problem
Hmmm...my link in the previous post works. More proof of why Linux has never really taken off with the non-spectrum general public. I guess just following format ([words](https://your.lousy.link)) or -- god forbid -- you select a word, click the link button and paste just isn't esoteric enough...?
In any case, I see that you edited your post to cover your tracks fix Lemmy's error.
The error is that I dont use https as every browser defaults to that, but lemmy links it internally. I fixed it. Stop annoying me, my comment was constructive and trying to help, so whatever this is stop it.
Best of the three major agnostic package formats. If it brings more focus to Linux development, I don't see how it can be a bad thing. A bit more space needed but for most setups this is a non-issue
Plus, being able to sandbox user space applications, which previously had free reign, is nice.
Sandboxing isn’t 100% there yet, but it’s come along way.
Yeah duplication of running libraries is also a RAM/CPU resource issue but for modern well resourced machines probably not noticable. It is an issue when scaling down to low powered / old devices though. Like, running a web browser which runs in it's own sandbox with duplicate libraries running is going to have noticable performance differences compared to a non-sandboxed program running native libraries on a low RAM or low CPU system.
That's not to say Flatpak isn't a good solution; and all the agnostic package formats have the same issue compared to non-sandboxed apps. Plus the added security issues and stability on bleeding edge systems is good.
I love flatpak. It makes it easier for Linux to become mainstream.
As a non-technical user: fucking love it.
As a semi-technical user: I also fucking love it. It gets out of the way so I can focus my time on my work and not OS maintenance.
@tet its great because you can listen to people whine about it now instead of systemd
The two whines are not mutually exclusive. ¯\_(ツ)_/¯
@kingmongoose7877 until someone tells me another way to run 2 python apps one which requires python 2 and one which requires python 3, on the same system, which is EASIER than installing a flatpak, im gonna maintain that they have a use case, even if they aren't idealized package management as we dreamed of
Easy, tiger. I think you misinterpreted my original reply.
I meant the whining about the two (systemd and flatpak) isn't strictly OR but may be AND. Have a nice day.
I think pyenv would be the appropriate tool for doing a native install. And of course when it comes to CLI, Flatpak isn't really for that.
@pingveno i think that two things get conflated. 1. flatpaks and appimages, snaps, have some niche uses for obsolete software and maybe some other edge cases 2. because the two major standards are backed by dumbass corporate entities, they have been promoted as the universal solution to everything that will revolutionize linux 3. the real thing everyone hates, is these stupid companies trying to get rid of a beautiful package management architechture so they can enshittify linux like windows
I think their uses extend beyond obsolete software. In particular, trying to get updates out to a wide variety of Linux distros has generally meant a tradeoff between "move fast, break things" and "move slow, never change". Flatpak gives you a stable set of libraries to work with and the ability to run multiple versions of those libraries at once. Linux package managers have a place, but their sheer proliferation means that for most applications to reach all desktop Linux users, they have to go through something like Flatpak for distribution.
Uh. Python is like the worst example for this, conda/mamba?
Cheese with your whines?
You should use WINE only through Flatpak btw
🤦♂️
Speaking of which, didja hear that for the upcoming Easter holiday, Amazon is offering a special gift basket of northern Israeli cheeses.
They're calling it Cheeses of Nazareth.
You have received the Dad Joke Gold Star
Are you trying to start a war? Hopefully no one mentions wayland vs xorg else it might go nuclear
@squid_slime let me install this flatpak of kde wayland on my oracle unbreakable kernel running under redhat enterprise
That's like two keystrokes in emacs.
It's fantastic, for two reasons:
I really like the idea of a universal app format and flatpak seems the best for it. And flathub has been great as a repo.
The idea of separate system layer (with traditional packages) and user app layer with flatpaks seems like the way to go. Perhaps even immutable system layer.
I think it's a good way for people to release software for Linux without having to deal with specific distro stuff (which historically has pretty much been "just provide a .deb for Ubuntu and a .tar.gz for other people to figure out").
I'm hoping that it pushes for more people porting stuff to Linux because it's a single target that gives you access to Steam Decks, Chromebooks and desktops.
I don't think it makes sense for things that aren't desktop applications such as servers or libraries, just because those tend to be open source, don't need to be that up to date and benefit from tighter system integration. I see it as something that sits on top of other package managers rather than replacing them.
For Flathub? Eh, if they turn out to be bad we can just all move to another server, we're not snap. :P I'm willing to bet that someone has already made a flatpak repo for Citra and Yuzu.
I personally prefer to use Flatpaks over traditional packages because of the added security, sandboxing, and overall convenience of not having to deal with dependency hell. It's especially nice being able to have proprietary applications sandboxed from the rest of my system without worrying that Steam is snooping on my 'super-important-tax-documents'.
Flatpaks are also very useful for having up-to-date packages on distros like Debian, and it's derivatives. People can still use their preferred distro without having to worry about not getting a certain update, feature, bug fix, etc, for their applications.
Being able to restrict what applications have access to is a game-changer for me. A lot of times Flatpaks, by default, have very lenient permissions, and with the use of Flatseal I can restrict it to my liking. Worried about Audacity's telemetry?? Turn network permissions off. Now, not all applications will work well (or at all) without internet connectivity, but for applications like Audacity, it works great!! Flatpaks can also be very useful for developers.
That's not to say that Flatpaks are without their fair share of issues. Are they bloated?? Yeah, and although it's not an issue for me, it may be for some people. Desktop integration is, meh. Themes, and fonts don't always integrate the best. (A while back there were issues with Flatpak's sandbox, but I won't touch on that because I need to refresh my mind on it, and it was actively being developed to fix those issues so it possibly isn't even an issue anymore.)
Overall I think Flatpaks are absolutely wonderful.
People need to realize that before Flatpak, distributing a small-time Linux app was a nightmare. Appimages were your best option if you wanted to avoid distro specific builds, PPAs and AUR, etc. Ever since packaging 2009scape on Flathub I haven't looked back. It auto updates. People can find it from software centers. It works on all distros. It connects straight to upstream's CICD. It even forced us to adopt XDG compliance so we could sandbox it better.
Yes, Flatpak has downsides like the download size (on disk it doesn't matter because it gets compressed and the runtimes are shared, same as literally any other package manager). But overall, I hugely welcome it over the options we had before. Much love to the Flatpak and Flathub devs!
So YOU are the one to blame for my latest Runescape addiction relapse! I only learned of the project because I stumbled on it while browsing flathub
LOL
Flatpak shooould just download the diffs
They should, actually. Google released a tool for downloading only the diffs on binaries a few years ago
They use ostree afaik, so "they should" as in "I think they do"
And they did, with bsdiff, an algorithm invented awhile ago. I wish system package managers carried this/weren’t actively dropping their implementations :(
As a generalist I have to learn many concepts and dont have time to delve into any one that deep. Flatpak works and isnt proprietary like snap so I enjoy that. My recent debian+kde installation works well with if. Open discover and install flatpaks as much as you wish.
Is it true that Snap has proprietary server?
Exactly, proprietary.
Exactly, proprietary.
if the only way to use the open source client, is with a closed source server, is it really open source at all? The platform is the server.
This isn't threatening in a way that Canonical would hack my computer with it. It's threatening the Linux ecosystem. They created a distro agnostic package manager which is solely controlled by them. In other words they want everyone to use Snap and then vendor lock in everyone into it. "embrace, extend, extinguish"
I honestly wouldn't care if snap was both Canonical proprietary and Ubuntu proprietary but this M$ like strategy sucks.
I definitely prefer it over Snaps or appimages. Straight-forward to update, and Flatseal provides a nice GUI to control permissions (if needed). Themes may not work properly, but whatever, not a big deal for me.
The distro's repo is always my go-to. If it's not available there, then flatpak, and I'll use appimage under duress. If that doesn't work, I'll figure out a different solution.
Yeah I'm not a huge fan of Appimages because I don't like that to update it you usually have to go find and download the file again, instead of just getting it from a repository. They feel too Windows-y to me in that way.
I use them for some things and I think they are fine. Mostly apps that are kinda messy and I want to keep them and their atrocious dependency tree away from my base system. I also like to use them for proprietary apps or apps where I actually want to use the sandbox. Other than that I prefer native packages 99% of the time.
Flatpak is slower to update than pacman, the cli interface just doesn't feel good to use. There is the weird naming, no real way to get a dependency tree, can't hide those annoying eol messages even for apps that I specifically don't want to update. Another thing is that not every app was made to run in a sandbox or it is just more difficult to use sometimes. A lot of people tend to cite ide's, but in my case I was having issues with the steam flatpak. Running games with steam was fine, but anytime I wanted to hook up something third party eg: mods, cheat engine, etc. Doing so in the flatpak either required some tinkering around the sandbox or straight up didn't work.
I feel like that last sentence sums up the whole experience. If you just need to point and click and have it work. Flatpak does that amazingly. If you need any kind of integration with other things, expect problems.
Edit: just wanted to add that, the whole point and click and work is fine for 99% of people which is why I and many others choose to use it.
Yeah, I also had apps like Steam native break once or twice due to library updates (such as Mesa) - the downside to rolling distros. However, the Flatpak version continued to work so now I only use that. I don't use mods though.
I'm now gravitating towards treating my rolling distro a bit like an immutable; more Flatpaks, avoid user repositories.
While I don't think flatpak shouldn't replace traditional packages, I still like it.
Flatpak apps just work most of the time, they work without issues and are often very up to date. The sandboxing does have benefits because no apps interfere with it, the problem is that it doesn't work super well with other apps, sometimes the theming is off, and it doesn't work well with other apps, installing apps takes much longer, and it isn't as easily started from the command line.
Edit: typo
In my opinion, with a debian style distro as the example, apt-get should be used for syatemwide stuff. Individual users can go for flatpak.
Flatpak is fantastic for end-user GUI applications
Flathub is also great, but the fact that it's really the only repo that flatpak maintainers are using concerns me. I know I'm dreaming, but I would love to see some sort of federated or P2P hosting
Its a solution to one of the typical Linux issues. Its a step toward overcaming the fragmentation of Linux package managers.
I don't personally like it too much, I prefer the distro package stuff, but I understand the app developers cannot manage a plethora of different package formats.
Distro maintainters should, but its clearly more and more a massive task for different distros to keep up with the amount of apps out there.
Also, npm, pip and the various "packaging" ways existing add to the chaos.
I see distro package managers converge toward providing basic packages for the general system and some other solution like flatpack to provide additional stuff.
I think it would be wrong for flatpack/containers to replace package managers as well, it's not their scope.
IMHO doing this would be suicide for most distros.
There are only so many ways you can make a basic system and the distro scene is already saturated by various interpretations of "basic".
A distro needs to offer more than the basic system and a huge part of that added value lies in its packages (and by extension package manager).
I love them. They make the immutable distributions possible.
We need to stop with the idea of shared libraries, it's nice on the paper but in practice you only save a bit of disk space and it's a pain for developers to package for different distributions.
Distribution packages are great for core components of the system, or utilities everyone needs, but for end users applications something like flatpak makes more sense. This way it can be packaged by the upstream developer for all distributions, and sandboxing adds a layer of security. You wouldn't install an app that have all permissions on mobile, why do it on desktop?
As a guix/nix user
Please, no more copies of the same dependencies 10 times over. My hard drive is tired.
Lol this ^
Some of the under-the-hood implementation of Flatpak irritates me, like why the hell are we installing software in /var? Using it with the terminal is a pain because of the org.something.SomeThing shit it does, and I think Flatpak gives you all the drawbacks of app sandboxing with none of the benefits. It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn't see anywhere I wanted to put my games library. That needs to be fixed.
That said, I think it's the better of the three all-distro package managers, it's got a central repository and package manager unlike Appimage so it's a place to publish and get stuff, and it's not tied to Canonical so it's obviously better than Snap.
https://github.com/trytomakeyouprivate/flatalias
Try this script I wrote and help improve it!
if you want to change app permissions, use Flatseal and add the needed directory. This is very easy. If it is something all users generally need, open a bug on their repo.
Installing a separate program to make the first program work the way it should in the first place, and opening bugs in repos, is abolutely 100% things end users are willing to do.
KDE has flatpak settings included, GNOME is doing their thing with unix philosophy and all. Flatseal works fine.
As I said, you should not need to edit those settings, maybe you need to, and if it generally makes sense (for example GNUmeric only has documents access, nothing else) this needs to be fixed.
Will not happen often for common apps
Reminds me of this XKCD.
The state of flatpak permissions currently is like that. They can never read each others storage, much like on Android with
/storage/emulated/0/Android/data. So it you keep stuff stored inside these apps its safe.Until they can use portals, many have permissions to read/write everything
That has been fixed with the introduction of Portals: https://docs.flatpak.org/en/latest/portal-api-reference.html
I use it as the primary way of installing apps on my Steam Deck, as well as my Ubuntu PC (I also use Snap over there). The apps installed via Flatpak just work, so I have nothing to complain about.
I prefer Flatpaks because it's a nice easy way of getting software without the chance of broken or missing dependencies for a program.
Much better than Snaps, snaps is flatpaks but MUCH worse and slower.
They have their uses. In particular they're useful for easily getting applications your system repositories don't have or getting more up to date version of applications. Downsides are certainly the space all the redundant dependencies take up and the sandboxing can be a PITA especially if you have an application that needs to run another application. Overall I think they're the best "third party" package system available but they're not great.
👍
I got sick and tired of the AUR for the simple packages so I started using it for most things I would use the AUR for, and I'm very happy with it. I think some packages have issues with default permissions - I was wondering why 86Box would forget my hard drive images but then I realised the permissions on my home folder weren't set properly - but that can be sorted anyway.
very cool and awesome
Great to me. My personal favorite piece is the portals system built to make permission access easier but transparent to the user. It also helps more pieces of the desktop space interoperate (for example use the system defined file picker instead of needing to ship your own).
My main problem with Flatpak is that it hands temporary /var/run/1000 file links to programs instead of real filenames. That would almost be bearable, if Flatpak also took responsibility for keeping those links from breaking sometime after your next reboot.
If I say "here is a path that an app is allowed to use", flatpak should just allow an open() in there to work. It should not lie about the name of files in there. An app should be able to open a file there, remember that name, and count on being able to access it again in the future.
Other than that, Flatpaks are the bees knees. I love finding something I want to do, finding a solution in the flatpak store, and click-click I'm already doing shit. Finding Windows software is absolute garbage next to this.
Thats basically persistent portals. Would be possible if Distro portals had a button to give the app permanent (static) permission to that dir.
Would indeed be useful and not hard to implement. In the portal window just add a button "permanent" which does
Want to open a discussion or Feature request for your desktops portal?
I only used AUR for a few packages (<5 at a time). It's to be avoided and only used if the other options are a massive pain (unless it's an official package).
Then I left Arch and eventually landed on MX. During that time Nix with home-manager has slowly replaced flatpak, and I don't even have it installed anymore. Nix is better in every way, except for ease of use.
Flatpak has great gui integration (for gui tools). You can click through everything, and the updates are unified. It usually works perfectly fine if you just need to install a few programs.
With nix, there's a lot more setup, but there are many benefits. You end up with a list of packages, and that's really useful because you can take a fresh install, install nix and home manager, and then run a single line to reinstall everything. You can rollback updates, pin specific versions, install packages from a repo (if it has a flake.nix with outputs), and also configure them. I'm using the unstable branch, and it's giving me bleeding edge packages on Debian. And there's no risk of outdated system libraries, like with flatpak, because it provides everything.
That all sounds great, thanks!
Do you have any tips for an "easy" start, where everything is already pre-configured?
Nope, and that's the worst part of nix. I'm actually planning on writing a short startup guide, but I need to solve a few more issues first.
But, this should help you out until then:
The home.nix should be automatically generated, and that's where you put all of your packages. I left a few as an example.
NixGL is needed to use openGL (
nixGL lutrisfor example). It works in most cases, but I couldn't get alacritty or kitty to work. There are some ways to have packages automatically use it, but I still haven't tried them out.Flake allows you to select the correct nix repo (stable/unstable), appropriate home-manager version, and add outside packages like nixgl. It's technically not necessary, but I wouldn't go without it. Here I'm using the unstable repository, check the relevant docs if you want to go with releases instead.
The equivalent of
apt update && apt upgradeisnix flake update && home-manager switch --impure. I like cd-ing into the nix dotfile directory (all of the files are in there and symlinked to ~/.config/ locations), but you can also use command line arguments to point to the flake.nix flake updateupdates the package definitions to what's in the repohome-manager switchinstall them, and also updates any configs it's managing. The --impure is only needed if you're using nixgl (bad build commands depend on system time).nix-collect-garbageto force a clean up of unused packageshttps://search.nixos.org/packages makes searching for packages a lot easier
https://mynixos.com/search?q=home-manager+ same, but for finding options to configure packages through home-manager
Comment if you need help
update: removed nixGL from flake and home, installed it through nix-channel in order to not use
--impureduringhome-manager switchThanks! I saved the comment for later.
What advantage do you see in Nix compared to Distrobox?
I personally enjoy DB because of its simplicity.
I just open BoxBuddy, create a new container from the dropdown-list, and then just start using my Debian or Arch container on top of Fedora Atomic for example.
The two main benefits I see in Nix are the reproducibility and the big repo. But in case of the repository size, Debian and Arch (+ AUR) are extremely big aswell.
Are there any other big benefits, that I can't get with Distrobox, but with Nix?
Just as a small side note, I'm no power user and tend to use my PC more like a casual guy.
I haven't used distrobox, so take this with a grain of salt:
reproducibility: if you copy my nix files, the
flake.lockwill ensure you have the exact same results as medeclarative package management: you make a list of packages and the declarative nature forces you to keep it up to date at all times, that's how you install/remove them. On arch you need to
-Syuthe package and remember to add it to an installation script (I never did). This also allows for easier maintenance because you don't need to go through random dependencies to find an unused package you've installed (~100 packages on the list == almost 2000 packages installed). If there's a distrobox version of a Dockerfile, you can do the same but it will most likely have the same disadvantages.home-manager allows you to configure packages (usually not worth it though)
no need to export packages, when you install them they're immediately available in your main distro
combine these and you have an extremely simple setup to distrohop, or work on multiple devices. You can also for example break off certain packages in a separate module, and only install them on a certain machine.
I'm guessing updates are easier, and if it breaks something, you can easily rollback to a previous generation. It will not only revert to the exact same packages you used previously, but it will also revert any package configs it controls. And on top of that it lets you pin a package to a specific version, and upgrade everything else.
cross-platform: you can take your list and install the same packages on win/mac natively. They don't need to run linux in a vm like a container would
less storage used?
temporary package installs. For example I only needed
arandrfor 30 seconds to set up a new monitor, so I justnix shell nixpkgs#arandrand it created a shell with that package. When I was done I just closed the terminal, and didn't need to think about it anymore. The package was completely removed the next time I rannix-collect-garbage.you need a package that's in no repository, but it has a flake with all of the compilation dependencies? You just
cdinto the repo,nix develop, and you've got a temporary environment with everything you need to start following the compilation instructionsArch has a lot of packages, but there are some that I had to install through aur which I don't like. Nixpkgs have so far had everything I needed, except for nixgl (although I couldn't get a few of them to work). Also, you can chose between "stable" and unstable repos. Arch doesn't have a frozen version with updates every ~6 weeks, and no other release based distro comes even close in either quantity or freshness.
That's what I can think of for a casual user. There are a lot more benefits for professionals to be honest, and I wouldn't suggest nix at all if home-manager didn't massively simplify the whole process. Getting to those few simple files from above was a massive pain, and it's made even worse by the official nix guide suggesting outdated methods, and most of the support threads being for nixos. With them, you can get going in like 10 minutes even if you don't know anything.
Thanks for your great explanation!
How up-to-date are the packages, compared to Flatpaks?
IIRC, I used Nix a while ago to install a program, which was supposedly hard to build for Linux and crashed all the time as Flatpak. Sadly, the Nix version was almost a year old and also not great.
But I think I'll take a look into it again. I began using terminal apps a lot more and also became a huge fan of image based distros, and I think Nix packages have similar benefits as immutable distros.
Same or more up to date. It's up there with arch, but some packages are purposely separated. For example the
gopackage is 1.21.7, but there's also ago_1_22package that's 1.22.1. I'm guessing they're waiting for it to be fully tested, while arch replaced it immediately.check here , set the channel to unstable to see the freshest packages
Nix as an external pm has most of the benefits, but almost none of the downsides. It creates an immutable package store, but doesn't cause FHS compliance related issues.
Banned at both my jobs; one for security and the other for breaking consistency.
That last point is often under-appreciated in its importance, especially when dealing with hundreds of servers.
Flatpak is very nice. Flathub is very nice. Flathub’s developer documentation is shit covered shit.
good enough, still prefer the system package manager for most things though
I use it but I hate how much space it uses and I hate when I update flatpaks I have no idea how much is going to download.
https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker
And it should only download the diffs, not everything.
@tet @linux Fundamentally, I'm just not interested in containerizing applications on my host computer. If I needed to do that, I'd use docker, so Flatpaks and such feel redundant.
I also don't like that distros like Ubuntu increasingly force snaps via apt, because it results in an unknown factor in case I ever need to troubleshoot.
AUR works for me best in cases when something isn't in the package manager. it's easier to make a custom aur package as opposed to a .deb
"I use Arch btw"
I still prefer traditional packages, but I get why devs of complicated graphical apps with lots of dependencies hate them. As for Flatpak specifically, I'm not super impressed. It's just going to get more annoying over time having more old versions of all their libraries and more and more apps that aren't updating to the latest version so they eat up a ton of drive space and give constant notices to harass the devs, but out of all the major distro agnostic options they suck the least and they're getting better the fastest, which is why I think they've pretty much won at this point. I'm not currently using them, but it's pretty much inevitable that I'll have to at some point, and overall that's probably more good than bad. I think AppImages could have been better if the lead dev wasn't a walking, talking collection of weird hills to die on, but I'm afraid that ship has already sailed.
I mean if the apps are not maintained, they wouldnt work well as distro packages too, would they?
Not really. It's actually pretty common for simpler, unmaintained apps to get small changes in each distro made by the distro maintainers to stay compatible with their current library versions. There's nobody doing that on Flathub.
Probably, but I guess thats the lack of "it has to be updated". Just as distro maintainers do, flatpak maintainers or contributors can do as well, as its often pretty easy.
Sure, they can, and yeah it is pretty easy, but people have lives. They move on. A distro always has someone checking to make sure things aren't broken. On Flathub it won't even break. It'll just waste drive space and start giving users annoying error messages, and there if the maintainer isn't interested in maintaining it anymore the only option for doing anything about it is to fork the whole project, and who's going to do that for something that isn't even really broken?
you dont need to fork a project to update its manifest on github flathub. I think the packaging is very easy and accessible, in comparison to maintaining some Debian repo package etc. Also there are way more officially supported apps on Flathub, so I dont think the lack of pressure to upgrade an app is such a big problem.
But for sure, Onionshare was one of them, and different parts of the community took care of it.
How exactly do you update the github of a flathub package with no one actively maintaining it? Not sarcastic. That is an actual question.
And I'm not worried about big officially supported apps. A better example of the kind of thing I'm talking about is older open source games. Flatpak could be great for games. No distro out there is maintaining a current version of every open source game that has ever been released, but Flathub can, and it could be great. Unfortunately anything that's not being actively maintained is rapidly going to become a 200MB download that whines about security every time you update your flatpaks, even if it doesn't connect to the internet at all. Even if it's possible for any random person to update it, who will?
Of course, this doesn't just have to be about games. There are lots of open source programs out there that just kind of get completed and abandoned. And that's not even bringing up all the closed source software on flathub that definitely won't be updated eventually. These aren't unsolvable problems, of course, but I don't even think anybody working on flatpak even cares.
I dont know who manages "who can maintain", if its only a single person thats bad of course. Good point that should be addressed to the flathub people. There should always be administrative access to some form of elected bunch of people that can then merge PRs or make new people admins.
True about the EOL runtime error messages, I mean they are important but should be possible to mute per app, especially when its offline. This will then just consume more disk space, which is probably fine.
Don't like it, I try to avoid it wherever I can.
purely as an end user i hate how much it downloads with each update and how much it uses the disk space although that's much less of an issue. i know it's solving a real problem and relieving a lot of the headaches of developers maintaing packages for each distro's specific package standard, but it's simply not the software distribution solution for people without at least well enough internet.
i wouldn't use any distro with flatpaks as its main way of delivering software and i would in almost all cases always choose alternatives even if it's outdated. i don't necessarily hate flatpak itself but for me i don't want to spend money on extra data cap and wait 30 minutes for a small update for my game launcher to finish.
the appimage of one of the applications i was interested in was 3 times less than the average flatpak update so redownloading the appimage every time would be better. if i installed more packages yeah the math would be better but it's still wasted data per update no matter how small it actually is. i found out after a while of using flatpak that i wouldn't just update and was stuck with outdated software anyway.
Does anyone know how they handle spoofed malware? I can never figure out whether I can trust the packages from flathub. I always have to check the official website of the particular software first.
Flathub maintainers do not upload anything, they just write a manifest pointing to the official source and flathub does the rest. They also cannot modify it freely, approval is required.
Flathub verifies you have permission from upstream before accepting it. Other than that, sandbox.
I'll always prefer the repositories, but Flatpak comes in handy for applications with weird dependencies where you need to compile everything needed on your own - or outdated 32 bits software.
Ambivalent. I like the consistency between distros and the idea of sandboxing, in practice sandboxing is a pain in the ass and Flatpaks use up an inordinate amount of space for different library versions. However, if I have to use a proprietary application I do appreciate the sandboxing and Flatpak is my preferred install method.
Mostly positive. My encoding utility Aviator can be shipped with a custom community-backed SVT-AV1 fork in the background without anyone noticing any issues like they would if I linked to system SVT-AV1. Flatpak makes this kind of thing easy, and users don't have to think about it.
I usually install Debian Linux on old Chromebooks that have only 16 GB SSD, and then gift them to my cousins or their kids. Flatpacks are out of the question, since pretty much every app I checked is between 500 and 1 GB of size. I only have 7.5 GB of free space in there after the base XFce Debian installation is done, plus 2 GB of swap. I find flatpacks to be space eaters, and I avoid them even on my normal, higher SSD size laptops.
You can probably reclaim at least 1 GB of that swap, maybe even a few hundred megabytes more. I've been running with a 512 MB swap for a while now and the most I've seen occupied was about 150 MB.
Haven’t had issues, elementary uses them for system apps
I really like them. They give us a reliable application that doesn't depend the distro building a version for specific platform. For example if the newest versions are compiled for Ubuntu 24.04 but you're on 22.04 it might take a while to get the update.
It does come at a cost though, it'll have to package all the dependencies for 24.04 in a layer of the package so it'll take a long time to start up and take a lot more memory than necessary.
This is mitigated by flatpaks using same base for their application (like Ubuntu with Electron) but it still isn't the same as just starting up a proper
aptprogram.I really like it since we can have a modern version of a program for small distros and in general the barrier to entry so much lower so companies can't just say "oh we can't support all Linux distros, not feasible".
Aur you compile yourself for your own distro instead of it being done already by
aptand the like.Nix is a super cool since you can just setup and configure pretty much everything so that you just press "install" and you'll have your Gimp, VPN and whatever apps all done for you. You'll have to do some heavy configuration so programming knowledge is not necessary but really helps.
I wish more apps where officially supported, instead of saying it supports Linux and providing a .deb. Good thing the community provides unofficial flatpaks at least.
A lot of people seem to complain about them, but I really like them. I've even started using them over the AUR for some things now. I like that they keep certain things like Steam a lot tidier, and I like being able to see and control permissions and settings for everything all in Flatseal. The main downside I guess is that they use up more space by downloading dependencies for each app individually which is kind of redundant, but for me I've got a pretty big SSD in my laptop so it's never caused me any trouble. I could see how it could be a problem for someone with limited space on their system though.
Generally I tend to go Flatpak/AUR as a first choice, Appimage if I really need to, and Snaps never lol.
Get Job done but remember don't use it for Browser and Text Editor. It will make you suffer.
I'm using it for my browser on Steam Deck and it's fine. You just have to give it the right permissions.
Yea, I know but still some time it doesn't interact with system.
Sure, if you don't give it filesystem permissions it won't be able to download files and save them to disk.
Wow Cool
Edit: NVM and Sorry bro, I was feeling kinda annoyed that's why I comment this but actually my problem was GNOME extensions integration.
It is awesome
Doesn't work properly, apps are bigger and don't always apply GTK themes. I also can't easily edit the desktop file to edit the icons. I therefore only use it as a backup when I can't find an app on the AUR or office repositories, which is very rare.
"Dont ask yourself if it works, but how it works"
For editing desktop entries, copy it fron this strange directory
~/.local/share/flatpak/exports/share/applications/to your normal~/.local/share/applicationswhich will always override the others.Flatpaks are great. I install my core os and gui with the base package management. All my user side packages are Flatpaks. I then use Flatseal to lock down and modify Flatpaks as needed. What's great is running programs like wine without installing a ton of dependencies and then locking the install from parts of my computer I don't want it to have access to.
What package manager do you currently use?
Depends. Ha ha
RPMs at work, Debs for my RaspberryPi devices. PacMan (Arch) and Flatpaks for home.
AUR is similar to flathub in that most packages aren't thoroughly checked. Except for the packaging guidelines which usually have to be followed. I'm not sure how in depth nixpkgs or other distros check the source of packages of new maintainers.
Flatpak runs on all distros and supports sandboxing, which makes it a great addition to all distro repos. AUR can cause issues with dependencies and unmaintained packages, and the make file should be read since it's run with root privileges. Additionally the AUR only works on Arch Linux. Breakage isn't a risk with Nix and it's seamless rollback, but has to be installed deeply into the system (
/nix)My personally preferred package manager for most GUI apps is flatpak. Nix is great because it allows to install packages declaratively.
Edit: NixOS -> Nix
Why only use nix on nixos?
You're right. I've never tried installing a wm with Nix on another distro, but it should be possible.
Half of the packages on my system are debian, the other half is nix. It's a really good combo, and home-manager makes it easy.
Flatpak is why i moved to Debian, Running a Stable OS with the latest packages have made my Linux Desktop a full replacement for Windows, MacOS and Rolling releases.
On the one hand I like the basic idea, on the other hand I think that some fundamental problems aren't fully solved yet. There big use case are passkeys and direct password manager integration – neither mesh well with the idea of software that isn't allowed to talk to most of the system.
I'm certain that this will be resolved at some point but for now I don't think Flatpak and its brethren are quite there yet.
Dont know, may already work? Keyword adaption
Not sure what that means, but probably native messaging, a biig missing portal.
Flatpak has an Inter-process-communication permission, so software could absolutely be opt-in allowed to talk, while keeping security for the rest. Apps cant see each others
~/.var/app/org.app.name/storage though, never.The problem with Flatpak is that for me I would only use it to sandbox propietary apps, and most of these are not officially supported, so there is almost always something broken, like screen sharing, etc.
The sandbox can be very cumbersome when there is not a way to break out. I'm thinking specifically of command line tools for developers. You can poke holes in the sandbox to access the filesystem, but the moment you want to run an executable it won't let you.
Flathub doesn't accept CLI tools (unlike the Snap store)
Regarding modifying Sandboxes, try Flatseal
Why is helix there then?
Other way around, accessing command line tools. As far as I know, there is no sandbox setting to allow access to execute commands directly on the host system.
Flatpaks aren't meant for command line utilities.
Right. I mean something like an embedded terminal in an IDE that has full shell access to the host environment.
I never ever will use a flatpak or snap or whatever "application". I'm using good old .deb package.
I love the idea and the philosophy behind ! I have no trouble with them for now, one click install perfect.
However I’ll never use it for programming and I don’t understand why people use vs code flatpak or other coding app, because the app is contained and cannot interact with your system.
@Shareni@programming.dev @CeeBee@lemmy.world thanks for the resources I did not know. I was pretty confused it was not possible to do it and here you are thx ! :)
It can. Think of it like allowing a phone app to interact with your stored files.
https://docs.flatpak.org/en/latest/sandbox-permissions.html#
I installed PyCharm via flatpak. I don’t appreciate that I can’t access vim via the IDE’s terminal, and so far that’s all I really have to say about it. I like that things are sandboxed, and I think maybe this wasn’t the kind of thing I ought to have used flatpak for.
I have to agree. I tried some of the JetBrains IDEs from Flathub, and I switched back to the regular JetBrains Toolbox versions.
Have you tried granting additional permissions via Flatseal?
I haven’t, and prior to this post I wasn’t even aware of flatseal. I haven’t been doing too much dev work on my home machine lately, so fixing this gripe is kinda low on my priority list, but I’ll keep that in mind as an option if I ever get around to it. Most likely, though, I’ll probably just go back to the tarball. I really do think that I picked a less-than-ideal use case for flatpak on this one.
I didn’t want to containerize every installed app. Switched to Arch and don’t have to worry about it.
It's alright
I like it but I would prefer it to be more restrictive out of the box. Such as have apps declare a list of urls the are permitted to contact , a browser could have * .
I'd like a more granular filesystem list too more akin to apparmors were each file path needed is explicitly defined, in some cases you would need a wildcard or a directory but for most apps this could be done.
I like it, it's good for desktop apps but I LOVEEEEEE nix, if there was a graphical box distro I think it would beat everything else out of the water. Full reproducible builds is not something to sneeze at
I usually prefer not to use them, but they flatpak for Prism Launcher comes with all versions of Java preinstalled which is convenient because I play verious versions of Minecraf, other than that I try to use xbps as much as possible
I think Flatpaks are great for applications like Firefox, Steam, etc. where dependencies or delay in package distribution due to building multiple versions can be a problem.
However, there are many situations where Flatpak's sandbox can be more detriment than helpful, if the application wasn't developed with that in mind. It's not a silver bullet for everything.
I dont use insecure tools to install software
I click install, app launches and I don't need to deal with dependency hell for it. (I like them)
I personally think it is trash..
Just putting "personally" in front of an unfounded statement doesnt make it better
Why it is unfounded?? The sandbox is still a lie (flatseal is impractical security since it makes you become a security researcher overnight), apps are not properly filesystem-unveiled. But a new level of complexity.
Could you explain "filesystem-unveiled"?
Apps are not updated to support portals for "compatibility" or just lack of maintenance. Flatpak needs to follow their approach if they want to have many apps being supported.
Desktop Linux doesnt have the marketshare to dictate that all apps need to adopt portals. In the meantime, flathub.org has a rating system and verified checks, this is simply not well shown in KDE Discover and not sure about GNOME software.
Means its filesystem access is restricted.
For example, chromium on OpenBSD use the unveil(2) system call to restrict itself to /tmp and $HOME/Downloads .
Many popular flatpak applications have filesystem=host. This is equal to restrict all filesystem access and then unveil the whole filesystem.
If they can't even enforce portals, flatpak is a new level of complexity.
So I said it is trash.
Good that Chromium does that, but this means if it doesnt use portals many things will be broken.
The host access is not actually everything
Portals need a change in the app code that is not huge but differs from other packaging formats on any distro and OS. So it sucks that its so slow but that has a reason.
Not as restrictive as chromium's unveil.
For home it even restrict to the downloads folder, not accessing the whole home directory.
Yes that only works for browsers and would completely break image viewers, document editors etc
They’re great on certain desktops, like Fedora’s Atomic Desktops, but you usually have to work around Flatpak specific issues. On NixOS there doesn’t seem to be a declarative way to install them.
I love flatpaks and flathub. They're amazing for GUI apps, though there are still a couple of wrinkles that needs to be ironed out.
I would really love if it was better with regards to cli apps and developer tooling though. As someone that uses a lot of TUI apps that seriously limit how much I can use flatpak.
Thicchub
I like them sonce they're easy to install and you can update all Flatpaks at once. But I don't likke the paths and run commands. Very unintuitive.
https://lemmy.world/post/12069769
Flatpak works most of the time. Nix works almost all the time (except when stuff happens like the download fails)
Flatpak is free to assume anything about your system which is sometimes not compatible with NixOS
It's pretty good for desktop apps, but it doesn't provide CLI applications, so I still have to rely on the AUR. There are some issues with it, but overall I think it's the best solution we currently have. And it's very easy to use, which is great for new users and it will become important if Linux continues growing like this.
It's the easiest solution to packaging software for Linux that doesn't mean it's good, In fact fhe way no dependencies are shared absolutely wrecks my hard drive and makes everything super long (downloading, updating, etc...).
Where it shines is security but to be honest do you really need an open source app to be in it's own secure sandbox?
I vastly prefer nix and I wish packaging stuff for it was easier.
It does share dependencies, but in a different way than a regular package manager. You share runtimes and base apps: https://docs.flatpak.org/en/latest/dependencies.html
It still takes forever to update compared to more traditional package managers
I never notice any update times, as the default in Fedora is to auto-update (I think?). Everything is just always up to date.
Edit: coming from ten years of Arch, this has significantly reduced my time fixing things related to an update 😆
Yeah I disabled those because my Internet is shit. I'm also on fedora and when I update, the 3 flatpak apps that I have installed take as long as my entire system to update. But I get it doesn't make much of a difference if it just happens in the background
As other have pointed out, saying that "no dependencies are shared" is a very missinformed take, given that sharing dependencies as runtimes is an integral part of Flatpak's structure. But what makes it even funnier and more obvious that you don't know what your talking about, is that you than cite Nix as something you "vastly prefer" when Nix actually deals with dependencies in a very similar way to Flatpak. From the official site:
In both Flatpak and Nix, apps will only download a different version of a dependency when they need it. This ensure that, instead of breaking, the app will work the same on any system (be it an old stable Debian or a bleeding edge Arch system), without requiring devs to create monkey patches that they have to maintain as things evolve. It has the potential to immensely reduce the burden on app devs and maintainers, and make it a lot easier to make apps for Linux.
The picture is too big.
Where's that Chris Pratt meme? --
I don't know what that is and at this point I'm afraid to ask
Flatpak is a project trying to fix many things at once
What's not to Ike? These systems' development has been long overdue.
They are awesome but personally I don't use them. I have an obsession with memory management. Flatpak apps don't share libraries so they get chunky at times. This shouldn't be a problem for most people. It's a personal problem.
Man this Missinformationen is hard to squash. Yes Flatpaks absolutely share libraries. These are called runtimes and are shared between all the Flatpak apps that use the same version of it. You will only get more than one version of a given runtime if some apps need this other version. For most runtimes that I know of, most only have 2 currently maintained versions, so I almost never get more than that on my system (and when I do, app devs tend to update their apps shortly after so that they're using a maintained runtime). For example on my system where I mostly use GTK apps, I only have two versions of the Gnome runtime (44 and 45). And even when you have more than one version of a runtime, they get deduplicated, so even runtimes share parts between them.
If you're interested here is an article about it.
It’s bloated. Not as bad as snap though. xbps for the win
Everything I've gotten as a flatpak has been borked in one way or another. I only use it if there is literally no other option available.
I'm a bit "eh" on flatpak. The only benefit I see is that it's sometimes more up-to-date than what I can get from an LTS package repository. As a heavy CLI user they force me to find and click icons which is irritating (yeah - I know about
flatpak run something.I.always.forgetbut that's even worse somehow).I've hit occasional issues with applications being too locked-down. Like with Darktable only being able to see things in $HOME/Pictures. But I keep my photography work in a different location so it can't see it. I had to jump through some odd hoops to fix that. Not a problem of flatpak itself per se but something you can expect when dealing with package makers.
I fall back on flatpak if the version available through the standard package manager is too out-of-date for my liking. Other than that I can't be bothered.
EDIT: Okay - for people who think they're being "helpful" by telling me that "aliases are a thing" just stop. I'm not going to workaround a broken system. I'm going to use another one that isn't broken (or less broken).
If you're going to use flatpak from the command line you're definitely going to need to start aliasing those flatpak run commands. It's still annoying, but at least that way it's only annoying once.
No. I'll use snaps before I start maintaining a bunch of aliases that I shouldn't have to. It's a flaw in flatpak.
Well okay. I agree that it's a flaw in Flatpak, but if you think adding a single line to your .bashrc is some kind of unbearable burden that you shouldn't have to endure and you're willing to make your own experience far worse just to avoid it, then I think you're being a bit silly. I mean, be as silly as you want. Don't let me tell you what to do. You are being silly though.
I'm making my experience much better actually? Stop justifying flatpak's flaws because you like flatpak. It's flawed. Deal with it.
I don't even like flatpak very much, I'm not currently using it at all, and I already agreed it was flawed right at the very start of the quote you cut off there. I was just trying to be helpful. Sorry. Won't happen again. If you want to make things hard for yourself and no one else as a weird self-defeating protest then don't let me stop you. Don't pretend I didn't do the thing I just did and you had to edit out of the quote though. That's a real dick move, frankly.
I'm sorry - but WTF? What part of me "doing something that is easier for me" also "making things hard for myself?" Talk about a "dick move"...
No snaps are insecure on other distros that Ubuntu, as they are only isolated using apparmor. Also they are nonfree by design, just no.
They're not insecure. No more so than when I install a package via apt. No more so than when I download some code and compile it. This is propaganda.
They are less secure than flatpaks and there was malware on that store
You think the unverified flatpaks which choose their own permissions are "safe"?
You have the option to add the verified subset only, and you can always check permissions before starting an installed app, and it will not start before.
I'm sure everyone does that.
Yeah with Snaps you also have unofficial packages, no apparmor at all and a mix of foss and nonfoss apps.
But with flatpak these things are accessible and Flatseal is very commonly used.
"Already perfect" vs. "Has the foundation to fix it easily" distros could easily allow to add the subset or improve the permission system.
Do... Do you think I'm claiming snaps are better or something? I'm saying they're much easier to use and I don't give a shit about walled-garden BS. I don't want my laptop to be like my phone. I want to install an application and I want it to work. Flatpaks are fine - they just made a really stupid decision about how to run them from the CLI which is 90% of the time where I launch programs from.
Do you have a better approach for running from CLI? Apps need exact names I guess, and the system is exact.
Sandbox not working = insecure. Very simple
Indeed - if your understanding of "secure" is that simple then that definition works fine.
In the real world there is no such thing as "secure" and "insecure" - there are tradeoffs and levels of security.
Oh yeah for sure I’m just mentioning what it means in this context. Definitely means snap is more insecure off Ubuntu though.
Try this aliasing script I made
No idea if it still works lol, but should tbh. I think its even pretty well done.
-_Only thing missing is handling duplicate apps I think.
It's a decent packaging solution.
regarding the sandboxing, all the negatives are present with none of the benefits, wish they'd just rip that shit out
if you want to run software you don't trust, firejail it or get it's snap
My totally unscientific opinion (with a double-your-money-back guarantee!):
I'm not crazy about either Flatpak or Snap for that matter as there's so much backend baggage for both as well as certain hurdles regarding privileges and access to the file system (somebody please correct me if I'm wrong or working with dated information.)
My other completely prejudiced, unfounded bias against Flatpak is that it appears to have been adopted by RedHat as "the one true way," and what with IBM's/RedHat's behaviour anti-FOSS behaviour lately, plus I've almost always have been an
aptuser, I find it a pill hard to swallow.Me, say what you will about the security issues and its other flaws, but I like AppImage.
AppImages are actually more secure than flatpak. At least it has a way for devs to sign them and users to verify them.
Flatpaks follow the concept "losen the sandbox as much as needed to make apps work". This sucks, in constrast to android, but its needed.
So you shouldnt need to edit anything via Flatseal/KDEs settings, if you want to make apps work.
Flatpak is default on OpenSuse too, even more as they use Flathub instead of the Fedora Flatpaks repo. RHEL is just trying to get some money and stop people from using their work, as they need to make money.
Honestly it should be normalized that people on FOSS do weird things to make money. Fedora is RHEL upstream, so RHEL is not stealing any code, just take what Fedora does and wait a bit until its stable.
Appimages are completely flawed and as an apt user you should not like to use them, at all. This post of min may give some infos, I will update it soon.
And speaking of completely flawed, your link doesn't work.
Anyway, thanks for
beratinginforming me about AppImage but it's the closest thing on Linux to app bundles which IMThats a lemmy problem, copy the link and remove the lemmy part
Hmmm...my link in the previous post works. More proof of why Linux has never really taken off with the non-spectrum general public. I guess just following format (
[words](https://your.lousy.link)) or -- god forbid -- you select a word, click the link button and paste just isn't esoteric enough...?In any case, I see that you edited your post to
cover your tracksfix Lemmy's error.The error is that I dont use https as every browser defaults to that, but lemmy links it internally. I fixed it. Stop annoying me, my comment was constructive and trying to help, so
whatever this isstop it.