Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

["Canek Peláez Valdés" <caneko@gmail.com>]

On Mon, Mar 3, 2014 at 12:57 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Canek Peláez Valdés <caneko@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