On Fri, 2003-09-26 at 15:49, Ed Schaller wrote: > I take issue with this comment. For one thing initrds are very useful > thing. Just like I don't run windows on my servers cause I don't need > an entire gui, com+ and ton of other stuff taking up resources, I don't > need driver probing modules, modules for hardware that does get used but > rarely, network stacks that I need for some hardware at times and a ton > of other stuff floating around in my kernel all the time. An initrd > solves many of these problems.
Not only is initrd useful, Linus Torvalds is pushing in a big way to make everything a module where possible and to depricate the old method of compiling everything statically into the kernel. As Ed has said, initrd makes a lot of sense in many applications, particularly net booting. As an aside, I appreciate Ed's incredible depth of knowlege concerning linux, and particularly regarding linux on non-intel platforms and netbooting and so forth. Unfortunately if Ed posts a problem that he can't solve, I highly doubt my ability to solve it! :) Michael > > Not to mention that initrds make the job of an admin that doesn't want > to custom compile a kernel for every slightly different system setup > they have a lot easier. They also make it possible to do such things as > network boots and root filesystems on things like loop back devices for > encryption or to avoid partitioning a ntfs mess. > > The entire opensource movement has been based on ideas including that of > people do have the time and talents to use such things. If something as > fundamental as setting up a very simple root filesystem to boot strap > another is a job to complex for anyone but a full time paid distro > developer, than this idea is dead. > > Anyone who has set up a daemon to run in a chroot environment or put > together a linux from scratch system (which many on this list have) > is perfectly capable of using an initrd. > > If your reply to someones question does not have more substance than > you're too dumb to do that then please don't respond. It doesn't help > the person asking the question or anyone else. They are highly likely to > never ask a question on the list again for that matter. > > > Ah, well there you have it. If things do not work out once you apply > > the official Debian kernel patch, you may want to escalate this issue > > to another (development) mailing list. Either that, or engage in some > > Happy Fun Kernel Debugging. Block decompression in cramfs has > > historically had issues in the 2.4 kernel, especially for larger > > cramfs images, but I would be surprised if this has not been resolved > > in 2.4.22... > > It is still broken and the apparently will not be fixed. Not to mention > the fact that the bug the prohibits initrds from being released was > introduced and discovered in 2.4.22-pre3. It appears that it may have > been fixed in 2.4.22-pre2 but I do not have time to confirm that. > > Oh and thanks for informing me that this isn't the place to ask this > question since it isn't a development list. Thankfully there are other > people on this list who are a lot more useful than you. Hans pointed me > in the right direction without telling me that I am a moron. > > Yes I am in a bad mood today. Don't rub it in. > > >>>------> > > -- > > +-------------+-----------------------+---------------+ > | Ed Schaller | Dark Mist Networking | psuedoshroom | > +-------------+-----------------------+---------------+ > > ______________________________________________________________________ > ____________________ > BYU Unix Users Group > http://uug.byu.edu/ > ___________________________________________________________________ > List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list -- Michael Torrie <[EMAIL PROTECTED]> ____________________ BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
