TUHS

tuhs@tuhs.org

34 participants
6418 discussions

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

please ignore this message

by Doug McIlroy

This tests a guess about anomalous behavior of the mailing-list digest. I apologize for inflicting it on everybody. Doug

6 years, 6 months

Any Definitive Unix Celebrations Next Year?

by Warren Toomey

All, I'm planning to come to the Usenix ATC next year on July 10-12 on the assumption that there will be some Unix 50th celebration there. Does anybody know of other events in the date range June 28 to July 9, as those are the dates I'll be able to get off work. And/or, if I'm in the U.S on these dates, does anybody want to catch up? Just trying to build an itinerary for this time next year. Thanks, Warren

6 years, 6 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