4 ms·

The Nix community can try to boil the ocean, or they can create a platform that can be a stepping stone to better things. With the recent upswing in Nix usage,

The Nix community can try to boil the ocean, or they can create a platform that can be a stepping stone to better things. With the recent upswing in Nix usage, many new systems and packages are built with Nix and Nix-like declarative systems in mind. It's a positive feedback loop. It's not possible to rebuild literally everything from scratch to work in the "nix way", so older systems are supported with a wrapper layer, and newer ones should hopefully work in a more natural way. Guix and Hurd and whatnot try to be more pure about things and look how far it got them. There are tens of thousands of projects that would basically need to be redesigned and written from the ground up to achieve what you desire, and I think the best approach is to build the platform and prove its value and create a path and model for new projects to follow. There are only so many open source developers out there.

cstrahan 3y ago
I agree with all of the above. And I just realized: I should probably clarify what I meant when I suggested "the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix" as the means for a "cleaner base". While that would make things cleaner in some sense, it's not what I'm suggesting Nix should do. I was mostly trying to clarify that the majority of what needs cleaning is extrinsic, rather than some intrinsic failing of Nix itself (though things could certainly be improved there, too). The greatest source of difficulty for packaging/running things under Nix (having contributed at least a couple dozen packages, and the entirety of the Ruby/Bundler support) is software violating well established principles. To pick one silly example: say you need to get the home directory for the current user. Yes, you could do the equivalent of "/home/${USER}", and while that might coincidentally work on 99.999% systems, that's still wrong -- there's nothing keeping someone from having their home dir be something arbitrary like "/home_is_where_the_heart_is", and now your software will break. The funny thing is that the right way to handle this is also the easy way: use "${HOME}" if it exists, and failing that, fall back to `getpwuid` (or whatever your language calls it). It's easier/simpler because you no longer need to make any assumptions about how the file system is laid out -- either the user tells you through $HOME or you consult the password entry. Easy. But what happens when you send a pull request to fix the objectively wrong logic of the first example? You get push back saying "well, it works on my machine, and this is the first complaint we've heard, so no, I don't think I'll merge your request". So, I guess I'm being kind of roundabout, but the takeaway I'd like for everyone to have is this: if working with your programming language is difficult on Nix, please go look for (and upvote) open issues in your language's issue tracker (they're probably there) from other Nix maintainers begging for fixes that would not only make it easier for Nix users, but would also remove latent correctness problems that have gone unnoticed solely due to the coincidental uniformity of all other commonly used distros. Just because something works everywhere other than Nix doesn't mean that the code in question isn't needlessly complicated/fragile and/or dependent on non-standardized assumptions that just so happen to be common on other systems.

cstrahan 3y ago

I agree with all of the above. And I just realized: I should probably clarify what I meant when I suggested "the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix" as the means for a "cleaner base". While that would make things cleaner in some sense, it's not what I'm suggesting Nix should do. I was mostly trying to clarify that the majority of what needs cleaning is extrinsic, rather than some intrinsic failing of Nix itself (though things could certainly be improved there, too). The greatest source of difficulty for packaging/running things under Nix (having contributed at least a couple dozen packages, and the entirety of the Ruby/Bundler support) is software violating well established principles. To pick one silly example: say you need to get the home directory for the current user. Yes, you could do the equivalent of "/home/${USER}", and while that might coincidentally work on 99.999% systems, that's still wrong -- there's nothing keeping someone from having their home dir be something arbitrary like "/home_is_where_the_heart_is", and now your software will break. The funny thing is that the right way to handle this is also the easy way: use "${HOME}" if it exists, and failing that, fall back to `getpwuid` (or whatever your language calls it). It's easier/simpler because you no longer need to make any assumptions about how the file system is laid out -- either the user tells you through $HOME or you consult the password entry. Easy. But what happens when you send a pull request to fix the objectively wrong logic of the first example? You get push back saying "well, it works on my machine, and this is the first complaint we've heard, so no, I don't think I'll merge your request". So, I guess I'm being kind of roundabout, but the takeaway I'd like for everyone to have is this: if working with your programming language is difficult on Nix, please go look for (and upvote) open issues in your language's issue tracker (they're probably there) from other Nix maintainers begging for fixes that would not only make it easier for Nix users, but would also remove latent correctness problems that have gone unnoticed solely due to the coincidental uniformity of all other commonly used distros. Just because something works everywhere other than Nix doesn't mean that the code in question isn't needlessly complicated/fragile and/or dependent on non-standardized assumptions that just so happen to be common on other systems.