<lovesegfault>
2. Look at #1, talyz explained me the issue he faced; I think we will have to symlink files
<lovesegfault>
But at least we'll still be able to bind-mount user dirs
<etu>
lovesegfault: yeah, I think so as well
<lovesegfault>
A shame :P
<etu>
lovesegfault: Bind mounting dirs is a big advantage though
<etu>
indeed
<lovesegfault>
I wonder whether we can provide APIs that give both
<etu>
I tested #3 for a bit, had some weird issues with some things in my home directory that got owned by root in the tmpfs. I have to look closer into it. It may be because I link to... symlinks :D
<lovesegfault>
like impermanence."/state".{bind, link}
<etu>
And bind mounting a symlink may not work either
<lovesegfault>
Oh, jesus
<lovesegfault>
I have no idea what that'd do lol
<lovesegfault>
bind mount a symlink to a bind mounted symlink to a device
<lovesegfault>
UNIX
drakonis has joined #nixos-dev
Jackneill has joined #nixos-dev
Jackneill has quit [Read error: Connection reset by peer]
Jackneill has joined #nixos-dev
tilpner has quit [Read error: Connection reset by peer]
tilpner has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
Shados has quit [Quit: Shados]
Shados has joined #nixos-dev
<domenkozar[m]>
hmm, status.nixos.org seems to be lying :)
<rnhmjoj>
do you how error reporting works in the nixos perl script like insta-grub.pl? running `nixos-rebuild build-vm-with-bootloader` with invalid values cause the script to "die" but no error is shown
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
FRidh has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 272 seconds]
teto has joined #nixos-dev
evanjs has quit [Read error: Connection reset by peer]
<matthewbauer>
domenkozar niksnut : any chance we could revisit https://github.com/NixOS/nix/pull/2698? I think there was some misunderstanding in that: 1. this only effects statically built Nix and 2. statically built Nix is broken without it
<{^_^}>
nix#2698 (by matthewbauer, 1 year ago, open): Add --whole-archive to include all store implementations (when BUILD_SHARED_LIBS=false)
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
<niksnut>
reminds me I should get back to that recursive nix blog post
justanotheruser has joined #nixos-dev
<gchristensen>
I'm thinking maybe I can directly pass the tools I need in to the recursive build and write my own derivation { ... }'s to reduce the reasons to rebuild
orivej has quit [Ping timeout: 256 seconds]
Valodim has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
FRidh has quit [Ping timeout: 264 seconds]
FRidh has joined #nixos-dev
<Mic92>
gchristensen: where does it save time?
<Mic92>
Does it make multiple small squash file systems?
<gchristensen>
yes, and also the same for the cpio's for the initrd
<Mic92>
gchristensen: does the linux kernel set any limits on this?
<gchristensen>
dunno
<gchristensen>
for the cpios, it can just cat them all together to get the cpio (fast, compared to rebuilding the cpio from scratch each time)
<gchristensen>
for mksquash, it mounts each one, copies its contents out, and then unmounts and deletes the squash
<gchristensen>
it does this unmount bit because otherwise systemd tries to unmount them all at shutdown and gets stuck
<Mic92>
gchristensen: so it needs at least twice the initrd as memory?
<gchristensen>
more because squashfs does compression
<gchristensen>
an incremental build going from a basic netboot system to adding nginx to the netboot system takes about 12-15 seconds
<gchristensen>
in comparison, even with 96 cores, making the squashfs and initrd each time would take several minutes for every build
<gchristensen>
(cores is relevant because mksquashfs parallelizes across cores fairly well)
<Mic92>
gchristensen: mhm. if you are unpacking it anyway, one could skip squashfs right away, no?
<gchristensen>
yes-ish. there is a trade-off here, which is that ipxe is actually pretty bad at TCP
<gchristensen>
though maybe a tar.gz would be fine
<Mic92>
or a more efficient squashfs algorithm
<gchristensen>
sure
<gchristensen>
note each store path not in the initrd but in the run-time image gets squashed, then cpio'd, then those cpio's are cat'd together to become the `nix-store` file served for netboot
<gchristensen>
things that make start-up faster would be lovely :P mounting, copying, unmounting, deleting isn't so fast and fun
<Mic92>
yeah
<gchristensen>
but even the slow-down caused by that pales in comparison to the speed-up this provides overall, at least, on the hardware I'm working with
<Mic92>
At this point it might be worth considering nbd
<gchristensen>
I don't think that is really an option for me
<Mic92>
anyway, it is good to see some pratical examples for recursive nix
<gchristensen>
:) fwiw the restriction I have is my image must be totally bootable over http
<Mic92>
gchristensen: I think archlinux had some tricks to boot from http
<gchristensen>
I mean i'm already doing it, but it makes nbd not really work I think?
<cole-h>
Not that I have any say/opinion in the matter, but why not propose that in the committers issue? Slightly more visible (for longer) than a question on IRC: #50105
<arianvp>
what does the number suffix mean in binary cache keys?
<arianvp>
cache.nixos.org-1:<blah>
<arianvp>
is the thing before the : even used for anything?
<arianvp>
the docs dont explain the syntax anywhere as far as I can see
<gchristensen>
I assumed it was to have a thing, in the name, to support creating a second one
<arianvp>
a second one of what?
<gchristensen>
like a new signing key
<arianvp>
why not just put two signing keys?
<gchristensen>
what would you call the second one?
<arianvp>
so wait; does a signing key actually get matches to a binary cache url?
<gchristensen>
no
<arianvp>
then don't name it; just have a list of base64 encoded strings. other words I dont understand what the name is used for
<gchristensen>
but my assumption is the motivation is that it is often useful for humans to have a way to identify and order keys
<arianvp>
I see
Valodim has quit [Ping timeout: 272 seconds]
Valodim has joined #nixos-dev
dongcarl has joined #nixos-dev
calbrech` has quit [Remote host closed the connection]
calbrech` has joined #nixos-dev
Valodim has quit [Ping timeout: 260 seconds]
Valodim has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<ajs124>
the name comes in handy exactly for that reason. if you have your own binary cache with its own key, you can see if it's in trusted-public-keys at a glance, without having to know the bas64 pubkeys.
teto has quit [Quit: WeeChat 2.8]
alp has quit [Ping timeout: 272 seconds]
justanotheruser has quit [Ping timeout: 264 seconds]
test has joined #nixos-dev
test is now known as Guest76318
Valodim- has joined #nixos-dev
Valodim has quit [Ping timeout: 260 seconds]
Valodim- is now known as Valodim
orivej has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]