/nix => /var/nix, /opt/nix, /usr/local/nix?

how much annoyance to create to the more numerous NixOS users (all of whom did some partition management during installation) so that the macOS users are not required to do any partition management for Nix use.

I might be projecting, but this at least sounds a little pejorative and dismissive. To be a little more fair–this subset of the question is about installing a package manager, not an OS. Some things to weigh:

  • If you installed macOS from scratch, there’s some chance you’ll have to do a little partition management.
  • It’s a bit weird for user-installed software to automatically create a partition, but we’re preparing to do just that for UX reasons.
    • If there are orgs already saying No to Nix because of /nix, creating a partition will probably only increase that likelihood.
    • In mixed-OS orgs, unless the decision-makers have a nuanced understanding of this issue, they might say No to Nix or NixOS organization-wide, rather than just to Nix on macOS.
  • Automatically creating a partition and bootstrapping it for use is a substantive change to Nix being so simple you can roll down your window and throw it out with rm -rf /nix. People who go run rm -rf /nix and still see a Nix Store in finder are going to be (justifiably) confused (and perhaps excusably suspicious).
1 Like

They set the root filesystem to immutable it’s constructed at boot. In order to make a new directory where you could bind-mount, you have to temporarily remove the immutable bit, make the directory, mount, restore the immutable bit. And it will not persist across updates, so you need e.g. a systemd unit to create the mount point. See e.g.:

It’s not insurmountable, but also more work than just adding an entry to fstab. Anything outside a top-level directory or /var will probably be difficult, since the rest of the filesystem is supposed to be immutable, since it is constructed through OSTree snapshots. However, they seem to be open to have top-level mount points.

Fedora is only one of the 1 or 5 most popular distributions, depending on how you are counting :wink:. Also, it is also the major distribution that is philosophically the closest to NixOS.


At any rate, more on-topic: I think both keeping and switching to another store locations has its cost and it should be carefully mapped out.

Another thing for the problems section of the table: all the documentation out there on the net, slide decks, etc. that discuss the Nix store will be outdated.

Not a major issue, but at least something that should be taken into account.

1 Like

how much annoyance to create to the more numerous NixOS users (all of whom did some partition management during installation) so that the macOS users are not required to do any partition management for Nix use.

I might be projecting, but this at least sounds a little pejorative and dismissive.

Sorry, I definitely did not want any pejorative meaning, especially not towards people — it is about comparing annoyances and under assumption that people can do this pretty easily if they decide to (there can be different reasons why the decide it is not worth the time or not worth the policy negotiations or whatever, but ).

To be a little more fair–this subset of the question is about installing a package manager, not an OS. Some things to weigh:

I have a feeling that non-native package managers are used as something half the way towards a VM.

  • Automatically creating a partition and bootstrapping it for use is a substantive change to Nix being so simple you can roll down your window and throw it out with rm -rf /nix. People who go run rm -rf /nix and still see a Nix Store in finder are going to be (justifiably) confused (and perhaps excusably suspicious).

Is dropping the volume and easy operation, BTW? Still requires changing the documentation and obsoletes some more of the existing learning materials.

I’m not sure what you mean by this.

Also to note, macOS has no native package manager. The most common one right now is Homebrew, but years ago it used to be MacPorts, and before that it was Fink. If we nail the UX story, there’s no reason why Nix can’t some day become the most common macOS package manager (though it’s unlikely we’ll ever get simpler than Homebrew due to Nix’s inherent complexity, so we probably can’t supplant it, but we can at least be a strong second choice).

We need some sort of uninstall script. FWIW a multi-user macOS install really should have an uninstall script anyway because the installer adds a LaunchDaemon that we should clean up. And nuking /nix doesn’t clear out /etc/nix/nix.conf either which is a problem if you’re going from single-user to multi-user or vice versa (I’ve been bitten by this before).

Requiring people to manually delete the partition isn’t the end of the world, but it is going to trip people up because most people don’t know how to do manual partition management. And we need to clean up the fstab as well, and ideally the synthetic.conf too (though that one should be harmless to leave).

1 Like

I have a feeling that non-native package managers are used as something half the way towards a VM.

I’m not sure what you mean by this.

Well, a package manager is not an ordinary application, and a bit of a system-inside-system, so there is some chance of shifting perception of what is «too global». But of course the annoyance doesn’t go anywhere.

Why there are packages hardcoding /nix/store? Guix project uses /gnu/store but it is completely compatible with /nix/store; then it is at least dangerous to hardcode it!

That way, if it is really needed, /opt/nix or /opt/nix/store would be a nice place to install Nix packages.

1 Like

I concur. Non-standard top level directories in enterprise enviroments are definitely an issue for multiple reasons (policies for standard images, unexpected behavior of third-party security tools, etc.). As far as MacOS goes, when hundreds or thousands of laptops are managed centrally, making any changes to the partition table is totally out of question.

2 Likes

I do not argue one way or the other but it might just be a conjecture at this point, there is no way to know if there are more NixOS users or machinetosh users using Nix. Thing about Nix/NixOS is that it just works for most people and use cases, so there is often a silent “majority” quietly going about their business.

1 Like

I have a feeling that non-native package managers are used as something half the way towards a VM.

I roughly agree with this, but since you’re framing this as half-way to a VM, it may be worth pointing out that macOS users can install both Vagrant and VirtualBox without repartitioning their hard drives (and uninstall them without leaving stray partitions).

This isn’t Nix’s fault–but I don’t think any amount of finger-pointing or Overton-window-shifting will change the fact that at least in the year 2020, it’s weird for an installer (let alone one that wants me to trust it enough to curl | sh it) to create a partition.

Is dropping the volume and easy operation, BTW? Still requires changing the documentation and obsoletes some more of the existing learning materials.

All relative, I guess:

  1. The current tentative installer creates a volume and adds it to fstab and /etc/synthetic.conf. We can’t just wipe these to remove it, so we either need to:

    • be confident enough in our ability to automatically edit them back out without accidentallying something else on their system that there’s 0 chance we’ll get dragged in some public forum
    • send people who may have absolutely no clue what an fstab or /etc/synthetic.conf is (or how to format them) to go edit them without messing it up
    • (I guess if we confirm the entries don’t cause any trouble without the volume present, we could also just remove the volume itself and leave the entries rather than risk mishaps? Some subset of these users may turn up when they notice these entries, but I feel a little more confident that the kind of user who’ll notice this cruft can be readily talked through removing it?)

    I would guess “most” people who find out about Nix and think it sounds like a hot date are capable of following instructions here, but several days ago I had to set someone straight in the GH issue because they used LnL’s create-darwin-volume.sh script and couldn’t be bothered to read the uninstall instructions plainly visible in command output they had bothered to copy and paste into their comment.

  2. If the users want an encrypted volume, we currently leave implementation up to them. They’ll need to set up the encryption and their own mechanism to automatically supply decryption credentials to it. Unless we’re able to settle on a OneTrueSupportedEncryptionProcess, I doubt there’s anything sane we can do to clean up these systems. I’d guess most people who care enough to work through this in the first place can revert it with instructions, but that’s a guess. (It also somewhat assumes they’ll be feeling as generous on the way out the door as they were on the way in).

I guess all of this seems like a small lift after installing any Linux sans GUI, but I think it’s best to set this aside. It’s not a big deal if a fresh install goes sideways–just start over. Being entrusted with people’s working systems is a different contract.

1 Like

I think there’s evangelism/onboarding value in making sure Nix is easy to install on any OS/platform that has a fair number of developers. Beyond that, I don’t know the challenges well enough to earn strong opinions here.

I think someone in the GH issue speculated that macOS could be a canary for a trend more operating systems will follow. (I don’t recall if the example was/included Fedora Silverblue.) This seems to provide both the strongest case and asterisks. Some thoughts (just numbering/lettering in case anyone wants to refer to them without quoting; no real narrative):

  1. The strong case would be: if taking action here gets Nix ahead of a trend that is going to be a recurring hurdle over a multi-year period.
  2. *But, if there’s no confidence that a single change can serve every OS going forward, I’m not sure it’s worth a big upheaval to fix a single instance.
  3. *If this is a real ongoing risk and there’s no “safe” adaptation, the Nix ecosystem may need to actively advocate for standards/solutions here to avoid getting painted into a corner and having to re-fight the same defensive battle multiple times?
  4. *If there’s any set of steps that can keep the current advantages of a single canonical path–but get rid of the single canonical path–this seems like the least-risky investment of effort. Since some OS could still break compatibility with the new path, or standards work could be a bottomless time/effort pit with no guarantee of adoption, it’s probably “worth” investing up to 1.5x the effort of a canonical path change? (Assuming none of the transition steps add their own intrinsic value?)
1 Like

I think that it is fairly safe to say that there are fewer contributors that use macOS. As someone using NixOS, Nix on Darwin, and Nix on Ubuntu, I can say that packages are broken far more frequently on Darwin. Also, there are sometimes packages marked as Linux-only when they compile/run fine on Darwin (the maintainer just didn’t have access to a Darwin machine to test).

Of course, that does say anything about the number of users. But I would expect that with Nix the number of users and contributors are correlated.

1 Like

Also, there are sometimes packages marked as Linux-only when they compile/run fine on Darwin (the maintainer just didn’t have access to a Darwin machine to test).

Can relate. I have a good AMD machine, but no OSX to play around.

1 Like

I like to imagine there’s some Nix-aware corporation out in the world regularly retiring MacBooks into a dark closet/woodchipper/reseller who’d be willing to trade one for a hot package or two…

This seems to come up very frequently now on various places, e.g.:

https://news.ycombinator.com/item?id=23274749

What would be the way to push this forward for consideration? Write an RFC? Even though I have been critical in this thread, I think it would be useful to write out a proposal and work out its implications more formally and get a community review per the RFC process.

Writing an RFC sounds like the least unlikely to succeed way forward,
though I wouldn’t advise anyone to raise their hopes too high :slight_smile:

1 Like

[quote=“Ekleog, post:52, topic:7101, full:true”]
Writing an RFC sounds like the least unlikely to succeed way forward,[/quote]

Waah, that negation crashes my brain ;). An RFC does not have to succeed, but it might be a way to see what the consensus is given a well-thought out proposal.

(Coincidentally, I’m working on a tangential RFC where I’m now proposing moving the store to /var/lib/nix as a part of CAS. https://github.com/NixOS/rfcs/pull/17#issuecomment-629776797

I’m liking what I’m laying out in that comment, it feels right. The primary property of CAS paths is that they are self-validating, and therefore I’m proposing to decouple the store and the metadata, giving each interested party their own metadata.)

I think this is a good idea. We can simply leave the old cache in place. Content-addressible derivation will also hopefully make migrating existing cached builds easier. But even without that, we frequently build everything from scratch during a mass rebuild, so is this really worse??

We can just make this upgrade in the next release of GCC, or some massive event like that.

1 Like