>> In contrast, regular package managers solve this problem pretty well.
Except the upstream dev's are sick of dealing with "It doesn't work in my distro" ... there are plenty of instances of these sorts of pissing matches.
bwrap, flatpack, containers... were really talking about software distribution. I dont think any of these solutions "solve" the problem, we're just putting all the bullshit in one bag, not getting rid of it.
> bwrap, flatpack, containers... were really talking about software distribution. I dont think any of these solutions "solve" the problem, we're just putting all the bullshit in one bag, not getting rid of it.
I agree, personally I prefer flatpaks more often then not because they "just work" for most programs I use (that aren't on the terminal) but Its far from an elegant solution, still, I do generally like a lot of the work their doing like the various xdg-desktop-portal permissions that are standardising a lot of common "desktop" interactions
I'm with you on this. Even if I can dig into issues that come up and have, if just rather but most of the time. Not to mention that flatpak, AppImage and docker leave my Host pretty unscathed and allow updates to go much more reliably.
> Except the upstream dev's are sick of dealing with "It doesn't work in my distro"
99/100 it does work on their distro, they just need to handle their libraries better. Identify the packages they need to support the software, or if no packages exist then they need to compile the libraries themselves. The entire point of Linux distributions is to do this job for the user. Sometimes the distro will fall short, so you need to have the basic understanding to handle it yourself.
Of course, Linux users aren't as tech savvy as they were 20 years ago.
>> The entire point of Linux distributions is to do this job for the user.
You would think, but we have some fair conflicts between distros and upstream software.
Bottles is throwing the gauntlets down and said "we dont care about your bug if your NOT using the flat pack, if you got it from your distro its your distorts bug". A lot of other bits of software are moving this way because they just dont have the bandwidth to support the disros' nonsense (in their eyes)
Some software maintainers are looking at flatpack as a way to right size the effort in supporting users.
> "we dont care about your bug if your NOT using the flat pack, if you got it from your distro its your distorts bug"
Two cases here:
* it's a legitimate upstream bug, but is being rejected because you are using a distro-packaged version, not an official upstream release. Reproduce the problem with the upstream release, report it, done.
* it's a distro-specific bug, you cannot reproduce it with an upstream release. In that case you should indeed report it to the distro, not upstream.
I really love the theory of NixOS... an entire OS that is declaritively (or dynamically) defined. But the nix language itself does not seem like the right approach. A lot of packages just break out into command line scripting because of its limitations. As much as I've despised the JavaScript ecosystem in the past, it seems like TypeScript with Deno which has built-in JSON/TOML/INI/YAML and sandboxing would be a better language to handle automatic system configuration overall... plus, you'd have the advantage of a web app to manage your system config(s), sort of like what fish does.
> I really love the theory of NixOS... an entire OS that is declaritively (or dynamically) defined. But the nix language itself does not seem like the right approach. A lot of packages just break out into command line scripting because of its limitations.
What you're describing is the use of bash builders in Nixpkgs. This is conventional because lots of build systems expect bash anyway, and because it lets you easily incorporate the whole Nix build environment for a given package into a conventional interactive shell for debugging, where you can invoke functions that are available in the build environment and even copy/paste snippets from the build to inspect their behavior. I like it; I think it's a good approach!
It's worth noting though that Nix supports using builders in arbitrary languages, and there are some rare uses of non-bash builders throughout Nixpkgs as well.
Some other points:
- if you prefer a using the same language for your package recipes as the builders themselves, Guix has you covered.
- Nix has built-in support for reading and writing to many some of the formats you mention, like TOML and JSON. Some tools use those languages to provide an external configuration language for Nix, for the simple stuff, e.g., devenv, devbox, Flox, etc. One could certainly attempt this with NixOS as well.
> lot of packages just break out into command line scripting because of its limitations
That’s not a breakout, nix just provides the glue around shell commands, because that’s the most readable/accepted way to specify process invocations. Nix should be thought of as a data store, it’s just a huge object with keys and values.
This idea that we need to spoon feed simple solutions to users of free software really needs to die. If you're giving code away you don't owe your users much.
I might even say that if you're giving code away, you don't owe users anything. But you might also have goals for your project that would benefit from trying to attract, on onboard, or otherwise please users.
The idea of spoon feeding simple but incredible solutions for free can be very rewarding for maintainers, and can also generate a monetary reward as well. There are projects that I happily donate to because they create value for me. How many terms of service have you read of apps that you pay for? It seems that many apps you pay don't just take your money, but your privacy and rights away too. Developers creating something in the open can inspire and help make communities of people working on a shared goal, that attracts quality individuals from all over the world to help. It brings people that are excited about your goals and that came to your project because it was something they could find and appreciate. I'd say, you don't get the same from closed-source software. You also can't achieve the same by being an asshole to potential contributors just because you feel like it. Sure, it is an option, but if you want to actually build something... not just for you, but a dream, then it is a bad choice to not try to build a healthy community.
Except the upstream dev's are sick of dealing with "It doesn't work in my distro" ... there are plenty of instances of these sorts of pissing matches.
bwrap, flatpack, containers... were really talking about software distribution. I dont think any of these solutions "solve" the problem, we're just putting all the bullshit in one bag, not getting rid of it.