1 |
On 26/12/2016 20:35, lee wrote: |
2 |
> Tom H <tomh0665@×××××.com> writes: |
3 |
> |
4 |
>> On Fri, Dec 23, 2016 at 9:07 PM, lee <lee@××××××××.de> wrote: |
5 |
>>> Tom H <tomh0665@×××××.com> writes: |
6 |
>>>> On Mon, Dec 19, 2016 at 3:07 PM, Daniel Frey <djqfrey@×××××.com> wrote: |
7 |
>>>>> |
8 |
>>>>> It is even more frustrating that these so-called predictable network |
9 |
>>>>> names actually can change on a reboot, it's happened to me more than |
10 |
>>>>> once when multiple network cards are detected in a different order. |
11 |
>>>> |
12 |
>>>> >From Kay Sievers in [1]: |
13 |
>>>> |
14 |
>>>> <BEGIN> |
15 |
>>>> Btw, predictable means it will not change between reboots, that names |
16 |
>>>> will not depend on enumeration order within the same setup. It does |
17 |
>>>> not mean or promise, that added kernel/driver/firmware features will |
18 |
>>>> not result in different names. That is expected behavior. |
19 |
>>>> </END> |
20 |
>>>> |
21 |
>>>> [1] https://lists.freedesktop.org/archives/systemd-devel/2015-October/034614.html |
22 |
>>> |
23 |
>>> So the names will not change when rebooting and are to be expected to |
24 |
>>> possibly change at any time. |
25 |
>>> |
26 |
>>> How is that more reliable? |
27 |
>> |
28 |
>> It's more reliable than using the kernel's names because the names |
29 |
>> won't change UNLESS there's kernel/driver/firmware change for that |
30 |
>> NIC. I doubt that these changes occur that often. Perhaps someone else |
31 |
>> knows. |
32 |
> |
33 |
> What happens more often: That a network card is replaced with a |
34 |
> different one or that the software changes? |
35 |
> |
36 |
|
37 |
|
38 |
OK, let me try explain this again. |
39 |
|
40 |
NIC names are tricky, several posters (myself included) have laid out |
41 |
various methods and options by which it can be done. Experience shows |
42 |
that in real life the simple traditional names are easy to remember but |
43 |
prone to changing and (worse) prone to race conditions. Other methods |
44 |
change less often in reality but the names are somewhat trickier to |
45 |
remember. |
46 |
|
47 |
Opinions on these things differ; experience on these things differ and |
48 |
people's use cases on these things differ greatly. A coder working in |
49 |
this area has to decide what sort of cases they want to support, what |
50 |
problems they want to attempt to solve and what new features they want |
51 |
to introduce; then they have to write the code. |
52 |
|
53 |
Once the code is written, the coder then has to decide what nomenclature |
54 |
to use when describing the software and the effects it has. In this case |
55 |
centered around systemd a word was chosen: "reliable". |
56 |
|
57 |
Some will think it's a good name, some don't care, some will think it's |
58 |
a bad name; and all of those things are basically irrelevant because the |
59 |
name doesn't tell you much abut what the software will do. Reading the |
60 |
fine manual will tell you that. It's all a part of being human because |
61 |
our languages are imprecise, heavily overloaded and hugely redundant. So |
62 |
are our spellings. But we are stuck with it because that's the general |
63 |
emergent behaviour of a homo sapiens brain. |
64 |
|
65 |
Arguing abut this is about as nonsensical as arguing about whether "lee" |
66 |
is a good handle on a forum or not. To a pedant it's a bad name, one |
67 |
can't tell if you are male, female or if it's actually an Asian family |
68 |
name.... |
69 |
|
70 |
Or one could do what most folk do, and not see a problem with 3 letters |
71 |
|
72 |
-- |
73 |
Alan McKinnon |
74 |
alan.mckinnon@×××××.com |