Subject: experience installing and using NetBSD
To: None <firstname.lastname@example.org>
From: T. William Wells <email@example.com>
Date: 08/25/1994 16:33:05
I recently switched from FreeBSD to NetBSD. The switch itself
was relatively painless: snarf the binaries and put them into
place, update the boot blocks, and go. (Well, more or less.) I'm
running the August 1 binary snapshot right at the moment.
Of course, getting my previous operating environment running
again was a bitch. This was not helped by several problems in
NetBSD. Here they are, along with some random observations, in no
Pppd is in /usr/sbin and it uses stuff in /var. This makes
it unsuitable for running out of /etc/netstart. Which is
a pain, since my net connection is a 56K serial line.
The serial driver is an exercise in absurdity. You cannot
reliably use it, not at 9600 with a 486/33 and a 16450,
nor at 57.6K and a 16550A. The only reason I can tolerate
it is that all my communications have end-to-end error
checking. Never mind the lack of bidirectional support,
which is only insult added to injury. Examining the
kernel code suggests that one can share interrupts for
the serial driver. Don't believe it. Attempting this
merely locked the UARTs up solid.
You might want to check out mount -a's response to a
missing fstab, to correct the error message.
The initial rc.local doesn't include /usr/local/lib.
Neither pccons nor pcvt are adequately documented. Let
me put that more positively: I won't speak for pccons,
because I stopped using it as soon as I could config a
new kernel (I like virtual consoles), but the pcvt
documentation might as well not exist, for all the good
it did me. I had to read the !@#$ code to figure out how
to switch screens!
Pcvt doesn't interlock something somewhere. If you switch
screens while they're being updated, both the original
and the destination screen can be garbled.
It's irritating that pcvt reinitializes the screen
controller whenever you change screens.
The getty initial configuration makes things 7 bits. Not
7 bits no parity or anything reasonable, 7 bits. I've
worked around it by adding np's where appropriate but
this is truly a brain-dead configuration.
I have been getting random system crashes. The most
frequent are simple hangs, which I suspect are hardware
problems. On the other hand, I have been getting some
sbdrop panics, and one remrq panic. It's annoying that
scsi doesn't allow crash dumps....
There was a bug discovered in FreeBSD, where setting your
controlling terminal twice would result in losing a vnode.
This bug appears to exist in NetBSD, though I have no
idea if it has caused any of my problems. There is a
The change in the lseek return value broke about every
other package I attempted to install, most of which have
a `long lseek' somewhere in them.
I couldn't get top to compile, though I'll admit that I
only tried standard configurations, rather than code
hacking. (Is there a repository for ported software