All containerization is just the fever to the sickness that is the futureshock from extremely fast rate of development of major libs like c++$year, glibc (no matter what they say about having stable endpoints), and the like. You can't run a program written today on the system repo libraries from 5 years ago.
Containers try to mitigate this problem but like a fever they often end up making things worse.
I don't run any APT based distribution right now but I understand the issues... I think the biggest problem I see is Canonical developing what looks like a very useful tool but holding it proprietary.
If Canonical provided the snap creation and hosting tools to the community I imagine it would be judged on its technical merits.
As it is, I see more and more reports that Canonical is trying to gain more and more control and that's exactly what I don't like to see.
Would have tried Ubuntu but they've poisoned that well. I'll have to recalculate.
As far as I can tell, snapcraft[0], the tool that allows the creation of snaps is open-source and on github. However the hosting server-side code is closed source.
> glibc (no matter what they say about having stable endpoints)
glibc does have a stable ABI. What they don't have is a frozen ABI so they will all new entry points. But old programs linked against glibc do and will continue to work fine.
> You can't run a program written today on the system repo libraries from 5 years ago.
You can absolutely write programs today targeting 5 year old ABIs. I agree that the FOSS toolchains could be more helpful there so you can just pass some compiler flag for the oldest glibc version you want to support but it is not impossible to achieve that on your own.
Do you see the fast development itself as a problem? I tend to see as the real issue that most package managers only allow one version of a package to be installed, leading to conflicts very quickly.
The best known manager that does allow this is Nix, do you know of any more, maybe ways to get this working with "traditional" package managers (completely transitioning to Nix is would be quite hard, from my limited experience)?
Yep. One of many reasons they're banned in our shop.
Even for client software it is bad - an app quitting out from under me because it wants to update is functionally equivalent to a crashing bug - but they're offering daemons this way, which is just insane.
Who doesn't want all their containers randomly restarting because someone up the distro chain decided when your machine needed to upgrade?
> an app quitting out from under me because it wants to update
This doesn't happen, at least on account of Snap. It's copy-on-write when it comes to updates, and whatever version you have running at the time of update will happily keep on running. I've been mildly confused by this a couple times, when I would end up with two different versions of VS Code running side by side, but the bright side was that my work wasn't interrupted.
It incidentally also sidesteps all the problems that stem from libraries or configuration being updated under a running application, which can happen with Apt.
This is sort of like saying you can turn off auto-updates by leaving your Internet connection disabled - true, but missing the point that what people are primarily complaining about is having to adopt an adversarial relationship to the software they use.
Depending on the qualities your after, AppImage is also really great. Advantages over Flatpak are that they are completely portable (you can store them anywhere and run them from anywhere), and they don't require a special runtime or package management infrastructure of any kind.
AppImages are basically (kind of) statically linked binaries.
Not my favorite to install software since they're usually huge (500mb is not far out of the norm), but great for things that are hard to install, as they're pretty much guaranteed to work.
I just wish there was a command line switch to stop it from wanting to install itself on my system (move the AppImage to /opt).
I have never seen that behavior from an AppImage. I just mark them executable and run them and they do their thing. If there is a specific AppImage behaving this way then it is probably the fault of the author, and if all of them are doing it then I wonder if it is the behavior of something like appimaged?
