> > There is some kind of in-kernel nfs server in newer kernels, you might
> > want to try that. It is not hard to put a 2.2.x kernel on tomsrtbt, just
> > make sure it supports the minix filesystem and ramdisks.
>
> Could you please make a 2.2.x boot set. We really like
> tomsrtbt and have learned to add/subtract stuff -- but the hurdle to
> adding a 2.2 kernel is a bit steep.
No. It is _NOT_ steep. It is one of the *easiest* customizations to do.
What "hurdle" are you talking about? Just replace the zImage with your
own 2.2.x zImage! It is easier than adding a program to /usr/bin, since
with that you have the libc issue. I have made several 2.2.x versions of
it for specific tasks, I have one in my stereo to play MP3 files right
now. If you have a particular reason for 2.2.x, use it. Just say 'yes'
to the minix filesystem and ramdisks, and _any_ 2.2.x kernel will work!
In fact, replacing the kernel is often *easier* and *saves more space*
than trying to mess with modules! After all, you can compile a kernel
with *exactly* what you need, *without* stuff you don't use, and a 2.2.x
kernel will *save* you space! I frequently recommend that users build a
2.2.x kernel that matches their hardware, and blow away the 2.0.x modules.
Moreover, this case is a perfect example of a job that does NOT call for
2.2.x. (1) The normal NFS server stuff works on 2.0.x, (2) NFS serving
is not one of my design goals, anyway, and, (3) the in-kernel NFS stuff is
not necessarily stable, anyway, and (4), in-kernel NFS is a performance
thing, tomsrtbt explicitely is *never* concerned with performance.
I am open to any good reasons why 2.2.x is necessary. I am working on the
2.0.39 version right now, the 2.0.39 kernel fixes all of the stupid ext2fs
incompatabilities. In general: 2.0.39 is still the *BEST* compromise of
space and function. The cases where 2.2.x has real advantages are still
rare enough, and, the 2.2.x customization is *easy* enough.
> I think we and a lot of folks would love to see an
> "Official" 2.2. boot set from you (even if it takes 2 disks). Our use
Go for it. I am working on the 2.0.39 version right now. I encourage
spinoffs and forked versions. I don't have a problem if there is the
Johnsrtbt and the Paulsrtbt and the Samanthasrtbt, or the gccrtbt and the
xfreertbt and the sambancpnfsrtbt, or the 2disk2.2.14.rtbt.
> for tomsrtbt is to recover crashed file servers -- putting two
> disks in is no big deal. Could you divide your site into two
> sections?
No. Tomsrtbt is "the most Linux on 1 floppy", that means, 1 floppy, and,
it also means, 1 version. My design goal stands. The niche that tomsrtbt
fits in is that I am trying to make the best *compromise*, and keep it
relatively *easy to customize*. I may well go to 2.2.x or libc6 at some
point, but I will probably NEVER have more that 1 version that fits on 1
floppy.
Some of the things I *am* working on:
2.0.39. Solves the ext2-filetypes (and sparse-super) problems.
adding bzip2 instead of gzip to the kernel-compression and
root-compression. If I can get the kernel to use bzip2 instead of gzip, I
can simplify the whole structure, get rid of the bzip2-cpio archive
portion, and make it more LSB/FHS compliant to boot.
Finding a way to strip kernel modules of unnecessary symbols while keeping
the ones the kernel needs. I would like help with this one, by the way,
the "strip" tool seems unable to do what I want...
Reviewing busybox as used in tomsrtbt and various awk tools, mostly to fix
a lot of problems like the current "rm" works with "rm -r -f" but not with
"rm -rf", etc., secondarily to make stuff smaller.
Reviewing the main tools for backup and filesystem repair such as e2fsck,
dd, lilo, and tar both for some bizaare bugs I havn't figured out and also
to decide if it is worth the space tradeoff to go to more current
versions.
I have the newest beta of pax working with SVR4 cpio format, that means, I
will be able to include a tool to un-RPM a .RPM file. I also need to
further test/verify the un-DEB tool and make sure they are both robust.
I am working on a "foolproof libc5 compilation environment". This is
going to be MUCH easier, and bombproof, but will be a larger
download. The idea will basically be a distribution of gcc, binutils,
headers, and basic tools, that you run through chroot. That is, un-tar
the package into /libc-5-environment, then do "chroot libc-5-environment",
then you can build and compile and customize to your hearts content,
without *any* worries about incompatabilities and conflicts with your
normal libc6 environment.
Adding DAC960 (Mylex RAID) support.
Upgrading the ntfs module.
Miscellaneous bugfixes.
I am still way behind on a lot of stuff and am not spending a big lot of
time on it, but I am making progress, and hope to release something soon,
especially as more distributions are defaulting to ext2fs options that
1.7.185 can't handle.
-Tom
