-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 14 Aug 2001, lito lampitoc posted the following:
ll>I agree. Many of the linux users are still using 2.2 kernel.
ll>Matt Balaun wrote:
ll>
ll>> > Although limited knowledge exists, this is the preferred method for
ll>> > managing devices in the 2.4 release of Linux. It should be covered
ll>> > wherever it is decided to cover mknod. I actually teach this in my
ll>>
ll>> Why, when there is already talk and plans for scrapping it for a new
ll>> system in 2.6? Since 2.2 is still the preferred production-level kernel,
ll>> I think that most, if not all, classes and questions should revolve around
ll>> 2.2, with perhaps some mention of how things are changed in 2.4
Alright now let's think about what we're doing... we're writing an
examination to certify the professionalism of Linux System Administrators.
How can we do this by extrapolation of anecdotal information? We cannot!
While I agree that there probably *is* a reasonable representation of 2.2
kernels remaining in operation I do not think it represents a majority of
the systems in service, but simply thinking a thing is so does not make it
so! We have no statistically valid data telling us that 2.2 *or* 2.4
represents the majority of what's in the field, nor do we have credible
evidence to the contrary. We only have our own experience for that unless
we embark on a census to evaluate it directly. That leaves us with our
own anecdotal evidence which is completely unscientific no matter how much
we might believe in our own opinions. So what's the best thing to do then?
Long ago LPI made the decision that when we developed tests we would
evaluate what was in the current releases and develop the tests
accordingly. The same thing applied to the FHS and the LSB... we chose to
adopt these as standards (as have the majority of distribution vendors).
In the places where we've veered from the standards (such as package
management where we cover dpkg and tarball as well as rpm) we've done so
because we *do* recognize the realities of what's in the field. We've
chosen to be inclusive rather than exclusive. So, if we are to continue to
function based on established method (and I see no reason to change our
methods) we will need to test what's in the current release kernel *and*
what ever exists in large numbers in the field (irrespective of any
presumed *majority status* simply because we know that *both* of them are
out there).
So... we need to develop this test to include issues from *both* the 2.2
and 2.4 kernels with emphasis placed on the 2.4 since we know that to do
differently would harm the tests longevity. After all, we're not going
backwards folks!
- --
csm
"...software engineers, as Percy Bysshe Shelley said of poets, are the
unacknowledged legislators of our time. acknowledge this reality and try
to shape it..." - stille/lessig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjt5GYcACgkQv6Gjsf2pQ0rqtgCfV7kflduAcWbtm+YYvbVaI1FY
4lIAn2MeigwnG7iRoFCImXH1wf2pGMw4
=6GEl
-----END PGP SIGNATURE-----
--
This message was sent from the lpi-examdev mailing list.
Send `unsubscribe lpi-examdev' in the subject to [EMAIL PROTECTED]
to leave the list.
