Earlier quoted context omitted.
But, since the files were under /nix, if you put them under /opt, then you wouldn't be able to make use of the compilation caches for /nix. Until a very short time ago there was no binary cache for Apple Silicon Macs.
There are for anything you run as x86_64 (using Rosetta). It's also important if you're cross-compiling anything.
We want to make Nix better
171–180 of 204 posts
Re: We want to make Nix better
#172Earlier quoted context omitted.
The Nix store has to be housed in /nix because all references to runtime dependencies in the store are absolute paths in /nix, This is true, but in some sense Nix on Apple Silicon was a missed opportunity. It started as a blank slate (fresh binary cache) and it would've been a good opportunity to move the store to a writable path like /opt/nix . This would have solved the whole dance needed with volumes and synthetic…
> It started as a blank slate (fresh binary cache) and it would've been a good opportunity to move the store to a writable path like /opt/nix. That breaks caching cross-compiled outputs and x86_64 outputs, which do still run on Apple Silicon.
This is the main reason why I don’t use Nix on the Mac anymore, I just don’t want the pile of hacks that is necessary on my system. And I am a former nixpkgs contributor. Many people will just shrug and install Homebrew.
Re: We want to make Nix better
#173Earlier quoted context omitted.
Having used Nix a bunch, the system has been hard to use and learn in exactly the same ways that messy legacy codebases I've worked with have been hard—which makes sense since Nixpkgs is an absolutely massive codebase that's evolved over the years with very distributed development. People latch onto the Nix language and the paradigm because that's the most tangible difference but, everything else held equal, Nix + Ni…
> People rarely jump I'd just like to take a moment to reiterate that object-oriented programming is a mistake produced by cargo-culting half a dozen different styles used by competent programmers (including the devolpers of smalltalk and its relatives, from which OOP appropiated its name), and that Java is completely unusable by anyone with a sense of self-respect and a awareness that programming languages can be be…
Java is a tiny language with not too many concepts going around sitting on top one of the best runtimes with one of the biggest ecosystems. It is a very sane and good choice for almost every program out there, especially that empirically we have absolutely zero evidence for any significant difference between language productivities, other than managed languages being a boost (so your mention of C, which is arguably a language with so many faults one could fill a whole book about, is frankly, quite laughable).
Re: We want to make Nix better
#174Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…
Having just done some prototyping with Nix, this list is spot on in enumerating the pain points I hit. I think most of the docs problems could be solved with the meta-strategy of “deeply understand all the things the Rust ecosystem got right with docs, discovery, and general pedagogical structure, and replicate that”. Actually have a canonical set of docs. Link liberally between packafes and stdlib. Figure out typing…
I think every project would love having the money to hire someone full time to work on the documentation and evangelism.
Re: We want to make Nix better
#175Earlier quoted context omitted.
NixOS handles nvidia cards better than any linux distro i've ever uses including Debian, Ubuntu, and Archlinux. I've only had to add a few lines to my configuration over 10 PCs and laptops.
Ok, that is good to know. But how well does it run on NVidia's Jetson line of systems? https://developer.nvidia.com/embedded-computing
I have trouble understanding your question. Why do you want to use Nix if you use a system which comes pre-configured to do something else?
Re: We want to make Nix better
#176Earlier quoted context omitted.
> they haven't been able to focus on the UX. I also feel like folks for whom Haskell is comfortable may not realize just how absurd it feels to everyone else. The majority of communication I've seen from Nix maintainers over the last few months has been about exactly this. The submitted post is about exactly that while Nix powerful, they want more people to be able to use it without having to pay a steep penalty to l…
It also doesn't have anything to do with Haskell or it looking somewhat like Haskell. I'm very comfortable in Haskell, and Nix looks awful to me. It's not that it's functional or it's declarative, it's that it's badly designed and not intuitive, making it hard to remember and therefore awkward to code in.
Re: We want to make Nix better
#177Earlier quoted context omitted.
There are for anything you run as x86_64 (using Rosetta). It's also important if you're cross-compiling anything.
Sure. But I think 90% of the Nix on Apple Silicon users does not compare about cross-compiling or running x86_64 binaries with Nix. So, everyone is worse off for supporting minor use cases.
I don’t really understand the complain in this thread. Using an APFS volume just works and is entirely transparent to the user.
People could just learn instead of complaining they don’t understand.
Re: We want to make Nix better
#178Earlier quoted context omitted.
Right but the comment said they compromised on using a different directory in the end, so it could be under /opt like Homebrew, and not a root directory.
> it could be under /opt like Homebrew You can install Homebrew other places, too, for that matter. I'd only tried NixOS (bounced off, couldn't get X-Window working even following tutorials to the letter) not Nix on macOS. "Must be installed in a specific, root directory" is a hard no for me, when it comes to add-on package managers. That's one hell of an odor.
> That's one hell of an odor.
That’s very much fine. They do that to be able to share the cache between system. There is nothing magical about the root folder by the way. It’s just Apple being annoying.
Re: We want to make Nix better
#179Earlier quoted context omitted.
My main gripe is documentation. Look at this: https://nixos.wiki/wiki/PostgreSQL Now, the real "workflow" with nix is look at other setups, or just look at the code: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/s... And look at the code is the only reliable way to see what exactly is supported. My second gripe is the fact is hard to see what nix do. Today I hit this trouble: https://www.reddit.com/r/Nix…
Yeah, dealing with user directory is a pain, and it is a pain because you can't make it completely functional (what about passwords). And it is the only place I found where nix doesn't work as you would expect it to in my 3 years of nixos use.
Re: We want to make Nix better
#180Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…
It's the easiest programming language in the world.
(Which is a problem when people start building huge projects like nixpkgs with it. It's not a language fit for programming-in-the-large, just like Javascript isn't.)