IRC channel 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>o/

<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 http://logs.guix.gnu.org/guix-hpc/2022-08-16.log

<civodul>reminds me of someone who wanted to standardize the nar format

<drakonis>same day at guix

<drakonis> http://logs.guix.gnu.org/guix/2022-08-16.log#002114

<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>Hi!

<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?

IRC channel logs

2022-08-29.log