3 ms·

If there's a lot of thankless, mundane work for the majority of projects that seems rather routine from what I've seen described thus far across multiple decade

If there's a lot of thankless, mundane work for the majority of projects that seems rather routine from what I've seen described thus far across multiple decades, so this seems quite ripe for some form of automation sans projects that seem to keep requiring changes constantly. C extensions, interop across languages, and ABI considerations are certainly much more complicated and require a lot of complicated work but given that 90% of the issues even power users run into are things like "the lxml library I installed won't get detected by package X when I run autoconf, please help." There's nothing sustainable as an industry about something like software dependency management and versioning being so critical for things "just working" while people are sticking their heads in the sand saying "not my problem" as a rule. I'm so tired of solving the same problems that were already solved in the past because of developers wanting to work on "more interesting things" and doing the bare minimum to get stuff compiling and running again regardless of the package format. In fact, Docker may have made this situation even worse with so many Dockerfiles that will basically be unable to work. This is part of why I'm interested in the Nix ecosystem because there's so much work being done to make software installations repeatable and easier to manage. Unfortunately, it's squarely aimed at developers and is way, way too complex for most sysadmins to put the time into understanding, especially when they're so overwhelmed like everyone else with so many tasks.

larusso 3y ago
I‘m 100% with you there. I also think that the problems described are solvable on some levels if not all. I remember the time when brew took of on macOS. I used macports at the time. The reason why people preferred brew was the fact that installs where way faster. The reason was simple: brew based everything on system libs where macports similar to nix maintained packages for all libraries etc. It took way longer to install a package with macports. I‘m running Nixos on my private machine (I need to work with macOS at work as the only other option would be windows) and it is sadly way too complicated. Nix flakes make this harder and easier at the same time since nix channels had a way of breaking as well. I switched to nixos because I had issues with running nix packagemanager on other distros (including macOS). It either behaved wrong when installing gui packages or in some cases with a rust package I maintain had issues with glib-c which nearly drove me nuts. As to docker. Yes I also think it made stuff worse in the majority of cases. What people forget to grasp is that Linux be it a vm or a container is just a the kernel and that we have dependencies for some programs and libraries to the kernel. Reason why we have distros in the first place. So not all containers might run the same on each host because it docker runs on the same kernel as the host machine or the VM which installed (macOS) Issues are rare but can happen. Also the number of base images. „Let’s use alpine because that means I build a small container image“ … No it means you build on top of an alpine release with all the installed system libs etc. And that may or may not work with your software. And stuff like that.

larusso 3y ago

I‘m 100% with you there. I also think that the problems described are solvable on some levels if not all. I remember the time when brew took of on macOS. I used macports at the time. The reason why people preferred brew was the fact that installs where way faster. The reason was simple: brew based everything on system libs where macports similar to nix maintained packages for all libraries etc. It took way longer to install a package with macports. I‘m running Nixos on my private machine (I need to work with macOS at work as the only other option would be windows) and it is sadly way too complicated. Nix flakes make this harder and easier at the same time since nix channels had a way of breaking as well. I switched to nixos because I had issues with running nix packagemanager on other distros (including macOS). It either behaved wrong when installing gui packages or in some cases with a rust package I maintain had issues with glib-c which nearly drove me nuts. As to docker. Yes I also think it made stuff worse in the majority of cases. What people forget to grasp is that Linux be it a vm or a container is just a the kernel and that we have dependencies for some programs and libraries to the kernel. Reason why we have distros in the first place. So not all containers might run the same on each host because it docker runs on the same kernel as the host machine or the VM which installed (macOS) Issues are rare but can happen. Also the number of base images. „Let’s use alpine because that means I build a small container image“ … No it means you build on top of an alpine release with all the installed system libs etc. And that may or may not work with your software. And stuff like that.