| 20 Jun 2025 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @emilazy:matrix.org
I haven't thought that much about how much value we get out of needing to make it explicit, but generally I'd say derivations being able to talk over the network is a pretty bad default Why don't we disable it for Linux as well so we get some consistency | 18:00:52 |
 emily | btw, it is not needed on Hydra at all, since Hydra does not use the sandbox | 18:01:03 |
| emily | for better or worse | 18:01:11 |
| emily | (the sandbox is off by default) | 18:01:28 |
| emily | because on Linux it is actually isolated, since Linux has network namespaces and builds run in a namespace with their own loopback interface and nothing else | 18:01:44 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @emilazy:matrix.org
because on Linux it is actually isolated, since Linux has network namespaces and builds run in a namespace with their own loopback interface and nothing else I know | 18:02:08 |
| emily | Darwin sadly lacks that functionality | 18:02:09 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | But you'd make them know they are doing it wrong, rather than failing silently on some other cases | 18:02:35 |
| emily | it's not really silent, is it? that's why we have CI/ofborg | 18:11:22 |
| emily | there's no way to know whether something will build on a platform before something actually attempts the build | 18:11:37 |
 John Ericson | https://pad.lassul.us/zvvXlsRCRVeXU48WWaCpDg | 22:35:16 |
| John Ericson | We on the SC are thinking about this as a possible project to organize and fund on the foundation level | 22:35:51 |
| John Ericson | were curious what the Stdenv Team thinks about this | 22:36:08 |
| John Ericson | CC tomberek | 22:36:11 |
| John Ericson | to be clear, at this point, we're thinking more about the first step of a relocatable store | 22:36:42 |
| emily | it was discussed here recently :) | 22:41:02 |
| emily | here | 22:41:16 |
| emily | it's something I've thought about before, there are some tricky issues I outlined, I expect somewhat invasive patching across the tree would be necessary, but the initial hurdles are more writing loader code etc. | 22:41:52 |
| emily | I think it would be feasible but hard (and some packages may never work) | 22:42:19 |
| emily | I see this came up as DT_INTERP in the doc. I think you can just solve the problem by avoiding the kernel's code for it as I outlined earlier. | 22:43:02 |
| emily | IIRC #!/usr/bin/env -S is not portable wrt macOS so may not be a good solution for shebangs. | 22:43:44 |
| emily | might be workaroundable. | 22:43:58 |
| John Ericson | oh my bad | 22:44:08 |
| John Ericson | I was scrolling around and didn't see it yet | 22:44:14 |
| John Ericson | with the static PIE? | 22:45:56 |
| John Ericson | that does sound nice | 22:46:14 |
| John Ericson | I'm hoping if we actually do it, we can petition POSIX to standardize more $ORIGIN | 22:46:42 |
| John Ericson | so the cure gets better, longer term | 22:46:51 |
| emily | you just need loader code that resolves out the interp path and does exec. hopefully. unless that doesn't quite do the right thing in which case you need to load the interp into memory and jump into it, which would be awful | 22:47:17 |
| emily | anyway it's definitely prototypeable I think and I've toyed with the idea but it'd take a lot of time and not sure the appetite for the requisite patching would be there in Nixpkgs | 22:47:58 |
