On Mon, Mar 3, 2014 at 12:57 PM, Barry Schwartz <chemoelect...@chemoelectric.org> wrote: > Canek Peláez Valdés <can...@gmail.com> skribis: >> Of course every single user can keep a neat and clean /dev directory. >> The point is, most users don't want to do that. Using udev solves that >> issue *for every possible user using every possible hardware >> combination*. > > Which is why it is a nice _option_, unnecessary for Gentoo in general,
Whoa, excuse me? Who are you to make that call? I'm a Gentoo user, and I think udev is necessary. Besides, Gentoo uses udev *by default* since, like, ever. That is not going to change, at least soon, and probably never. > and foolish to make a _prerequisite_ to run a whole lot of > software. That's your opinion, and you're entitled to it. I don't share it, and (more importantly) the Gentoo devs don't share it, since udev is installed and used by default in Gentoo. If you want to use eudev (or mdev), you need to do it by yourself. > That’s exactly my point, and I think it was Frank’s as well. I understand; I'm just trying to explain why every Linux distro (except a few niche ones) uses udev, and why most of them use systemd. > The trouble comes not from udev itself but from ‘vertical integration’ > involving udev, which is directly contrary to principles of good, > modular design. We already had this discussion in -user (and they had it in Debian, Arch, OpenSUSE and Fedora). Those "principles" you speak of are not religious commandments; they are rules of thumb, and the sky doesn't fall if you don't follow them to the letter. And, also, it can be argued that systemd/udev has a good modular design. From [1]: "1. Myth: systemd is monolithic. If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too. A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle." That's all I will post related to the good or bad design of systemd; we've had that conversation many times in different lists, and I will not enter to it again. Specially since, every single time, the consensus from the people that actually write and design code is that systemd is quite good, or at least OK. This thread is about the new /etc/systemd/network directory, and how its cooties infect a machine. Regards. [1] http://0pointer.de/blog/projects/the-biggest-myths.html -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
