[lpi-discuss] Re: [lpi-staff] RPM and Debian
ross e. brunson
ross at brunson.org
Sat Mar 12 23:46:02 EST 2005
There are times when I am _very_ glad that of all the things I have to
worry about, this isn't one of them.
I agree that we're due for a retooling of the process, the exams have
only recently come out of the phase where they were perceived as being
Red Hat-centric, something I fought daily when I joined Novell, but it
is slowly getting through to everyone that they are really LSB-centric
and any distro will do.
Is it once again time for me to bring up that old chestnut of a topic
called "We should have a practicum-based exam option"? Not as the
primary option for exams, but perhaps we could offer the ability to
"CLEP" out of the different levels at LW's or an annual event?
On Sat, 2005-03-12 at 13:30 +0100, Torsten Scheck wrote:
> Mark Miller wrote:
> > I am happy with the present split myself. I truly wish that more people
> > would take the Debian specific test. We should not get into any other
> > level of package management in the 101/102 test. The only way to cover
> > such things would be in a third distro specific test designed to test on
> > the things that are unique to the distro like a yum, up2date, Synaptic
> > etc. Until and unless such a test exists we will not go there.
> This discussion about the two main package management systems (rpm,
> dpkg) is very important, as it foreshadows future problems with similar
> choices in other areas of Linux administration.
> In the long run it will be difficult to remain distribution neutral. To
> let the majority choose one application (e.g. sendmail vs. exim) and
> to ask all details on it in our exams, for instance, will lead to a
> certification for the most popular distribution. Including all choices
> and demanding all details will be even worse. Candidates and training
> industry will struggle hard with the wealth of command parameters of
> applications duplicating functionality.
> IMO to ensure a distribution-neutral LPI program, it's time to find a
> new future-proof approach for designing our objectives and for testing
> the skills described by them. It should be reliable, comprehensible, and
> attuned to long-established theories of learning. The principles of
> that approach could be applied to
> * the process of transforming Job Task Analysis results to objectives,
> * the writing of exam items, and
> * the preparation for exams according to the objectives.
> I'm not sure how this could be attained, but instinctively I would
> suggest to introduce several levels of detail:
> * important commands, including parameters which are used almost daily
> with a "commandline-only system"
> (e.g. tar, rpm, dpkg: short parameters for install, remove,
> list, search)
> * general concepts, common to similar applications
> (e.g. installation dependencies: when compiling from source package?;
> prevent package from being updated, downgrading, components of a
> package, priorities, security updates, package repositories)
> * knowledge about similar solutions, their common features and
> their main differences (no gui tools, though)
> (e.g. dependencies-aware applications: apt-get, ...)
> It's difficult to capture the distribution-neutral skills of a Linux
> system admin with one year work experience. Even with a Job Task
> Analysis there will be tough decisions to make. But with the right
> approach it will be doable, I guess. After all, there are not so many
> diverse applications in Level 1. We just need a consistent way, how to
> deal with them in the future.
More information about the lpi-discuss