TUHS

tuhs@tuhs.org

17 participants
6470 discussions

Rivers, the ragged right, and BCPL roff (was: Spooky action at a distance in line adjustment...sometimes)

by Doug McIlroy

> I was poking around on the Unix v7 man page archive the other day, and > discovered to my delight that BCPL roff's request list was documented > there. Yes, it's the same spec, though reimplementated; there was no BCPL compiler for the PDP-11. > Unfortunately, it was marked up in...BCPL roff embedded within > a man page, which hopelessly confused groff. I edited the v7 manual and I believe I proofread every man page. How could I have overlooked the misbehavior of the .li request*, which was even then not in the reference manual's list of n/troff requests? On closer examination, .li does appear in a condensed alphabetical list of requests--and it appears in the source. But if Joe never described it, it's no surprise that groff dropped it. It is totally unnecessary--a bit of special pleading rendered obsolete by Joe's elegant invention of \&. doug * .li causes the next line to be read literally, even if it begins with a dot.

6 years, 9 months

Re: [TUHS] Any Good dmr Anecdotes?

by Norman Wilson

Greg Lehey: No, that was Peter Weinberger, as dmr confirmed. There's quite a story behind what happened to the stencil. I'll let Warren tell it, but if you want to cheat, check http://www.lemis.com/grog/diary-oct2002.php#17 ==== There are many stories behind the use and abuse of Peter's face. The canonical source is http://spinroot.com/pico/pjw.html spinroot.com belongs to Gerard Holzman, who was involved with many creative uses of digitized photography during my time at the Labs. (Also much work on software reliability, which he now pursues at JPL.) The org chart with every face replaced by Peter's was on the wall of the UNIX Room when I first visited 1127 in February 1984. I suspect it appeared not long after Peter became a department head, but I don't know just when that was. Peter didn't really take the alleged glory of being a department head all that seriously, just the responsibilities. One of the official glories was that Department Heads were supposed to get carpet in their offices, atop the standard linoleum tiles. Peter didn't want it, and (as he told me the story later) had to argue with Facilities a lot not to get it. Somehow this resulted in a trophy: a small square of carpet stuck to the wall outside his office. Norman Wilson Toronto ON

6 years, 9 months

Unix Kernel Size

by Warner Losh

Greetings, I'd like to thank everybody that sent me data for my unix kernel size stuff. There's two artifacts I've crated. One I think I've shared before, which is my spreadsheet: https://docs.google.com/spreadsheets/d/13C77pmJFw4ZBmGJuNarBUvWBxBKWXG-jtvA… The second are some simplified graphs and the first half of my BSDcan talk: http://www.bsdcan.org/2018/schedule/events/934.en.html The video should be available soon for my talk as well, but it's not up yet. If there's interest, I'll post an update when it is. Warner

6 years, 9 months

Re: [TUHS] Masscomp oops [was: Any Good dmr Anecdotes?]

by jnc＠mercury.lcs.mit.edu

> From: Mike Markowski > a cute, slender gal came into the lab. ... I typed mkfs... On the plus > side, I ended up marrying the girl. OK, so now I _have_ to hear the backstory - _when_ did you tell her what happened? Then? (Maybe she noticed the look on your face once you realized what you'd done? :-) Later? Never? :-) Noel

6 years, 9 months

Re: [TUHS] Any Good dmr Anecdotes?

by Larry McVoy

I've told this story so much that my kids hear me start it and go "is that the Unix guy? Yeah, we've heard this". And I think many of you have heard it as well so you can hit delete, but for the newbies to the list here goes. Decades ago I was a grad student at UWisc and pretty active on comp.arch and comp.unix-wizards (I was not a wizard but I've lived through, and written up, the process of restoring a Masscomp after having done some variant of rm -rf / so a stupid wizard wanna be?) >From time to time, some Unix kernel thing would come up and I'd email ...!research!dmr and ask him how that worked. He *always* replied. To me, a nobody. All he cared was that the question wasn't retarded (and I bet to him some of mine were but the questions showed that I was thinking and that was good enough for him). I remember a long discussion about something, I think PIPEBUF but not sure, and at some point he sent me his phone number and said "call me". Email was too slow. So yeah, one of the inventors of Unix was cool enough to take some young nobody and educate him. That's Dennis. I've tried to pass some of that energy forward to my kids, telling them that if you want to learn, smart people like that and they will help you. Dennis was a humble man, a smart man, and a dude willing to pass on what he knew. I miss him and cherish the interactions I had with him.

6 years, 9 months

Moderation on for a bit

by Warren Toomey

OK, so now I'm a bit p*ssed off. We've losy Johnny a few days ago because of the traffic on the list and now Tim is asking to be unsubscribed. First up: Unix Heritage. I don't mind a bit of drift but seriously?! I put in a nugde to wind up the comp.arch chat but that didn't help. Secondly: a few of you need to pull your heads in. The TUHS list is going to be moderated for the next couple of days. If you really feel it necessary, you can post a _summary_ of your comp.arch position and then stop. Posts on Unix anecdotes and on-topic stuff I will let through. Cheers, Warren

6 years, 10 months

PDP-11 legacy, C, and modern architectures

by Nelson H. F. Beebe

There is a provocative article published today in the lastest issue of Communications of the ACM: David Chisnall C is not a low-level language Comm ACM 61(7) 44--48 July 2018 https://doi.org/10.1145/3209212 Because C is the implementation language of choice for a substantial part of the UNIX world, it seems useful to announce the new article to TUHS list members. David Chisnall discusses the PDP-11 legacy, the design of C, and the massive parallelism available in modern processors that is not so easy to exploit in C, particularly, portable C. He also observes: >> ... >> A processor designed purely for speed, not for a compromise between >> speed and C support, would likely support large numbers of threads, >> have wide vector units, and have a much simpler memory model. Running >> C code on such a system would be problematic, so, given the large >> amount of legacy C code in the world, it would not likely be a >> commercial success. >> ... ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

6 years, 10 months

ATT Hardware

by ron＠ronnatalie.com

The recent reference to the Dennis's comments on ATT chip production had me feeling nostalgic to the 3B line of computers. In the late 80's I was in charge of all the UNIX systems (among other things) at the state university system in New Jersey. As a result we got a lot of this hardware gifted to us. The 3B5 and 3B2s were pretty doggy compared with the stuff on the market then. The best thing I could say about the 3B5 is that it stood up well to having many gallons of water dumped on it (that's another story, Rutgers had the computer center under a seven story building and it still had a leaky roof). The 3B20 was another thing. It was a work of telephone company art. You knew this when it came to power it down where you turned a knob inside the rack and held a button down until it clicked off. This is pretty akin to how you'd do things on classic phone equipment (for instance, the same procedure is used to loopback the old 303 "broadband" 50K modems that the Arpanet/Milnet was built out of). Of course, the 3B20 was built as phone equipment. It just got sort of "recycled" as a GP computer.

6 years, 10 months

Faster cpus at any cost

by Steve Simon

I know this is a dangerous game to play, but what of the future? I am intrigued by the idea of true optical computers, perhaps the $10M super-computer will return? GPUs have definitely taken over in some areas - even where SIMD would not seem a good fit. My previous employer does motion estimation of realtime video and has moved from custom electronics and FPGAs to using off the shelf GPUs in PCs. -Steve

6 years, 10 months

C Threading

by ron＠ronnatalie.com

Thread local storage and starting threads up is largely a rather inconsequential implementation detail. When it comes down to actual parallel programming, of which I have done more than a little, the big thing is thread synchronization. It's rather hardware dependent. You can pretty much entirely wipe out any parallism gains with a synchronization call that results in a context switch or even a serious cache impact. On one side you have machines like the Denelcor HEP where every memory word had a pair of semaphores on it and the instructions could stall the process while waiting for them and the hardware would schedule the other threads. On the other hand you have your x86, which you can do a few clever things with some atomic operations and inlined assembler but a lot of the "standard" (boost, pthread, etc...) synchs will kill you.

6 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