So you say you want an interim release of 386bsd?
Chris G. Demetriou
to lately... I've told some, i've randomly babbled to more,
and now everybody gets to know.
Reading the first three sections is probably useful to most.
Reading the rest in up in the air...
if you'd like to know more of the reasons behind this, ask;
they don't belong in this document, for reasons stated.
have a ball with it!
chris
==================
INSTALLATION NOTES for NetBSD 0.8 <1.2>
Be sure to read _ALL_ of this document before you try to
install NetBSD. NetBSD probably looks a bit similar to
things that you've seen before (e.g. 386BSD), but the
installation procedures have changed a LOT.
"We can walk our road together if our goals are all the same;
We can run alone and free if we pursue a different aim."
- Rush
What is NetBSD:
---- -- ------
NetBSD is a new system, based heavily on 386BSD 0.1, with
many improvements over 386BSD 0.1, and with different goals
than those which are espoused by the principal developers
of 386BSD. NetBSD, as the name implies, is a creation of
the members of the network community and without the net,
it's likely that this release wouldn't have come about.
The source for NetBSD is derived from 386BSD 0.1, patched
with the 0.2.2 patch kit. In addition, many programs in
UCB's second BSD Networking Software Release which were
missing from 386BSD have been integrated into NetBSD, some
of the changes from the upcoming 0.2.3 patch kit have been
included, and many local additions and bug fixes have
been performed. NetBSD is currently 100% binary compatible
with 386BSD, so programs like XFree86 which are already
available for 386BSD will install and run on NetBSD as easily
as on 386BSD.
NetBSD would not be possible were it not for the work
of the UCB Computer Systems Research Group, which
released Net/2, or the work of William and Lynne Jolitz,
who brought 386BSD into the world, or the work of the
thousands of contributors to Net/2 and 386BSD. NetBSD
is the product of the efforts of a large group of people,
and we believe that that group should have a say in deciding
NetBSD's future.
Differences Between 386BSD and NetBSD:
----------- ------- ------ --- ------
NetBSD is currently 386BSD 0.1, with lots of patches applied.
As such, it is completely binary-compatible with 386BSD 0.1,
and is much more stable. It, like 386BSD, is intended to be
used for research.
Some could look at NetBSD as simply an interim release of
386BSD. We look it as more, and therefore have named it
differently. The new name and version number reflect two
of our goals for NetBSD: an escape from the political wars
surrounding what we consider a wonderful operating system,
and the rapid development of a stable release which we
would consider of "production quality."
The Future of NetBSD:
--- ------ -- ------
We have several plans for the future of NetBSD.
The first is to organize regular releases of patches to
the source tree. These will probably be done using "cron"
to automate the process and ensure that it actually
happens. We believe these are necessary in order to
minimize duplicated work. We also hope to have
regular releases of the full binary and source trees,
but as these are much more difficult to coordinate,
this can only happen if someone volunteers for
the job.
We intend to integrate free, positive changes from
whatever sources will provide them, providing
that they are well thought-out and increase the
usability of the system. This includes integrating
changes from 386BSD 0.2 when it appears, as well
as from 4.4BSD, and perhaps even going back to Net/2
in order to re-integrate support for other architectures,
such as the Hewlett-Packard 9000/300 family of workstations.
Above all, we hope to create a stable and accessible system,
and to be responsive to the needs and desires of NetBSD
users, because it is for and because of them that NetBSD exists.
Sources of NetBSD:
------- -- ------
Currently, the NetBSD system is available from the host
agate.berkeley.edu [128.32.155.1] in the directory
pub/NetBSD/NetBSD-0.8, by anonymous FTP.
The distribution as provided on agate.berkeley.edu does not
contain crypt(3), for password and data encryption, because
it is an implementation of DES and not exportable from the
United States. If you wish to obtain the files containing
the crypt(3) functionality and are in the United States,
you may obtain it from sun-lamp.cs.berkeley.edu [128.32.240.164]
in the directory "NetBSD/NetBSD-0.8".
Hopefully, other sources of the distribution will become
available in the near future, as agate.berkeley.edu can
accept a very limited number of anonymous FTP connections.
(If you wish to become a distribution site for NetBSD,
contact Chris Demetriou, c...@sun-lamp.cs.berkeley.edu.)
NetBSD 0.8 Release Contents:
------ --- ------- --------
The NetBSD 0.8 Release consists of the following elements:
Bootable Kernel-copy floppies
These disks contain file systems, are bootable, and
have enough utilities on board to copy a new
kernel to your hard disk, once you have it partitioned
for NetBSD. They make upgrading to a new kernel
easy, because all you have to do is get a new
kernel-copy floppy with a new kernel, boot from it,
and confirm that you want to have the kernel copied
to your disk.
There are currently two different kernel copy floppy
images, "kc-aha.fs", and "kc-ahbbt.fs". The first
has the driver for the Adaptec 154x host adapter,
the second has the drivers for the Adaptec 1742 host
adapter and the Bustec 742 host adapter.
Installation floppies
These are currently two disks which contain the
software necessary to prepare your hard drive
for NetBSD and install the NetBSD distribution.
They are not bootable, and must be used in
conjunction with the kernel-copy floppies.
NetBSD distribution sets
These are collections of software, and include
both the binaries necessary to run the system
and the sources to the entire system.
NetBSD 0.8 is split up into ten different
distribution sets, six of which contain binaries,
three of which contain the NetBSD source, and
the last of which contains the tools which
could not be included in the base distribution
because they contain crypt(3).
The binary distribution sets can be found in
under "binary" subdirectory of the distribution,
and are as follows:
base08 The NetBSD 0.8 base binary distribution.
You need to install this distribution set.
This contains no compiler tools, no text
formatting tools, no games, and, in short,
nothing listed in the remaining sets;
its purpose is to be as small as possible,
and, in fact, if you've got a 30Meg
hard disk, you should be able to install
the base distribution with no problems.
It does include the man pages for the
included utilities, however, as we consider
them essential to the use of the system.
(In fact, the files in the base distribution
use approximately 16Megs, but you need
space for swap, and there's some overhead
in installation.)
[ 5.7M gzipped, 16M uncompressed ]
comp08 The compiler tools set. This includes
gcc 1.39, g++, and the full set of include
files, libraries, and profiling tools.
[ 2.1M gzipped, 7.9M uncompressed ]
text08 The text formatting tools set.
[ 0.4M gzipped, 1.3M uncompressed ]
doc08 The BSD PS1, SMM, and USD manuals,
in source form. (In other words, the
contents of /usr/share/doc.) You need
the "text08" set for this to be useful.
[ 0.6M gzipped, 2.2M uncompressed ]
game08 The games and their man pages.
[ 1.4M gzipped, 3.6M uncompressed ]
misc08 Miscellaneous files: the dictionary
and non-i386 machine-specific man-pages.
[ 1.1M gzipped, 3.9M uncompressed ]
The source distribution sets can be found in
under "source" subdirectory of the distribution,
and are as follows:
ksrc08 The sources to the NetBSD 0.8 kernel.
[ 2.6M gzipped, 5.9M uncompressed ]
src08 The sources to the rest of the NetBSD
system, excluding the "share" sources
[ 20M gzipped, 43M uncompressed ]
ssrc08 The "share" sources. These include
sources for the man pages not associated
with specific programs, the sources
for the dictionary, and so on.
[ 5.1M gzipped, 9.3M uncompressed ]
It is worth noting that unless all of the source
sets are installed, you can't rebuild and install
the system from scratch, straight out of the box.
However, all that is required to rebuild the
system in this case is a trivial modification
to one Makefile.
Finally, the security distribution set contains
crypt.c, the source file for the DES encryption
algorithm, and the binaries which depend on it.
It is named "secr08", and can be found in the
"security" subdirectory on sites which choose
to carry the complete NetBSD distribution.
[ 0.5M gzipped, 1.1M uncompressed ]
All of the sets are distributed as groups of files
named "set_name.nnn" where "set_name" is the
distribution set name, and "nnn" is the sequence
number of the file, starting with 000 for the first
file. All of these files except the last files
for each set are 240,640 bytes long. (The last
file is just long enough to contain the rest
of the data for that distribution set.)
Put together, the files for a set comprise a
gzipped tar file. If you don't want to
go through the install process, but want to
look at the contents of the files, you could use
the command
cat set_name.??? | gunzip | tar tvf -
to get a table of contents of the file set, or
cat set_name.??? | gunzip | tar xvf -
to actually extract the files.
Using this method, the files are extracted,
"below" the current directory. That is, if you
want to extract the binaries "into" your system,
i.e. replace the system binares with them, you have
to run the "tar xvf" from /.
In each of the distribution directories, there is
a file named "CKSUMS" which contains the checksums
of the files in that directory, as generated
by the cksum(1) command. You can use cksum to
check the integrity of the archives, if you suspect
one of the files is corrupt and have access to a
cksum binary.
System Requirements and Supported Devices:
------ ------------ --- --------- -------
NetBSD 0.8 runs on ISA (AT-Bus) and EISA systems, with
386 and 486 processors, with or without math coprocessors.
It does NOT support Micro-channel systems, such as some
IBM PS/2 systems. The minimal configuration includes
4Meg of RAM, and a 30Meg hard disk, but to install the entire
system you'll need much more disk space, and to run X
or compile the system more RAM is recommended. (4Meg
will actually allow you to run X and/or compile, but it's
extremely slow.)
Supported devices include:
Standard floppy controllers
Standard hard disk controllers:
MFM
ESDI
IDE
RLL
SCSI hard disk controllers:
Adaptec AHA-1542A, -1542B [ only on kc-aha floppy ]
Adaptec AHA-1742 (EISA) [ only on kc-ahb floppy ]
Bustec 742 (EISA) [ only on kc-ahb floppy ]
Ultrastor 14f
Display Adaptors:
MDA
CGA
VGA (and SVGA)
HGC
Serial communications ports
Ethernet controllers
SMC/WD 8003, 8013, and equivalents
(including the SMC "Elite" series)
Novell NE1000, NE2000
3COM 3c503
ISOLAN ISOLink
Tape drives:
QIC-02 format tape drives
most SCSI tape drives should work
_NO_ QIC-40 or QIC-80 tape drives will work
CD-ROM drives:
most SCSI CD-ROM drives should work
_NO_ non-SCSI CD-ROM drives will work
To be detected by the distributed kernels, the devices must
be configured as follows:
Device Name Port IRQ DRQ Misc
------ ---- ---- --- --- ----
Floppy Cntlr. fdc0 0x3f0 6 2
Std. Hard Disk Cntlr.
wdc0 0x1f0 14
AHA-154x SCSI Cntlr. 0x330 11 5 [ only on kc-aha floppy ]
AHA-1742 SCSI Cntlr. automagically configured [ only on kc-ahbbt floppy ]
BT742 SCSI Cntlr. 0x330 12 [ only on kc-ahbbt floppy ]
UHA-14f SCSI Cntlr. 0x330 11 5
SCSI Disks sd[0-2] automagically configured
SCSI Tapes st[01] automagically configured
SCSI CD-ROMs cd0 automagically configured
Serial Ports com0 0x3f8 4
com1 0x2f8 3
SMC/WD Ethernet wd0 0x280 2 iomem 0xd0000 iosize 8192
Novell Ethernet ne0 0x300 2
3COM 3c50 ec0 0x250 2 iomem 0xd8000 iosize 8192
ISOLAN ISOLink is0 0x320 10 7
QIC-02 Tape wt0 0x300 5 1
Getting the System on to Useful Media:
------- --- ------ -- -- ------ -----
Installation is supported from several media types, including:
MS-DOS floppies
Tape
NFS partitions
FTP
No matter what you do, however, you'll need to have
three disks (1.2M or 1.44M) handy, on which you will put
the kernel-copy image and the install floppy images.
The images are available from the directory "floppies",
under the root of the NetBSD tree at your favorite
archive site. They're available both as raw
disk images, and gzipped, to save time downloading.
If you are using an AHA-154x SCSI host adapter, you need
the kc-aha.fs image. If you're using an AHA-1742 or
BT-742 SCSI host adapter, then you'll need the kc-ahbbt.fs
image. If you're using none of these disk controllers,
you can use either kernel-copy floppy image.
If you are using UNIX to make the floppies, you should
use the command dd(1) to write the raw floppy images
(.fs files) to the disks. "man dd" or ask your system
administrator for details on the correct set of arguments
to use; it will be slightly different from system to system,
and the exact set of necessary arguments to dd is beyond the
scope of this document.
If you are using DOS to make the floppies, you should
use the rawrite utilitiy, provided in the directory
"utilities" in the distribution. It will write a raw (.fs file)
image to a disk.
The steps necessary to prepare the distribution sets
for installation depend on which method of installation
you choose. The various methods are explained below.
To prepare for installing via MS-DOS floppies:
To install NetBSD from MS-DOS floppies, you need to do
the following:
Count the number of "set_name.nnn" files
you have. Call this number N. You will
need N/6 1.44M floppies, or N/5 1.2M
floppies to install the distribution
in this manner.
Format all of the floppies, with MS-DOS.
Don't make any of them MS-DOS bootable
floppies. (i.e. don't use "format /s"!)
Place all of the "set_name.nnn" files on
the DOS disks. (How you do this is up to
you. You could, for instance, use a DOS
terminal program to download them on to
the floppies, or perhaps use a UNIX machine
capable of reading and writing DOS filesystems
to place the files on the disk. The
possibilities are almost endless.)
Once you have the files on DOS disks, you can
proceed to the next step in the installation
process, preparing your hard disk.
To prepare for installing via a tape:
To install NetBSD from a tape, you need to be somehow
to get the NetBSD filesets you wish to install on
your system on to the appropriate kind of tape,
in tar format.
If you're making the tape on a UN*X system, the easiest
way to do so is:
tar cvf <tape_device> <files>
where "<tape_device>" is the name of the tape device
that describes the tape drive you're using (possibly
something like /dev/nrst0, but we make no guarantees 8-).
If you can't figure it out, ask your system administrator.
"<files>" are the names of the "set_name.nnn" files
which you want to be placed on the tape.
To prepare for installing via an NFS partition:
NOTE: this method of installation is recommended
only for those already familiar with using
the BSD network-manipulation commands and
interfaces. If you aren't, this documentation
should help, but is not intended to be
all-encompassing.
Place the NetBSD software you wish to install into
a directory on an NFS server, and make that directory
mountable by the machine which you will be installing
NetBSD on. This will probably require modifying the
/etc/exports file of the NFS server and resetting
mountd, acts which will require superuser privileges.
Note the numeric IP address of the NFS server and of
the router closest to the the new NetBSD machine,
if the NFS server is not on a network which is
directly attached to the NetBSD machine.
Once you have done this, you can proceed to the next
step in the installation process, preparing your hard disk.
To prepare for installing via via FTP:
NOTE: this method of installation is recommended
only for those already familiar with using
the BSD network-manipulation commands and
interfaces. If you aren't, this documentation
should help, but is not intended to be
all-encompassing.
The preparations for this method of installation
are easy: all you have to do is make sure that
there's some FTP site from which you can retrieve
the NetBSD installation when it's time to do
the install. You should know the numeric IP
address of that site, the numeric IP address of
your nearest router if one is necessary
Once you have done this, you can proceed to the next
step in the installation process, preparing your hard disk.
Preparing your Hard Disk for NetBSD Installation:
--------- ---- ---- ---- --- ------ ------------
NOTE: If you wish to install NetBSD on your whole drive,
(i.e. you do not want DOS or any other operating system
on your hard disk), you can skip this section, and go on
to "Installing the NetBSD 0.8 System."
First, be sure you have a reliable back up of any data
which you may want to keep; repartitioning your hard
drive is an excellent way to destroy important data.
WARNING: If you are using a disk controller which
supports disk geometry translation, and a large disk,
you MUST turn off geometry translation before
repartitioning your disk. If you do not, NetBSD
will become hopelessly confused when you give
it partition information, as it uses the raw,
untranslated disk parameters for all operations.
Second, using the DOS "fdisk" program, repartition
your hard drive to create a new partition of at least
30Megs in size. Note the starting location and size
of this new partition; you will need this information
when you install NetBSD.
Third, using fdisk, set the other partition to be "active",
then, after leaving fdisk, do whatever is necessary
to restore order to that partition. (If that partition
used to contain DOS, this will probably involve invoking
the DOS "format" command, probably in the manner of
"format c:/s". You will then have to restore your
backed-up data to the partition.)
You are now set to install NetBSD on your hard drive.
Installing the NetBSD 0.8 System:
---------- --- ------ --- ------
Installing NetBSD is a relatively complex process, but,
if you have this document in hand and are careful to
read and remember the information which is presented
to you by the install program, it shouldn't be too
much trouble.
Before you begin, you must know several of your hard
disk's parameters. You must know the number of sectors
per track, the number of tracks per cyliner (i.e. the
number of heads), the number of bytes per sector,
and the number of cylinders on the disk. If you
use a disk controller which supports disk geometry
translation, you must turn geometry translation off,
or NetBSD will not operate properly.
If you are installing NetBSD into a partition on your
hard disk, you should have completed the section
regarding the preparation of your hard disk, and you should
know the size and offset from the beginning of the disk
of the NetBSD partition.
Once you know that information you should be ready
to proceed with the NetBSD installation. It will probably
be useful to have a pencil, paper, and calculator handy.
That all being said, it's finally time to install the system!
The following is a walk-through of the steps necessary
to get NetBSD installed on your hard disk. If you wish
to stop the installation, you may hit Control-C at any prompt,
but if you do, you'll have to begin again from scratch.
Insert the kernel-copy floppy into the boot
drive. Boot from it. It will take a while to
load the kernel from the floppy, probably
on the order of a minute or two.
You should see a copyright notice and some information
about the hardware in your machine. This could take
a long time (up to two minutes) to print out, especially
if you're using a non-SCSI hard disk controller. Eventually,
you should see two lines:
"* insert the floppy you want to have mounted as
* root, and hit any key to continue booting:"
If you do not see this message after a reasonable period of
time, try it again. If you still don't see it, you can't
install NetBSD on your hardware. If you were able to
install 386BSD, this is definitely a bug in our software;
please report it! Please include your system configuration,
and any other relevant information in your bug report.
Once you have reached that prompt, remove the kernel-copy
floppy from the drive, insert the first installation disk,
and hit any key.
After a short while (approximately 30 seconds), you should
see a welcome message and a prompt, asking if you wish
to proceed with the installation.
If you wish to proceed, enter "y" and then return.
You will then be asked what type of disk drive you have.
The valid options are listed on the screen. You may
be asked if your disk supports automatic sector forwarding.
Answer yes if and only if you know that it automatically
re-maps bad blocks for you.
The install program will then print out what it thinks
your disk is. It can only install on the first
"wd" (i.e. ESDI, ST506, or IDE) disk, or the first "sd"
(SCSI) disk in the system.
You will then be asked for a label name for your disk.
This should be a short, one-word name for your disk,
e.g. "cp3100-mine" for a Conner Peripherals "3100" disk.
You needn't remember this name.
Next, you will be prompted for the information you were
supposed to remember about your disk. Enter it when the
install program asks for it.
When asked for the size of the NetBSD portion of the disk,
either input the number listed as the total size of your
disk, or multiply the number of cylinders in the NetBSD
portion of your disk by the number of sectors per cylinder
(also listed by the install program) and input the result.
If you are not installing on the whole disk, you will
be asked for the offset of the NetBSD partition from
the beginning of the disk. Again, calculate this
number from the information you recorded when partitioning
your disk with fdisk, and input the result.
You will then be asked for the size of your root partition,
in sectors. Enter a number which is a multiple of the
number of sectors per cylinder for your disk, in the
range of 12000 to 16000, assuming your disk uses 512 byte
sectors and depending on how large you want your root
partition to be.
Next, you will be asked for the size of your swap partition.
You should probably allocate around twice as much swap
space as you do real memory, and, again, this number should be
a multiple of the number of sectors per cylinder. As an example,
if you've got 8Meg memory and 512 byte sectors, you want
a multiple of your sects/cyl close to 32000 as your swap size.
The install program will then ask you for information
about the rest of the partitions you want on your disk.
For the purposes of this document, you only want
one more: /usr. Therefore, at the prompt, when in asks
you to enter the size of the next partition, enter
the number of sectors remaining in the NetBSD portion of
the disk. (It is displayed on the previous line.)
When it asks you for the mount point for this partition,
say "/usr".
YOU ARE NOW AT THE POINT OF NO RETURN.
If you confirm that you want to install NetBSD, your
hard drive will be modified, and perhaps it contents
scrambled at the whim of the install program.
This is especially likely if you gave the install
program incorrect information.
If you are sure you want to proceed, enter "yes" at the prompt.
The install program will now make the filesystems you
specified. There should be no errors in this section
of the installation. If there are, restart from the
the beginning of the installation process.
After the installation program prompts you to see if you'd
like to be told about all of the files it's going to copy
to your hard drive, it will spend a few minutes copying these
files and then will print out an informative message and
place you at a "#" prompt.
Read the message and note which partition you need
to copy a kernel to. Reboot the machine according
to the instructions given and boot once again
off of the kernel-copy floppy.
At the prompt asking you to replace the floppy and
press any key, do _not_ replace the floppy, just
press any key.
At the ">" prompt, enter "copy" to prepare to copy
the kernel on the floppy to your hard disk.
At the next ">" prompt, enter the disk partition to
which you want to copy the kernel.
It will work for a minute or two, then present you
with another prompt. Follow the instructions given,
and reboot from the hard disk.
When the machine begins to boot, a three-line banner
should appear at the top of the screen. In a few
seconds, a bunch of messages should appear,
describing the hardware in your machine. Once again,
this stage can take up to two minutes, so DO NOT PANIC!
It will ask you to insert the second install floppy
into a floppy drive, and enter that drive's number.
"0" corresponds to DOS's "A:" drive, "1" corresponds
to DOS's "B:" drive.
After you enter the number it will ask you if you'd
like to watch its progress, and after you answer this
question it will begin installing still more files
on your hard disk. This should take no more than
3 minutes.
You will be given (more) instructions, and you
should reboot the machine again, from the hard drive.
CONGRATULATIONS: You now have the minimum base of
NetBSD files on your hard disk! Now you get to
install the dxistribution file sets.
After the machine is done booting, you will be presented
with a screenful of information about what to do next.
What you do from this point on depends on which
media you're using to install NetBSD. Follow the appropriate
instructions, given below.
To install from tape or floppy:
The first thing you should do is pick a temporary
directory where the distribution files can be stored.
To do this, use the command "set_tmp_dir" and enter
your choice. The default is /usr/distrib.
After you have picked a temporary directory,
you should issue the appropriate load command:
load_fd if you're loading from floppies
load_qic_tape if loading from QIC-02 tape
load_scsi_tape if you're loading from the first
SCSI tape drive in the system.
You will then be prompted for information as to which
floppy drive to load from, if you choose that
method of isntallation.
Next, you will be told to insert the media into
the appropriate drive, and hit return. Continue
to follow instructions until you are returned to
the "#" prompt.
Go to the directory which contains the first
distribution set you wish to install. This is
either the directory you specified above, if loading
from floppy, or possibly a subdirectory of that
directory, if you loaded from tape.
When there, run "set_tmp_dir" again, and choose
the default temporary directory, by hitting
return at the prompt.
Run the "extract" command, giving it as its sole
argument the name of the distribution set you
wish to extract. For example, to extract the base
distribution, use the command:
extract base08
and to extract the games distribution:
extract game08
After the extraction is complete, go to the location
of the next set you want to extract, "set_tmp_dir"
again, and once again issue the appropriate
extract command. Continue this process until
you've finished installing all of the sets which you
desire to have on your hard disk.
After each set is finished, if you know that you
are running low on space you can remove the
distribution files for that set by saying:
rm set_name.???
For example, if you wish to remove the distribution
files for the game08 set, after the "extract game08"
command has completed, issue the command:
rm game08.???
Once you have extracted all sets and are at the "#" prompt
again, proceed to the section "Configuring Your System,"
below.
To install via FTP or NFS:
First, use set_tmp_dir to pick a temporary directory
for the installation files. /usr/distrib is suggested.
configure the appropriate ethernet interface (e.g. we0,
ne0, etc.) up, with a command like:
ifconfig <ifname> <ipaddr> [netmask <netmask>]
where <ifname> is the interface name (e.g. we0, etc.),
and <ipaddr> is the numeric IP address of the interface.
If the interface has a special netmask, supply
the word "netmask" and that netmask at the end of the
command line. For instance, without a special netmask:
ifconfig we0 129.133.10.10
or with a special netmask
ifconfig we0 128.32.240.167 netmask 0xffffff00
If the NFS server or FTP server is not on a directly-
connected network, you should set up a route to it
with the command:
route add default <gate_ipaddr>
where <gate_ipaddr> is your gateway's numeric IP address.
If you are NFS-mounting the distribution sets,
mount them on the temporary directory with the command:
mount -t nfs <serv_ipaddr>:<dist_dir> <tmp_dir>
where <serv_ipaddr> is the server's numeric IP address,
<dist_dir> is the path to the distribution files on
the server, and <tmp_dir> is the name of the local
temporary directory.
Once this is done, proceed as if you had loaded the
files from tape, "cd"ing to the appropriate directories
and running "set_tmp_dir" and "extract" as appropriate.
If you are retrieving the distribution sets using ftp,
cd into the temp directory, and execute the command:
ftp <serv_ipaddr>
where <serv_ipaddr> is once again the server's
numeric IP address. Get the files with FTP,
taking care to use binary mode to transfer
all files.
Once you have all of the files for the distribution sets
you wish to install, you can proceed using the instructions
above as if you had installed the files from a floppy.
Configuring Your System:
----------- ---- ------
Once you have finished extracting all of the distribution sets that
you want on your hard drive and are back at the "#" prompt,
you are ready to configure your system.
The configuration utilitiy expects that you have installed the base
system. If you have not, you will not be able to run it successfully
(nor will you have a functional system regarless of configuration).
To configure the newly installed operating system, run the
command "configure".
Configure will ask for the machine's hostname, domain name, and other
network configuration information.
Once you have supplied configure all that it requests, your
machine will be configured well enough that when you reboot it
it will be a completely functional NetBSD system. It is not
completely configured, however; you should adjust the /etc/sendmail.cf
file as necessary to suit your site and/or disable sendmail in
/etc/rc and you should look in /etc/netstart to make sure the flags
are defined correctly for your site.
Once you are done with configuration, reboot with the "reboot" command.
When it boots off of the hard drive, you will have a complete
NetBSD system! CONGRATULATIONS! (You really deserve them!!!)
Administrivia:
-------------
Registration? What's that?
If you've got something to say, do so! We'd like your input.
Please send random comments to:
netbsd-...@sun-lamp.cs.berkeley.edu
Please send bug reports, and that sort of material to:
netbs...@sun-lamp.cs.berkeley.edu
If you'd like to help with this effort, and have an idea as to how
you could be useful, send mail to:
netbs...@sun-lamp.cs.berkeley.edu
THANKS FOR USING THIS; that's what makes it all worthwhile.
Thanks go to:
------ -- --
Members of UCB's Computer Systems Research Group, including but not limited to:
Keith Bostic
Marshall Kirk McKusick
Mike Karels
for their ongoing work on BSD systems.
William and Lynne Jolitz for providing 386BSD.
Brian Berliner, Jeff Polk, et al., because without CVS this
would have been MUCH harder.
All of the people involved in the patch kit, including but not limited to:
Terry Lambert
Nate Williams
Jordan Hubbard
Rod Grimes
and the many people who've submitted patches!
for a good number of the bug fixes and improvements to be found in
this release.
Rob Robertson, for the disk space on agate.berkeley.edu that got
this _whole_ thing going.
Dave Silvia for a head start on a reasonable install program.
The attendees of the Winter '93 USENIX 386BSD BOF, whose discussions
of various issues surrounding 386BSD caused cgd to decide to jump in
head first.
Carl Staelin, for his patience...
And, of course, all of the people who've put sweat and tears into that
which constitutes this package over the last year.
(Obviously, there are a lot more people who deserve thanks here.
If you're one of them, and would like to be here, by all means,
_SAY SOMETHING_... We've probably forgotten you!)
We are:
-- ---
Chris G. Demetriou <c...@sun-lamp.cs.berkeley.edu>
Adam Glass <gl...@sun-lamp.cs.berkeley.edu>
Theo Deraadt <der...@sun-lamp.cs.berkeley.edu>
Sean Eric Fagan <s...@kithrup.com>
Charles Hannum <myc...@sun-lamp.cs.berkeley.edu>
Rodney Grimes <rgr...@sun-lamp.cs.berkeley.edu>
Chris Provenzano <pro...@sun-lamp.cs.berkeley.edu>
Peter da Silva <p...@sun-lamp.cs.berkeley.edu>
--
Chris G. Demetriou c...@agate.berkeley.edu
"Sometimes it is better to have twenty million instructions by
Friday than twenty million instructions per second." -- Wes Clark
Chris G. Demetriou
that you probably want to... 8-)
chris
looking for a bed to crash into...
--
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
Chris G. Demetriou
this has been picked up by gatekeeper.dec.com...
it's in pub/BSD, i think...
chris
John Jackson
: Some of you have undoubtedly been wondering what i've been up
: to lately... I've told some, i've randomly babbled to more,
: and now everybody gets to know.
: Reading the first three sections is probably useful to most.
: Reading the rest in up in the air...
: if you'd like to know more of the reasons behind this, ask;
: they don't belong in this document, for reasons stated.
: have a ball with it!
: chris
<rest deleted>
Does NetBSD fix silo overflows?
Chris G. Demetriou
>Does NetBSD fix silo overflows?
a slightly better question would be:
does it fix the serial driver.
the answer to that is: right now, it's the stock
serial driver plus patches.
incorporation of Bruce Evans' interrupt, NPX, and
serial driver code will probably happen
by the first few source diff releases, i.e. probably
within a month or so.
Thomas David Rivers
Well, while I applaud the effort generalizing 386BSD to NetBSD, and
(hopefully) having it stay relatively close to whatever becomes
of BSD (not necessarilly the newest, most nifty-keen operating system
ideas that someone thought of last night - but not the drudgey old
Sys V 3.2 stuff...) - I'm now very confused. I really like the idea
of divorcing from 386bsd; for all the reasons mentioned in the NetBSD
announcement, but just don't know where to go from here.
We now have at the moment; "another" 386BSD. Should I abandon
my current sources and switch to NetBSD? Will the patchkit, etc...
be moved from 386bsd to NetBSD - what is to be done?
We probably should reach a consensus about how our collective support
is to be applied. Personally, I would like to go with NetBSD, as that
offers a set of goals which more closely matches my own.
Thus, I suggest we begin generating patch sets against that, and
encourage everyone to move over to NetBSD.
What do you think?
- Uncertain and confused -
- Dave Rivers -
(sas...@unx.sas.com (work))
(riv...@ponds.uucp (home))
--
UPDATE ALL INFORMATION AND POD INTO COSMOS - Federal Express
Dave Burgess
>
>
[...crunch...]
>
>We now have at the moment; "another" 386BSD. Should I abandon
>my current sources and switch to NetBSD? Will the patchkit, etc...
>be moved from 386bsd to NetBSD - what is to be done?
>
>We probably should reach a consensus about how our collective support
>is to be applied. Personally, I would like to go with NetBSD, as that
>offers a set of goals which more closely matches my own.
>
>Thus, I suggest we begin generating patch sets against that, and
>encourage everyone to move over to NetBSD.
>
>What do you think?
>
Another question is what do I do now?
I have the patched 386bsd source tree, albeit not necessarily in the Netbsd
structure. IN addition, I have several 'server' processes, including an
enterprise wide News Server that I can't just 'dump' to load a new version of
an operating system. While tape backups are all well and good; seriously,
where do I go from here. Are the underlying disk structures of the 'old'
386bsd still there? Has the partition numbering scheme for DOS fdisk
changed? Are there other, more insidious questions that need asked that I
don't dare utter?
I suspect, and hope (fervently hope), that by keeping up with the patchkit,
I am actually in a position to be able to change the name on what I already
have and press on from there. I can move stuff around, and change source
directory names, but restarting from scratch is definitely out of the
question.
Also, what is to become of the FAQ? We have made serious progress on creating
a new FAQ (most everyone will see the first three or four sections of it on
Wednesday) and need to keep moving. Many of the questions/answer will
continue to apply to both the old 386bsd (v0.1) and the new NetBSD for
a while.
Speaking of FAQs, Peter Tattum has been working on a Hypertext FAQ system that
seems to be really neat. The new 386bsd/NetBSD faq is loaded on his server,
in Tasmania, and he is looking for a Unix guru to help him get the DOS
software that he has written translated into Unix. E-Mail me for more
information on the FAQ or the Hypertext program...
Suffice it to say, this software announcement gives me a feeling a little
like the one I got when I got married. Once I start down this road, there
is little hope of turning back. A few words of consolation might be
appropriate at this point for those of us who think the vnode layer is the
one between the mustard and the cheese....
The worried maintainer of somebody's FAQ, but not just sure whose!?!?
--
------
TSgt Dave Burgess
NCOIC AL/Management Information Systems Office
Brooks AFB, TX
Holger Veit
|> In article <C5sCv...@unx.sas.com> sas...@torpid.unx.sas.com (Thomas David Rivers) writes:
|> >
|> >
|> [...crunch...]
|> >
|> >We now have at the moment; "another" 386BSD. Should I abandon
|> >my current sources and switch to NetBSD? Will the patchkit, etc...
|> >be moved from 386bsd to NetBSD - what is to be done?
|> >
|> >We probably should reach a consensus about how our collective support
|> >is to be applied. Personally, I would like to go with NetBSD, as that
|> >offers a set of goals which more closely matches my own.
|> >
|> >Thus, I suggest we begin generating patch sets against that, and
|> >encourage everyone to move over to NetBSD.
|> >
|> >What do you think?
|> >
|>
|> Another question is what do I do now?
[..specific problems with secondary software not from the distribution..]
I also asked the same question when I read the NetBSD announcement. Apparently
many people will grab the "new release of 386bsd" just because it is new.
What is missing is a procedure to upgrade from a src01dist+patchkit-0.2.2
to the new release for all persons who do not want to start from scratch.
Besides some reorgs of trees and splitting into separate packages the real
difference to src01+pk022 cannot be so extreme that an upgrade kit is impossible
(it just has to be done).
The situation becomes more interesting with the release of 386bsd-0.2
(even if it looks as if everyone will get a grey beard until it arrives;-)).
In this case we have three releases people can offer patches for:
The 386bsd-0.1+pk0.2.*, NetBSD with its own patchkit possibly, and 386bsd-0.2.
In the latter case we again have the difficulty whether to drop NetBSD and
take the latest and best (?). Probably there will be a set of diffs to upgrade
NetBSD to the 0.2 level, or vice versa (?).
So what?
Personally I would wait for 0.2, but the question is whether many people
are as patient, and it is really possible that NetBSD will become the currently
most stable BSD available (if upgraded with GNU software). 0.2 will be
(according to the numbering scheme) an experimental system with possibly
several new bugs (and old corrected, of course). On the other hand, this brings
386bsd back into the research area that has been left when it was entirely
released to the real world (and not requiring to adopt any real world standard
is not the worst for experimenting with novel approaches).
BTW: I just saw the announcement of pk-0.2.3, and wonder if this brings my system
to NetBSD.
Maybe the patchkit people and the NetBSD people (who are mainly the same group)
comment some more about the expected future.
Holger
|> TSgt Dave Burgess
|> NCOIC AL/Management Information Systems Office
|> Brooks AFB, TX
--
Dr. Holger Veit | INTERNET: Holge...@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions
Nate Williams
>|> Another question is what do I do now?
>
>
>many people will grab the "new release of 386bsd" just because it is new.
>What is missing is a procedure to upgrade from a src01dist+patchkit-0.2.2
>to the new release for all persons who do not want to start from scratch.
>Besides some reorgs of trees and splitting into separate packages the real
>difference to src01+pk022 cannot be so extreme that an upgrade kit is impossible
>(it just has to be done).
One, the amount of changes from 386BSD + patchkit -> NetBSD are
extremely large, especially in the area of configuration.
The goals for the NetBSD group and the continuing 386BSD group are different.
There is currently work in progress (Yeah, right, we've heard that a
million times now) to produce an interim release of 386BSD, with Bill's
blessing.
The purpose of this release is to make the 0.1 -> 0.2 transition easier,
and to introduce some new code into the tree (updated software, shared
libraries :-), better installation tools, etc..)
>The situation becomes more interesting with the release of 386bsd-0.2
>(even if it looks as if everyone will get a grey beard until it arrives;-)).
If I am not mistaken, (Chris, contradict me if I'm wrong), the NetBSD
crew have no intention on running 0.2. However, this doesn't mean they
will ignore 0.2, but instead take what they consider to be useful
features from it (if possible), and place them into NetBSD.
>In this case we have three releases people can offer patches for:
>The 386bsd-0.1+pk0.2.*, NetBSD with its own patchkit possibly, and 386bsd-0.2.
>In the latter case we again have the difficulty whether to drop NetBSD and
>take the latest and best (?). Probably there will be a set of diffs to upgrade
>NetBSD to the 0.2 level, or vice versa (?).
Doubtful, if my statement on NetBSD is correct.
>BTW: I just saw the announcement of pk-0.2.3, and wonder if this brings my system
>to NetBSD.
No, NetBSD and 386BSD are still different. Chris and his support crew have
done a lot of VERY GOOD THINGS in NetBSD (and some things on which I disagree
with, but that's to be expected. :-)
Hopefully alot of these changes will be integrated into the interim release,
but due to lack of hardware, and some miscommunication with the site hosting
the interim release, things have not progressed as quickly as we would like.
>Maybe the patchkit people and the NetBSD people (who are mainly the same group)
>comment some more about the expected future.
I can't speak for Rod, but as a former patchkit maintainer, if we can
get these technical problems ironed out, we are planning on still doing
an interim release.
Now, right now today, Chris's release is the best thing on the market,
and if you are a new users, I suggest using it. But, if you're happy
with 386BSD today, Rod is going to continue to work his tail off and
produce patchkits against 386BSD. (And there is some very nice stuff
coming up in the next patchkit, but Rod needs to take about 2 years off
after cranking this one out :-)
Anyway, that's the status from my end,
Nate
--
os...@terra.oscs.montana.edu | Still trying to find a good reason for
na...@cs.montana.edu | these 'computer' things. Personally,
work #: (406) 994-4836 | I don't think they'll catch on -
home #: (406) 586-0579 | Don Hammerstrom
Chris G. Demetriou
=>my current sources and switch to NetBSD? Will the patchkit, etc...
=>be moved from 386bsd to NetBSD - what is to be done?
my answer to the first is "if you want to..."
the patchkit will *not* be moved; we have our own maintenance scheme,
which you'll be seeing more of in probably 2 weeks.
basically, "cvs rdiff" is your friend...
=>We probably should reach a consensus about how our collective support
=>is to be applied. Personally, I would like to go with NetBSD, as that
=>offers a set of goals which more closely matches my own.
for support: there is currently a group of people "supporting"
NetBSD -- if you'd like to help out, get in touch... 8-)
=>Thus, I suggest we begin generating patch sets against that, and
=>encourage everyone to move over to NetBSD.
we plan to put out mostly-regular diff sets, and possibly regular
binary realeases, as well.
the diff sets will probably happen every two weeks or so,
the binary sets about every 2 months, or however often
we can convince some sucker to do them... 8-)
(i did this last one myself... and oh, do i ache... 8-)
Chris G. Demetriou
=>I have the patched 386bsd source tree, albeit not necessarily in the Netbsd
=>structure. IN addition, I have several 'server' processes, including an
=>enterprise wide News Server that I can't just 'dump' to load a new version of
=>an operating system. While tape backups are all well and good; seriously,
=>where do I go from here. Are the underlying disk structures of the 'old'
=>386bsd still there? Has the partition numbering scheme for DOS fdisk
=>changed? Are there other, more insidious questions that need asked that I
=>don't dare utter?
basically, the system as it is now is 386bsd 0.1 + patches,
plus improvements. to the best of my knowledge
"the gang" and i introduced no incompatibilities.
if you'd like to install the new stuff on top of what you've got,
dump your system, get a the binary/source distributions,
and
cat distname.??? | gunzip | (cd / ; tar xvf - )
or wherever.
you can do the same to get the source tree, and build the sources
into binaries, then install them into the right place when you
feel up to it...
=>I suspect, and hope (fervently hope), that by keeping up with the patchkit,
=>I am actually in a position to be able to change the name on what I already
=>have and press on from there. I can move stuff around, and change source
=>directory names, but restarting from scratch is definitely out of the
=>question.
the patchkit is not going to converge on NetBSD, if i'm not mistaken...
=>Also, what is to become of the FAQ? We have made serious progress on creating
=>a new FAQ (most everyone will see the first three or four sections of it on
=>Wednesday) and need to keep moving. Many of the questions/answer will
=>continue to apply to both the old 386bsd (v0.1) and the new NetBSD for
=>a while.
true.
=>The worried maintainer of somebody's FAQ, but not just sure whose!?!?
whosever you want... probably 386BSD's, if you plan to keep it in sync with
0.2 when it comes out...
Chris G. Demetriou
=>many people will grab the "new release of 386bsd" just because it is new.
=>What is missing is a procedure to upgrade from a src01dist+patchkit-0.2.2
=>to the new release for all persons who do not want to start from scratch.
(i thought i explained this in the install notes, but...)
if you'd like to install the new stuff on top of what you've got,
dump your system, get a the binary/source distributions,
and
cat distname.??? | gunzip | (cd / ; tar xvf - )
or wherever.
you can do the same to get the source tree, and build the sources
into binaries, then install them into the right place when you
feel up to it...
>(it just has to be done).
honestly, if you'd like to volunteer to do it, that'd
be great, and i'll do my best to help you. doing a release this
big is *really* a bear, a lot harder than i thought it would
be when i started...
=>BTW: I just saw the announcement of pk-0.2.3, and wonder if this brings my system
=>to NetBSD.
not by a long shot.
=>Maybe the patchkit people and the NetBSD people (who are mainly the same group)
=>comment some more about the expected future.
sorry this is hasty, but i'm really busy, and leaving town until sunday,
at 4PM this afternoon, and need to make some slides for a presentation
first... 8-)
NetBSD plans to continue what we consider "appropriate" development,
and incorporate positive changes from all souces which provide them.
we've given our source tree to the patchkit and 0.1.5 folks,
and are working reasonably closely with them. (basically, we tend
to trade pre-release stuff, if i'm not mistaken.)
We'd like NetBSD to be a useful, stable, featureful, and
widely-compatible operating system, and we don't want it
to be surrounded by the "we must be different" statements
which seem to come out of 386BSD, nor the political wars...
Chris G. Demetriou
=>One, the amount of changes from 386BSD + patchkit -> NetBSD are
=>extremely large, especially in the area of configuration.
this is true.
=>The goals for the NetBSD group and the continuing 386BSD group are different.
this too, is true.
=>If I am not mistaken, (Chris, contradict me if I'm wrong), the NetBSD
=>crew have no intention on running 0.2. However, this doesn't mean they
=>will ignore 0.2, but instead take what they consider to be useful
=>features from it (if possible), and place them into NetBSD.
(give nate a cookie for nice statement... 8-)
that's correct.
=>No, NetBSD and 386BSD are still different. Chris and his support crew have
=>done a lot of VERY GOOD THINGS in NetBSD (and some things on which I disagree
=>with, but that's to be expected. :-)
thanks.
Guido van Rooij
version running here, with *lots* of patches not in the patchkit.
Just saying NetBSD is a modified 0.1 with patchkit 0.2.2 is not
enough, I think. I need to know the exact differences between it
and 386bsd. I just don't have enough space to install both systems.
I am also not going to just throw away a stable system.
I think many ppl., like me, will have this feeling. Whenever a
new patchkit comes out, it's relatively easy just to look which
patches you already applied, were covered by it.
Isn't it possible to put into some README:
1) What is completely new.
2) What exactly the diffs are between 0.1+patchkit 0.2.3 (note the 3)
and NeTBSD
3) Other changes that are important.
Note that I like the idea of NetBSD very much. I just think many ppl.
will hesitate installing it without having an exact notion of what
they will get back.
-Guido
--
Guido van Rooij | Internet: gu...@gvr.win.tue.nl
Bisschopsmolen 16 | Phone: ++31.40.461433
5612 DS Eindhoven | ((12+144+20)+3*sqrt(4))/7
The Netherlands | +(5*11)=9^2+0
Marc WANDSCHNEIDER
>1) What is completely new.
>2) What exactly the diffs are between 0.1+patchkit 0.2.3 (note the 3)
> and NeTBSD
>3) Other changes that are important.
>
>Note that I like the idea of NetBSD very much. I just think many ppl.
>will hesitate installing it without having an exact notion of what
>they will get back.
I would basically guess that in the short term, you will get
some slight hassles. I wouldn't expect changing to be THAT great a
hassle for people without heavily customized machines, but those who
have applied many selective patches might have more trouble.
However, in the long run---If you agree with the NetBSD philosophy,
and are more up to date on the squabbling of the day---you'll end up with
a potentially better product.
I have the advantage of having sold my machine in the last couple
of weeks, and will be looking again in a month to see which one of the
two I should install. In the interim, I will continue to help out with the
FAQ and will still pay attention to what's going on... Then, when I get the
new machine, I will be able to choose which I want...
I had a feeling this announcement would cause some troubles, and
I find the fragmentation that the BSD community seems to be undergoing
nothing short of sad.
[cheesy mode]
As Rodney King once said: "People, can't we just all get along?"
[end cheesy mode][THANK GOD]
However, if this turns out to be a GROUP PROJECT, and not just
a personal act of revenge against some heinous act that wfj might have
once committed, then I think that this has a very good chance of
becoming something very good.
Toodlepip!
Marc [die-hard BSDer] 'em.
Elizabeth Haley
What do I do if I already have 386bsd 0.1 plus unnamed patches
installed, and don't want to lose much... Will there be a
from-naked-386bsd-0.1 patchkit?
--
Jesus saves sinners...
/****************************************************************************\
==============David Charles Todd, tHE mAN wITH tHREE fIRST nAMES==============
I/O Error: core dumped.
\*************************hac...@headcheese.daa.uc.edu**********************/
Rodney Grimes
>: chris
><rest deleted>
As Chris stated, more or less, no... but I am very close to haveing this
work done for the patch kit.. a new npx-0.5 will be out some time tomarrow,
..
Then next week I plan to get intr-0.0 in the patchkit..
--
Rod Grimes rgr...@agora.rain.com
386BSD patchkit coordinator Wish it paid real money!
Accurate Automation Company All opinions belong to me and my company!
Gene Stark
now I am. When the NetBSD 0.8 announcement came out I saw that many of the
patchkit people were acknowledged and I thought "Good! The patchkit will
follow NetBSD, and probably most of the active kernel hacker community on the
net will follow." This made me happy because I agree with the goal of
turning 386bsd into a stable system. But now it looks like NetBSD and
the patchkit are going to be separate forks. I predict another bifurcation
at such time if/when 386bsd 0.2 is released, because if the rumor mill is
accurate, it is going to be an experimental system with many changes, and
probably moving to that will be a giant step backwards in terms of stability.
I think many of the 386bsd users who post here don't want that.
I'd just like to send out an appeal for those who have been active in
working on 386bsd to rally 'round one version, so that the support doesn't
get too diluted. At first I thought NetBSD would be this version, but
after reading this thread it looks like I'm going to stay with the patchkit
for now.
- Gene Stark
Paul Kranenburg
One of the problems for "active workers" with 386bsd 0.2 is that one can only
wait for it and that's not what can be counted as active work. On the other
hand, any number of people working on a project of any sort at a site as
distributed as the world, is bound to lead to bifurcations at some stage. In
this particular case the split-up has only been hastened by the fact that
personal begrudgements threaten to become a main guide in the development
of an operating system. That won't do enthusiasm any good.
As to the different (more generic) name, I like the change since it hints,
if only in name, at the possibility of supporting other platforms. This will
help with keeping portability up on an acceptable level.
-pk
Remember, it's just a fork(), nobody got executed() yet.
Jan-Oliver Neumann
>INSTALLATION NOTES for NetBSD 0.8 <1.2>
Great work ! Thanks to Chris and all the others who put it together.
I'm very keen on seeing it. (I'm searching some german folks who can put
it on tape for me, I can't FTP it).
> comp08 The compiler tools set. This includes
> gcc 1.39, g++, and the full set of include
> files, libraries, and profiling tools.
> [ 2.1M gzipped, 7.9M uncompressed ]
I think it would be better having gcc 2.3.3 in there, wouldn't it? This
should be done in the next release.
>Chris G. Demetriou <c...@sun-lamp.cs.berkeley.edu>
>Adam Glass <gl...@sun-lamp.cs.berkeley.edu>
>Theo Deraadt <der...@sun-lamp.cs.berkeley.edu>
>Sean Eric Fagan <s...@kithrup.com>
>Charles Hannum <myc...@sun-lamp.cs.berkeley.edu>
>Rodney Grimes <rgr...@sun-lamp.cs.berkeley.edu>
>Chris Provenzano <pro...@sun-lamp.cs.berkeley.edu>
>Peter da Silva <p...@sun-lamp.cs.berkeley.edu>
A sixpack of virtual beer for all of them! :-)
Prost!
Jan-Oliver Neumann
--
Jan-Oliver Neumann <mave...@encap.hanse.de>
Gegen Rassismus und Extremismus ------------------- Against racism and extremism
XXXXXXXXXXXXXXXXXXXXX Kopiere mich in deine Signature XXXXXXXXXXXXXXXXXXXXXXXXXX
Charles Hannum
> 2) What exactly the diffs are between 0.1+patchkit 0.2.3 (note the 3)
> and NeTBSD
> 3) Other changes that are important.
Have you read the `CHANGES' file in the FTP directory?
--
\ / Charles Hannum, myc...@ai.mit.edu
/\ \ PGP public key available on request. MIME, AMS, NextMail accepted.
Scheme White heterosexual atheist male (WHAM) pride!
Rodney Grimes
Chris is correct, the patch kit will not converge on NetBSD, but I am currently
setting up a NetBSD source tree so I can obtain the BUG fixes that are
applicable to 386BSD + patchkit 0.2.3 for inclusion patch kit 0.2.4.
I will probably continue to do this on a regular bases so that significant
bugs that are fixed in NetBSD also get fixed in 386BSD. Note that NetBSD's
group is doing the same with each patch kit release and that both teams are
cross connected pretty will via lots of mailing lists.
>=>Also, what is to become of the FAQ? We have made serious progress on creating
>=>a new FAQ (most everyone will see the first three or four sections of it on
>=>Wednesday) and need to keep moving. Many of the questions/answer will
>=>continue to apply to both the old 386bsd (v0.1) and the new NetBSD for
>=>a while.
>true.
And I would suggest that NetBSD pick up the current FAQ and get some one to
maintain it for NetBSD. Or that the current maintainer of the FAQ if he
is going to move to NetBSD pass his current work on to some one else to
maintain it for 386BSD.
>=>The worried maintainer of somebody's FAQ, but not just sure whose!?!?
>whosever you want... probably 386BSD's, if you plan to keep it in sync with
>0.2 when it comes out...
The FAQ is based up on 386BSD0.1 + the patch kits if I am not mistaken, NetBSD
is going to diverge from this very rapidly. It would be best to chose one of
the two and continue in that direction. But also pass a copy of your work on to
some one from the other operating system to maintain it as a seperate FAQ.
>--
>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
Rodney Grimes
>In article <1993Apr20.1...@gmd.de> ve...@mururoa.gmd.de (Holger Veit) writes:
>>|> Another question is what do I do now?
>>
>>
>>I also asked the same question when I read the NetBSD announcement. Apparently
>>many people will grab the "new release of 386bsd" just because it is new.
>>What is missing is a procedure to upgrade from a src01dist+patchkit-0.2.2
>>to the new release for all persons who do not want to start from scratch.
>>Besides some reorgs of trees and splitting into separate packages the real
>>difference to src01+pk022 cannot be so extreme that an upgrade kit is impossible
>>(it just has to be done).
>One, the amount of changes from 386BSD + patchkit -> NetBSD are
>extremely large, especially in the area of configuration.
>The goals for the NetBSD group and the continuing 386BSD group are different.
Some areas of the goals are different but a lot of them are common, and
I think that the level of cooperation will help both teams produce some
very good work. I am glad I do not have to make a choice on which to run,
I am running BOTH!
>There is currently work in progress (Yeah, right, we've heard that a
>million times now) to produce an interim release of 386BSD, with Bill's
>blessing.
And again and again.. so I wont say it... :-) <chuckle>
>The purpose of this release is to make the 0.1 -> 0.2 transition easier,
>and to introduce some new code into the tree (updated software, shared
>libraries :-), better installation tools, etc..)
And a lot of the fixes from NetBSD. One of my primary goals as a 0.1.5
team member is to leverage as much of the NetBSD code that makes since
into the 0.1.5 release. This is why I am now running both 386BSD and
NetBSD at current revision.
>>The situation becomes more interesting with the release of 386bsd-0.2
>>(even if it looks as if everyone will get a grey beard until it arrives;-)).
>If I am not mistaken, (Chris, contradict me if I'm wrong), the NetBSD
>crew have no intention on running 0.2. However, this doesn't mean they
>will ignore 0.2, but instead take what they consider to be useful
>features from it (if possible), and place them into NetBSD.
And Chris stated this was so in another post.
>>In this case we have three releases people can offer patches for:
>>The 386bsd-0.1+pk0.2.*, NetBSD with its own patchkit possibly, and 386bsd-0.2.
>>In the latter case we again have the difficulty whether to drop NetBSD and
>>take the latest and best (?). Probably there will be a set of diffs to upgrade
>>NetBSD to the 0.2 level, or vice versa (?).
>Doubtful, if my statement on NetBSD is correct.
Humm yes very doubtful.
>>BTW: I just saw the announcement of pk-0.2.3, and wonder if this brings my system
>>to NetBSD.
>No, NetBSD and 386BSD are still different. Chris and his support crew have
>done a lot of VERY GOOD THINGS in NetBSD (and some things on which I disagree
>with, but that's to be expected. :-)
>Hopefully alot of these changes will be integrated into the interim release,
>but due to lack of hardware, and some miscommunication with the site hosting
>the interim release, things have not progressed as quickly as we would like.
Or at least from Nates view point that is true, from mine it is a little
different since I am in the process of culling certain work from NetBSD
and making it into patch kit patches.
>>Maybe the patchkit people and the NetBSD people (who are mainly the same
>>group)
>>comment some more about the expected future.
>I can't speak for Rod, but as a former patchkit maintainer, if we can
>get these technical problems ironed out, we are planning on still doing
>an interim release.
I can speak for Rod, or at least I think I can, and a binary release of
patch kit 0.2.3 is being worked on as I type this... it is simple a replace
ment for the bin01dist cpio files (it is actually going to be one huge
tar.z (gzip) file that I will split when I upload it from my box)
I am also working up a new set of install floppies based on some of NetBSD's
work to make installing 386BSD0.1.2.3 (that is what I am now doing with
patch kit version numbers to identify what you are running, just take the
patch kit revision, drop the leading 0 and take it on the end of the 386BSD
version) a lot easier.
>Now, right now today, Chris's release is the best thing on the market,
>and if you are a new users, I suggest using it. But, if you're happy
>with 386BSD today, Rod is going to continue to work his tail off and
>produce patchkits against 386BSD. (And there is some very nice stuff
>coming up in the next patchkit, but Rod needs to take about 2 years off
>after cranking this one out :-)
I don't know if I agree with the claim that Chris's release is the best
thing on the market, but I have no problem calling it a very good thing
on the market.
My work is gong to slow down starting tomarrow... I am going off to have
a life for a few days.. or at least I keep telling myself that..
2 years.. heck if I took that long off I would propably never come back!
>Anyway, that's the status from my end,
And some what form my end...
Gene Stark
In <GENE.93Ap...@stark.uucp> ge...@cs.sunysb.edu!stark (Gene Stark) writes:
>Arrgggh! OK, I just read this whole thread, and I wasn't upset before but
>now I am. When the NetBSD 0.8 announcement came out I saw that many of the
As to the different (more generic) name, I like the change since it hints,
if only in name, at the possibility of supporting other platforms. This will
help with keeping portability up on an acceptable level.
I like the name, too. What I would like to see happen is for the patchkit
effort and NetBSD to merge. I am guessing 386BSD 0.2 is going to be so
different that very few people are going to want to use it, so at this point
I am not really even expecting to use that if/when it comes out. Why not have
one main line "Net BSD" system to avoid dilution of effort?
--
st...@cs.sunysb.edu
Robert Withrow
| We'd like NetBSD to be a useful, stable, featureful, and
| widely-compatible operating system, and we don't want it
| to be surrounded by the "we must be different" statements
| which seem to come out of 386BSD, nor the political wars...
...curious, considering the above statement is just another salvo in
the ``political war'' of free unicies.
Am I alone in wishing we were approaching ``The Great Free Unix Unification''
rather than ``The Great Free Unix Balkinization''?
While I agree that it is asking too much of people to wait indefinately for
Bill to ``bless'' something beyond 0.1, and the (I believe technical rather
than political) problems with patchkits have turned people off, is it really
necessary for each faction to tell the others to ``piss off, well do it
our way''?
Will it be forever impossible to have a unified system that takes the
best technology from 4.4, 386bsd, netbsd, mach, and yes linux? Or
will we be forever dissipating our energies on developing twice as many
variants every year?
--
Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: wi...@rwwa.COM
R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
Joel M. Ward
here, but i see 386bsd losing lots of potential users becasue, 386bsd 0.1
'out-of-the-box' is an unstable system, and the docs that come with it
don't point you in any direction to change that.
"All you have to do is apply the latest patchkit!" you might say,
but *maybe* everyone doesn't have 300 megs to keep all the source on!
I only have 100 megs, and it has been HELL installing 386bsd (& i'm STILL
not happy with it or done with it).
Plus, i see the same questions asked over & over on the questions
newsgroup, and i NEVER see a FAQ! I keep hearing the there is a new FAQ
being readied, but I don't think this procces should be kept so secret!!
Why don't you post every question/answer when you get it written?
Why don't you post a list of questions so that people may add to it?
I *want* to write parts of the FAQ that i feel i have experience with,
but I have NO IDEA what's being done!! I don't want to waste my time writing
what's already being/going to be written! Does *anyone* agree with me
on this last point?
& I see wars going on with the Jolitz's & the main 'patchers'
(for lack of a better term), and it seems like the 'patchers' have
finally had it out and released thier own baby! More power to them!
I would rather have a stable system that I know is being worked on by
competent, interested programmers than sitting around & waiting for an
incompatible system to come along! If you are so worried about evergy
being wasted on 2 different systems, then what do think of 386bsd 0.2
throwing away all thats' been done up to now. What's to stop them from
doing the same thing in 0.3??
& finally my main point: SOMETHING IS BEING DONE!! I see
motivated people interested in helping their product be the best that
it can & give it as much support as they can! Despite all the good
intentions i read about in the 386bsd docs, I don't see any attempt to
help the end user!
I predict that NetBSD will supercede 386bsd as one of the main
free unixes. I intend to help support it (& help to work on it as well)
for the sole reason that i think it has a future. This announcement has
given me new hope when i was about to give up on 386bsd, since it
seemed mostly dead in the water unless you were already a UNIX hacker
with a HUGE hard drive :)
Uh oh, this message looks like it has all the makings of
a new flame war :) Please don't post anything unless you have something
constuctive to say. If you want to call me stupid & ignorant, go ahead,
but use Email :)
--
++Joel;
Hellmuth Michaelis
>I like the name, too. What I would like to see happen is for the patchkit
>effort and NetBSD to merge. I am guessing 386BSD 0.2 is going to be so
>different that very few people are going to want to use it, so at this point
>I am not really even expecting to use that if/when it comes out. Why not have
>one main line "Net BSD" system to avoid dilution of effort?
Yes!
I'm a bit confused, as i see it we now have 4 (F O U R) directions in which
386BSD is splitting:
1/ - 386BSD 0.1 + patchkit
2/ - 386BSD 0.1.5
3/ - NetBSD
4/ - 386BSD 0.2
1/ is running stable, we are slowly getting things done (patchkit, FAQ, etc)
but the system runs very stable now.
2/ nothing heard of it but roumors - is it 1/ patched up to the current patch-
kit or something different ?
3/ many of the well known supporters of 1/ switched to NetBSD - so 386BSD 0.1
+ pk lost their support....
4/ nothing heard of it but roumors - if it is REALLY so totally different then
perhaps few people will like it.
I would like something like 386BSD 0.1 + patchkit + shared libs + loadable
device drivers, support from EVERYONE (1/ + 2/ + 3/ + 4/) working in the
same direction of getting a stable (!), standardized (POSIX) operating system
which is not only good for just being an operating system but also for providing
a base for some "real world applications".
If we had 2 directions (one stable release for "work" and one not-so-stable
release for "playing" where getting stable features slowly migrate from play
to work) it would be more understandable.
I can imagine nothing good from splitting up in 4 directions, 4 patchkits,
4 FAQ's, 4 serial drivers, 4 refrigerator drivers, 4 news hierarchies,
5 types of postings "which is the best OS?", and, and, and ...
I would really like everyone is pulling at the same end of the rope.
Why is'nt it possible to unite?
Proposal: - merge 0.1.5 and NetBSD into "one" NetBSD.
- provide a patchkit which will people allow to move
from 0.1 + pk to NetBSD
- stop any support for 386BSD 0.1
After this we would have Chris + friends working on the stable, working
side of 386BSD, being very present and responsive and responsible for
the production version with patches, FAQ's etc, on the other side would
be 0.2 as a new (incompatibe?) way of an operating system experiment
to try out new roads.
I'm really not knowing whats going on behind the curtain, but the more
this OS is splitting up, the more it will become unimportant.
I have the feeling, that all we need is a bit more "official" support -
there is no need for weekly releases but there is a need for coordination,
representation, and "publicity".
As far as i see it, we should learn from Linus being very present in the
linux newgroups, everyone reading it knows about the current status of
linux, whats going on, who's working on what, when to expect the next
release and what it contains.
Noone knows what's coming with 0.2, Bill & Lynne are very seldom seen
in this newsgroup tree (this is NO flame, Bill & Lynne!) so a newcomer
(and not only they) get the feeling that noone cares about the direction
386BSD is going. What is needed is someone or a group of people who is
"seen" by everyone and who is responsible for a direction and for coordination.
And Chris + friends are much more "seeable" than the creators of 386BSD.
On the other side it is good to have some motion in the arena, many people
stopped work an all sorts of projects because 0.2 was supposed to come
but never came, not even informations if it ever comes or not.
still confused,
hellmuth
--
hellmuth michaelis HCS Hanseatischer Computerservice GmbH hamburg, europe
h...@hcshh.hcs.de tel: +49/40/55903-170 fax: +49/40/5591486
Allen `Xext' Briggs
>I would like something like 386BSD 0.1 + patchkit + shared libs + loadable
>device drivers, support from EVERYONE (1/ + 2/ + 3/ + 4/) working in the
>same direction of getting a stable (!), standardized (POSIX) operating
>system which is not only good for just being an operating system but also
>for providing a base for some "real world applications".
I think a reminder is probably in order. The Jolitz' appear to be
sticking to the CSRG release system. The CSRG tended to release even
numbered releases with new ideas/experiments/innovations/bugs. Odd
numbered releases tended to be stable, bug-fixing releases.
Everyone would like a stable system. Kernel hackers live with unstable
systems, but I don't think anyone *likes* living with them.
There are some good reasons for revamping the kernel interfaces now as
opposed to five years from now. There are some good reasons for not
doing so.
My favorite plan would be to have several groups working together. The
NetBSD group states that they plan to integrate patches from the patch
kit. I might have been hallucinating, but I think I saw someone else
planning to make sure that the NetBSD enhancements will be put into the
patch kit.
0.2 is a somewhat different entity in that many of its changes sound
like they will not be very compatible with 0.1. I beleive Chris
mentioned in his announcement that NetBSD would pick pieces from 0.2
after it's available. Following the assumptions in the previous
paragraphs, these will bring the 0.1+pk and NetBSD paths converging
with 0._3_ (stable 0.2) when that's available. The process then starts
anew as 0.4 starts exploring new ground.
This kind of development has great potential to produce a very rich
system. I concur with Hellmuth, though, that it needs some coherency,
and at least a couple of consistent, visible, organizers for it to
work. Hopefully MacBSD can be integrated into this whole process, too
(E-mail for FAQ on MacBSD, such as it is :).
-allen
--
Allen Briggs \ Swift has sailed into his rest;/Savage indignation
bri...@csugrad.cs.vt.edu | there/Cannot lacerate his breast./Imitate him
- end / if you dare,/World-besotted traveller; he/
killing - / Served human liberty. -- W.B.Yeats, 1931
brian d. carlstrom
Hopefully MacBSD can be integrated into this whole process, too
(E-mail for FAQ on MacBSD, such as it is :).
since the announcement i have received email about the possibility of
getting a 68kbsd going again, for the apollo specifically. i assume a
macBSD group would be slight related, given the motorola in common.
i have volunteered (been suckered) to set up a list for interested
apollo hackers. i am not as familiar with apollo hardware, but given
that it uses an ISA bus, at least some 386bsd code could be used,
although i realize its graphics card is atypical.
so all you people with APOLLO's interested in at least joining in some
talk please email me, and i'll set up some kind of list. there are
apparently people with apollo boot code and graphics routines already
done, but i have lost track of who these parties are. pointers
appreciated to these people!
-bri
--
Brian D. Carlstrom b...@mit.edu
Programmer and System Administrator
M.I.T. Flight Transportation Laboratry
Nate Williams
>386BSD is splitting:
>
> 1/ - 386BSD 0.1 + patchkit
> 2/ - 386BSD 0.1.5
> 3/ - NetBSD
> 4/ - 386BSD 0.2
>
>1/ is running stable, we are slowly getting things done (patchkit, FAQ, etc)
> but the system runs very stable now.
The current status of three of the directions are as follows:
386BSD 0.1 + patchkit == 386BSD 0.1.5 => 386BSD 0.2
It is the absolute intention of the 0.1.5 team (all former/current patchkit
maintainers plus others), to have 0.1.5 be the entire patchkit, new install
tools, updated software (groff, gcc, shared libs). One of the goals of the
0.1.5 effort is to make the 0.1 -> 0.2 transition easier. This interim
release has the "Blessing" of Bill.
>3/ many of the well known supporters of 1/ switched to NetBSD - so 386BSD 0.1
> + pk lost their support....
>
>4/ nothing heard of it but roumors - if it is REALLY so totally different then
> perhaps few people will like it.
>
>I would like something like 386BSD 0.1 + patchkit + shared libs + loadable
>device drivers, support from EVERYONE (1/ + 2/ + 3/ + 4/) working in the
>same direction of getting a stable (!), standardized (POSIX) operating system
>which is not only good for just being an operating system but also for providing
>a base for some "real world applications".
NetBSD + 386BSD have those goals in mind, but the NetBSD group has no intention
on running 0.2, while the 386BSD group has the intention of moving towards
0.2. Until 0.2 is released, most of the fixes in one will apply directly to
the other. However, because 0.1 was a step towards 0.2, the NetBSD folks
are removing some of those 'features/bugs' from 0.1 and making it look more
like 4.3BSD.
>If we had 2 directions (one stable release for "work" and one not-so-stable
>release for "playing" where getting stable features slowly migrate from play
>to work) it would be more understandable.
>
If I understand Rod correctly, it is his goal to take the stable patches
out of ANY work that ANYONE does and apply them to the patchkit. Currently,
Chris is planning on doing a different scheme for patching that IS NOT the
patchkit, so at this time Rod's work is DIRECTLY appliable to 386BSD as you
all know it. However, the NetBSD folks will take Rod's work (if it wasn't
from them), and integrate it into NetBSD. It's a win for everyone.
As a matter of fact, I know that most of the patchkit stuff is already in
the current NetBSD sources. Everyone wins.
>Proposal: - merge 0.1.5 and NetBSD into "one" NetBSD.
> - provide a patchkit which will people allow to move
> from 0.1 + pk to NetBSD
> - stop any support for 386BSD 0.1
Problem: Differing goals with regard to 0.2.
If Chris wants to provide a set of patches to move from 386BSD to the
patchkit, so be it. But Rod is going to be hard to keep up with, since
he is already cranking out the next version of the patchkit. :-)
There are already MAJOR differences in the configuration mechanism between
386BSD and NetBSD.
>
>I have the feeling, that all we need is a bit more "official" support -
>there is no need for weekly releases but there is a need for coordination,
>representation, and "publicity".
All of this is volunteer work. No one gets paid to do it. My grades
have suffered, my wife has complained, but I do this for fun. You can't
expect anything more from people. You aren't going to get anything
'official' from anyone unless you see $$ start flowing.
>
>As far as i see it, we should learn from Linus being very present in the
>linux newgroups, everyone reading it knows about the current status of
>linux, whats going on, who's working on what, when to expect the next
>release and what it contains.
Linus doesn't say much of anything about what's in the next release until
it is announced.
> What is needed is someone or a group of people who is "seen" by everyone
> and who is responsible for a direction and for coordination. And Chris +
> friends are much more "seeable" than the creators of 386BSD.
You can 'force' anyone to act in a direction. This is a free O.S., intended
for research. However, if you have the same goals as someone else, then
send them some email and see if they want some help. Beyond that, that's
all you can do.
In the meantime, I will continue to push towards the goals I see needed,
which a large part of is the interim release.
If you are interested in the interim release, send me some email and we
can talk.
Address for interim release:
Joel M. Ward
Sorry to those who were offended. :)
Okay, i had intended to put together a 0.1.23 release of 386bsd
(0.1 + .2.3 patchkit) so it would not be necessary for new users to have
to deal (or even know about) patches... that was right before Chris made
his netBSD annoucement. It looks to me like he's already done that, mostly.
Now the choice I have is whether to work on 386bsd or netBSD. The
main difference between them at this point is whether or not you want to
be compatible with 386bsd 0.2.
It seems like we're missing some data here. What exactly will
0.2 do?? what will be the advantages? we already know there will probably
some disadvantages like incompatibilities (i know people are trying to
avoid this, but it is inevitable), but without this sort of information
making a choice seems like flipping a coin.
NetBSD has a big advantage at this point in my mind with the
patches already installed (is 0.2.3 the latest? If so, Chris is only 1
version behind) plus a better install program (i hear). It is far easier
to install NetBSD as a new system than 386bsd.
I am leaning towards NetBSD right now, (i have some cool ideas for
the install program, & some other stuff). It seems like any work i do
on NetBSD will be quickly integrated if it is useful, while if i do any
work on 386bsd, it will be yet another patch scattered among the net that
people can use if they choose.
NetBSD seems like it will approach a 'user friendly' state faster
than 386bsd. Like, if i want Linux, i can read up on it & install it.
If i want 386bsd, i have to get it, install it, get the source, get the
patchkit, patch it, rebuild it, and hope i don't get too confused along
the way.
Plus, since Chris intends to pick & choose the best of 0.2, it
seems as though it will retain the 'lead' so to speak.
All i am trying to say is that if 0.2 doesn't come out soon, I think NetBSD
will soon outstrip 386bsd as a easier to install, more up to date OS.
well, i think i'm done rambling now :)
--
++Joel;
Joel M. Ward
straight UNIX. wouldn't that be a problem for X support?
or maybe not, i don't know too much about macs or internal X stuff...
--
++Joel;
Nate Williams
>
>
> Okay, i had intended to put together a 0.1.23 release of 386bsd
>(0.1 + .2.3 patchkit) so it would not be necessary for new users to have
>to deal (or even know about) patches... that was right before Chris made
>his netBSD annoucement. It looks to me like he's already done that, mostly.
NetBSD is 0.1.23 release, plus a little less, and a lot more.
> Now the choice I have is whether to work on 386bsd or netBSD. The
>main difference between them at this point is whether or not you want to
>be compatible with 386bsd 0.2.
Technically, I think it will boil down to that in the long run. One or
the other may have features the other one doesn't for awhile, but if
they are good features, sooner or later they will both get them.
> It seems like we're missing some data here. What exactly will
>0.2 do?? what will be the advantages? we already know there will probably
>some disadvantages like incompatibilities (i know people are trying to
>avoid this, but it is inevitable), but without this sort of information
>making a choice seems like flipping a coin.
One of the BIG (BIG!) advantages of 0.2 is that Bill has completely re-
written the VM system to avoid the stupid 'lockup when under heavy load'
problem due to limited memory. Also, there is supposedly a unified
VM and buffer cache (similar to Linux), so that your buffer cache can
grow and shrink with the amount of available memory. I have also heard
that the machine is much more 'configurable' on the fly.
> NetBSD has a big advantage at this point in my mind with the
>patches already installed (is 0.2.3 the latest? If so, Chris is only 1
>version behind) plus a better install program (i hear). It is far easier
>to install NetBSD as a new system than 386bsd.
Agreed, but the interim release group (an announcement will be made
soon) also has access to this same install program. I looked at it, and
it is very good to know what's going on with install finally, but as
folks have been stating in other posts, there is still some work to be
done.
> I am leaning towards NetBSD right now, (i have some cool ideas for
>the install program, & some other stuff). It seems like any work i do
>on NetBSD will be quickly integrated if it is useful, while if i do any
>work on 386bsd, it will be yet another patch scattered among the net that
>people can use if they choose.
If you want your patch to get integrated into BOTH versions, send it to
our friendly neighberhood neutral patchkit co-ordinator, Rodney Grimes.
Instructions on how to submit patches (which end up on both a interim
machine and the host machine for NetBSD) are included in the newest
patchkit.
> NetBSD seems like it will approach a 'user friendly' state faster
>than 386bsd. Like, if i want Linux, i can read up on it & install it.
>If i want 386bsd, i have to get it, install it, get the source, get the
>patchkit, patch it, rebuild it, and hope i don't get too confused along
>the way.
Hopefully, that will change. But as I've stated in the past, lots of
people have said 'soon', and nothing has come out of it.
> Plus, since Chris intends to pick & choose the best of 0.2, it
>seems as though it will retain the 'lead' so to speak.
>
It's a matter of opinion. If 0.2 is such a large difference from 386BSD,
it may take awhile for the NetBSD crew to integrate the stuff in, if it
is even possible.
>All i am trying to say is that if 0.2 doesn't come out soon, I think NetBSD
>will soon outstrip 386bsd as a easier to install, more up to date OS.
NetBSD is *right now* an easier to install, more up to date OS. Same as
the MCC Interim Release is today more up to date, and easier to install
than the current SLS release, but that may change tomorrow. (Besides,
Peter gets $$ to do the SLS releases, which is a better motivator. :-)
Joel M. Ward
interim release (if i understand him correctly), and the post with
Lynne's comments, the issue becomes ever more confusing.
Until 386bsd 2.0 comes out, we still have essentially ONE
OS here. 386bsd 0.15 & NetBSD, despite all the opinions & all, are
both based off of 386bsd 0.1 + the patchkit. The differences are more
philosophical than anything else at this point.
Let's say i write The Great American Install Program. & let's
say that it works with NetBSD. Well, there's absolutely *nothing*
preventing the interim relase people from snagging it & putting it
in thier copy. In fact, they would be stupid not to, if it was a
superior program.
So at this point, it's six of one, 1/2 dozen of the other.
I am going to install NetBSD becasue it's easier to install & more up
to date. I can always change over to 386bsd 0.2 when the time comes.
Regarding Lynne's comments: If i interpret them correctly,
the 0.2 release is almost ready. I see the comment about 'finishing
touches' to mean that B&J have put extensive work into making sure
that this release is stable. And with the new memory manager & all,
it might just be the way to go. & then again maybe not.
Until it comes out, we just don't know.
It is easy to get polorized ont his issue, but the way i see
it now, it's just shades of grey. Two, specifically, and they're
mostly the same shade.
Maybe it's even possible to merge the releases again. When
0.2 come out, let's say it just sucks. Then NetBSD will probably become
the dominant breed. Or maybe 0.2 will be totally superior, and NetBSD
will fall aside as a good idea whose time has come & gone. Probably
bith sides will have pros & cons...
I've seen posts about MacBSD & 68BSD. Maybe we can get together
with them too, and make an OmniBSD :)
--
++Joel;
Warren Stevens
> I predict another bifurcation
>at such time if/when 386bsd 0.2 is released, because if the rumor mill is
They're trying to generate fractal distrbution trees. :)
W
--
"An anthropologist at Tulane has just come back from a field trip to New
Guinea with reports of a tribe so primitive that they have Tide but not new
Tide with lemon-fresh Borax." -- David Letterman
brian d. carlstrom
i was addressing the graphics system of the apollo and is important
because there is no character mode. you have to start off drawing the
characters in graphics mode right away. i think there mught be hope of
using the X11R5 apollo distibution since it is based on the apollo BSD
enviroment, but i can say for sure.
i have received a lot of encourageing mail from people that have
successfully made book blocks and graphics code for the apollo, and am
currently get a list setup (sorry for the delay) and will post the
information i recevied so far to this.
Gary Roberts
>
> [much sensible stuff deleted]
>
>I would really like everyone is pulling at the same end of the rope.
>Why is'nt it possible to unite?
>Proposal: - merge 0.1.5 and NetBSD into "one" NetBSD.
> - provide a patchkit which will people allow to move
> from 0.1 + pk to NetBSD
> - stop any support for 386BSD 0.1
YES, YES, YES!!!
Splitting into multiple (and diverging) streams must surely lead to
reduction of useful output, slowing of development, disenchantment of
the user population out there and the risk of ultimate annihilation.
The majority of 386BSD users want a stable and productive environment
without the politics, the flame-wars, the endless "this *nix is better
than that *nix because I sez so" arguments. We users appreciate the
work of the wizards in putting together patch-kits and archives of
ported software, etc. Even although Rod Grimes has stated that he
will be running both systems and extracting the best from both for the
benefit of the users, there must surely be a limit to how much he can do.
>After this we would have Chris + friends working on the stable, working
>side of 386BSD, being very present and responsive and responsible for
>the production version with patches, FAQ's etc, on the other side would
>be 0.2 as a new (incompatibe?) way of an operating system experiment
>to try out new roads.
Sounds great to me!! The goals stated by Chris & Co are exactly my goals.
I have been using 386BSD for about four months now and am very grateful
for the work done by people like Terry, Nate, Chris, Julian, Charles
Hannum, Jordan Hubbard, Rod Grimes, and many others too numerous to
mention, as well as the original developers of 386BSD. I wish the Jolitz's
well with the development of 0.2 but that development seems to portend a
radical change in direction and is thus not really of interest to me at
this stage. My aim is to duplicate my work environment (Sparcstation +
SunOS 4.1.3 + OpenLook) on a 486 Notebook PC. In fact with what I now have
(Notebook + Docking station + 16M + 325M + 386bsd-0.1.2.3 + XFree86-1.2)
I reckon my "portable" environment is better than my work environment.
My fear is that the current apparent divergence of effort will lead to
much more chaos and misunderstanding out here in user-land.
We users are really grateful for the tireless efforts of those who
contribute to the stability and usefulness of *all* PC *nixes. We rely
on the freely given work of many gurus and we hate to see what appears
to be the first signs of disintegration. My fervent hope is that just
one 386BSD/NetBSD stream will emerge with everyone pulling in the same
direction. It would seem that if those working on 386BSD-0.1.5 could
join with the NetBSD folks and if the great Rod Grimes could unite
everything patchkitwise, we would have the best possible situation.
That way the 0.2 developers could work in the background at their own
pace and according to their own timetable, whilst the vast majority of
average users, like myself, could continue to enjoy what is really a
beautiful (and stable!!) operating system.
>
> [still more good stuff deleted]
>
>still confused,
>hellmuth
>--
>hellmuth michaelis HCS Hanseatischer Computerservice GmbH hamburg, europe
>h...@hcshh.hcs.de tel: +49/40/55903-170 fax: +49/40/5591486
Confused, YES, but very sad also.
Cheers,
--
Gary Roberts | Ph: +617-3654176
Mining & Met Engineering | Fax: +617-3654377
University of Queensland | Internet: ga...@minmet.uq.oz.au
Brisbane. 4072 AUSTRALIA |
Peter da Silva
> + pk lost their support....
Not at all. The patchkit and NetBSD are working together.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' Har du kramat din varg idag?
'U`
My Apple-II has more RAM than my Mac!
Theo de Raadt
> sticking to the CSRG release system. The CSRG tended to release even
> numbered releases with new ideas/experiments/innovations/bugs. Odd
> numbered releases tended to be stable, bug-fixing releases.
This is irrelevant, misleading, etc. The CSRG works cooperatively with
many people, not in a vacuum, but the Jolitz' obviously want to.
> Everyone would like a stable system. Kernel hackers live with unstable
> systems, but I don't think anyone *likes* living with them.
>
> There are some good reasons for revamping the kernel interfaces now as
> opposed to five years from now. There are some good reasons for not
> doing so.
I'm a kernel person. I don't see any reason to revamp stuff.
> 0.2 is a somewhat different entity in that many of its changes sound
> like they will not be very compatible with 0.1. I beleive Chris
> mentioned in his announcement that NetBSD would pick pieces from 0.2
> after it's available. Following the assumptions in the previous
> paragraphs, these will bring the 0.1+pk and NetBSD paths converging
> with 0._3_ (stable 0.2) when that's available. The process then starts
> anew as 0.4 starts exploring new ground.
What a wonderful plan. It gives people a useable and stable operating
386BSD operating system around the turn of the century.
> This kind of development has great potential to produce a very rich
> system. I concur with Hellmuth, though, that it needs some coherency,
> and at least a couple of consistent, visible, organizers for it to
> work. Hopefully MacBSD can be integrated into this whole process, too
> (E-mail for FAQ on MacBSD, such as it is :).
A very rich system inconsistant with many of the ways that standard BSD
unix works, it appears.
<tdr.
--
This space not left unintentionally unblank. der...@fsa.ca
Robert Withrow
| I'm a kernel person. I don't see any reason to revamp stuff.
So am I, and I do.
De gustibus and all that.
Herb Peyerl
: seems like the graphic system shouldn't matter too much for just
: straight UNIX. wouldn't that be a problem for X support?
: or maybe not, i don't know too much about macs or internal X stuff...
The assumption you're making is that Apollo cards are just like PC cards
where you can tell them to put a character on the screen and they will.
This is a bad assumption. Apollo display cards are raster cards and
so you have to manually draw each pixel. (essentially; actually you
blit them line by line but whatever...)
So; if you wanna see letters on the screen then you have to do graphics
operations.. The cards were designed to do graphics in the first place
as opposed to PC's where graphics capabilities was a kludge that no one
has really fixed...
--
"I was early to finish | hpe...@novatel.cuc.ab.ca <Reply-To> | I brew |
I was late to start, I | pey...@cuug.ab.ca | there- |
might be an adult, but | #define JANITOR "Network Anal-yst" | fore I |
I'm a minor at heart." | JANITOR, NovAtel Communications Ltd.| AM. |
Herb Peyerl
: i was addressing the graphics system of the apollo and is important
: because there is no character mode. you have to start off drawing the
: characters in graphics mode right away. i think there mught be hope of
: using the X11R5 apollo distibution since it is based on the apollo BSD
: enviroment, but i can say for sure.
Not! The Apollo X11R5 server is based on gpr_$xxxx calls which is going
to be useless for netbsd0.x... I'll continue the graphics stuff but I'm
NOT going to do a /usr/lib/libgpr.a and a /usr/lib/libctm.a!
Allen `Xext' Briggs
>In article <1r8qnp$1...@csugrad.cs.vt.edu> bri...@csugrad.cs.vt.edu (Allen `Xext' Briggs) writes:
>> The Jolitz' appear to be sticking to the CSRG release system.
>
>many people, not in a vacuum, but the Jolitz' obviously want to.
It's not obvious to me. From what I've seen, they haven't been working
in any more of a vacuum than anyone swamped with work. They're working
hard on both "386BSD" 0.2 and "regular" jobs. Just about every post
from Lynne says that they're too busy to keep up with usenet news.
Working away from usenet does not constitute working in a vacuum.
>> There are some good reasons for revamping the kernel interfaces now as
>> opposed to five years from now.
>
>I'm a kernel person. I don't see any reason to revamp stuff.
Oh, really? Have you tried being a kernel person on multiprocessor
machines? Haven't you seen problems with the current kernel device
driver support? Have you considered portability to other platforms?
How about dynamically loadable device drivers? I'd much rather have
a kernel that was designed for them rather than kludging them in.
>> 0.2 is a somewhat different entity in that many of its changes sound
>> like they will not be very compatible with 0.1. I beleive Chris
>> mentioned in his announcement that NetBSD would pick pieces from 0.2
>> after it's available. Following the assumptions in the previous
>> paragraphs, these will bring the 0.1+pk and NetBSD paths converging
>> with 0._3_ (stable 0.2) when that's available. The process then starts
>> anew as 0.4 starts exploring new ground.
>
>What a wonderful plan. It gives people a useable and stable operating
>386BSD operating system around the turn of the century.
You're welcome to your opinions. What makes you think it'll take that
long?
>A very rich system inconsistant with many of the ways that standard BSD
>unix works, it appears.
What version of BSD are you considering to be "standard?" Is not one of
BSD's features that it evolves to meet the computing community's needs,
not the marketing wizard's?
It would be useful to have more net.input into what features are
important to work on, and there is a lot of development talent on
the net that could be applied toward achieving those features.
This seems to be where NetBSD comes in--it's much more net.driven,
and has a host of people working on it, directly or indirectly.
BSD 0.2 may suffer from the lack of net.input. NetBSD may suffer from
too much. Both have advantages and disadvantages. We'll see better
what those are when 0.2 is released. Wasn't it supposed to be around
March of this year???
Andreas Klemm
|In <GENE.93Ap...@stark.uucp> ge...@cs.sunysb.edu!stark (Gene Stark) writes:
|Proposal: - merge 0.1.5 and NetBSD into "one" NetBSD.
| - provide a patchkit which will people allow to move
| from 0.1 + pk to NetBSD
| - stop any support for 386BSD 0.1
That would be the best !!!!!!!!!!!!!!!!!!
o Let the NetBSD people integrate the latest stuff from the patchkit
into NetBSD.
o Then let's work together as supposed by Nate Williams
(one of his plans for 386BSD 0.1.5) on upgrading
every utility to the latest patchlevel.
o Finally release an unique BSD ==> NetBSD 0.9
Now I'd like to ask the NetBSD's and 386BSD's authorities ...
Would it be possible to merge 386bsd 0.1.5 and NetBSD 0.8
to a single improved NetBSD 0.9 ??????
Andreas
--
////// Andreas Klemm \\\\\\ /////// and...@knobel.GUN.de \\\\\\\
private : +49 2137 12609 D-4040 Neuss 21 (Norf), Germany
at work : +49 2173 3964 161 Wiechers & Partner Datentechnik GmbH
Telefax : +49 2173 3964 222 Abteilung Unix Support, D-4019 Monheim
Andreas Klemm
|In article <21...@hcshh.hcs.de> h...@hcshh.hcs.de (Hellmuth Michaelis) writes:
|>Proposal: - merge 0.1.5 and NetBSD into "one" NetBSD.
|> - provide a patchkit which will people allow to move
|> from 0.1 + pk to NetBSD
|> - stop any support for 386BSD 0.1
|Problem: Differing goals with regard to 0.2.
Ok, but what about going together until 0.2 ?! After that
you have 0.1.x and 0.2.x. Not so bad as 4 different releases.
Holger Veit
|> In <21...@hcshh.hcs.de> h...@hcshh.hcs.de (Hellmuth Michaelis) writes:
|>
|> |In <GENE.93Ap...@stark.uucp> ge...@cs.sunysb.edu!stark (Gene Stark) writes:
|>
|> |Proposal: - merge 0.1.5 and NetBSD into "one" NetBSD.
|> | - provide a patchkit which will people allow to move
|> | from 0.1 + pk to NetBSD
|> | - stop any support for 386BSD 0.1
|>
|> That would be the best !!!!!!!!!!!!!!!!!!
|>
|> o Let the NetBSD people integrate the latest stuff from the patchkit
|> into NetBSD.
|> o Then let's work together as supposed by Nate Williams
|> (one of his plans for 386BSD 0.1.5) on upgrading
|> every utility to the latest patchlevel.
|> o Finally release an unique BSD ==> NetBSD 0.9
|>
|> Now I'd like to ask the NetBSD's and 386BSD's authorities ...
|>
|> Would it be possible to merge 386bsd 0.1.5 and NetBSD 0.8
|> to a single improved NetBSD 0.9 ??????
This is an illusion. 386bsd and the upcoming NetBSD have different goals.
NetBSD wants to become a PD UNIX like Linux, and will sooner or later
include things (like code under GPL) which makes it uninteresting for
commercial organisations. The 386bsd won't adopt GPL-restricted code
for reasons that have been discussed for a long time. Whether or
not 0.1.5 will ever exist or whether the NetBSD people will integrate
parts of the patchkit or code from future 386bsd-0.2 is irrelevant;
the diverging of NetBSD-X.Y and 386bsd-A.B won't go away any more
unless one of them will die out which is something I doubt will happen.
Holger
|>
|>
|> Andreas
|> --
|> ////// Andreas Klemm \\\\\\ /////// and...@knobel.GUN.de \\\\\\\
|> private : +49 2137 12609 D-4040 Neuss 21 (Norf), Germany
|> at work : +49 2173 3964 161 Wiechers & Partner Datentechnik GmbH
|> Telefax : +49 2173 3964 222 Abteilung Unix Support, D-4019 Monheim
--
Dr. Holger Veit | INTERNET: Holge...@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions
Chris G. Demetriou
>This is an illusion. 386bsd and the upcoming NetBSD have different goals.
>NetBSD wants to become a PD UNIX like Linux, and will sooner or later
>include things (like code under GPL) which makes it uninteresting for
>commercial organisations. The 386bsd won't adopt GPL-restricted code
>for reasons that have been discussed for a long time.
hmm, i guess i'm going to have to talk to myself more often,
because i certainly never told myself about this! 9-)
NetBSD has the same attitude toward GPL'd code as does 386bsd,
and perhaps even a stronger one.
As long as i'm in "control" of NetBSD, there will be:
(1) No GPL'd code in the kernel
(2) No GPL'd code in libc
(3) GPL'd code added to the standard tree only
where no adequate free replacement is presented.
examples of the latter are currently limited to:
195 [sun-lamp] gnu % pwd
/usr/src/gnu
196 [sun-lamp] gnu % ls *
Makefile
CVS:
Entries Repository
games:
CVS/ Makefile Makefile.inc chess/
lib:
CVS/ Makefile libg++/ regex-0.12/
libexec:
CVS/ Makefile Makefile.inc uucp/
usr.bin:
CVS/ diff/ gas/ gzip-1.0.7/ tar/
Makefile diff3/ gcc/ ld/
Makefile.inc egrep/ gdb/ lex/
awk/ fgrep/ grep/ pr/
bc-1.02/ g++/ groff/ sort/
you might note that a number of utils which were in 386bsd's
main source tree have been replaced with non-GPL'd equivalents,
a the GPL'd sources have been segregated from the rest of
the sources, and exactly two new items have been added:
regex-0.12
gzip-1.0.7
(bc was in the distribution, is necessary to build
the distribution, the binary was shipped with 386bsd's
bindist, but the src was in etcdist...)
the former is because i couldn't find a posix regexp library
(actually, this may no longer be necessary...), and the latter
is there because in terms of performance, it absolutely
destroys compress, and size is very important when
shipping a distribution...
Please, Holger, don't speak for the NetBSD group,
and *everybody* if you've got questions/comments, mail
them, and preferably to the mailing lists listed
in the NetBSD installation notes, because none of
us really have time to read news any more...
chris
who's unfortunately got a 400+-piece queue of mail, too...
Peter da Silva
> include things (like code under GPL) which makes it uninteresting for
> commercial organisations.
What makes you think that? The NetBSD folks are systematically isolating
and removing GPL code where possible. Please don't dump this sort of
unfounded speculation in as if it were a fact.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' Har du kramat din varg idag?
'U`
"Det er min ledsager, det er ikke drikkepenge."
Pete Chown
NetBSD has the same attitude toward GPL'd code as does 386bsd,
and perhaps even a stronger one.
As long as i'm in "control" of NetBSD, there will be:
(1) No GPL'd code in the kernel
(2) No GPL'd code in libc
(3) GPL'd code added to the standard tree only
where no adequate free replacement is presented.
I think this is a shame. To my mind there is no gain in producing a
free operating system for other people to make money out of.
Another, perhaps more important, point is that some of the things
supplied with ***BSD are of low quality, and better alternatives
exist. The reason these alternatives are not used is because they are
under the GPL. I give two examples:
1. The include files seem confused, although the situation has
improved rather of late. Particular problems are experienced when you
try to work with a new version of gcc that has some of its own include
files - the number of clashes are quite surprising. But we can't use
glibc, or the Linux libc, both of which are much better because they
are under the GPL.
2. The DBM library seems most peculiar. Linking programs to it often
seems to give link errors due to non-existent routines.
I don't see what the problem is with the libraries. All the GNU
libraries are under the library GPL, so they can't "infect" other
programs just by them being linked with them.
Perhaps I should start assembling a kit of GNU software that you can
add to your 386BSD implementation...
--
---------------------------------------------+ "A tight hat can be stretched.
Pete Chown, pc...@phx.cam.ac.uk (Internet) | First damp the head with steam
pc...@uk.ac.cam.phx (Janet :-) -+ from a boiling kettle."
Sean Eric Fagan
>1. The include files seem confused, although the situation has
>improved rather of late. Particular problems are experienced when you
>try to work with a new version of gcc that has some of its own include
>files - the number of clashes are quite surprising. But we can't use
>glibc, or the Linux libc, both of which are much better because they
>are under the GPL.
Wrong. The problem is with gcc. The net/2 (and, thus, 386bsd, netbsd,
bsd/386, and 4.4bsd) header files are most certainly *NOT* confused. In
general, in fact, I'd say not to use any of gcc's header files on a net/2-
derived system at all -- gcc's header files are a mishmash hacked to work
on many, many systems.
In addition, glibc, and the Linux libc, are not better "because they are
under the GPL." They are better despite being GPL'd: many, many fine
and talented programmers will not work on GPL'd library code, or, if they
do, they do so reluctantly. Other people have had to write their own
libraries because they could not use GPL'd code, and, thus, they concentrate
all their efforts on their own -- when they might have shared their code
if they'd started from, say, Net/2's libc. (That's assuming Linux' libc
is better; I do not believe it is, personally, nor glibc.)
>2. The DBM library seems most peculiar. Linking programs to it often
>seems to give link errors due to non-existent routines.
You mean like dbm_open et al? It took me ten minutes to write wrappers for
these functions. The compatable routines were, apparantly, deliberately
not included in Net/2, for reasons I don't really understand :). I've
posted dbm(3) wrappers that used ndbm(3) routines, which, in Net/2, just
call various db(3) routines.
>I don't see what the problem is with the libraries. All the GNU
>libraries are under the library GPL, so they can't "infect" other
>programs just by them being linked with them.
1. I can make a case that the LGPL buys one nothing over the GPL.
2. Embedded applications still cannot use LGPL'd code.
3. Lots of people object to the GPL on purely philosophical and
political terms. Just because you cannot understand them does not invalidate
them, any more than their beliefs invalidate the FSF.
fis...@ivy.dt.navy.mil
those same people not use any GNU software to be consistant? Such
as gcc?
-steve
Charles Hannum
The flaw in this logic should be obvious.
In article <1s8d6k...@dtix.dt.navy.mil> fis...@ivy.dt.navy.mil
writes:
>
> Question: Since so many 386BSD people are against the GPL, shouldn't
> those same people not use any GNU software to be consistant? Such as
> gcc?
Question: Since so many GPL supporters are against non-GPL software,
shouldn't those same people not use any non-GPL software to be
consistent? Such as Unix, X, DOS, or most everything else?
A computer is a *tool*. My principle is to use the best tool available
to me for a reasonable exchange. I also provide tools for others. I
do *not* try to make a political statement about socialism through
software.
--
\ / Charles Hannum, myc...@ai.mit.edu
/\ \ PGP public key available on request. MIME, AMS, NextMail accepted.
Scheme White heterosexual atheist male (WHAM) pride!
Larry Granroth
: In article <1993May4.0...@gmd.de> ve...@mururoa.gmd.de (Holger Veit) writes:
: >This is an illusion. 386bsd and the upcoming NetBSD have different goals.
: >NetBSD wants to become a PD UNIX like Linux, and will sooner or later
: >include things (like code under GPL) which makes it uninteresting for
: >commercial organisations. The 386bsd won't adopt GPL-restricted code
: >for reasons that have been discussed for a long time.
: NetBSD has the same attitude toward GPL'd code as does 386bsd,
: and perhaps even a stronger one.
: As long as i'm in "control" of NetBSD, there will be:
: (1) No GPL'd code in the kernel
: (2) No GPL'd code in libc
: (3) GPL'd code added to the standard tree only
: where no adequate free replacement is presented.
. . .
: Please, Holger, don't speak for the NetBSD group,
: and *everybody* if you've got questions/comments, mail
: them, and preferably to the mailing lists listed
: in the NetBSD installation notes, because none of
: us really have time to read news any more...
First let me say that I applaud Chris' efforts in the NetBSD development
and respect any decisions he makes with respect to GPL'd code.
Second let me say that I'm a strong advocate of GNU products.
If Holger or anyone else would like to produce a GNUified NetBSD (gnuBSD
(not GNUBSD)) I would be thrilled. Frankly, I had hoped that NetBSD
was taking the course described by Professor Veit above.
(For those who feel swayed by the mostly straw-man propaganda against
the GPL and LGPL, please obtain a copy and read them.
gnu.misc.discuss would be the appropriate place to discuss these
documents or even suggest modifications that might help promote the
FSF's clear intentions.)
Pete Chown
subject because I wanted to suggest setting up an archive of ported
GNU software for those who didn't mind the GPL. I would welcome
feedback on this, since I might do it if people think it's a good
idea.
So I will only reply briefly to what follows:
In article <C6J0w...@kithrup.com> s...@kithrup.com (Sean Eric Fagan) writes:
In article <PC123.93M...@bootes.cus.cam.ac.uk> pc...@cus.cam.ac.uk (Pete Chown) writes:
>1. The include files seem confused, although the situation has
>improved rather of late. Particular problems are experienced when you
>try to work with a new version of gcc that has some of its own include
>files - the number of clashes are quite surprising. But we can't use
>glibc, or the Linux libc, both of which are much better because they
>are under the GPL.
Wrong. The problem is with gcc. The net/2 (and, thus, 386bsd, netbsd,
bsd/386, and 4.4bsd) header files are most certainly *NOT* confused.
That's a matter of opinion... I've had some clashes between the
components of the Net-2 include files as well. By the way, if you
contradict people as forcefully as by saying "Wrong. ..." you will do
everyone a disservice by starting the flame war off again. Other
people will flame you, even if I don't.
In addition, glibc, and the Linux libc, are not better "because they are
under the GPL." They are better despite being GPL'd...
Quite so. I missed out a comma, causing you to make a parse error. I
leave you to work out the details... :-)
many, many fine
and talented programmers will not work on GPL'd library code, or, if they
do, they do so reluctantly. Other people have had to write their own
libraries because they could not use GPL'd code, and, thus, they concentrate
all their efforts on their own -- when they might have shared their code
if they'd started from, say, Net/2's libc.
You make the GPL sound like the greatest tragedy outside Shakespeare.
(That's assuming Linux' libc
is better; I do not believe it is, personally, nor glibc.)
I used the Linux libc a lot, I haven't used glibc much at all. The
Linux libc is certainly free of a lot of the annoying glitches in the
BSD one.
>2. The DBM library seems most peculiar. Linking programs to it often
>seems to give link errors due to non-existent routines.
The compatable routines were, apparantly, deliberately
not included in Net/2, for reasons I don't really understand :).
Well you said it!
1. I can make a case that the LGPL buys one nothing over the GPL.
I read it again, and I believe you are right.
3. Lots of people object to the GPL on purely philosophical and
political terms. Just because you cannot understand them does not
invalidate them, any more than their beliefs invalidate the FSF.
When did I say that it did? What I was suggesting was creating an
archive of GNU software, so that people are FREE TO CHOOSE whether
they want GPL or Berkeley copyright.
A Wizard of Earth C
The issue of "why avoid GPL?" has been discussed on this group before. To
avoid a flame-fest, if you are arleady a religious zealot on one side or
the other, skip to the next article now. 8-).
In article <PC123.93M...@bootes.cus.cam.ac.uk> pc...@cus.cam.ac.uk (Pete Chown) writes:
>In article <CGD.93Ma...@eden.CS.Berkeley.EDU> c...@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes:
>
> NetBSD has the same attitude toward GPL'd code as does 386bsd,
> and perhaps even a stronger one.
>
> As long as i'm in "control" of NetBSD, there will be:
> (1) No GPL'd code in the kernel
> (2) No GPL'd code in libc
> (3) GPL'd code added to the standard tree only
> where no adequate free replacement is presented.
>
>I think this is a shame. To my mind there is no gain in producing a
>free operating system for other people to make money out of.
Well, we (and the FSF) disagree with you. The FSF *promotes* sales of
precompiled GPLed code (in the guise of copying fees) and support for
that code. Cygnus Support has been very successful (and has contributed
greatly to the UNIX community) doing this.
The BSD license lets you do anything you want with the code: sell it,
distribute modifications of it, etc., You can do anything you want
with the BSD licensed code that you can do with GPLed code, plus the
things disallowed by the GPL.
Unless there's money in it somewhere, there won't be commercial quality
applications for it (other than development tools, also under GPL). The
only market for such systems is as part of a vertical market soloution,
and then the beneficiaries tend to be the small consultant. Even then,
the LGPL on the library requires that object modules be shipped for any
application that wants to link with them, basically publishing every
non-static function, variable, and interface in an application -- this
goes a long way towards reverse engineering it, something that would
be only marginally possible after a *lot* more work if the software
was distributed as a stripped executable.
>1. The include files seem confused, although the situation has
>improved rather of late. Particular problems are experienced when you
>try to work with a new version of gcc that has some of its own include
>files - the number of clashes are quite surprising. But we can't use
>glibc, or the Linux libc, both of which are much better because they
>are under the GPL.
The confusion is in the generically hacked gcc includes that must be
grafted in... unless you are complaining about the lack of ANSIfication,
which protects a programmer from needing (or knowing how to) run lint.
>2. The DBM library seems most peculiar. Linking programs to it often
>seems to give link errors due to non-existent routines.
This was an intentional omission, and can be easily remedied by using
appropriate wrapper functions. In general, you should *not* mix the
old and new syntax; it assumes that the underlying implementation is
shared.
>I don't see what the problem is with the libraries. All the GNU
>libraries are under the library GPL, so they can't "infect" other
>programs just by them being linked with them.
No, but they can require you to distribute object modules which can
be interpreted as a disclosure of the overall organization of your
program, as well as providing a symbolic organization of each object
module -- thus disclosing the functional organization as well. You
can't ship stripped binaries.
>Perhaps I should start assembling a kit of GNU software that you can
>add to your 386BSD implementation...
This would be a nice feature as an add-on "GNU utilities" package, and
would certainly add value to a 386BSD system as far as a consumer is
concerned... Go for it!
Terry Lambert
te...@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Peter da Silva
> free operating system for other people to make money out of.
Please, let's not have this fight all over again?
Different people have different priorities, and different goals. Accept
it, instead of flaming folks whose goals differ from yours.
> Perhaps I should start assembling a kit of GNU software that you can
> add to your 386BSD implementation...
Please do. That would be a valuable tool, plus let us accelerate the unGNUing
of the base platform.
Charles Hannum
Surprise! This is not a flame...
In article <PC123.93M...@bootes.cus.cam.ac.uk>
pc...@cus.cam.ac.uk (Pete Chown) writes:
>
> I don't want to start this flame war off again, I only posted on the
> subject because I wanted to suggest setting up an archive of ported
> GNU software for those who didn't mind the GPL.
There already *is* one; alpha.gnu.ai.mit.edu:/386bsd (soon to switch
over to NetBSD).
I've set up this archive not necessarily because I think the GNU
software is better. (In fact, in many cases it's just larger, slower,
and buggier.) I set it up only because I recognize that many people
want the GNU versions of utilities; I don't even use most of it myself.
>> In addition, glibc, and the Linux libc, are not better "because they
>> are under the GPL." They are better despite being GPL'd...
>
> Quite so. I missed out a comma, causing you to make a parse error.
> I leave you to work out the details... :-)
I don't agree. The only problem I'm aware of in the current NetBSD
library is the inaccuracy of printf()ing floating point numbers.
> The Linux libc is certainly free of a lot of the annoying glitches in
> the BSD one.
Would you care to elaborate on what these `annoying glitches' are? I
certainly haven't seen any reported. If I hear about them, I will fix
them (within reason; this *is* volunteer work, after all).
>> 1. I can make a case that the LGPL buys one nothing over the GPL.
>
> I read it again, and I believe you are right.
I am impressed not that you agree, but that you actually reread it.
Charles Hannum
In article <1993May6.0...@fcom.cc.utah.edu> te...@cs.weber.edu
(A Wizard of Earth C) writes:
>
> No, but they can require you to distribute object modules which can
> be interpreted as a disclosure of the overall organization of your
This is misleading. One can simply link all of the object modules of
the final program together and remove internal symbols; this yields
something which discloses no more information than if you had linked it
with shared libraries (something Sun vendors sometimes do, for
example).
The requirement of keeping the same version of the source around for a
minimum of three years, to supply on demand, is a really annoying
adminstrative hassle, though. Linux SLS violates this clause of the
GPL.
Holger Veit
|> Chris G. Demetriou (c...@eden.CS.Berkeley.EDU) wrote:
|> : NetBSD has the same attitude toward GPL'd code as does 386bsd,
|> : and perhaps even a stronger one.
|>
|> : As long as i'm in "control" of NetBSD, there will be:
|> : (1) No GPL'd code in the kernel
|> : (2) No GPL'd code in libc
|> : (3) GPL'd code added to the standard tree only
|> : where no adequate free replacement is presented.
|> . . .
|> (not GNUBSD)) I would be thrilled. Frankly, I had hoped that NetBSD
|> was taking the course described by Professor Veit above.
Chris already mentioned that the NetBSD support is a full time job for
several people (I am again speaking for NetBSD :-)), and furthermore, there is
already enough confusion with 386bsd-0.1, -0.1.5, -0.1 with patchkit X.Y.Z,
-0.2-vaporware, and NetBSD-0.8, so that I am quite reluctant to
add another derived system.
But I would have considered it as a natural consequence of proceeding
with NetBSD to GNUify certain parts. GNUifying the kernel would be something
to discussed, but utilities and libc could be a step into a direction of
getting more compatibility with e.g. Linux.
Since this is apparently not the direction, the serious question arises
what NetBSD is really good for, besides being an upgraded set of the
outdated bindist/srcdist/etcdist distribution, which shouldn't be
underestimated. But the first announcement of NetBSD implies that the
distributors want to go further than this and do not intend to accept
everything Bill seems to have in mind with 0.2 and later. To me it looks
a bit like the revenge of the 4.4BSD people against Jolitz (which might
be said of 386BSD with a different sign as well). I hope I am wrong...
fis...@ivy.dt.navy.mil
|>
|>The flaw in this logic should be obvious.
So what. Most of the arguements against the GPL have been flawed, too.
(I've never used the GPL on any of the software I've released).
|>
|>In article <1s8d6k...@dtix.dt.navy.mil> fis...@ivy.dt.navy.mil
|>writes:
|>>
|>> Question: Since so many 386BSD people are against the GPL, shouldn't
|>> those same people not use any GNU software to be consistant? Such as
|>> gcc?
|>
|>Question: Since so many GPL supporters are against non-GPL software,
|>shouldn't those same people not use any non-GPL software to be
|>consistent? Such as Unix, X, DOS, or most everything else?
But the GPL supporters have not been arguing against using non-GPL software.
-steve
Peter da Silva
> Since this is apparently not the direction, the serious question arises
> what NetBSD is really good for,
A common base for a free production operating system that can be used by
hobbyists and small entrepreneurs alike, as opposed to a pure-hobby system
like Linux or a pure-research system like 386BSD.
Dave Albrecht
> In article <1993May6.1...@gmd.de> ve...@mururoa.gmd.de (Holger Veit) writes:
>> Since this is apparently not the direction, the serious question arises
>> what NetBSD is really good for,
>
> A common base for a free production operating system that can be used by
> hobbyists and small entrepreneurs alike, as opposed to a pure-hobby system
> like Linux or a pure-research system like 386BSD.
> --
which can be used in the workplace or home projects that I then have the freedom to
sell or not without including the source. In some ways it is more frustrating
to have to re-invent the wheel when wheels are available that are perfectly
adequate but the wrong color (i.e. GPL when you are doing work that you might
want to commercialize) than if there were no available wheels at all.
While I admire and respect and yes, use GNU software it isn't as useful to me
as it could be because I won't borrow any of the code in it for my own purposes
as it restricts my freedoms with how I choose to distribute the result.
I am very much pleased that NetBSD is going the direction it is. i.e. as unGNU
as possible, moving to standards rather than experimentation. I have no
relationship to movers/shakers in NetBSD but it is laid out exactly as I would
do it and as that so rarely happens I must say I was quite surprised.
With all the efforts in languages to foster and encourage reusable code it is
nice to see lights in the GPL murk producing code that will be resuable by
everyone, not just those producing GPLed software.
David Albrecht
Michael Richardson
sun today), I'll bite.
In article <C6oF5...@megatest.com> albr...@megatest.com (Dave Albrecht) writes:
>From article <C6M5J...@sugar.neosoft.com>, by pe...@NeoSoft.com (Peter da Silva):
>> In article <1993May6.1...@gmd.de> ve...@mururoa.gmd.de (Holger Veit) writes:
>>> Since this is apparently not the direction, the serious question arises
>>> what NetBSD is really good for,
>>
>> A common base for a free production operating system that can be used by
>> hobbyists and small entrepreneurs alike, as opposed to a pure-hobby system
>> like Linux or a pure-research system like 386BSD.
>> --
>Equally important in my view, it provides a large repository of code pieces of
>which can be used in the workplace or home projects that I then have the freedom to
>sell or not without including the source. In some ways it is more frustrating
>to have to re-invent the wheel when wheels are available that are perfectly
>adequate but the wrong color (i.e. GPL when you are doing work that you might
>want to commercialize) than if there were no available wheels at all.
There is nothing in the GPL to prevent you from `commercializing'
software. What it really prevents you from doing is a quick sale of
some code and then disappearing.
I've never quite figured out why BUYERS of software, especially PC
software haven't been screaming bloody murder over the kind of
customer service they are getting.
Case example: Apparently WP craps all over floppy FAT tables when
used on a Novell network. It doesn't happen every time, but it happens
often. Ever try explaining to some poor psych or english major who
just got over a major conceptual hurdle and figured out how to use the
damn wordprocessor, WHY their document has been trashed? I thought
this was a recent bug. Then I learned that the Journalism students at
Carleton University were warned out this bug _three_ years ago. Give
the symbol table, and a couple of weeks to hack 286 and 386 GDT tables
and I'll tell you what routine is trashing what. The university pays a
lot of money for their WordInperfect site license.
>While I admire and respect and yes, use GNU software it isn't as useful to me
>as it could be because I won't borrow any of the code in it for my own purposes
>as it restricts my freedoms with how I choose to distribute the result.
Ah! Too much trouble to keep a disk/tape around for three years in
case they want the code? You mean, you can't do that and you expect me
to buy software from you? What about maintenance? Bug fixes?
Very few companies expect upgrades to be free at this point.
Want to sell some business software, say maybe some MRP software?
[to keep things on familiar ground for me]. They have this neat
concept called ``escrow'' --- tapes go to a lawyer, who puts them away
in a vault somewhere, just in case your company goes under. Sound like
the GPL to you? Sure sounds like it to me.
>With all the efforts in languages to foster and encourage reusable code it is
>nice to see lights in the GPL murk producing code that will be resuable by
>everyone, not just those producing GPLed software.
Wait a minute... you are happy that you can rip off work that would
not have been possible without the GPL? And you won't share your stuff
with the rest of us?
You know why the suits are so thrilled about OOP languages? It is
really clear and simple if you used the Foo Class or not. ``Software
ICs'' --- and 30,000 lawyers to work out all the licensing required.
--
:!mcr!: | The postmaster never | So much mail,
Michael Richardson | resolves twice. | so little time.
HOME: m...@sandelman.ocunix.on.ca Bell: (613) 798-0698
SCHOOL: m...@physics.carleton.ca
Peter da Silva
> There is nothing in the GPL to prevent you from `commercializing'
> software. What it really prevents you from doing is a quick sale of
> some code and then disappearing.
It also prevents you from selling software in a hostile environment and
then hanging around. How are you supposed to make a living on software
sales at a few dozen to a few hundred bucks a pop when after the first
few sales the market's gone? Support? Well, that takes us to the next point:
> I've never quite figured out why BUYERS of software, especially PC
> software haven't been screaming bloody murder over the kind of
> customer service they are getting.
They have. They also scream bloody murder over the kind of software that
requires ongoing customer support. Cygnus can make it because they're
supporting a product in an environment where support is expected: a complex
and powerful set of developer tools *to* software developers. For most
commodity software, if they call the support line it means *the vendor*
has fucked up. They shouldn't be *expected* to provide the vendor with
its primary revenue stream here. Hell, they already get upset enough at
vendors that try to do simple cost recovery on support calls.
> Case example: Apparently WP craps all over floppy FAT tables when
> used on a Novell network.
Have you written software for DOS? I'm not a fan of Word Perfect, but it's
damn hard to maintain software in such a fragile environment. The floppy FAT
tables shouldn't even be visible to a word processor.
> It doesn't happen every time, but it happens
> often. Ever try explaining to some poor psych or english major who
> just got over a major conceptual hurdle and figured out how to use the
> damn wordprocessor, WHY their document has been trashed?
Yep. "You bought the wrong operating system. Oh, sorry, there isn't a better
one you could have bought. Well, there are a bunch of people working on
building one, but they're wasting time explaining why they couldn't expect to
sell it through regular retail channels if they had no recourse against
piracy".
Now let's have a digression:
> You know why the suits are so thrilled about OOP languages? It is
> really clear and simple if you used the Foo Class or not. ``Software
> ICs''
Software ICs exist. OOP languages do *not* make it that much easier to build
them... designing a system with a clean factoring of responsibilities between
components is needed for that, and if you do that you'll end up with a
software IC no matter what the target language is... and if you don't you
won't even if you target an OOP language. Ever hear of Spaghetti Inheritance?
> --- and 30,000 lawyers to work out all the licensing required.
Back to the point, of course: the question of software patents is separate
from the issue of software copyright. You can support the LPF without buying
into the goals of the FSF.
Dave Albrecht
> software. What it really prevents you from doing is a quick sale of
> some code and then disappearing.
>
I would like to think that everyone is honest and fair too but I know that given
source for a popular commercial product in mass distribution, some number of people
will tweak it slightly (change the appearance etc.) and merchandise it
as their own without distributing the source. Being realistic, the only reasonably
decent protection for a commercial developer is not distributing source. Period.
It takes much time effort and costs money to develop products which by distributing
source is given away in an instant. This is tantamount to shooting oneself in the
foot.
>>While I admire and respect and yes, use GNU software it isn't as useful to me
>>as it could be because I won't borrow any of the code in it for my own purposes
>>as it restricts my freedoms with how I choose to distribute the result.
>
[lots of stuff having to do with support and also absolutely nothing to do with my
point deleted]
Get real. I want the freedom to take the software I produce and make it freeware
or make it commercial without including source (gasp) or even make it GPL
(double gasp) if I so choose. I want the choice to be MINE MINE MINE. GET IT YET?
Jeez. That is why I don't use extractions of GNU code in anything of mine.
Certainly I can't use anything GNU in something for my job. What is
so difficult to understand about this?
>
>>With all the efforts in languages to foster and encourage reusable code it is
>>nice to see lights in the GPL murk producing code that will be resuable by
>>everyone, not just those producing GPLed software.
>
> Wait a minute... you are happy that you can rip off work that would
> not have been possible without the GPL? And you won't share your stuff
> with the rest of us?
Try lowering the volume of the GNU bible thumping for a minute. People pay
my salary. They pay it for producing software. Of necessity that software will
not be shareable with the community at large. Most software I produce on my
own time I am perfectly willing to distribute as PD. If I distribute it as
PD I expect, I want, I am pleased when people use my work in works of their
own whatever they might be. I am not disputing anyones right to distribute
the fruits of their labor however they choose. I am simply stating my
personal viewpoint that PD software is generally more useful than that under
the GPL and why. Given the rather inaccurate and inflamatory phrase
'rip off', your opinions on this topic are pretty obvious.
David Albrecht
Theo de Raadt
as it could be because I won't borrow any of the code in it for my own purposes
as it restricts my freedoms with how I choose to distribute the result.
NetBSD code will not cause the following dire personality changes to occur:
1. not bathing
2. robbing the blind
3. being unkind to your mother (unless you already are)
4. wearing colors that clash
5. eating your dessert first
regarding the GNU tools, YOU HAVE BEEN WARNED
--
This space not left unintentionally unblank. der...@fsa.ca
merlin
scientists "stood on each others' shoulders" by using earlier results
and techniques to generate new knowledge. Today, with the application
of patents to every minor (primarily genetic engineering) development,
it seems as though many scientists want to own (and collect rent from)
every step of the ladder upon which future scientists must base their
work. The GPL constitutes one such form of ownership interest -- the
rent for which must be paid by agreeing to redistribute source code --
some people are willing to do this -- others are afraid integration of
GPL source code into their own work will contaminate their own efforts.
I tend to use GPL code (i.e. gcc) as a tool to develop other more freely
distributable code. But I would be hard pressed to integrate GPL code
into my own efforts. I think we would all be far better off if commonly
used software development tools and operating system source codes were
public domain rather than GPL derived. The 386BSD & NetBSD efforts must
be applauded for adhering to a more freely redistributable philosophy.
------------------------------------------------------------------------------
Alexander-James Annala
Principal Investigator
Neuroscience Image Analysis Network
HEDCO Neuroscience Building, Fifth Floor
University of Southern California
University Park
Los Angeles, CA 90089-2520
------------------------------------------------------------------------------