I think most of your concerns have at least one “yes, and…” response.
For example, yes it’s niche; it also has the most number of first class available software packets out all distributions. So it’s not a little unsupported corner with a small community; it’s quite large actually.
The security model is inherently at least as good as for any other major community. If package maintainers read the new upstream code, it’s safer, if they don’t it’s not. I don’t know of any useful security mechanisms in debian or arch that don’t exist for nix. However, packaging software IS less cumbersome with nix, once you know how; which leaves more time for code reviews and testing in theory.
Programmability of software packaging is mostly irrelevant to the normal user. Package maintainers will have to do some special handling for the odd package, and power users might want to put abstractions into their configuration. For normal day-to-day, where you want to package your own project and get a dev shell, it’s mostly straightforward.
Most of the time, for os features, it’s absolutely not 1:1. Many very useful intents are modeled as nixos configuration flags. In most cases no, you don’t need to figure out what you need to install and what file to change to set the theme in gtk; there’s an option and you’re done. Sure, there are packages with less abstraction, but nixos makes it very easy to add. Furthermore, the options are safe between system upgrades which is not always the case for major software releases.
Yes. NixOS is complex, yes Nix is hard to learn, there’s no doubt about that. I assume there’s going to be many projects down the line taking nixos ideas and wrap them into nicer UX.
I think most of your concerns have at least one “yes, and…” response.
For example, yes it’s niche; it also has the most number of first class available software packets out all distributions. So it’s not a little unsupported corner with a small community; it’s quite large actually.
The security model is inherently at least as good as for any other major community. If package maintainers read the new upstream code, it’s safer, if they don’t it’s not. I don’t know of any useful security mechanisms in debian or arch that don’t exist for nix. However, packaging software IS less cumbersome with nix, once you know how; which leaves more time for code reviews and testing in theory.
Programmability of software packaging is mostly irrelevant to the normal user. Package maintainers will have to do some special handling for the odd package, and power users might want to put abstractions into their configuration. For normal day-to-day, where you want to package your own project and get a dev shell, it’s mostly straightforward.
Most of the time, for os features, it’s absolutely not 1:1. Many very useful intents are modeled as nixos configuration flags. In most cases no, you don’t need to figure out what you need to install and what file to change to set the theme in gtk; there’s an option and you’re done. Sure, there are packages with less abstraction, but nixos makes it very easy to add. Furthermore, the options are safe between system upgrades which is not always the case for major software releases.
Yes. NixOS is complex, yes Nix is hard to learn, there’s no doubt about that. I assume there’s going to be many projects down the line taking nixos ideas and wrap them into nicer UX.