Yeah, once things are enumerated, or other labels are made, best not to reorder or change them. Sometimes it's best to leave everything for backward compatibility and educate people that they are not intended to be sequential or changed for such.
-- bjs On Tue, Jul 15, 2014 at 5:34 AM, Marc Baudoin <mbaud...@linagora.com> wrote: > Hi everybody, > > G. Matthew Rice <m...@starnix.com> écrit : > > On Mon, Jun 23, 2014 at 9:38 AM, Anselm Lingnau > > <anselm.lingnau+exam...@linupfront.de> wrote: > > > So far this list has been suspiciously silent, but if you go to the > LPI wiki > > > you will find a page called > http://wiki.lpi.org/wiki/LPIC-1_Objectives_V4 . In > > > > Here is the latest draft of the LPIC-1 objectives: > > > > http://wiki.lpi.org/wiki/LPIC-1_Objectives_V4 > > So I'm going to break the silence. > > Let's talk about 101 first. > > I've already said that a few years ago but the order of the > objectives is not logical. The current 103 topic should be > covered first because the command line is heavily used in topics > 101 and 102. When I said that before, I was told that order was > irrelevant and that it's the trainers role to put things back in > the correct order. So be it, that's already what I do. But what > about people who do self-training? Can they stand back enough to > do this by themselves? Book authors have also to put things back > in the correct order, which makes it difficult to compare book > contents and objectives. Moreover, what's the point in having > objectives in an unlogical order? > > I would suggest to put 103 first and reorder (that implies > renumbering) it that way: > > 103.1 > 103.8 > 103.3 > 103.5 > 103.6 > 103.4 > 103.2 > 103.7 > > Basic shell first. Then vi because file management needs > files... And it's a good idea to deal with vi soon so that > people can use it to take notes. Then file management. Then > processes. Then and only then pipes because ps | grep allows for > great exercises. > > At least vi much sooner that now and 103.4 before 103.2 (pipes > before filters, that makes sense). > > Let's get to the details now. > > In 103.1, . and source would make more sense in 105.2. Is exec > really useful (if it is, I would also suggest to move it to > 105.2)? > > 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. > > In 103.3, xz should be added to the list of compression programs. > > The title for topic 102, "Linux Installation and Package > Management", is not accurate. Linux installation is not dealt > with. > > 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. > > 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 (yes, I'm not a bash fan, zsh rocks!). > > 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. > > In 107.1, vipw is dearly missing... > > In 109.2, configuration files (/etc/network/interfaces, > /etc/sysconfig/network and > /etc/sysconfig/network-scripts/ifcfg-*) should be covered (they > are used by ifup, which is in the objectives). > > 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. > > 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). > > -- > 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 > lpi-examdev@lpi.org > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
