hak@cooper.cooper.EDU (Jeff Hakner ) (09/30/89)
Perhaps there is any incredibly simple explanation.
Perhaps not. Simply put, here is my question:
Are the BSD sources, archived @uunet, among other places,
the sources to actual, working, tested programs?
Allow me to elaborate:
I obtained the source to ftpd from uunet's bsd-sources
directory. To my surprise, ftpd.c didn't even compile! The problem
was several little scratch variables which were used but never declared.
The code was of recent vintage (Feb 89). Then, just the other day,
I was looking at telnetd, and found this shocker:
.
.
.
if (fmt = wont ) {
....
} else {
...
}
(telnetd.c 5.31 (Berkeley) 2/23/89) (line 999)
So:
1) Why are these bugs there? Is this the "correct"
source for BSD.
2) If not, where can I get it?
3) If so, WTF?
Jeff Hakner
Cooper Union
New York
hak@meagan.cooper.edu
pokey@well.UUCP (Jef Poskanzer) (09/30/89)
Yep, software has bugs. Imagine that.
---
Jef
Jef Poskanzer pokey@well.sf.ca.us {ucbvax, apple, hplabs}!well!pokey
Sanitized for your protection.henry@utzoo.uucp (Henry Spencer) (09/30/89)
In article <1802@cooper.cooper.EDU> hak@cooper.cooper.EDU (Jeff Hakner ) writes: > Are the BSD sources, archived @uunet, among other places, > the sources to actual, working, tested programs? Uh, this may come as a surprise, but universities generally do not have quality-control departments. Alas. And considering some of the screwups that come out of places that *have* QC departments, like Sun, it should not be surprising that free software is sometimes worth what it costs. (Fortunately, it's *usually* worth more.) -- "Where is D.D. Harriman now, | Henry Spencer at U of Toronto Zoology when we really *need* him?" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dls@mentor.cc.purdue.edu (David L Stevens) (09/30/89)
I think if Jef P. had read the article he's being sarcastic about, he'd realize that "software has bugs" isn't quite so clever an answer. I got some kernel source for IP/ICMP's record & source route options from this archive a while back and I found that it wouldn't even compile, either, because of minor missing declarations and couple lines of missing code. It was pretty obvious and quickly fixed, but it is bizarre that someone would include compile-time errors in a distribution source. On the other hand, it's free and very useful. It just takes away a little confidence when the code you get doesn't compile and so you're certain nobody's every tested exactly that version-- also certain it ISN'T the one they really run at Berkeley. Just close. -- +-DLS (dls@mentor.cc.purdue.edu)
chris@mimsy.UUCP (Chris Torek) (10/01/89)
>In article <1802@cooper.cooper.EDU> hak@cooper.cooper.EDU (Jeff Hakner) writes: >>Are the BSD sources, archived @uunet, among other places, >>the sources to actual, working, tested programs? In article <1989Sep30.060807.15103@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Uh, this may come as a surprise, but universities generally do not have >quality-control departments. *I* am the quality control department, or at least Kirk, Mike, and Keith [both Keiths] sometimes think so :-) . More seriously: the basic problem here is that the stuff on uunet is built by taking the current source and back-converting it (applying changes to old revisions in the SCCS files). Code built this way is hard to test, because Berkeley CSRG no longer have machines running 4.3BSD-tahoe on which to test them. It does seem, though, that someone should at least run them once through `cc' to check for syntax errors. Also (quite seriously) in many cases it is a matter of getting work done. CSRG are just five people; they simply do not have time to test everything released this way. These fixes only get out because Keith Bostic uses his `spare' time to slap them together and ship them off. If he took much more time for them, nothing else would get done. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bt455s39@uhccux.uhcc.hawaii.edu (Carmen Hardina) (10/01/89)
In article <4281@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: [...] > I got some kernel source for IP/ICMP's record & source route options >from this archive a while back and I found that it wouldn't even compile, >either, because of minor missing declarations and couple lines of missing >code. It was pretty obvious and quickly fixed, but it is bizarre that someone >would include compile-time errors in a distribution source. > On the other hand, it's free and very useful. It just takes away a >little confidence when the code you get doesn't compile and so you're certain >nobody's every tested exactly that version-- also certain it ISN'T the one >they really run at Berkeley. Just close. >-- > +-DLS (dls@mentor.cc.purdue.edu) Sometimes it *is* identical to the unpublished proprietary source. For instance, the freely redistributable version (5.3 (Berkeley) 6/29/88) of mkstr.c from the 4.3BSD-Tahoe release of Berkeley UNIX (which is what UUNET post in their archives) is exactly the same as the proprietary version (5.1 (Berkeley) 5/31/85) of mkstr.c, with the expection of the SCCS info and redistribution rights. Just an observation... --Carmen -- Carmen Hardina, Assistant System Administrator INET: islenet!manapua!carmen@uhccux.uhcc.Hawaii.Edu UUCP: {uunet,ucbvax,dcdwest}!ucsd!nosc!uhccux!islenet!manapua!carmen
bt455s39@uhccux.uhcc.hawaii.edu (Carmen Hardina) (10/01/89)
In article <19900@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: [....] >Also (quite seriously) in many cases it is a matter of getting work >done. CSRG are just five people; they simply do not have time to test >everything released this way. These fixes only get out because Keith >Bostic uses his `spare' time to slap them together and ship them off. >If he took much more time for them, nothing else would get done. I really appreiate the fact that time is made to distribute these versions. Without them, most people would rarely get a chance to see Berkeley source code. Thanks again Keith! :-) --Carmen -- Carmen Hardina, Assistant System Administrator INET: islenet!manapua!carmen@uhccux.uhcc.Hawaii.Edu UUCP: {uunet,ucbvax,dcdwest}!ucsd!nosc!uhccux!islenet!manapua!carmen
guy@auspex.auspex.com (Guy Harris) (10/01/89)
>Sometimes it *is* identical to the unpublished proprietary source. >For instance, the freely redistributable version (5.3 (Berkeley) 6/29/88) >of mkstr.c from the 4.3BSD-Tahoe release of Berkeley UNIX (which is what >UUNET post in their archives) is exactly the same as the proprietary version >(5.1 (Berkeley) 5/31/85) of mkstr.c, with the expection of the SCCS info and >redistribution rights. Just an observation... ...and one based on the assumption that the old code actually *was* proprietary; in many cases, the only reason it didn't have the redistribution stuff is either that: 1) they hadn't actually sat down and checked that there wasn't any AT&T code or 2) they hadn't invented the redistribution rights comment yet.
epsilon@wet.UUCP (Eric P. Scott) (10/01/89)
A more likely explanation is that there are two different public places on uunet where BSD networking stuff is stored. There are two ftpd sources. The "version 4.xxx" is GARBAGE. The "version 5.xxx" is "almost" a working copy. You have to look in both "bsd-sources" and "networking" to find which is where. I sent some fixes to Rick Adams (not because he's Mr. UUNET, but because he's been enhancing ftpd) a few months back. I don't know if they ever made it into the released stuff, though. -=EPS=-
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (10/02/89)
There have been a number of recent postings about the relationship between the source code on uunet.uu.net and various BSD releases and bugs found in the code. > Are the BSD sources, archived @uunet, among other places, > the sources to actual, working, tested programs? Pretty much. The BSD programs on uunet come from three possible sources. The first is the 4.3BSD-tahoe release, which was an interim release last year. The second is the BSD networking release of this spring. The third is piecemeal from Berkeley. Unfortunately, none of these methods involved real release engineering of the kind that 4.3BSD was subject to. Release engineering is hard to do well, takes a lot of time, and isn't all that much fun. (As an example, when 4.3BSD was being prepared for release, members of CSRG checked *every* entry in the SCCS logs to make sure it was both reasonable and, if necessary, documented. For more details read Kirk McKusick's paper "The Release Engineering of 4.3BSD" from the April USENIX Software Management Workshop Proceedings.) Anyhow, we generally put release engineering off until we're ready for a "final" version of the software, in this case, 4.4BSD. Vendors and other organizations don't want to wait for the final release, so Berkeley has historically done intermediate releases to make the software available to other development groups. These releases aren't snapshots, i.e. they've run for extended periods of time on a few machines, but they haven't gone through extensive beta cycles either. The large majority of the code on uunet comes from the 4.3BSD-tahoe release, is fairly well tested and has been run in the configuration in which it is presented. Code from the networking release is well tested, but has never been run in the configuration in which it is presented. This is because networking is a current research area at Berkeley and getting a coherent snapshot of our networking sources is somewhere between difficult and impossible. This is the reason that the code as distributed didn't compile -- we were trying to merge a number of versions of the software and it didn't quite work. (We apologize for that, by the way, and the next version will, at least, compile!) The final category is usually due to a significant security problem or simply because enough people have asked us for copies of the code that I've asked Rick Adams to add it to his sources so that we can direct people to uunet rather than email'ing out the source tree each week. Ftp and dbx are good examples of this. In general, this code is the least well tested, although you can be sure that it compiles and has been run -- for at *least* twenty minutes. These versions are usually copies of what we are currently running on our development machines, which causes problems in and of itself. For example, our method of doing Makefiles has recently been reworked and include files often change over time. > Sometimes it *is* identical to the unpublished proprietary source. > For instance, the freely redistributable version (5.3 (Berkeley) 6/29/88) > of mkstr.c from the 4.3BSD-Tahoe release of Berkeley UNIX (which is what > UUNET post in their archives) is exactly the same as the proprietary version > (5.1 (Berkeley) 5/31/85) of mkstr.c, with the exception of the SCCS info and > redistribution rights. Just an observation... As part of the process of identifying non-AT&T portions of our distribution, we occasionally simply change the copyright notice. Copyrights from Berkeley fall into three categories. Code from 32V which has not been modified: this code has whatever copyright notice that AT&T had on it when we got it, usually none. Code from 32V which has been modified at Berkeley: /* * Copyright (c) 1988 Regents of the University of California. * All rights reserved. The Berkeley software License Agreement * specifies the terms and conditions for redistribution. */ Code which has been written at Berkeley and is not proprietary to any vendor: /* * Copyright (c) 1989 The Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ Until about a year or so ago we did not distinguish between the second and third cases, they both got the "see the Berkeley License for details" version of the copyright. That is why you can find source code where that copyright notice has simply been replaced with the "freely redistributable" version without software modification. --keith
chrisp@hcr.UUCP (Chris Phillips) (10/04/89)
In article <1989Sep30.060807.15103@utzoo.uucp> henry@utzoo.UUCP writes: >In article <1802@cooper.cooper.EDU> hak@cooper.cooper.EDU (Jeff Hakner ) writes: >> Are the BSD sources, archived @uunet, among other places, >> the sources to actual, working, tested programs? > >Uh, this may come as a surprise, but universities generally do not have >quality-control departments. Alas. And considering some of the screwups >that come out of places that *have* QC departments, like Sun, it should >not be surprising that free software is sometimes worth what it costs. >(Fortunately, it's *usually* worth more.) >-- >"Where is D.D. Harriman now, | Henry Spencer at U of Toronto Zoology >when we really *need* him?" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu I guess that the original question still needs an answer. Yes that bug is in code as delivered from bsd. -- Chris Phillips, Hcr Corp.,1001 "A wise old owl sat in an oak, 130 Bloor St W,Toronto Ontario The more he heard the less he spoke, Bell: (416) 922-1937 M5S 1N5 The less he spoke the more he heard, CIS : 75026,3673 CANADA Why aren't we all like that wise old bird?" UUCP: {utzoo,utcsri,ihnp4}!hcr!chrisp <Traditional childrens verse>