# eudev: udev split out of systemd so a distribution can drop the init system > eudev is a standalone dynamic and persistent device naming daemon, forked from systemd's udev, that runs independently of the init system and is used as the devfs manager by more than a dozen distributions. It suits a distribution or an embedded image that wants device nodes without systemd, and the release history jumps from 3.2.14 in 2023 to 3.2.15 in September 2026. **eudev-project/eudev** — Repository for eudev development - Repository: https://github.com/eudev-project/eudev - Stars: 580 · Forks: 144 - Language: C - License: GPL-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/eudev-project-eudev ## What eudev actually is, and where it came from eudev is a standalone dynamic and persistent device naming support daemon, also described as a userspace devfs, and it runs independently from the init system. The name and the behaviour are worth separating. The daemon's job is the one udev has always had in the systemd tree: it watches device events from the kernel, and it creates and manages device nodes in /dev with stable names, applying permissions and ownership through rules and a hardware database. What eudev changes is not that behaviour but the dependency. The history is stated plainly in the project README. This git repo is a fork of git://anongit.freedesktop.org/systemd/systemd with the aim of isolating udev from any particular flavor of system initialization, and in this case the isolation is from systemd. So the ancestry is upstream systemd code, and the fork exists to cut the tie to the init system rather than to rewrite the daemon. The stated goal is to remain init system and Linux distribution neutral, and the claim of coverage is that eudev is currently used as the devfs manager for more than a dozen different Linux distributions. That is a meaningful claim to make, because udev is the component that most distributions kept when they removed systemd, since without it device nodes would be static and a machine would come up with the wrong permissions on /dev/input and friends. The primary language is C, the licence is GPL-2.0, and the default branch is master. The repository is laid out like an autotools project, with a configure.ac, a Makefile.am, an autogen.sh script, and separate directories for src, rules, hwdb, man, test, rule_generator and the BUILD, CONTRIBUTING, LEGACY and NOTES documents. ## The project was restarted by three distributions, and that history still shows The governance history in the README is unusual enough to be worth reading closely, because it explains the project you are looking at today rather than the one you might expect. The project was started by Gentoo developers, and testing was initially being done mostly on OpenRC. The invitation to contribute from others using a variety of system initialisations is explicit, with the stated purpose of ensuring eudev remains system initialization and distribution neutral. Then the history turns. On 2021-08-20 Gentoo decided to abandon eudev, and a new project was established on 2021-09-14 by Alpine, Devuan and Gentoo contributors, in alphabetical order. The current project therefore lives under the eudev-project organisation, and the team list names Arsen Asenović, Luca Barbato, Anthony G. Basile, Boian Bonev and Ariadne Conill as active team members, with an emeritus list of Francisco Izquierdo, Ian Stakenvicius, Matthew Thode, Tony Vroon and Richard Yao behind them. Two consequences follow. The first is that a fork of a fork of a distribution package is now the canonical upstream, which is a reminder of how much of systemd's utility code had become a de facto standard on Linux. The second is that the current maintainers are three distributions with a shared interest in not depending on systemd, which is a coherent motivation. The Gentoo situation is also stated, and it is a live caveat for anyone evaluating the project. eudev is no longer in the Gentoo main tree. The third-party without-systemd overlay provides sys-fs/eudev and a virtual/udev that accepts it, but that overlay is not maintained by this project. So a Gentoo user adopting eudev is depending on an overlay outside this repository's control, and the README is honest about the boundary. ## Where the device naming rules and the hardware database live The directory listing tells you where the substance of the project is, and it is not in src. The rules/ directory holds the rule files that decide what happens to each kernel device, and hwdb/ holds the hardware database that assigns properties to devices by identifiers such as USB vendor and product IDs. Both are the parts a distribution customises, and both are the parts a hardware database update touches on every kernel release. The rule_generator/ directory is the tool that produces those rule files, and it is a distinct top-level entry rather than a script buried in the source tree. That separation matters for maintainers, because rules are generated from hardware data and then patched by hand, and a distribution that wants to adjust the generation needs a stable place to point it. The man/ directory holds the manual pages, test/ holds the test suite, and src/ holds the daemon itself in C. The top-level documents are BUILD, which covers building the project, CONTRIBUTING, COPYING for the GPL-2.0 terms, LEGACY and NOTES. The presence of LEGACY and NOTES alongside BUILD is a hint about what a fork of a large upstream carries with it: not just the code but the history of what was removed, what was left behind and what the maintainers decided to keep. The build system is autotools rather than meson. configure.ac and Makefile.am are present with autogen.sh to regenerate the build files, and there is a .travis.yml file from the era when Travis was the CI default, alongside a .github/ directory whose build workflow badge is the one shown in the README. The build badge points at a GitHub Actions workflow named build.yml, so the continuous integration runs on GitHub Actions while the older Travis configuration file is still in the tree. ## Getting a release, and building it yourself There are three sources of releases, and they are listed in the README without much commentary, so the choice comes down to what you need. The homepage is the GitHub organisation page for the project. Tarballs of releases are on the GitHub releases page of the same repository. Old releases are archived at a Gentoo-hosted location, which exists for the versions that predate the current project or the current packaging. The build path is autotools, and the repository ships the standard entry points. The configure.ac file holds the configuration checks, Makefile.am is the top-level makefile definition, and autogen.sh is the bootstrap script that regenerates the configure script from configure.ac and the automake inputs. For a project descended from systemd's build system, that arrangement is inherited rather than chosen, and it is familiar to anyone who has built a GNU-style C project. ```bash Homepage: https://github.com/eudev-project/eudev ``` The README does not give a step-by-step build recipe beyond the existence of the BUILD document and these files, so the practical guidance for a packager is to read BUILD in the tree and follow the standard autotools sequence from there. The last push was on 2026-09-27, the same day as the v3.2.15 release. The release before that was v3.2.14 from 2023-10-05, and before that v3.2.12 from 2023-05-16. That gap of roughly three years followed by a new release is worth noting for anyone pinning versions: the project was quiet and then shipped, so the version you find in a distribution's repository may predate the current release by a long way. The community gathers on Libera.Chat, with the channel given as ircs://irc.libera.chat:6697/#eudev and a web link to the same channel, and the team member list with real names and contact addresses is part of the README rather than buried in a wiki. ## What eudev gives you against udev, and what it costs The comparison is not really eudev against a different project. It is eudev against the copy of udev that already ships inside systemd. The systemd version is the same code base, maintained in the systemd tree, and it inherits udev's integration with the rest of systemd: the daemon is started by systemd, its log goes to the journal, and it can be configured with the same unit and drop-in mechanisms as everything else. If your distribution ships systemd, that copy is free, it is tested with the rest of the tree, and it is what most udev rules on the system are written against. What eudev adds is the ability to have the same daemon without the init system. That matters for three kinds of system: a distribution that has removed systemd and wants only its useful pieces, a small embedded or appliance image where every process is a cost, and a container or chroot build where you want device nodes without pulling in an init. The README frames it as remaining init system and Linux distribution neutral, and the claim that it serves more than a dozen distributions is the evidence for that. The costs are real. Running two device managers on one machine is not a supported configuration, because both would respond to the same uevents and race to create and own nodes in /dev. So eudev replaces systemd's udev rather than accompanying it. The daemon also has to be started by whatever your init is, and the README's neutral framing covers the systemd case and OpenRC, the init system that testing was initially done mostly on, but the README does not document a setup guide for each init it supports. There is also a maintenance asymmetry. The systemd copy gets worked on by the systemd developers alongside the rest of that codebase, while eudev is maintained by a small volunteer team from three distributions, and the 2023 to 2026 gap in the release history shows what a small team can and cannot sustain. For a distribution that has already made the hard decision to drop systemd, that trade is worth making. For a general-purpose desktop or server distribution, the systemd copy is the better deal. ## Conclusion eudev fits a distribution maintainer or an embedded image builder who needs the standard device naming rules without shipping systemd, and it does not fit a system that already runs systemd's own udev, since running both would have two managers claiming the same device nodes. Before choosing it, check whether your distribution still ships eudev in its main tree, since Gentoo dropped it in favour of a third-party overlay that this project does not maintain, and confirm that the rules your distribution relies on are present in the hwdb/ and rules/ directories of the tree you build from. ## FAQ ### What is eudev and how is it different from systemd's udev? eudev is a standalone dynamic and persistent device naming daemon, also described as a userspace devfs, that runs independently of the init system. It is a fork of systemd with the aim of isolating udev from any particular flavour of system initialization, in this case systemd itself. ### Which distributions use eudev as their devfs manager? The README states that eudev is currently used as the devfs manager for more than a dozen different Linux distributions, and it is maintained as a neutral project by contributors from Alpine, Devuan and Gentoo. ### How do I build eudev from source? The project uses autotools. The repository contains configure.ac, Makefile.am and an autogen.sh bootstrap script, and the BUILD document at the top level covers the build. Releases are published as tarballs on the GitHub releases page of the project. ### Why is eudev no longer in the Gentoo main tree? Gentoo decided to abandon eudev on 2021-08-20, and a new project was established on 2021-09-14 by Alpine, Devuan and Gentoo contributors. In Gentoo, eudev is provided by the third-party without-systemd overlay, which the project does not maintain. ## Sources - [eudev-project/eudev on GitHub](https://github.com/eudev-project/eudev) - [Issues](https://github.com/eudev-project/eudev/issues) - [License: GPL-2.0](https://github.com/eudev-project/eudev/blob/master/LICENSE) - [README](https://github.com/eudev-project/eudev/blob/master/README.md) - [Releases](https://github.com/eudev-project/eudev/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eudev-project-eudev