> If it's an important part of your network, it doesn't seem to make > sense to risk significant down time and/or admin work to switch to > 2.4.
Three reasons: My network is not a production network. I'm a University professor of CS (operating systems, computer architecture and networks are among my regular classes). The departmental network I supervise uses only production kernels and Debian distributions. I have had some problems mixing 2.2.19 and 2.4.x on my home network. NFS seems particularly reluctant to comply. 2.4.x contains netfilter. Under the OSS model, the kernel only becomes stable when users have tested it. Someone has to engage the problems. > Why are you so keen on moving to 2.4? It must be a very good reason > to risk destabilizing the machine. I keep several kernels for every machine. I keep a known stable kernel that I can boot to. I don't have to 'destabilize' my machine to work on use and test a 2.4 kernel. > If it was a small amount of extra work, it would be done long before > now. I even compiled a few myself (had to fix a bunch of header > file problems) but they wouldn't boot. I've heard that very > recently the vger cvs tree has code that will boot and run but is > not ready for prime time. I don't believe this is necessarily the case. I still don't understand what the problem is, and therefore what work would need to be done to fix it. It honestly surprises me that it is easier to port a 32 bit kernel to a 64 bit machine than it is to a 32 bit one. For example, I don't understand the 'provenance' of the SPARC kernel code we use. I remain confused. Simon Read