Darin O. wrote: > Do you have a plan for where you want to take tomsrtbt? > I've seen the "ToDo" section in the FAQ, but I do you have > a vision for this tool? The vision is to keep adding stuff that makes it a great rescue and recovery floppy, there are a lot of things missing, such as the ability to read gnu-CPIO SVR4 format (-H newcrc), the ability to unpack a .RPM file, support for things like reiserfs, etc. There are also many more ways to make the existing stuff take less room, such as stripping more stuff that isn't really needed out of the binaries, rewriting dhcpcd in awk, or patching the kernel to use bzip2 instead of gzip for its own compression and the root ramdisk. The vision is summed up in 1 and 2 of the FAQ, which I think it is probably a good idea for me to annotate and expand on: (1) '"The most Linux on one floppy disk" for:' (2) 'as much stuff as possible on 1 floppy disk' It will stay on one floppy. I will probably never expand it into a multi floppy set, never make add-on floppies, and only support other media such as hard drives and bootable CDs to the degree that it is trivial to do it without fundamental structural consideration. It will always be a single floppy image, it will never be scripts to build one. There will continue to be work done on making more fit in less space- there are _hundreds_ of open ideas to make more stuff fit, it is by no means at any kind of limit yet. (1) 'rescue recovery panic & emergencies' (2) 'rescue and recovery functions get priority' It will never expand into a general distribution, there is no intention to put on applications such as mail, browsing, printing, routing, security testing, compiling, embedded use, etc., those design spaces may be filled by others such as MuLinux, LRP, Trinux, EmbeddedLinux, and SmallLinux. I will endeavor to support more rescue and recovery tools, such as dump and restore and amanda, and I will endeavor to support more hardware. (1) 'tools to keep in your shirt pockets' (2) 'whenever you can't use a hard drive' It will always be oriented to being a toolset, not pre-packaged menus or scripts, it won't force or encourage one approach over another, the idea being that you don't know in advance what situations you'll be in, and that the expert shouldn't be required to cope with a worse system just to make it easier for a novice to figure out. It won't require you to have access to a working hard drive at all, no assumptions will be made that any tools will be available. (2) 'keep it self contained, build under itself' The idea is, you can pull out your tomsrtbt floppy at the mall, boot it on a display computer in the store, and be able to customize and modify and build a new, customized, tomsrtbt. You should be able to hack on it with itself. This leads to the inclusion of things like 'cut', which is needed by the build.s script, but probably would be otherwise excluded. (2) 'try to make it behave like a normal system' The idea is, when you are recovering your system, you don't want to have to figure out the shortcomings of a crippled shell or a crippled unix command. You should still be able to do "ls -Srl" and you should still be able to do "man ls". Your habits on a normal *nix system should still all work. There is still work to do here, and obviously some compromises are made for space reasons. But, for example, the included "rm" will accept "rm -f -r" but not "rm -fr", these kind of things need to be fixed. I welcome any comments from the list as to how I can clarify, flesh out, or improve this explanation. -Thanks -Tom
