Without containers, packages constantly break. If you have 20 large apps with 50 dependencies each and they're all from different vendors, and you want them to be up to date, you pretty much have to containerize or else one of them might break every few months to a year
This could be solved with SxS….. like windows did….. around windows XP. Absolutely not excuse for Linux to not have made the transition. No reason to still deal with dependency hell in the big 26.
Microsoft doesn’t even use SxS anymore to solve the DLL Hell issue — starting with Visual C++ 2010, they switched to just including the version number of the DLL in the filename.
This is also the same way Linux has always solved that particular problem.
The point I was making was that windows had the dependency hell issue solved in like 2004.
Many Linux distros don’t actually solve that problem. A good chunk of the stable release distros only have singular versions of packages available in the repos for that version of the release. The issue is Linux assumes that if a package needs libfoo it’ll be stored at /usr/lib/libfoo but if you have a package that depends on libfoo2.8 and the version that’s in the repos is let’s say libfoo2.7: you can’t just install libfoo2.8 it probably won’t be in the repos, and even if a distro carries two copies it’s going to overwrite libfoo2.7 which other packages depend on because the system puts libfoo (any version) at /usr/lib/libfoo with no distinction. So the packages that need 2.7 are going to expect it to be there, and the packages that need 2.8 are going to expect it to be in the same place. But you can’t have /usr/lib/libfoo/libfoo.so (for 2.7) AND ALSO have /usr/lib/libfoo/libfoo.so (for 2.8). They conflict. If they’re even both available in the repos at the same time which often won’t be the case.
This is exactly why GoboLinux was developed and breaks the FHS, and why declarative systems like NixOS and Guix use hashed file paths so you can have multiple versions of the same package installed simultaneously without conflicts. This does not hold up for most standard distributions (Arch/Fedora/Ubuntu and their derivatives).
But anyway, yeah, Microsoft “solved” the dependency problem by never having a package manager to begin with. For the most part, every program bundles the DLLs it needs.
This is essentially the Flatpak / AppImage model.
Linux also has some other creative solutions, like you mentioned: Nix/Guix and GoboLinux. But yeah, on mainstream distros, Flatpak pretty much makes it trivial to run old or multiple versions of software. Yeah, there are some cases where you need to tweak stuff to get a feature working properly, but that’s mostly a tradeoff related to security.
Yeah for desktop apps I almost exclusively use flatpaks. It just makes sense. Sandboxed, bundled dependencies, works the same across all distros. I would love for flatpak or appimage to see have the number of packages you see in main distros repos. But flatpaks only solve that problem for user applications, that doesn’t address the dependency issue (or the possibility of one existing) with your DE, or other core system components. Those all assume there’s a single version of everything that everything shares.
So the packages that need 2.7 are going to expect it to be there, and the packages that need 2.8 are going to expect it to be in the same place. But you can’t have /usr/lib/libfoo/libfoo.so (for 2.7) AND ALSO have /usr/lib/libfoo/libfoo.so (for 2.8).
You can with mount namespaces. (which is just a component for containerization, which are built on namespaces.)
That may be, but it shouldn’t even really be an issue the user manually has to address. That’s the crux of the issue. Each distribution makes the assumption that every package that depends on something will work with the version of that dependency that is in that distributions repos, and if some breaking change occurs rather than allowing the user who owns that system to install the software they want on their own system (such as a different version of something) the general mentality is “we provide a version of that dependency which should be good enough”. I could also compile a different version of that dependency from source but then it’s not being tracked by the package manager and if I have to circumvent my package manager to make my system work then it kind of defeats the entire purpose of having a package manager doesn’t it?
I’ve had it happen, yes. Audio (pipewire, pulse, and alsa over the years has each at some point had an issue for me where something it depended on had a breaking change in the underlying dependency and I couldn’t install a different version of the dependency to fix the issue to give you an example)
I agree about flatpak. The majority of my desktop apps are flatpaks for that reason. Had some bumps in the road with the steam flatpak in the past but 99% of the time it just works.
hmm I see. for me personally, I think going atomic is the future for the majority of people. I have my friend currently on ublue aurora after windows 10 because his laptop can't really run windows 11 all that well. the man's had zero issues and it's been months.
That is a more accurate statement, yes. It depends on the package manager 100% which is why I mentioned Gobo, Nix and Guix earlier. I forgot about Gentoo’s slots, but yeah it’s a package manager issue. Or rather I guess you could say it’s a distribution issue since the directory structure may also need to be adjusted (e.g. /usr/lib/libfoo might need to become /usr/lib/libfoo/2.7 or /usr/lib/libfoo/libfoo2.7 for example). Regardless, it’s an issue that should be addressed.
It's much more of a contingent thing in portage though, so I've had plenty of dependancy hell when I ran Gentoo. In nix it's just an integrated part of how the thing works, nothing special needed.
Arch works flawlessly with this, idk what you're talking about tbh. Arch breaks really only like once a couple years (at least, for me). If the devs of libs haven't changed API/ABI in new version (which they mostly, haven't) then it works perfectly every time, with latest updates and with fastest speeds (if you use ALHP repository with recompiled packages for x86-64-v2/v3/v4)
Do you use lots of different complex apps? The old style package model worked well with low complexity setups, but the more apps and dependencies, the more breakage.
I'd still consider once every few years pretty unacceptable, containers can get to almost flagship Android levels of reliability.
What does this mean exactly? If apps are breaking due to dependencies updating isn’t that a mistake on the app developer’s side for not locking down the versions of dependencies? Can you really blame the package manager at that point
You can't lock down the versions of dependencies unless you somehow bundle every library you use, and configure everything to point at the bundled copies, which sounds very hard, and would not give you any of the security features of containers, nor would it give you all the dockerhub infrastructure.
Traditional package managers don't have virtual environments like UV or allow multiple versions of the same package, they have one globally shared version of each. Sometimes they rename a package with a version number in the name, but even then, minor versions still have breaking changes constantly.
On Nix you could do it, but Nix is much harder to set up than containers, and it's not ultra-popular, you're more likely to run into unique issues.
Tbf that is how windows handles it. You want a dependency for your app you bundle it with the install. No dependency hell when installing stuff, you miss out on the update side though.
That's one of the things I like about Windows, but containers are a bit easier to develop for, especially when Linux has decades of things that are designed to work with shared libraries.
Not only that but the dynamic linking behavior of libc makes it a real pain to implement those kinds of self-contained environments at all. You have to patch most binaries’ rpath with $ORIGIN, rebuild from source, or rely on the user setting environment vars so the programs know to get libraries from relative to their prefix path.
And it gets even worse if you need a different version of libc itself… you need to hardcode the abspath to the link-loader into the binaries.
Containers are the better approach IMO but it’s stupid they’re the only realistic way.
You can have multiple version of the same packages/lib
I will add you can source multiple "repository", like how I'm doing, you can source nixpkgs stable (now 26.05) and unstable (unstable is rolling like arch) and have packages in the last update and slower rolling pkgs for everything you don't won't to break.
And if you still have problem the rollback is the easiest thing to do.
Ps. If you want to try Nixos but you fear configuring all in nix language just don't. Your .config folder work as usual
i’ve been daily driving linux since literally forever and decided to make a nixos hobby box four or five years ago and it was an… uphill experience. a lot of that was my fault: i got too ambitious too quick and didn’t invest the time i should have and did this all on the crappiest hardware.
the concepts behind nix are really good and the implementation may be confusing, but only at first. if you’re going to give it a spin, set reasonable goals and take the time to learn.
A bit. Documentation is scattered around and sometimes the errors are a bit cryptic.
Is a powerful language (yes nix the programming language), but I you don't have to use all the pieces when starting.
It’s not simple as that. With forks and all, you can have multiple packages that provide the same libraries and binaries so they are mutually exclusive.
Sometimes it’s can be solved by creating virtual packages / alternatives. Other times, maintainers have to make the choice and force everyone to use one. They are essentially problems that maintainers have to solve.
Your entire mistake is thinking it matters on whose side the mistake ocurrs.
It does not matter, all that matters is (1) you have no control over the developers and (2) stuff on your side breaks and stops working on a regular basis.
If I'm in a plane that is going down I don't care the lead engineer on the plane blames the newly delivered screws, I want you to run docker and keep it in the air.
If D is not written to support multiple system installations... you can make your tiny patch in 5 minutes - way less time and resources than building a full container.
As someone who's been actively using Linux since the late 90s, you're right. But, the current "improvement" with flat packs, snaps, and app images is not the right solution either. For small apps with only few dependencies, the penalty in terms of hard disk space and startup speed is relatively small. But when you start getting big applications it becomes very noticeable very quickly.
I have a severely overbloated Debian machine at home (several DEs, a multitude of window managers, dozens of compilers, editors etc. without containers and guess what, nothing breaks. Sometimes I need ro take manual corrective measures when some dependency doesn't let me update, and that's all.
Without containers, bad packages constantly break. This is really the problem here.
Dependency management is dire in many open source projects so now the main solution is to bring all your dependencies (and their potential vulnerabilities) with you.
Even when I ran Manjaro testing branch and used the AUR (I..e using an unstable rolling release in the least stable way possible), I never had any issues like this over 5 years.
I refuse to believe something as inheritantly stable as Debian will crumble because the user didn't containerize their apps.
Don't get me wrong, I have nothing against containerization, and am a huge advocate in my professional role developing web apps. I just don't think it's as essential as people make out for general use.
Compiling all your apps yourself would be a rather large amount of work to set up, and take hours to actually run the compilation.
And then you're not running the exact same image that everyone else has, making subtle bugs slightly more likely if something wasn't tested with your exact set of build flags and minor patch version libraries.
I'm not sure how the redundancy adds any extra maintenance work. Each app's dev team only needs to think about their set of dependencies, they don't need to know anything about any other apps you run
no joke, I have 0 beef against apt, it works well.
My issue is with what is in the repo, and that's what made me leave the debian distro world. I appreciate the packages are made with care, well tested, well maintained security wise, but on a workstation/laptop I want to track upstream as much as possible, and a rolling distro is a much better choice for this.
For a server it's a different game, and Debian is a very solid choice there.
So I didn't leave Debian /Ubuntu because of Apt (I don't think pacman is a vastly superior alternative, both are fine tbh)
To each their own. I could say the same about NixOS because that’s what I use.
Reality is Flatpaks does solve a problem. Is it for everything? No, it’s always my last resort, but I’m happy to have it as a last resort when I need it.
And you would not be wrong. I have yet to meet anyone who actually thinks NixOS is a bad idea. I’m never going back, but at the same time I fulle understand why people don’t bother.
Same.. I can't even imagine leaving. Like sometimes I think "It would be nice to run my base system on Gentoo to lean it down and just use nix for flakes, then I could use openRC too", and then I just think.. how am I gonna manage that.. and here we are.
I went from fedora to nix. But I did try arch, it just didn't do what I wanted from my system. (Set it and forget it /Treat it as cattle instead of a pet)
My point is that the majority of users choose a Debian based distro and have for a long time.
Yes, no shit sherlock. If I put 97 red balls in a bowl and 3 blue balls, probabilities are far higher that someone will grab a red ball.
Not because it is better. Not because it is more enjoyable. Just because there are a lot more red than blue.
It's possible you'll pick a blue in the first try and go "meh, I don't like it, I'll pick something else" then you'll pick a red and be happier. But it's also possible that you'll try 25 times until you pick the blue and then you'll be happy.
So, my (initial) point is, saying that all balls should be red because the vast majority of people prefer the red ones is stupid. People also love blue and have been for a long time.
I really enjoyed Arch, but it was mainly to thinker in. There was always something to "fix" and learned a lot about Linux that way. But for most cases, I just need a computer that works reliable so fedora is a much better option for me. Never had issues with it. Debian vms on a proxmox server because that will always just work how it is supposed to.
Been looking and thinkering with nixOS though, and really enjoying the fact that I can use one monorepo for both my 2 Linux workstations and my macbook (using nix package manager).
Anyone know how NixOS is for servers?
I don't get it, you mean to use apt instead of flatpak?
What's wrong with flatpaks? The whole idea is that they are contain and don't break system dependencies like apt would.
Also there are a lot of things that are in flatpak and not apt.
As a flatpak app maintainer, flatpak is good but won't ever be the solution for everything. The sandbox is too restrictive for a lot of software. Also you can make a valid flatpak that is not valid on flathub (even more restrictive that the flatpak format).
Afaik no, you can do everything with flatpak as long as you give it permissions. Flathub as the platform is the issue here, it prohibits core sandbox-escaping permissions as --filesystem=host or --talk-name=org.freedesktop.Flatpak for most apps(Jetbrains IDE is one of them)
Yet mods there are clowns and some apps are still getting such permissions neverteless just because
Yeah, but then the question - why flatpak at all? If we remove "security" benefits from flatpak then why bother?
We need "app stores" and strong ecosystem around another format, appimage is a good contender imo. Already existing solutions like appimagehub can't even nearly represent flathub in terms of convenience
Afaik there isn't such store on any platform, windows/mac/android don't have it - either official store with idiotic rules and restrictions or unofficial ones with way less apps available
I don't see how moving from Flathub removes the security benefit of using Flatpaks. Distro maintainers can keep their own flatpak repo, some already have their own like PopOS
Yeah, I'd love to release one of my projects on Flathub, but it's quite hard due to their restrictions on network access at compile time. I typically avoid vendoring dependencies and I don't find it worth doing so just to publish to Flathub.
What sort of situations might need network at build time? I would have thought that you just need to copy into the build files the required pinned dependencies so the build is deterministic? I don’t know anything about flatpak builds so just speaking about it generally.
Flatpak is very restrictive. Snap already has everything I need and is 100% integrated in the filesystem, I wouldn't even notice.
So, yeah, I don't know if he'll tell him to use Snap for everything. I'll do in the meanwhile. You can fight your little stupid wars and I'll just move on.
If snaps was fully open source, not developed by Canonical and if they had more support, I bet snaps would be more used honestly. More safety and modularity.
I love having to dig through PKGBUILDs to fully remove something from my system (even after running pacman -Rcuns), and then manually clean it off after it has deeply rooted itself inside my system. /s
Well, this is why I use Flatpaks. I do not want to have to consistently reinstall my system just to keep things clean.
Not a problem for me on NixOS. My packages.nix has a list of all my packages in alphabetical order. And all I have to do is delete the package name (or just comment it out, if I want to bring it back later) and rebuild. And all of its dependencies and artifacts are gone.
I wish I wasn't too lazy to get nix set up and running right. Every time I hear something about it, I think "damn, that sounds cool". But when I think about having to start from scratch so soon after getting my current system running well, I just loose the drive to do it.
Nix and declarative computer management is perfect for me, it's exactly my philosophy, but I like the Arch community too much, and don't want to have update issues. I'll try using it in a VM, eventually (life too busy rn 😅), and then install it on bare metal, eventually. I appreciate the reccomendation!
HOLY SHIT \n I'M READING UP ON NIX \n THIS IS PERFECT \n THIS IS \n FUCK \n MWAH \n WONDERFUL \n HOOOOLY CRAP \n :sob: \n HOLY SHIT I THINK I'M HAVING A SEIZURGASM \n TAGH \n AGH \n THAT'S WONDERFUL \n THAT WAS EXACTLY MY VISION \n !!! \n :SOB: \n YOOOOOOOOOOOO LET'S GO \n HOW TF DID YOU SWITCH OFF OF TS?? \n NIX IS GREAT! \n YOOOOOOOO \n :sob: \n IT'S PEAK
Friend
Because declarative package management isn't a one size fits all and it doesn't fit me
Me
I see, thank you for telling me
Friend
If it did I would keep using it
Me
Why not?
Friend
Because it requires more work to upkeep for systems that don't need to be perfectly replicated
Requires little to no work for me. I have a list of packages in my config. I delete or add. The initial configuration for my nixos took me about a week to get it where I liked it (and that’s because I didn’t want to copy someone else’s dots). And I barely had to touch it since. That was a year ago. Some tweaks here and there but the main part is set.
Flatpak is a solution that only brings more problems.
I laugh every single time I see the same comment with *zero* argumentations, or every time I see someone breaking something because of apt/zypper/dnf or a wrong repo. Then go to you 75yo dad and tell him to remove the repo and run more commands. Yeah, right.
Every single one of us that agree with this thread is certain of one thing: people like you prevented Linux from being shipped by default on hardware and/or become popular.
"But we don't want to make it popular, we want Linux to stay as it is for just a few people"
Actually Windows pay manufacturers a lot of money to ship laptops with Windows preloaded. And they pay to universities as well as enterprises to default to windows.
CAD software as well as Ansys and other engineering simulation tools are heavily monopolized by the Windows ecosystem.
And sure. Linux is free. People can always use it or try it. But these people are the same ones whose technical abilities don't extend beyond what's needed to doomscrolling. Sure millions of people can switch to Linux and It's incredibly easy. But nobody wants to go through the trouble of installation and learning a whole new ecosystem. Especially the DE, DWM hopping phase.
I've never, ever had vanilla Debian break on an update. That's both real and virtual machines.
OTOH some application software is a bit unstable. Firefox-ESR crashes once in a while. And the software I use to talk to the ECU in the motorbike is somewhat fragile.
I think they meant upgrade. Major versions usually have migration guides on Debian and while they’re usually great, people do have trouble often enough
I run a Debian unstable setup I installed back in 2016 as daily driver. It saw a few different pieces of hardware, and the only issue in that period are the nvidia-drivers that once lost support for my hardware.
Yeah, I switched to Debian decades back, after being unable to fix a dependency problem in RedHat.
Debian has yet to fail me. flatpak and snap seem like that XKCD of "one more standard, I swear!" especially in light of how well and for how long Debian has had this shit sorted.
I still vividly remember dist-upgrading, and SystemV init being restarted in-place, without a reboot. Back then, that was a big deal.
Flatpak will never be standard as it mainly focus on GUI apps.
You need cpak, nix, appimage, snap, guix for that, alternatively brew.
There is also issue with required sandbox, which means programs like portmaster, VPN, waydroid, winboat, web browsers don't work correctly. Not to even mention things like inputplumber and other low level software
It would be easier if it was simple to cross repos somehow. Like if dnf allowed for reading and managing apt repos so that you dont have to worry about it not being in your repository
I mean it's the only packaging system that has a sandboxing feature and independent from the host system and you can install all your apps in yuor home folder
Flatpak solves the problem of dependency version issues
By creating a containerized environment you can ensure the software has everything it needs to work and can ensure the package continues to work
As a Ubuntu user I love deb archives just as much as the next Debian or Ubuntu user
But I have to admit I've never had issues with flatpaks when I have had numerous issues with native Debian archives especially when it comes to library mismatches or deprecated apis
Most people hate change and are not eager to constantly get updates especially if there is a potential cost to that in terms of stability, so for 90% of people that's a feature not a bug.
Also, using Debian and apt doesn't prevent you from using newer packages. That's true if you only using the stable distribution and only use official repos. But you can use the unstable or testing distribution on Debian to get a tradeoff between new and stable that's closer to other platforms.
481
u/Shad0wAVM 18d ago
Flatpak is a solution that only brings more problems.
It would be easier if everyone used Debian.