Snap bad

submitted by

https://lemmy.world/pictrs/image/810a436c-3ea3-4e15-8a2a-bdecd0591078.jpeg

Snap bad
1.1k

Log in to comment

246 Comments

Seeing ".TAR.GZ" in all caps gives me strong feelings of wrongness.

Unfortunately imgflip prints text in all caps only.

Yes, the format demands it; not fault implied on your part, just commenting on how it hits

A magnetised needle and a steady hand is a better package format.

What you are thinking of is not a package manager but a compiler.

Not if you just have list of blobs in your head.

Are there enough watermarks on this meme? At least we got reddit covered.

Deleted by moderator

 reply
29

You can change the labels but the groups in them would remain the same. :)

A stab at my personal ranking: .deb > appimage > flatpack > curling a shell script

I can't help but love a .deb file (even when not via repo), I've almost exclusively used Debian and it derivatives since the late 90s. And snap isn't on the list because it got stored in a loopback device I removed.

I just recently de-snapped yet another ubuntu system. Couldn't agree more.
I use debian standard for all of my stuff, and I agree with your ranking.

As someone who hasn't used Ubuntu since the time they used to mail disks for free, may I ask why? Why not install another distro?

Ubuntu support online (I mean, the size of the community) can be useful. And besides the snap and "ubuntu advantage" thing, they're mostly a more up to date vanilla Debian, which is extremely convenient because, Debian.

It's obviously good for people used to Debian, but it's also great for other, because of the regular updates. But in fairness with your point I've been thinking about moving to mint since it's basically a de-snapped ubuntu.

Why not use Debian? Non-free packages issues?

Second this. I got tired of Ubuntu and moved to Mint first, then Debian.

When I switched to Ubuntu, they just had more up to date packages, and with two releases a year (sort of), stayed up to date with other software, which is a good thing for a system I actually use. From then on, I just stayed on it, because I don't reinstall my OS until something's broken. I've been moving the same one for a decade now.

If I had to install a new desktop system I'll probably go with mint, for the same reason : more frequent software update.

Note that this is all for desktop (and some specialized systems). Servers are all running debian, because stability is preferable and frequent software change is not what I want in these environments.

I say this to be fair, since I've used Debian since almost the very beginning:
Debian is a bit more complicated to set up.

I generally find when people ask me for help, they're either on Ubuntu or on Fedora (in which case I direct them to someone else for help). Sometimes they're gamers or using something where Debian + tweaks is ideal, but often I just help them configure Debian, or just help them get their Ubuntu where they want it.

Not that user: My biggest problem with Debian was that packages were often so out of date (even sid). This was a big issue for the kinds of software I wanted to run, and also generally denied me useful newer features in most programs. Security and stability weren't that device's most important values.

You can consider using Armbian x64, which is very similar to Ubuntu minus Snap.

As someone who is confused when he has to deal with a .deb file and always has to google what to do with it - what is the advantage of a .deb over let's say a shell script?

Well for one a .deb comes out of the box with an uninstall machenism. As well as file hashes, package singing, etc...

I never fully trust a shell script and usually end up reading any I have to use first, so I know what they do. And after so many years dpkg holds no mysteries for me and Discover will install .debs if I double click while in KDE.

It's worth knowing that .deb files can contain setup scripts that get run as root when installed, so you should trust them too.

Yeah. They all come with risks, but I psychologically struggle to run shell scripts unless I know what's in them. And the same brain dysfunction makes my automatically distrust a script that doesn't set pipefail.

That definitely makes sense. Also, the scripts in a .deb should be incredibly short and readable, if you choose to check them out.

If made correctly (which is hilariously easy), it's a clean install and uninstall process, support some level of potential conflict regarding files that are shared with other packages/commands, support dependencies out of the box, and with minimal work can be made easy to update for the user (even automatically updates, depending on the user's choices) by having an (again, very easy to setup for a dev) repository. With the added value of authenticity checks before updating.

All this in a standardized way that requires no tinkering, compatibility stuff, etc, because all these checks are built-in.

Note that some of this probably applies to other system package management solutions, it's not exclusive to .deb.

dpkg -i <nameofpackage.deb>

Which can be read as: (Debpackage) -install <nameofpackage.deb>

That's it!

Also, if you haven't already, install tldr (apt install tldr), then you can 'tldr deb' (or any other command) to get a few examples of their most used functions.

It might be different for other distros, but for me on MX Linux, I just click on the .deb and it opens a shell with a root prompt and installs the file automatically. Easy peasy.

Am I the only one who struggled extensively with .deb file with out-of-date dependencies? It seems the software dev needs to update the .deb file frequently, which they never do.

I tried a snap package on my pop-os system once & it poo'ed folders all over my system, then didn't actually uninstall when I uninstalled it.

No thank you.

by
[deleted]

thats the thing with snaps: they go all over the place on your system, so even if you uninstall it (which itself is a tiring and cumbersome task at times!), they magically stay everywhere on the systems, with tons of folders and files.

I thought contained snaps can only install into /snap directories.

They're downloaded somewhere under /var/snap and by default a snap only has access to a limited set of directories - one under /var/snap for system-wide data (generally used by snaps that run services like cups or MySQL) and one under ~/snap for each user. When you snap remove an app, it bundles that up into a file that's kept for a while in case you reinstall, but it won't if you use --purge.

Obviously many apps request access to other places (such as non-hidden directories in your homedir) so they can read or write stuff, but that's down to the app to then behave correctly (same as with any other packaging system).

by
[deleted]

install yes, but there are tons of other files and folders that get created, IIRC even pseudo-users or something along those lines? (or that was distro-specific perhaps)

You mean like the program itself is creating files? The issue would be the same whether apt or snap is used, in this case.

by
[deleted]

never had a problem with other programs leaking out on the system after being properly uninstalled except snap

.tar.gz should be appimage.

There were only three characters so it kinda got left out.

my issue with snaps is honestly just that they are controlled too much by just one entity (canonical) and there is no reason for them to exist because flatpak already does everything they do.

My issue with snaps is also the power that Canonical has to fuck you over one day, because of the centralization that you mentioned, but also that their shitty fucking packaging format sucks ass and breaks everything but the most basic of apps. I've wasted hours trying to help people with their broken applications that were hijacked when they typed apt install whatever and "whatever" was actually a fucking broken snap package.

Flatpaks and AppImages actually do the fucking things they're supposed to. Snaps don't, and Canonical is pulling a Microsoft by hijacking your package manager.

Also, Snap sandboxing only works with AppArmor, so if you were hoping that all the breakage was worthwhile because you get sandboxing, you don't if you're on anything but a handful of distros 🙂

Let me know when I can get cups as a flatpak.

(Oh and snaps predate flatpaks.)

Yup, thats why a tarball is better

Why tf does every app have to mount itself as a virtual block device?

Because fuck you, that's why

This annoys me when I don't have a command aliased to filter them.

And it annoys me that I have to make an alias just to filter them, my fish config must only have what's necessary 😤

Serious question: why not? What's bad about that?

Because with snap lsblk gets very cluttered, making it hard(er) to find any disk you're looking for.

Edit: lsblk or any other command that lets you see all the connected disks really

Yeah it feels like unnecessary bloat

Tar is not a package manager, it is just a packaging format. AppImage has the same problem.

Flatpak is a bit of a crappy package manager but at least it is one. And, due to its use of container technology, it allows the same packages to run on any Linux kernel (any Linux distro). That is pretty useful.

Of the other package managers, apk 3 is my favourite but the only distro that uses it is Chimera Linux. Pacman is good. dnf / RPM is ok. apt / deb is in last place for me. The recent Ubuntu 25.04 launch snafu illustrates some of the problems with apt. The first Linus Tech Tips Linux challenge really highlighted the dangers of apt.

I only used snap briefly but instantly hated it. Fstab was a mess. It was slow. It was proprietary. I fled before I could form an educated opinion.

it allows the same packages to run on any Linux kernel (any Linux distro). That is pretty useful.

flatpak itself depends on namespaces, so saying that it works on any kernel is quite a stretch.

Can flatpak do this? This is a GIMP3 appimage running on ubuntu 10.04 without any container:

The kernel is so old that even the appimage runtime itself complains of missing functions and has to fallback to a workaround.

UPDATE: flatpak can't work because bubblewrap itself can't:

PR_SET_NO_NEW_PRIVS is only available since kernel 3.5

Just curious, why are you using a 15 year old version of Ubuntu?

I'm not, it's a vm that I use to test.

There is quite a lot of systems still stuck on kernel 2.6 that can't be updated, so it is always nice to make sure what I do can work on such.

I really like flatpak and it's system, but AppImages are in a nice second place. I usually look for a flatpak first and appimages if I can't find the first.

Let the hate of the crowd wash over me, but I don't even like Flatpak, and I've got love-hate (mostly hate) relationship with AppImage as well.

Just give me a system package or a zipped tarball.

In recent years, have had to just get used to needing to build most projects from source.

Why the hate part of AppImage?

For me it is the "Windowsy" feeling of downloading an executable from some website. I prefer having all my packages managed in one place.

Makes sense, I kinda like it from a distributor standpoint. Flatpak is my favorite though.

For simple "apps" it is fine, but my computer is not a phone and I don't use it like one. I mostly don't want simple apps that have their own little sandbox to play in.

I want full-scale applications that are so big they have to use system libraries to keep their disk size down. I also don't want them in a sandbox. I want them to have full access to the system to do everything they need to do, I want them to integrate with far-flung parts of the system and other applications too. I only use applications I trust and don't want them constantly pestering me about configuring permissions and access in just the right ways and opening all the right doors and ports and directories to make them work, I trust them by installing them, they have permission, and the easier they make it to access everything I will inevitably be asking them to access, the happier I am.

My practical concern with distribution methods like AppImage and Flatpak is that now I have to do a lot of extra thinking every time I'm installing anything. To pick how I'm going to install something, I have to solve the matrix of "what kind of distribution method do I prefer for this type of software" combined with "what distribution methods are available for this software" and "what versions are the available distribution methods for this software" and "what distribution method provides the best way for this software to get updates".

In the olden days, when the distro's package manager was the only choice, all I had to care about was "is it available in my distro" and the decision tree was complete. I appreciate all the availability of choice that things like AppImage provide, but it doesn't actually make it easier for me, it just makes it easier for the packager of the software. They're doing less, but making more work for me, as a user. Distro packages are a lot of work for the maintainer precisely because they at least make an effort to solve many of these issues for the user. The value-add that maintainers provide is real.

I agree, there's a place for flatpaks and appimages, but for the most part my computer isn't it. If I was setting it up as more of an appliance or as a work computer in a fleet of devices, sure they'd be great. I installed VLC in it's flatpak form on accident once and it was worthless because the entire reason I installed it was to watch either a DVD or Blu-ray, and it didn't have the libraries to read the disc. It took me far longer than I'm willing to admit to figure out it was because flatpak. I'm sure there's a way to work around that, but at that point I was done with any flatpaks for anything that might need additional anything.

They do cut down on needing multiple versions of the same package, so I'll sometimes install the flatpak version to try something out if I'm not sure it's what I want.

I want full-scale applications that are so big they have to use system libraries to keep their disk size down

Linux is in such sad state that dynamic linking is abused to the point that it actually increases the storage usage. Just to name a few examples I know:

most distros ship a full blown libLLVM.so, this library is a massive monolith used for a bunch of stuff, it is also used for compiling and here comes the issue, by default distros build this lib with support for the following targets:

-- Targeting AArch64
-- Targeting AMDGPU
-- Targeting ARM
-- Targeting AVR
-- Targeting BPF
-- Targeting Hexagon
-- Targeting Lanai
-- Targeting LoongArch
-- Targeting Mips
-- Targeting MSP430
-- Targeting NVPTX
-- Targeting PowerPC
-- Targeting RISCV
-- Targeting Sparc
-- Targeting SystemZ
-- Targeting VE
-- Targeting WebAssembly
-- Targeting X86
-- Targeting XCore

Gentoo used to offer you the option to limit the targets and make libLLVM.so much smaller, but now rust applications that link to llvm have issues with this with caused them to remove that feature...

Another is libicudata, that's a 30 MiB lib that all GTK applications end up linking to for nothing, because it is a dependency of libxml2, which distros override to build with icu support (by default this lib does not link to libicudata) and what's more sad is that the depenency to libxml2 comes because of transitive dependency to libappstream, yes that appstream that I don't even know why most applications would need to link to this.

And then there is archlinux that for some reason builds libopus to be 5 MiB when most other distros have this lib <500 KiB

Sure dynamic linking in the case of something like the coreutils, where you are going to have a bunch of small binaries makes sense, except you now have stuff like busybox which is a single static bin that acts as each of the different tools by checking the name of the symlink that launched it and it is very tiny at 1 MiB and it provides all your basic unix tools including a very good shell.

Even Linus was surprised by how much dynamic linking is abused today: https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/

> To pick how I’m going to install something,

https://github.com/ivan-hc/AM

I have all these applications using 3.2 GIB of storage while the flatpak equivalent actually uses 14 GiB 💀: https://i.imgur.com/lvxjkTI.png

flatpak is actually sold on the idea that shared dependencies are good, you have flatpak runtimes and different flatpaks can share, the problem here is that those runtimes are huge on their own, the gnome runtime is like 2.5 GiB which is very close to all those 57 applications I have as appimage and static binaries.

but it doesn’t actually make it easier for me, it just makes it easier for the packager of the software

Well I no longer have to worry about the following issue:

  • My application breaking because of a distro update, I actually now package kdeconnect as an appimage because a while ago it was broken for 2 months on archlinux. The only app I heavily rely from my distro now is distrobox.

  • I also get the latest updates and fixes as soon as upstream releases a new update, with distro packaging you are waiting a week at best to get updates. And I also heard some horror stories before from a dev where they were told that they had to wait to push an update for their distro package and the only way to speed it up was if it was a security fix.

  • And not only you have to make sure the app is available in your distro packages, you also have to make sure it is not abandoned, I had this issue with voidlinux when I discovered the deadbeef package was insanely out of date.

  • Another issue I have with distro packages in general is that everything needs elevated rights to be installed, I actually often hear this complains from linux newbies that they need to type sudo for everything and it doesn't have to be this way, AM itself can be installed as appman which makes it able to work on your HOME with all its features. And you can take your HOME and drop it in any other distro and be ready to go as well.

omg I cannot fucking believe that while I was typing this I just saw another distro package nonsense:

There is this very good tool called soar which I use for static binaries. (It also has support for appimages but to be honest it is not as good as AM rn).

Well we just got a complain that fastfetch is not displaying the package count of soar, which fastfetch is able to do.

Turns out this is because the archlinux package is built without SQLITE3 which is needed for that feature to work 😫

And what's worse is that account registrations are disabled in the archlinux gitlab, so I have to jump thru some hoops to get a basic bug report filed...

Just enable the sqlite3 USE flag in /etc/portage/make.conf.

Sorry, wrong distro. I'm assuming Arch can use portage or something if you want.

It doesn't sound like they're making more work for you. It sounds like you're making more work for yourself, and it sounds exhausting.

I couldn't agree more. Occasionally I'll use an appimage where something is not packaged for my distro version and I only need it temporarily.

Maybe I'm just long in the tooth, but linux used to be a simple, quite elegant system, with different distros providing different focuses, whether they were trying to be windows clones, something that a business could bank on being there in ten years, or something for those who like to tinker. The common theme throughout was 'the unix way', each individual tool was simple, did one job, and did it well. Now we seem to be moving to a much more homogenous ecosystem of distros with tooling that tries to be everything all at once, and often, not very well.

So, vibes?

And the added work with keeping them updated.

AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.

The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using appimageupdatetool

This method also provides delta updates, meaning it doesn't download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:

Most update themselves & flatpaks are the worst when you need them to work with your system (ie: scripts).

So I guess your opinion is just wrong, sorry! (That's a joke you guys)

I despised the Windows way of everything having their own updater either running in the background or only alerting you when you want to use an app.

AppImage to me feels like a big step backwards.

Damn, should have said that sooner, I see people don't tolerate that kind of talking to others in here. Respect the community.

Interesting you compare it to Windows, given how in OS X you literally just drag applications into your Applications folder to install them.

Missing dependencies. (Or wrong version of fuse)

I'd say that complete lack of a single consistent way to manage updates.

I really don't feel having to micromanage each piece of software.

AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.

The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using appimageupdatetool

This method also provides delta updates, meaning it doesn't download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:

TLDR: https://github.com/ivan-hc/AM

No automated updates has be the biggest reason for me.

Just not a fan of container formats in general.

I say that as a heavy user of Docker, but that's a different use-case.

I go the opposite way. I like the ideas of container formats lol

Easy to update, easy to uninstall, easy to migrate.

Not trying to be annoying like a kid here 😅, but why not?

At least for appimage, it doesn't create application launchers. And it's 50/50 whether the icon in the window list works or not.

I also build a lot of Docker images, and container formats throw a wrench in that if that's the only way the application/utility is packaged. So I end up building from source.

Personally, I use AM. Takes care of that and more.
- https://github.com/ivan-hc/AM

It is CLI and I'm GUI by nature, but AM is easy enough for me. Just yesterday I did a simple
am -u and got the latest updated versions of qBittorrent, FreeTube, yt-dlp etc. (I.e. the kind of program that system packages are too out of date to work safely or even work at all.)

There are other options like zap (CLI), Gear Lever (GUI) and just recently I believe the Nitrux distro came out with a complete AppImage software manager. (Checking it out, https://github.com/Nitrux/nx-software-center , it seems it pulls from AppImageHub.com, which unfortunately has largely been forgotten by developers, a lot of software is either out of date, unverifiable or completely absent. AM is much more up-to-date, pulling the latest AppImages mostly from official GitHub repos.)

I already have the system package manager. Everything else that isn't it doesn't manage my system and is doomed to suck.

Emerge, baby!

Gentoo nerds represent!

Why is there such a shortage of gentoomen on lemmy? Where the gentoo homies hanging? Prolly irc still, huh? 😮‍💨

Hey, IRC was federated before federation was cool.

IRC federation is closed

It's also 36 years old. I think we can cut it some slack 🤣

There's a lot on reddit. Maybe someone should take the journey and inform them of Lemmy.

If it's not in Apt, I just run it in docker.

For regular apps? Like a media player?

For anything CLI based, anyway. I also run Webbian in Docker for GUI, but those are special use cases.

You almost blew my mind out there.

How the hell do you learn to use nix. I'm not a programer but figured out how to run gentoo just fine with the guide. nixOS feels like I'm in a mirror maze in the dark and the room is rotating.

Well, Nix is a programming language, so there’s no getting around having to learn basic principles of coding.

That said, I feel like coming into Nix with a lot of programming experience actually worked against me at first, because I made a lot of assumptions that weren’t true and basically had to “unlearn” certain things.

The main things being:
- Lazy evaluation is trippy as hell sometimes
- The language truly does not allow for side-effects. Everything you might think is a side-effect is really executed from outside the language runtime itself
- It might be more accurate to think of Nix as a database, where the keys are the parameters of what to build and the values are directories full of the built artifacts

What really made it click for me was seeing how a derivation object is basically equivalent to a path. So if I do ”${pkgs.foo}/bar”, that’s the exact absolute path (plus /bar) where Nix will end up storing the output of the pkgs.foo derivation. Even without actually building the derivation, you can know where it will end up.

Anyway, the documentation is pretty shitty, so you basically have to scour every community resource you can find and read way more of it than it seems like you should have to. Discord/Matrix servers help a lot too. And learning to navigate the source code for nixpkgs.

Also: Don’t start with NixOS, imo. Start with dumb throwaway stuff where you make a derivation that downloads a file and unzips it and runs a single command. Once you understand that, do something that requires understanding a bit of nixpkgs, like using overlays. Then you can use NixOS. Otherwise, there’s too much going on all at once.

Edit:

  • Nix pills is good
  • Vimjoyer is amazing

I need nothing but apt or dnf. Miss me with that other junk.

I use apt and flatpak. They both are good for what they do.

Why do you need flatpak

Because it just works. After being with computers all day fixing the insane problems that other people create I just want to come home and press buttons and have things work

I use boring Debian, so apt and older packages, and flatpak for a few programs that I want up to date.

When using certain apps I prefer them being containerized on my system. It's case-by-case for me. I keep steam containerized, my web browser containerized, etc.

But..why

In the case of steam and web browser, the containerization means I can control their access permissions via flatseal. This adds another layer of security, since they're both web-accessing applications, and it's easier than setting up a VM to run those applications.

If you are going to be running an Atomic/immutable distro, you really want to use things like flatpack/snap/appImage to keep your user space separate from the OS.

Oh, you can sledgehammer an rpm/deb/what ever into the underlying OS. But if you do that, why did you choose an immutable distro in the first place? It's kind of the whole point.

Why do you need flatpak

Not OP, but I like Flatpak (in addition to Apt) because it doesn't require escalation to add or remove packages, so my kids can self-serve adding or removing games.

Flatpak is a common way to install something newer than you can get in your repo. If you are using apt in Debian Stable, Flatpak is a miracle. This is even the reason Ubuntu installs Firefox as a snap (their version of Flatpak).

ensures software support when the developer in question is a moron

Weird way to spell pacman

As an Arch user for many years, my question is when is Arch going to ditch pacman and upgrade to APK 3?

I've never used it -- what do you like about it?

That's because we are...

If .y Firefox will once again be updated without asking me and then refusing to open any page without a restart I'll fucking lose it

Wait hold on wait, does that bullshit have something with Firefox being distributed through Snap?

If it does, I'm going to sn... also fucking lose it

Yeah, it's snap

Always updating without letting you know, without asking and it's ALWAYS at the most inconvenient time

Ah gotcha, it's not the cause but it makes the problem way worse

It basically IS the cause as it's the system doing the updates without asking. But snap has other issues too. For one, it's the slowest installer in recorded human history, it takes literally ten times longer on snap to install anything. Why? Beats me, in theory it ought to be faster as it shouldn't have to resolve dependencies but here we are. Try installing anything with snap, it takes forever.

Then, snap is closed source eon the server side, so fuck all of that, that's already 200% of reasons not to use it ever. I don't trust closed source software anymore

By "problem" I meant having to close Firefox before further browsing, not automated updates - I don't know if I could stand daily-driving a system with Snap updating my stuff while I'm trying to use it tbh, that's one of the main reasons I left Windows behind.

Your first comment gave me the impression that Firefox required a restart because it's distributed officially through Snaps or something, idk 27 days have passed since then

The required FF restart after updating is indeed an FF thing, but in combination with snap just updating without asking is extremely annoying.

I have bad news four you ....

(TBH I am not sure, but as I remember, this problem was specifically a snap problem.)

Nix is just across the street sipping tea because it understands what it is and is at peace with the chaotic world around it.

Gentoo is too busy compiling to notice what's going on around it

If you want, you can also compile everything with Nix!

I use NixOS and Flatpak (Nix-Flatpak) to install software that is not available in Nixpkgs. Unlike Arch's AUR, Nixpkgs has fewer popular packages. However, Nixpkgs beats AUR in terms of quantity because many Nixpkgs packages are redundant.

Nix organizes Bohemian Grove.

A rusty bucket riddled with holes and the stick part of a shovel is better than snap for running software.

Only tangentially related - but a friend brought over a new kubuntu install and Canonical had the cheek to demand money for VLC patches?
They don't fing own VLC. What the actual f is going on over there, Canonical?

Mark Shuttleworth is a greedy bastard and it’s finally starting to show.

Eh. He's done more for Linux than you, I, or anyone else in this thread for that matter.

He came into a vacuum created by Microsoft being litigious in the 90s. There were other companies already doing a better job. (Caldera, for example) As with many rich assholes, he was simply in the right place at the right time with millions already in hand.

Is it backports for an old version?

I don't know, this was for a system on kubuntu 24.04, the latest up there.
I removed it, replaced it with debian and kde - my friend isn't a gamer, doesn't require anything bleeding edge, so that was just a better choice in our opinion.

I have really started to like AppImage. You just download a single file make it executable and it just works.

I use Cursor for coding, and it has an appimage that replaces itself when it updates.

That's cool and all but it would be even cooler if you could just install and keep it updated through your package manager

I use AM package manager for that.
- https://lemmy.ca/comment/16209551
- https://github.com/ivan-hc/AM

That's cool.

It would still be even cooler if the app makers just packaged them for distros. Or even just Flatpak.

But that's a cool project I'll keep it in mind for my next go with an immutable distro

I do wish something like AM's functions was built into an all-in-one package manager for my distro. The closest I found was bauh which handles "AppImage, Debian and Arch Linux packages (including AUR), Flatpak, Snap and Web applications". Which seems like an all-in-one solution.

But the problem with bauh (that last time I tried it) is that it accesses only a small number of (often very out-of-date) AppImages from the largely moribund AppImageHub.com, unlike AM, which pulls in the latest releases from loads of GitHub repos, and adds more on a frequent basis or request.

Or even just Flatpak.

AM was started because flatpak sucks.

  • With flatpak devs can't agree to use a common runtime, so the user ends up with a bunch of different runtimes and even EOL versions of the same runtime, making the storage usage 5x more than the appimage equivalent and this is much worse if you use nvidia which flatpak will download the entire nvidia driver again.

  • flatpak could not bother to fix the hardcoded ~/.var directory, something that AM fixes by simply bind mounting the existing application config/data files to their respective places when sandboxing which yes it is able to sandbox appimages with aisap (bubblewrap).

  • flatpak threw the mess of handling conflicting applications to the user, so you have to type nonsense like flatpak run io.github.ungoogled_software.ungoogled_chromium, AM just puts the app to PATH like everyone else does, even snap doesn't have this issue.

Having experienced Flatpak bloat and seeing your posts here, I might just have been converted. The Flatpak integration on my distro is neat though. But I already use Aptitude for most of my package management needs, so I guess adding AM to my toolbox doesn't seem too bad.

Some AppImages have that built in, like Ente.

That’s kind of the point though. One of the foundational pillars of a good distribution is mature package management, and that includes not relying on self-updaters that will pollute your system with untracked files

Absolutely, but don't AppImage updaters basically just replace the AppImage? They're self-contained, no?

updating Hello World program

Some apps are a bitch and a half for some reason, other apps just work

Make a .desktop file, slap it in ./local/share/imdrawingafuckingblank and boom, it's integrated into your shell menu like any other app

The Nexus Mod App and Foundry VTT work flawlessly and it's so nice

As a somewhat Linux noob I just made a folder called ~/Apps and launch them through terminal. Not ideal, but I don't care enough to fix it.

Your suggestion makes me kinda want to fix it though. Doesn't seem like to much work

I've used Linux for years and I also have a ~/Applications folder where I put AppImages, applications cloned with git and stuff like that in. E.g. I have the last Yuzu AppImage in there, since it got taken down, but I also made a .desktop file for it, so I can launch it through the application menu. Btw, you should be able to just double click AppImages in your file explorer to open them.

appimaged does exactly that automatically for you.

see: https://streamable.com/dm575h

With that said I prefer AM, because it also adds the applications to PATH, meaning you type yuzu on the terminal and it launches yuzu as well.

Maybe I should install one of these but I would have expected Fedora to come with something like this preinstalled tbh

but I would have expected Fedora to come with something like this preinstalled tbh

Fedora is just plagued with poor decisions, and that's expected, it is the testing ground of redhat and not something that regular users should be using, they even go as far as repacking existing flatpaks just because and then break them.

A while back they pulled this nonsense that not even upstream approves of: https://gitlab.com/gnuwget/wget2/-/issues/661

iirc fedora also enabled wayland by default on gnome in 2016 when pretty much nothing worked.

Rhino linux lets you install AM thru its GUI installer btw.

Also a noob and this seems like the most reliable way for sure. As long as I'm in the right directory I'm good

Add that directory to $PATH so you can use those apps in any directory

Change ~/Apps to ~/bin or ~/.bin & you are doing it like a seasoned pro.

Completely ideal, actually.

AM puts all AppImages in /opt for me, as well as automatically creating menu entries, easy updates etc.
- https://github.com/ivan-hc/AM

Flatpak and SystemD Portable services are actually pretty good.

That's the direction I see Linux going. I personally use NixOS because I am sad.

I looked into Nix but it seemed like it locks you into using bash for your shell. Is that the case?

Sorry I was meaning in the context of using nix-shell for isolated reproducible environments. I read that things can go wrong if you try to use a shell other than bash

You could use something like nix-your-shell.

Excellent, ty for showing this to me

If flatpak didn't make me put the entirety of KDE onto my system (thats an exaggeration but you know what I mean) I'd gladly crown it king of the package managers.

Plus make it hell on earth to a) access drives other than the one flatpak is installed on, b) interoperate with non-flatpak applications, and c) retain any amount of free space on my drives (exaggeration for effect).

Yeah, flatseal should come stock with flatpak IMO. You will have to configure many apps to get them to play nice with your system.

This is a "security" feature and I'm so tired of it. Same thing with Wayland, random crap doesn't work sometimes

Wayland is trying to replace a standard that people have been saying is obsolete for a decade. I'll give them a bit of leeway.

I just want to point out the dependencies of Konsole (arguably a small and simple application in concept): glibc gcc-libs icu kbookmarks kcolorscheme kconfig kconfigwidgets kcoreaddons kcrash kdbusaddons kglobalaccel kguiaddons ki18n kiconthemes kio knewstuff knotifications knotifyconfig kparts kpty kservice ktextwidgets kwidgetsaddons kwindowsystem kxmlgui qt6-5compat qt6-base qt6-multimedia sh.

Psst .. the first KDE app you installed via your package manager also put "the entirety of KDE" onto your system.

At least if you install other apps you already have KDE. If you install another Flatpak, it's likely this will need another version of the KDE runtime, so it's 2.5 more GB for a 450kB application.

i don't think I use any kde apps on my system at all

Indeed. As much of how loved and popular KDE is, fuck it. I use the glorious XFCE. XFCE is beautiful too. Fuck, I'm not the maniac who would waste 2GB just for my DE to look beautiful.

Flatpak does not install KDE by default. It is only required if you install a KDE app. You can hardly blame it if you do that.

Haha, I break snap a lot less than the others, and it took a bit to figure out the differences. Appimages are annoying af. Flatpaks are my favourite when there isn't a good old .deb. I recently broke Flatpak though so it's on my naughty list. Snap still chugging along for some reason, I just wish the permissions weren't so crazy strict (Nextcloud).

Speaking of all this, I realised I've accidentally installed some things twice. Is there a good way to list all the different package managers together to see what is duplicated?

How do you break a flatpak?

Asking the real questions here.

I broke Gnome and now I have Flatpaks that don't launch. I don't want to reinstall so I am slowly fixing things.

You can try flatpak repair.
Or it could be a leftover .desktop file for that app.

You can check if that app is still installed with flatpak list

Yeah that isn't the problem haha. I have deleted something gnome is not happy about. This has been a few days of tinkering. I think I actually just might have fixed it. Fingers crossed, anyway.

I once uninstalled a flatpak and it rendered another installed flatpak unlaunchable. Not even the repair function would fix it. Ended up having to use timeshift to rollback. Not sure if that was the fault of Flatpak or that one specific app but it was pretty frustrating.

How exactly are appimages annoying? I think they are awesome tbh

I want a centralised app manage, not 50. I'd probably stick them in a folder and forget them if not for Gear Lever.

So, I would say the primary complaint should be a lack of package management.

https://github.com/ivan-hc/AM

Oh perfect, they added this to topgrade.

https://github.com/topgrade-rs/topgrade/pull/423

But yes, they hyper trigger my ocd because I cannot manage it all in one place and they just float around as a seperate entity. I just discovered Bauh too which can manage them. The problem there lies that you have to choose one manager now to manage them all and they don't all just detect them like a flatpak manager. They're too manual. The more that these things are separated the more time I'll spend fucking with them and that's the last thing I need. I need them to be all in one place and standardised to stop my bad habits. It's too much extra shit. I get why they're good, it's just not for someone that is not a dev thay actually needs to do other work.

what

Is topgrade used to update all the package managers at once? how many stuff are you using that you need that???

Different users need different things. Not everyone can run a bare bones Arch setup. I'd use it anyway even if I didn't have a lot of updates. It's the centralisation that's important. It even updates Docker containers and windows. I have several devices I can just automate now. It's a set and forget.

AppImage is a package format, not a package manager. Same with tar.

So, I would say the primary complaint should be a lack of package management.

So, I would say the primary complaint should be a lack of package management.

https://github.com/ivan-hc/AM

Still don't know how I'm supposed to add dictionaries to FF on snap. So many little issues like this with snaps.

Even OCI containers are better

Let's not get ahead of ourselves

snap uses containers

Sort of

They aren't OCI containers and the sandboxing is weak at best

To me, namespaces = containers. I don't know much about OCI, I only know how namespaces work.

Apt is kind of broken, to be honest. No package should have full system access during installs or execution.

AppImage is the no-nonsense universal package format.

Absolutely my favorite. Just download and go. Super portable.

by
[deleted]

Deleted by moderator

 reply
5

It would, if there were no other options for package management. Package formats don't have to be either/or. My systems typically end up with mixes of native packages, flatpak, appimages, and you could technically consider Steam a package management system as well.

AppImages have a lot of problems

Like not updating or shared dependencies duplicated for every single app image

Just use flatpak

or they somehow still find a way to not work. I can count the number of times i had an appimage just work, and it is exactly 2. Any other time i had crashes

Last time I read something from the main dev I almost ran stright into the woods.

Also idk about how it is the management situation, portals integration, etc…

Don't worry, Snap: Flatpak and Tarballs are NOT better by much. And, chances are, the system package manager may be lacking in so many validation requirements that it's not iso27002-compliant and thus could be junk.

There-there, Snap. Most people won't even know why you suck.

Hadn't snap fixed a lot of the complaints people initially had?

Probably, but the stink will linger for quite a long time.

There's a burger place near my house that I use to go to almost every week. But then the quality started going down, and I stopped going there. That was two years ago. Maybe they fixed the problems, but I'm not going to know - because I no longer go there. Snap is like that.

I think the main complaint is that it seems like Canonical is trying take control of Linux packaging. Don't they handle their stuff in a way that pretty much prevents third party 'Snap Stores'? Like, their backend being closed source and their software only accepting their own signatures?

I dont know for sure so disregard what I say. but I remember reading that users could host their own snap repos but canonicals one was the only one at the moment. Everything about snap is open source except the webserver.

Yeah the API is open and there used to be an open store, but lack of interest ended up with the project shutting down. As it turns out people don't like alternative stores nearly as much as they like the idea of alternative stores.

Not the biggest: User choice.

Has it? My complaints are: I have to use VPN software for work that replaces /etc/resolve.conf with a symlink to another location, one that sandboxed snaps can't access. There's no way to grant them access; the "slots" that you can connect are fixed and pre-defined. You can't even configure the file path; it's defined right in the source code. Not even as a #define, but the string literal "/etc/resolve.conf". That seems like poor practice, but I guess they're not going for portability.

Also, I have /usr and /var on different media, chosen for suitability of purpose, and sized appropriately. Then, along comes snap, violating the File Hierarchy Standard by filling up /var with application software.

Minor annoyances are the ~/snap folder, and all of the mounted loopback filesystems which make reading the mtab difficult.

i just got an Ubuntu machine at work, and really simple packages are only available as snaps. so i guess i’m going to try out Nix home-manager

Like a bunch of old farts in a coffee shop arguing over which truck brand is better.

Yeah, but Snap is the equivalent of Tesla...

You want me to top off your coffee before you go home to take a nap?

Yes please, and more cake!

Now remember old fella you can't have cake anymore. It messes with your blood sugar.

I'd love to use flatpak more, but with my peculiar internet situation, installing a single package can take 6-7 hours.

What's wrong with Snap?

EDIT: I had minimal exposure to Snap, sometimes Snap was my only option to get some software on Linux in a decent version and without getting into dependency hell while trying to compile it (why can't someone make a package manager for C/C++?). I do see the issue with proprietary servers though.

What's wrong with Snap?

Proprietary servers.

Can you elaborate a little? I imagined this meant something like Visual Studio Code' Marketplace (which doesn't allow non Microsoft products to connect), but I don't see anything about that on Snap's TOS.

To be clear, I'm not saying you're wrong or anything, I'm just trying to understand.

People want a full open stack, and the server is closed. Its less a technical complaint and more a philosophical one.

Not the person you are asking, just trying to add context on why some find that problematic for those who are reading later.

I don't think it's a TOS thing, just a lack of open source server software? To the best of my knowledge, it's just not possible to host my own snap server. At least, I didn't find any solution when I looked. Which seems weird, for an open source operating system.

Surely it can be reverse engineered by the API that snap uses?

Surely it can be reverse engineered by the API that snap uses?

Uh... Sure...

But the competing options that require no reverse engineering are completely free, so...to each their own, I suppose.

ffs, no need for the tone. I'm not trying to defend them. Just trying to understand what exactly the problem is and isn't.

Everything else is FOSS besides the server and snaps can even be installed locally. I wrote a section of an article about most of the complaints. Most of the complaints I hear are just elitistic bullshit that makes new users confused and spreads misinformation.

A long time ago I needed to install a program. It needed snap I think. Well I googled and googled and googled and I couldn't just type "sudo apt install snap" for some reason. But there was a way to get snap if you had flatpak. I didn't have flatpak So I googled and googled and googled some more and I couldn't find a way to install flatpak that didn't involve already having snap first.

So then I never fucked with flatpak or snap ever again except for that one time I installed gzdoom in flatpak and it actually worked for some reason, the end.

Fuck flatpak, all my homies hate flatpak

Appimage>your inferior packaged application method