7 ms·

Nix has a few shortcomings: * The syntax isnt well liked. * The package manager relies on global state which kills the use of sharing / over NFS. * The nixst

Nix has a few shortcomings: * The syntax isnt well liked. * The package manager relies on global state which kills the use of sharing / over NFS. * The nixstore treats a filesystem as an object store. * Related to above, permissions aren't secure as they could be. Some of these can be worked around, some of them require an entirely new project.

Ericson2314 5y ago
That's a decent list, but I don't think we need to start from scratch. I think Nix can be adapted to meet all of those.
catern 5y ago
>* The nixstore treats a filesystem as an object store. That's a weird thing to list as a shortcoming, since that's the main innovation of Nix. ("package management as memory management" as the paper and thesis said)
- nwmcsween 5y ago
  Because you can encode the same information within the files and some dirs while keeping the benefits of a filesystem, heck you could encode what nix uses sqlite for using symlinks, files and dirs
- deleted 5y ago
  [deleted]
ncmncm 5y ago
Moreso than the syntax, the language semantics are a problem. There seems to be no value in a dynamically-typed system description language, but both a practical burden and a degree of unnecessary risk. Transitioning to a more consciously-designed, statically-typed, still-declarative language should put the project on sounder footing. The existing language interpreter should be easy enough to instrument to annotate all the existing specs with the actual types seen when building the corresponding packages, enabling automatic translation and transition to a better language for almost all packages, excepting only those (probably?) few that actually rely on dynamic-type follies. Those last could stay on the old language, be hand-translated to the new one, or be abandoned, case by case.
- tazjin 5y ago
  4-5 years ago I was first in line to claim that the Nix language needs a static type system. Now that we've seen what happens with languages like Cue I'm not so sure anymore. In a language like Nix there isn't really a distinction between compile time and runtime anyways and for cases where you want to check the shape of some data you can use e.g. yants[0]. The only difference would probably be slightly better error messages for incorrect type applications on builtins. [0]: https://code.tvl.fyi/about/nix/yants https://code.tvl.fyi/about/nix/yants
  - ncmncm 5y ago
    I read lots of complaints about how hard it is to discover what types of arguments are needed and what types result for any particular function. If they were declared, there would be no need to dig and guess.
  - southerntofu 5y ago
    > Now that we've seen what happens with languages like Cue I'm not so sure anymore. Could you maybe elaborate on this point? Or point me to other resources detailing this argument? I'm unaware of details about the cue project: i found it interesting on paper but when i never tried it as i personally consider it's useless as long as you can't validate data against an external schema (like JSON-LD or XML schemas). > The only difference would probably be slightly better error messages for incorrect type applications on builtins. Why only on built-ins though? If nix was statically typed, every package could define its own types for configuration/overrides and entire documentation could be auto-generated. I was not aware of yants, it looks great but it sounds like something that would be very useful as part of nix itself (like a nix check command). I love nix/guix as a concept but every time i've tried i've been been put off by severely-unintelligible errors due to bad typing or simple syntax errors (due to my lack of experience of what to use where and lack of documentation on expected types).
  - Kinrany 5y ago
    I'd also like to read about people's experiences with Cue. > In a language like Nix there isn't really a distinction between compile time and runtime anyways This is very true, but exactly for this reason Cue's unified approach of having types be values seems like a good thing. Perhaps Cue is missing the ability to create new abstractions? I guess Turing-completeness may be necessary for this after all.
octoberfranklin 5y ago
Third point isn't a shortcoming, it's a design choice. Fourth point is objectively false: there are no setuid binaries anywhere in /nix/store. No setcaps either. One unprivileged user owns everything under /nix/store. I absolutely love this. Installing a new package cannot create security vulnerabilities, because it cannot affect existing packages or their dependencies, no new processes are spawned, and no setuid/setcap binaries are created. Note I am talking about nixpkgs here, not nixos. If you trust sandboxes (like chrome does) then compiling a new package cannot create security vulnerabilities either. Second point is just an annoyance. It bothers me too, but we NFS-users lost the mindshare battle long ago. It's all HTTP and SSH now.
- nwmcsween 5y ago
  Third point could still use something similar to FHS while encoding hashes as file names e.g /api/$TRIPLET/bin/$hash-$name Fourth you could have each package have it's own user/group

Ericson2314 5y ago

That's a decent list, but I don't think we need to start from scratch. I think Nix can be adapted to meet all of those.

catern 5y ago

>* The nixstore treats a filesystem as an object store. That's a weird thing to list as a shortcoming, since that's the main innovation of Nix. ("package management as memory management" as the paper and thesis said)

nwmcsween 5y ago
Because you can encode the same information within the files and some dirs while keeping the benefits of a filesystem, heck you could encode what nix uses sqlite for using symlinks, files and dirs
deleted 5y ago
[deleted]

ncmncm 5y ago

Moreso than the syntax, the language semantics are a problem. There seems to be no value in a dynamically-typed system description language, but both a practical burden and a degree of unnecessary risk. Transitioning to a more consciously-designed, statically-typed, still-declarative language should put the project on sounder footing. The existing language interpreter should be easy enough to instrument to annotate all the existing specs with the actual types seen when building the corresponding packages, enabling automatic translation and transition to a better language for almost all packages, excepting only those (probably?) few that actually rely on dynamic-type follies. Those last could stay on the old language, be hand-translated to the new one, or be abandoned, case by case.

tazjin 5y ago
4-5 years ago I was first in line to claim that the Nix language needs a static type system. Now that we've seen what happens with languages like Cue I'm not so sure anymore. In a language like Nix there isn't really a distinction between compile time and runtime anyways and for cases where you want to check the shape of some data you can use e.g. yants[0]. The only difference would probably be slightly better error messages for incorrect type applications on builtins. [0]: https://code.tvl.fyi/about/nix/yants https://code.tvl.fyi/about/nix/yants
- ncmncm 5y ago
  I read lots of complaints about how hard it is to discover what types of arguments are needed and what types result for any particular function. If they were declared, there would be no need to dig and guess.
- southerntofu 5y ago
  > Now that we've seen what happens with languages like Cue I'm not so sure anymore. Could you maybe elaborate on this point? Or point me to other resources detailing this argument? I'm unaware of details about the cue project: i found it interesting on paper but when i never tried it as i personally consider it's useless as long as you can't validate data against an external schema (like JSON-LD or XML schemas). > The only difference would probably be slightly better error messages for incorrect type applications on builtins. Why only on built-ins though? If nix was statically typed, every package could define its own types for configuration/overrides and entire documentation could be auto-generated. I was not aware of yants, it looks great but it sounds like something that would be very useful as part of nix itself (like a nix check command). I love nix/guix as a concept but every time i've tried i've been been put off by severely-unintelligible errors due to bad typing or simple syntax errors (due to my lack of experience of what to use where and lack of documentation on expected types).
- Kinrany 5y ago
  I'd also like to read about people's experiences with Cue. > In a language like Nix there isn't really a distinction between compile time and runtime anyways This is very true, but exactly for this reason Cue's unified approach of having types be values seems like a good thing. Perhaps Cue is missing the ability to create new abstractions? I guess Turing-completeness may be necessary for this after all.

octoberfranklin 5y ago

Third point isn't a shortcoming, it's a design choice. Fourth point is objectively false: there are no setuid binaries anywhere in /nix/store. No setcaps either. One unprivileged user owns everything under /nix/store. I absolutely love this. Installing a new package cannot create security vulnerabilities, because it cannot affect existing packages or their dependencies, no new processes are spawned, and no setuid/setcap binaries are created. Note I am talking about nixpkgs here, not nixos. If you trust sandboxes (like chrome does) then compiling a new package cannot create security vulnerabilities either. Second point is just an annoyance. It bothers me too, but we NFS-users lost the mindshare battle long ago. It's all HTTP and SSH now.

nwmcsween 5y ago
Third point could still use something similar to FHS while encoding hashes as file names e.g /api/$TRIPLET/bin/$hash-$name Fourth you could have each package have it's own user/group