this post was submitted on 16 Sep 2024
805 points (97.4% liked)

linuxmemes

20707 readers
415 users here now

I use Arch btw


Sister communities:

Community rules

  1. Follow the site-wide rules and code of conduct
  2. Be civil
  3. Post Linux-related content
  4. No recent reposts

Please report posts and comments that break these rules!

founded 1 year ago
MODERATORS
805
Snap out of it (lemmy.zip)
submitted 2 days ago* (last edited 2 days ago) by [email protected] to c/[email protected]
 

How do you guys get software that is not in your distribution's repositories?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 56 points 2 days ago (4 children)

Native package manager > Native binaries > AppImage > Flatpak.

Yes, snap isn't even on the scale.

[–] [email protected] 52 points 2 days ago (1 children)

Not a fan of AppImages myself. For an universal format it has surprising amount of issues with different distros, in my experience. And the whole Windows style "go to a website, download the AppImage, if you want to update it, go to the web page again and download it again" is one thing I wanted to get away from. At least they don't come with install wizards, that clicking through menus thing was a pain.

For one off stuff I run once and never need again, AppImage is alright. But not being built-in with sandboxing, repos, all that stuff, it just seems like a step back.

[–] [email protected] 11 points 2 days ago (2 children)

I ran into the same issues, mentally, when trying out AppImages for the first time - but my attitude changed once I found and started using this tool: https://github.com/ivan-hc/AM

[–] [email protected] 3 points 2 days ago

Glad you like AM.

[–] [email protected] 1 points 2 days ago

So it's Scoop, but for Linux? (That's a compliment. I love Scoop.)

[–] [email protected] 23 points 2 days ago (2 children)

App images are a very Windows way to do things. They bundle everything so they are big

[–] [email protected] 9 points 2 days ago

They are windows, but the linux version of dll-hell across distros and distro versions makes windows dll hell look quaint.

If someone had addressed that better it would be one thing, but binary interoperability is infinitely broken, so app image is actually an improvement.

[–] [email protected] 6 points 2 days ago* (last edited 2 days ago) (1 children)

Isn't the gnome runtime alone 2GiB? You know how many appimages that is?

Not to mention you are unlikely to only use one runtime.

[–] [email protected] 9 points 2 days ago (2 children)

Then again, loads of apps share that runtime. And if other runtimes have same stuff as that GNOME runtime, the shared parts are on your disk only once. It's pretty smart in how it works.

[–] [email protected] 7 points 2 days ago (1 children)

Ran out of space on a 30GB partition when trying around 10 smallish programs as flatpaks. Runtimes are shared in theory but not in practice.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

If you allocate 30 GB for / that seems pretty low these days for a desktop system. If you don't have much space, it's always best to go with regular repository packages

Here someone had 163 flatpaks and it used 8,7GB in runtimes. So I'm guessing the 30GB number is for whole of /.

I just checked out mine, I have 34 apps and runtimes use 3,1GB

Runtimes are shared in theory but not in practice.

I think three runtimes (newest freedesktop, KDE and GNOME) cover 90% of my flatpaks. Then there's programs that use some EOL'd runtime and never get updated, which sucks

[–] [email protected] 2 points 1 day ago

It was on a phone, and 25 GB was Flatpak

[–] [email protected] 5 points 2 days ago (1 children)

I tested installing some web browers, kdenlive, yuzu and libreoffice and without knowing I ended up with 3 different runtimes and the total storage usage (with deduplication) was 4.79 GIB.

Meanwhile with 33 appimages that I have (which includes same flatpak apps I mentioned) are using 2.2 GiB.

It doesn't matter if they share if in the end they end up using several times more storage than the appimage equivalent.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

You should test it out with those 33 installed as flatpak. If you end up with 4.7GB for runtimes, that's basically nothing these days as far as storage goes for that amount of programs. More you have, more you benefit from shared runtimes. I doubt it'll be less than AppImages but it's usually the starting runtime space use that shocks people.

Here someone tested it with 163 flatpaks and the runtimes used 8.7GB. With the top 5 most used runtimes covering 128 of those flatpaks.

https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

I just checked out mine, I have 34 apps and runtimes use 3,1GB

It doesn't matter if they share if in the end they end up using several times more storage than the appimage equivalent.

Well we are talking about two gigs, after all. Unless you're using an embedded system, it's not a much of a concern if you ask me. But it is more, true

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

. If you end up with 4.7GB for runtimes, that’s basically nothing these days

Yes but that wasn't the original comment I replied to was about.

163 flatpaks and the runtimes used 8.7GB

163 flatpaks using 8.7 GiB means that the average flatpak is using 54.6 MiB.

That's good the other time I got this linked: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users

Which is no good as in that example there was 173 flatpaks using 27.66 GiB, average 160 MiB, while in your case the average flatpak is using 91 MiB.


This is what I have with appimages:

In this case the average appimage is using 69 MiB, though there is one outliner which is the Steam appimage that I have there (470 MiB) which is an entire conty container with its own video drivers and everything, without it the average would be 56 MiB.

I know this doesn't matter these days but once again that wasn't what the original comment was about.

Well we are talking about two gigs, after all. Unless you’re using an embedded system, it’s not a much of a concern if you ask me. But it is more, true

Thanks for the link showing an average flatpak using 54 MiB though, didn't think it was possible lol.


WAIT I just took a deeper look at the link, isn't that guy just showing the runtimes without the applications using 8.7 GiB?

[–] [email protected] 1 points 2 days ago

Yes but that wasn’t the original comment I replied to was about.

I know this doesn’t matter these days but once again that wasn’t what the original comment was about.

I agree, it was just about the size differences. I just think it's good to bring up since there's many confused about the flatpak size use. Often people might want to install some small app and they're hit with gigs of stuff and come off thinking that's the same for every app, which would be insane of course.

WAIT I just took a deeper look at the link, isn’t that guy just showing the runtimes without the applications using 8.7 GiB?

Yes it's specifically comparing runtimes. Same for my number, I was calculating how much the runtimes used.

[–] skulblaka 8 points 2 days ago (2 children)

I'm a technically savvy but new to Linux user who installed Mint as my primary OS about a month ago. So far I've used Flatpaks and AppImages without any issue and haven't come across snaps. Would you explain the differences and why I would care about one over another?

[–] [email protected] 4 points 2 days ago

At the end of the day, they're just different ways of reaching the same goal: universal packages for Linux. I personally use them interchangeably depending on the application and use case.

There are some packages that definitely work better and are intended to be used and installed via your native package manager (if they rely on system libraries and whatnot). But using either a Flatpak or AppImage results in the same experience - in my experience. It's a personal preference.

[–] [email protected] 2 points 2 days ago (1 children)

IMO flatpaks are the future of installing linux apps. The comment you replied to lives in the past. System package manager should be for system binaries, not for applications.

[–] [email protected] 6 points 2 days ago (1 children)

But I like my applications years out of date and I think its good that every distro has to spend manhours on packaging it individually.

[–] [email protected] 4 points 2 days ago (1 children)

lmao you joke but half this thread is exactly that opinion

[–] [email protected] 2 points 2 days ago (2 children)

I see the appeal for the package manager for a lot of things, but space got so incredibly cheap and fast that duplication is way less of a deal than the effort to make stuff work the traditional way. But im not a real linux user. I don't like tinkering, I want to download something and it works. And the amazing thing is we can have both. If people like spending time to package something be my guest.

The funniest interaction I had recently. I downloaded a program that isn't in my package manager or had any sort of flatpack/appimage so I downloaded it as a deb and it didn't run because of some dependency. So I could clone the git and build it from source which might have worked, but I was too lazy to. So I just downloaded the windows exe and ran it through wine, which worked flawlessly.

[–] [email protected] 2 points 1 day ago

I don't like tinkering, I want to download something and it works.

And this is what's keeping Linux at bay. Normies are that to the extreme. They want something that is as simple and resilient as possible, they couldn't care less about the dependencies or even know what they are. They want ~~a program~~ an app and just install it from an "app store" if possible.

[–] [email protected] 2 points 2 days ago

you are a real linux user don't let some neckbeard tell you otherwise :P

[–] [email protected] 5 points 2 days ago

And the last three aren't even an option in the enterprise unless your CTO is 24.