deleted by creator
Dependency hell every day
Damn near 25 year Linux user here, servers, desktops, everything. I haven’t seen a single dependency issue in over 5 years.
Quick question can you suggest some lotto numbers thx
deleted by creator
I get what you mean, but the way you worded it makes it seem like you experienced dependency hell for 20 out of 25 years…
Dependency hell happens when you try to go against your distro and install something. Someone who used Linux for 20 years probably found a distro that works well for them, hence the no dependency hell.
Or they just stopped tinkering. Either case is solvable by Nix/Flatpak/Bedrock/20+ other solutions
Yeah, could have worded that better. I’ve had some dependancy issues here and there over the years, especially in the early days (20+ years ago) but since like 5 years or so I haven’t seen anything
ffmpeg was like three weeks ago
What happened with ffmpeg ?
I’m genuinely curious too. Was there a big update? Bad interaction with the new plasma? I know they added av1 last year but I looked like a week ago and atsc 3.0 and ac4 audio still didn’t work.
Did that cause breaks on certain distros? No issues with it on Arch.
Hmm. I’m not finding anything on it now, but all my hosts at home started asking which package provider I wanted it from
ಠ_ಠ
So lucky ones do exist after all
Or they just use a distro that doesn’t frequently break dependencies. I used to experience lots of dependency issues on Ubuntu many years ago. Been on Arch for ~10 years and have only had 1 dependency issue, which was fixed within 1 day.
Haven’t had any major dependancy issues for years on Ubuntu. Maybe tiny things where I had to manually download a package somewhere because I use external repos, but those are easy fixes.
It’s a personal anecdote, sure, bit I’ve seen this issue become a non-issue, really.
deleted by creator
It’s common on Ubuntu/Debian. They’re stable releases, plus there are repos for them all over the place. This unfortunatelly leads to dependency hell, sooner or later. If you use only the provided repos, that will most likely never happen.
Not really.
I’ve been on Ubuntu for decades now, and I’ve done some crazy shit in my time. External repos indeed do increase a risk-of but it’s exceedingly rare and easier to fix these days
deleted by creator
That is true… though dll hell was also somewhat of an issue with Windows, but they managed that with WinSxS.
This is why rolling release distros are the way to go for desktops. I found this out early on. But, on the other hand, I get that people in corporate environments like to use stable releases.
I would suggest Void as a really stable rolling release distro for personal use (corporate probably won’t go with this, there is no legal entity backing the distro, it’s just a bunch of people maintaining it). It’s not bleeding edge like Arch, but more like cutting edge. They do pick and choose when to update/upgrade to stable releases of kernels and other packages, so it really is a lot more stable than Arch.
Sounds like that tool was badly packaged then, as no package install should just bork up other packages, let alone your gui. A SEO tool definitely has nothing to do there, so yeah, bad package. Always check what the package manager tells you before installing
I mean luckily distro maintainers usually deal with it (quite a lot of work) but have any additional repos and it gets wonky if those are not in total lockstep.
That’s a Debian/Ubuntu specific issue. Repos all over the place, so yeah, you will break things eventually.
No it isn’t, any distro might have these issues if they have third party repos. openSUSE commonly has these conflicts with Packman.
Yeah, that is true as well. I meant Debian/Ubuntu because it has the most 3rd party repos available. But yes, if you have more than one package manager, then things will most likely go south after a while as well.
Well not two different package managers but just two repos from different people (so hard to keep deps in sync). Packman (the third party codec repo for openSUSE) is slower to update compared to official repos, which often results in a situation where a thing from Packman requires a different version of a library than stuff from official openSUSE repos. But in that case it is easy to solve (for the user) in that you’ll just have to wait a bit for Packman people to figure out the situation.
Oh, packman, I misread pacman 😁.
In over 5 years? Like when containers and flatpaks became popular and include all their dependencies? Or when RHEL8 introduced app streams to help combat dependency issues?
Yeah, to be honest, they’re less and less common, especially with rolling release distros.
I just had one yesterday trying to get Mobile Verification Tookit going on my laptop. I mean I just had to manually find it and install it but it was still a very minor issue.
But Flatpak packages don’t contain the Runtime dependencies. Those are shared among all Flatpak packages. AppImage bundles everything.
deleted by creator
I get what you mean, especially regarding stuff like Python 2 vs 3 and the like. In that case it’s mostly an upstream issue. The Python devs disregarded this very important aspect and we’re stuck bearing with it.
Excepting those problem children, dependency hell is a solved problem. When people complain about it today I assume they either:
- Are struggling with badly designed backwards/multi version compatibility of a specific library; OR
- Never went through actual dependency hell, be it either early 00s Linux package managers or Windows DLLs. Then they see an easily solvable package conflict and think that is dependency hell.
4GB of dependencies shared across loads of apps
The horror… That’s almost 0,4% of my drive!
Its good if all many apps use them. But the problem is when you have to install one 10mb app and it pulls 4gb deps.
Also i don’t know what is flapak runtimes which are big and different versions of them are required for different apps
Indeed, for a single app it might be a lot, considering it’s a single app. But even then it’s not a lot of disk space out of what people have. But with every additional app, that additional space use lessens thanks to shared runtimes and dedupping.
Also i don’t know what is flapak runtimes which are big and different versions of them are required for different apps
I think a few of the most used one cover most apps, but even with different runtime versions and I think even different runtimes, thanks to dedupping it should only use extra space for stuff that’s actually different between the two. Two instances of the same library in different runtimes would only use the space of one, afaik.
Yeah. The problem is when I want to install one flatpak app and it takes space.
Are thoose runtimea like a library itself? The runtime itself seems to be using more than a hundred megabytes of space. Isn’t the deduplications applicable only for libraries used in different runtimes but runtimes itself uses space, right?
Runtimes are collections of common libraries. The idea is that instead of everyone having to bundle everything, they can use the same runtimes. Yes, dedupping only takes effect when you have multiples of the same library.
Well, at least with FlatPak the dependencies are likely shared, if applications are in the same ballpark.
Contrast with docker style where everything bundles their own dependencies so even if you have identical containers, you have essentially duplicate content wasting space.
4Gb of dependencies so far
I use Flatpaks mostly because I like having my base os and gui minimal as possible. Every thinking that is not core os I install as a flatpak. This is great because I didn’t have to install dependencies like lib32 and other libraries on my root partition. Lean and mean.
But doesnt each flatpak is packed with its own dependencies? So bascially you have the same dependency over and over.
No, each runtime is only used once. You only get duplicates for apps that use different runtimes or for dependencies that are bundled in the app.
dependencies that are bundled in the app
Isn’t flatpaks exactly this?
No, it’s a layered model like Docker. They depend on various images that can be shared across applications targeting the same runtime.
Didn’t know that, intresting, thank you.
Some are bundled, lots of the deps come from runtimes that are collections of deps. And many apps use those same runtimes. It’s sorta middle point between bundling everything and sharing everything.
It’s like a separate package manager with much less granularity than most distros packages. It’s a very clever implementation that has got its pros and cons, but massive duplication of libraries isn’t one of them.
You may be thinking of AppImage. That’s one file that contains everything.
deleted by creator
Yeah storage is cheap but I last reformated my boot drive in 2017 so my root partition is 20GB and now I have no room for Flatpak. Now I could just resize it but wheres the fun in that.
TL:DR “A 20GB root partition ought to be enough for anybody.”
You can have flatpak install it’s stuff into your home with the --user flag.
I feel your pain. Flatpack can really ruin partitioning strategies.
It has an installations feature to use any location, as well as users home by default.
Before I realized you could install as user and have it install on your home drive I just symlinked the install directory where i wanted to.
To be fair it’s 2024 and I’m still doing this, because adding an alternate location to install flatpaks in results in Flatseal not being able to detect those apps or edit those permissions. Just setting the default location as a symlink to where I want to magically fixes everything.
I seriously want to switch some of the small distros like tinycore as a daily driver.
1GB of RAM and 4GB disk space is more than enough for all but the most bloated apps.
I’ve put steam on a librebooted chromebook with similar stats, it has to install games on a usb drive/sd card but it works quite well even for casual linux gamers
Which Chromebook did you use?
Lenovo n42
i just gave up on that and have everything i can on one partition
Volumes FTW!
I use SSDs so it’s pretty quiet actually
Ba-dum-tss!
I was starting an install of Debian the other day, and it suggested 25 GB as the root partition (including /usr, but not /var, /home, or /tmp). I had to laugh. My server has a 50 GB partition for that purpose and it’s around half full.
I aborted the installation. Might try again later today. (Switching this machine from Kubuntu, using a new drive, so it’s not critical that it be done at a certain time.)
Depends on what you run on the server. A lot of the VMs I use for https://dnstools.ws/ have 5GB space and they use less than 2GB of it. They don’t have much installed though.
I was mistaken in my earlier comment. It’s my desktop machine that has 50 gb for everything but home, and it’s running very short on space. The server, which is what I thought I was thinking of, has 25 gb for / (not including /var, /tmp, or/home) and I’m using just over half of that space.
Format with btrfs if you use flatpack, it has deduplication.
I have to admit, I only have the barest understanding of this flatpak, snap, docker, etc. business. I’ve been using Linux since the late 90s and missed this development. I haven’t been following what was happening in the development end, I suppose - in part because there isn’t that much need to, because Linux has gotten so good.
But while I’m a power user (hey, I used Slackware until about 2015), I’ve found that I much prefer not having to spend hours and hours administering my machines every few weeks or months.
Sorry for the long comment. But this has been bugging me for a long time and you triggered me. No need to try to answer my questions if you’re not feeling it, I’m just dumping. You can stop reading here, if you like.
I’ve used a few appimages for limited cases - BalenaEtcher to burn HomeAssistant on to SD cards for my Raspberry Pi, and I think the scanning software I use is also an AppImage. The idea of having the libraries and binaries all together for certain things is a good one for certain cases, such as software I do not use regularly. BelenaEtcher strikes me as a perfect use case for appimage, because I don’t want to spend time installing Balena and keeping it up to date or uninstalling it, when I’m only likely going to use it once or twice. I never even move it out of my Downloads directory, just download, run, and delete.
Ubuntu (I use Kubuntu) moved Firefox to a snap image some time back. I get it, sandboxing, not a bad idea. But I’m pretty sure I had one installed by root, and one erroneously installed by my user account, possibly caused by forgetting to “sudo” during an update one day (I’m really not sure how it happened). And that latter one, if it existed, was almost certainly sitting in my /home directory somewhere, because my user account doesn’t have authority to write to /usr or /opt or anywhere like that. I didn’t plan to install software in /home, and didn’t allocate space for it, and don’t really like the concept in general. (I’ve switched debs for Firefox, and think I got the snaps for it cleaned up.)
If we’re going to do images installed by users, /opt seems like a much better choice, albeit with some controls - maybe /opt/username/ with permissions set by user; I’d be okay with the user account being able to install there and being unable to screw up system files. My current backup strategy involves grabbing everything in /home with a few very specific exceptions, and clearly I don’t need the current release of Firefox on my backup.
I have OpenProject (community edition) installed for keeping track of a restoration project I’m working on, and I’m pretty sure I used docker to install it. I have to admit it was easy to install (but so are debs 99.9% of the time), but now I’m wondering about the best way to get the data back out so I can migrate that software to my server (it’s running on my desktop because my server was that 2008 computer). I assume I can backup and restore, but I haven’t yet looked into this. Or heck, maybe it’s possible to just move the Docker image, the way I moved the HomeAssistant KVM image. It looks like the data is stored in a separate volume (which I interpret to mean a file that acts as a virtual disk, similar to how KVM has a virtual disk for the OS and apps in the virtual machine). Also, I’m not clear if docker images automatically update or if I should be updating them manually.
Then there’s Zwift. Zwift is a virtual cycling program that runs on Windows, Mac, Android, and iOS. No Linux client, which isn’t a surprise. I have a whole Windows 10 computer in the basement that only runs Zwift, and it’s my only Windows machine that I use. But, someone created a docker image of Zwift! I tried it on my Linux desktop machine a while back, and it worked. Very cool! But Zwift updates the program regularly, introducing new bugs and features - does the maintainer of that image have to do anything? What if he or she loses interest? It’d be nice to ditch Windows, but I have no idea if that docker image will remain usable indefinitely.
I think Zwift is using Wine to run. So it seems the docker image for that has the Zwift Windows client, some Wine libraries, and everything supporting Wine is already supplied by the Kubuntu install…but I’m really not sure. Theoretically I don’t need to know, until something breaks.
I have yet to use a flatpak, I think.
I’ve considered asking about all of this in the Linux community here on Lemmy, but there’s probably an article with an overview of it somewhere, and I just need to search for it.
WTF!? Didn’t know you could post dissertations here!
LOL sorry. It’s closer to an unhinged rant, though. :)
Dude, seriously, your post crashed Jerboa 🤣.
LOL nice. That’s…uh…kind of a surprising bug.
I’ve used a few appimages for limited cases - BalenaEtcher to burn HomeAssistant on to SD cards for my Raspberry Pi, and I think the scanning software I use is also an AppImage. The idea of having the libraries and binaries all together for certain things is a good one for certain cases
This very much, I use an appimage for gimp because I’m not fucking putting GTK2 in my system lol.
Also if steam came as an appimage with the 32bit libs and a patched glibc it would be amazing, it would save so many headaches for everybody, one can only wish though.
Also they support a portable home, so steam can be on a different partition with all the games and its own user files independent of the distro/home you are using.
Flatpak is already deduplicated.
Yeah, but you have to dedup manually.
Conpression is nice though, zstd at 10 is perfect.
I use flatpaks on my desktop all the time, no issue with storage space. But my laptop with only 128gb SSD starts sweating.
I that half of what my cell phone has
Not everyone has top notch tech, or the money to afford it. 128GB for a phone is more than enough storage space, so if the price of the 256GB model is 30 or $40 plus, I’d opt for the 128GB model as well.
Flatpak don’t be like this at all.
I suppose it might seem like that if you install it just for a singular app. Then the runtime + possible drivers are a hefty load. But everything after that, the weight of the deps proportional to the apps gets lighter through shared runtimes, drivers, dedupping and so on.
Some go to install a singular flatpak and are horrified by the amount it tries to install and never look back. Which I sorta get, though if that their level of familiarity with flatpak they might not be the best people to partake in the dep/flatpak/snap/appimage fights. But they still do.
Yes, the same can be said if you run GNOME and install a single KDE app or vice-versa. And here’s my petition to convert DigiKam to FLTK so everyone can enjoy it.
That’s true. I even have this thing where I don’t like to install KDE stuff on GNOME or GNOME stuff on KDE because I feel like the deps they pull in make my system “messier” since it now includes stuff from two DEs. It’s silly but it just bothers me. With flatpak I don’t feel the same, with it it keeps them neatly separated so it feels better.
I used it after getting frustrated with the AUR. Never looked back unless the package wasn’t on Flatpak or had an AppImage.
AUR is for esoteric shit, what were you trying to get on there that had a flatpak lol
For me, things like a Tidal music player, and proton-ge. Both can be found in flatpaks
You say that but there are people who swear by the AUR for everything because it has everything or they prefer Pacman for everything lol
I’ve had about 15% success rate with my attempts at AUR. I don’t have the patience to figure out why things don’t work, I guess. Either ended up with a flatpak, or decided it wasn’t that important to me.
I loved Chaotic-AUR when I was using Arch. No waiting to build AUR packages, you know if it works right away.
You have to decide if you trust the source. Personally I’m not worried.
Also if you know how to fix an AUR package you can open a ticket on their github and they will update it immediately most of the time.
I found a QT app today. Uncompiled file size: 1 MB. Compiled size: 100 MB
Yeah, completely normal for Qt… well, if you bundle everything that is. If it depends on shared libraries, should’t be larger than 10MB or so.
Also this app had an entire instance of WebKit compiled in it
Yep, that will make it quite large…
Flatpak is crazy inefficient, but at least I can get software that is not yet on distro repos. It will get better.
Yeah, I’m still not sure which is better flats or images? I still try to find .debs or apt get stuff.
I usually repack in cases like this (not in repos). It’s fairly easy in Arch and Void (haven’t tried Portage in Gentoo yet).
those are shared tho, no biggie
I haven’t had any real issues with Flatpaks outside of them not following my GTK theme which I fixed with Flatseal.
When you’ve got decent Internet and storage is cheap…
flatpak is about permission:
https://github.com/tchx84/Flatsealthe fact that gtk, qt, firefox pull in a hundred deps is their own problem.
not a problem per se…ask software to install itself twice and it becomes noticable how enormous the code is.
I just use appimages, they are even smaller than native packages many times due to their compression, for example libreoffice being 300 vs 600 MiB, librewolf 110 vs 330 MiB, etc.
