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 |