GMail wrote: > On Monday 24 November 2008 13:23:27 David A. Bandel wrote:
[snip] > > However, LILO is not in widespread use and is not the default on anything but > a handful of distros. That fact alone should warrant it being removed from > LPI's exam objectives, as the exam seeks to be representative of what is in > widespread use. If it is the default on _one_ distro, that's enough. You can't admin what you can't boot. > > If this were not so, we could come up with a long list of stuff that should > go > back into the exam. Such as gtk-1, xfree86, all the many and varied versions > of db. Or even mSQL. I could go on forever. Apples and oranges. Fact is, I can boot and even run a server without X. In fact, why anyone would put X on a server is beyond me. But server or desktop, you have to boot it. Many packages have alternatives. I still run sendmail. I don't care if you test on it or not -- or BIND, etc. Because I can always change the mail|dns|web|etc server. Once booted, I can do what I like. Gotta boot first, though. > >> And AFAIC, the GRUB devs did everyone a disservice in not using >> standing conventions and having the software translate it from that >> nomenclature into one it could use (if it couldn't use the nomenclature >> of the OS it's booting). LILO is at least sane and readable from that >> standpoint -- and it doesn't use /dev/hda or /dev/sda, it translates >> that for us into 3,0 or 8,0 used by the OS to refer to the devices. > > You miss the point again. You are assuming that from a boot loader point of > view, there is a thing called "standard nomenclature" that even exists. It > does not. /dev/*da is Linux thing, utterly and completely irrelevant to BSD, > Windows or Solaris or anything else that is not Linux. > > Boot loader are ideally OS-agnostic, and grub tries to go this by natively > booting anything that is multi-boot complaint, and using chainloading for > anythign that isn;t. Let's make this REAL simple. You have an OS. You need to boot it. You set up the bootloader in THAT OS, NOT IN A VACUUM. You don't set up a bootloader on a multiboot system in every OS, just one. Ok, so I have a system in front of me (this is not a make believe system, but one I actually installed -- poor choice, but it was provided by a client): 2 IDE hard drives, 2 SATA drives, on IDE CDROM. I connected the two IDE drives as masters on the two IDE channels, w/ the CDROM as slave on IDE0. Not relevant for GRUB, but make the SATA drives md0 and the IDEs md1. OK, which is hd0? Thank you LILO, boot=/dev/md0, root=/dev/md0, raid-extra-boot=mbr-only. Will ensure the BIOS looks to the SATA for boot (usually a choice of SATA or IDE boot in the BIOS). Had I not RAIDed them, then boot=/dev/sda, root=/dev/sdaN (whatever). Which drive is hd0? There is no such thing. Fortunately with LILO, I can use drive designations we can agree on. I have NO IDEA where GRUB will write the MBR (and neither do you, like a broken clock that shows the right time twice a day, you could be right sometimes, too). And it may change if the BIOS is upgraded (AAAAAAGGGHHH). This is insane, but a reason for not using GRUB, not for excluding LILO from the exam. The issue remains, as long as LILO exists in any distro, as important as booting is, it needs to be included. If you upgrade any of the 50+ servers I've installed in the past 2-3 years and forget to run lilo, have a good time if you don't know how to spell LILO. Perhaps you can eventually get in and install GRUB. And the first time I run lilo, you're back to wondering why the new kernel you just installed won't boot again. If LPIC removes LILO it won't be taught. If a new generation of admins is not taught about LILO, the LPIC exam and LPIC cert becomes, to me, irrelevant. > > I agree that the nomenclature is a major pain in the butt, but I also submit > that it is a much lesser evil than using any specific OS conventions. Can you > imagine the uproar if you had to describe disks to grub using Solaris > conventions on a Linux system? The majority of people I know who are LPI > certified can't even described how Solaris does it! Heck, I even have to look > it up every time. > >> Not even boot loaders should be geek elitist garbage. But just because >> seemingly every distro has GRUB as default on x86 systems doesn't mean >> LILO has become irrelevant. > > I never said it is. It works, it gets the job done and if that's cool for > you, > then go ahead and use it. But that doesn't mean it should go in the exam. > > Example: I admin 9 caching servers dealing with around 6000 queries a second > each. I've given up explaining to the youth brigade why they do not run bind. > But I'll tell you - bind instantly slows to a crawl under that load and hard > limits to 130 queries a second. So we use cns and take the license fee in the (and I can tell you why it is so limited, so what?) > shorts. > > Should I now ask for cns to be included in the exam because it's a > carrier-grade caching name server and that industry has heavily adopted > Linux? This is obviously a stupid statement, doubly so because my machines > run FreeBSD, but you get the idea. Actually, under your circumstances, I'd run OpenBSD and there are a few fast dns servers out there (powerdns comes to mind). Your choice. But w/ 6000 queries/sec, you need to spread the load a little more (IMHO). Do the math. If one goes down you get a significant load increase on the others. And I would lobby against all but BIND for a simple reason, after a system is running, you get to choose BIND, djbdns, etc (there are 15+ web servers, a goodly number of mail servers, but what is the industry standard?). > >> When Caldera (the first to use this) came out with it as default in 1997 >> (IIRC), it crossed my eyes and I thought: gee, I hope the folks writing >> this start using standard OS conventions for disks (let the software do >> the work instead of me). Over 10 years later and I can't understand why >> the ridiculous conventions persist. ANYONE can read and understand >> lilo.conf (assuming they read English). But when I saw GRUB (having >> admin'd SUN and ULTRIX for some 10 years at this time) my head hurt. It >> still hurts when I see it and why I immediately change it. I don't need >> my job made harder on purpose. > > Again you miss the point and assume a convention exists where there is none. > > LILO is also Linux and x86 specific. I could be wrong, but I don't think you > can put LILO on a machine from FreeBSD dual-booting Linux and FreeBSD. Well if I can't I've done the impossible (OK, it was OpenBSD I dual booted, but it was *BSD). The beauty of LILO is, it will boot _anything_ that runs on x86 (for other architectures we have milo, silo, etc.). GRUB is limited in that it has to understand the underlying filesystem. LILO doesn't care about the underlying filesystem, it points to a place on the disk. Fundamentally different. No fundamental difference in DNS servers if you expect clients to be able to get an answer from the server (that's what the RFCs are all about). > > Not everyone has your use-cases, so I'll say it again: you are free to use > LILO if you wish. It does a fine job for you but is way too restrictive to be > used in the wider arena. Grub can, the distros recognize this and the vast > overwhelming majority have made the default. Therefore grub logically belongs > in the exam and LILO logically does not. Lilo is restrictive? I would have said the opposite, but that because so many newbies can't remember to run lilo, they changed to GRUB _despite_ its countless limitations. Not sure where the logic is here -- I'm still missing it. I have fought against including software in the exam. This is one I will continue to fight FOR (probably the only one). For any other service I can choose to use something else. > >>> [snip] >>> >>>>> Also grub is written in C, lilo is assembly. I know which one I find >>>>> easier to maintain and add features to. >>>> I haven't the time or desire to maintain or add features to lilo, grub, >>>> or any of a thousand plus other packages. I install the binaries and >>>> run with them. If I tinker w/ 3 packages a year, that's a lot. >>>> >>>> Lilo needs to stay in the exam. >>> Well, that's your opinion. Others might disagree. The only sane criterion >>> I've seen yet in this thread to decide if lilo stays or goes is "how many >>> distros use it by default" and perhaps "how many people use it in real >>> life"? >>> >>> If you find it useful, that's great - continue to do so. You have the >>> same choice w.r.t. qmail or djbdns[1] for example. But that doesn't mean >>> it is sufficiently pervasive to warrant inclusion in a generic exam. >> Again, GRUB/LILO are not convenience items. I can run a server without >> it running DNS or even SMTP. But I can't run it at all if I can't boot >> it, so your argument is irrelevant. > > What the living blazes are your talking about? How can my argument possibly > be > irrelevant when I'm saying LILO is not in sufficient wide-spread use to > warrant inclusion on an exam and you are talking about getting the machine to > boot? > > I really don't care which boot loader you use. I assume that you are > sufficiently knowledgeable in these matters to make up your own mind. But, > and this is a big but, the only perspective you have offered is your own, and > that is simply not good enough for inclusion on an exam on that sole basis. > >> If a new LPIC-1 admin enters my >> shop, upgrades the kernel and reboots without running lilo, he's going >> to have a hard time recovering (while I wonder how he passed the exam). > > No, he will not have a hard time at all. The machine will simply boot into > the > previous kernel, not the new one, from where he can run lilo and boot again. > Inconvenient, yes. Train smash, hardly. No, it won't. It will boot the old kernel _only_ if the admin knows about LILO (and hits a key to stop the default boot which is usually to the new kernel). And if he knows nothing about LILO (not on the exam, then not taught), he'll be a signicant amount of downtime rescuing something that doesn't need rescuing. > > Unless he, the distro, or whoever wrote your deployment software is > sufficiently brain-dead to have deleted the old kernel files before testing > them at least once. [Yes, I have seen this in real-life production...] > [snip] > > I'm waiting for the return of the dodo. That ain't gonna happen either, for > pretty much the same reason. Wow. I didn't know LILO was extinct (are we living in the same reality?). Not sure what that LILO upgrade was that just came out last week. I'll be sure to pass on your comments to the developer, though. I'm sure he'd like to know LILO is extinct. And if that's true, then we need a new bootloader, cause if the answer is GRUB ... it was the wrong question. > > David A. Bandel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
