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