1. 9
  1. 7

    These “modern” problems are, in my opinion, based on the fact that webshit-practices are seeping more and more into software development. Containers are an admission that the complexity has become too high and there is little interest in actually interoperating with package managers, even though they are mostly doing a great job.

    Trying to grow and solve a chicken-egg-problem, modern languages made it very simple to pull in little-used dependencies directly from GitHub et. al., however, there hasn’t been a big push to develop these things into more mature and manageable solutions.

    I have come to associate these container/GitHub-dependency/cargo-practices with first-world-arrogance that is based on the assumption of ever-steady internet-connectivity. This is a massive falsehood, and with Debian/Gentoo/et. al. you can set up your own caches or use infrastructure that is spread across the world.

    Making out package managers to be the evil ones is naïve at best. The problem is software bloat and an unwillingness to learn from those that have years of experience with software packaging. I personally am not a packager, but have the utmost respect for everyone spending their time with it, and every software I write is tailored towards optimal packagability, often requiring exchanges with packagers from multiple distributions.

    1. 5

      Not sure where the author got the idea that Nix has anything to do with containers?

      1. 5

        The author doesn’t know about ports trees, I guess. They didn’t mention Gentoo, which is how most Arch users would have experienced them prior to nixpkgs. When the ability to build software is builtin to the package manager, rather than being a privileged manual operation which only official distro developers can perform, then users are empowered to patch their applications as necessary. Better, most ports trees have some sort of patch-sharing community, so that the user is in full control of their userland and does not need to use distro-provided binaries.

        I’m guessing that they also don’t know about ambient authority. The reason why Nix feels like containers is because both Nix and containers offer basic filesystem isolation, and the sensation of not having ambient packages is similar in both cases. But Nix’s isolation is easily broken, whereas breaking out of a container is just hard enough that some folks mistakenly think that it is impossible. (Edit: Nix’s build-time isolation is fine; I’m talking about Nix’s isolation of the Nix store from the running userland, which is isolated only by a polite convention of not searching through /nix/store.)

        That said, this isn’t a bad direction for the author to take. They’ve intuitively found some of the real problems with classic distros and ambient packages.

        1. 3

          What I am missing from this article is an explanation of what this has to do with the “modern applications” in the title. Was all this not a problem with old fashioned applications? If so, what changed? In the disclaimer part there is talk of graphical applications, but that is a very different categorization.

          Any way, in both cases, containers are not the answer. Using a laptop is different than using a server. You generally don’t want that high level of isolation between apps on you personal computer. I would not want to use a laptop that gets in my way as Android does on my phone. Specially not for graphical apps. They work best in a highly integrated desktop environment.

          What really changed, I think, was the amount of dependencies. Or maybe even: the amount of developers. All creating and consuming dependencies at a high churn rate. This brought a lot of good things, but also some problems.

          1. 1

            My aim with datalisp is to solve this problem. Packaging is not complete until the behaviour is indexed in a menu so that the user can invoke it by pressing enter. Missing data can be queried for etc.

            The fundamental problem is actually “how do we do decentralized automatic software updates for less technical users?”. This is why we must find a way to measure the trust we can place in different versions of software. To start playing with different ways to do that we should have a suitable playing ground, and that’s kinda where I am heading with tala saman.