*BSD News Article 8234


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!sun-barr!cs.utexas.edu!wupost!uunet!psinntp!pool!ujlh
From: ujlh@pool.info.sunyit.edu (James Henrickson)
Subject: Re: Shared Libraries for 386BSD (long, w/source)
Message-ID: <1992Nov28.045223.1045@pool.info.sunyit.edu>
Organization: State University of New York -- Institute of Technology
References: <lohse.722861707@tech7> <JKH.92Nov27145531@whisker.lotus.ie> <veit.722878428@du9ds3>
Date: Sat, 28 Nov 1992 04:52:23 GMT
Lines: 61

In article <veit.722878428@du9ds3> veit@du9ds3.uni-duisburg.de writes:
>
>You may use this code, it might work, but you should expect a number of
>changes in 0.2 (I don't comment on this), which might cause a large number
>of things work in a different way, or no longer at all. This applies in
>particular to some (source) postings in the last few days or weeks, which are
>mainly results of "the unknown, lonely, uninformed hacker" and are often
>in no way acknowledged by THE WIZARD @ soda.berkeley.edu.
>
>-----------------------------
>I take this chance to ask all the "unknown hackers" (who might do good work,
>nevertheless): If you have ported or written something, or want to write or
>port something, PLEASE check first whether it has not already been done yet.
>The workgroups forming at ref.tfs.com are a good reference of what is
>going on. Ask one of the known bsd wizards *), whether your "super-duper 
>program/driver/whatsoever" is really in the line of 386bsd. What we do not
>need is duplicate work and work which is incompatible to existing things
>and will invalidate existing software. This should not cripple your creativity,
>but coordination is necessary. I am not against competition, but not on
>the shoulders of the people who mainly want to use 386bsd.

I see nothing wrong with the latest posting of source code.  I understand 
that 0.2 might support shared libraries, but who is getting hurt by adding
shared libs to 0.1?  Isn't that what research (and hacking) is all about?
I doubt this source code will have any effect on 0.2, and I doubt it will
have any effect on those people working on shared libs for 0.2.  With all
of the anticipated changes in 0.2, wouldn't it make sense to just install
it from scratch?  I seriously doubt it will be feasible to distribute
0.2 as a HUGE series of patches to 0.1, so I doubt this source code will
have any effect on 0.2.

You mention "people that mainly want to use 386bsd."  If they are USERS
and not HACKERS, they shouldn't even try adding the source code.  Wouldn't
it just be sufficient to append a "THIS IS FOR HACKERS ONLY" disclaimer
at the end of such an announcement? :-)

Furthermore, you mention the threat of intervention by AT&T or USL or
somebody (don't remember for sure, I deleted that part already).  If
this particular implementation of shared libs is kept separate from the
official 386bsd distribution, how would 386bsd be affected?  I've seen
a lot of "questionable" add-on source code for operating systems floating
around, but I haven't seen the operating system people get dragged into
court over it.

I think that you made some good points, but I believe you are being
overprotective of the centralized development of 386bsd.  Must there
be such a solid line drawn between users and official developers?
There are many of us that fall in the middle, and we are the ones you
seem to be speaking out against.  I admit that I haven't done a lot
of kernel hacking, but what if I did something that I thought was
beneficial?  Some of us would like to experiment with new features
NOW.  Are you suggesting we use a different operating system, or that
we should start a "comp.os.386bsd.unofficial.hackers" newsgroup?

"This had to be said."  :-)

-- 
Jim H.
*
* James L. Henrickson  |  "I don't need a signature, I need a job!"
* ujlh@sunyit.edu      |  BSCS, December 1992