philr has joined #nix-darwin
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
aminechikhaoui has quit [Quit: The Lounge - https://thelounge.github.io]
<__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> no
<supersandro2000> can't read
<abathur> `readonly NIX_USER_COUNT=${NIX_USER_COUNT:-32}`
<abathur> so if you export or prefix NIX_USER_COUNT=4 or whatever, it should work I think
<supersandro2000> *nvm cant read
<supersandro2000> --daemon-user-count 4 should work
<abathur> oh, yeah, guess that works too :)
<LnL> abathur: kind of
<LnL> gist of it is that I definitively wouldn't introduce a deamon there
<supersandro2000> > clang-7: error: argument unused during compilation: '-fno-strict-overflow' [-Werror,-Wunused-command-line-argument]
<{^_^}> error: syntax error, unexpected ':', expecting ')', at (string):345:51
<supersandro2000> Anyone already encountered such issue?
<supersandro2000> hardeningDisable = [ "strictoverflow" ];
aminechikhaoui has joined #nix-darwin
<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
<abathur> my goal, basically, is to get macOS back to `curl https://nixos.org/nix/install | sh` being viable
<abathur> ah
<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 :)
<abathur> and an uninstaller :]
<abathur> nod
<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
ehmry has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<LnL> that's not exactly true tho, every platform conditional in build tools, etc. only ever runs on case insensitive systems
<LnL> it might be that this is only an issue in one direction, but I doubt that
<LnL> for the current state I know it's a problem for eg. darwin->linux cross so switching might make that feasible
ehmry has joined #nix-darwin
<LnL> but I definitively wouldn't change this without having some kind of an idea of what this might mean for nixpkgs
Chiliparrot has quit [Ping timeout: 260 seconds]
<abathur> gah, 2.3.8's already been cut and I didn't even notice :P
Chiliparrot has joined #nix-darwin
<abathur> could've sworn I had turned release watch on
<abathur> I thought it was waiting for the nixpkgs support for big sur; did that also go in while I had my nose in this? :)
hmpffff has quit [Ping timeout: 240 seconds]
hmpffff has joined #nix-darwin
philr has joined #nix-darwin
__monty__ has quit [Quit: leaving]
<domenkozar[m]> heh
<abathur> :]
johnw has quit [Quit: ZNC - http://znc.in]
hmpffff has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hmpffff has joined #nix-darwin
<LnL> nope, hydra is still building stuff
<LnL> my jobset has much lower build shares so master, etc. will generally get priority
hmpffff has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]