Matt Rice wrote: > > In 103.1, . and source would make more sense in 105.2. > > I think that it would better in 105.1 (ie. for sourcing bashrcs and > login/logouts). And revisited in 105.2 (or left as an 'aha' moment). > > Opinions? I've moved it to 105.1 until I hear otherwise from people.
OK … > Yes, it's useful. Why have a shell process kicking around when you > really want something else to take over. It is useful and takes about one minute to explain (two with a demonstration). Let's keep it in. > Personally, I use(d) pr. Although, I'm more likely to use enscript > nowadays but I don't think that we should cover that. I'm okay with > dropping it if we can get a 'second' from someone on this nomination. I usually spend some time (a few minutes) on pr(1), not because it is a tool I think everybody should use all the time, but because it is a good illustration for the sort of thing one can accomplish with pipelines. It does come in handy every so often, though. > Also, personally, I use expand on other people's source code quite > often. Mixed spaces/tabs are really annoying when people don't use > the right tabstops. ;) Seconded. > And fmt is pretty handy when you want to make your paragraphs look > nice. I use fmt in vi all the time I should probably make a map for > it. Seconded. > > The title for topic 102, "Linux Installation and Package > > Management", is not accurate. Linux installation is not dealt > > with. > > Isn't 102.1 (designing hard disk layouts) and 102.2 (installing a boot > manager) part of doing a Linux install? > > Arguable, so is managing shared libraries when you're installing > (additional) software. We haven't covered Linux installation in the strict sense in our classes for a very long time, because (a) how to do it is distribution-specific, and (b) it isn't exactly rocket science – if you pop in the CD (or USB stick) and keep hitting RETURN you will usually end up with a reasonable Linux system. I agree that hard disk layout is something worth covering, simply because it is easy for people to shoot themselves in the foot. I don't know who still does detailed boot manager configuration these days (other than people compiling their own kernels, which would suggest that the topic might eventually move to LPIC-2). > [Shared libraries] > I'd vote 'yes' to keeping it. IMO, it's essential knowledge. And > dropping it to move it to 201 would mean a 4 year window (our next > major update to LPIC-2) where it isn't covered at all. > > What about the use case where someone wants to download something new > and try it out in their user account? Especially, something that > hasn't been packaged for them. Yes, because it takes all of a five-line C program to demonstrate most of what there is to demonstrate about static vs. shared libraries. If people can't sort-of grok a five-line C program if it is explained to them, even if they haven't seen C before, they have no business doing LPI exams. It's not as if we're asking them to write configure.in files. > [bash vs. zsh] > Agreed. At least for command line use. I still use bash for > scripting, though. Least common denominator and all. Actually, I > just switched from #!/bin/sh to #!/bin/bash a year or two ago for all > script writing. I've had it with having to remember when I started using > bashisms in my scripts. We explain /bin/bash vs. /bin/sh and the caveats involved. We mention the existence of other shells but don't go into detail. > I think that most people would argue for less X in general for the > exam. I have a soft spot for it, though. Porting X11R5, Motif and > CDE to a new platform was my second job out of university (a long time > ago ;)). X11 used to be a huge problem back when one would have to figure out one's monitor timings in order not to fry one's display. In previous reviews of the exam, the level of X knowledge required has been downgraded again and again, and as far as I am concerned that trend should continue. For example, I'd kick out all the display manager configuration details in favour of more high-level knowledge (i.e., what is Wayland and why is it interesting?). > > In 107.1, vipw is dearly missing... > > I believe that vipw (and vigr) were in the objectives but dropped a > few years ago to keep vi from creeping into the 102 exam. Although, > the EDITOR environment variable will fix that problem for the > vi-challenged. > > Isn't this where usermod/groupmod come in, though? Imagine you're rearranging the /home layout for your 200-user file server. Personally I'd prefer using »:s///« in vipw to 200 calls to usermod (even in a shell loop). The latter is still an improvement if you'd otherwise have to use a GUI, but even so … (vipw/vigr have been part of our training materials from the very beginning.) > We're getting into distro specifics here (albeit, prevalent ones). > I'm not against adding them at an "awareness" level but I don't think > that we need to cover the innards. > > Opinions anyone? In our training materials we go over the network configuration files for the most important Linux distributions. I'm not sure detailed knowledge of their content belongs in the exam, though. > [inetd/xinetd] > How about we wait until the next update. By then systemd will have > subsumed everything and we can decide on whether it should replace the > (x)inetd coverage? :-D Agreed. Anselm -- Anselm Lingnau ... Linup Front GmbH ... Linux-, Open-Source- & Netz-Schulungen [email protected], +49(0)6151-9067-103, Fax -299, www.linupfront.de Linup Front GmbH, Postfach 100121, 64201 Darmstadt, Germany Sitz: Weiterstadt (AG Darmstadt, HRB7705), Geschäftsführer: Oliver Michel _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
