I don't like the idea of merging a vibe-coded component in guix core. Replacing eudev with udev shouldn't be difficult for guix maintainers. I prefer udev to goodev if goodev is vibe-coded.
On Friday, October 2nd, 2026 at 8:59 PM, Marius Bakke <[email protected]> wrote: > 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. :-) >
