Path: sparky!uunet!sunquest!venus.sunquest.com!terry From: te...@venus.sunquest.com (Terry R. Friedrichsen) Newsgroups: comp.unix.bsd Subject: Sigh - now it'll *never* be free Summary: CSRG disbanding as of 4.4BSD Keywords: 4.4BSD CSRG Message-ID: <41950@sunquest.UUCP> Date: 12 Jun 92 18:33:51 GMT Sender: n...@sunquest.UUCP Followup-To: comp.unix.bsd Distribution: usa Organization: Sunquest Information Systems, Tucson Lines: 27 I just read a report that CSRG is *disbanding* with the 4.4BSD release, which the report says will be released fairly soon. According to this report, the release will still be burdened with USL kernel sources. Can anyone comment on the accuracy of this report? If true, this greatly saddens me. It looks like I have just lost any chance of running BSD free with sources on my DECstation. I was really looking forward to running an operating system with full source code again ... Does anyone see any chance that either of the 386-style BSDs discussed here will ever be upgraded to run on real computers? ;-) (Please, PLEASE note that the above remark was made in jest. I greatly applaud the efforts of both groups to bring full Unix OS sources to the masses. I do not mean to denigrate their massive efforts AT ALL (I only mean to denigrate the 386 :-).) Terry R. Friedrichsen te...@venus.sunquest.com (Internet) uunet!sunquest!terry (Usenet) te...@sds.sdsc.edu (alternate address; I live in Tucson)
Path: sparky!uunet!spool.mu.edu!agate!boulder!ophelia.cs.colorado.edu!drew From: d...@ophelia.cs.colorado.edu (Drew Eckhardt) Newsgroups: comp.unix.bsd Subject: Re: Sigh - now it'll *never* be free Keywords: 4.4BSD CSRG Message-ID: <1992Jun15.202726.21177@colorado.edu> Date: 15 Jun 92 20:27:26 GMT Article-I.D.: colorado.1992Jun15.202726.21177 References: <41950@sunquest.UUCP> Sender: n...@colorado.edu (The Daily Planet) Distribution: usa Organization: University of Colorado at Boulder Lines: 44 Nntp-Posting-Host: ophelia.cs.colorado.edu In article <41...@sunquest.UUCP> te...@venus.sunquest.com (Terry R. Friedrichsen) writes: >I just read a report that CSRG is *disbanding* with the 4.4BSD release, This is correct. Funding problems, the loss of both Karels and Bostic (Keith just got married, and is moving out of state. Berkeley will not allow him to telecommute), and the political situation all have taken their toll. >which the report says will be released fairly soon. According to this Kirk said ~1 month for an alpha, at the BSD BOF at Summer USENIX. >report, the release will still be burdened with USL kernel sources. Technically, this is correct too. There will be a 4.4bsd, requiring at least a 32V license, as well as a 4.4bsd lite, or a net3 if you will - in the same state as net2 as far as detoxification. The CSRG folk's opinion they gave at the BSD BOF was that allthough the Jolitz, etc work isn't there, and can't be because of political considerations, anyone can get it off the net and can fill in missing pieces. >Can anyone comment on the accuracy of this report? It's very accurate, only missing the details. >If true, this greatly saddens me. It looks like I have just lost any >chance of running BSD free with sources on my DECstation. I was really >looking forward to running an operating system with full source code >again ... > >Does anyone see any chance that either of the 386-style BSDs discussed >here will ever be upgraded to run on real computers? ;-) There are seven files missing, for which should be able to get the Jolitz stuff to work. This is not on the standard distribution because Berkeley requires all contributors to sign a release, and given the situation between Jolitz and Berkeley, this will not happen. The decsstation 3000 and 5000 serties will be supported platforms - I don't remember if they will make the alpha tape or not.
Path: sparky!uunet!spool.mu.edu!agate!pasteur!hermes.Berkeley.EDU!bostic From: bos...@hermes.Berkeley.EDU (Keith Bostic) Newsgroups: comp.unix.bsd Subject: Re: Sigh - now it'll *never* be free Keywords: 4.4BSD CSRG Message-ID: <1992Jun17.001544.4017@pasteur.Berkeley.EDU> Date: 17 Jun 92 00:15:44 GMT Article-I.D.: pasteur.1992Jun17.001544.4017 References: <41950@sunquest.UUCP> <1992Jun15.202726.21177@colorado.edu> Sender: n...@pasteur.Berkeley.EDU (NNTP Poster) Distribution: usa Organization: University of California at Berkeley Lines: 53 Nntp-Posting-Host: hermes.berkeley.edu A couple of comments: In article <1992Jun15.202726.21...@colorado.edu> d...@ophelia.cs.colorado.edu (D rew Eckhardt) writes: > Technically, this is correct too. There will be a 4.4bsd, requiring > at least a 32V license, as well as a 4.4bsd lite, > or a net3 if you will - in the same state as net2 as > far as detoxification. The CSRG folk's opinion they gave > at the BSD BOF was that allthough the Jolitz, etc work > isn't there, and can't be because of political considerations, > anyone can get it off the net and can fill in missing pieces. 4.4BSD-Lite does have some new, freely redistributable software, including C library modules, include files and utilities, among them dd, init and join. It may have an implementation of ex/vi, but the odds are currently against that happening. > There are seven files missing, for which should be able to get the Jolitz > stuff to work. This is not on the standard distribution because > Berkeley requires all contributors to sign a release, and given > the situation between Jolitz and Berkeley, this will not > happen. This isn't right, and needs to be corrected. Bill Jolitz, Pace Willison and others have already offered to contribute their versions of the missing modules to the CSRG to make the distribution complete. We have chosen not to include them for the following reasons. The first reason is that it would take a significant amount of time to make them work in our current system. Time that we just don't have. The NET/2 release, from which the free 386 releases are derived, was a year ago. Our system has changed in many significant ways. As an example, we've added a version of Sprite's log-structured file system, LFS. LFS uses the buffer cache code in very "interesting" ways. Ways that it was never intended to be used. It took weeks to get the bugs out of the current LFS/buffer cache interface, and I'm not eager to do it twice, especially not a few weeks before a release. The second reason is that we don't want reimplementations of the current missing functionality. Buffer caches were great for 1972, but for 1992 I want a "buffer cache" that's fully integrated with the VM. The same goes for exec, ptrace and the other missing functionality. Finally, we expect that the groups that replaced the missing functionality in NET/2 will immediately reintegrate their source into the system, and they can probably do it as least as quickly as we can! So, given that the CSRG's resources are extremely limited, the choice was between reimplementing already existing, working functionality and making the rest of the system correct and stable. Since the CSRG will be going away we felt that the latter was more important. --keith
Newsgroups: comp.unix.bsd Path: sparky!uunet!cs.utexas.edu!utgpu!torn!watserv1!wes.on.ca!tomh From: t...@wes.on.ca (Tom Haapanen) Subject: Re: Sigh - now it'll *never* be free -- and ex/vi Organization: Waterloo Engineering Software Distribution: na Date: Wed, 17 Jun 1992 12:10:39 GMT Message-ID: <1992Jun17.121039.19472@wes.on.ca> Keywords: 4.4BSD CSRG References: <41950@sunquest.UUCP> <1992Jun15.202726.21177@colorado.edu> <1992Jun17.001544.4017@pasteur.Berkeley.EDU> Lines: 19 bos...@hermes.Berkeley.EDU (Keith Bostic) writes: > 4.4BSD-Lite does have some new, freely redistributable software, including > C library modules, include files and utilities, among them dd, init and > join. It may have an implementation of ex/vi, but the odds are currently > against that happening. Never having looked at the source for ex/vi (while I had BSD source access), I'm not really on firm ground here, but would it be foolish to assume that some (most?) of the source modules for ex/vi would by now be free of AT&T copyrights? And, if so, couldn't the free source modules be distributed in the manner of NET/2, so that net.volunteers could complete a "real" free vi (just like the 386BSD and Linux projects are being done)? It's nice to have stevie, vile and elvis, but they're not quite complete, and definitely not as robust as the real thing... [ \tom haapanen "i don't even know what street canada is on" -- al capone ] [ t...@wes.on.ca "trust the programmer" -- ansi c standard ] [ waterloo engineering software "to thine own self be true" -- polonius ]
Newsgroups: comp.unix.bsd Path: sparky!uunet!wupost!think.com!ames!agate!pasteur!hermes.Berkeley.EDU!bostic From: bos...@hermes.Berkeley.EDU (Keith Bostic) Subject: Re: Sigh - now it'll *never* be free -- and ex/vi Message-ID: <1992Jun18.164531.10222@pasteur.Berkeley.EDU> Keywords: 4.4BSD CSRG Sender: n...@pasteur.Berkeley.EDU (NNTP Poster) Nntp-Posting-Host: hermes.berkeley.edu Organization: University of California at Berkeley References: <1992Jun15.202726.21177@colorado.edu> <1992Jun17.001544.4017@pasteur.Berkeley.EDU> <1992Jun17.121039.19472@wes.on.ca> Distribution: na Date: Thu, 18 Jun 1992 16:45:31 GMT Lines: 50 In article <1992Jun17.121039.19...@wes.on.ca> t...@wes.on.ca (Tom Haapanen) writes: >bos...@hermes.Berkeley.EDU (Keith Bostic) writes: >> 4.4BSD-Lite does have some new, freely redistributable software, including >> C library modules, include files and utilities, among them dd, init and >> join. It may have an implementation of ex/vi, but the odds are currently >> against that happening. > >Never having looked at the source for ex/vi (while I had BSD source access), >I'm not really on firm ground here, but would it be foolish to assume that >some (most?) of the source modules for ex/vi would by now be free of AT&T >copyrights? And, if so, couldn't the free source modules be distributed >in the manner of NET/2, so that net.volunteers could complete a "real" free >vi (just like the 386BSD and Linux projects are being done)? Yes, most of the sources for ex/vi are freely redistributable, but the original file buffering code is clearly derived from ed(1). A couple of other things are tainted as well. The difficulty in doing what you suggest is that ex/vi is an incredibly convoluted beast. Trying to isolate the specific portions that are tainted would be difficult, to say the least. And, even if the tainted portions were identified, removing them without reimplementing the entire program would be even more difficult as they include the fundamental ex/vi data structures. --keith Vi trivia time: Q: When is the command "2x" not the same as "xx"? Q: What does the command "3y4y" do? Q: If the cursor is on the last character in a line, is the "l" command ever legal? Q: When is the command "4e" not the same as "eeee"? Q: In the line "abc def ghi jkl", with the cursor on the 'd', the command "dfg" will delete up to, and including, the 'g'. The command "dtg" will delete up to, but not including, the 'g'. What does the command "d/g<CR>" do? Q: What is the movement command that, when there are no more of it's searched for conditions in the file, goes to the beginning of the last line, not the end? Q: What are the three (yes, three) conditions where a join does not insert white-space between the two lines being joined?