Snap out of it

it's called snap cos thats what the community will do to your bones if you use it. apparently

Install from source if there isn't a repo for the software.

Hardcore
- Way back in the before times there was only the source.

Why not just stick to what we've always been doing?

wget something.tar.gz
tar something.tar.gz
man tar
tar xzf something.tar.gz
cd something
ls -al
./config.sh
chmod +x config.sh
./config.sh
make config
Try to figure out where to get some obscure dependency, with the right version number. Discover that the last depency was hosted on the dev's website that the dev self-hosted when it went belly up 5 years ago. Finally find the lib on some weird site with a TLD you could have sworn wasn't even in latin characters.
make config
make
Go for coffee
make install
SU root
make install

I much prefer our modern package format solutions:

sudo apt install something

open

wtf this is like 6 months old

find a PPA hosted by someone claiming to have packaged the new version

search how to install PPAs

sudo apt <I forgot>

install app finally

wtf it's 2 months old and full of bugs

repo tells me to report to original developer

report bugs

mfw original dev breaks my kneecaps for reporting a bug in out of date versions packed with weird dependency constraints they can't recreate
We should normalize programs that don't use such exotic and impossible libraries that you have to do anything besides type "make" and "make install" for it to work.

In theory it's a no brainer. In practice not so much.
- in the end we end up using containers afaict

Linux noob here, can someone ELI5 why snaps are bad? And how does .deb works?

Nothing necessarily at the tech level. They're more capable than Appimages or flatpaks to the point that you can use it to build a reproducible system hardened against tampering or defective updates.

The downside is that it's controlled entirely by canonical, has limited abilities (if any?) for hosting storefronts/packages outside of their ecosystem, and said ecosystem is insecure and has already allowed multiple waves of malicious apps to reach end users because of poor moderation of listings masquerading as legitimate versions.

Canonical has also been increasingly hostile to flatpaks - removing it from Ubuntu and derivatives by default to push users towards snap.

The whole loopfs thing is just an annoyance, but the aggressive posturing by canonical as well as the closed nature of the storefront that has led to malicious attacks on end users is enough to give it more than a few haters.
The primary thing I hate about them is that every snap package appears to your system as a separate mounted filesystem. So if you look in your file explorer, you can potentially see dozens of phantom drives clogging up your sidebar.
Snaps are a standard for apps that Ubuntu's parent company, Canonical, has been trying to push for years.

The issue that most people have with them, is that Canonical controls the servers, which are closed source. Meaning that only they can distribute Snap software, which many Linux users feel violates the spirit & intention of the wider free and open source community.

Appimages and Flatpaks are fully open source standards, anybody can package their software in those ways and distribute them however they want.

.deb files are software packaged for the Debian distribution, and frequently also work with other distros that are based on Debian, like Linux Mint.
- Some further context on this that @[email protected] might want to know:
  
  While Canonical's snap store is proprietary (which, to be clear, I don't really like), all the client software is open source and the API is well documented (though a bit janky). Their snap store relay app (which is open source) has a full implementation of it. There was a fully functional open snap store for a while, but the project died out of a lack of interest. You can also distribute snaps through another mechanism and install them locally on the machine (though you then lose the benefit of snapd's auto updates). You can even do this with snapd still checking the signatures of the snaps.
  
  The standard for snaps is fully open, as is snapd itself.
  
  There's no need to oversell the negatives to the point of being wrong.
- Thanks, I recently needed picocrypt and not being comfortable with the terminal, snap were a rather convenient way to get it installed, I'll avoid them from now on.
I don't think snaps are bad (and when someone tries to explain why they are, about 85% of the time they say something wrong enough that I suspect they're probably just parroting someone else rather than actually knowing what's going on). It's sad, because if we could get rid of the bullshit we could actually have decent discussions about the benefits and shortcomings of snaps (and how to fix those shortcomings).

On the .deb front: it's a package format made by Debian. Each archive contains a data tarball, which has the files in the package in their full structure from /, and a control tarball, which contains metadata such as name, version and dependencies as well as pre-install, pre-remove, post-install and post-remove scripts, which are used doing any setup or removal work that can't be done just by extracting or deleting the files.

The upside of deb files is that they tend to be pretty small. The downside is that this typically comes from having a tight coupling to library versions on the system, which means upgrading a library can break seemingly unrelated things. (This is why you get warnings like this page: https://wiki.debian.org/DontBreakDebian) Many third party distributors (e.g. Google with Chrome) take care of this by packaging most dependencies inside the deb, inflating the size.

Another major difference between packages like debs and rpms and newer formats like snaps and flatpaks is that the latter have confinement systems to prevent apps from having full access to your system.
- Honestly if not for the convoluted Linux FS layout, debs would be pretty serviceable and aren't really different to the Windows solution. The fs layout makes installations way too fickle to clashing with other applications.
  
  That and dependency hell, which distros should have never been allowed to touch beyond the core dependencies required to get your desktop running.
- For me, it was snapd taking ~2.5 GiB of RAM.
- Worth noting that the confinement of Flatpaks and Snaps can have major drawbacks. It has been a major pain in the ass to get Flatpaks working nicely with fractional scaling (think tiny cursor, huge text, tiny text etc etc)
The snap store is some proprietary store Canonical runs, and snaps are friggin huge in size. I don't really know though as I don't use Ubuntu anymore
- Size isn't an issue imo. Applications are bulky for many more reasons than their packaging formats.
- The first two snaps I compared sizes of on my system are uv and bitwarden. The uv snap is 9.5 megs vs. the wheel's 12.2 megs, and the bitwarden snap is 97 megs vs. the Deb's 79 megs and the AppImage's 114 megs. These seem pretty reasonable - doubly so since snaps also have delta updates.

I don’t really like neither of the 3, personally. But I understand the need and the benefits

I feel like that's a pretty good take. As long as you're getting the software in an elegant way that doesn't break the dev's back, we're good.

Native repos > AUR > compile from source > Flatpak

Mine is

AppImage > Native repos > AUR > Manually compiling from source > Finding an alternative

I don't like installing software that doesn't need to be installed, thus I like AppImage. Pretty portable. That also applies to compiling from source. Yes, my home directory is a mess.

I have yet to find a need to go outside of the Debian repos.

Artix repos > Arch repos > existing AUR package > create my own AUR package

No need to use any of these flatpak/appimage/snaps when I can just make a package for my distro. Most software is not difficult to package.

This may be true from your perspective but won't sway over many newbies / plebs who don't have the knowledge (yet) or who simply do not have or want to take the time for self packaging.

And flatpak, snap and appimage tend to become the standard to get verified, tried and tested software hosted & supported by the official maintainers or the company behind the software.

Now to the personal part:

There was a time when I was motivated enough to get packages from user repos - I actually never was motivated enough to do self packaging so maybe I have missed something world changing - but I got so tired of having to figure out the missing "optional" dependencies that meant the software wasn't working as expected and having to trust 3rd party maintainers when most stuff on flathub was "install & ready" and officially supported or at least hosted by a "verified" source. And maybe distro xyz has a mindblowing solution to all my problems but for the moment I am happy with what I have and not looking for yet another distrohopping and yet another point was whilst distrohopping it was soo easy that I could use the same install.sh containing all my favourite flatpak apps & the "applications" folder containing my favourite appimages no matter if I was on a Debian, RedHat, Arch, ... based distribution.
- I never claimed I was trying to "sway over newbies"? Do what you want, this is just my personal preference.

There is no software that is not in AUR. I use arch, BTW.

But yeah, sometimes I just compile from source, if needed.
- That’s exactly what the vast majority of AUR packages do already? You can also apply modifications to the compilation process if needed.
My software, QuickDAV, is not in the AUR. It’s open source, and I release it only as an AppImage, because I am lazy.
- I guess we should have added the word “notable”
  
  I’m terribly sorry, you left the door wide open ;)
  
  I’m curious, what makes AppImage a good choice for the lazy developer? Is it easier to create?
- There's so much random, useful software distributed only as appimages. But not notable enough for packaging fanboys.
i use arch based btw (I love my Manjaro and it's AUR support) :>
Gatekeeping the word "software" here?
Here's something not in the AUR. Tested on arch
- Clearly we need an Arch version of rule 34 and rule 35
  
  Rule 34a: If linux software exists, it's in the AUR. No exceptions.
  
  Rule 35a: If linux software is not in the AUR, it will be made available in the AUR.
https://youtu.be/V1mOWypIFRM

Native package manager > Native binaries > AppImage > Flatpak.

Yes, snap isn't even on the scale.

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.
- 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
App images are a very Windows way to do things. They bundle everything so they are big
- 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.
- 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.
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?
- 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.
- 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.
And the last three aren't even an option in the enterprise unless your CTO is 24.

cant we just have .deb?

On arch?
- If you look at some aur packages, it's probably deb...
- I was going be a smart ass and make the "I use Arch joke"... But if you can use .debs on Arch, that's kind of neat.
- we got tar.zst
The issue is with pushing updates. Eget is nice, but it doesn't push updates.

If you don't compile from source, do you even Linux?

Linux From Scratch user detected
- Or Slackware
- Ah ... yeah ... totally. I would never use some filthy peasant distro like Mint. No sir! Never never ever!
AUR changed my life
- Did someone's script wipe out your tax returns?

Compile from source
Find alternative
Deploy in VM/Docker

If I wanted snap, flatpak or appimages, I would use windows. Shared dependencies or death.

Shared dependencies or death
Docker

🤔
- I don't like middle grounds in my packages, what can I say.
  
  Docker containers are treated as immutable and disposable to me, like a boot CD, for each, I write a shell script to generate both a .conf if needed, a docker-compose.yml and run the container.
  
  They're plug'n'play separate parts to the rest of the OS, while packages are about integrating nicely with the rest of the OS, in a non-snowflakey, non-disruptive manner.
  
  I also hate .conf.d folders and always deleted them. One program, one .conf.
Flatpaks and snaps both have shared dependencies, just at a less granular level than debs. OCI images and VMs are pretty much the extreme opposite of shared dependencies.
But snaps do have shared dependencies to a degree. Also, do you use gentoo?
- No, that's not what is meant by shared dependencies, and I don't use Gentoo, I use Debian.

I’m currently on a atomic distro, so how I get my software from favorite to least favorite is this:

Flatpak
Appimage
Fedora distrobox
rpm-ostree

finally, somebody in this thread who doesn't live in the past.

System package manager is for system binaries. Not for applications.
Have you met nix?
- Nix is cool but also incredibly painful
os-tree is slow as molasses
- As it should be, don't do that.
  
  Doctor, when I do this it hurts...
  
  Also, you're creating a disk image...
- It is. I also wonder if there was a model that accomplishes the same thing but with less image copying.
  
  Like, make snapshots every day, but manual installs are not snapshotted but still tracked with ostree. So you can revert them, display them transparently etc.

.deb first and then flatpak if not available as on deb repo or if deb version is outdated. Never used appimage or snap. Rpm just as good as deb when I use Fedora. Flatpaks are much larger in size which is why I first go with the deb version.

Nix, if not in nix pkg for nix, then nix

I .... I don't have any of these problems....

Am I missing out on shit? Have I Grandpa Simpsoned?

AUR. If it doesn't exist on AUR (very unlikely, but happens sometimes), I make a package for it.

On non-arch distros, I often use LURE.

How safe is LURE?
- I only use my own installer scripts with LURE, so I'm not sure about the safety of the publicly available repos. But the project itself seems to be pretty solid and reliable.

I hate fucking snap. It might be enough to make me switch distros if Ubuntu keeps up with it (which I am sure they intend to).

The continual "you have new snaps" or whatever it was message every time I'm just trying to have a web browser open made me eventually figure out how to install firefox for real on all of my computers.

EDIT: I think you may have convinced me to try out Debian on my next OS installation.

The Firefox snap was the reason I left Ubuntu. (Or, the last straw, at least.) Fedora has been wonderful.
They've been doing snaps for a few years already so it already seems like they're keeping up with this bullshit (in fact they're putting more and more stuff there) It's already the reason people stopped recommending Ubuntu to new users and instead go for Mint or Pop!OS
Try debian, they improved so much over the past decade, they're a better Ubuntu than Ubuntu now without any bullshit.
- What do you mean "improved"? Ubuntu is based on Debian.
Make a script to extract it to /opt/local and make a symlink.

You'll end up using it so much and it's an easier upgrade on your terms.

Download the sources and build it, like Kernighan & Richie intended.

sounds like a modern approach

Appimages are crap too, but at least there is progress with AppMan, repos and that sandboxing solution.

Snaps are only sandboxed with Apparmor and snapd only allows a single repo (which contained malware multiple times) so get the hell off my lawn XD

Just use flatpak. It runs and installs local but still has the benefits of a package manager
- Yup.

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

Since i use a gaming arch based distro (Cachyos) the aur

as it should be, nobody likes proprietary vendor-locked formats that get shoved down your throat

curl

|sudo bash
- very smart much secure
- I don't remember what program it was, the dev explained it wasn't available as flatpak because flatpaks are unsafe or something. Then the installation guide went "well anyway here's curl | sudo bash." Like, lmao. Talk about bad security practices.

AUR or flatpak.

Honestly the longer I spend daily driving Linux the more I enjoy using flatpaks...

I try my hand at packaging it for my distro.

the hero we need

Wow a reference to those Mac Vs PC ads from like 15 years ago

They stopped that ad campaign about 15 years ago, and they started it closer to 20 years ago.
I am fairly certain the original version of this meme has red shirt saying Linux and getting beat up

AppImage, build from source, or don't bother

Compile from source.

Every February, I emerge qtwebengine to keep us warm.
- Lol. It's not the groundhog we should be watching, then?

For some reason the first time I read it, I thought it was an "L" so now I always call them "Apple mages"

OCI

Wow, this escalated quickly.
What is that?
- They probably mean Open Container Initiative (OCI), the protocol shared by Podman and Docker.

I pretty consistently find the snaps to be the best trade-off of being up-to-date and stable for me. Especially for CLI tools and services.

Build from source

I have a few source built packages that I use every day.

Loading up my system with several development libraries to compile a program is preferable to taking a giant dump on my system in the form of soypacks.
LFS Ftw!

If not in Fedora repos or any Copr, then AppImage (manage using Gear Lever for that ease of use) then Flatpak

If it's C or C++, I get the source from the project's GitHub / GitLab / Source Hosting thing and compile it for myself.
For programming languages that I don't read, I usually use the AUR.

Also,

GoG for games
Xilinx website, for that one time, I got the ISE
AppImage sometimes

God that's painfully me.

Except I moved to lxc and zfs with homebrew scripts for most now, pass containers around the network like candy, including an arch lutris one.

People spend a lot of time on this one. It must suck to be losing to snap.

No one uses app image anymore

this is probably an edge case but I do when i visit family and friends. these trips are short and infrequent enough that a laptop would be an unnecessary expense and i'm not driving through mountainous areas with my tower. none of them use linux. most have aged windows or mac machines. they don't care if i run a live system or puppy linux from a USB drive. i add a handful of appimages i'll use at night or if there's free time. I'm sure there are better ways but it works for me.
- If it works for you then it works, no need to switch it up. I guess one other way of doing it would be a persistent install on that USB.

Native binaries

Snap

Snap'd