Return to BSD News archive
Xref: sserve comp.os.386bsd.development:563 comp.os.386bsd.misc:233 comp.os.386bsd.questions:1982
Newsgroups: comp.os.386bsd.development,comp.os.386bsd.misc,comp.os.386bsd.questions
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!usenet.coe.montana.edu!nate
From: nate@cs.montana.edu (Nate Williams)
Subject: 386BSD Interim Release Status Information
Message-ID: <1993Apr25.060340.14059@coe.montana.edu>
Followup-To: comp.os.386bsd.misc
Summary: not NetBSD, something else
Keywords: patchkit, 0.2,
Sender: usenet@coe.montana.edu (USENET News System)
Organization: 386BSD 0.1.5 temporary head-quarters
Date: Sun, 25 Apr 1993 06:03:40 GMT
Lines: 141
There seems to be some confusion regarding the status of 386BSD 0.1,
386BSD 0.1.5, 386BSD 0.2, the 386BSD patchkit, and NetBSD. Hopefully,
this article will help clear up some of the confusion.
After much thought and some prodding from others, here are some thoughts
on 0.1.5. Please read this all the way through before jumping to any
conclusions.
Regarding the interim release, I *think* I can speak for most of the
principles involved. Additionally, Rod has given me permission to
speak for him, as these goals also reflect the goals of the patchkit.
---
These are what I consider to be the goals and purpose of the 386BSD
interim release.
1) To update any software for which a newer version currently exists.
An example of this would be groff, which has gone from version 1.01
to 1.08.
2) To add certain missing pieces of the BSD environment that we've deemed
important. Examples are `GNU dc', many utilities from the NET/2 release
of BSD, and user contributed utilities such as `vmstat'.
3) To ensure that the entire 386BSD source tree can be compiled with
either gcc1 (the currently supplied version) or gcc2, depending on the
user's preference.
4) To create tools that enhance and simplify the 386BSD installation
process.
5) To wholly replace the out-dated and rather buggy 0.1 "base release"
with something that both integrates the bulk of the patchkit and gives
developers a more stable and current platform on which to base
their own changes.
6) To create a new 'patch kit' mechanism which will make it easier to:
a) Generate and submit patches.
b) Back-out faulty patches.
c) Allow multiple, experimental versions of the system without
impacting `main-stream' users.
d) Aid developers in easily tracking their own changes.
7) Provide an updated release of 386BSD for new users, one that does
not require the immediate application of potentially hundreds of
patches.
8) To aid in the transition to 0.2. This is one of the key differences
between this project and NetBSD.
---
Things that this release isn't:
1) Competition with NetBSD. Even though I see us as having differing
goals in certain respects, in most areas the work between 0.1.5 and
NetBSD can and will be shared. Linux is a good example of how even
having multiple ways of getting the same things done doesn't necessarily
result in a poor operating system. Additionally, many of the principles
involved are active in *both* projects, and therefore in day to day
contact, so the sharing of ideas and code between the two groups will
happen naturally. Rodney Grimes is currently attempting to migrate as
many bug fixes as possible from NetBSD 0.8 into the 386BSD patch
kit.
2) An implementation of everyone's pet project. At this point in time,
we can't add every patch and new driver that has been submitted to
this release effort. We'd like to get this done and tested before
we all turn old and grey. :-)
---
Things that I'd like to see, but don't have the time for:
a) Upgrading the documentation. It would be nice to have documentation
that is relevant to 386BSD, rather than being VAX specific.
b) A new whiz-bang install program. I was working on something
recently, but it's pretty basic and, while nothing fancy, will
hopefully get the job done. [ This was put on hold, but will probably
be picked up after school lets out ]. There are several other
people looking into this as well.
c) Additional user-supported software. It would be nice if we could
bundle up things like emacs, TeX, and such together for this, but for
right now I think such things would put an unacceptable burden on our
time constraints. We are, of course, always willing to accept submissions
provided that we are also not necessarily called upon to support them
or provide idiot-proof installation methods. Consider such packaging
details before making a submission!
d) Lots of kernel hacks. While we are mostly interested in re-packaging
what is already out there, we would also like to get packages such as
the Barsoom drivers, the interrupt-less driver, Bruce's com and npx
stuff and other such good things in the source tree, provided they can be
debugged in time. We are not, however, looking at adding new ways of
interfacing to the kernel. That kind of stuff we are leaving up
to Bill and the patchkit mechanism.
Summary:
386BSD interim will follow, patch by patch, the 'patchkit' that Rodney
Grimes is co-ordinating. In addition to this, it will have software
updates for packages such as tar, groff, elvis, and more.
As an added bonus, because all of the former/current patchkit
maintainers are involved in the interim release, we would like to
replace the current version of the patchkit with a new implementation
that makes it easier for the patchkit maintainer to bring patches out
faster, as well as making it easier for developers to send out changes
directly to the users.
Finally, we are planning on integrating this material into 0.2 when it
is released. Whether or not we migrate to 0.2 immediately upon
release will have to be decided at the time, but, speaking for myself
only, I am more interested in stability than new features. I hope
that this release, and further work after the release, can help to
ease the transition to 0.2 by taking the 'good' parts out of whichever
release is more stable, and merging the two together.
Questions, comments, feedback, criticism, are all welcome. Flames
welcome, but take it to email.
If you would like your name and project added to this list, please
send me (Nate) all the necessary information.
Nate - Interim Release mouth piece
Rodney Grimes - Patchkit co-ordinator
Jordan Hubbard - Final Editor
Please send all requests and inquiries to the email address
nate@bsd.coe.montana.edu, since I still get less than a hundred mail
messages/day at that address. :-)
PS. For those w/out resources to do projects, talk to me (Nate) and we
might be able to work something out, if you already have network access.
--
osynw@terra.oscs.montana.edu | Still trying to find a good reason for
nate@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