IRC channel logs
back to list of logs
<rekado_>I’m now using Shepherd as the container supervisor. <rekado_>it’s a bit clunky, and I feel I’m doing things wrong, but it works <rekado_>for every container I eval a service definition with a bunch of actions, e.g. to get the container pid, print its pid, bring up or shut down the network, etc <drakonis>there was a very interesting discussion 2 weeks ago <civodul>reminds me of someone who wanted to standardize the nar format <drakonis>i ended inviting as a means of allowing the author to make his case to the contributors with more knowledge <drakonis>i've already opined on the matter during the discussion when it took place <drakonis>civodul: do you have any thoughts on the matter right now? <civodul>drakonis: not really! i like the idea in principle <civodul>i'm not sure "sharing the test suite" is an attractive argument for Guix or Nix developers though <ericson2314>I do hope to circle back and post my thing to the list <ericson2314>About enforcing the showing off the layering better on our end <ericson2314>civodul: you might also remember me for having emailed the maintainers mailing list about sharing content-addreesed derivativions between Nix and Guix <ericson2314>But I saw some of your points so I now think standardizing the existing stuff we have we can common first is better :) <drakonis>since i've been out of the loop of what's been going on on the nix side of things, have they ever sorted out secrets? <civodul>ericson2314: oh right, that rings a bell <ericson2314>it will be easier to think about in an all-CA world, where we separate data itself from claims of what the data represents <ericson2314>Basically thought experiment is "Suppose we turned off the ability to stat the store directory. Then what?" <ericson2314>I think this is a good channel to soft-propose- thing in, because all the potential benefit in sharing daemon ideas/innovations with less friction is best for HPC / institutional use-cases <ericson2314>single-machine users are probably fine with the daemon that exists to day, for the most part, wit Nix and Guix alike <ericson2314>but in the institutional compute farm setting there is absolute huge potential to make things way better <ericson2314>And I would love to have Nix and Guix both benefiting on day 1 :) anytime some makes a thing to improve the situation <efraim>as a hack a few years ago on the small HPC I help support I added a line to my .bashrc 'export GUIX_DAEMON_SOCKET=ssh://headnode' <rekado_>in many Guix packages we disable compile-time CPU tuning. <rekado_>should we enable the tuning option for those packages, too? <rekado_>or is that only really supposed to be used for libraries?