> I'm sorry to bring this subject to the table again but why sticking to
> a one diskette distribution? With two diskettes, you would have plenty
> of space for kernel 2.2.x, more modules (e.g. network cards), glibc
> 2.1 and many other useful goodies.
Arbitrary cutoff. There exist both packages for building a single-disk
solution based on your own criteria from scratch (yard, byld) and multi-
diskette solutions (trinux, mulinux, xdenu). Just about the only things
that make tomsrtbt unique and give it a niche where it is useful are the
best-compromises one-diskette cutoff and the tradeoffs I make between the
set of what goes on it.
> What I need is a complete, reliable, powerful, diskette-based way to
> boot Linux and do debugging with it. I don't really care if it fits on
> one diskette or two. Am I the only one in this situation?
But, it is *easy* to do this. For that matter, why not boot from CDROM?
It is faster, you can have as much stuff as you want, etc... But, if all
you want is a 2 diskette solution, you can put a huge kernel on the first
diskette, then make the second one a big gzipped ramdisk. The very point
of tomsrtbt is to be an irrational attempt to make usable compromises in a
space constraint that isn't supposed to be enough. It was *never* enough,
when I started tomsrtbt the prevailing wisdom was *already* that you had
to build a customized-per-machine-and-kernel muliple-diskette rescue set.
> I know that other "Linux on diskette(s)" distributions exist but I
> still prefer tomsrtbt because it is the best one for me. However,
> kernel 2.0 and libc5 are dead: problems like the ext2 one will be more
> frequent and workarounds won't always be available...
I havn't given up on having my cake and eating it too... I still hope to
figure out how to add 2.2.x, add glibc, and not take away functionality.
But, I am going to go kicking and screaming, and delay the steps to the
degree that I can. Given the arbitrary cutoff, it means more shrinking is
required, and also of course hard decisions about what to remove. Lets
look at areas to cut. I will want help with cutting. Things to just
delete include maybe dmsdos, a nic or 2, eata, fdomain, seagate, and
qlogicfas. Should I just whack emacs and make switching from vi something
that requires a rebuild? Maybe pcmcia can run with only the modules and
lose the cardmgr, have to play with it. Loadkeys- 40K is too big for what
it does, maybe whack it or trim it? Dhcpcd- lose it or make a smaller
one. Maybe just drop pcmcia support entirely? Maybe drop network
support. If I drop all networking support and all nic drivers, along with
the previous changes, that might be enough for 2.2.x and glibc... Bzip2 in
the kernel would help a lot. More work on the elf linking tricks. More
work on crtn.o etc. More busybox like linking? Maybe...
The thing is, it may be forced to 2.2.x or glibc. But, if I don't break
the 1 diskette cutoff, then it is probably best to delay both of those as
long as possible. For a long time my thinking was that glibc would come
first, as many more users run into the customization problem. Now, it
looks like the 2.2.x issues are more fundamental, and a workaround to make
building libc5 stuff easy may be the way to go. I probably won't consider
breaking the 1 diskette cutoff- that way lies madness, more work, a tree
of splintered versions, and no end in sight. But, there is no getting
around that making a 2.2.x kernel with the same options adds over 100K.
-Tom
