TUHS March 2023

tuhs@tuhs.org

84 participants
77 discussions

Re: I can't drive 55: "GOTO considered harmful" 55th anniversary

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > for breaking out of multiple levels of while/for loops. Yeah, multi-level 'breaks' were one of the things I really missed in C. The other was BCPL's 'VALOF/RESULTIS'. Back before C compilers got good enough to do inline substitutions of small procedures (making macros with arguments less useful), it would have been nice to have, for macros that wanted to return something. Instead, one had to stand on one's head and use a '(cond ? ret1 : ret2 )' of some form. Noel

2 years

Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

by jnc＠mercury.lcs.mit.edu

> From: Ralph Corderoy > if you say above that most people are unfamiliar with them due to their > use of goto then that's probably wrong I didn't say that. I was just astonished that in a long thread about handling exceptional conditions, nobody had mentioned . . . exceptions. Clearly, either unfamiliarity (perhaps because not many laguages provide them - as you point out, Go does not), or not top of mind. Noel

2 years

simh running System V add serial (telnet) lines

by KenUnix

I have successfully got System V running on a PDP11 sim. I have been trying to add serial lines like on Version 7 but have had no success. What would be necessary under System V on a sim to do so. I have already tried the SIMH group but no working answers. If direct telnet is a better way please let me know. Thanks Ken -- WWL 📚

2 years

scaling on TCP socket connections

by ron minnich

Ca. 1981, if memory serves, having even small numbers of TCP connections was not common. I was told at some point that Sun used UDP for NFS for that reason. It was a reasonably big deal when we started to move to TCP for NFS ca 1990 (my memory of the date -- I know I did it on my own for SunOS as an experiment when I worked at the SRC -- it seemed to come into general use about that time). What kind of numbers for TCP connections would be reasonable in 1980, 90, 2000, 2010? I sort of think I know, but I sort of think I'm probably wrong.

2 years

Fifth Edition Manual Restoration

by segaloco

So I decided to keep the momentum and have just finished the first pass of a Fifth Edition manual restoration based on the same process I used for 3B20 4.1: https://gitlab.com/segaloco/v5man There were a few pages missing from the extant PDF scan, at least as far as pages that were in both V4 and V6 sources, so those are handled by seeing how V5 source of the few programs compares to V6. I'll note which pages required this in a second pass. I've set my sights on V1 and V2 next, using V3's extant roff sources as a starting point, so more to come. - Matt G.

2 years

Re: scaling on TCP socket connections

by Paul Ruizendaal

From reading a lot of papers on the origins of TCP I can confirm that people appear to have been thinking in terms of a dozen connections per machine, maybe half that on 16-bit hardware, around 1980. Maybe their expectations for PDP-10’s were higher, I have not looked into that much. > From: Tom Lyon <pugs78(a)gmail.com> > Sun chose UDP for NFS at a point when few if any people believed TCP could > go fast. > I remember (early 80s) being told that one couldn't use TCP/IP in LANs > because they were WAN protocols. In the late 80s, WAN people were saying > you couldn't use TCP/IP because they were LAN protocols. I’m not disputing the above, but there was a lot of focus on making TCP go fast enough for LAN usage in 1981-1984. For example see this 1981 post by Fabry/Joy in the TCP-IP mailing list: https://www.rfc-editor.org/in-notes/museum/tcp-ip-digest/tcp-ip-digest.v1n6… There are a few other similar messages to the list from around that time. An early issue was check-summing, with that initially taking 25% of CPU on a VAX750 when TCP was heavily used. Also ideas like having "trailing headers" (so that the data was block aligned) were driven by a search for LAN performance. Timeouts were reduced from 5s and 2s to 0.5s and 0.2s. Using a software interrupt instead of a kernel thread was another thing that made the stack more performant. It always seemed to me that the BBN-CSRG controversy over TCP code spurred both teams ahead with BBN more focussed on WAN use cases and CSRG more on LAN use cases. I would argue that no other contemporary network stack had this dual optimisation, with the possible exception of Datakit.

2 years

Unix System V date command update

by KenUnix

Guys, Find attached an updated date.c for Y2K for System V IE: date 0309182123 Also works: # date +%D 03/09/23 # date +%y%m%d%H%M 2303091823 Interesting Version 7 wants: date 2303091821 Ken -- WWL 📚

2 years

Re: Origins of the frame buffer device

by jnc＠mercury.lcs.mit.edu

> From: Kenneth Goodwin > The first frame buffers from Evans and Sutherland were at University of > Utah, DOD SITES and NYIT CGL as I recall. > Circa 1974 to 1978. Were those on PDP-11's, or PDP-10's? (Really early E+S gear attached to PDP-10's; '74-'78 sounds like an interim period.) Noel

2 years

'Huge' file support removed from PWB1

by jnc＠mercury.lcs.mit.edu

In PWB1, support for 'huge' files appears to have been removed. If one compares bmap() in PWB1'S subr.c with V6's, the "'huge' fetch of double indirect block" code is gone. I guess PWB didn't need very large (> 8*256*512 = 1,048,576 bytes) files? I'm not sure what the _benefits_ of removing it were, though - unless PWB was generating lots of files of between 7*256*512 and 8*256*512 bytes in length, and they wanted to avoid the overhead of the double-indirect block? (The savings in code space are derisory - unlike in LSX/MINI-UNIX.) Anyone know? Noel

2 years

Origins of the frame buffer device

by Paul Ruizendaal

I am confused on the history of the frame buffer device. On Linux, it seems that /dev/fbdev originated in 1999 from work done by Martin Schaller and Geert Uytterhoeven (and some input from Fabrice Bellard?). However, it would seem at first glance that early SunOS also had a frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature (a character device that could be mmap’ed to give access to the hardware frame buffer, and ioctl’s to probe and configure the hardware). Is that correct, or were these entirely different in nature? Paul

2 years

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 March 2023