It can get even funnier when Chris Baines replaces the Nix daemon with a new implementation in Guile. Then, the NIH argument can be reused instead.

Any news on that front?

> The daemon also is a key part of the history of Guix. The Guix project started mixing Guile with ideas from the Nix project, and the guix-daemon is a fork of the nix-daemon with some tweaks made over the years. Rather than being implemented in Guile though, the daemon is implemented in C++ with some helpers written in Guile.[1]

[1] https://guix.gnu.org/en/blog/2023/a-build-daemon-in-guile/

---

Found https://github.com/alezost/guile-daemon (https://packages.guix.gnu.org/packages/guile-daemon/), too, which is just as old. Is it "finished"?

I suppose nothing has happened out of https://summerofcode.withgoogle.com/archive/2017/projects/59...?

Is https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/... even relevant today?

The Summer of Code project was unsuccessful for personal reasons. The project was also never even close to high priority, because the daemon just isn't all that interesting beyond performing its one job of implementing the functional package management paradigm. That is to say, for a long time there was very little to be gained from a rewrite.

The most recent project has only just started and is spearheaded by Chris Baines, who has extensive experience with the build side due to his work on a (Guile-based) build coordinator used by one of the two major independent build farms.

I don't think the older branches contain much that needs to be ported; most of the work from past projects has in fact made it into Guix already and is used for other features --- just not in the daemon. If the Guile daemon project is successful, the daemon will incorporate many of these existing features for build isolation and coordination.

Have you tried reading the code? It's twice as large (107KLOC) as ext4 (45KLOC), where ext4 is viewed as a natural evolution of ext2 (7KLOC).

45KLOC of C code already sounds really scary to me, although yeah, journaling is really nice to have.

Yes, that's scary. Understandable, but it does come with a lot of functionality that's nice to have no?

GNU is not an ecosystem (see <https://www.gnu.org/philosophy/words-to-avoid.en.html#Ecosys...>), it's a philosophy.

Yes, it's old. Yes, there's only little interest. Yes, there are _still_ many technical problems.

The interesting thing here is that technical problems can be solved, and will be solved given enough time. Heck, I've heard rumors that even Windows does not crash multiple times a day anymore.

Focussing and working on what is popular will most likely create a world that is less free every year. Some people rather work on something that seems right and promises a better, freer future. Even if it's not popular (right now), even if it has a high probability of failure.

Popularity is a very volatile property...

The biggest success that GNU has had is that they made it incredibly unpopular to keep source code proprietary and closed. It is no longer necessary to limit yourself to just the GNU OS in order to enjoy limitless freedom of computing.

And popularity might be a double edged sword, but double edged swords are still useful if you're careful.

That's a great compliment as I think the core vision of GNU is that all software should be free (<https://www.gnu.org/philosophy/shouldbefree.en.html>).

Although keeping software proprietary or writing proprietary software may have become somewhat unpopular in some niches (I'm not sure it's incredible unpopular seeing how many people and institutions still use and often advocate Apple, MicroSoft, use FaceBook, WhatsApp, whatsnot...), I'm not yet convinced that many people (say more than 1%) really believe that all software should be free and act on that?

Hurd does not support USB devices, officially, just yet, but these are surely exciting times. Unless maybe you're a capitalist ;-) <https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00158...>

By reading the fine manual (<https://guix.gnu.org/manual/en/html_node/Virtualization-Serv...>) or blog post (<https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes...>).

TL;DR; Add this

    (service hurd-vm-service-type
             (hurd-vm-configuration
              (disk-size (* 5000 (expt 2 20))) ;5G
              (memory-size 1024)))             ;1024MiB

GNU Shepherd system service description to your system configuration, and reconfigure; then just do something like

    sudo herd start childhurd
    ssh -p 10022 root@localhost

If you're not using Guix System, you can still download a prebuilt QEMU image from <https://guix.gnu.org/en/download/latest/>:

    wget -O hurd-latest.img https://ci.guix.gnu.org/search/latest/image?query=spec:images+status:success+system:x86_64-linux+hurd-barebones.qcow2

and do something like:

    qemu-system-i386 -m 2048 --enable-kvm --hda hurd-latest.img

Enjoy!

Rumpdisk on a GNU Guix childhurd: https://toot.aquilenet.fr/@civodul/110848429561223704

just one simple `guix system reconfigure' away!

Guix Hurd on my thinkpad x60: https://todon.nl/@janneke/110451493405777898

yeah, that's real (old, but not ancient) iron.

Enjoy!

What I don't understand is why people are so willing to install and run opaque binary blobs, even is it's from/supporting free software-hostile Evil Corp. I've been running GNU Guix, which uses Linux-Libre--i.e., no blobs-- on my Dell XPS-13 and Lenovo x270. The only change I needed to make to buy my freedom was install an atheros wifi card (yeah, proprietary bios sucks, buy puri.sm).

And while Guix/Hurd isn't there yet as a daily driver (Debian/Hurd is much more polished), progress has been pretty exciting lately and it now runs on my IBM x60 -- https://todon.nl/@janneke/110451493405777898

Ah no, there is no competition, at least not yet ;)

Stage0---of with cc_x86.c is a part---as a project started off from the bottom (hex0) and is working up. When stage0 just started, I created GNU Mes soon to be folowed by MesCC, which aimed to build a version of TinyCC and the remaining bootstrap for GNU Guix. The first versions of mescc had its own linker, which was later in a joint effortt replaced by M1 and hex2 from MesCC-Tools (also part of Stage0.

My initial idea for Mes was to translate it by hand to assembly, so the M1 assembler would come in handy. As it turned out, cc_x86.c and its next step M2-Planet were developed as part of Stage0.

Starting from an 357-byte hex0 provided by the bootstrap-seeds, Stage0-posix builds hex0, kaem, hex1, catm, hex2, M0, cc_x86, M1, M2, get_machine, (mescc-tools), and M2-Planet. M2-Planet in turn builds Mes, which builds a bootstrappable TinyCC, etc.

Thanks for your answer!

I'll try out some bootstrapping paths and will make an effort of getting a full understanding of the whole picture, and am hoping to write something up about what I find out.

(BTW I did ask on IRC, some further details might be found from the answers I got here: http://logs.guix.gnu.org/bootstrappable/2022-05-03.log#14495...)

NixOS is an awesome system and Guix owes much to it and its creator, @edolstra.

Although GNU Guix is my personal preference, I believe that NixOS is an excellent choice and for the most part we have a shared vision.

If you are still using a legacy system, you'll want to try NixOS or GNU Guix!

I have been using GNU Guix for over 4 years now on a modern Dell laptop (exchanged the WIFI card to keep my freedom), two older thinkpads, home server.

Since three years our development team at work uses Guix; the reproducible offload builds are awesome. Extending the package graph with your own version of packages is very helpful. Since about a year we also use server(s) at Digital Ocean running GNU Guix.