I guess it is time to clarify the design goals and future of tomsrtbt, Ltd. > > expect to lose stty, ramtest, ntfs, and some other things... > > If they must go, why not keep them there as add-ons? The purpose of add-ons is not to accumulate stuff. Modules such as ntfs will surely go there. Utilities such as ramtest that are directly related to the recovery function will go there as long as libc5 makes it difficult to use your own, no longer. Something like stty will *never* go there. Just because I had a need for it on the diskette at one point does not mean that it should be in add-ons. Add-ons is only going to have modules. And as long as tomsrtbt is libc5, it will have things like dump and restore and memtest, but it is hard for a utility to make that cut. > In fact, you could have another "tomsutils" 1.7Mb-formatted > "auxillary" disk (perhaps multiple) with the modules and the other > useful-but-non-base-essential programs and utilities on it. No. Never. Nada. Nohow. Tomsrtbt is "The most GNU/Linux on 1, (1), Uno, single, 00000000000000000000000000000001 floppy. There will never be an auxilliary second floppy from me. Forgetaboutit. Lost cause. Not gonna happen. Tomsrtbt will always forever be a single, 1, floppy image, without customizing build scripts, without add-on utility kits, without expansion tarballs, without packages, without much more architecturally than it has right now. It already is basically what I want it to be, and it *definitely* is as broad scoped as I can try to handle maintenance of. > (In truth, if you distributed the addons like this, it would save > me the [minor] hassle of un-bzip'ing them and putting them onto > floppies :-) Do not download all the add ons and put them on floppies. Only download an add on if you have specific direct proximate need for that function. Just hearing you say that brings me closer to making all module add ons by email request only. The add-ons are not fundamentally part of tomsrtbt, are not fundamentally supported, and do not constitute the 'rest of tomsrtbt'. My bandwidth has cost me money on several occaisions, and it does not warm my heart to think that mirrors are downloading dgrs.o.bz2 at a 50K cost to me without owning a Digi RightSwitch SE-X or even knowing what it is. I am not kidding about the add-ons being available only by email, or at a minimum only by slow link that costs me nothing, and I am not kidding that there is NO reason for all +/- 1 users to have dgrs.o.bz2 filed on a floppy with them. That is not the point of the add ons. > And for the ElTorito image, you could put everything you can fit > into it by default (which would be a way cool bonus). I already fill the available 2.88 floppy image with add-ons. Note, it is NOT an ISO image, it is still 1 floppy. The ElTorito will always only exist as a side-affect, useful along with a cd filesystem, and exactly the same as the tomsrtbt floppy with the exception of stuffing stuff into the extra space in a haphazard and uncareful way. > You might even have a "tomsdevel" image, which would allow the easy > construction of a tomsrtbt development environment (compiler, > sources for utilities, etc). This will sort of happen if I don't get it to glibc6, but, not the way you think- it won't be a floppy image, it will be a filesystem tarball that can be chrooted to after you unpack it, with everything in place to build stuff. Expect it to be at least 10MB if I ever do it. Note, it is not that these are bad ideas. There does exist the 'super rescue cd' and 'bootable business card', and several floppy distributions such as nuclinux are derivative of tomsrtbt. If someone wants to make an auxilliary diskette, go for it, I'll add a link pointing to it. Maybe the firm promise that I will never do it will encourage this... Now, what I *do* want to do is: -Find ways to get it to linux-2.2.19 and glibc-2.2.3 or later. -Might mean bzip2 for the kernel and root ramdisk, libc with only functions actually used by included programs, and more hard choices to delete stuff to make space... -Add many more cool things you can do with it. -Might mean working with busybox, asmutils, and my trusty C compiler, or even assembler, to actually do real work... -Might mean writing more stuff from scratch in Lua... -Fix the manpages in a major way, they are experiencing entropy. -They are also too large, and reducing them manually is hard... -Keep the basic tar/pax/cpio/lilo/fdisk/e2fsck reasonably up to date -Might involve trade offs like adding reiserfs and removing ntfs... -Tom
