Let's use vi and apache as examples of a growing trend, and thereby highlight what I think is the actual issue.
Back when LPIC was being formed and the first round of exams were being weighted, we tended to have one and only one real tool for any given task. Vi and apache reigned supreme in their areas and had no competition - true we had pico, joe and geronimo but those tools never really went anywhere. If a sysadmin couldn't weild vi and apache they were mostly dead in the water. Now editors are important, sysadmins must be able to change text files to suit their needs. The skill is changing the file and knowing what must be in it, the tool doesn't have to be vi - these days, it very frequently isn't and is absent. Same with web servers. I have not deployed apache for some years now, my http server of choice is nginx as I do not need the full feature set apache provides. And additionally, nginx is usually a reverse proxy and flask is the actual backend. So there is two examples where concentration on the specifics of a single tool can overshadow the actual important task. I say this knowing full well that we cannot test abstract knowledge or knowledge of results, we can only really test practical and real-world examples. But we also should keep in mind that the landscape we work in is changing, and changing rapidly. We now have containers which are about as different from classic servers as one can get and still have Linux under the hood. Very different skill sets, very different testing methods required. Let me also just point out that LPI has dealt with this type of problem at least once before - there was a time when sendmail reigned supreme. Then along came postfix, exim and qmail and sendmail's relevance as the primary MTA fell away and we have to deal with it in our exams. I believe we are again at a similar point and a great many sacred cows are creeping closer to the butcher's knife. vi is but a single example of that, albeit the one most people will see first. Alan On Tue, Aug 6, 2019 at 4:46 PM Bryan J Smith <[email protected]> wrote: > On Tue, Aug 6, 2019 at 10:27 AM G. Matthew Rice <[email protected]> wrote: > >> Well, I'm glad you guys all learn everything in 10 minute sprints. I >> still take half an hour to make a 3 minute egg. >> > > I would argue that while these things can be learned in 10 minutes, > 'muscle memory' and 'from experience' takes at least 3 hours ... likely > spread over 3 days.** > > You keep saying 'automation track'. Maybe we could expand the DevOps cert >> into a full and separate track (or diverging) and include some of LPIC-1 >> (and LPIC-2)? >> > > So, again, I want to preface that with ... > > 1) bjs was just saying the 'get away from bjs-like old fart stuff' or > 'weighing it far less heavily than old-fart bjs wants' means ... > > 2) there *may* -- I stress *may* -- be merit to look at the 'future > purpose' of LPIC-1 (and even LPIC-2) overall > > Right now another certification entity (*cough*Red Hat*cough*) has been in > this cycle of changing things around, and it's now very different than it > was just 5 years ago. One can get a RHCSA or RHCE without even passing a > general RHEL exam, in addition to the specialty exams that don't require a > RHCSA or RHCE as pre-requisite. Most of these changes are the last 3 years. > > So ... is Vi important today? Are sysadmins just 'interactive' and > 'break-fix'? That's a really good question. > > Hence ... this is really for Fabian et al. to look at and possibly seeing > where DevOps may or may not be overlapped with LPIC-1 (or even LPIC-2), if > there shouldn't be more options in the 100 (or even 200) tracks, or if it's > not viable. I was just trying to play my own 'devil's advocate.' > > Because I'm of the viewpoint ... > > A) If LPIC-1 will still be considered (future) 'interactive' and > 'break-fix' support sysadmin, and editing is the common denominator, then > Vi is probably still one of the most important skills for LPIC-1, > especially as a foundation, or ... > > B) If LPIC-1 will not so much be (future) 'interactive' or 'break-fix' > but can encompass a new focus on 'mo'better' and 'newer' stuff, then maybe > we outta look at a new approach > > I'm an old fart and, worse yet, I also have a traditional engineering > degree, so to me, Vi is like calculus ... you cannot do most anything else > in engineering without it, just like a sysadmin that is 'interactive' and > 'break-fix' cannot live without Vi in the Linux world. But at the same > time, there are all sorts roles for sysadmins in the modern world, just > like technologists in the engineering world, who don't need calculus and > mechanics. > > So ... that's really the debate in my eyes. I know many will differ that > we can reduce (even if not eliminate) Vi coverage, to cover other topics, > but I really think it should be a far greater change. I now leave it to > others to discuss. > > - Self-aware, 'old-fart' bjs > > _______________________________________________ > lpi-examdev mailing list > [email protected] > https://list.lpi.org/mailman/listinfo/lpi-examdev -- Alan McKinnon alan dot mckinnon at gmail dot com
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
