Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[zimoun <zimon.toutoune@gmail.com>]

Hi Tobias, All,

(French Bastille Day is a day off, so a day for trolling. ;-))


On Thu, 14 Jul 2022 at 10:40, Tobias Geerinckx-Rice <me@tobias.gr> wrote:

> https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/

Thanks for the link.  It is helpful for understanding. :-)


> Far from 'recent' in my book.

Indeed, the announcement is from 2019-12-21. :-)

Quoting:

        This will not be a "distro", but a hard fork of the OpenBSD
        kernel and userspace

Not being a new distro means using the venerable pkg_* package manager,
right?  Well, I am confused by the aim…


>> If you run OpenBSD kernel and OpenBSD userland, why not just run an
>> OpenBSD system? :-)
>
> Because it contains blobs.  HyperbolaBSD doesn't, by definition (see above).

…because HyperboladBSD seems a new distro as gnewSense is a new distro
free from problematic parts but based on an existing other one.  Well,
since it had been announced on late 2019 and we are in 2022, it could be
interesting to know the status on this project.


> Whatever my opinion on WSL, Darwin, and the Hurd, I must concede that they at least exist.  
>
> Porting Guix to something that doesn't is a poor investment in comparison.

Just to be sure to understand, the initial question is to port Guix to
HyperbolaBSD which is a variant of OpenBSD (kernel and userland).

Therefore, correct me if I misunderstand something, it means:

 1. port Guix to a new kernel not using the GLibc
 2. package all the (free) userland OpenBSD managed by Guix

Bah I wish all the best for people who would tackle this. :-)

Well, dreaming about science fiction, it appears me more approachable to
have Guix running on something as Debian/kfreeBSD – it could be an
interesting project with the help of Debian folks.  Other said, “just”
replace the Linux kernel by a variant of the FreeBSD one running with
GNU GLibc.

However, doing so, the point #2 (BSD userland) is lost.

My understanding is: #1 and #2 require more work than the union of the
Guix community *and* the other kernel community could provide, IMHO.
Assuming both communities would be interested in. :-)


Cheers,
simon