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

Re: sun4m and 2.4.x revisited


> It is the case in this  case.  The thing is, sparc32 hardware is not
> new-and-groovy.   It's old  and slow.   People doing  development on
> this stuff  understandably want to do  it on machines  that are fast
> and young.  Even ultra1's and ultra2's are 4+ years old, and they're
> the slowest  of the  bunch, but still  much faster  than hypersparcs
> even.  If you were doing  the development, which would you choose to
> do first?

When I have been required to  write software that is portable (about a
dozen flavours of Unix), our  philosophy was 'port early, port often'.
That's also  the philosophy behind Extreme Programming  and the spiral
development models.

As  for development,  I've never  found myself  to be  limited  by the
compilation speed of the machine I use.  I've only been CPU bound when
I tested software using large 'regression' tests.

> It's not a 32 bit kernel.  It depends heavily on the arch.  sparc64,
> alpha, ia64 have a lot of 64 bit-ness in them.

Pentium, which is  where the leading edge of  development seems to be,
the largest number of ports, and the largest user base, is 32 bit.

I  still don't  understand where  the  problems lie.   Which areas  of
kernel functionality are affected?  What needs to be done to fix this?
How can we help?

Simon Read

Reply to: