Re: Debian GNU/(k)NetBSD and sparc32 hardware?
>> That's not quite true. Dave Miller is still collecting patches, Mark
>> Fortescue, Krzysztof Helt and others are producing them. See the respective
>> posts on sparclinux@vger. It's just that there is no real maintainer
>> for the port.
>> Call me a chicken, but I still think it will be less work to just fix the
>> issues in the kernel and use the existing stuff instead.
>That's the whole issue. I am under the impression (perhaps wrongfully)
>that Linux development is moving at a high pace, not considering support
>of "legacy" hardware as a high priority. For instance, the first 2.6
>releases introduced significant regressions wrt. SPARC32 support
>compared to 2.4. Only now is 2.6 starting to catch up with 2.4, thanks
>to the work of a few people.
What we've seen here is classic bitrot, IMHO. Of course, the main Linux
development platform is x86 and quite a lot kernel developers only work
on one platform. This has introduced bugs for all other ports (and will
continue to do so), which I can understand. Just look at the amount of
patches between 2.6.21 and 2.6.22.
>Conversely, it seems that NetBSD values continued support more, judging
>from the mailing list archives of various ports (including, e.g., the
>still active VAX port!). It's probably following a much more
>conservative development approach, less biased towards newer hardware.
I'm not following NetBSD so closely, so please correct me when something
I write isn't true, but I am under the impression that NetBSD has not
got that much devoted kernel hackers as Linux. As a result, the process
of bitrotting is slower with NetBSD. But NetBSD has a totally different
approach to ports as Linux, just because the motives behind NetBSD are
different. And maybe these reasons will suite debian@sparc32 better,
I don't know.
>> I agree that a new debian architecture would be more fun, but
>> splitting up the remaining debian sparc32 developers between NetBSD
>> and Linux does not sound too healthy for me.
>Agreed. In the short term, it does seem "easier" to try and fix Linux'
>SPARC32 support. However, I'm wondering whether that would be a good
>Now, similar issues may also arise with other architectures, too.
Right. m68k and mipsel are springing to my mind. Well, as I am not a
debian developer, I probably should keep my mouth shut now and leave
the discussion (and of course the final decision) for long term or short
term investment to debian members which care about sparc32.
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
Stormweg 24 |listening to: Channel 13 Is Haunted (Hex Dispensers)
24539 Neumuenster, Germany|Is It Good Or Is It Bad? (Opération S)