On Sat, 11 Nov 2017 at 11:29:48 -0500 Bryan Smith <[email protected]> wrote:
[...] > To "de-program" people from old, but no longer useful, solutions they > knew or have heard of, or may even find in a Google search.** That's the point: ifup/down are old yet still useful. They're the only tools I know of that allow you to bring up/down an interface *and* get/release a DHCP lease *and* start/kill wpa_supplicant and still other things in a two-words, <10 characters command line. ip only takes care of the IP assignement and of the link status. [...] > Does LPI cover everything that ships? Everything that ships *and* is useful. > What if there are 2-3 options in a single distro's install, even a > minimal install? > Cover all of them? > Or just one? > What if one has deprecated another? > Replaced another? LPI covers what a majority of competent stakeholders agreed is useful and available enought it deserves or needs to be covered. > This is the greatest difficulty LPI faces when it comes to objectives. > I, for one, am glad I'm not in the position of deciding this. No single person decides, it's a decision that arises after the stakeholders debated the matter and a rought consensus emerged. > It's always easy to argue someone uses something, even legacy. LPI always carried legacy technology in its objectives, for the same reason distributions regularly carry legacy packages in their repositories: they are old, yet useful and used enought to warrant that. [...[ > But when that starts sprawling into dozens upon dozens of commands and > files and other support for a single objective? And some won't even > be available as they are deprecated ... today, even 5 years ago? That's technology, baby! :-) Remeber how long LiLO was around after basically nobody was using it? > Inertia is difficult to fight. But it's very human and very Unix-like: "If it isn't broken, don't fix it", "If it still runs OK it doesn't need the latest release". > But that also begs the question ... > should LPI objectives cover what was used, and some still use ... or > what is being recommended by Upstream to replace things? Or both? If the old kludge is still used in production, is still available in the repos and there is consensus it still needs to be present, it stays. If the newfangled technology is still not widley used, few distros carry it and lack consensus about their prompt adoption by LPI, they wait next turn. >Ingo Wichmann <[email protected]> wrote: >> Here is the difference to net-tools: net-tools has shortcomings and is >> no longer used in any relevant distribution during startup. So let's get >> rid of it. > > That's one of the reasons why the ifup/ifdown scripts were segmented > from the net-tools package years ago, as it was originally included > with it in many distributions. And do you know why that was done? Because there was a demand for those commands to survive the imminent demise of net-tools, because they are useful and needed. > But even as it's been hacked to > support "ip" and other developments, it still doesn't support a lot. They support ip and what ip supports, among the other things. > A good 5 years ago, even though Red Hat still shipped many things in > the legacy 'initscripts' package, and updated it to use various > subsystems. But it finally reached the point that Red Hat was hacking > in all sorts of support, and it's still a 'static' script that doesn't > handle most solutions. Like what? It seems to me they do support most solutions, > So it finally decided to remove it from the > minimal and even base installs. > And 3.5 years ago, RHEL7 was released > with the same removal of them as Fedora in both the minimal and even > base installs. Are you sure? I do find them in a normal Fedora 26 install. > And that's Red Hat, who has hacked up ifup/ifdown in initscripts, like > a lot of other things, to be as backward compatible as possible ... > far more than Debian. Red Hat deprecates and removes things when they > know things break other things. What do ifup/down break? [...] > Debian has ifupdown2 trying to address various issues with ifupdown. > And even that has shortcomings. Everything has shortcomings, old stuff because it couldn't keep up with the latest technology, the latest technology because it still needs to mature. That's the reason both LPI and major distributions cover them both when the afore-mentioned circumnstances are met. > My only concern -- and I'm not even thinking for LPI here -- is that > we -- collectively, as peers, as advocates, as trainers -- are setting > up new sysadmins up for failure. Failure also includes missing useful tools, for all they're old. I mean, cars still run on wheels, that were invented... how long time ago? > > That's the oldest generation of supported linux distros today. > > LPI had this same discussion regarding ReiserFS with SLES. ReiserFS > "support" (technically) is still in SLES 12 no less. But the > questions is always how well "maintained" it is, the userspace fsck as > much as the kernel implementation. And if you call SuSE AG for > support, will they? Since they ship it, they ought to. >> SLES 11 and CentOS both used ip instead of net-tools for startup. > > Which CentOS? 5? 6? 7? Oh wait, it doesn't matter, even gone > CentOS 5 used "ip". ;) > >> So there is no point in keeping net-tools. But one more reason to keep >> ifupdown for another 5 years. > > So ... does LPI adopt this for everything? Everything that is widely available and used and that a consensus determined they are still to be kept where they are now, with the right weight. Alessandro _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
