8 ms·
Caution for OS X users — https://github.com/NixOS/nix/issues/2925 https://github.com/NixOS/nix/issues/2925
by srik 7y ago
Caution for OS X users — https://github.com/NixOS/nix/issues/2925 https://github.com/NixOS/nix/issues/2925
- echelon 7y agoWhy do they require /nix to be writable? It seems like the cache path should be user configurable. This reminds me of GOROOT/GOPATH and other complexities that arise when systems care too much about paths.
- costrouc 7y agoThere is a very good reason. Nix strives to be reproducible. Thus all hardcoded paths in builds have to point somewhere. /nix was chosen.
- hpfr 7y agoI recognize your nick—I found a few comments of yours [0] [1] that were intriguing. You should publish your config, if you can sanitize it. [0]: https://old.reddit.com/r/linux/comments/9o44id/how_do_you_automate_your_distro_setup/e7sxhko/?context=3 https://old.reddit.com/r/linux/comments/9o44id/how_do_you_au... [1]: https://old.reddit.com/r/NixOS/comments/9mm2pb/syncing_across_machines/e7g65nq/?context=3 https://old.reddit.com/r/NixOS/comments/9mm2pb/syncing_acros...
- kohtatsu 7y agoSure, but you can translate the user-configured path to be /nix on inputs and outputs.
- rgoulter 7y agoSo, if you were to build a package assuming /opt/nix instead of /nix, the sets of packages would be entirely different. The "can't" is more of a "seems impractical" than "hardcoded assumption in the nix program itself".
- zeckalpha 7y agoThis ignores chroot
- echelon 7y agoI don't mean to slight you or the effort you've put into this if you're an author or maintainer, but that's a terrible rationale. Given this choice, your tool doesn't fit well with other software, and from a systems perspective, it feels slightly egotistical. In the future, file systems will be immutable and only a few sanctioned volumes will be writable (if any). It'd be better if systems like this abstracted away the notion of the file system and operating system altogether. Everything should be virtual and that is how hermeticity and reproducibility should be achieved. That said, I admire the work you're doing and can't really point fingers as I'm not a contributor.
- catalogia 7y ago> In the future, file systems will be immutable and only a few sanctioned volumes will be writable (if any). If any?! Where do I put my files if not on a filesystem? In some corporate cloud? Writable filesystems for corporations but not for the common plebian? Is that the sort of dystopian future you're envisioning? If I've misunderstood what you're saying, then I apologize. But I'm alarmed by my perception of what you're saying.
- echelon 7y agoSome IDEs allocate config directories in your homedir: .idea, .vscode, .vim Some of them do it under .config. Some systems write to /usr/local Some things scope to the project you're working in. Python venv, node_modules, etc. Build systems, such as Cargo, Maven, and Pants each do their own thing. Make, autotools... Have you looked at an Android filesystem? I don't even know how to describe it. Everything everywhere is horribly inconsistent. I'm thinking in terms of workloads, of which building and linking are merely types of work that produce artifacts. There are many types: server workloads, jobs, userland software. If you semantically declare what a workload needs, what dependencies it has, where those dependencies must exist, and what outputs it produces, everything can be wired together logically and hermetically. I'm hoping the immutable containers of the Docker/microservice world make their way onto the desktop. If I can reduce my entire desktop environment into a single config file and have it reliably reconstruct itself, it would be magical. I would freeze and wipe my machine constantly. Of course writable, mutable volumes will exist for humans, but software can't play in that realm or it will lose hermeticity. I've sort of gotten off track and am no longer speaking about package managers / build systems. I think there's a more general solution to all of these problems.
- xenadu02 7y agoTaking a top-level directory isn't very good form IMHO. I understand wanting a hard-coded path but /opt/nix seems more in keeping with the Unix philosophy.
- Annatar 7y agoIt would be /var/opt/nix since it's data. Payload in /opt/nix and configuration in /etc/opt/nix. That's what the specification states.
- anarchogeek 7y agoI find it pretty stunning that Nix has decided to drop support for OS X over ideological reasons like this. There are workarounds, but the reality is that they're upset at apple's decision so they just dropped support. We're not close to a year in to this these issue threads. Any software which would be so anti-user does not deserve to be used. Nix might be magical but that sucks.
- comex 7y ago> I find it pretty stunning that Nix has decided to drop support for OS X over ideological reasons like this. What are you talking about? There’s no such decision. The first comment mentions it as a possibility, but the rest of the (very long) thread is exploring different ways to solve the issue.
- user555555555 7y agoCan you provide a link to where it says they have actually droped support. In that link they describe how to make a firmlink, its seems like they have a way to just keep doing their thing as before (edit, reworded)
- whateveracct 7y agoIt's FUD
- tottenhm 7y agoThis comment confuses me. It makes it sound like some authoritative figure came in and said, "Nix shall not support OS X because Apple is evil." But to my eye, this is not at all borne out by the thread. There's one or two early comments which float the idea that Apple/Catalina's problematic technical change "may force us to drop support for macOS...". That prompted lots of -1's, and then there's a gigantic thread where people are trying to figure out how to adapt, and that's an on-going/non-trivial process. Did I miss something? Is there actually a policy decision buried mid-thread that's hard to see? In your comment, I pick up some fear/vulnerability. There's no reassuring voice to say, "macOS Catalina support will be fixed yesterday!" I share that sense of fear/vulnerability, but I think it's a natural trade-off when you sign up for free/open/transparent/community-driven software. For better and worse, you get to watch how the sausage is made in real-time.
- kohtatsu 7y agoI'm lost, why does nix care so much about things being in /nix and not, for example, /usr/local/nix?
- infinisil 7y ago- /nix has been the (default) location for at least 15 years without problems, changing this now just because Apple messed with this would be very strange - With Nix, every path in /nix/store has its own ./bin, ./share, ./lib, etc. As such, putting /nix anywhere but in / doesn't make much sense - And honestly, it's just short, fresh and distinctly different. The path symbolizes that Nix isn't bound by the conventions of other distro's And problems with changing this now: - It would be a huge amount of effort, there's many places where this location is assumed, not only in code, but also by people - Finding the workforce to actually do this change will be near impossible, as the only benefit is a slightly easier installation for the latest macOS version, which is not Nix's main platform