[lpi-discuss] Principles for creation of exam objectives

Bryan J. Smith b.j.smith at ieee.org
Fri Jul 29 10:01:09 EDT 2005

Torsten Scheck wrote:
> As the former sendmail discussion didn't touch those
> processes, I assumed that our processes are not well-
> known.

Evan Leibovitch <evan at telly.org> wrote:
> On the contrary. The MTA discussion that Mark started was
> an integral part of the process, specifically intended to
> engage in what Ross described as
>  ...
> So it's incorrect to say that the MTA discussion was
> outside the known process, and thus inaccurate to use
> such an assertion as a premise for other assumptions or
> assertions.

Several times during the discussion, which I entered once the
concept of "different/multiple MTAs" was discussed, I
reguarly probed about the capability and, later, feasibility
of such in the exam format.

My posts were not to "lay down the gauntlet" of what LPI must
do, but what it could do to appease the fact that there are
going to be a select _few_ (i.e., _rare_) areas where no
single product is the most popular and relevant to system
administration (e.g., MTA).  At the forefront of each of my
statements was the capability of the exam format as an
overriding limitation.  I try to make myself aware of what is
feasible for LPI.

In fact, I used various examples where mulitple solutions
were not always equal in usage, at least from a sysadmin
standpoint.  E.g., Emacs v. Vi as a very common case where Vi
is clearly the overriding tool for system administrators,
especially given the fact that nearly all distros include a
statically linked, minimal Vi for use of system recovery. 
Unfortunately, some people seem to take it wrong.

It would be great if LPI could offer the most open-ended,
modular and appeasing exam.  But the reality is that such
will never become feasible for LPI.  Furthermore, I _do_
agree in _most_ cases that nearly _all_ services/functions
can be broken down to a single, popular implementation or two
to three popular implmentations that _all_ sysadmins should

But the MTA is going to be a _rare_ case where it's not going
to be "clear cut," and it does differ wildly.  It's the same
issue of DPKG v. RPM (let alone before even looking at APT,
URPMI, YUM and quickly becoming popular front-ends like
SmartPM).  When you run into _rare_ cases like this,
inclusion is probably necessary.  How you do that, either by
testing the top 2-3, or by making modular/separate tests, I
leave that to LPI.

Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)

More information about the lpi-discuss mailing list