Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Neil Bothwick]

On Sat, 24 Dec 2016 10:50:53 -0500, Tom H wrote:

> >> I'm also a heretic who uses the systemd bootloader no matter what
> >> pid1 is in charge.
> >>
> >> It's the best thing that the systemd developers have produced!  
> >
> > Except they didn't produce it. They assimilated gummiboot, which I was
> > already using, into the systemd collective!  
> 
> Wasn't Kay Sievers one of the two gummiboot developers? (Along with
> Harald  of dracut fame.)

I had been unaware of that. But it was developed away from systemd
originally - maybe here was a conspiracy to add it to the systemd
collective all along ;-)

I was using gummiboot before I tried systemd.


-- 
Neil Bothwick

Marriage is a relationship in which one person
is always right and the other is a husband


pgp2wuL4PQVWz.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] where are KDE 5 menu item commands stored ?

[Fernando Rodriguez]

On 12/21/2016 11:27 PM, Philip Webb wrote:
> I just updated Tatham's puzzles & all my individual settings in the
> KDE menu were overwritten.
> 
> I'ld like to back them up to save labor the next time, but I can't
> find where they're stored. In  ~/.config/menus/  there's a file
> applications-kmenuedit.menu , whose content corresponds to the
> layout of my restored menu, but for each puzzle there's merely a
> filename, eg 'sgt-puzzles_galaxies-sgt-puzzles.desktop', whereas in
> the menu I've specified the command as 'sgt-puzzles_galaxies
> 15x15dn', which must be stored somewhere, as it opens correctly
> when clicked.
> 
> Can any KDE user advise ?
> 

I *think* it's ~/.local/share/applications.
Or just run: find ~ -name 'sgt-puzzles_galaxies-sgt-puzzles.desktop'


-- 

Fernando Rodriguez

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Dale]

lee wrote:
> Dale  writes:
>
>> lee wrote:
>>> Dale  writes:
>>>
 lee wrote:
> Dale  writes:
>
> I didn't go look at boards I had around here.  I went to a major
> computer supplier, newegg, and looked at what they had.  Go back and
> read again what I did and maybe read it more carefully. 
>
> Might I also add, it's more than just me that has pointed out that you
> are not correct on this.  It's a few others as well.  You ever stop to
> think that what you observe is not the normal and certainly not the
> default?  If what you claim was even remotely accurate, newegg would
> have had a lot larger number of boards with two ports on it.  Thing is,
> they didn't.  Kai pointed out that the same is true in Europe.  
> Why would I assume that what someone else observes is a default?
> Besides, I don't see what problem you're having with this.
>
>
 Then why would what you observe also be claimed to be the default?   As
 I also pointed out, it's not just what I observe, it's what I and others
 have observed as well.  So far, you are the only person claiming that
 two ports on a home user board is the default.  I have not seen anyone
 else post that you are correct.  Others have posted that you are not
 correct tho. 

 The problem is, you claim that having two ports is the default.  It is
 not the default.  I've said it, even researched it and explained how I
 researched it, others have also posted the same point.  Just because you
 have boards with two ports does not mean it is a default.  Given the
 research I did, it isn't even close.  Boards with two ports for a home
 user is not only not the default, it's somewhat rare.  Out of the top 72
 boards I checked, only a couple or so had two ports.  That is far from
 being the default.  That is quite rare.  Even if it was 5 boards, that
 would be under 10%.  That is hardly something to call a default.  If it
 were say 50%, then one could at least argue that the default is moving
 to having two ports.  It's just not the case. 

 The sooner you figure that out the better for you. 
>>> And eating rice is the default because so many people do it ...
>>>
>>> .
>>>
>> You can claim that having two ports is the default but that isn't
>> supported by a single fact.  As I said, the only person who thinks it is
>> a default is you.  The default would be set by the manufacturers.  Since
>> what is manufactured has to be sold, one good way to find out what the
>> default is, go look at what is being sold.  When you see something that
>> is common, like say four USB ports, then that is the default.  Another
>> example, if most all boards have five PCI-e slots, then that is the
>> default.  If you want six slots, seven slots or more, then you are
>> likely going to pay extra and have fewer buying options because that is
>> not the default. 
>>
>> Using your logic, no one eats rice since so much of it is grown and
>> sold.  If rice was not grown and not sold, then your logic would work. 
>> So, your post doesn't even make sense.  The manufacturers of boards by a
>> large margin puts one ethernet port on a home use board and even most
>> office computers only need one port.  If one goes and looks at what is
>> being manufactured and sold, they would be able to see that.  Of course,
>> some people can't see it even when several people post the facts.  It
>> seems some will never get the idea. 
> Rice is not eaten much around here, so it's not the default type of
> food.
>
> Besides, people buy what is being manufactured.  If all boards were
> manufactured with 4 ports, it wouldn't stop ppl from buying them, and if
> no rice was grown, it wouldn't stop ppl from eating (if sufficient
> quantities of other types of food were available).
>
>

Rice isn't eaten much around here either.  That IS NOT the point tho. 
The point is that having two ports is not the default.  As I said
before, if what you claim were even remotely true, then board sellers
would be listing boards with two ports by huge numbers.  They are not. 
It is rare even.  Well under 10%, likely less than 5%.  That is FAR from
being a default.  Anyone claiming otherwise is delusional. 

Given your other posts, I've come to the conclusion that you are truly
living in a world that is not based on reality.  You live is some bubble
that you have created where what you think is the only option.  You,
even when shown facts, can not accept anything that doesn't fit in your
little bubble. 

You posted that two ports is the default.  Others and myself posted that
is not correct.  I even went to the trouble to prove it.  Yet here you
are still posting that it is when you have yet to post a SINGLE fact to
back up what you claim.  I posted how I researched it and did so in a
way that you should be able to do the same, and see 

Re: [gentoo-user] Pale Moon Air-Gapped portage EAPI 6 Install WAS: [Logging] SSL with PM

[Miroslav Rovis]

On 161223-23:29-0800, Daniel Campbell wrote:
> On 12/23/2016 08:58 AM, Miroslav Rovis wrote:
...
> > 
> > Thanks if there will be any explanations and advice. And in the meantime, I
> > really enjoy using Pale Moon in my Gentoo, both master and, of course,
> > clone(s)!
> > 
> > Regards!
> > 
> 
> Could you be a bit more concise? I'm not sure what exactly you're asking
> about. A simple question or two might be enough to better explain your
> problem.
It doesn't look easy to me to do it.

With palemoon Gentoo overlay cloned, and Pale-Moon sources cloned, and
the sources git served by cgit installed on apache, I managed to install
Palemoon successfully.

But it's strange, because it installed in /usr/portage/distfiles with
strange directory names in the structure. Most prominently strange
being:

git3-src EGIT_MIRROR_URI=git:

(that's the name of the dir first level under /usr/portage/distfiles,
but there are more underneath)

Is that expected behavior with EAPI=6 in the ebuild, or is it a
successful installation just by some stroke of luck?

Note: the installed palemoon (but we're in the cloned system, another
system of same hardware as the Air-Gapped system where I installed...),
which I'm browsing online with, works faultlessly, as if I had installed
it regularly with layman and emerge while being online.

For any more detail, pls. look in the very detailed account of the
entire installation in my previous email which I took several hours to
write to my best ability.

> -- 
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
> 

Thank you for your kind consideration!
-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[lee]

Neil Bothwick  writes:

> On Sat, 24 Dec 2016 02:52:54 +0100, lee wrote:
>
>> >> I only know what the names are when I can look them up when the
>> >> computer is running.  I don't call that "predictable".  
>
> That's because you are using a different definition of predictable from
> that intended.

I'm not using a definition but understanding.  If you are about
definitions, then you should invent a new word by using the intended
definition and call the unrecognisable names by your new word.

>> > If they are constructed according to specific rules, they are
>> > predictable, by definition.  
>> 
>> You're overlooking that you need to know exactly, in advance, what the
>> rules are applied to, and all the rules, for having a chance that your
>> prediction turns out to be correct.
>
> So how do you write udev rules to rename ports without knowing the
> specifics of the hardware?

I don't.

> How do you know which port will be eth0 and which will be eth1 the first
> time you boot if you use no renaming?

I don't, I only know that they will be called eth0 and eth1.  With
unrecognisable names, I don't know anything.

> I really don't see your objection to a setting that, while a default, is
> trivial to change, even before you boot the installed distro for the
> first time. It is clearly useful to others, otherwise they would not have
> invested time and effort in implementing. If, in doing so, they had ruled
> out all alternatives, you would have a point. Those alternative are still
> there, so all you are doing is whining.

That's the usual method of calling something "whining" when someone has
run out of arguments and/or doesn't understand what someone else is
saying.

> No one has taken away your choice to do things how you see fit, why do
> you want to do the same for others.
>
> The choices are there, why not just use the one you want and leave others
> to use what they want.

Where did I say that anyone must use particular names for their network
interfaces?

It's the other way round in that the unrecognisable names have been
forced upon everyone because they were made the default.  You can either
use them or change them, and both requires additional work.  Why wasn't
the extra work forced upon those who want to use the unrecognisable
names?

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[lee]

Alan McKinnon  writes:

> On 24/12/2016 03:52, lee wrote:
>> Neil Bothwick  writes:
>> 
>>> On Thu, 22 Dec 2016 04:15:50 +0100, lee wrote:
>>>
> There are no config files to edit with the predictable names, the
> names are created from the physical location of the port.  That's why
> they are called predictable,  

 I only know what the names are when I can look them up when the computer
 is running.  I don't call that "predictable".
>>>
>>> If they are constructed according to specific rules, they are
>>> predictable, by definition.
>> 
>> You're overlooking that you need to know exactly, in advance, what the
>> rules are applied to, and all the rules, for having a chance that your
>> prediction turns out to be correct.  Provided you know all that, you can
>> predict the universe, assuming that everything always goes according to
>> rules.  You can not prove that it does and only disprove that it does
>> when you find a case in which it doesn't.  So what's your definition and
>> your predictions worth?
>
> You keep mis-defining what "predictable" means in this context. It does
> not mean, in the style of Newton, that you will always know everything
> about it. Neither is it the same meaning as prediction in the context of
> a scientific theory.
>
> "prediction" here simply means that the interface name is guaranteed to
> be the same as it was on last boot, and the somewhat random nature of
> kernael names (ethX, wlanX) is not in play.
>
> It does NOT mean that you are guaranteed to know exactly what an
> interface will be called before you boot it for the first time.
>
> Rename "predictable names" to "already known names" if it makes you feel
> better. There's nothing wrong with this definition of predictable, as it
> satisfies it's own rules and is consistent within itself. It is not
> complete though but we already know that from Godel.
>
> As long as you keep trying to apply the wrong meaning of predictable to
> this situation, you will keep typing mails like this one I'm replying to
> where you argue about something that is not even there. You also can't
> realistically argue about what "predictable" means because like almost
> all human concepts it is not a singularity, rather it is a spectrum
> where it means what the author says it means.
>
> And the quote for that meaning has already been posted in this thread
> somewhere.

Seriously?

Predicting something means to tell something in advance.  You are trying
to defend a wrong usage of language here.

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[lee]

Dale  writes:

> lee wrote:
>> Dale  writes:
>>
>>> lee wrote:
 Dale  writes:

 I didn't go look at boards I had around here.  I went to a major
 computer supplier, newegg, and looked at what they had.  Go back and
 read again what I did and maybe read it more carefully. 

 Might I also add, it's more than just me that has pointed out that you
 are not correct on this.  It's a few others as well.  You ever stop to
 think that what you observe is not the normal and certainly not the
 default?  If what you claim was even remotely accurate, newegg would
 have had a lot larger number of boards with two ports on it.  Thing is,
 they didn't.  Kai pointed out that the same is true in Europe.  
 Why would I assume that what someone else observes is a default?
 Besides, I don't see what problem you're having with this.


>>> Then why would what you observe also be claimed to be the default?   As
>>> I also pointed out, it's not just what I observe, it's what I and others
>>> have observed as well.  So far, you are the only person claiming that
>>> two ports on a home user board is the default.  I have not seen anyone
>>> else post that you are correct.  Others have posted that you are not
>>> correct tho. 
>>>
>>> The problem is, you claim that having two ports is the default.  It is
>>> not the default.  I've said it, even researched it and explained how I
>>> researched it, others have also posted the same point.  Just because you
>>> have boards with two ports does not mean it is a default.  Given the
>>> research I did, it isn't even close.  Boards with two ports for a home
>>> user is not only not the default, it's somewhat rare.  Out of the top 72
>>> boards I checked, only a couple or so had two ports.  That is far from
>>> being the default.  That is quite rare.  Even if it was 5 boards, that
>>> would be under 10%.  That is hardly something to call a default.  If it
>>> were say 50%, then one could at least argue that the default is moving
>>> to having two ports.  It's just not the case. 
>>>
>>> The sooner you figure that out the better for you. 
>> And eating rice is the default because so many people do it ...
>>
>> .
>>
>
> You can claim that having two ports is the default but that isn't
> supported by a single fact.  As I said, the only person who thinks it is
> a default is you.  The default would be set by the manufacturers.  Since
> what is manufactured has to be sold, one good way to find out what the
> default is, go look at what is being sold.  When you see something that
> is common, like say four USB ports, then that is the default.  Another
> example, if most all boards have five PCI-e slots, then that is the
> default.  If you want six slots, seven slots or more, then you are
> likely going to pay extra and have fewer buying options because that is
> not the default. 
>
> Using your logic, no one eats rice since so much of it is grown and
> sold.  If rice was not grown and not sold, then your logic would work. 
> So, your post doesn't even make sense.  The manufacturers of boards by a
> large margin puts one ethernet port on a home use board and even most
> office computers only need one port.  If one goes and looks at what is
> being manufactured and sold, they would be able to see that.  Of course,
> some people can't see it even when several people post the facts.  It
> seems some will never get the idea. 

Rice is not eaten much around here, so it's not the default type of
food.

Besides, people buy what is being manufactured.  If all boards were
manufactured with 4 ports, it wouldn't stop ppl from buying them, and if
no rice was grown, it wouldn't stop ppl from eating (if sufficient
quantities of other types of food were available).

Re: [gentoo-user] Re: from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[lee]

Martin Vaeth  writes:

> lee  wrote:
>>
>> So the names will not change when rebooting and are to be expected to
>> possibly change at any time.
>
> /at any time/when you open the computer and mess around with the hardware/

That's not what is said the quote.

> Your whining in many postings becomes meanwhile unbearable.

Ah, again the usual method of bringing up "whining" when someone runs
out of arguments and/or doesn't understand.

> Just face the facts:
> Unless somebody comes up with an ingenious new idea there are
> essentially only 3 possibilities:

I have brought up another idea which you have chosen to ignore.

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Rich Freeman]

On Fri, Dec 23, 2016 at 8:52 PM, lee  wrote:
>
> I didn't see portage or anything else give me any instructions or
> warnings about this.  The names just suddenly changed, and that screwed
> things up.
>

https://www.gentoo.org/support/news-items/2013-03-29-udev-upgrade.html

This shows up in eselect news list (and so on), and portage will tell
you when you have unread news items.  Note that it only shows up if
you have 

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Tom H]

On Fri, Dec 23, 2016 at 3:39 AM, Neil Bothwick  wrote:
> On Fri, 23 Dec 2016 02:26:05 -0500, Tom H wrote:
>>>
>>> I don't use grub on UEFI systems, but I use the systemd bootloader,
>>> so I thought I'd keep quiet about that ;-)
>>
>> I'm also a heretic who uses the systemd bootloader no matter what pid1
>> is in charge.
>>
>> It's the best thing that the systemd developers have produced!
>
> Except they didn't produce it. They assimilated gummiboot, which I was
> already using, into the systemd collective!

Wasn't Kay Sievers one of the two gummiboot developers? (Along with
Harald  of dracut fame.)

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Tom H]

On Fri, Dec 23, 2016 at 9:07 PM, lee  wrote:
> Tom H  writes:
>> On Mon, Dec 19, 2016 at 3:07 PM, Daniel Frey  wrote:
>>>
>>> It is even more frustrating that these so-called predictable network
>>> names actually can change on a reboot, it's happened to me more than
>>> once when multiple network cards are detected in a different order.
>>
>>>From Kay Sievers in [1]:
>>
>> 
>> Btw, predictable means it will not change between reboots, that names
>> will not depend on enumeration order within the same setup. It does
>> not mean or promise, that added kernel/driver/firmware features will
>> not result in different names. That is expected behavior.
>> 
>>
>> [1] 
>> https://lists.freedesktop.org/archives/systemd-devel/2015-October/034614.html
>
> So the names will not change when rebooting and are to be expected to
> possibly change at any time.
>
> How is that more reliable?

It's more reliable than using the kernel's names because the names
won't change UNLESS there's kernel/driver/firmware change for that
NIC. I doubt that these changes occur that often. Perhaps someone else
knows.

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Tom H]

On Fri, Dec 23, 2016 at 8:57 PM, lee  wrote:
> Tom H  writes:


>> [1] There's no need to learn/use the udev rules syntax. I use the
>> following in "/etc/systemd/network/" on a Debian 8 system with
>> sysvinit-as-pid1:
>>
>> [Match]
>> MACAddress=can't_be_bothered_to_look_it_up
>> [Link]
>> Name=en0
>
> Thanks!

You're welcome.


> What happens when you replace the card with another one that has a
> different MAC? Shouldn't an assignment like this rather go by the
> unrecognisable name? I'd find that more consistent.

AFAIK, you have three possibilities.

1) If you're renaming a NIC via its MAC address, you have to edit the
config file thatlinks the NIC's names and its MAC address.

2) If you're using udev's predictable names, the NIC'll have the same
(more or less complex) name if you use the same slot.

3) If you're using the kernel names, you have no guarantee that ethX
will be assigned to the same NIC at every bot.

Re: [gentoo-user] Re: from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Neil Bothwick]

On Sat, 24 Dec 2016 06:57:39 + (UTC), Martin Vaeth wrote:

> Your whining in many postings becomes meanwhile unbearable.
> Just face the facts:
> Unless somebody comes up with an ingenious new idea there are
> essentially only 3 possibilities:
> 
> 1. One gives names in order of detection.
> 
> 2. One binds the name to the card.
> 
> 3. One binds the name to general attributes
> (e.g. card type, slot type, ...)
> 
> 4. One binds the name to the slot.

While your argument is well reasoned and convincing, your arithmetic is
somewhat suspect ;-)


-- 
Neil Bothwick

I am in total control, but don't tell my wife.


pgpQv9g26imd9.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Neil Bothwick]

On Sat, 24 Dec 2016 02:52:54 +0100, lee wrote:

> >> I only know what the names are when I can look them up when the
> >> computer is running.  I don't call that "predictable".  

That's because you are using a different definition of predictable from
that intended.

> >
> > If they are constructed according to specific rules, they are
> > predictable, by definition.  
> 
> You're overlooking that you need to know exactly, in advance, what the
> rules are applied to, and all the rules, for having a chance that your
> prediction turns out to be correct.

So how do you write udev rules to rename ports without knowing the
specifics of the hardware?

How do you know which port will be eth0 and which will be eth1 the first
time you boot if you use no renaming?

I really don't see your objection to a setting that, while a default, is
trivial to change, even before you boot the installed distro for the
first time. It is clearly useful to others, otherwise they would not have
invested time and effort in implementing. If, in doing so, they had ruled
out all alternatives, you would have a point. Those alternative are still
there, so all you are doing is whining.

No one has taken away your choice to do things how you see fit, why do
you want to do the same for others.

The choices are there, why not just use the one you want and leave others
to use what they want.


-- 
Neil Bothwick

I stayed up all night playing poker with tarot cards. I got a full
house and four people died.


pgpqpmnyPFtPo.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Alan McKinnon]

On 24/12/2016 03:52, lee wrote:
> Neil Bothwick  writes:
> 
>> On Thu, 22 Dec 2016 04:15:50 +0100, lee wrote:
>>
 There are no config files to edit with the predictable names, the
 names are created from the physical location of the port.  That's why
 they are called predictable,  
>>>
>>> I only know what the names are when I can look them up when the computer
>>> is running.  I don't call that "predictable".
>>
>> If they are constructed according to specific rules, they are
>> predictable, by definition.
> 
> You're overlooking that you need to know exactly, in advance, what the
> rules are applied to, and all the rules, for having a chance that your
> prediction turns out to be correct.  Provided you know all that, you can
> predict the universe, assuming that everything always goes according to
> rules.  You can not prove that it does and only disprove that it does
> when you find a case in which it doesn't.  So what's your definition and
> your predictions worth?

You keep mis-defining what "predictable" means in this context. It does
not mean, in the style of Newton, that you will always know everything
about it. Neither is it the same meaning as prediction in the context of
a scientific theory.

"prediction" here simply means that the interface name is guaranteed to
be the same as it was on last boot, and the somewhat random nature of
kernael names (ethX, wlanX) is not in play.

It does NOT mean that you are guaranteed to know exactly what an
interface will be called before you boot it for the first time.

Rename "predictable names" to "already known names" if it makes you feel
better. There's nothing wrong with this definition of predictable, as it
satisfies it's own rules and is consistent within itself. It is not
complete though but we already know that from Godel.

As long as you keep trying to apply the wrong meaning of predictable to
this situation, you will keep typing mails like this one I'm replying to
where you argue about something that is not even there. You also can't
realistically argue about what "predictable" means because like almost
all human concepts it is not a singularity, rather it is a spectrum
where it means what the author says it means.

And the quote for that meaning has already been posted in this thread
somewhere.





> 
>>> They were much more predictable before because I could be reasonably
>>> sure that each of the ports would be called 'ethN', starting with N = 0,
>> "Reasonably sure" is not predictable.
> 
> It's still better than something entirely unpredictable.
> 
> Show me that the names are predictable by writing them down, then
> grabbing an arbitrary computer and plugging in a network card the
> port(s) of which will then have the names you wrote down.
> 
>> A lot of this stuff is designed to
>> make automated management easier, so editing rules or config files is
>> undesirable. It is more about being able to automatically provision and
>> configure new systems, whether hardware or virtual.
> 
> How does it help with that?  Wouldn't it help even more if you could
> just give them the names you wanted them to have?
> 
> Like if you have N machines with an interface each you want to do
> something with, the only thing you'd have to do is make sure that this
> interface gets the right name assigned.
> 
> With unrecognisable names, the interface can still have a different name
> on each machine.  What's the advantage of that?
> 
>>> unless I changed a card for a different one after an udev rule had
>>> already been created.
>>
>> and being able to make changes without messing with the rest of your
>> system. I stand by my previous analogy of disk devices nodes vs UUIDs.
> 
> Are they predictable?
> 
>> One is readable the other is safe. Yes, you can use filesystem labels,
>> which can be both, but that requires intervention, just like your udev
>> rules. That doesn't make either approach wrong, just suited to different
>> purposes.
> 
> And I would find it much better if network ports had recognisable names
> without intervention.
> 
 unless you move the NIC to a different PCI slot, it will always have
 the same name, no matter what other hardware you add or remove. Yes,
 the names are cumbersome, but they have to be like that to guarantee
 their uniqueness.  
>>>
>>> You don't need to defend the unrecognisable names.  The names used for
>>> referring to network ports don't need to be like that.
>>
>> No they don't. It is merely one solution to the problem, and the names
>> are recognisable, Alan posted the key earlier. They are complex and may
>> look cryptic until you understand them, but so is English.
> 
> They don't become any more recognisable by knowing the rules.  They
> simply remain a combination of letters and numbers which is difficult to
> recognise.
> 
>>> The perceived advantage lies in being able to refer to network ports in
>>> a more reliable way, and I don't see how using unrecognisable names