TUHS

tuhs@tuhs.org

48 participants
6504 discussions

by William Corcoran

Hello TUHS on Tues., Warren Toomey suggested I let the group know about a utility that exists at least for iMacs and IOS devices. It’s called “cathode” and you can find it on the Apple App Store. Please forgive me if this has already been mentioned. This utility provides for an xterm window that looks like the display an old *tube. You can set the curvature of the glass, the glow, various scan techniques, 9600 speed, and so on. It adds that extra dimension to give the look and feel of working on early UNIX with a tube. I would love to see profiles created that match actual ttys. My favorite tube is the Wyse 50. Another, one I remember is a Codex model with “slowopen” set in vi. Remember how early UNIX terminals behaved with slowopen, right? The characters would overtype during insert mode in vi, but when you hit escape, the line you just clobbered reappears shifting the remaining text as appropriate to the right. Cathode adds a little spice, albeit artificially, to the experience of early UNIX. Truly, Bill Corcoran (*) For the uninitiated, we used to call the tty terminal a “tube.” For example, you might hear my boss say, “Corcoran, that cheese you hacked yesterday launched a runaway that’s now soaking the client’s CPU. Go jump on a free tube and fix it now!”

5 years, 8 months

PiDP-11 in action!

by Adam Thornton

https://share.icloud.com/photos/0MKJjk8pRBvkZAEzaobjfOyPQ I start v7 Unix and play "Hunt The Wumpus". (I finally got it put together this weekend, and fixed the last couple dodgy joints tonight). Adam

5 years, 8 months

Re: [TUHS] block operations in editors, was My EuroBSDcon talk

by Doug McIlroy

Noel Chiappa wrote: > > From: Doug McIlroy > > > the absence of multidemensional arrays in C. > >?? From the 'C Reference Manual' (no date, but circa 'Typesetter C'), pg. 11: > > "If the unadorned declarator D would specify an n-dimensional array .. then > the declarator D[in+1] yields an (n+1)-dimensional array" > > >I'm not sure if I've _ever_ used one, but they are there. Yes, C allows arrays of arrays, and I've used them aplenty. However an "n-dimensional array" has one favored dimension, out of which you can slice an array of lower dimension. For example, you can pass a row of a 2D array to a function of a 1D variable, but you can't pass a column. That asymmetry underlies my assertion. In Python, by contrast, n-dimensional arrays can be sliced on any dimension. Doug

5 years, 8 months

Re: [TUHS] earliest Unix roff

by Doug McIlroy

> Excellent - thanks for the pointer. This shows nroff before troff. > FWIW: I guess I was miss informed, but I had been under the impression > that was the other way around. i.e. nroff was done to be compliant with > the new troff, replacing roff, although the suggestion here is that he > wrote it add macros to roff. I'll note that either way, the dates are all > possible of course because the U/L case ASR 37 was introduced 1968 so by > the early 1970's they would have been around the labs. nroff was in v2; troff appeared in v4, which incidentally was typeset in troff. Because of Joe Ossanna's role in designing the model 37, we had 37's in the Labs and even in our homes right from the start of production. But when they went obsolete, they were a chore to get rid of. As Labs property, they had to be returned; and picking them up was nobody's priority. Andy Hall had one on his back porch for a year. Doug

5 years, 8 months

Re: [TUHS] block operations in editors, was My EuroBSDcon talk

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > the absence of multidemensional arrays in C. ?? From the 'C Reference Manual' (no date, but circa 'Typesetter C'), pg. 11: "If the unadorned declarator D would specify an n-dimensional array .. then the declarator D[in+1] yields an (n+1)-dimensional array" I'm not sure if I've _ever_ used one, but they are there. Noel

5 years, 8 months

[tuhs] Computer history preservation

by Nelson H. F. Beebe

A major topic on this list has been the preservation of computer history, through museums that collect and operate old hardware, software emulation of past hardware and software systems, and data recovery from newly discovered, but previously thought to be lost, archives. I came across an article today about another major industry that has been exceedingly careless about preserving its history: Wipe Out: When the BBC Kept Erasing Its Own History https://getpocket.com/explore/item/wipe-out-when-the-bbc-kept-erasing-its-o… It is a must-read for Dr Who fans on this list. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

5 years, 8 months

Re: [TUHS] block operations in editors, was My EuroBSDcon talk

by Thomas Paulsen

--------------------------------- > > Though the vi clone with the best name was, indisputably, elvis. > unfortunately unmaintained. elvis has a smaller memory footprint, and a more pleasant (nroff later html) based help support than vim. There are no plugin, vimscript feature sas well as no python/perl support. I'm interested in a vi with syntax coloring and help support, however I don't need scripting features. Therefore I hope someone will take over maintenance, as I'm too old for tha

5 years, 8 months

block operations in editors, was My EuroBSDcon talk

by Doug McIlroy

> The "block copy in an editor" thing is something which has intrigued > me for years. poor old ed/ex/vi just couldn't do it, and for the life > of me, I could not understand why this was "deprecated" by the people > writing that family of editors. One might trace it to the founding tenet that a file is a stream of bytes, reinforced by the absence of multidemensional arrays in C. But it goes deeper than that. Ed imposes a structure, making a (finite) file into an array, aka list, of lines. It's easy to define block moves and copies in a list. But what are the semantics of a block move, wherein one treats the list as a ragged-right 2D array? What gets pushed aside? In what direction? How does a block move into column that not all destination rows reach? How do you cope when the bottom gets ragged? How about the top? Can one move blocks of tab-separated fields? I think everyone has rued the lack of block operations at one time or another. But implementing them in any degree of generality is a stumbling block. What should the semantics be? > Similarly the 'repeat this sequence of commands' thing which emacs had. Ed's g command does that, except the sequence can't contain another g. Sam, barely harder than ed to learn, cures that deficiency and generalizes in other ways, too--but has no block operations. Doug

5 years, 8 months

Re: [TUHS] [SPAM] Re: SCCS

by Norman Wilson

Peter Jeremy: > NFS ran much faster when you turned off the UDP checksums as well. > (Though there was still the Ethernet CRC32). Dave Horsfall: Blerk... That just tells you that the packet came across the wire more or less OK. ===== UDP (and TCP) checksums are nearly useless against the sort of corruption Larry described. Since they are a simple addition with carry wraparound, you can insert or remove any number of word-aligned pairs of zero octets without the checksum changing. I discovered this the hard way, while tracking down a kernel bug that caused exactly that sort of corruption. Does IPv6 require a meaningful checksum, or just the useless old ritual one? Norman Wilson Toronto ON

5 years, 8 months

Fwd: Re: earliest Unix roff

by Steffen Nurpmeso

Sorry, i said "yes" to the false question. --- Forwarded from Steffen Nurpmeso <steffen(a)sdaoden.eu> --- Date: Mon, 16 Sep 2019 21:12:28 +0200 From: Steffen Nurpmeso <steffen(a)sdaoden.eu> To: chet.ramey(a)case.edu Subject: Re: [TUHS] earliest Unix roff Message-ID: <20190916191228.1YQHs%steffen(a)sdaoden.eu> OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt Chet Ramey wrote in <95916cf9-9aa1-f949-0f37-0ae466e38aa2(a)case.edu>: |On 9/16/19 8:10 AM, Clem Cole wrote: |> I use the standalone Info reader (named info) if I want to look \ |> at the |> Info output. |> |> Fair enough, but be careful, while I admit I have not looked in a while, |> info(gnu) relies on emacs keybindings and a number of very emacs'ish th\ |> ings. |> Every time I have tried to deal with it, I have unprogram my fingers and |> reset them to emacs. |> |> If it would have used more(1) [or even less(1)] then I would not \ |> be as annoyed. | |It seems to me that the strength of info (the file format and program) is |the navigation of a menu-driven hierarchical document containing what are |essentially selectable links between sections. Something like more or less |is poorly suited to take advantage of those features. But you can do that in man macros with a normal pager like less(1), too. I mean, i may bore people, but yes i have written a macro extension for the mdoc macros which can be used to generate a TOC, and which generates document local as well as links to external manual pages. This works for all output formats, but particularly well for those which support links themselves, HTML, PDF as well as grotty, the TTY output device of groff. There was a feature request, but it has not been included yet. (My own port of roff where it will ship out of the box i just do not find time for, but i said to myself that after having banged my head a thousand times against the wall of a totally f....d up software code base, if i maintain yet another free software project then this time i do not release anything until i can say i am ready.) You can see the manual page online if you want to, it is at [1] (and itself the HTML output of a manual which uses the macro). Nothing magic, it is just that the grotty device then uses backspace escape sequences not only to embolden or otherwise format text, but also to invisibly embed content information. And a patched less(1) can search for these specially crafted backspace sequences easily, in fact i use that each and every time when i look at the manual page of the MUA i maintain, which is even longer than the bash manual. The patch for less is pretty small, even though it cares for less conventions: #?0|kent:less.tar_bomb_git$ git diff master..mdocmx|wc -l 413 [1] https://www.sdaoden.eu/code-mdocmx.html It has the deficite of not being able to dig macros as part of headers, e.g. "HISTORY ON less(1)" where less(1) would be an external link, this cannot work out the way the mdoc macros are implemented in groff. They would need to become rewritten, but no time for that yet. Other than that it works just fine for half a decade, for development i have mdoc() ( MDOCMX_ENABLE=1 \export MDOCMX_ENABLE \: ${MDOCMXFLAGS:=-dmx-toc-force=tree} \mdocmx.sh "${1}" | \s-roff -Tutf8 -mdoc ${MDOCMXFLAGS} | LESS= \s-less --RAW-CONTROL-CHARS --ignore-case --no-init ) where s-roff and s-less are the patched version. This is the development version, the nice property of mdocmx is that the preprocessing step can be shipped, in fact it is for half a decade, too. For such manuals you only need grotty/less to be patched. So then in in less i hit ^A and will be asked [anchor]: then i enter the number and it scrolls into view. And ' will scroll back to where you have been before following the internal link. Likewise, if the entered number links an external manual page you first see Read external manual: !man 1 sh and if you hit return, you go there, temporarily suspending the current less. (This external thing is actually a compile time option.) So this is all i need, and it would be very nice to have this possibility much more often. Well. The mandoc project has an option to generate links for manual pages on best guess, too. This works surprisingly well, and does not need a patch for less as it generates the usual tag files that you all know about. It cannot support exact anchor support, of course, and TOC generation it does not have too, i think. But anyway: it is possible. |You need a way to position the cursor with more flexibility than more gives |you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -- End forward <20190916191228.1YQHs%steffen(a)sdaoden.eu> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

5 years, 8 months

Re: [TUHS] earliest Unix roff [correction]

by Doug McIlroy

The URL for roff71 scans is https://www.cs.dartmouth.edu/~doug/roff71/

5 years, 8 months

user-level v1

by Doug McIlroy

The TUHS archive does not include /usr/src for v1. Does it exist anywhere? doug

5 years, 8 months

Re: [TUHS] earliest Unix roff

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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 months

If not Linux, then what?

by Arthur Krewat

https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anni… Leaving licensing and copyright issues out of this mental exercise, what would we have now if it wasn't for Linux? Not what you'd WANT it to be, although that can add to the discussion, but what WOULD it be? I'm not asking as a proponent of Linux. If anything, I was dragged kicking and screaming into the current day and have begrudgingly ceded my server space to Linux. But if not for Linux, would it be BSD? A System V variant? Or (the horror) Windows NT? I do understand that this has been discussed on the list before. I think, however, it would make a good late-summer exercise. Or late winter depending on where you are :) art k.

5 years, 8 months

early vm systems

by Steve Simon

hi the other early vm system not mentioned yet is the one Charles Forsyth wrote at the university of york for sunos. i never used it as i was learning v7 on an interdata 30 miles away at the time but i read his excellent paper on it. -Steve

5 years, 8 months

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

by Rudi Blom

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, 8 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