G. Matthew Rice <[email protected]> écrit : > On Tue, Jul 15, 2014 at 5:34 AM, Marc Baudoin <[email protected]> wrote: > > So I'm going to break the silence. > > But on the day that we're supposed to go from draft to released? I'm > gonna get you for this. ;)
Was there a calendar? Sorry about that. Remind me next time we meet so I can apologize with the correct amount of beers ;-) > > I've already said that a few years ago but the order of the > > objectives is not logical. > > Agreed. But I'll let the other responses cover that. I give up on that. > > 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. 105.1 is OK too (at least better than 103.1). > > Is exec > > really useful (if it is, I would also suggest to move it to > > 105.2)? > > Yes, it's useful. Why have a shell process kicking around when you > really want something else to take over. > > Plus, I find using exec to redirect file descriptors very useful. > This isn't the best article/forum post on the matter but it > illustrates my point: > > > http://unix.stackexchange.com/questions/18899/when-would-you-use-an-additional-file-descriptor > > I don't think that we cover this aspect of exec in the LPI exams, though. > > I think that you're right about it being in 105.2, though. Doing an > exec on the command line isn't usually what someone wants. It could be a good joke. > > In 103.2, is the pr command (designed for matrix printers, which > > are seldom used today) really useful? I also doubt expand, fmt, > > join, paste, split and unexpand are heavily used. On the other > > hand, more and less are useful filters, which are not listed > > here. > > hilarious. We've missed less on that list for years. I've added it. Thanks. > Personally, I use(d) pr. Although, I'm more likely to use enscript > nowadays but I don't think that we should cover that. enscript or a2ps. But I agree they're not relevant here. > 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. I use Vim and gqap (which does the same thing but without forking a process). > > In 103.3, xz should be added to the list of compression programs. > > Added. Thanks. > > 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? Of course but 102.1 and 102.2, if I'm not mistaken, focus on the manual part of things. > > I still find it hard to deal with shared libraries with people > > with no knowledge of C programming. Let's face it, most systems > > administrators nowadays know nothing about C and the POSIX API, > > which also makes their understanding of the operating system much > > more superficial. Does the 102.3 subtopic, with only 1 question > > in the exam, needs to be maintained here? It would make much more > > sense in 201. > > 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. So sad people don't use the source code anymore. Everybody is boasting they're doing open source stuff but nobody uses the source anymore. But I see your point. > > Enough for 101, let's move to 102. > > > > In 105.1, /etc/bash.bashrc is missing in the awfully long list of > > bash configuration files > > Added. Thanks. > > In 106.1, should xhost still be covered given its coarse > > security? Basic knowledge of xauth should replace it, knowing > > that ssh -X automatically does everything necessary. > > 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 ;)). Don't tell. That was when people used to compile X (see above). I also remember downloading X11R6 the day it got released and compiling it on a Sun SparcStation. Sigh... > > 109.4 should immediately follow 109.2 and so > > /etc/resolv.conf, /etc/hosts and /etc/nsswitch.conf should not be > > covered in 109.2. > > hosts + nsswitch.conf (hosts: files ...) != DNS Well, it's not but it's pretty close. > > In 110.2, shouldn't inetd and xinetd be removed? I think they > > haven't been used by default on any distribution for quite some > > time now. Standalone daemons are the default now (even if I > > still launch my UW IMAP from inetd, but that's me). > > It's still around and important stuff. Plus, some people use LPIC-1 > (particularly) as a Unix certification. BSD systems still come with inetd by default (I'm a huge user of NetBSD, I can tell for this one) but it's still rarely used because most daemons are standalone. > How about we wait until the next update. By then systemd will have > subsumed everything Or not... http://boycottsystemd.org/ > and we can decide on whether it should replace the (x)inetd > coverage? :-D Why not. > Thanks, Marc. These were great comments. You're welcome. -- Marc Baudoin Linagora formation - responsable pédagogique http://formation.linagora.com/ La présente transmission contient des informations confidentielles appartenant à Linagora, exclusivement destinées au(x) destinataire(s) identifié(s) ci-dessus. Si vous n'en faites pas partie, toute reproduction, distribution ou divulgation de tout ou partie des informations de cette transmission, ou toute action effectuée sur la base de celles-ci vous sont formellement interdites. Si vous avez reçu cette transmission par erreur, nous vous remercions de nous en avertir et de la détruire de votre système d'information. The present transmission contains privileged and confidential information belonging to Linagora, exclusively intended for the recipient(s) thereabove identified. If you are not one of these aforementioned recipients, any reproduction, distribution, disclosure of said information in whole or in part, as well as any action undertaken on the basis of said information are strictly prohibited. If you received the present transmission by mistake, please inform us and destroy it from your messenging and information systems. _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
