TUHS

tuhs@tuhs.org

6 participants
6532 discussions

by Douglas McIlroy

> I can think of at least 4 things, some big, some small, where post-V7 > Research Unix was influential Besides streams, file system switch, /proc, and /dev/fd. v8 had the Blit. Though Rob's relevant patent evoked disgruntled rumblings from MIT that window systems were old hat, the Blit pioneered multiple windows as we know them today. On the contemporary Lisp Machine, for example, active computation happened in only one window at a time. V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS mapped UIDS, thus allowing files to be shared among computers in different jurisdictions with different UID lists. Unfortunately, RFS went the way of Reiser paging. And then there was Norman Wilson, who polished the kernel and administrative tools. All kinds of things became smaller and cleaner--an inimitable accomplishment > No clue what was new in V10 This suggests I should put on my to-do list an update of the Research Unix Reader's combined table of man-page contents, which covers only v1-v9. I think it's fair to say, though, that nothing introduced in v10 was as influential as the features mentioned above. Doug

3 years

Re: RFS (was Re: Re: forgotten versions)

by norman＠oclsc.org

I don't know the exact history of RFS a la System V, but I don't think it was Peter Weinberger's stuff, and it certainly wasn't his code. Nor his name: he called his first version neta and his second netb (he knew it would be changing and allowed for it in the name from the start). I don't remember us ever calling it RFS, or even remote file systems, inside 1127; we called it network file systems (never NFS because the Sun stuff existed by then). For those who don't know it, Peter's goal was quite different from that of NFS. The idea behind NFS seems always to have been to mount a remote file system as if it were local, with a base assumption early on that everything was within the same administrative domain so it was OK to make assumptions about userids matching up, and running code as super-user. Peter described his intent as `I want to be able to use your disks, and that's a lot simpler if I don't have to get you to add code to your kernel, or even to run a program as super-user.' Hence the entirely-user-mode server program, which could use super-user privileges to afford access as any user if it had them, but also worked fine when run as an ordinary user with only that user's file permissions. We did in fact normally run it as super-user so each of our 15 or so VAXes could see the file system tree on each other, but we also occasionally did it otherwise. That was one reason device files worked as they did, accessing the device on the server end rather than acting like a local special file on the client: we didn't care about running diskless clients, but we did occasionally care about accessing a remote system's tape drive. Peter, being a self-described fan of cheap hacks, also wasn't inclined to spend much time thinking about general abstractions; in effect he just turned various existing kernel subroutines (when applied to a network file system) into RPCs. The structure of the file system switch was rather UNIX-specific, reflecting that. That also means Peter's code was a bit ad-hoc and wonky in places. He cleaned it up considerably between neta and netb, and I did further cleanup later. I even had a go at a library to isolate the network protocol from the server proper, converted the netb server to use it, and made a few demo servers of my own like one to read and write raw FILES-11 file systems--useful for working with the console file system on the VAX 8800 series, which was exported to the host as a block device--and a daemon to allow a tar archive to be mounted as a read-only file system. In modern systems, you can do the same sort of things with FUSE, and set up the same I-want-to-use-your-disks (or I want to get at my own files from afar without privileges) scheme with sshfs. I would be very surprised to learn that either of those borrowed from their ancient cousins in Research UNIX; so far as I know they're independent inventions. Either way I'm glad they exist. Norman Wilson Toronto ON

3 years

Re: early plan9

by Steve Simon

interesting to know the vax was a complete dead end. i do remember jmk (rip) reporting on 9fans, maybe even releasing, the vax plan9 kenc compiler he discovered in a dusty corner of the dump filesystem. I was intrigued and asked if there was anything else, but he said he said there where no kernel or driver fragments to go with it. -Steve

3 years

Re: forgotten versions

by Paul Ruizendaal

For those interested in a quick feel for V8 and early SysV, I recommend the excellent unix50 stuff: SSH to unix50: "ssh unix50(a)unix50.xn--org-9o0a Password is “unix50” You end up in a menu with: SDF Public Access UNIX System presents ... /~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/ /~/~ H Y S T E R I C A L ~ U N I X ~ S Y S T E M S ~/~/ /~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/ [a] UNICS (Version Zero) PDP-7 Summer 1969 [b] First Edition UNIX PDP-11/20 November 1971 [c] Fifth Edition UNIX PDP-11/40 June 1974 [d] Sixth Edition UNIX PDP-11/45 May 1975 [e] Seventh Edition UNIX PDP-11/70 January 1979 [f] Research UNIX 8 VAX-11/750 1984 [g] AT&T UNIX System III PDP-11/70 Fall 1982 [h] AT&T UNIX System V PDP-11/70 1983 [i] AT&T UNIX System V 3b2/400 1984 [j] 4.3 BSD MicroVAX June 1986 [k] 2.11 BSD PDP-11/70 January 1992 [w] What's running now? [q] QUIT (and run away in fear!) User contributed tutorials are at https://sdf.org/?tutorials/unix50th Want persistent images? networking? more ttys? Join https://sdf.org Don’t to exit from a run, press Ctrl-E to return to sims, type 'exit', type ‘q' I just tried V8 and it still works, although the boot log suggests that an image reset may be in order. Many, many thanks to whoever is maintaining this!

3 years

Re: Sockets vs Streams (was Re: forgotten versions

by norman＠oclsc.org

As one of the few remaining people who has actually worked with the original dmr stream I/O system, I'd love to dive into the debate here, but I don't have time. I can't resist commenting on a few things that have flown by, though. Maybe I can find time to engage better on the weekend. -- If you think there were no record delimiters in the stream system, you don't know enough about it. A good resource to repair that is Dennis's BSTJ paper: https://www.bell-labs.com/usr/dmr/www/st.pdf It's an early description and some of the details later evolved (for example we realized that once pipes were streams, we no longer needed pseudoterminals) but the fundamentals remained constant. See the section about Message blocks, and the distinction between data and control blocks. Delimiters were one kind of control; there were others, some of them potentially specific to the network at hand. In particular, Datakit (despite being a virtual-circuit network) had several sorts of control words, including message delimiters. Delimiters were necessary even just for terminals, though: how else does the generic read(2) code know to return early, before filling the buffer, when a complete line has arrived? -- It's hard to compare sockets to streams and make much sense, because they are very different kinds of thing. When people talk about sockets, especially when complaining that sockets are a mess, they usually mean the API: system calls like connect and listen and getpeername and so on. The stream system was mainly about the internal structure-- the composable modules and the general-purpose queue interface between them, so that you could take a stream representing an (already set up) network connection and push the tty module on it and have a working remote terminal, no need for user-mode programs and pseudo-terminals. It's not inconceivable to build a system with socket-like API and stream internals. -- Connection setup was initially done with network-specific magic messages and magic ioctls. Later we moved the knowledge of that messy crap into network-specific daemons, so a user program could make a network call just by calling fd = ipcopen("string-destination-name") without knowing or caring whether the network transport was TCP or Datakit or involved forwarding over Datakit to a gateway that then placed a TCP call to the Internet or whatnot. That's what the connection server was all about: https://www.bell-labs.com/usr/dmr/www/spe.pdf Again, the API is not specific to the stream system. It wouldn't be hard to write a connection server that provided the same universal just-use-a-string interface (with the privileged parts or network details left up to daemons) on a system with only socket networking; the only subtle bit is that it needs to be possible to pass an open file descriptor from one process to another (on the same system), which I don't think the socket world had early on but I believe they added long ago. -- There's nothing especially hard about UDP or broadcast. It's not as if the socket abstraction has some sort of magic datagram-specific file descriptor. Since every message sent and every message received has to include the far end's address info, you have to decide how to do that, whether by specifying a format for the data (the first N bytes are always the remote's address, for example) or provide an out-of-band mechanism (some ioctl mess that lets you supply it separately, a la sendto/recvfrom, and encodes it as a control message). There was an attempt to make UDP work in the 9th/10th edition era. I don't think it ever worked very cleanly. When I took an unofficial snapshot and started running the system at home in the mid-1990s, I ended up just tossing UDP out, because I didn't urgently need it (at the time TCP was good enough for DNS, and I had to write my own DNS resolver anyway). I figured I'd get around to fixing it later but never did. But I think the only hard part is in deciding on an interface. -- It's certainly true that the Research-system TCP/IP code was never really production-quality (and I say that even though I used it for my home firewall/gateway for 15 years). TCP/IP wasn't taken as seriously as it ought to have been by most of us in 1127 in the 1980s. But that wasn't because of the stream structure--the IP implementation was in fact a copy of that from 4.2 (I think) BSD, repackaged and shoehorned into the stream world by Robert T Morris, and later cleaned up quite a bit by Paul Glick. Maybe it would have worked better had it been done from scratch by someone who cared a lot about it, as the TCP/IP implementors in the BSD world very much did. Certainly it's a non-trivial design problem--the IP protocols and their sloppy observance of layering (cf the `pseudo header' in the TCP and UDP standards) make them more complicated to implement in a general-purpose framework. Or maybe it just can't be done, but I wish someone had tried in the original simpler setup rather than the cluttered SVr4 STREAMS. Norman Wilson Toronto ON

3 years

sockets [was Re: forgotten versions]

by Paul Ruizendaal

> Sockets (which btw, totally SUCK PUS) were coded into things > and even (YECHH) made POSIX and IETF spec status. Streams didn't stand > a chance. The question that originally pulled me into researching Unix networking 1975-1985 was more or less “how did we end up with sockets?”. That was 7 years or so ago, I now have a basic feel for how it came to be, and I also have better appreciation of the trade offs. What is the most “Unixy” of networking (as in the API and its semantics) is not something with an easy answer. If I limit myself to the 1975-1985 time frame, I see three approaches: 1. The API used in Arpanet Unix, which was also used by BBN in its first reference implementation of TCP/IP 2. The BSD sockets API, in two flavours: the Joy flavour in BSD4.1a, and the Karels flavour in BSD4.1c and later 3. The Ritchie/Presotto IPC library / API from V8/V9. This evolved into SysV networking, but the original is the clean idea At a high level of abstraction, there is a lot of similarity; close-up they are quite different. I like all three solutions! One thing that struck my attention was that the Ritchie/Presotto IPC library has the concept of “calling” a host and the host/network can reply with a response code (“line busy”, “number unknown”, “not authorised”, etc.). BSD sockets do not cover that. I guess it derives from Spider/Datakit having that functionality, and Arpanet / tcp-ip not having that (resorting to a connection ‘reset’ or dead line instead). Sockets have a more elegant solution for connectionless datagrams (imo), and for the same reason I guess. Sure, sockets has too much of the implementation sticking through the abstractions, but it is IMO not a bad design. That it became dominant I think is in equal measure due to economics and due to being “good enough”. If someone has a proposal for a network API that is cleaner and better than what was out there, and would have worked with the hardware and use cases of the early 80’s, I’m all ears. But maybe better on COFF... Paul

3 years

Re: forgotten versions

by Paul Ruizendaal

Wholeheartedly agree with the observations on forgotten versions, lack of source and a smaller pool of people back in the day. It is not just the Research versions, also the internal AT&T versions and the base System V versions get little attention. Same reasons I think. Luckily, these days the sources are available (although in the case of SysV of unclear legal status). Part of the problem I think is that it is not well known what innovations are in each version. About 2 years ago I did a lot of spelunking through the V8 source and with the help of this list could come up with a list of highlights for V8 (text is now on the TUHS V8 source web page). Never had the time to do that for V9. I think it was mentioned that it had a new filesystem with a bitmap free list. Also, it seems to have a lot of cleaned-up implementations of things that were new and rough in V8. No clue what was new in V10. Similar with Unix 3, Unix 4 and Unix 5. I’m thrilled that the docs for Unix 4 showed up recently. In these doc’s there is no material on IPC. From this I think that the IPC primitives from CB-Unix did not get merged in Unix 4, but only in Unix 5 (in a reworked form). Personally, I’m still working (off and on) on recreating the Reiser demand paging system. To keep it interesting I’ve now got Sys III running on a small RISC-V board, and when I find another time slot I’ll try to add Reiser paging to it. So the forgotten versions are only mostly forgotten, not totally forgotten :^)

3 years

Re: Documentation for Unix 4.0

by Norman Wilson

Maybe make www.tuhs.org a CNAME for tuhs.org? Surely a site devoted to the history of UNIX should use a real link, not a symbolic one. Norman `Old Fart' Wilson Toronto ON

3 years

Re: Source code for SCCS

by Paul Ruizendaal

It would seem that a Spinellis-like exercise for SCCS is possible: PWB1.0 (1978): https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/sccs4 SysIII (1980): https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/sccs SysVr1 (1983): https://www.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/cmd/sccs SysVr2 (1984): https://github.com/ryanwoodsmall/oldsysv/tree/master/sysvr2-vax/src/cmd/sccs SysVr3 (1987): https://github.com/ryanwoodsmall/oldsysv/tree/master/sysvr3/301/usr/src/cmd… SysVr4 (1988): https://github.com/ryanwoodsmall/oldsysv/tree/master/sysvr4/svr4/cmd/sccs Ultrix3.1 (1988): https://www.tuhs.org/cgi-bin/utree.pl?file=Ultrix-3.1/src/cmd/sccs I did not find SCCS sources included with the BSD sources on TUHS, but there is a front-end “sccs” command. For sure, SCCS was used for BSD development. Kirk McKusick’s DVD has a directory "CSRG/historic1/sccscmds”, but I did not look into this further. From here the trail probably continues with Solaris, GNU and Bitmover -- all very much outside my timeframe of research. Paul > The original Marc Rochchild/John Mashey and team code from PWB 1.0 can be > found: http://tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz > In the directory: sys/source/sccs4 > The man pages are in the same archive but mixed with the rest of the > commands in usr/man/man* > > That said, there is Gnu version of same written C++ if IIRC: > https://www.gnu.org/software/cssc/ > > And there's more ... but I'll Larry offer details here other than point out > his: http://www.bitmover.com/bitsccs/ [which is of BitKeeper] is a > more modern implementation still]

3 years

Documentation for Unix 4.0

by Warren Toomey

Hi all, we have a new addition to the Unix Archive at: https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ This is the documentation for Unix 4.0 which preceded System V. The documents were provided by Arnold Robbins and scanned in by Matt Gilmore. Cheers, Warren

3 years

blast from the past

by Andrew Hume

this is an old video, new to me, but i’m sure others on this list have seen it. its a little long, but has al aho, jon bentley, bjarne, ken&denis, plan 9 amongst others. https://www.youtube.com/watch?v=IFfdnFOiXUU&t=2s <https://www.youtube.com/watch?v=IFfdnFOiXUU&t=2s>

3 years

Fwd: [simh] Announcing the Open SIMH project

by Clem Cole

Announcing the Open SIMH project SIMH is a framework and family of computer simulators, initiated by Bob Supnik and continued with contributions (large and small) from many others, with the primary goal of enabling the preservation of knowledge contained in, and providing the ability to execute/experience, old/historic software via simulation of the hardware on which it ran. This goal has been successfully achieved and has for these years created a diverse community of users and developers. This has mapped to some core operational principles: First, preserve the ability to run old/historically significant software. This means functionally accurate, sometimes bug-compatible, but not cycle-accurate, simulation. Second, make it reasonably easy to add new simulators for other hardware while leveraging common functions between the simulators. Third, exploit the software nature of simulation and make SIMH convenient for debugging a simulated system, by adding non-historical features to the environment. Fourth, make it convenient for users to explore old system environments, with as close to historical interfaces, by mapping them to new features that modern host operating systems provide. Fifth, be inclusive of people and new technology. It's serious work, but it should be fun. Previously, we unfortunately never spent the time to codify how we would deliver on these concepts. Rather, we have relied on an informal use of traditional free and open-source principles. Recently a situation has arisen that compromises some of these principles and thus the entire status of the project, creating consternation among many users and contributors. For this reason, a number of us have stepped up to create a new organizational structure, which we call "The Open SIMH Project", to be the keeper and provide formal governance for the SIMH ecosystem going forward. While details of the structure and how it operates are likely to be refined over time, what will not change is our commitment to maintaining SIMH as a free and open-source project, licensed under an MIT-style license as shown on the "simh" repository page. It is our desire that all of the past users and contributors will come to recognize that the new organizational structure is in the best interests of the community at large and that they will join us in it. However, this iproject as defined, is where we intend to contribute our expertise and time going forward. At this point, we have in place the following, although we foresee other resources being added in the future as we identify the need and execute against them: A Github "organization" for the project at https://github.com/open-simh A Git repository for the simulators themselves at https://github.com/open-simh/simh The license for the SIMH simulator code base, found in LICENSE.txt in the top level of the "simh" repository. The "SIMH related tools" in https://github.com/open-simh/simtools. This is also licensed under MIT style or BSD style open source licenses (which are comparable apart from some minor wording differences). A "SIMH Steering Group" -- project maintainers and guides. The conventional git style process is used for code contributions, via pull request to the project repository. The Steering Group members have approval authority; this list is likely to change and grow over time. By formalizing the underlying structure, our operational principles and guidance can best benefit the community. These are being developed and formalized, with a plan to publish them soon. We have used our best judgment in setting up this structure but are open to discussion and consideration of other ideas, and to making improvements. Many of us have been part of different projects and understand that past mistakes are real. We have tried to learn from these experiences and apply the collected wisdom appropriately. We desire to hear from the community as we update and refine the operating structure for the Open SIMH project. We hope for your patience and look forward to your support as we work to refine the organization and be able to provide this wonderful resource for anyone to use as we continue to evolve the technology provided by the SIMH system. The SIMH Steering Group Clem Cole Richard Cornwell Paul Koning Timothe Litt Seth Morabito Bob Supnik ᐧ ᐧ ᐧ

3 years, 1 month

Please move the SIMH discussion to COFF

by Warren Toomey

Hi all, I think it's time to move the (no longer) SIMH discussion over to the COFF mailing list. The S/N ratio is dropping and we are straying too far away from the Unix side of things. Many thanks! Warren

3 years, 1 month

Re: [TUHS, groff] 1981 edition of AT&T Nroff/Troff User's Manual

by Douglas McIlroy

> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/C.1.2_… Since PDF didn't exist in 1981, the document is either a scan or the result of a recent *roff run on ancient source. If it was made from source, it's an impressive testimonial to the longevity and stability of troff. Most probably it's a scan, in which case we owe many thanks to the public-spirited person who digitized this trove. Was it you, Arnold? Doug

3 years, 1 month

Re: Fwd: [simh] Announcing the Open SIMH project

by Bakul Shah

On Jun 3, 2022, at 4:48 PM, Larry McVoy <lm(a)mcvoy.com> wrote: > Um, so there were 3: 386, Net and Free. That's already 2 too many. My recollection matches what Warner is saying. NetBSD & FreeBSD got going *because* 386BSD was effectively frozen. It wasn't dead dead but patches were not being upstreamed (as we say now), and so on. I do agree with you that even two variants were 1 too many. But even one would probably not have mattered as the AT&T lawsuit was a huge cloud on *BSD's popularity. As well as there were other factors. Linus and Linux had a much better story, its development was more nimble, with many younger and much more enthusiastic developers/users etc. Not that anyone really cares at this point except some graybeards! The Open SIMH project sounds great!

3 years, 1 month

Historical application software

by Paul Ruizendaal

I came across a website that discusses reviving an old binary for Lotus 1-2-3 for SysV Unix (386 COFF), on the way to making it run on Linux: https://lock.cmpxchg8b.com/linux123.html The audience here may enjoy the read, and maybe it is of use when reviving other old application software for 1980’s and 1990’s Unix. The key part I think is this: Quote: "Yikes - it’s an original unstripped object file from 1-2-3. There are nearly 20,000 symbols including private symbols and debug information. Why would Lotus ship this? It’s so big it must have required them to phyiscally ship an extra disk to every customer? Could it have been a mistake, accidentally left on the final release image? I had so many questions, but I’m not old enough to have any experience with SysV, so I asked the greybeards on alt.folklore.computers if they had seen this before and why this might have happened. The answer was that this is probably deliberate - dlopen() was not widely available on UNIX in the early 90s, so there was no easy way to load native plugins or extensions. To solve this, vendors would ship a bunch of partially linked object files with a script to relink them with your extensions – Clever!"

3 years, 1 month

Re: Anyone have an interest in really old analog multimeters and a vacuum tube tested circa 1960s or 1950s?

by Kenneth Goodwin

The party also has a vintage AUTOMOBILE tester If anyone knows of a car collector with a passion for such things interested in a display piece Or if you still have the first car you ever bought sitting in the garage Link to posting attached. https://cnj.craigslist.org/zip/d/hightstown-for-scrap-vintage-eico-888/7489… I am in direct contact with the party offering these items. They are all coming out of basement storage On Sun, May 29, 2022, 8:53 AM Kenneth Goodwin <kennethgoodwin56(a)gmail.com> wrote: > No worries. > > On Sun, May 29, 2022, 12:04 AM John Sambrook <john(a)common-sense.com> > wrote: > >> Hi Kenneth - >> >> Thank you for the pics. >> >> The tube tester appears to be just the meter from a whole tester. >> Usually, a tube tester is about the size of a small suitcase and has a >> number of different sockets on its front panel for testing different types >> of tubes. >> >> One of the meters seems worthwhile, but at this time, I am going to >> decline and hope that at least some of the gear can be salvaged. >> >> Thank you for the consideration. >> >> John >> >> Sent from my iPhone >> >> On May 28, 2022, at 7:18 PM, Kenneth Goodwin <kennethgoodwin56(a)gmail.com> >> wrote: >> >> >> One thing >> >> Sort of looks like the tube checker might be missing a whole lot of the >> rest of it. >> Like an entire cabinet of stuff >> >> See photos >> >> On Sat, May 28, 2022, 10:11 PM Kenneth Goodwin < >> kennethgoodwin56(a)gmail.com> wrote: >> >>> Everyone feel free to inquire around. >>> If it all goes to one private party. Then at least they will know who to >>> passing along to. >>> >>> On Sat, May 28, 2022, 7:45 PM Clem Cole <clemc(a)ccc.com> wrote: >>> >>>> What about the rescue mailing list? >>>> >>>> On Sat, May 28, 2022 at 7:31 PM Ed Cashin <ecashin(a)noserose.net> wrote: >>>> >>>>> If you don't get a response here, I wouldn't mind asking on the >>>>> Heinbach subreddit. Just let me know. >>>>> >>>>> Heinbach is a musician who creates live and recorded music using lab >>>>> equipment. He has a large following of inspired creators who would >>>>> probably love to use this equipment. >>>>> >>>>> >>>>> On Sat, May 28, 2022 at 6:09 PM Kenneth Goodwin < >>>>> kennethgoodwin56(a)gmail.com> wrote: >>>>> >>>>>> Details >>>>>> >>>>>> 1) Knight Allied Radio volt meter 446-06235 >>>>>> 2) Precision Apparatus series 85 volt meter >>>>>> 3) Weston Model 676 Tube checker >>>>>> >>>>>> Useful as display pieces >>>>>> >>>>>> Presumed to all be functional. >>>>>> >>>>>> On Sat, May 28, 2022, 6:06 PM Kenneth Goodwin < >>>>>> kennethgoodwin56(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> I have a party in Hightstown NJ >>>>>>> Looking to donate them. >>>>>>> >>>>>>> Will follow up with specs. >>>>>>> >>>>>>> They already contacted the radio museum in Wall NJ >>>>>>> >>>>>>> I told them to try VCF since they should be a separate organization. >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Ed Cashin <ecashin(a)noserose.net> >>>>> >>>> -- >>>> Sent from a handheld expect more typos than usual >>>> >>>

3 years, 1 month

Why is it always "fast boot" in 2.11BSD?

by Matthias Bruestle

Hi, I have noticed, that 2.11BSD is in all cases where I looked set to "fast boot", which AFAIK means no fsck of at least /. I found nobody talking about this or providing information about how to change it to "slow boot" with a proper check, which is now normal. Is there a reason why it is not possible to deactivate fast boot? Or is it just that nobody bothered to do it? Thanks Matthias -- When You Find Out Your Normal Daily Lifestyle Is Called Quarantine

3 years, 1 month

ACM opens up much of its archives

by Douglas McIlroy

>> If you’re a *current* member of these societies then you should have good access to journal content. >I believe this is true for ACM, but for IEEE not so much. You have to pay for a digital library membership _in addition to_ your standard membership ACM is the same. At $99/year membership is a bargain by ordinary professional society standards. But they charge an additional $99 for access to 21st-century Digital Library.content. Doug

3 years, 1 month

ACM opens up much of its archives

by arnold＠skeeve.com

https://associationsnow.com/2022/05/the-way-things-were-why-open-access-to-… cm-digital-library-matters/

3 years, 1 month

Fwd: ACM Digital Library now open access

by Richard Salz

From an internal $WORK chat: The ACM Digital Library now offers access to ~50 years of papers/records without paywall or registration: https://associationsnow.com/2022/05/the-way-things-were-why-open-access-to-… This includes Dennis Ritchie & Ken Thompson's seminal 1974 "The UNIX Time-Sharing System" (https://dl.acm.org/doi/pdf/10.1145/357980.358014) an interview with one Steve Jobs from 1989 ( https://dl.acm.org/doi/pdf/10.1145/63334.63336) where he discusses basing NeXTSTEP on "Berkeley UNIX" (aka BSD) + Mach and how the (previous year's) Morris Worm "isn't a really serious problem", and goes all the way back to 1951's paper on the UNIVAC ( https://dl.acm.org/doi/pdf/10.1145/1434770.1434772)

3 years, 1 month

First test e-mail

by Warren Toomey

If I'm lucky, this will be the first e-mail to the TUHS list using the mailman3 software on the new minnie server. Cheers, Warren

3 years, 1 month

Re: Pronunciation

by Norman Wilson

It's spelled TUHS but it's pronounced values of beeta may give rise to dom!

3 years, 1 month

Archives of the TUHS mailing list

by Warren Toomey

All, now that the TUHS list has migrated over to the new mailman3 system, I should point out where the list archives are now available. They are: https://minnie.tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/ - new mailman3 format https://minnie.tuhs.org/pipermail/tuhs/ - old mailman2 format https://www.tuhs.org/Archive/Documentation/TUHS/Mail_list/ - same as above, but in a format that makes it easier to download All mail to the TUHS list should, eventually, end up in all three places. Cheers, Warren

3 years, 1 month

Old UNIX file system formats

by norman＠nose.cita.utoronto.ca

I've assembled some notes from old manuals and other sources on the formats used for on-disk file systems through the Seventh Edition: http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html Additional notes, comments on style, and whatnot are welcome. (It may be sensible to send anything in the last two categories directly to me, rather than to the whole list.)

3 years, 1 month

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