[sle-beta] Network missing pieces
jrd at netlab1.net
Mon Nov 6 08:13:18 MST 2017
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
> "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.
More information about the sle-beta