[sle-beta] Network missing pieces

[Joe Doupnik]

On 06/11/2017 13:39, Richard Brown wrote:
> On Mon, 2017-11-06 at 11:48 +0000, Joe Doupnik wrote:
>>      Without meaning to start a long discussion, I have the distinct feeling here that we have another classical "could versus should" situation.
>>      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).
>>      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].

     That is a fair question, to which most of us would say if actual 
(vs just someone's perception) usefulness has nearly vanished while a 
better replacement is on offer then please do move us along, provided 
the consequences are manageable.
     Again, the people and their applications parts of this equation are 
of high importance. Thus taking ifconfig as a handy example, removing 
its real code can/ought to result in a replacement which still fits 
people and systems, and that could be as simple as a shell alias. What 
we have gracefully left behind is supporting IP over carrier pigeons, 
token ring, and some other transports.
     Exceptions to the rule dept. Clearly, Linux is not so simple as to 
have one utility fit every possible situation. We understand that. Where 
consideration is needed is evaluating the consequences of abandonment 
for the sake of a special case or a few narrow cases, versus keeping 
what exists and creating a tool to handle special cases. This evaluation 
is not purely about machinery. Yes, I am well aware of role playing 
here, where a Linux vendor might be drawn into rewriting some material 
just to keep it going (which they might do so if it serves a good 
business case, such as retaining customers).
     It seems to me, thus just my perception, many authors while meaning 
well do get caught up in technique, stop short of completing solutions, 
and tend to forget larger consequences. We see this a lot, particularly 
with small projects. Whether or not a tool uses the latest in say 
processor features or similar is of much less importance than the tool 
itself continuing to work. Clearly, the reason is people and things 
created by/for them know and use the tool over the long term. As all of 
us appreciate, version/feature chasing is not friendly for production 
level work, yet it might cope with some newly arising important cases. 
Example: chasing versions of openssl to fend off the bad guys, but often 
encountering objections from some applications about mismatches (thus 
nearly rock & a hard place for awhile).
     Poking about here for the "net-tools-depreciated" item. I don't see 
it in in SLE-15. So I dug deeper, enabled just about everything 
non-debug, no show. Next I followed that with enabling all search 
sources in YaST, and only then did it appear. I installed it, and 
ifconfig/netstat/et al now function. Whew! The point is they seem to 
work; the gibberish alternatives remain in the unnecessary gibberish 
category at this time. A bridge over troubled waters (unquote) has been 
provided.
     Thanks,
     Joe D.

> "could" we install a package, by default, on all of our customers machines, which are intended to be supported
> for 10+ years, when the upstream of said package has been abandoned for over 8 years?
> Especially when the old tooling doesn't use many modern kernel features, many of which are required for fully
> supported SLE features like infiniband?
> And when the new tooling is both actively maintained and has been the designated successor for net-tools for 7
> years, and developed for over 10.
>
> Sure, we "could", but the question then becomes "should" we?
>
> And I think it's the height of reasonableness to not inject a poster child example of legacy software on every
> SLE-15 machine by default.
> Like I said, it is still around as 'net-tools-deprecated' for those users who have no other choice, but a
> major new SLE version is exactly when we "could" and "should" make the necessary changes to distance ourselves
> from long abandoned tooling that no longer interacts with key components, like the kernel, in the correct way.
>
>