On Mon, 11 Jun 2001 [EMAIL PROTECTED] wrote:
> Let's look, for example, at this current sketch of an objective. How could
> we reformat it to satisfy the needs which we've discussed. Tom, you
> specifically having background in this stage of development as well as
> your keen insight on cultural language differences, I am quite interested
> in your suggestion.
>
This is not too bad; there are some moderately important issues (*), but
otherwise I like to divulge in nit-picking:
> Obj 2 : Compiling Kernel
^^^^^
* How are the objectives to be identified? For Level 1 that was
<Exam>.<Area>.<Objective> . I proposed to change that to
<Level>.<Area>.<Objective> . So do you plan to collect related objectives
into areas? I did see a list of 12 new areas in this forum. Or do you
just give the objectives some sequence number? I think we must use
a consistent system of unique identifiers that cover all levels.
> Properly compile a kernel to include (or disable) specific
> features
^^^ this break is not nice
> as necessary. Includes recompiling an existing kernel when needed,
> implementing updates and noting changes in new kernel releases
> which may affect your production systems, creating initrd, and
> installing new kernels.
> Includes tools and files such as:
^^^^^
I would prefer "utilities" here, but I don't know which term is most used
or would be better understood.
> Includes tools and files such as:
^^^^^^^^^^^^^^^
I guess using a bulleted list is OK. In fact, some of the stuff above
could be in a bulleted list.
However, most of the list below actually are commands, so this leader is
inaccurate.
Scott used to be very much against being too specific on listing actual
files and utilities in objectives, not to mention complete commands,
because:
- the objectives should concentrate on skills, not utilities
- you may become distribution-specific
- you may be incomplete, which will raise all kinds of issues with the
users
- the objectives grow stale fast
However, people have been puzzled on how to translate those general
objectives into specific questions and examples about actual Linux
commands, so we probably should be more specific then we used to be in
L1.
I guess Alan's position on this is authorative now.
> * make
> * /usr/src/linux/*
> * /etc/lilo.conf
> * make config
> * make xconfig
> * make menuconfig
> * .config
^^^^^^^ confusing, a file among commands
> * make mproper
> * make oldconfig
> * mkinitrd
> * make image
> * make bzImage
Notes on the content of this particular objective:
* Most of the example commands actually deal with kernel configuration,
which is NOT clearly covered by the title nor the text of the
objective. "compile a kernel to include specific features" is an
incomplete and possibly inaccurate statement: configuration of a kernel
to include certain features is a step very much distinct from compiling it
and should precede the compilation step that this objective appears to
address.
Also I am missing any mention of modules: both deciding what to
modularize, and `make modules` and `make modules_install`.
In addition the objective is not too clear on how to properly and
securely install the kernel (make install, make lilo, backup old kernel,
add old and new kernel to lilo.conf, run lilo).
mkinitrd is unknown on my Debian system. The initrd.txt in the kernel
docs does not mention it either, and explains other mechanisms. In this
context, shouldn't people know about `rdev` and should this be included in
the objective?
Last but not least, should patching the kernel sources be in this
objective? It is explicitly excluded from L1, I thought it would be
appropriate for L2.
--
Tom Peters
Director of the Board & Exam Development Specialist,
Linux Professional Institute
e-mail: [EMAIL PROTECTED]
--
This message was sent from the lpi-examdev mailing list.
Send `unsubscribe lpi-examdev' in the subject to [EMAIL PROTECTED]
to leave the list.
