Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA2175 ; Fri, 26 Feb 93 17:31:21 EST
Newsgroups: comp.os.386bsd.questions
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!newsserver.jvnc.net!gmd.de!fanoe!veit
From: veit@fanoe.NoSubdomain.NoDomain (Holger Veit)
Subject: Re: 386BSD Posix Compliance
Message-ID: <1993Feb25.080612.16553@gmd.de>
Sender: veit@fanoe (Holger Veit)
Nntp-Posting-Host: fanoe
Organization: GMD, Sankt Augustin, Germany
References: <1me016$4j8@agate.berkeley.edu> <C2z38u.3BA@panix.com>
Date: Thu, 25 Feb 1993 08:06:12 GMT
Lines: 82
In article <C2z38u.3BA@panix.com>, tls@panix.com (Thor Lancelot Simon) writes:
|> In article <1me016$4j8@agate.berkeley.edu> wjolitz@soda.berkeley.edu (William F. Jolitz) writes:
|> >Just to reassure people, 386BSD will remain POSIX compliant.
|> >Extensions to the system are "experimental" and will be justified
|> >over time.
|> >
|> >However, 386BSD development remains focussed on novel research and
|> >development issues. Compatibility with commercial systems
|> >is not a primary goal. Commercial companies which wish to
|> >slip-stream 386BSD development work instead of competing
|> >in the commercial market and spending their own dollars
|>
|>
|> With all due respect, I think you're misunderstanding the issue!
*I* think *you* are misunderstanding what POSIX is, and what Bill (Lynne?)
meant with compatibility and interface. See below.
|>
|> There are a lot of us who _DON 'T_ have the money or need for a commercial
|> system (thus being 386BSD's target audience as I understand it) who would
|> like to be able to slip-stream the work done by others who _do_ use the
|> commercial systems like BSDI and Mach386 with which 386BSD is currently
|> compatible. Changing interfaces in a way incompatible with those
|> commercial systems (and other noncommercial ones, like 4.4 and HURD)
|> hurts _us_, part of your user base, as much as it might hurt the
|> commercial vendors. I know you work very hard and am sure you put a lot
|> of thought into it before deciding to do this, but I really do wish you'd
|> reconsider.
386bsd has at least two aspects: the kernel and the user view. The user view is
basically the set of user applications, such as 'ls', 'rm' and others, as well
as the set of standard functions (like open, printf, fgets, and many more) and
include files (<stdlib.h>, <stdio.h>, <curses.h> etc.) The latter two areas are
covered by POSIX, and noone intends to change essential things in this area
("tomorrow 'printf' will be gone, we now have 'outputsomething()'"). 386bsd will
remain downward compatible for the application programmer for the next time.
So expect that you will need to do the same amount of modifications to get a new
software running under "BSD" like you needed before (if you ever ported something
yet). What is not an issue, is to adapt 386bsd further to commercial "standards"
(which aren't). There is no reason to provide a XENIX loader interface, if all
sources can be compiled to run under BSD. If you still want to run your old
"SVR X.Y" binaries, why didn't you stuck with SVR X.Y? If you cannot afford
buying SVR X.Y, where the hell did you get this binary from? ;-)
The second aspect is the kernel domain. A typical user does not normally write
kernel code; in most commercial systems you have to pay a considerable amount
to get the necessary (re-)sources to do so. You might perhaps compile a kernel,
or install some patches. Whether you compile a kernel by
'config FOO;cd /sys/compile/FOO;make depend;make' or 'installit FOO' is
quite irrelevant, as long as it is documented; as well as the fact if the kernel
is called '386bsd' or 'this_is_the_kernel_of_the_system_distributed_in_100_files'.
Bill's mentioned "novel research" focuses on changes in the kernel interfaces,
for instance device drivers, memory management, file systems, networking. This
might be an extreme change for kernel hackers, and 386bsd surely becomes incompatible
to e.g. NET/2 on the *source level*; but this *is* acceptable (noone complains
that device drivers must be rewritten from SysV to BSD, but apparently
they must remain exactly the same for all BSD's since 0.0BSD to 99.99BSD;
this is not progress. BTW: the interfaces have evolved in BSD!). If a kernel
programmer does not accept this, he/she is not worth doing any work here. They
ought to know what they are doing.
Another point: Even if the 386bsd research community decides to greatly improve
let's say the sendmail program (there are alternative packages already), noone
is forced to use it, as long as the original source is available. Even if I
and thousand other people suddenly decide to remove 'ls' and call a replacement 'dir',
you are not forced to do the same (see /usr/src/bin/ls/ls.c).
This "threatening incompatibility" in the future of 386bsd, seen in the light, is
no reason for general panic.
Holger
|> Thor Lancelot Simon tls@panix.COM
--
Dr. Holger Veit | INTERNET: Holger.Veit@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