> -Why was tip/cu essentially dropped? Is it really expected that I
> download everything onto DOS floppies and then read them back using
> mread? I hesitate bring my PC into work to connect it to the network --
> using the modem automates the process (I do it over night)? To get it
> to work, I had to create /var, /var/spool, /var/spool/lock (or was it
> uucp?) and copy "tip" to "cu" ( because there was no "ln"). To figure
> out what I had to do, I had to extract base08 on my main UNIX machine
> and browse through the man pages.
"tip is on the set of install floppies, but i couldn't test it, so i
didn't document it..."-chris
It actually works fairly good -- it just needs to be documented,
include the appropriate directories, etc (and perhaps include the ln of
tip to cu).
> -After I was able to get the modem to function under NetBSD, I had a few
> problems with rz. Is there a problem with using a newer version of RZ?
> This one lacks crash recovery and multiple file receives (the latter can
> be handled by a tedious shell loop).
"Yes. You need a modified version to work with tip - see on netcom.com:
~ftp/pub/alm/rzsz-3.24.tar.Z" Others mentioned that Chuck Foresberg
doped Tip support in his freeware product, limited licensing policies,
etc. Unfortunate...I have thought many times about writing a
BSD-type-free Zmodem program that worked, but never got around to it...
> -Why do I keep getting SILO overflows? I have a 386SX-20 with 16450
> UARTS connected to an external Zoom VFX V.32bis/V.42bis modem. I have
> to use software flow control due to a deficiency in our terminal server.
> This setup generally works at 9600 baud (which I could not say for
> 386BSD-0.1), but occasionally it stalls.
This one sounds like it will be fixed -- there are faster drivers
around -- they just are not bundled, yet. I have heard of a few around
-- I just wished they were bundled.
"I ignore the silo overflows and never had a problem. Ironically I
quit having silo overflows after I got a faster modem V.32 and set the
interface speed to 38,400. This works much better than my 2400 bps
modem at 19,200."
> -Are there any plans for virtual screens (ala Linux)? I found them
> pretty handy when I tried Linux out a while back. One thing about Linux
> is that the terminal drivers feels much faster. Most UNIX consoles have
> pretty slow consoles (they expect you to scoot right on into X), but
> Linux felt like direct writes to video RAM.
"Try codrv
This is a console driver - I am not sure if NetBSD has ported it.
It is in the 0.2.4 patch kit (for 386BSD). It will be in 386BSD 0.1.5
(to be alpha released this week??)"
> -Some commands seem to me missing -- like mfs. I wanted to try out
> memory file systems, but I could not seem to get anything going. "mfs"
> does not seem to exist -- the way I understand the man pages, I create a
> memory-block device using mfs and than mount it. "adduser" does not
> exist either. Some man pages seem to missing, too.
I was told I could "ln newfs ms". I was also told I had to make a dummy
filesystem, but it would not have to be as big as the MFS (I think it
does have exist because I tried using a nonexistent name).
"if you want to use an MFS, put a line like:
/dev/sd0b /tmp mfs rw,-s=32768 0 0
in your /etc/fstab."
'you shouldn't use "mfs" to create an MFS, but rather "mount_mfs"'
Conclusion: this program does not seemed to be used very often...
I was also told I could edit the password file manually. That was a
general comment. There are two ways I rate a system -- does it confuse
me or mislead me at first -- and once I learn its peculiarities, does
it work. Linux (for me at least) failed the last one. Missing adduser
is just an annoyance (well, I was not sure about the new
/etc/passwd:/etc/passwd.master format, too). I am fairly well versed in
UNIX so I was not completely lost...
> -Is there anyway to make it so that I can make my system think its on a
> network even if I do not have an Ethernet card? I would like to route
> traffic such that if I were to do "ping atom" (atom is my machine), it
> would go through the loopback device (and making atom an alias for the
> loopback address is not what I mean). I would also like to try out the
> NFS through the loopback, too.
"the next version of NetBSD will have support for multiple loopback
interfaces. you can do this with them." -chris
"# ifconfig lo0 inet localhost
Works for me."
> -Is there any plans to ship various programs like Top or Joe with
> NetBSD? Linux SLS did that and I thought it was pretty good idea.
> In order to keep things separate, perhaps somebody could just direct me
> to an FTP site of pre-compiled packages? I usually wish to compile
> packages myself, but I am not sure if I will have the space. I would
> like to use NetBSD to orient myself with kernel programming, although, I
> probably need a system upgrade (at least more HD space).
I was essentially told no, but that I could ftp to
alpha.gnu.ai.mit.edu. BTW, Joe's scrolling is not slow (when you do
stty 38400 or setenv BAUD 38400) and it supports multiple windows. The
new version does have an odd flicker, though.
> > -How do I change the system's timezone? Do I just move the symbolic
> link in /etc to point to the midwest rather than the pacific? On
> UNIX systems at work, the timezone is an environment variable -- which
> is preset in /etc/TIMEZONE and /etc/TIMEZONE.csh.
One has to rebuild the kernel and change the link
> -Which Ethernet card is the best? I have heard good things about the
> NE2000 in general, but it sounds like 386BSD/NetBSD's NE2000 device
> driver has some problems. Does anybody plan to fix that or is there a
> better card?
On this one I generally heard that "Good" Ethernet cards were:
WD8003S
WD8003E
WD8013EBT
WD8003EP
WD8013EB
WD8003EP
WD8013EBP
WD8013EPC
3c503
because they use the if_ed driver. There was a caveat about old WD8003
cards not working, but that may be fixed by now. Does anybody know if a
3COM 3C509 would work (the Etherlink III I think)? It is supposed to be
one the fastest PC Ethernet cards out there. We have 3 unused Cabletron
Ethernet cards, one 3C503 in a public PC, and one 3C509 in a staff
computer. I could probably switch the 3C503 with the Cabletron (thought
it might be a lot of work because the public PC in question is an old
Zenith PC with odd memory mapping).
Chris said: "buy a wd8013 (SMC Elite-16). i think that's probably your
best bet."
Another person, however, said that their NE2000 worked great with
386BSD, but the SMC Elite did not.
> -How does NetBSD-0.8 differ from BSD4.4's networking and filesystem
> code? BSD4.4 has been available in alpha and beta for some time now --
> has any of it been borrowed for the 386BSD project? If not, when (if)
> BSD4.4-lite becomes available, would upgrading those subsystems improve
> performance a great deal? That is, would 386BSD require less CPU power
> to push full Ethernet through TCP/IP or get greater throughput on the
> filesystem by switching?
It seems 386BSD is already using Mach's (2.5?) VM system. One
person thought that 386BSD used the BSD4.2 UFS.
On to another question:
My understanding of the various PC-BSD's available are:
386BSD 0.1 - Basic starting point of 386BSD. Not very robust
386BSD 0.1 + patchkit (currently at 0.2.4) - 386BSD, but it works
386BSD 0.1.5 - Stable version of patched 386BSD
386BSD 0.2 - "The greatest BSD ever made - promised by WJ"
NetBSD 0.8 - offshoot of 386BSD 0.1 + 0.1.5 patchkit designed to be more
reliable and not require getting 386BSD 0.1 and applying a patch kit
and recompiling.
NetBSD current - NetBSD that is not binary compatible with 386BSD
"NetBSD also tries to be more portable -- and whereas 386BSD 0.2 goes in
new directions, NetBSD is more like 4.4BSD. I think 0.2 is the right
way to go, if it can muster enough support."
>> >-Is there any plans to ship various programs like Top or Joe with
>> >NetBSD? Linux SLS did that and I thought it was pretty good idea.
>>
>> This is more the domain of 386BSD 0.1.5 (aka FreeBSD).
"You can get the 386BSD 0.1 0.2.4 (sic) patch kit from freefall.cdrom.com.
The 386BSD 0.1 bin and src distributions are on agate.berkeley.edu (if
not on freefall)
If you are interested in kernel hacking, NetBSD is the right one.
386BSD 0.1.5 trys to be more stable as it will be distributed on
CD-ROM. An alpha release should be put up for ftp this week on
freefall.cdrom.com.
One problem with NetBSD current (as opposed to 0.8) is that the kernel
has changed so much, it does not work with many existing drivers.
It is not even binary-compatible with 386BSD now."
Anybody want to clarify any of that? BTW, do we really need this many
versions? We seem to need a reliable base version; an extended,
reliable, friendly version based on the reliable base version; and a
research version -- based loosely on the reliable version. Right now,
we have four released versions, a few available (alpha/beta) versions,
and a few promised versions.
One thing I would like to see are more binary too releases -- some
of the bugs fixed in the patchkits are prevent me from aquiring them (I
was never able to download 386BSD 0.1 because the serial driver in the
original did not work -- I never got around to feeding my computer
floppies for an afternoon).
Thanks for the all the help from:
Bruce Evans <b...@kralizec.zeta.org.au>
Bruce Jackson <jac...@ponder.csci.unt.edu>
Andrew Moore <a...@netcom.com>
Alex Tang <alti...@css.itd.umich.edu>
chris <c...@postgres.Berkeley.EDU>
Vax <v...@ccwf.cc.utexas.edu>
[I hope I did miss anybody...]
[P.S.I hope nobody minded that I did not attribute responses to their authors]
--
Benjamin Z. Goldsteen
Almost. 0.1.5 is now called "FreeBSD" and represents quite a bit more
than just a "stable patched version" - it and NetBSD can more properly
be considered siblings. The primary difference between the two groups
is that we are more conservative in what we add (we don't have, for
example, things like kernfs, devfs, LKM's, etc - we will probably have
some of these in the future, but only after they've been well shaken
out), and we're more inclined to focus on added functionality at the
utility level (more bundled packages, willingness to use GNU software,
etc).
>386BSD 0.1.5 trys to be more stable as it will be distributed on
>CD-ROM. An alpha release should be put up for ftp this week on
>freefall.cdrom.com.
Erm. Well, I may have let the cat out of the bag earlier but I never
said *THAT*. We're going to initially push it out to a few early
ALPHA testers (around 10 or so) to shake out all the obvious problems
before we push it out to the world. That said, I'd hate to close the
door on anyone really wishing to take part in the ALPHA or BETA
releases, so send me mail if you're both interested and GENUINELY HAVE
THE TIME to seriously evaluate it! Sorry to use caps, but lots of
folks just want to be the first on their block to see it, and after
we've gone through a lot of trouble supporting them while they get it
it up and working, they lose interest and disappear!
>versions? We seem to need a reliable base version; an extended,
>reliable, friendly version based on the reliable base version; and a
In a nutshell, that's us.
>research version -- based loosely on the reliable version. Right now,
And that's NetBSD.
I think the divisions are pretty clear, and sensible.
> One thing I would like to see are more binary too releases -- some
>of the bugs fixed in the patchkits are prevent me from aquiring them (I
>was never able to download 386BSD 0.1 because the serial driver in the
We will be doing this - Rodney Grimes is working on the binary distribution
set right now.
Jordan
--
Jordan Hubbard j...@violet.berkeley.edu, j...@al.org, j...@whisker.lotus.ie
Almost. 0.1.5 is now called "FreeBSD" and represents quite a bit more
than just a "stable patched version" - it and NetBSD can more properly
be considered siblings. The primary difference between the two groups
is that we are more conservative in what we add (we don't have, for
example, things like kernfs, devfs, LKM's, etc - we will probably have
some of these in the future, but only after they've been well shaken
out), and we're more inclined to focus on added functionality at the
utility level (more bundled packages, willingness to use GNU software,
etc).
>386BSD 0.1.5 trys to be more stable as it will be distributed on
>CD-ROM. An alpha release should be put up for ftp this week on
>freefall.cdrom.com.
Erm. Well, I may have let the cat out of the bag earlier but I never
said *THAT*. We're going to initially push it out to a few early
ALPHA testers (around 10 or so) to shake out all the obvious problems
before we push it out to the world. That said, I'd hate to close the
door on anyone really wishing to take part in the ALPHA or BETA
releases, so send me mail if you're both interested and GENUINELY HAVE
THE TIME to seriously evaluate it! Sorry to use caps, but lots of
folks just want to be the first on their block to see it, and after
we've gone through a lot of trouble supporting them while they get it
it up and working, they lose interest and disappear!
>versions? We seem to need a reliable base version; an extended,
>reliable, friendly version based on the reliable base version; and a
In a nutshell, that's us.
>research version -- based loosely on the reliable version. Right now,
And that's NetBSD.
I think the divisions are pretty clear, and sensible.
> One thing I would like to see are more binary too releases -- some
>of the bugs fixed in the patchkits are prevent me from aquiring them (I
>was never able to download 386BSD 0.1 because the serial driver in the
We will be doing this - Rodney Grimes is working on the binary distribution
Yes.
>386BSD 0.1 + patchkit (currently at 0.2.4) - 386BSD, but it works
It works very well, and is generally more stable than NetBSD-0.8, but
is it being replaced by the 0.1.5 version, since all of the patchkit
co-ordinators are involved in the 0.1.5 version.
>386BSD 0.1.5 - Stable version of patched 386BSD
Unreleased, but based on the 0.2.4 patchkit
>386BSD 0.2 - "The greatest BSD ever made - promised by WJ"
*grin*
>NetBSD 0.8 - offshoot of 386BSD 0.1 + 0.1.5 patchkit designed to be more
> reliable and not require getting 386BSD 0.1 and applying a patch kit
> and recompiling.
NetBSD is based on 386BSD 0.1 + 0.2.3 patchkit, and has some additional
features as well. Check out the README on agate.berkeley.edu for the
Changes. It is also not binary compatible with 386BSD (but it can run
386BSD binaries)
>NetBSD current - NetBSD that is not binary compatible with 386BSD
This is a much improved and totally re-vamped version of NetBSD, and
it contains alot of very good fixes. However, NetBSD current is not
guaranteed to be stable at times (and is at times very unstable), but
is a very good product. The next release of NetBSD should be very
good.
>If you are interested in kernel hacking, NetBSD is the right one.
Not necessarily, but if you are interested in multi-platform
support, NetBSD is definitely the way to go.
>386BSD 0.1.5 trys to be more stable as it will be distributed on
>CD-ROM. An alpha release should be put up for ftp this week on
>freefall.cdrom.com.
:-) Speaking as a 0.1.5 (aka FreeBSD) person, this means that we are
less likely to change things (this could be construed as leaving buggy
code in) unless we are more sure of the stability of the changes, at
least in this release.
>
>Anybody want to clarify any of that? BTW, do we really need this many
>versions? We seem to need a reliable base version; an extended,
>reliable, friendly version based on the reliable base version; and a
>research version -- based loosely on the reliable version.
It seems to me that's what we have.
1) 0.2 - Definately a very much research oriented version, since it contains
a ton of new code/features, but no-one but the Jolitz have seen it.
(vaporware)
2) NetBSD - an extended, reliable, friendly version that is can be easily
be used for research, and for porting to additional architectures.
But the best reason is that it's available, and not vaporware.
3) Interim - Reliable version, based on work in NetBSD and the patchkit
+ additional work and such.
(vaporware for a little bit longer)
I don't consider 386BSD 0.1 a version anymore, since it is unstable and
fairly unusable. If you want something to run *today*, I would get NetBSD.
If you are already running 386BSD, get the patchkit if you don't want to
re-install. If you want to wait a bit, get either FreeBSD or the next
NetBSD release.
> One thing I would like to see are more binary too releases -- some
>of the bugs fixed in the patchkits are prevent me from aquiring them (I
>was never able to download 386BSD 0.1 because the serial driver in the
>original did not work -- I never got around to feeding my computer
>floppies for an afternoon).
The FreeBSD group will provide a binary release, which contains all of the
patchkit + more fixes.
Nate
--
na...@bsd.coe.montana.edu | In the middle of it ........ again.
na...@cs.montana.edu | Running/supporting one of many freely available
work #: (406) 994-4836 | Operating Systems for [34]86 machines.
home #: (406) 586-0579 | (based on Net/2, name changes all the time :-)
This point has been confusing me, and hopefully someone from NetBSD and/or
FreeBSD will clarify. What precisely is considered "research" use? Does
everyone agree on one definition? I'm assuming that by "research" people
are referring to operating systems related research. My needs are not for
an OS that is undergoing rapid changes to its structure but for an OS which
will let me use *NIX and X11 on PC hardware. I also like the availability
of the source for the kernel, to make additions I need (like a device
driver for a frame grabber) and for adding patches to fix bugs as they are
found.
Now, if these are my needs, which version should I upgrade to?
Ken
--
Ken Hughes | "I can't believe this is my life;
(hug...@napa.eng.uop.edu) | I'm going to have to send my SAT
FT-Ph D candidate, PT-ex-sysadm | scores to San Quentin instead of
University of South Florida | Stanford..." _Heathers_
I hope that this answers your question, and some of the NetBSD folks may
want to comment as well.
I don't think there is a clear-cut direction on this issue, but I think
that FreeBSD may have "less rapid changes to its structure" than NetBSD,
simply because we are willing to leave in some of the code longer rather
than replace it. However, this is a bad thing for people who need many
of these changes to get NetBSD running on other architectures, so these
changes may be very good changes and will (hopefully) get shaken out
quickly, so in the end NetBSD will end up with good changes.
(Which FreeBSD will of course steal unscrupously, thus making our system
"change rapidly in it's structure") ;-)
i think nate did a pretty good job of answering the questions,
but as usual, i'll poke my nose in:
From my standpoint (and i think a number of others in the NetBSD group
feel the same way), the i386 version of NetBSD (aka NetBSD/i386),
is just a port.
i would much rather see an advanced *system* than a this-does-everything-that-
you-could-ever-hope-for-from-a-pc system.
frankly, i consider the PC hardware incredibly broken, to the point
that it will do a good job of attempting to cripple any OS running
on top of it.
NetBSD should be a good system for running "stuff" on, but some
internals are bound to change...
chris
--
Chris G. Demetriou c...@cs.berkeley.edu
"386bsd as depth first search: whenever you go to fix something you
find that 3 more things are actually broken." -- Adam Glass
> On this one I generally heard that "Good" Ethernet cards were:
[WD80?3* and 3c503]
>because they use the if_ed driver.
I saw the announcement about this being released soon. Did I miss the actual
release announcement?