LPI board meeting minutes available
The LPI board members have never been all together in one room. Instead, we have regularly been having telephone conference calls (sponsored by Linuxcare). The minutes of the meetings we had since we officially have been incorporated are now available at: http://www.lpi.org/minutes/LPI_board_minutes.html They may be of interest since they usually contain decisions and policies that have been officially accepted by the LPI board; most of these have been discussed on the lists at some time. The content is there but hardly readable. Expect the information to become better accessible in the future; I just didn't want to wait for that. -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom Peters Secretary, LPI Board [EMAIL PROTECTED] This message was sent by the linux-cert mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: LPI Exam Order
On Mon, 24 Jan 2000, Chuck Mead wrote: On Mon, 24 Jan 2000, [EMAIL PROTECTED] said: As you already know, the first level of LPI's Linux certification program includes the following exams: % cut % and the requirements for the Level I certificate are passing both 1a and 1b, and one of the 2x exams. We propose to allow candidates to take the required exams in any order they wish. In other words, completing test 1a will not be required before taking 1b or one of the test 2 exams. Are there any comments on this policy proposal? My preference would be that the T1's be taken prior to T2. The order of the T1's does not matter to me. It has been discussed in November that RHCE can get a waiver for the T2d (LPI Red Hat) exam. A general policy to this effect has been approved by the board on 10 January (see http://www.lpi.org/minutes/minutes_board_2110.txt), so effectively people will have done the equivalent of the T2d test before any LPI test. Note however the final line from the policy: "Unless otherwise provided for by the Board, waivers will only be recorded after a candidate has attempted at least one LPI exam." This has a technical reason, having to do with candidate registration and administration. Since we will be certifying a specific level of expertise, the breakdown into multiple exams is a matter of convenience (or whim). I see no reason to require any order. -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.+31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
going to the next level
Now that the exams for level one are nearing completion, it is time to start working on the higher levels. Soon I'll send some more detailed plans to the [EMAIL PROTECTED] mailing list, so I invite all those who are interested to get a subscription to that list. Topics that need to be discussed are: - what will be the overall content of the higher levels? - how do we structure the content? - how do we get sufficient advice from high-level experts? -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.+31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Accept consensus point X: Recertification
Here's another one. Consensus Point X: Recertification === 1999-09-21 LPI will not require certificate holders to renew or recertify. LPI will provide to third parties, at the certificate holder's request, information pertaining to the history of certifications(s) passed, the date the certification(s) were passed, and the revision date/level(s) of the completed certification(s). In providing this information, LPI reserves the right to indicate the current revision level of any or all of the certification(s) passed by the certificate holder and to issue public advisories concerning changes in the content or objectives of the certification(s). Votes = In favour: -- Jared Buckley [EMAIL PROTECTED] A.R. (Tom) Peters [EMAIL PROTECTED] Chuck Mead [EMAIL PROTECTED] Stephen Holcomb [EMAIL PROTECTED] Forrest Tiffany [EMAIL PROTECTED] Neil Thompson [EMAIL PROTECTED] Kenneth J. Lund [EMAIL PROTECTED] Against: none PASSED 1999-10-04 * -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Accept consensus point IX: Exam Renewal
We never gave an overview of the complete final text of this policy, nor of the various opinions. Here it is; we'll update the webpage (http://www.lpi.org/cps.html) Consensus Point IX: Exam Renewal 1999-09-21,22 LPI will review the contents of its test objectives and exams and revise them as deemed necessary in order to provide for new material, test validity, security, and to incorporate feedback. Test objectives and exams will be reviewed at least once in two years. Votes: == In favour with previous version but comment on last sentence: - Dan York [EMAIL PROTECTED] Neil Thompson [EMAIL PROTECTED] Kenneth J. Lund [EMAIL PROTECTED] Stephen Holcomb [EMAIL PROTECTED] Uli Weis [EMAIL PROTECTED] In favour after final amandment of last sentence: - A.R. (Tom) Peters [EMAIL PROTECTED] Jared Buckley [EMAIL PROTECTED] Chuck Mead [EMAIL PROTECTED] Against: none ACCEPTED 1999-10-04 *** -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Accept consensus point IX: Exam Renewal
We never gave an overview of the complete final text of this policy, nor of the various opinions. Here it is; we'll update the webpage (http://www.lpi.org/cps.html) Consensus Point IX: Exam Renewal 1999-09-21,22 LPI will review the contents of its test objectives and exams and revise them as deemed necessary in order to provide for new material, test validity, security, and to incorporate feedback. Test objectives and exams will be reviewed at least once in two years. Votes: == In favour with previous version but comment on last sentence: - Dan York [EMAIL PROTECTED] Neil Thompson [EMAIL PROTECTED] Kenneth J. Lund [EMAIL PROTECTED] Stephen Holcomb [EMAIL PROTECTED] Uli Weis [EMAIL PROTECTED] In favour after final amandment of last sentence: - A.R. (Tom) Peters [EMAIL PROTECTED] Jared Buckley [EMAIL PROTECTED] Chuck Mead [EMAIL PROTECTED] Against: none ACCEPTED 1999-10-04 *** -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
reminder new program structure
Like I posted last week, we plan to re-order the LPI exams. We will accept them by Thursday, so please send your comments soon. I repeat the new overall structure below; the detailed objectives are still on-line in the current (old) structure under http://www.lpi.org/objectives/ == Proposed exam structure T.P., v.2.11, 19990927 T1a: General Linux I# Objectives: 26Total Weight: 83 T1b: General Linux II # Objectives: 30Total Weight: 105 T2a: Caldera# Objectives: 6 Total Weight: 25 T2b: Debian # Objectives: 7 Total Weight: 28 T2c: TurboLinux # Objectives: 8 Total Weight: 32 T2d: Red Hat# Objectives: 9 Total Weight: 33 T2e: Slackware # Objectives: 5 Total Weight: 24 T2f: SuSE # Objectives: 7 Total Weight: 27 T1a: General Linux I# Objectives: 26Total Weight: 83 3. GNU Unix Commands # objectives: 7 total weight: 26maintainer: Chuck 4. Devices, Linux File Systems, Filesystem Hierarchy Standard # objectives: 8 total weight: 21maintainer: Tom 6. Boot, Initialization, Shutdown, Run Levels # objectives: 2 total weight: 6maintainer: Tom 8. Documentation # objectives: 4 total weight: 9maintainer: Tom 11. Administrative Tasks # objectives: 5 total weight: 21maintainer: Scott T1b: General Linux II # Objectives: 30Total Weight: 104 1. Hardware Architecture # objectives: 3 total weight: 10maintainer: Chuck 2. Linux Installation Package Management # objectives: 4 total weight: 13maintainer: Tom 5. Kernel # objectives: 2 total weight: 7maintainer: Tom 7. Text Editing, Processing, Printing # objectives: 4 total weight: 8maintainer: Tom 9. Shells, Scripting, Programming, Compiling # objectives: 2 total weight: 9maintainer: Tom 10. X # objectives: 4 total weight: 10maintainer: Chuck 12. Networking Fundamentals # objectives: 3 total weight: 18maintainer: Chuck 13. Networking Services # objectives: 5 total weight: 20maintainer: Chuck 14. Security # objectives: 3 total weight: 10maintainer: Chuck T2a: Caldera# Objectives: 6 Total Weight: 25 maintainer: David A. Bandel 81. OS Installation # objectives: 4 total weight: 14 82. Package Software Management # objectives: 1 total weight: 8 84. Administrative Tools # objectives: 1 total weight: 3 T2b: Debian # Objectives: 7 Total Weight: 28 maintainer: Tom Peters 81. OS Installation # objectives: 3 total weight: 13 82. Package Software Management # objectives: 2 total weight: 10 84. Administrative Tools # objectives: 2 total weight: 5 T2c: TurboLinux # Objectives: 8 Total Weight: 32 maintainer: Faber Fedor 81. OS Installation # objectives: 3 total weight: 13 82. Package Software Management # objectives: 2 total weight: 10 83. File Locations # objectives: 1 total weight: 3 84. Administrative Tools # objectives: 2 total weight: 6 T2d: Red Hat# Objectives: 9 Total Weight: 33 maintainer: Chuck Mead 81. OS Installation # objectives: 3 total weight: 13 82. Package Software Management # objectives: 2 total weight: 9 84. Administrative Tools # objectives: 3 total weight: 8 89. Other # objectives: 1 total weight: 3 T2e: Slackware # Objectives: 5 Total Weight: 24 maintainer: Tom Peters 81. OS Installation # objectives: 3 total weight: 13 82. Package Software Management # objectives: 1 total weight: 8 84. Administrative Tools # objectives: 1 total weight: 3 T2f: SuSE # Objectives: 7 Total Weight: 27 maintainer: Faber Fedor 81. OS Installation # objectives: 2 total weight: 8 82. Package Software Management # objectives: 1 total weight: 8 84. Administrative Tools # objectives: 4 total weight: 11 -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom Peters Director Program Development, Linux Professional Institute [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
LPI Glossary renewed
While Alan Mead was on holiday, I have been doing a lot of work on the glossary/jargonacronym list. I entered a very large number of crosslinks, added lemmata and removed some, and edited or added "comments". Now it has become a fairly comprehensive glossary of computer terms. The latest list is (as it has been) on-line at: http://assess.ipat.com/~cert/lpi/lpilist.html The current list mostly reflects my personal preferences, so it could do with a few other pairs of eyes. Everybody who has an interest please check if your favourite acronyms and terms have not been deprecated or that I ruined the comment you submitted. My policy has been to accept acronyms that are in use for official protocols and organisations, but to avoid them for other things that have a normal name, because that would be jargon that may be confusing. Please send any improvements to Alan Mead [EMAIL PROTECTED]. -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: certification database and privacy - DIGEST
On Tue, 24 Aug 1999, A.R. (Tom) Peters wrote: Subject: certification database and privacy I guess those who cared to comment did by now, so here's the score: All stressed that we should not disclose test scores, and most that we should only disclose if someone is certified or not (hiding any failed attempts). All prefer we assign our own unique ID's, although AE and DB like to combine that with a name. Beyond this, there is less consensus, and not all clearly stated their opinions on the questions posed. Q1: Is our full register public anyway, or do the LPICs need to give their consent to inclusion? FF and GK want a flag in our database for LPICs to opt in or out. DB thinks a register that can be accessed without active participation of the LPIC is OK, but then the LPIC should be notified by e-mail. Conclusion: people can choose if their certification status is disclosed or not. Q2a: Can the register be accessed freely, or does the LPIC need to agree (and give his not-guessable ID)? Opinions diverged, but if we use our own unique generated ID's, the LPIC needs to disclose his so he is in control anyway. Q2b: Is the LPICs name input (with the ID), or output? Only GK and BB gave a clear answer, and they disagreed. My conclusion: == Exam candidates get a unique personal ID for public use. They can choose to be in a public register, which can be queried for certification status (no info | L.I+distro | L.II | L.III+specialization) using the ID; also the date that the certification was granted as well as the name of LPIC is returned (so the inquirer can check the ID belongs to the person who used it). Note: Decency and in some jurisdictions the law, require that people know what information is stored about them in the database, and they may demand corrections. So we assign LPICs a public ID for the register, but we may also assign all exam candidates a secret ID (and maybe a password) for access to their full record. As OH and AE pointed out, this is practice for some other certification programs. -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: Linux certification BOF at LinuxWorld
[ personal list mail ] On Wed, 11 Aug 1999, Khawar Nehal wrote: How many types of certifications are there for Linux. Any web page which lists all of them or pointers to their separate types. I thought there was only SAIR. Is there anything official by the community or is it free to develop based on specialities ? Please see http://www.lpi.org/links.html for linux-related certification and training we are aware of; and the rest of our website on what LPI is about. -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: Recertification Requirements Revisited (fwd)
I suppose this was meant to go to this list. -- Forwarded message -- From: Martien Lammers [EMAIL PROTECTED] To: Jared Buckley [EMAIL PROTECTED] Date: Tue, 27 Jul 1999 20:25:13 +0200 Subject: Re: Recertification Requirements Revisited Jared Buckley wrote: Ok, since it seems like conversation on this topic has died down, let's summarize and see if we can begin to move towards a consensus: 1) Do we need recertification? No, as long as the world asks for a certificate of basic knowledge to a defined level. Ofcourse you could develop as many levels as you want or update the levels from time to time. Everything else makes it unserious or just "decertifies" certification to a commercial interest for a few people. First tendencies of this you'll find in the comments to the E-Certification which seems to be free. By the way, who did a recertification of his Master or BSC degree? Martien Lammers This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: Recertification Requirements Revisited
On Mon, 26 Jul 1999, Chuck Mead wrote: On Mon, 26 Jul 1999, Jared Buckley spewed into the bitstream: Ok, since it seems like conversation on this topic has died down, let's summarize and see if we can begin to move towards a consensus: 1) Do we need recertification? Pros: It seems like the general sentiment was that recert was necessary to keep the value of the certificate from going stale and to protect LPI's reputation. I don't think much of this argument. Neither do I. Cons: The potential exists for LPI to become a "paper mill" generating endless recertification requirements as a source of continuing revenue. (cash cow) and this one is so bogus... it may be a legitimate thought but LPI isn't a "cash accruing entity" beyond operational and developmental funding. Yet if we do not have a good reason to require re-certification, that may be what people will be suspecting and I would like to avoid such an image. % cut % o Recert on "major" (-- undefined) revisions or at a fixed time interval, whichever comes first. Revisional recert is the way to go. Example: from RH5.0 thru 5.2 I wouldn't have required a recert but for 6.0 I would and this applies to the issues outlined in the next two points as well. Note that this has to do with renewal of the exam content, which really is a different issue from renewal of the certification. Chuck's comment is only relevant for the distribution-specific part of the second basic exam. We will allways lag behind the vendors, and rather would like to have some control on when we will upgrade instead of leave it to their marketing requirements. Maybe we can establish a policy, like changing to a new exam whenever 20% (or whatever) of the test objectives have changed. Such a policy can be used for the other exams as well. % cut % b) After a major kernel revision release, i.e. 2.x.x to 3.x.x. That is arbitrary: only a small fraction of the exams is influenced by kernel issues. Again, this is about exam renewal which is different from certification renewal. c) Let the Employers/Employees (cert holders) Decide - In other words, date each cert test passed and let potential employers or the cert holder themselves decide if enough time has passed that recertification is required. All of these are really related to the same issue. Vendor releases containing major changes will require a re-cert. They can take it when ever they want, in my view (but I'd expect their employer is gonna dictate!). Don't focus on the T2* exams too much. Nevertheless, we might offer the brief distribution-specific T2* exams separately. Scott, will that be feasible? 3) Do we make recertifying LPIC holders take the newest version of the same test, or do we have special test just for recert'ing at a particular level? No special recert test... they should take the whole thing again! I agree, for 2 reasons: a) Not only do they show they know the new stuff, but they show they didn't forget about the old stuff either. b) It saves us the trouble of establishing and validating a whole range of differential exams, which will probably cost more than it returns (not only financially, but also in terms of resources and quality). -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: additions for review, completionn
On Wed, 7 Jul 1999 [EMAIL PROTECTED] wrote: Ok, I've extracted and pawed through the terms used in the objectives to form a further list of terms which we may wish to add to the list. I haven't yet given them definitions. I would appreciate feedback if any seem inappropriate. % cut % URL: http://conan.ipat.com/~cert/objlist.html Here is my initial analysis: .. These are or may be names of programs or commands, and if they are, do not need to be on these lists, since programs will be part of the objectives when they need to be: chat ? COAS (coas) cut ? die ? LISA (lisa) Lizard (lizard) netscape nice rpm (the program) Samba (samba) SaX (sax) tail tcp_wrapper ? turbodesk .. These I think belong in the list (some additions of my own); this is open for discussion, including which alternative will be preferred: CERT~ Computer Emergency Response Team~ BUGTRAQ ~ ? ~ CSLIP ~ Compressed Serial Line IP ~ Debian ~ DEBorah IAN (Murdock) ~ A GNU/Linux distribution built by a volunteer organisation. DMA ~ Direct Memory Access ~ GNU ~ GNU's Not Unix~ a Free Software Foundation project to build Unix(R)(TM)-compatible utilities and programs exclusively based on free program code. graphical user interface~ GUI ~ N.B.: refer to a "graphical user interface" only if there actually is a graphical interface (like X), and do not use it for interactive programs on terminals (based on ncurses or slang). Use "interactive interface" as a catch-all. I/O ~ Input/Output~ IRQ ~ Interrupt ReQuest ~ kbps~ kilo-bit per second, Kbps, kBps, KBps KB ~ kilobyte, kB, kb KBps~ Kilo-Byte per second, kBps, kbps MB ~ Mega-Byte, megabyte, mb logfile ~ log ~ record of activities MS-Windows NT ~ NT, Windows NT ~ A 32-bit operating system from Microsoft(R) Caldera OpenLinux ~ Caldera, OpenLinux, CSOL~ A commercial Linux distribution PnP ~ Plug and Play ~ RedHat ~ Red Hat, RH ~ A commercial Linux distribution RPM ~ RedHat Package Manager, rpm ~ a package format (cf. "rpm" for the package management program). SUID~ Set user ID, suid ~ a permission bit for files in Unix-compatible file systems SuSE~ S.u.S.E. ~ A commercial Linux distribution TurboLinux ~ Pacific HighTech Linux, PHT ~ A commercial Linux distribution UTC ~ Coordinated Universal Time ~ Official world time virtual console ~ virtual terminal, VT, VC~ X-terminal ~ X-station .. "arp" I think should be capitalized (Address Resolution Protocol). I think it should not be spelled out, because I believe it is the name of a formal protocol (does anybody know the RFC?) .. these keywords are duplicated: "dependency" "media" "postscript" .. Should this actually be in level I? DHCP ICMP Smart? (what is that, where does it come from?) WINS .. These already are in the list: NFS NIC (N.B.: this TLA is deprecated, and should be spelled out!) SCSI -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: NEW dictionary
On Wed, 7 Jul 1999, Alan Susan Mead wrote: % cut % ! This brings up another issue: we should discriminate which concepts and acronyms we are using at what level. For higher levels we will be using names that need not be known at the lower. I propose to add a new section for each level we make, so the current draft should be headed by "Level I". This is a good point. However, I vote no about "higher levels" because (1) who will decide what is level 1 and what is level 2, etc.? WE do. That is, as the L.II test objectives will be developed at the end of this quarter, we will be using new concepts, that should be added to the list. I see no good reason why these should be lumped together with the ones that cover L.I : people maintaining the tests or studying for L.I are not supposed to deal with the advanced stuff there. Of course on the reverse, both writers and students for the higher levels can use all the lists up to that level. (2) the jargon shouldn't be a big difference between levels (wisdom, integration, better familiarity with details, etc.) I am concerned with new concepts that have not been addressed at the lower level. Like the details of the OSI model. I expect the higher-level parts to be smaller. But as I recall, L3 exams are specializations and it would make sense that there will be all kinds of new jargon and acronyms that shoudl have different (expanded) lists. It would be most natural to label the lists by content. This could be the system administration list. There could be a security list, a networking list, etc. One for each L3 exam. That seems OK. I hesitate to do this for the L.I exams: the division between exam 1 and 2 is arbitrary (topics have been shuffled until we got 2 exams of equally-sized content); and I hate to sort it out for the distribution-specific part. OK, maybe a Slackware guru does not necessarily need to know about the existence of .deb packages, but hey, they are not living on an island either. So I suggest to keep one list for all L.I . % cut % At SMB: ... % cut % Yes. point well taken. I expect I have numerous such errors. If I have gotten something wrong, it would be most helpful if you would supply a proper definition/description of a sentence or two. Because if I got it wrong the first time, I think chances are excellent that I will screw it up again. Sorry, I should have proposed an improved definition. -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: NEW dictionary
On Thu, 8 Jul 1999, Forrest Tiffany wrote: "A.R. (Tom) Peters" wrote: Of course we should limit them! If they use it, it is in the exams which means that we require the candidates to know about it. In which case it should be in our list or objectives. Well, I can tell you get the first part of my point. However, I think you are missing the second part. It is quite possible (although I can't think of an example for PHP) that a concept which will not be tested until a later exam will be mentioned in a lower level exam. I will give you an example, however note that I don't think this particular term will be a term that would be a problem, but lets look at SCSI. I don't think the details of SCSI would be necessary to be known at level one, but I might want to say something about the SCSI disk attached to the system. I am not making this argument for any of the obvious terms. I am making it for the terms which are not obvious. If we intend the list to be a study aid, then yes we may want to separate the different terms into categories based on the test level (or some other method). However, as a tool for test creation, I think this would be a counter-productive idea. A list of terms is just that a list of terms. If I am to talk about something I should use the correct term. And this list is the source to determine if the term I used is the correct one. It doesn't matter how advanced I am. I feel that we should make the list to be used as a tool, not a constraint, and putting levels next to terms could become constraining for test developers. I think I get your point, but OTOH: why would item writers bring up advanced topics in their questions that are NOT part of the exam content? It can only confuse things. Maybe we should actively discourage them to do so! -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: Retiring Exams WAS: [Recertification Requirements]
On Thu, 8 Jul 1999 [EMAIL PROTECTED] wrote: I think that the two criteria should be (1) exam security and (2) change in content. I can tell you that the books I bought a year or 18 months ago (which were written six to 18 months previously) are definitely stale. I think Linux is currently changing sufficiently in a year or two to make new exams a good idea. Scott mentioned similar things in the mother thread. So I think it is worthwhile to consider these things separately: 1) Change an exam (partially or in whole) to improve quality and keep secrecy. This is an internal, technical matter: the exam is (should be) fully equivalent to its pre-decessor. Specifically, it does not need to concern examinees, and they do not need to re-certify. These should be "minor-number" upgrades. 2) Change in exam content. This will be because the exam objectives have changed, which will be because Linux has evolved. The old exam is obsoleted, we get a new major number. After "sufficient" changes have accumulated, people may have to re-certify. Now we need to set a policy about how much "sufficient" is. One upgrade is not sufficient, or everybody who took the old exam yesterday will cry out for our blood. And we don't want everybody to wait for the new exam either, because it surely will be behind schedule as usual, and we will go broke because of lack of revenues. The same thing happened to Osborne way back in the stone age. -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: Call for dictionary
On Wed, 30 Jun 1999, Alan Susan Mead wrote: -Original Message- From: A.R. (Tom) Peters [EMAIL PROTECTED] % cut % * The list will not mention terms (acronyms) that don't really have synonyms: for example, you either use "Mail Transfer Agent" or [...] I'm not sure I understand... Are you despairing of any list/dictionary/enumeration? Or what would relate "sendmail, smail, qmail, exim, ..." with MTA? This point I don't understand but I am *completely* open to modification or alternatives. Given the time crunch, as I said, alternative models would be appreciated. My concern was, that things that have no reasonable synonym (like Mail Transfer Agent) would not be included in the list, hence we would need another list for them. On MTA itself: in my vocabulary, sendmail is a Mail Transfer Agent. Mailreaders like pine are Mail User Applications, and procmail is a Mail Delivery Agent. If you understand these things otherwise, we definately need definitions. Even more so, because in the MS-Windows world things like this usually are arranged differently. Please see below. % cut % Item writing is my vocation and my main concern. :) Regardig the guidelines, you're right; they were drafted some time ago and I revised have them slightly. I would be *VERY* open to input from anyone on the list. (As an aside: A non-English-native Linux user has, to date, supplied the best commentary). The URL is still: http://www.soltec.net/~amead/generic.html I found that writing a few sample items helped elicit some of the unspecified issues. I do not recall you announced this; I suggest you issue a specific post on this in both the l-c-program and linux-cert lists. % cut % STATUS: Unless I hear otherwise, I am going to create a list with fields for: preferred term: definition/description: deprecated synonyms [preferred term: definition/description: deprecated synonyms (context 2)] [preferred term: definition/description: deprecated synonyms (...)] This seems workable, with the understanding (I didn't at first) that in some cases the acronym is preferred, and the written-out form deprecated; and in some cases the reverse. It should be understood that acronyms that are not in the list, should not be used but spelled out. This means we must include them in our list even if they are not in use yet, but if we anticipate someone will in the future. All this stuff may not nicely fit on a line, so I suggest to use a format where each field is on a line by its own, maybe beginning with a keyword; e.g.: Preferred: DNS Definition1:uhh ... "Internet Protocol (port 53?) to translate between Definition2:computer names (Fully Qualified Domain Names) and Definition3:numerical IP adresses (Dotted Quad numbers)." Deprecated: domain name server, ip address resolution, name resolution -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
