indieterminacy <indieterminacy@libre.brussels> writes: > > I recall dicussing this topic area with you last year: > https://lists.gnu.org/archive/html/help-guix/2021-06/msg00080.html > https://lists.gnu.org/archive/html/help-guix/2021-06/msg00082.html > https://lists.gnu.org/archive/html/help-guix/2021-06/msg00083.html > https://lists.gnu.org/archive/html/help-guix/2021-06/msg00084.html > https://lists.gnu.org/archive/html/help-guix/2021-06/msg00085.html > https://lists.gnu.org/archive/html/help-guix/2021-06/msg00086.html > > Im pleased that the Hyperbola community has been making strides. > > Hopefully I can one day have an OpenBSD kernel overseeing Guix SD. > > > Kind regards, > > > Jonathan McHugh
Looks like the most relevant bit to my question was here: https://lists.gnu.org/archive/html/help-guix/2021-06/msg00078.html The real problem will not be the languages (guile or C++), but the system calls used by Guix. Guix makes use of some recent (less than 2 decades) and somewhat advanced features of the Linux kernel, such as namespaces. To port Guix to another operating system such as BSD (including OSX), one would have to translate these calls. For example, Guix is the only software I've actually encountered that can not run in SmartOS' emulation of Linux, because the system calls it uses are not implemented there. I would love for Guix to be a Multi Kernel package manager (I mean it works on the Hurd also, but I have never encountered a Hurd user in real life). My dream would be to port Guix to Plan 9 ;-)
