Going back to chkconfig... I myself dont think chkconfig warrants to be in the partial list, however, one should study it when taking lpi certification. I believe that "partial list..." means partial and one should research for more and other commands in relation to each objective, 'chkconfig' for example.
Be on guard, don't take any chances, if your time permits it review all related commands and topics under the LPI level certification you will be taking. Rgds. On Wed, Apr 29, 2009 at 3:15 PM, Alan McKinnon <[email protected]>wrote: > On Wednesday 29 April 2009 22:04:25 Bryan J. Smith wrote: > > [snip] > > Hello Bryan, > > We hadn't heard from you in a while. Strangely, I missed your provocative > writing style :-) > > > Alan McKinnon wrote: > > > And what about "rc-update", the Gentoo equivalent? > > > Or "vi /etc/init.d/<some_arb_file>" followed by > > > "ln -s /etc/init.d/<some_arb_file> /etc/rc.<num>/<stuff> > > > for the truly hard-core? > > > chkconfig, like "service", is purely a RedHat-ism > > > - designed to work only with init.d scripts that contain > > > the special comment marker used by chkconfig > > > > And yet, like so many Debian'isms, Red Hat'isms, etc...'isms, > > they end up being adopted by many? Including going into and > > becoming LSB'isms? > > A good idea starts somewhere in one place, gets used elsewhere and might > eventually be used almost everywhere. At some point we reach this mythical > stage where it can be described as "pervasive enough to be considered > somewhat > standard". The trick is to find a way to agree on where that tipping point > is. > > > There are still people arguing that YUM is a Red Hat'ism while > > APT is not an equivalent Debian'ism -- or worse yet -- trying > > to compare RPM to APT, when it's RPM:DPKG, YUM:APT. > > > > [ BTW, in case others didn't know, YUM = Yellow Dog Updater, > > Modified, Yellow Dog being a completely different distro. ] > > Ah, but YUM is a front-end to rpm and gaining traction. rpm itself is (with > good reason) an objective on its own. If we include YUM in the objectives, > I > suppose we should include urpmi and YaST as well. That gets ridiculous > after a > while so to preserve sanity it stands to reason that we should include none > of > them. > > > Alan McKinnon wrote: > > > So it seems at odds with what LPI is all about - a generic > > > cert that is applicable to Linux at large. "Red Hat does it > > > like this" is never a valid reason to put something in the > > > exam. > > > > And yet, most distros are largely _not_ following the LSB > > standard anyway: > > > http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-ge > >neric/initscrcomconv.html > > I still believe that LSB is a good idea that can't go anywhere, and it's > elective anyway. It can't go anywhere because it ends up having to describe > a > median, and nothing precisely conforms to that. > > So distros cherry-pick the nice bits, like file system directory layout. > And > ignore the hard bits, like how to provide 32 bit libs on a 64 bit machine. > Gentoo for instance, largely ignores LSB; where it follows LSB it is more a > case of that part of the standard is a good idea, not because it's a > standard. > > > In fact, I think SuSE comes "closest" to following the LSB for > > the longest time on this. So should we cover YaST, since it > > does? > > Now there's a can of worms :-) > YaST is probably too distro-specific for inclusion, and is only familiar to > people who use SuSE. And sometimes not even then - all my servers running > proprietary databases on Linux are SuSE, and I take savage delight in > disabling YaST. So none of my juniors have much of a clue how to drive it. > But > they do know Linux broadly as they also have to contend with Red Hat, > Centos, > Gentoo, Debian, Ubuntu, the odd Slack box lying around and about 30 FreeBSD > boxes. > > > And that's also ignoring the fact that Red Hat is moving to upstart, > > which is what Canonical has pushed as an init replacement. Upstart > > changes things even more radically. > > > > Is Upstart now a Canonical'ism (or Ubuntu'ism for those that don't > > know who Canonical is)? > > Upstart is a fantastic idea, bonus points to the Canonical dev who kept > plugging away at it to get it useable. SysVinit is a horrible mangled mess > in > comparison, way too complex and convoluted. > > However, SysVinit has been there for years and for better or worse is the > de- > facto standard. One day Upstart may replace it as the standard - I have no > idea when that day might be but I'm certain it is not today. > > > And then there are the parallelization and 20-30 second boot > > comparisons. Even with Fedora 11 Beta compiled with debugging > > (which is why Fedora 11 Beta's GCC compile speed sucks compared to > > Ubuntu 9.04, as some sites _failed_ to point out adequately), > > it's clear that Red Hat and Canonical take boot time seriously. > > > > http://www.youtube.com/watch?v=yWoEBQeEdmg > > > > We can discuss options all day, but nothing is finalized. > > My rules of thumb: > > If there's one tool that is obviously much more widely used than any other, > even if it is not in use across all distros, it's a candidate for exam > inclusion. Sendmail used to be like this, bind still is. > > If there's several competing tools for the same job with no clear leader, > you > can't choose just one, and including all lowers exam quality, so a hard > choice > must be made. Obvious examples are desktop apps and browsers. More sysadmin > related examples are configuring runlevels, configuring interfaces, > sysloggers > and for the last 4 years MTAs. > > > -- > alan dot mckinnon at gmail dot com > _______________________________________________ > lpi-examdev mailing list > [email protected] > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev >
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
