*BSD News Article 56834


Return to BSD News archive

Newsgroups: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!usc!chi-news.cic.net!news.midplains.net!gw2.att.com!nntpa!not-for-mail
From: dyson@inuxs.inh.att.com (John S. Dyson)
Subject: Re: Linux vs FreeBSD
Message-ID: <DJ6IJE.78D@nntpa.cb.att.com>
Sender: news@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: inuxs.inh.att.com
Organization: AT&T
References: <489kuu$rbo@pelican.cs.ucla.edu> <DJ3DM7.n0L@kroete2.freinet.de> <4a14v5$1lq@dyson.iquest.net> <4a2kme$32d@josie.abo.fi>
Date: Wed, 6 Dec 1995 19:09:14 GMT
Lines: 196
Xref: euryale.cc.adfa.oz.au comp.os.linux.advocacy:30254 comp.unix.bsd.freebsd.misc:10413

In article <4a2kme$32d@josie.abo.fi>, Mats Andtbacka <mandtbac@abo.fi> wrote:
>John S. Dyson, in <4a14v5$1lq@dyson.iquest.net>:
>>In article <DJ3DM7.n0L@kroete2.freinet.de>,
>>Erik Corry <erik@kroete2.freinet.de> wrote:
>
>[deletia]
>
>>development centralized.  It still does not appear to be open -- in
>>fact, I accepted patches and mods from users when working on SVR4 --
>>that does not make SVR4 open :-).
>
>I still fail to see what's so much more "closed" about Linux
>development that isn't similarly closed in *BSD. In both systems, if
>you want to change something, you've got to convince the Powers That
>Be that it needs to be changed, and that your change is the right way
>to do it; or become a Power That Is yourself.
>
Linus calls the shots in the kernel doesn't he???  He ALLOWS people
to work on certain sections, right??  On FreeBSD, the development is
much more open and diverse.

>
>If the code had been so bad as you described, you wouldn't have had
>much trouble convincing people about it; there would've been dozens or
>hundreds of people screaming for it to be changed on the 'net. Such
>
Actually, NetBSD is looking into changing their VM system after seeing
the difference in performance between FreeBSD and NetBSD.  They may
or may not adopt the FreeBSD stuff -- but they are seeing the
deficiency.  Many of the VM system problems are only significant under
heavy load -- and FreeBSD has always targeted high performance under load
as one of its goals.  So yes, there is acknowlegment -- even from Mike
Hibler (who did the original port of the MACH VM system) that there are
problems in the original stuff..  BTW, he did a tremendous job on the
original stuff -- it just needed some re-work, polishing and the MACH
stuff before his port wasn't really up to the task.  Most of our work
has been removing the problems with the original MACH stuff.

One more thing, if you are stuck with a slow VM system, it mostly appears
that your machine is slow in starting up processes or slow in swapping.  You
can get used to it pretty fast.  Sometimes it isn't even noticed, because
the system is a single user workstation with light load.  Start loading
the system and the VM system becomes a major player.  It appears that VM
systems are a 'stepchild' and I think that there is alot that can be done.
(Even in FreeBSD -- but I think that others are a bit behind.)

>
>Could you? Care to look over the Linux VM system (since that is your
>area of specialization) and offer some constructive criticism? The
>networking code might be hard to comment on, since it's currently
>seeing intense development; you might want to wait for 1.4 before
>saying anything definitive.
>
Yes, I have not had much time -- but earlier results of some performance
test runs show some problems under heavy load and slowness under light load.
I haven't yet had time to see how the kswap (or 1.3.40 or so kernels) patches
do -- they should help alot, but from what I have heard some heuristics were
used, and those heuristic things scare me(1).  But, the proof of the pudding
as they say, is in the eating.  When I get the time, I will try to see how
it does.

(1) Heuristics scare me because they impose a policy.  I found that in working
on the FreeBSD stuff, that all of my experimental heuristics ended up in being
a tradeoff between performance in certain situations.  That is the reason
that the FreeBSD stuff is statistics driven.

>
>What do you mean they're not getting credit? Looked at the Linux
>sources recently - read the CREDITS file? There are people's names
>smothered all over the sources; authors near as I can tell always get
>credited for their work.
>
Is the CREDITS file necessary under GPL???  It is good that there is a
credits file in Linux, I guess, but it is not really necessary -- nor is
it in FreeBSD.  But in the case of the VM system where I spent much
of my life with very little or no money reward, the BSD copyright protects
me from preditors that might try to take credit for it (and indemnifies
me from any damages, etc.)  BTW, what about those files in the Linux
kernel without any copyright messages at all???

>
>>What is the problem with the BSD copyright? -- I'll bet it is
>>primarily that one must give credit to the developers and not take
>>credit for work that others have done...
>
>No part of the GPL grants you any right to claim others' work as your
>own. No part of the GPL forbids you from crediting your own work to
>yourself.
>
But the BSD copyright guarantees it.

>
>As for what's "wrong" with the BSD copyright, I'm not sure if there's
>anything wrong with it at all; I've never even read it, so I couldn't
>tell.
>
It is short and sweet -- probably 20 or so lines.

>
>Doesn't this somewhat contradict what you said above about crediting
>people for their work? Or does BSDI list you as co-developer of their
>private, proprietary OS? I really don't know.
>
It is guaranteed -- they can use my code without disclosing it.  There is
very little that they can do to it that I can't either.  In essence, they
can make proprietary mods that they feel can give them an edge -- and that
is okay with me.  I can do the same mods if I want.  There is very little
"magic" in any kernel that I know of.

>
>You seem to have proven his point, I'm afraid. I'm glad you're
>managing anyway, but so long as Caldera makes money from their code
>additions to Linux - the IPX stuff, foremost - *I* see it as only
>right and proper that they contribute that code back to the rest of
>Linux. Of course, the GPL pretty much forces them to, but...
>
You and I disagree about that, and that is okay.  I believe that when
I give a gift, that it is best to give with as few conditions as reasonable.
You probably feel similar, and I believe that we just disagree on what is
reasonable :-).

>[...]
>>I see the GPL as an ideal that if studied, is very scarey.  Socialism
>>is another such ideal.
>
>Careful, you're committing a logical fallacy here in trying to make a
>connection GPL <==> socialism. If you want to argue against one of
>them, showing the bad sides of the other won't do.
>
I wasn't calling GPL equivalent to socialism -- it is just that the two ideals
can be very scarey if carried out to their logical conclusion. (IMHO).  I think
that socialism is worse than GPL though, but that is off the topic.

>
>>I think that de-facto in both cases (BSD copyright or GPL) people
>>are giving away code.  The difference is that the BSD copyright is a
>>gift without strings, except one -- give credit where credit is due.
>>That credit costs maybe about 4-5k -- the source code as the GPL
>>implies, costs multi-megabytes!!!
>
>No it doesn't; you don't have to supply full source with every
>ten-byte utility, you have to _make source available_. Naming a
>publically available anon FTP site qualifies perfectly well; even an
>explicit notice (good for >= 3 years, mind) that you'll snail-mail
>anybody who wants it the source is good enough.
>
How can one guarantee the availablity of the site????  That sounds like
a significant encumberence to me.  My little special program that has
a very small special interest following might not be available on such
an FTP site for long.  I'd rather not deal with that encumberance.

>
>But even so, gzip'ped source trees tucked away on the last one in a
>set of distribution CD-ROM's do not hurt these days. Don't try to fool
>me that it does.
>
Hmmm...  There is quite a space crunch on the latest WC cdroms lately :-),
I guess that they will just need to press more of them.

>>Let me explain a case-in-point...  If someone makes a fancy mod to
>>the FreeBSD VM system thereby gaining a 50% performance increase and
>>makes it private, do you think that I cannot do the same???
>
>Maybe you can, I wouldn't know. If FreeBSD was GPL'ed, neither one of
>you could legally do that.
>
I wasn't meaning that I would make FreeBSD private -- I could easily reproduce
their work and keep it public.  It is NOT in my interest to take FreeBSD
private, since I use it as advertising like advertisers do for PBS.

>
>The GPL is more legalistic - it doesn't trust in the good intentions
>of a lot of people, it puts down in legal terms what you can and can't
>do, and if anybody does it anyway, they'll have _broken the law_.
>
Legalistic does not mean clear cut.  Legal language has been used to
be obscure at times (at least in the US.)

>
>So maybe you won't be able to do anything about it because you can't
>afford the lawyers. But if the BSD copyright doesn't make those same
>things explicit in much the same way, then even if you _could_ afford
>the lawyers, you wouldn't be able to do anything.
>At least the GPL tries.
>
GPL is definitely not a layman's contract -- but I can sure read the BSD
copyright.  It was written by lawyers (apparently) and is very very simple.
I am not sure all that GPL encumbers, and it would take a team of lawyers
for me to be conviced that I would not be setting myself up for some kind of
strange lawsuit.  BSD copyright is very short with very simple conditions.
Many people who gain more and more assets, become more risk adverse,
especially with very complicated licenses like GPL.


John
dyson@freebsd.org