Re: Glibc-based Debian GNU/KNetBSD
Nathan Hawkins <utsl@quic.net> schrieb am 02.12.03 19:40:27:
> Absolutely not. One of the reasons I want to use FreeBSD is because
> Linux is too unstable for me. I've begun to conclude that the glibc port
That's also my impression (and the reason why i'm getting back again to
NetBSD on old SPARCs). Just my experience witg debian woody on a sparc station 2
and a sparc station 10 with roos cpu and leo frame buffer, a ss20 and a sun ultra1 c3d:
1st impresssion: really good, looks and behaves like my intel PCs.
2nd impression: only old kernels do support 32 bit sparc machines,
the support of builtin isdn on sun4m and sun4u machines has been dropped...
when confugrung the kernel with menuconfig You have to select/unselect the
options twice in order to get them recognized. No documentation how to build the
kernel; i had do lookup make targets in order to figure out.
3rd impression on the ss2: it ran apache with mod_php. After an uptime of about two weeks
with only sporadic access to the web server the processses hang the system. reboot
necessary. do i use nt or a unix clone?
4rth impresssiojn, on the ss10: leo support is really nice, about 10%faster than on
solaris in 24 bit 1280x1024. But the benchmarks an a few other programs installed from
the distro crashed the xserver (the same sources build on solaris did not give rise to
problems)
5th impression on ss2: software development: i´m presently coding a fltk based app and aiding
the development of mMosaic (a recent descendant of NCSA Mosaic providing tables and frames).
Both apps behaved strangely on woody/sparc and nicely on woody/intel. Starting gdb to
locate the problem brought up the machine into a state of irregularly software crashes (as if some
pages of memory were broken). Could only be repaired by power-off an reboot. running the
openprom diagnostic tools did not show up any errors (and the box has been stable on netbsd
1.3.2 - 1.5.2 as well as with solaris 7)
Conclusion: on Intel, debian is ok, but on 32 bit sparcs it is unusable. So I fully agree to You and tend to favour a debian/knetbsd on sparc with kernel and original libc, maybe with an additional lib curing the largest discrepances in the API if possible.
The rest, i.e., packaging system (IMHO debian´s system is superior to the on used in netbsd, Your mileage might vary) and the user level apps according to some debian distro (i.e., having a sid/knetnbsd/sparc and so on). Maybe describing my real problems in daily use of a debian/sparc machine helps one or another in the decision wether to use glibc or native libc in this environment.
who think they really need the glibc can still easily install it in /usr/local or use linux anyway.
Michael
______________________________________________________________________________
WEB.DE FreeMail wird 5 Jahre jung! Feiern Sie mit uns und
nutzen Sie die neuen Funktionen http://f.web.de/features/?mc=021130
Reply to: