TUHS

tuhs@tuhs.org

61 participants
6532 discussions

by Doug McIlroy

> I'd love to see the docs on that early stuff and see if Joe Ossanna > added in his own magic or was he carrying forward earlier magic. Here are scans of non-unix roff in 1971: https://www.cs.dartmouth.edu/~doug/roff71/roff71 I also have 1969, but it's bedtime and that will have to wait. Relative numbers (+n), roman numerals, .ti, top and bottom margin settings, .po, running titles, tab settings, hyphenation and footnotes were not in Saltzer's runoff. Most other features were. Doug

5 years, 9 months

CB-UNIX tapes?

by Warner Losh

I found the following in the archive: To: cbunix23(a)yahoo.com Cc: Warren(a)plan9.bell-labs.com, Toomey(a)plan9.bell-labs.com, <wkt(a)tuhs.org> Subject: Re: cb/unix tapes From: Dennis Ritchie <dmr(a)plan9.bell-labs.com> Date: Tue, 15 Jul 2003 21:23:37 -0400 They've arrived on my doorstep; thanks, Larry. 9-track drives seem thin on the ground, but we'll see. Dennis Does anybody know what became of those tapes? I know it was 13 years ago, but it's one of the few sitings of CB-Unix tapes I could find... Warner

5 years, 9 months

Re: [TUHS] SCCS

by Norman Wilson

Well, if we're going to get into editor, erm, version-control wars, I'll state my unpopular opinion that SCCS and RCS were no good at all and CVS only pretended to be any good. Subversion was the first system I could stand using. The actual basis for that opinion (and it's just my opinion but it's not pulled out of hyperspace) is that the older systems think only about one file at a time, not collections of files. To me that's useless for any but the most-trivial programming (and wasn't non-trivial programming what spurred such systems?). When I am working on a non-trivial program, there's almost always more than one source file, and to keep things clean often means refactoring: splitting one file into several, merging different files, removing files that contain no-longer-useful junk, adding files that implement new things, renaming files. A revision-control system that thinks only about one file at a time can't keep track of those changes. To me that makes it worse than useless; not only can it not record a single commit with a single message and version number when files are split and combined, it requires extra work to keep all those files under version control at all. CVS makes an attempt to handle those things, but the effect is clunky in practice compared to successors like svn. One shouldn't underestimate the importance of a non-clunky interface. In retrospect it seems stupid that we didn't have some sort of revision control discipline in Research UNIX, but given the clunkiness of SCCS and RCS and CVS, there's no way most of us would have put up with it. Given that we often had different people playing with the same program concurrently, it would have taken at least CVS to meet our needs anyway. Norman `recidivist' Wilson Toronto ON

5 years, 9 months

Livermore software tools dist

by Arnold Robbins

See https://drive.google.com/file/d/0ByJs3HoO8aRVd1JlOGJWRlJhTDg/view which seems to be stuff from 1984 and 1988. I have no idea where it came from or anything else; I stumbled across it while looking for some other things. Thanks, Arnold

5 years, 9 months

Re: [TUHS] SCCS

by Jon Steinhart

George Michaelson writes: > What Larry and the other RCS haters forget is that back in the day, > when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W. > > because running forward edits on a base state of 1000 edits is slow. > Since the majority action is increment +1 on the head state the RCS > model, whilst broken in many ways > was FAST > > -G And also that RCS had a much friendlier interface.

5 years, 9 months

Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]

by Norman Wilson

John Reiser did do his own paging system for UNIX 32/V. I heard about it from friends at Bell Labs ca. 1982-83, when I was still running systems for physicists at Caltech. It sounded very interesting, and I would love to have had my hands on it--page cache unified with buffer cache, copy-on-write from the start. The trouble is that Reiser worked in a different group from the original UNIX crowd, and his management didn't think his time well spent on that work, so it never got released. I remember asking, either during my interview at the Labs or after I started work there, why the 4.1 kernel had been chosen instead of Reiser's. It had to do with maintainability: there were already people who could come in and hack on the Berkeley system, as well as more using it and maintaining it, whereas Reiser's system had become a unicorn. Nobody in 1127 wanted to maintain a VM system or anything much close to the VAX hardware. So the decision was to stick with a kernel for which someone else would do those things. Once I'd been there for a year or so and settled in, I found that I was actually looking after all that stuff, because I was really interested in it. (Which seemed to delight a lot of people.) Would we have ended up using Reiser's kernel had I been there a couple of years earlier? I don't know. It is in any case a shame that jfr's code never saw the light of day. I really hope someone can find it on an old tape somewhere and we can get it into the archive, if only because I'd love to look at it. Norman Wilson Toronto ON

5 years, 9 months

Re: [TUHS] systime

by jnc＠mercury.lcs.mit.edu

> From: Steve Simon > i went for a student placement there but didnt get it - i guess my long > hair (then) didn't fit as the interview seemed good. Maybe you seemed too honest! :-) Noel

5 years, 10 months

Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?

by Rudi Blom

Just to be precise and because I dislike loose ends :-) Found the XTI to TCP/IP diagram. It's even online! https://www.cs.auckland.ac.nz/references/unix/digital/APS2WDTE/TITLE.HTM Network Programmer's Guide © Digital Equipment Corporation 1994, 1995, 1996 All Rights Reserved. Product Version: Digital UNIX Version 4.0 or higher March 1996

5 years, 10 months

Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]

by Rudi Blom

I don't remember from where I got the scheme, so it might be general, DigitalUnix, or HP-UX related. Checking the "HP 9000 networking XTI programmer's guide" from 1995 there's no diagram. The application which was initially developed on a SystemV derived UNIX the Computer division of Philips Electronics had bought, used TLI. Taken over by DEC we moved to SCO UNIX still using TLI, moving to XLI on Alpha/Digital Unix. The nice thing of TLI/XLI is the poll(). A multi-client server can check a list of file descriptors AND indicate a timeout value for the poll(). Like in ret_cd = poll(tep->CEPlist, tep->CEPnumb, timeout); BTW putting in a bit of OSI, on SCO UNIX I use a DEC package which offers a TLI interface to an OSI TP4/IP stack. Even worked using X.25 as WAN. OSI TP4 and NetBIOS originally bought from Retix. >Date: Sat, 31 Aug 2019 11:41:40 -0400 >From: Clem Cole <clemc(a)ccc.com> >To: Rudi Blom <rudi.j.blom(a)gmail.com> >Cc: tuhs <tuhs(a)minnie.tuhs.org> >Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?] >Message-ID: > <CAC20D2MJPFoU6r73U9GDaqG+Q7vpH3T7CiDNjgN3D2uyuAJgLQ(a)mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >It's the Mentant implementation that HP originally bought. At LCC we had >to hacked on it a bit when we put Transparent Network Computing (TNC) stuff >in HP-UX [we had full process migration working BTW -- A real shame that >never shipped]. >On Sat, Aug 31, 2019 at 5:44 AM Rudi Blom <rudi.j.blom(a)gmail.com> wrote: >> Whenever I hear UNIX, networking and streams I have to think about this >> scheme. >> >> Still using this, even on HP-UX 11.31 on Itanium rx-servers >> >> Cheers, >> uncle rubl

5 years, 10 months

ISO, OSI, and DECnet (was Re: If not Linux, then what?)

by Paul Winalski

On 8/28/19, Clem Cole <clemc(a)ccc.com> wrote: > On Wed, Aug 28, 2019 at 2:46 AM Peter Jeremy <peter(a)rulingia.com> wrote: > > Tru64 talked to DECnet Phase X (I don't remember which one, maybe 4 or 5), > which had become an ISO/OSI stack by that point for political reasons > inside of Digital (the OSI vs TCP war reminded me of the Pascal vs C and > VMS vs UNIX wars - all very silly in retrospect, but I guess it was really > about who got which $s for development). It was DECnet Phase V that was based on the ISO/OSI stack. IIRC, at the time the European telcos were pushing OSI, it had become an ISO standard, etc. etc. It was also pretty easy to compatibly slide the legacy proprietary DECnet Phase IV adaptive routing and virtual circuit layers into the OSI stack. TCP won the war, of course. The risk with international standards fashioned out of whole cloth by a committee (as opposed to being a regularization of existing practice) is that the marketplace may choose to ignore the "standard". OSI and the Ada programming language are cases in point. -Paul W.

5 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS