Welcome to Incremental Social! Learn more about this project here!
Check out lemmyverse to find more communities to join from here!

graham1 ,

I know a lot of people enjoy flatpak, and I enjoyed it for a couple apps that had annoying update processes in other package managers, but I'm really not impressed with it overall. Maybe it's an unpopular opinion

acockworkorange ,

Nah, it's pretty popular. Flatpack for the things you can't / won't use your regular package manager is the most common behavior.

Kusimulkku ,

I dunno. A lot of stuff is switching over to flatpak these days. And it is the right direction. Regular repo stuff for the system and flatpak for apps is the way to go. You can have solid base separate from the applications.

acockworkorange ,

From my cold, dead hands!

Kusimulkku ,

It's good that there's options for everyone. I feel like flatpak is to desktop systems what docker is to servers.

The situation right now is good in that both are maintained, but in the future it might be that distro repos get slimmer while flatpak becomes the norm. But we'll see. I bet there's people out there willing to maintain packages in the distro repos if nothing else then out of spite hah.

acockworkorange ,

I think there are some quite difficult technical challenges to solve with flatpacks that prevent its wholesale adoption. I'm sure they'll find a way, but it'll take some time. In the meantime, I'll rest on apt.

Kusimulkku ,

I don't know, I think it's really far already. I can't think of any big issues I've had. Biggest technical issue is KeepassXC talking to Firefox, if both are in flatpaks. But that has a working workaround and the issue is being worked on right now (I had a ton of emails since I seem to be following the issue on github lol).

acockworkorange ,

That is a big one, inter process messaging securely.

The other one is memory deduplication. Uncontainerized libraries get code stored in memory once. When two applications use the same library, only library variables are duplicated, executable code is stored once.

When two flatpacks package the same library, they duplicate memory use. This is has to be addressed if we're thinking of replacing regular packages altogether.

Ok, suppose we got over that technical jump and can share code memory among different flatpacks. What happens when one of them is updated and packs a newer version of the library? Can we use the newer version for both? Are we breaking compartmentalization by doing so? Or by the very sharing of it?

The concepts need to be worked out (a big hurdle), then implemented. At this point, are we departing too much for the concept that we're essentially creating just another package format?

I don't have these answers, but I think there's a good chance the answer to those will limit flatpack (and competitors) application as the end-all, be-all package format.

Kusimulkku ,

Inter process messaging seems to be have quite some attention right now. I don't think it's very far now, if KeepassXC/Firefox issue I'm following is any indication.

When two flatpacks package the same library, they duplicate memory use.

Maybe I misunderstood you, but if they share the same library, the memory deduplication is already happening? I found this https://github.com/flatpak/flatpak/issues/4997

I've been running fairly low ram machines and I genuinely haven't noticed any difference. Maybe I haven't run enough of them at the same time and them having different (not shared) libraries. I wonder what the benchmarks are on this. I've only seen threads where people say it uses a bit more but no real comparison.

end-all, be-all package format.

I'm not sure if that's the direction. I think flatpak is specifically targeting GUI apps, with the "system" packages being traditional packages. And I think that's a good solution, that way you'd have a tighter system layer that could even be immutable and you'd have a separate application layer, so they don't mess with each other. Good for preventing breakage of the system if there's somehing fucky with some app.

acockworkorange ,

I think that deduplication ticket refers to library flatpacks. Like both flatpacks depend on a third one, and the contents of that third one will be loaded only once in memory.

I was taking about libraries packaged together with two apps. I don't think the OS will know that two files located in different locations are actually the same and can be loaded only once in memory.

If that is solved, I'd be really glad to hear. Especially the decisions involved in handling multiple versions.

Whereas about how much of the system goes in flatpacks, once you've put your DE and apps on it, that's like 80% of a typical desktop software load. There's not much left and, like you said, the rest can be immutable. You may argue the DE is part of the base system, and I'd agree with you, but many people don't.

Veering off topic for a bit... TBH it feels a little too much like Windows for my taste. When apps have a package maintainer, you can choose the level of stability you want and developers can focus on adding features / optimizing. When you remove that layer, the developers need to figure out how stable to keep their app to cater to most users, and if you are not comfortable with that, tough luck.

Kusimulkku ,

They do talk about how the library deduplication in memory is an OS feature and nothing to do with flatpak so it's possible that the same library being shared might be dedupped whether it is in same runtime or not. But I don't know. In any case, I guess extra RAM use is possible but I don't think (from personal experience and reading up on it) that it's very noticeable. Not to mention a lot of the used libraries do come with the runtimes, so that alleviates the issue if the dedupping isn't happening.

Whereas about how much of the system goes in flatpacks, once you've put your DE and apps on it, that's like 80% of a typical desktop software load. There's not much left and, like you said, the rest can be immutable. You may argue the DE is part of the base system, and I'd agree with you, but many people don't.

I think the intention is to keep at least some parts of the DE outside of it, but the apps that make it as flatpaks. So for KDE I think it would be something like the shell, file indexer, "low level" stuff like that out and image viewer, media player, browser, "apps" like that in flatpaks. Which does break the DE up but makes sense to me, with "system" being separated from "apps".

Veering off topic for a bit... TBH it feels a little too much like Windows for my taste. When apps have a package maintainer, you can choose the level of stability you want and developers can focus on adding features / optimizing. When you remove that layer, the developers need to figure out how stable to keep their app to cater to most users, and if you are not comfortable with that, tough luck.

You could have "stable repos" for flatpaks, maintained by distros but I feel like it would take away some of the point of it (being to ease distro repo maintainer workload). Some devs will be happy that there's no "meddling" distro maintainers, which is a complaint I've sometimes seen from devs. I think the idea that the apps come straight from the devs is both good and bad. Good in that it's how the dev intended and updates are possible much quicker. Bad in that often the modification distros do serve a good purpose, of making the app better fit in to the whole or fixing stuff that misbehabes but for whatever reason hasn't been fixed upstream.

acockworkorange ,

Nothing further to add, I'd just like to thank you for the engaging discussion. Have a good one!

KISSmyOS , (edited )

And it is the right direction.

I disagree. There's already a universal format for deploying software on all Linux distros. It's called "source code".

Kusimulkku ,

Well there's always Gentoo for those who want that, I suppose.

KISSmyOS ,

Or Arch. Or Slackware. Or OpenSUSE. Or basically any general purpose distro that isn't Debian-based.

Kusimulkku ,

I meant more geared for source from the get-go. Compiling everything from source without package manager or something, old school style might be a bit of a pain for most users.

WeLoveCastingSpellz ,

Just no, lol

retrieval4558 ,

Noob question: lately I've been using flatpaks for most things because of the packaged dependencies. I am under the impression that as you add and remove programs over time, you'll run into less issues with flatpak than with the distro package manager because the dependencies will come and go with the flatpaks and not sit in the host accumulating my mistakes. Am I wrong about this?

acockworkorange ,

Any package manager worth its CPU cycles should take care of orphaned dependencies for you. Whether your package manager is decent or not is matter of heated debate, but the problem of orphaned dependencies has been largely solved.

TLDR, you're likely wrong about it. You're also paying to have a neat filesystem by using more storage (which is cheap, spend away), memory (a bit or a big bit, depending), and performance (there are comparisons online, only you can decide if it's significant for you).

Now, my opinion is that you're overtaxing yourself. The reason you mentioned for adopting flatpack is better addressed by familiarizing yourself with your main package manager. People that defend widespread use of flatpacks usually have other reasons (mostly newer versions, faster bug fixes and security fixes, etc.).

The combination of which distribution and how to use side-loaded software isn't a one size fits all. There are pros and cons to each approach, and they differ based on your needs, your distro, your threats...

retrieval4558 ,

Thanks for answering! I'll do some reading on how package managers work.

KISSmyOS , (edited )

Good luck. That's like "reading on how software works".

li10 ,

Maybe I’m talking out my ass, but it seems to be something devs like because it makes their life easier.

Flatpak/snaps are always a hard miss for me as a user, unless there’s no other option.

taladar ,

it seems to be something devs like because it makes their life easier.

It seems to be something some devs like because they get annoyed when distro maintainers point out problems in their software or implement workarounds for those issues.

Kusimulkku ,

For users it can mean a lot better app availability since not every distro has enough maintainers to have timely updates for all their repo packages and the maintainer obviously doesn't want to maintain it for every single distro. Less work for maintainers/devs all around, with the benefit of better app availability to the user.

Bishma ,
@Bishma@discuss.tchncs.de avatar

I'm convinced most of flatpack's popularity is just it not being snap. When one is meh but you actively dislike the other, "meh" starts to look pretty good. Or maybe I'm just projecting my own feelings.

anyhow2503 ,

They both solve a very similar set of problems and they each have their advantages, but canonical really managed to burn a lot of community goodwill with snap, so I'm just not willing to touch it personally (I also dislike having a hundred loop devices in my mounts).

stepanzak ,

Given the shortage of people working on FOSS apps, I'm all in for anything that makes their lifes easier, so tgey can focus on the programming part and don't have to care about packaging. That can be solved with community packaging like AUR, but that has it's own problems.

taladar ,

But Flatpak is one of the technologies that explicitly has the developer deal with packaging, something they are usually quite bad at because they don't do it very often, unlike distro maintainers.

stepanzak ,

Yes, but developers can create only flatpak, where they make sure it works and they officially support it, and then completely stop caring about other formats and community packages. Just like Bottles project does.

taladar ,

where they make sure it works and they officially support it

Citation needed

completely stop caring about other formats and community packages.

That seems to be the case every time developers package software in any way. Sometimes even if they don't package it at all.

stepanzak ,

I'll try to reword it so it's clearer what I meant:
I think developers shouldn't have to maintain more than one package format, and I think flatpak is the best format to be the one supported by the developer officially. Many developers officially support only .deb for example.

anyhow2503 ,

Maybe you have your own reasons for not being impressed with flatpak and you just didn't list them, but this post is just OP blaming the flatpak CLI for not using sudo for him. There are things that flatpak doesn't do well, but there's currently not a single comment under this post listing any genuine drawbacks.

starman ,
@starman@programming.dev avatar

I agree. I prefer using native package manager, nix in my case.

Kusimulkku ,

I really like it, I think it's genuinely great

cypherpunks ,
@cypherpunks@lemmy.ml avatar

next time you can use su or sudo

possiblylinux127 ,
@possiblylinux127@lemmy.zip avatar

That installs and or updates roots flatpaks

cypherpunks ,
@cypherpunks@lemmy.ml avatar

Only with --user (I think)? Root can also update the "system installation" flatpaks, which are presumably what OP needed a password for.

possiblylinux127 ,
@possiblylinux127@lemmy.zip avatar

Ah, I've never tried

SuperIce ,

Which is what flatpak will always do unless provided with the --user flag.

cypherpunks ,
@cypherpunks@lemmy.ml avatar

That installs and or updates roots flatpaks

Which is what flatpak will always do unless provided with the --user flag.

By default it operates in system-wide mode, which is different from "root's".

flatpak list and sudo flatpak list will both show you what is installed system wide, and flatpak list --user will show you your user's, and sudo flatpak list --user will show you the root user's flatpaks installed in per-user mode (of which there are typically none).

cyberpunk007 ,

Reminds me of updating aur

Overtheveloper ,

yay --sudoloop

MonkderZweite ,

yay using ssu = no password prompt.

Linkerbaan ,
@Linkerbaan@lemmy.world avatar

Sudo su

corsicanguppy ,

Sudo su

... for a brief period exposes you to risk. And its double-child kills a lot of context you may want. And it's ghetto like

cat file | grep string | cat | more

try sudo -i and join us in this millennium.

Linkerbaan ,
@Linkerbaan@lemmy.world avatar

Take off the training wheels 😎

https://media1.tenor.com/m/YuEiAHoh1fIAAAAC/fail-bike.gif

federatingIsTooHard ,
@federatingIsTooHard@lemmy.world avatar

sudo bash

NoLifeGaming ,

Wouldn't you just be able to terminate and then run sudo flatpak update ?

Samsy OP ,

Maybe, I thought this couldn't be end in another ask for password, and again, and again.

quicksand ,

I love that this post just turned into people giving helpful solutions and not bullying. Lemmy be awesome

corsicanguppy ,

I like this.

Flatpak is so bad for single-source-of-truth for install state that you should have to put in your password every time just to confirm you understand the pain you're signing up for.

My only advice here would be if they can change the prompt to say

THANK YOU SIR!  MAY I HAVE ANOTHER!
password:  *******
EpicFailGuy ,
@EpicFailGuy@lemmy.world avatar

sudo -i

KISSmyOS ,

I accidentally did a winget upgrade --all from a non-elevated powershell today. I know your pain.

Churbleyimyam ,

Good old flatpak.

Kusimulkku ,

This was rather an issue of flatpaks being installed for the system, so updating requires root. One option would've been to use sudo and another would've been --user. I guess flatpak could be blamed for defaulting to --system, which I'm not sure if the blame is on flatpak or distros, dunno.

Churbleyimyam ,

Who knows. I avoid flatpak for other reasons!

Kusimulkku ,

I specifically install flatpaks of most of my stuff. I really like it

Ilgaz ,

Really weird thing is, distros and flathub kinda pushes users to do system wide installs while most of the packages can work and get updated per user.
They are pushing the thing which made Windows almost impossible to use without an administrator user.
A dramatic example would be gnu guix, almost never requires root for updates or installs. It is also usable by normal users. From GNU... :-)

dadarobot ,
@dadarobot@lemmy.sdf.org avatar

sudo flatpak upgrade

Kerb , (edited )
@Kerb@discuss.tchncs.de avatar

huh?
why would you need to enter a password to update flatpacks?

why would flatpack ask for your pw multiple times when every other package manager only needs to ask once?

somethingsomethingidk ,

For every sever install I've had, flatpak defaults to the system install which requires a password. You have to explicity pass the --user flag.

I'm not sure how to make it the default

Pantherina ,

Thats probably still not possible over ssh.

Kusimulkku ,

Remove --system repos and install them as --user. For me it defaults to --user

SuperIce ,

Because he tried to update a system-wide flatpak install as a non-root user. Flatpak uses polkit for root permissions. Polkit is usually set up to allow non-root local users to update flatpak without a password, but not remote ones, hence having to continually enter the password for polit when using SSH. He could just run the update with sudo like a normal package manager and would only have to enter the password once. But then he wouldn't be able to complain on Lemmy.

Samsy OP ,

Hm, next time when I run into a serious issue, I make a meme here and wait for the explanation.

Thx, next time I just use sudo.

Kusimulkku , (edited )

I update flatpak through ssh and haven't had this issue. I think you installed it system wide and not for the user, since with user you don't need password at all

E: From the comments it looks like they didn't use sudo to update either. With it it would've asked once. With --user that wouldn't have been necessary ofc.

haui_lemmy ,
@haui_lemmy@lemmy.giftedmc.com avatar

Omg. That doesnt sound great. I‘m using discover on my machine and it works seamless.

SuperIce ,

Flatpak uses polkit for permissions. System level flatpak updates are typically permitted without password by polkit but only for local users. For SSH, most flatpak operations require a password, so it's a mess if you try to run an update on system level flatpaks without sudo, which solves OP's problem. They could also move everything to a user level install, which IMO makes more sense for flatpaks than the default system level mode.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • linuxmemes@lemmy.world
  • incremental_games
  • meta
  • All magazines
    •