TUHS

tuhs@tuhs.org

17 participants
6470 discussions

by jnc＠mercury.lcs.mit.edu

> From: Andrew Warkentin > Mach and the other kernels influenced by it basically destroyed the > reputation of microkernels ... a simple read() of a disk file, which is > a single kernel call on a monolithic kernel and usually two context > switches on QNX, takes at least 8 context switches - client->VFS->disk > FS->partition driver->disk driver and back again). Hammer-nail syndrome. When the only tool you have for creating separate subsystems is processes, you wind up with a lot of processes. Who'd a thunk it. A system with a segmented memory which allows subroutine calls from one subsystem to another will have a lot less overhead. It does take hardware support to be really efficient, though. The x86 processors had that support, until Intel dropped it from the latest ones because nobody used it. Excuse me while I go bang my head on a very hard wall until the pain stops. Noel

5 years, 10 months

Any oldtimers remember anything about the KS11 on the -11/20?

by jnc＠mercury.lcs.mit.edu

This is an appeal to the few really-old-timers (i.e. who used the PDP-11/20 version of Unix) on the list to see if they remember _anything_ of the KS11 memory mapping unit used on that machine. Next to nothing is known of the KS11. Dennis' page "Odd Comments and Strange Doings in Unix": https://www.bell-labs.com/usr/dmr/www/odd.html has a story involving it (at the end), and that is all I've ever been able to find out about it. I don't expect documentation, but I am hoping someone will remember _basically_ what it did. My original guess as to its functionality, from that page, was that it's not part of the CPU, but a UNIBUS device, placed between the UNIBUS leaving the CPU, and the rest of the the bus, which perhaps mapped addresses around (and definitely limited user access to I/O page addresses). It might also have mapped part of the UNIBUS space which the -11/20 CPU _can_ see (i.e. in the 0-56KB range) up to UNIBUS higher addresses, where 'extra' memory is configured - but that's just a guess; but it is an example of the kind of info I'd like to find out about it - just the briefest of high-level descriptions would be an improvement on what little we have now! On re-reading that page, I see it apparently supported some sort of user/kernel mode distinction, which might have require a tie-in to the CPU. (But not necessarily; if there was a flop in the KS11 which stored the 'CPU mode' bit, it might be automatically cleared on all interrupts. Not sure how it would have handled traps, though.) Even extremely dim memories will be an improvement on the blank canvas we have now! Noel

5 years, 10 months

Re: [TUHS] Any oldtimers remember anything about the KS11 on the 11/20?

by jnc＠mercury.lcs.mit.edu

> From: Rudi Blom > Probably already known, but to be sure Interesting options: MX11 - > Memory Extension Option: this enabled the usage of 128 KW memory (18-bit > addressing range) Actually, I didn't know of that; something else to track down. Wrong list for that, though. Noel

5 years, 10 months

Any oldtimers remember anything about the KS11 on the 11/20?

by Rudi Blom

Probably already known, but to be sure Interesting options: MX11 - Memory Extension Option: this enabled the usage of 128 KW memory (18-bit addressing range); KS11: this option provided hardware memory protection, which the plain /20 lacked. Both options were developed by the Digital CSS (Computer Special Systems). http://hampage.hu/pdp-11/1120.html PS the page listed below has a very nice picture of the 'two fathers of UNIX" working on a PDP-11/20 http://hampage.hu/unix/unix1.html

5 years, 10 months

Re: [TUHS] UNIX 50th at USENIX ATC

by Norman Wilson

Kevin Bowling: The conference looks supremely uninteresting outside one WAFL talk to me. ==== That is, of course, a matter of opinion. Just from skimming titles I see about two dozen talks of at least some interest to me in the ATC program. And that's just ATC; I'm planning to attend the Hot* workshops on Monday and Tuesday as well. Of course I won't attend every one of those talks--some coincide in time, some I'll miss because I get stuck in the hallway track. And some will prove less interesting in practice, though others that don't seem all that interesting in the program will likely prove much better in person. I've been attending USENIX ATC for decades, and although some conferences have been meatier than others, I've never ended up feeling the trip was a waste of time. Perhaps us old farts just aren't as discriminating as you youngsters. That said, I think Kevin's question Is there a way to participate [on the UNIX50 event] without attending Usenix ATC? is a good one. Norman Wilson Toronto ON

5 years, 10 months

RIP Bud Lawson

by Doug McIlroy

Bud Lawson, long an expat living in Sweden, died yesterday. Not a Unix person, he was, however, the originator of a characteristic Unix programmer's idiom. Using an idea adapted from Ken Knowlton, Bud invented the pointer- chasing arrow operator that Dennis Ritchie adopted for C. I played matchmaker. When Bud first proposed the "based storage" (pointer) facility for PL/I, he used the well-established field(pointer) notation. I introduced him to the pointer-chasing notation Knowlton devised for L6. Knowlton, however, had no operator because he had only single-letter identifiers. What we now write as a->b->c, Knowlton wrote as abc. Appreciating the absence of parentheses, Bud came up with the wonderfully intuitive pointer->field notation. Doug

5 years, 10 months

MtXinu floppy set for Mach386

by Jason Stevens

I came across Scott Taylor’s site which mentions his adventure with MtXinu (https://www.retrosys.net/) I had asked a few years ago (February 2017?) about locating a set Of this to no avail, but thanks to Scott the binary set is now available. ftp://ftp.mrynet.com/operatingsystems/Mach2.5/MtXinu-binary-dist/floppies/M… There is some additional documentation to be found here. ftp://ftp.mrynet.com/operatingsystems/Mach2.5/MtXinu-binary-dist/docs The floppy drive like 386BSD is super weak and I had no luck with Qemu. VMWare worked fine to install. The VMDK will run on Qemu as low as 0.90 just fine. I haven’t tried the networking at all, so I don’t know about adapters/protocol support. I’ve been using a serial line to uuencode stuff in & out but it’s been stable.

5 years, 10 months

Celebration of Internet History with their UNIX at 50 Event

by Clem Cole

We are all thrilled and thankful for the generosity of SDF and LCM+L by sponsoring and providing a celebration of Internet History with their UNIX at 50 Event for the USENIX ATC Attendees. We understand not all of you can participate in the conference, but would still like to be part of the celebration. Our hosts have graciously opened the event to the community at large, as I said in my previous message, it should be an evening of computer people being able to be around and discussing computer history. However, if you are not planning to attend the conference but wish to attend the evening's event, we wish that you would at least consider joining one or more of the organizations to help support them all in the future. All three organizations are members supported and need all our help and contributions to function and bring their services to everyone today and hopefully 50 years from now. Membership details for each can be found at Join SDF <https://sdf.org/join>, LCM+L Memberships <https://livingcomputers.org/Join/Memberships.aspx>, and USENIX Association Memberships <https://www.usenix.org/membership-services> ᐧ

5 years, 10 months

Question about finding curses to build on v7

by Adam Thornton

I've been playing with simh recently, and there is a nonzero chance I will soon be acquiring a PDP/11-70. I realize I could run 2.11BSD on it, and as long as I stay away from a networking stack, I probably won't see too many coremap overflow errors. But I think I'd really rather run V7. However, there's one thing that makes it a less than ideal environment for me. I grew up after cursor-addressable terminals were a thing, and, even if I can eventually make "ed" do what I want, it isn't much fun. I've been an Emacs user since 1988 and my muscle memory isn't going to change soon (and failing being able to find and build Gosmacs or an early GNU Emacs, yes, I can get by in vi more easily than in ed; all those years playing Nethack poorly were good for something). So...where can I find a curses implementation (and really all I need in the termcap or terminfo layer is ANSI or VTxxx) that can be coerced into building on V7 pretty easily? Also, I think folks here might enjoy reading a little personal travelogue of some early Unix systems from my perspective (which is to say, a happy user of Unix for 30+ years but hardly ever near core development (I did do the DIAG 250 block driver for the zSeries port of OpenSolaris; then IBM pushed a little too hard on the price and Sun sold itself to (ugh) Oracle instead; the world would have been more fun if IBM had bought the company like we were betting on)). That's at https://athornton.dreamwidth.org/14340.html ; that in turn references a review I did about a year ago of The Unix Hater's Handbook, at https://athornton.dreamwidth.org/14272.html . Adam

5 years, 10 months

Re: [TUHS] Montgomery's emacs

by jnc＠mercury.lcs.mit.edu

> From: Mary Ann Horton > Warren's emacs would have been part of the Bell Labs 'exptools' > (experimental tools) package ... it's possible that's what you have. I don't think so; Warren had been a grad student in our group, and we got it on that basis. I'm pretty sure we didn't have termcap or any of that stuff. Noel

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