Hello Guix!

Gabriel Wicki <[email protected]> writes:

> just yesterday, mbakke came to #guix to promote their udev replacement
> written in Guile, goodev¹.  They told me they were using it, already, so
> maybe this is good enough for a wider populus to test, extend and adapt
> for Guix?

I now believe it is ready for testing by a wider audience.  If you'd
like to try it, stick this in your channels.scm:

  (channel
    (name 'goodev)
    (url "https://codeberg.org/goodev/goodev";)
    (branch "main")

Then you can (use-modules (goodev-service)) and use it like so:

  (services
   (cons* (service goodev-service-type)
          (modify-services %base-services
            (delete udev-service-type))))

Note: this won't work if you have any service that extends
udev-service-type like elogind.

(I'm working to decouple eudev from udev-service-type, but it's tricky)

> They did mention that they used LLM to craft this piece of software,
> though to me the reasoning is sound, and the risk of losing it to the
> LLM corp due to copyright law seems small to inexistent.

I have used LLM for some parts like (hwdb trie) and the inotify
implementation.  And all "builtin" modules like 'path-id' are pure LLM
translations of the systemd C counterparts.

There were some LLM commits in the "core", but I have since rewritten
the entire "API surface" to get rid of LLM smells.  There was a lot!

The code is now much more pleasant to work with.

> @mbakke: Do you have a Guix Service ready for this?  Do you think it's
> ready to include in Guix (at least for tests)?

Now that there is a channel, I'm not in a hurry to merge it to Guix.

Things that rely on libudev like 'libinput' might not work without a
proper udev daemon.  I'm working to fix that (the database
implementation is identical to udev, and thus compatible with libudev;
but the 'udevadm monitor -u' netlink protocol is not yet supported).

Apropos libudev: I have fully "vibe-coded" a libudev in Rust:

  https://codeberg.org/goodev/goodev/src/branch/libudev-rust

I'm looking for someone to take ownership of that and help get it
merged.  Otherwise I'll learn enough Rust to merge it myself.  But
someone may need to stop me from porting the entire thing to Rust in
that case!

(just kidding, Guile is exceptionally well-suited for this task: I
believe goodev is *faster* than systemd-udevd in many cases)

Prospective hackers should know that it's perfectly safe to run goodev
as an unprivileged user for testing.  One fun activity is running
"./pre-inst-env goodev-daemon --monitor" in one window, and
"udevadm monitor -u -p" in another and compare output. :-)

Reply via email to