Linux package management is a rare example of successfully tamed complexity. It's magic: having a single copy of, say, gzip implementation imported and used by hundreds of installed applications.
Sandboxed approach works on servers, where a single machine is usually dedicated to running just a handful of rapidly re-installed apps, it has no place on a desktop. I am not interested of every little component (of which I use dozens) landing with its own "runtime".
this madness is caused by the common techno-disease of seeing a nail everywhere when holding a hammer. yes, containers are great for the (trivial) server use case and no, it's stupid on a desktop which is two orders of magnitude more complicated.
I clicked on your link and saw exactly what I expected:
> VisiFile is a NodeJS application built with Express, Sqlite, and various NodeJS modules.
yep. another example of wheels coming off: no, NodeJS is not an appropriate tool to build desktop software. by picking the wrong tool you're dragging the wrong deployment model along with it. I will only use an electron-like app if someone pays me for it (Slack at work).
Web browsers and Web applications actually completely break the distribution model completely on both ends, client and server. To fix this, you need containerization on both ends.
Chrome and Firefox ship new versions of their products every six weeks. Each version carries both new functionality (Web standards require field trials as part of the standard process), and essential security changes (e.g. for TLS). Ubuntu and Fedora repackage Firefox and ship it as fast as they can, because that is the responsible thing to do, but it would be easier and safer for everybody if that could be done with the transactional updates, parallel version installation and dependency isolation that flatpak and snap can provide.
I see this is working for a constantly developing project like browsers. But imagine you just stoped to work on your side project for a year. Now you come back and would just like to add a new feature.
You start with updating all your libraries and half of them started to introduce API incompatible changes (the author gave you at least 15 minor releases and three month of transition period but you did not pay attention) and you spent the next two days just with catching up on the development side of things. We did not yet look at all those bugs and security holes which were open in all the libs you used for the last year.
I see a similar friction here we also face between distributions and developers and the main issue for friction seems to be the friction about guarantees for stability. And only after that it extents to the friction about getting the latest version shipped to the user (either developer or end user of an application).
In corporate environments they claimed we solve this all by running microservices and we would just version our APIs to guarantee the stability of our interfaces to our fellow developers. I still would like to see this working for extended period of time in the real world.
I don't see how containers or flatpacks will solve it. At some point someone has to touch it again. Be it for bug fixes, security updates, feature development. If hell breaks loose everytime you've to continue stalled development because something wasn't as stable as expected in your ecosystem we've not solved the problem yet.
And it's not solved if we install five different versions of a lib with different sets of bugs in parallel.
Being only a teeny bit polemical, I sincerely hope the whole overblown containerization fad will die.
Sure, it has its uses, but outside of those, it's just yet another needless layer of obfuscation. OS'es and centralised package management served us well for a generation or two. I worry that Docker & Co. are going to send all that the same way js sent a few decades worth of soundly developed programming practice.
Containers is basically a way for devs to get admins out of their way.
Rather than have admins complain that something broke when some push-to-prod devs are running amok, said devs can just point to their containerized snowflakes and tell the admins to get lost.
The problem is not technical, it is cultural. It is the webdev mentality percolating down the stack, giving the devs the impression that they can just fix their latest API/ABI boondoggle by rapidly pushing another version, like a machinegun fires bullets.
It is not surprising that Gnome is one of the biggest pushers of this, as they seem to have and artistic attitude to their code. Just watch them trying to tar en feather Torvalds, as he has told them off many a time for this behavior (a behavior that is strictly not tolerated in kernel land, might i add).
> Linux package management is a rare example of successfully tamed complexity. It's magic: having a single copy of, say, gzip implementation imported and used by hundreds of installed applications.
Except it often breaks and you need to be an expert to fix it. I'll take the hit on disk space if it means I can reliably install software quickly and without hassle.
Containers aren't perfect, but they get the job done.
