Gentoo Archives: gentoo-amd64

From: "Canek Peláez Valdés" <caneko@×××××.com>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...
Date: Mon, 03 Mar 2014 19:20:46
Message-Id: CADPrc80wuxMrXJu2Ja-v_jCBA=j+4hyxQdnUOyLAe3Y6LnvGCw@mail.gmail.com
In Reply to: Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things... by Frank Peters
1 On Mon, Mar 3, 2014 at 1:10 PM, Frank Peters <frank.peters@×××××××.net> wrote:
2 > On Mon, 3 Mar 2014 12:20:29 -0600
3 > Canek Peláez Valdés <caneko@×××××.com> wrote:
4 >
5 >> >
6 >> > I have never used udev/eudev/mdev or anything similar and, if I am allowed
7 >> > to nave a choice, I never will.
8 >>
9 >> You will always have that choice, since the software is free.
10 >
11 > That's not true anymore. My USB scanners will not operate unless udev
12 > is able to create an entry within the /dev tree.
13
14 The repositories for everything SANE related are out there, aren't
15 they? Grab the code from pre-udev times and update it to support the
16 new scanners.
17
18 The code is free, you can do it.
19
20 > Fortunately, I was able to discover a work-around that does not require
21 > udev, but the point is that freedom of choice is starting to disappear.
22 > Udev will eventually be the *only* way to deal with hardware.
23
24 Mmmh, not true. The *BSD deal with hardware, and they don't use udev.
25
26 You mean in Linux? If someone *willing and able* wants to write
27 support for hardware that doesn't uses udev, they could, and they
28 will.
29
30 Of course, most people willing and able actually works with udev and
31 systemd, and they think they are a really neat idea. But the code is
32 out there, if you are so determined to pursue that goal.
33
34 I, and most people I believe, would think is a waste of time, but
35 that's the beauty of Free Software; nobody can stop anyone to write
36 what they want.
37
38 >> If you want to create a /dev tree for a computer that never gets new
39 >> hardware connected via USB, bluetooth, or another bus, yeah, it's
40 >> pretty trivial.
41 >>
42 >> Too bad that kind of computer is going the way of the dodo.
43 >
44 > Also not true. We are, to be sure, experiencing explosive growth in
45 > mobile computing but there is still a substantial number of traditional
46 > desktop machines in operation for which udev is still quite unnecessary.
47
48 Sorry, I believe you are wrong. I have a desktop computer, and I
49 connect a lot of hardware to it. Including bluetooth stuff.
50
51 I don't want to create a static /dev for it; I'm perfectly happy using
52 udev with my desktop computer.
53
54 > But, to continue your point, we can also claim that hardware itself
55 > is going the way of the dodo. The way of the future is to have Linux,
56 > and all other operating systems, existing on top of layers of virtualization
57 > without the need for specific hardware concerns at all.
58
59 And systemd works *beautifully* inside containers. If you are really
60 interested, I recommend you reading about systemd-nspawn[1].
61
62 > This possibility for total virtualization would still not be desirable
63 > for all.
64
65 I don't see how I can make a cell phone call without a physical cell phone.
66
67 >> The alternatives will be always available, of course.
68 >
69 > I hope that you are right, but when I see distributions like "Linux
70 > From Scratch," which purport to give the user total understanding
71 > and control of his system, not including alternatives to udev I begin
72 > to have serious doubts.
73
74 The alternatives will be always available, if someone writes code for
75 them and test them and fill bug reports for them. So, if you really
76 want the alternatives to work, help them. Contribute to its authors.
77
78 I'm perfectly happy with and standardized plumbing for Linux in general.
79
80 Regards.
81
82 [1] http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
83 --
84 Canek Peláez Valdés
85 Posgrado en Ciencia e Ingeniería de la Computación
86 Universidad Nacional Autónoma de México