[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sun4m and 2.4.x revisited



> 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



Reply to: