TUHS

tuhs@tuhs.org

29 participants
6557 discussions

by jnc＠mercury.lcs.mit.edu

> From: "John P. Linderman" > Brian interviewing Ken Ah, thanks for that. I had intended going (since I've never met Ken), but alas, my daughter's family had previously scheduled to visit that weekend, so I couldn't go. The 'grep' story was amusing, but historically, probably the most valuable thing was the detail on the origins of B - DMR's paper on early C ("The Development of the C Language") mentions the FORTRAN, but doesn't give the detail on why that got canned, and B appeared instead. Noel

6 years, 3 months

interpreted C?

by Larry McVoy

Decades ago there was an interpreted C in an X10 or X11 app, I believe it came from the UK. And maybe it wasn't X11, maybe it was Sunview? Whatever it was the author didn't like the bundled scrollbars and had their own custom made one. You could set breakpoints like a debugger and then go look around at state. Does anyone else remember that app and what it was called?

6 years, 3 months

Re: [TUHS] A question about ls(1)

by norman＠oclsc.org

Bakul Shah: This could've been avoided if there was a convention about where to store per user per app settings & possibly state. On one of my Unix machines I have over 200 dotfiles. ==== Some, I think including Ken and Dennis, might have argued that real UNIX programs aren't complex enough to need lots of configuration files. Agree with it or not, that likely explains why the Research stream never supplied a better convention about where to store such files. I do remember some general debate in the community (e.g. on netnews) about the matter back in the early 1980s. One suggestion I recall was to move all the files to subdirectory `$HOME/...'. Personally I think $HOME/conf would have been better (though I lean toward the view that very few programs should need such files anyway). But by then BSD had spread the convention of leaving `hidden' files in $HOME had spread too far to call back. It wouldn't surprise me if some at Berkeley would rather have moved to a cleaner convention, just as the silly uucp-baud-rate flags were removed from wc, but the cat was already out of the bag and too hard to stuff back in. On the Ubuntu Linux systems I help run these days, there is a directory $HOME/.config. The tree within has 192 directories and 187 regular files. I have no idea what all those files are for, but from the names, most are from programs I may have run once years ago to test something, or from programs I run occasionally but have no context I care about saving. The whole tree occupies almost six megabytes, which seems small by current standards, but (as those on this list certainly know) in the early 1980s it was possible to run a complete multi-user UNIX system comfortably from a single 2.5MB RK05 disk. Norman Wilson Toronto ON

6 years, 3 months

Running sparc Solaris with qemu

by A. P. Garcia

https://blog.adafruit.com/2019/04/29/new-guide-build-your-own-sparc-worksta…

6 years, 3 months

MASSCOMP MC-500 Guide to Writing a Unix Device Driver

by Norman Wilson

Dennis's `The UNIX I/O System' paper in Volume 2 of the 7/e manual is basically about how drivers work. Is that near enough, possibly as augmented by Ken's `UNIX Implementation' paper in the same book? Those were my own starting point, long ago, for understanding how to write device drivers. Along with existing source code as examples, of course, but (unlikely many who hack on device drivers, I'm afraid) I have always preferred to have a proper statement of rules, conventions, and interfaces rather than just reading code and guessing. Norman Wilson Toronto ON

6 years, 3 months

MASSCOMP MC-500 Guide to Writing a Unix Device Driver

by Warner Losh

Greetings, I'm trying to find the predecessor to "Writing a UNIX Device Driver, J. Egan & T. Teixeira, 1st ed, 1988". In the preface, it says: "This book is based on a MASSCOMP manual, Guide to Writing a Unix Device Driver. The first version that MASSCOMP published as part of the documentation set for the MC-500 was based on preliminary drafts prepared for MASSCOMP by Cliff Cary and Tom Albough of Creare R&D." I checked bit keepers and found nothing. I was wondering if people on this list know of this manual, have a copy, etc. In general, I'm looking for pre-SysV driver manuals. I can find all kinds of SysV driver books (some of which cover 4.2BSD or 4.3BSD as well), but nothing for System III or V7 unix. There were a lot of early systems that were based on ports of V7 to different architectures that were then updated to System III or System V (at least according to the big chart of unix history and some wikipedia entries, which may be just repeating marketing schlock and not reflect actual reality). As part of a talk I'm putting together on the 40th anniversary of V7, I wanted to have a bit of history for things we still have in unix today (like strategy) and things that successors to unix have added or left behind (like the packet mux in V7 that was tossed aside for either STREAMS or netinet from BSD, though packet muxing to userland is back with DPDK). Warner

6 years, 3 months

A question about ls(1)

by Anthony Martin

>From at least V2 to V6, the ls(1) command would not show directory entries whose names began with a '.' unless the -a flag was supplied. This was changed in V7: only the directory entries for "." and ".." would be skipped by default. All further versions of Research Unix retain the convention of V7 and Plan 9 ultimately made it unnecessary. However, BSD and its descendants did not follow suit. Instead, they continued behaving like V6 with an additional -A flag to emulate V7. Was the initial behavior intentional or just a matter of expediency? Who made the change and what was their motivation? Was it a reaction to the intentional hiding of what came to be known as "dot files"? Thanks, Anthony

6 years, 3 months

Re: [TUHS] OT: Need help getting old 9 track tapes read

by jnc＠mercury.lcs.mit.edu

> From: Arnold Skeeve > If you have information, PLEASE send it to me so that I can relay it > to Scott. IMO, only one choice: Chuck Guzis (cclist(a)sydex.com) he's very active in the vintage computer community, and reads old media professionally. I've used him (to recover those backup tapes of the MIT PWB1 system), which was rather tricky (bad mold; he had to build a special tool to remove it), and I was incredibly happy. Very reasonable price too - although he may have given me a special 'collector' rate.. :-) Noel

6 years, 3 months

v8 networking and streams (was: a question about ls)

by Paul Ruizendaal

> There was a hacky implementation of TCP/IP which we didn't really use: > 4.Y BSD (I don't know the value of Y) protocol code, wrapped up to > work as stream modules* and shoehorned in, with a custom API quite > different from the BSD one. The work was done by a summer student, > Robert T. Morris, who later became rather famous for a smaller but > rather more troublesome bit of network code. Our production network > was Datakit, which was also implemented as stream devices and modules > (it was the network whose use inspired the stream design, in fact). I’d love to hear more about that. So far, the only information I have found about (lowercase) streams and networking - as used at the labs - is the v8 source code and a 1984 message from dmr on a mailing list. The (lower level) v8 networking concepts appear to carry through to v10 and Plan9. It is my impression that the unix/datakit tradition essentially views a network connection as a special kind of device, whereas the unix/arpanet tradition essentially views a network connection as a special kind of pipe. In both cases this would seem to have been an accidental choice driven by convenience in early implementations (respectively the Spider network drivers and NCP Unix from the UoI). However, that is an impression formed 35+ years after the fact and the contemporary view may have been very different. Paul

6 years, 3 months

Re: [TUHS] A question about ls(1)

by jnc＠mercury.lcs.mit.edu

> From: Norman Wilson > Quite a while ago, someone asked how multiplexing was handled in the > stream world. I meant to write a reply but never did. In a sentence, > by a paired device driver and stream module. If someone wants more > details I'll be glad to write more about that. Please. Thanks! Noel

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