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>oh hey, its ludo!
<civodul>how's everything here? :-)
<drakonis>all's cool and full of musings
<civodul>good :-)
<drakonis>there was a very interesting discussion 2 weeks ago
<drakonis>on #guix
<drakonis>also in here there's
<civodul>reminds me of someone who wanted to standardize the nar format
<drakonis>same day at guix
<civodul>interesting, thanks for sharing!
<drakonis>the author is here
<drakonis>as i invited him then
<civodul>oh nice
<drakonis>i'm not sure if it is a problem
<civodul>it sure isn't, on the contrary!
<drakonis>ah, cool.
<drakonis>i ended inviting as a means of allowing the author to make his case to the contributors with more knowledge
<drakonis>ericson2314: are you around?
<drakonis>i've already opined on the matter during the discussion when it took place
<ericson2314>Yes I'm around
<drakonis>civodul: do you have any thoughts on the matter right now?
<civodul>hey ericson2314, welcome :-)
<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>I also want to post some things Nix side
<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>drakonis: No, but I do have some ideas on that :)
<drakonis>cool cool
<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>and the all CA world makes that easier
<drakonis>that would certainly make life easier
<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
<drakonis>indeed it is.
<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?