Lauren@tgr.UUCP (11/28/84)
John, My homegrown versions of UUCP/mail/basic netnews are in good shape. As you know, it has taken me a LONG time to get everything working, since I did everything from scratch without any reference to Unix UUCP sources. If I'd known how hard it was going to be I never would have started, that's for sure. Anyway, I've been holding off release while I added functionality to the mail sending/reading/answering programs, including a good deal of 822 compatibility, special features for ARPANET/MILNET mail transfers, additional netnews handling functions, and loads of other similar niceties. There are three basic versions of the code. One is for Coherent (to be distributed by the people that sell Coherent). Another is for VMS (this one is supposed to be distributed by DEC but is on temporary hold). The third version is for MSDOS operating system based machines (this one I'll distribute myself unless someone makes me a terrific offer). Right now the only thing really holding up initial release of the MSDOS and Coherent versions is lack of installation and user level documentation. Initial releases will probably be made to some people with a "read.me" type doc for installation, since a lot of people have been putting pressure on me to release the MSDOS version even without nice looking docs and the code all seems to be working well. Yes, I hope to make some money from my code. I make no apologies for this. I decided to stop putting anything of much significance into the public domain. I made this decision after watching programs that I released into the P.D. get hopelessly mangled by "well-meaning" people who only succeeded in complicating and often breaking the code (then people would call ME asking why it didn't work!), and sometimes even sold by others without any reference to my original authorship. In any case, I plan to provide real support for my UUCP/mail/netnews package, and I hope to make enough to help reimburse me for the massive amount of unpaid time I put into the work. I'm a consultant and do not have a "steady" source of income, but I still have to pay the rent or the landlord will get very upset... Bye for now. --Lauren--
Dave_Farber <farber@udel-ee.ARPA> (11/28/84)
Ah come on. Can I get a copy of the dos uucp. I will get you very good pr i it all works (and I can manage the install)
brenda@orca.UUCP (12/02/84)
: "My homegrown versions of UUCP/mail/basic netnews are in good shape. As you know, it has taken me a LONG time to get everything working ... I've been holding off release while I added functionality ... Right now the only thing really holding up initial release is lack of installation and user level documentation." Lauren has been saying this for months now. A few years ago he was sending out messages just like this about Marc, the Unixy system for eight-bitters, until finally he admitted that it was never going to happen. Sounds like a lot of vaporware to me.
thomas@utah-gr.UUCP (Spencer W. Thomas) (12/06/84)
In article <687@ihnp4.UUCP> gjm@ihnp4.UUCP (Gary J. Murakami) writes: >3) Some features or products get put off for years due to various > reasons (scheduling, technical, political, etc.). Witness > paging in USG UNIX (which will come! -- someday!?!). We just got a letter yesterday announcing release of System V Release 2.2 (or some such) which has, among other things, paging!! Quote: "You can run processes up to 16 MB, even if your processor has only 2MB of real memory." =Spencer
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/06/84)
> We just got a letter yesterday announcing release of System V Release > 2.2 (or some such) which has, among other things, paging!! Oh, good. Now that the cat is out of the bag, I feel free to mention that the paging version of UNIX System V was supposed to be Beta testing about now. My guess is that the memory management scheme presented by AT&T staff at the last Usenix conference is being used; it was remarkably like DEC's (create/attach region, etc.), which means that a reasonable implementation can be achieved using almost any memory management architecture (including segmented architectures, PDP-11s, etc.). Now if they would only incorporate the 3B20A hooks for a distributed kernel using semaphores into the standard product, I for one would be a lot happier about UNIX's future.
mwm@ea.UUCP (12/06/84)
/***** ea:net.unix / orca!brenda / 1:04 am Dec 3, 1984 */ Lauren has been saying this for months now. A few years ago he was sending out messages just like this about Marc, the Unixy system for eight-bitters, until finally he admitted that it was never going to happen. Sounds like a lot of vaporware to me. /* ---------- */ The story was that MARC was cancelled because it wouldn't have sold in the face of IBM PClones & 68000 boxes. Probably true, but a lot of us who use 8-bit systems still curse everytime we think about MARC - not because it was vaporware (my beta version isn't to shabby), but because we can't get it. <mike
hansen@pegasus.UUCP (Tony L. Hansen) (12/08/84)
< We just got a letter yesterday announcing release of System V Release < 2.2 (or some such) which has, among other things, paging!! Quote: "You < can run processes up to 16 MB, even if your processor has only 2MB of < real memory." < < =Spencer From what I've been told, the system comes configured to work with processes with up to 24 bits of address space, hence the 16MB. If your machine (such as the Vax) will handle a larger address space, the kernel can be reconfigured easily [:-)] to handle address spaces of up to 32 bits (4GB). Tony Hansen pegasus!hansen
gjm@ihnp4.UUCP (Gary J. Murakami) (12/09/84)
I think that alot of us can speak in defense/support of Lauren.
1) ihnp4 has been talking to vortex for years, and vortex has been
running Lauren's uucp. Any problems that we've had in communication
have all been with ihnp4 (mostly load and hardware problems).
2) It takes time (measured in years) to get some products to market
(e.g., UNIX SVR2 and 4.2 BSD).
3) Some features or products get put off for years due to various
reasons (scheduling, technical, political, etc.). Witness
paging in USG UNIX (which will come! -- someday!?!).
4) Markets change -- 32 bit machines are now in vogue, and 16 bit
machines left 8 bit machines in the dust some years ago.
5) Lauren is just one person even if he appears to do the work of 10.
Uucp is just one of his many projects.
6) Lauren has been a valuable contributor to the network, with his
level head, good humor, willing consultation, and considerable
expertise. I value his opinions as well as his expertise. Most
companyies pay good money for what he shares freely.
7) ...
-Garywcs@ho95b.UUCP (Bill Stewart) (12/10/84)
> < We just got a letter yesterday announcing release of System V Release > < 2.2 (or some such) which has, among other things, paging!! Quote: "You > < can run processes up to 16 MB, even if your processor has only 2MB of > < real memory." > < > < =Spencer > > From what I've been told, the system comes configured to work with processes > with up to 24 bits of address space, hence the 16MB. If your machine (such > as the Vax) will handle a larger address space, the kernel can be > reconfigured easily [:-)] to handle address spaces of up to 32 bits (4GB). > > Tony Hansen > pegasus!hansen I've been using a pre-release version of System V Rel 2 Version 2 (Paging version for Vaxen) for several months; it's nice to see it's being released. The default system configuration allows the users to run 16Meg processes. This default is set because the AT&T 3B-20 computers have a 24-bit = 16-MB address space limitation. The instructions for raising the process size limit make it look easy, but my users haven't been running their larger-sized jobs recently so I haven't done it yet. I haven't done extensive benchmarking, but the system seems to be running about as fast as 4.1BSD did for the simulation programs that my users run. The major features that came along with this release are: paging handles multiple swap areas and allows deletion of swap areas. updates to sar, crash, shared memory, sdb works for old object files as well as new ones faster fork() loader enhancements a new magic number for directly pageable files. improved Fortran 77 MIL-STD-1753 functions provided better optimization command line options - getarg() file and record locking lockf() - the /usr/group standard, but permissive rather than mandatory locks (i.e. the function tells you the record/file is locked but you can ignore that and write over it anyway.) fcntl(2)- some flexible extensions to fcntl() for file locking. The release names I know about are: Unix System V Release 2.0 Version 2 -- for Vaxen Unix System V Release 2.0 Version 4 -- for 3B-20's. The official people to call for information are probably the Greensboro N.C. 800 number - 1-800-828-UNIX, or call your normal AT&T UNIX support people. (standard-disclaimer: I'm saying all the above stuff on my own and not as an official announcement from AT&T. However, most of it should be reasonably correct.) Bill -- Bill Stewart AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ...!ihnp4!ho95b!wcs
guy@rlgvax.UUCP (Guy Harris) (12/12/84)
> The major features that came along with this release are: > paging > handles multiple swap areas and allows deletion of swap areas. As did 4.1BSD. > faster fork() This is done with copy-on-write; there is a bug in the 11/750 that can cause problems with copy-on-write - it can't recover from a write-protection error on a page, so you can't copy the page, turn on write permission, and retry the instruction, under certain circumstances. I don't remember what the circumstances are, so it may be possible to avoid them by not using copy-on-write in all cases (it may have failed if the write-protected page was a stack page, so it may only do copy-on-write on the data area). > loader enhancements > a new magic number for directly pageable files. Magic number 0413, to be precise; I wonder why they chose that number? :-) :-) :-) :-) :-) > improved Fortran 77 > better optimization The "Product Overview" doesn't go into much detail; the only thing it mentions about optimizing is that "f77" now "properly invokes the processor control interface (PCI) when using the -O option", and later says that it now forbids "-O" and "-g" being specified together. Is this *real* optimization, of the sort people expect from Fortran compilers? > lockf() - the /usr/group standard, but permissive rather > than mandatory locks (i.e. the function tells you the > record/file is locked but you can ignore that and > write over it anyway.) Considering OS/360 and all its successors, and VMS, and, I suspect, lots of other OSes, only provide permissive locking, I think AT&T made the right decision. Implementing mandatory locks is equivalent to walking around with a large "KICK ME" sign taped to your back; the only way to prevent J. Random Cracker from locking "/etc/passwd" is to require write access on a file in order to lock it, which means a process which only needs (and only has) read access can't prevent a record from being written on while it's reading it. They say they'll implement the "enforced lock" feature of the "/usr/group" standard later - the 12/83 draft says that this is enabled by turning on the "S_ENFMT" bit for the file, and implies that most systems will rip off the set-GID bit and use it as the "enforced locking" bit for non-executable files. The documentation also says that they've bundled all the encryption/ decryption facilities, as used by "crypt(1)", the "crypt(3)" functions, and the various editors ("ed" and "ex/vi") into a library, and split off the source for that library, the "crypt(1)" command, and the encryption code for the editors. It implies that the encryption stuff is stubbed out in the standard C library. All this is due to the Wise and Powerful U.S. Government (may they be buried with their feet in the air like a turnip), State Department (according to the AT&T Product Overview) issuing "regulations restricting encryption/decryption software to customers in the U.S.A.". Lordy, they're even afraid of the dumb old "crypt(1)" algorithm that the editors also use, but which has been broken (see the latest UNIX issue of the BSTJ)! Anybody think that the term "intelligence" in the phrase "intelligence establishment" is inappropriate? Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
woof@hpfclm.UUCP (woof) (12/15/84)
> 1) ihnp4 has been talking to vortex for years, and vortex has been > running Lauren's uucp. Any problems that we've had in communication > have all been with ihnp4 (mostly load and hardware problems). What causes Lauren's articles to be submitted to the net from vortex!lauren and then from brl-tgr!Lauren? It's bothersome to have to read two copies of the same article... Steve Wolf [hplabs,ihnp4]!hpfcla!woof
bsa@ncoast.UUCP (12/25/84)
> Article <15100001@hpfclm.UUCP>, from woof@hpfclm.UUCP (woof) +---------------- | What causes Lauren's articles to be submitted to the net from vortex!lauren | and then from brl-tgr!Lauren? It's bothersome to have to read two copies | of the same article... The problem is with brl-tgr!. There's been discussion in other newsgroups about it; brl-tgr! is resending to Usenet anything that got gated from Usenet to the Arpanet. --bsa -- Brandon Allbery @ decvax!cwruecmp!ncoast!bsa (..ncoast!tdi1!bsa business) 6504 Chestnut Road, Independence, Ohio 44131 (216) 524-1416 Who said you had to be (a) a poor programmer or (b) a security hazard to be a hacker?