You must log in or register to comment.
Nix needs a typed language, better CLI interface, better documentation, a distributed cache, to to get rid of the monorepo / single source of control, to support different builders (aka not just bash), and have a less toxic community.
For nix to be used by normal, non technical users, it must have a GUI. That is not optional.
Nix could be great for a lot of things, but it’s not the only solution and won’t be the last.
Nix is typed: there are strings, paths, lists, attrsets, etc;
Not sure what’s wrong with CLI, as I don’t really use it except
nix flake update(although I remember updating stuff installed vianix profilebeing a bit cumbersome, but it’s not exactly a good practice to use it this way);Good point with cache, although stuff outside of nixpkgs sometimes provides their own caches which are trivial to enable;
Nobody forces you to use
github:nixos/nixpkgs, it’s just a regular input. Ppl quite often have their own forks. It’s also trivial to use stuff from outside nixpkgs (also just another input);There are different builders (e.g. buildGoModule);
Idk where you’ve found toxic community, my interactions have been pretty nice so far (mostly matrix rooms);
GUI is optional, just like for all the other package managers. And it exists: https://github.com/snowfallorg/nix-software-center
Perfectly agreed with nix not (yet 🙃) being the best thing that exists, tho, albeit due to different reasons. For example, it’s a PITA to debug, and the error messages are sometimes unhelpful.
Nix is typed: there are strings, paths, lists, attrsets, etc;
Those aren’t types as far as programming language theory is concerned, they’re (using Rust terminology) variants of enums.
It’s not really unityped (“dynamically typed”) either, though, but it’s a rather small wibble: Include paths aren’t normal values, they must be statically evaluable. AFAIU that was some prescience regarding enabling future addition of separate compilation and maybe even proper typing.
Otherwise the language is just the untyped lambda calculus with a couple of primitive data types thrown in, just like lisp, scheme, or also lua or js (if you squint a bit), what makes it different is that it’s lazy and pure. Heck, it’s a language where you have to write down the y combinator (which wouldn’t work in typed lambda calculi) to do loops what else but the untyped lambda calculus is it supposed to be.
That all said, nickel exists. The whole CLI situation as well the documentation is a mess because practically everyone is using flakes even though it’s not an official feature (yet). And, of course, nixpkgs is nowhere close to having been ported to flakes, AFAIK we’re not even close to starting. Personally I think it should be done at the same time as a move towards nickel as not to do it twice but that requires nickel to actually get integrated into nix (as in the package manager).
tl;dr: NixOS is still very much in its “move fast and break the docs and all your habits” kind of phase. What it has going for itself, of course, is that “break things” doesn’t happen while that’s happening.
Nix is weird and confusing, and I say that as a self holster and student of computer science. Nix is a weird side thing.
So I’m running Debian. Say you want to use nix on it.
Is installing a package as simple as $ nix install vscode ? And would it “just work”?
Might give it a try if so.
Is installing a package as simple as $ nix install vscode ? And would it “just work”?
You fool. You absolute buffoon. You’re doing it wrong. That’s the wrong command, and even if it was the right command, this method could cause issues down the road. It goes against the declarative philosophy of nix. You’re supposed to refer to packages by their attribute, rather than name. If you launch the installed app that way, it won’t have any hardware accererated graphics becuase hardware accelerated graphics are impure, don’t you know this?
You need to read the nonexistent documentation to find all of this out, and then select a declarative solution, like home manager or nix-shell or nix develop, to install software, and nixgl to get hardware accelerated graphics for nix packages on non nix systems.
(/s (ish) over)
Yeah. Nix has some issues. If you just want more packages available, I would recommend distrobox.
It’s a very powerful tool, and I use nix to manage all of my development environments, but it has some severe limitations that only have hacky workarounds. I could not get hardware accelerated nix packages to have a working dekstop entry. So instead, I have to type
nixGLIntel gzdoomin my terminal when I want to play doom.In addition to that, the documentation is very poor.
The other comments in this thread elaborate on these, and a few other issues.
I mean, yeah, it’s
nix profile install nixpkgsand it should kinda work. Although to run it, you might have to also donix profile install github:nix-community/nixgl --impureand then run vscode asnixGL codebecause of video driver awfulness.Oof
