How do you guys get software that is not in your distribution's repositories?
deb
this post was submitted on 16 Sep 2024
847 points (97.5% liked)
linuxmemes
24675 readers
1517 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
3. Post Linux-related content
sudo in Windows.4. No recent reposts
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations.Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
If I could, I'd compile all my software from source. Unfortunately, it seems a lot of open source developers don't like writing software in C, which means the burden of sorting through dependancy-hell has been deferred to my shoulders instead.
In that case install Gentoo. Compiling everything from source is its thing. And on the way it will resolve all the dependencies for you. The dependencies you want.
I understand appimages. I use them exclusively. Can someone explain what flatpak and SNAP are and how they work? I have autism so please be as clear and concise as possible?
The easiest way to think of it is flatpaks are AppImages with a repository and snaps are flatpaks but bad.
That has benefits and detriments. Appimages contain everything they need to run, flatpak's mostly do, but can also use runtimes that are shared between flatpaks.
All flatpaks are sandboxed, which tends to make them more secure. AppImages can be sandboxed, but many aren't.
Flatpaks tend to integrate with the host system better, you can (kinda) theme them, their updates are handled via the flatpak repo, and they register apps with the system.
AppImages are infinitely more portable. Everything's in one file, so you can pretty much just copy that to any system and you have the app.
That was a fantastic explination, but you forgot to explain SNAP. Oh snap, you forgot SNAP. Intrusive though won. So what is SNAP, how does it work, and why is it bad?
Yeah, sorry couldn't resist.
snaps are very similar to flatpaks and, honestly, is technically better in a lot of ways.
Snap can be used for basically an entire system, while flatpak is limited to graphical apps. (Ubuntu core is built basically entirely off snaps.)
Snap is controlled by canonical, and the backend for the snap repo is entirely closed source. I've heard snaps are also easier for developers to work with, but I haven't experienced that side of them.
Snaps automatically update by default where flatpaks don't.
Snaps also get treated as loopback devices when they're installed, which bloats a lot of utilities. (And they keep a few old versions around which makes it even worse). For example, you could run lsblk and if you're using snaps like 90% of it will be snaps you've installed instead of actual devices.
Flatpaks are also noticeably faster to start up, which for desktop apps matters, but wouldn't really matter for a server that's aiming for a lot of uptime.
The loopback device issue is the main reason I don't use snaps. I also like flatpak being completely open, but realistically that doesn't matter for much. There used to be an open snap store, but that shut down because nobody used it.
I tried to install Ubuntu and it kept uninstalling Command Center every reboot. Not a fan of SNAPs. Or Canonical. But thanks for the explination.
Yeah, imo the problems solved by using snaps for core system stuff are better solved with immutable distros, and I see very little reason to use snaps for anything else.
Install from source if there isn't a repo for the software.
Hardcore
Way back in the before times there was only the source.
it's called snap cos thats what the community will do to your bones if you use it. apparently
I have yet to find a need to go outside of the Debian repos.
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.
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.
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