tech-net archive

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

Re: Removing ARCNET stuffs



On 30 May 2015 at 19:09, David Holland <dholland-tech%netbsd.org@localhost> wrote:
> The reason I floated the idea of forking is that an OS that's
> specifically intended to be a high-quality Unix for older hardware can
> make a different set of decisions (most notably, it can let C++ go
> hang) and this allows avoiding a wide and growing range of problems
> that currently affect NetBSD on old hardware. Meanwhile, it would also
> (one hopes) allow retaining a critical mass of retrocomputing
> enthusiasts in one place, as opposed to having them all gradually
> drift away in different directions.

Perhaps there are several, for want of a better phrase, "niche" plays here:

- remove C++ from base; Since when was UNIX's system compiler C++

Instead there should be small fast modern C compiler that runs on all
systems and generates reasonable code.  Unfortunately, and sorry PCC
(stabs, really?), this one currently doesn't exist, and no one seems
to have the time to make it exist, sigh.

This isn't to say that NetBSD shouldn't be cross-buildable using GNU
or LLVM, just that the above be the default compiler.

FreeBSD has clearly nailed itself to LLVM+LLDB and that means a C++
system compiler, and that, in turn means slow compiles on recent
machines with lots of ram.
And on a related note, the GNU tools - GCC, GOLD, GDB
(https://sourceware.org/gdb/wiki/cxx-conversion)  - which tend to be
used here - are are now all also members of the C++ Borg (is it only
time before binutils gets assimilated? :-) so if NetBSD does nothing,
it will find itself being lead down FreeBSD's C++ path.

(oh and please delete C++ groff,  just replace it with that AWK script)

- focus more on, and sorry for the marketing term, "scalability"

That is being able to run things on smaller and larger systems.  This
means more focus to algorithms and choices, and less focus on burning
ram like no tomorrow.

- look at, cough, simulators, cough, as a way to test and develop for
less mainstream architectures

The build process is sick, figuring out how to get it running on QEMU,
say, isn't.  Can this work, consistently, across all platforms:

    qemu-system-XXX -nographic -kernel
sys/arch/XXX/compile/QEMU/netbsd -cdrom releasedir/... -sd0 disk.img

Andrew


Home | Main Index | Thread Index | Old Index