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.
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.
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.
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:
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:
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.
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.
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):
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.
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.
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.:
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 
[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. [RFC 0017] Intensional Store by wmertens · Pull Request #17 · NixOS/rfcs · GitHub
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.
And I just realized, that if the store lives in /var/lib/nix, and the metadata is local per user, and then with PackageKit support we’d have a very compelling alternative to flatpak. Distros would only have to add the backend and the entire NixPkgs catalog would be installable from a GUI.
Ideally we’d also have a sandboxing wrapper though, like flatpak has.
ARM is now a certainty:
I was referring to Apple playing nice with always letting you write to / via synthetic.conf and them adding firm links.
Their move to ARM I was already expecting last year, they’re late 
Ack. The synthetic.conf man page on macOS 11 (Big Sur) does not describe any new options (besides making top-level directories or symlinks). But it seems that they did add /etc/synthetic.d, so that you don’t have to fiddle with /etc/synthetic.conf, but you can put your application-specific configuration in that directory. (Haven’t tried that yet though.)
Hello everyone,
I believe, I’m part of the user group you are trying to address here. I’m a long-time macos user managing most of my software with brew. It, for sure, has its pros and cons - its index being stored and managed with git is probably one of them.
Even though I recommend nix as part of my lecture, for me, the location of /nix has been a deal-breaker so far. Yes, I’m aware of the available workarounds, but I think reasonable arguments have been brought up here and across the internet.
I’m all the more exited to see this topic getting some serious traction. I would really love to see the proposal become reality. So, my questions is, what can we do to move forward with this?