1 |
On Tue, 27 Dec 2016 19:53:47 +0100, lee wrote: |
2 |
|
3 |
> > I would imagine because it cannot be used without some initial |
4 |
> > configuration. The default provides the greatest reliability out of |
5 |
> > the box, at the expense of less readable (which is not the same as |
6 |
> > unrecognisable, a value judgement you are imposing on the names) |
7 |
> > names. |
8 |
> |
9 |
> I call them unrecognisable because they are hard to recognise, as in |
10 |
> hard to read and impossible to remember. I find that annoying. I can |
11 |
> call them "annoying names" if you prefer that :) |
12 |
|
13 |
I do, or "difficult to remember" or "cryptic", but they are not |
14 |
unrecognisable - except to those that wish them to be. |
15 |
|
16 |
> > There is nothing wrong with wanting things to work as you do, but it |
17 |
> > requires input to do so. It you have to start editing files to make it |
18 |
> > work properly, there is little point in making it the default. |
19 |
> |
20 |
> Right, and it could work without editing files manually. A |
21 |
> configuration file assigning editable names to the annoying names could |
22 |
> be created automatically and filled by assigning the name an interface |
23 |
> already has to it (because when it has a name, the name is known, which |
24 |
> is easier than trying to make up all possible names in advance). Then |
25 |
> only if you wanted you would edit the configuration file to assign the |
26 |
> name(s) of your choosing, and if you don't want to do that, you simply |
27 |
> get the names you get now. There would be no change to how the names |
28 |
> are now, only an additional option. |
29 |
> |
30 |
> That would also have the advantage that when the annoying name of an |
31 |
> interface changes, you can choose to either adjust all configuration |
32 |
> files in which you have specified a particular interface or simply |
33 |
> adjust the one configuration file that assigns the names. |
34 |
> |
35 |
> I actually wonder why they didn't virtualise the names. It makes too |
36 |
> much sense for not to do it, and you could do likewise with other |
37 |
> devices (especially disks). |
38 |
|
39 |
That's a reasonable approach, and you could have the ebuild set it up |
40 |
with a USE flag. All it takes is for someone that cares enough about it |
41 |
to do something. |
42 |
|
43 |
|
44 |
-- |
45 |
Neil Bothwick |
46 |
|
47 |
I have seen the truth, and it makes no sense. |