<nckx>vixus: I use the EXTRA-OPTIONS field of the GUIX-SERVICE-TYPE to set --cores and --max-jobs. Again, there might be native fields for that nowadays. What it really should do is default to `nproc` in the daemon itself.
<nckx>sunmaster: Well, yes, as a side-effect of throwing just about everything relevant (=besides metadata like the description) into the hash-blender. So much more goes in than just a few configure options.
<nckx>Every single bit (literally) of information about the package and all its dependencies.
<sunmaster>nckx: Okay, you gave me an idea there, how to accomplish my thoughts about "clear name" package database
<nckx>I think the current scheme is close to (if not) ideal. It minimises collisions without being ridiculously wasteful. The only possible optimisation that might make sense is /gnu/store/h/a/sh-foo/, but that's already file system-specific and probably not worth it.
<nckx>If your goal is attaching human-meaningful metadata to store items, the store path is probably the worst place to put it.
<vagrantc>putting every single build into a single directory ... has it's cost ... and while ext4 can technically handle billions (trillions?) of files in a single directory ... in practice there are other considerations
<nckx>vagrantc: Maybe. Rather hard to benchmark that 😛
<nckx>I've never seen any of those symptoms and have had more than my share of graceless shutdowns.
<vagrantc>could also create a symlink tree alongside it, at the cost of an additional inode per item ... e.g. /gnu/human-store/package/version/hash or something
<vagrantc>nckx: yes, but how many terrabytes is your store?
<nckx>vagrantc: Heh. /gnu/bikeshed/package/version/hash is my favourite too.
<nckx>vagrantc: The problem I have with the symlink tree idea is a) people/build scripts will use both paths, so both effectively become API b) it's just a parallel shove-stuff-into-paths scheme with its own trade-offs where c) a separate database is what is probably desired.
<vagrantc>yeah, i can see the parallel symlink tree having some weird user-presenting issues
<vagrantc>e.g. accessing paths by multiple locations ...
<vagrantc>but isn't that already the case with the profiles being a huge pile of symlinks?
*vagrantc never knew tab-completion came up in babysitting!
<nckx>vagrantc: But those address store items at a different, er, ‘level’? /home/nckx/.guix-profile/bin/ls means give me the ls that nckx installed into their default profile. It's not a reference to a single build in time. Does that make sense?
*nckx once got kicked out of a Chuck-E-Cheese's for preferring emacs over vi.
*nckx isn't really up to discussing the hardest problem in computer science today. Too fuzzy.
<nckx>I mean I'm up for it, just not very clear in my thinking.
<ison111>Using GuixSD, is it normal on startup to see timeout errors coming from dbus-daemon, saying that it fails to start services like org.freedesktop.Accounts? I also see a red CRITICAL error that accounts-daemon fails to start because a timeout was reached trying to start org.freedesktop.PolicyKit1
<vagrantc>nckx: sure, the difference between profiles and the store are meaningful ... but it doesn't seem implausible to have another view of the same filesystem
<vagrantc>heh. could implement it as a fuse backend :)
<nckx>vagrantc: I'd personally prefer something like that that doesn't even touch Guix itself. Then everyone can make their own! 😛
<nckx>We already know that performance on NFS sucks, but then we already know performance on NFS sucks.
*kmicu wanted to point out that Nix has order of magnitude bigger farms than Guix; current store format still works there so it’s too soon to optimize it. hydra.gnu.org kerfuffle was more about terrible IO setup as pointed by Ludo.
<vagrantc>terrible i/o involving lack of lots of ram
<kmicu>Nix farms don’t have lots of RAM though. (Where lots of RAM ≈ 32GB)
<lfam>It wasn't just a lack of RAM. The storage array that used to host <hydra.gnu.org> was a VM with virtualized software RAID on spinning disks. When shared with other VMs, it was extraordinarily slow
<apteryx_>rekado: I decided to persist with the 'guix pack -f docker' approach, as guix system docker-image seemed heavy (it includes guix itself, the kernel, etc). So far I was able to get useradd and groupadd to work, but I'm still working out on 'su': https://paste.debian.net/1076903/
<apteryx_>(also I couldn't get my very barebone config to boot when using docker-image, but I must have done something wrong)
<apteryx_>su is the last missing bit to enable 'guix pack -f docker' to be super lightweight (lighter than official debian images) container which can do work as your own user so as to not foobar the permissions of files in bindmounted volumes.