supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nix-darwin
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nix-darwin
Mic92 has quit [Quit: WeeChat 2.9]
Mic92 has joined #nix-darwin
Chiliparrot has joined #nix-darwin
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
hmpffff has joined #nix-darwin
__monty__ has joined #nix-darwin
hmpffff has quit [Ping timeout: 272 seconds]
hmpffff has joined #nix-darwin
philr has quit [Ping timeout: 264 seconds]
hmpffff has quit [Ping timeout: 272 seconds]
hmpffff has joined #nix-darwin
Chiliparrot has joined #nix-darwin
Chiliparrot has quit [Client Quit]
<abathur>
emily ok; it was a little painful, but I've managed to split the baby on the UUID thing
* abathur
harmed no actual babies in the process
<abathur>
LnL: around?
Chiliparrot has joined #nix-darwin
<abathur>
want to discuss your concern about the daemon when you are, though first I'm hoping you can expand on this statement: and the installer (neither variant) manages the daemons so having a third variant in that regard doesn't seem like a good idea either
<emily>
probably controversial, but I wouldn't mind if the installer simply didn't offer single-user mode
<emily>
having /nix mutable by your normal user feels like a massive footgun
<emily>
and nix is pretty elaborate to install anyway esp. on darwin
<supersandro2000>
Doesn't multi user mode create 30 users?
<abathur>
I think it's 32? :)
<abathur>
the quantity can be overridden, CI installers tend to just use 4
<__monty__>
I do want to add that multi-user installs don't always work. I'm only on a single-user install because I couldn't get the multi-user install to work.
<abathur>
do you recall why it didn't work?
<supersandro2000>
abathur: you need to modify the install script for that?
<abathur>
LnL: I agree a daemon's undesirable, but I guess we're weighting things differently
<LnL>
abathur: so either some kind of suboptimal approach or make single user and encryption mutually exclusive and make eg. the current error point to the daemon mode instead
<abathur>
I think the status quo where we drag every new prospective macOS user through a Hall of Horrifying UX before getting them set up is sad enough that I did all of this work even though I'm not using filevault
<abathur>
(not that me doing the work means it goes in--just qualifying how bad I think the current state is)
<abathur>
it's a drag on the new experience for every prospective user, in exchange for a marginally more tedious uninstall process for the people who've already decided they're uninterested; it doesn't effect whether they have to sudo to install, so we're already filtering anyone who can't; it isn't the difference between having to follow manual install steps and not
<abathur>
I'd say if single-user isn't encrypting it probably can't be the default
<abathur>
because the ultimate thing we're down in the hole trying to solve is breaking people's expectations about whether their store is encrypted or not when they've bothered enabling FDE
<LnL>
yeah, that might be a good middle ground compared to eg. removing single-user entirely
<abathur>
my personal preference is indeed just no encryption, but IIRC it was quite clear when graham polled on Twitter that it wasn't a viable approach for orgs with encryption requirements
<abathur>
well
<abathur>
I don't have context on whether different defaults on different OSes is or has been an issue in the past
<abathur>
IIRC the default was changed to single-user when I was fairly new?
<abathur>
but I don't know what was under/behind it
<LnL>
no, an automated multi-user install (outside of nixos) was new
<LnL>
and the story on linux is also more complicated since there are a bunch of service managers and I think we still only support systemd there
<abathur>
so it had to become a default because before that it was the only option
<abathur>
nod
<LnL>
yeah and multi-user was very new so a bit scary to switch everything
<abathur>
gotcha
<LnL>
I don't see a particular issue with different defaults, but the installer still has some painful quirks
<abathur>
another thought I had is just prompting for permission like the multi-user does, not sure if that could satisfy your concern?
<LnL>
the multi-user variant can't upgrade and the story with /etc files is pretty bad I think
<abathur>
i.e., "This installer is going to require sudo, modify these global settings files, and install a LaunchDaemon to ensure your Nix volume is mounted early enough that restored programs can access it. Is that okay?"
<abathur>
nod
<abathur>
I wish we had something ~idempotent that supported changing install types
<LnL>
not sure how people deal with that without eg. nix-darwin to re activate stuff that gets replaced with updates
<LnL>
yeah that goes back to the nix-installer idea :)
<LnL>
I've thought about just taking a few days and seeing how far I'd get with making something in rust or go
<LnL>
some basic approach modelling the steps as resources that can be created/updated/destroyed
<abathur>
what if single-user prompted the user "We'd like to install this LaunchDaemon to ensure your Nix Volume mounts early enough that restoring apps can access it. <include LaunchDaemon plist>. If you say no, your volume will still be automatically mounted when the system processes /etc/fstab--but beware that apps may not restore properly if they try to access files on your Nix volume."?
<abathur>
and defaulted to installing it if headless
<LnL>
that's also an option, but it blurs the lines between the different cases again
<abathur>
how do you mean?
<LnL>
more combinations again, what do you need to uninstall single user?
<abathur>
yeah
<abathur>
It's possible to dice it and only prompt them when they're using filevault, for example, but I actually at first hoped I could just do the volume even for pre-catalina installs to cull some of the differences
<abathur>
though I'm not sure how much it matters; things like `rm -rf /nix` are just work differently with the read-only root vs before...
<abathur>
but when I ran a check on that in travis-ci I think everything before mojave was breaking
<abathur>
so I restored the guard to only run the script if /nix doesn't exist and / is not writable
<__monty__>
abathur: Sorry, grepping my logs isn't turning anything up. I remember a bunch of problems with the nixbld users.
<abathur>
no worries; didn't imagine so, was just curious if it'd be something I knew had been fixed
<LnL>
abathur: is that github actions stuff you made usable for installer testing?
<LnL>
__monty__: that was a bug in iTerm IIRC
<__monty__>
I've never used iTerm.
<LnL>
huh, well that's the only issue I remember
<__monty__>
Well, I have to test problems users reported with iTerm. But I'd be really very surprised if I ran the nix installer from iTerm. I either ran it from Terminal.app or Kitty.
<LnL>
something about the application policies they had didn't allow creating users from that shell without user prompting
<LnL>
quite painful if you have to type your password 32 times :D
<__monty__>
The nixbld users were created but then the daemon claimed they weren't or something?
<__monty__>
And then re-running the installer didn't fix it or maybe it didn't want to re-run at all.
<LnL>
hmm, that doesn't ring a bell
<__monty__>
I'm very hazy on what the trouble was but I remember I had to manually remove the nixbld users multiple times.
<abathur>
LnL you mean the CI run I linked testing this PR? or something else?
<LnL>
yeah the filevault thing
<abathur>
I plan to split it off because it was hard enough to figure out
<abathur>
I'm not certain it isn't a ToS violation of some sort, but as long as we don't toot the horn too much or break anything I doubt they notice...? :)
<abathur>
LnL if I've read you right, it seems like the least-controversial next steps are something like: default darwin installs to multi-user; block single-user installs if filevault is on; don't set up a mount daemon for single-user installs?
<abathur>
LnL and I would like to see us figure out regular CI testing of installers under as many conditions as possible
<abathur>
so I'll be happy if this little innovation helps
<LnL>
well yeah, but that's my opinion :)
<abathur>
nod, I assume there will be arguments and a bikeshed or two :P
<abathur>
just want to make sure I have the right sense of it
<LnL>
and yeah testing would be _really_ nice, that's also one of the main things that's kind of holding me back from taking a stab at the other approach
johnw has joined #nix-darwin
<abathur>
I have opinions as well, but my overriding preference for now is pretty pragmatic: the least-controversial path that gets us back to single-invocation `curl https://nixos.org/nix/install | sh` macOS installs in time to squeeze it into 2.3.8
<abathur>
yeah, I have a fantasy that even the shell-based installs could be a lot better, and could probably support a good uninstaller, once they're regularly getting run through a good install matrix with a test suite catching all of the little crap people turn up with on discourse/IRC with
<LnL>
having that "just work" I think that's a goal we can all agree on
<abathur>
<3 LnL
<{^_^}>
LnL's karma got increased to 89
<abathur>
oh
<abathur>
I think emily had the only other question so far that I haven't tried to address, and personally have no opinion on, about whether the volume should be case-sensitive
<LnL>
I'm not sure about that one, might be totally fine but might also cause weird bugs that literally nobody else runs into
<abathur>
I guess I could make APFS a variable default, so that people who want to try it local or in CI can specify NIX_VOLUME_FS='Case-insensitive APFS' or whatever
<abathur>
make fact-finding easier without stalling the PR
<abathur>
going afk a bit now; I'll try to make a comment later laying out the single-user thing; do you have a sense of who I should be treating as stakeholders on this one? whether I missed anyone in mentions, or if there's a list that should get pinged?
<emily>
I think case-insensitivity itself causes weird bugs that literally nobody else (using Nix) runs into, to be fair
<emily>
we know ~all packages work on case-sensitive FSes because of linux, darwin not so much, and there's stuff like hackage2nix
<emily>
my main concern would be that it shouldn't depend on encryption vs. not or anything like that
<emily>
we'd want to create a volume on all systems with apfs