<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Forwarding a copy to the beta list:<br>
<div class="moz-forward-container"><br>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix"> Without meaning to start a long
discussion, I have the distinct feeling here that we have
another classical "could versus should" situation. <br>
In my view, the customer/end-user/human experience has high
precedence about many matters of this kind. Thus classical tools
ought to remain until there are clearly superior versions
together marked need for those superior versions. If no such
need then the classical ought to remain intact because the goal
is to provide the end user with easy to use and remember
controls, rather than play with the toys just because one could.
There is also the unnecessary complexity part of things where
replacement commands for standard straight forward operations
require obtuse replacements and extra bits. Example: to open the
house front door please hold the key upright in the mail slot
while pointing one's left hand at the door's top hinge, which
demonstrates our new nifty electro-optical lock mechanism (void
during hurricane season).<br>
The aspects of need and complexity become evident when
dealing with more than one particular edition of Linux and with
our sundry scripts and helpful programs which depend upon such
features. Consider these aspects under stressful conditions
involving many sundry Linux machines and there is some kind of
trouble which must be fixed immediately by a duty manager.
Consider what new customers would expect to be available [cf.
the Windows 10 start menu fiasco].<br>
lspci. Gosh, I wonder how many people would think of that
when dealing with a regular Ethernet adapter, even assuming the
adapter were PCI based. Actually it does not help us, as readers
can verify for themselves. Obscure ("whimsical") naming does no
good either. ethN (N = 0, 1..) is at least regular,
predictable, some might say sensible and human oriented.
Contrast that with "ens32" which can be followed next by say
"ens34" (what happened to 33 or 31? Did I make an error
somewhere?) which seem to have no obvious relationship to the
observable world. The adapter name can be rectified manually,
say via YaST or much more obscure tricks, but then arguably the
regular system could/should have done that in the first place.<br>
The freedesktop.org article (aka systemd again) is useful to
read, so thanks for its reference in this discussion. In a
nutshell or two it says they don't know what to do about an
ideal AI solution (they haven't second guessed the kernel first
guesser), so instead of solving that at the post boot level
awkward special user commands are needed to restore rationality
for even 90+% of situations. Think: a deer in headlights. Two
quotations from the article:
<blockquote type="cite">Does this have any drawbacks? Yes, it
does. Previously it was practically guaranteed that hosts
equipped with a single ethernet card only had a single "eth0"
interface. With this new scheme in place, an administrator now
has to check first what the local interface name is before he
can invoke commands on it where previously he had a good
chance that "eth0" was the right name.</blockquote>
<blockquote type="cite">That's documented in detail in a comment
block <a
href="https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20"
moz-do-not-send="true">the sources of the net_id built-in</a>.
Please refer to this in case you are wondering how to decode
the new interface names. <br>
</blockquote>
Container projects seem to be inventing their own problems,
and one hopes that over time those awkwardnesses would filter
down into supporting kernel changes. An analogy is asking how
many children's swings and houses a normal tree could support
without requiring a new species.<br>
Thus far in the discussed material I perceive neither
superiority nor marked need, but I do see added complexity and
obscurity. I think the primary goal of usability by regular
people is being lost in technical noise. Retaining tried and
true tools while improving their underpinnings can be a
satisfying achievement and be widely accepted.<br>
Thanks,<br>
Joe D.<br>
<br>
On 05/11/2017 20:47, Richard Brown wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f8b1238d90ea8e4e3bf4265bdc1f10ea@suse.de">On
2017-11-05 16:26, Joe Doupnik wrote: <br>
<blockquote type="cite"> Perhaps this has been discussed
previously and I missed it, but I <br>
found two major network components are missing: commands to
support <br>
ifconfig and netstat. I have utilities which depend upon them,
plus <br>
humans and their habits. <br>
</blockquote>
<br>
Hi Joe! <br>
<br>
Those tools (along with arp and route) have long been deprecated
and should be substituted with their modern equivalents from the
iproute2 package <br>
<br>
* arp -> ip [-r] neigh <br>
* ifconfig -> ip a <br>
* netstat -> ss [-r] <br>
* route -> ip r <br>
<br>
If you really, really, really want to continue to use the old
unsupported tools I think SLE 15 has the 'net-tools-deprecated'
package which will install them, but the package description
gives the same recommendation as above. <br>
<br>
<blockquote type="cite"> Further, we seem to be repeating the
mistake of naming Ethernet <br>
interfaces in weird style, a matter which we thrashed out in
SLES 12 <br>
some time ago. That means I expect to see eth0, eth1, rather
than <br>
whimsical creations. <br>
</blockquote>
<br>
The new interface naming is not 'whimsical' but solves real
problems. I for one quite like the fact that I now have stable
device naming regardless of tinkering with VM configurations,
adding/removing cards on real hardware, etc etc <br>
<br>
A simple 'lspci' is all I need now to predictively create
configuration required for a card, whereas with the previous
model I could never be 100% certain my scripted 'eth0'
configurations would land on the CORRECT card on the system. <br>
<br>
It's compatibility with a read-only root filesystem is also a
boon for the work we're doing with CaaSP and Kubic. I'm quite
sick of the bugs I have in Kubic right now because we haven't
yet implemented this there as effectively as you see in the
SLE-15 beta. <br>
<br>
There's a lot more information about this on the Freedesktop.org
site: <br>
<br>
<br>
<a class="moz-txt-link-freetext"
href="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/"
moz-do-not-send="true">https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/</a>
<br>
<br>
Hope this helps, <br>
</blockquote>
<br>
</div>
</body>
</html>