TUHS

tuhs@tuhs.org

28 participants
6556 discussions

by Serissa

In the lost-in-time department, my group at Digital Cambridge Research lab in 1993 did an audio interface patterned after the X Window system. Paper in the Summer USENIX: https://www.usenix.org/legacy/publications/library/proceedings/cinci93/gett… For extra fun, the lab director of CRL at the time was Vic Vyssotsky. But there must have been some Bell work, because around 1983 (?) when I was doing Etherphone at PARC I visited John DeTreville at Holmdel. He was building a voice - over - Ethernet system as well. -Larry > On Jan 6, 2025, at 4:51 PM, Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote: > segaloco via TUHS wrote in > <BWYwXjScYdFHM1NV0KEtgvazEfJM1PX7WaZ8lygZ45Bw2pEQG6JQr5OCtX-KMwEwr_k2zLD\ > GXac7wymRCtifnU9VKnlsrJCrKFqGZSgM6-0=(a)protonmail.com>: > |The sound situation in the UNIX world to me has always felt particularly > |fragmentary, with OSS offering some glimmer of hope but faltering under \ > |the long > |shadow of ALSA, with a hodge podge of PCM and other low level interfaces > |littered about other offerings. > > Oh, but *how* great it was when FreeBSD came on over with those > "virtual sound devices", in 4.7 or 4.9 i think it was. Ie instead > of one blocking device, one could open dev.1 and dev.2 and it was > multiplexed in the kernel. It did some format conversion in the > kernel alongside this. > > It was *fantastic*!, and i had a recording program sitting on > a Cyrix 166+ and it took me ~1.5 percent of (single) CPU to record > our then still great Hessenradio HR3 for long hours (Clubnight > with worldwide known DJs, Chill with great sets in the Sunday > mornings), and oh yes HR2 with the wonderful Mr. Paul Bartholomäi > in "Notenschlüssel" (classical music), and the fantastic "Voyager" > hour with Robert Lug on Sunday evening. It cannot be any better. > I could code and compile and there was no stuttering alongside. > 1.5 percent of CPU, honestly! > > I say this because FreeBSD has replaced that very code last year, > if i recall correctly. It now all scales dynmically, if i read > the patches that flew by right. (So it may be even better as of > now, but by then, over twenty years ago, it blew my mind. And the > solution was so simple, you know. The number of concurrent > devices was a compile time constant if i recall correctly, four by > default.) > > I also say this because today i am lucky i can use ALSA on Linux, > and apulse for the firefox i have to use (and do use, too > .. i also browse the internet in such a monster, and at least in > parts still like that). I always hated those server solutions, > where those masses of audio data flow through several context > switches. What for? I never understood. Someone convinced me to > try that pulseaudio server, but i think it was about 20 percent of > CPU for a simple stream, with a terrible GUI, and that on > a i5-8250U CPU @ 1.60GHz with up to 3.4 Ghz (four core; the four > HT are alwys disabled). 20 percent!! > > ... > |Any recollections?[.] > > Sorry, the above is totally apart, but for me the above is still > such a tremendous thing that someone did; and for free. Whoever > it was (i actually never tried to check it, now that i track their > git for so many years), *thank you*! > (And that includes the simple usual format conversions in between > those 22050/44100 etc etc. Just like that -- open a device and > read it, no thousands of callbacks, nothing. And 1.5 percent CPU. > Maybe it is not good/exact enough for studio level audio editing. > But i still have lots of those recordings, except that the "Balkan > piss box" chill somehow disappeared. (Sorry Pedja, shall you read > this.)) > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > | > |In Fall and Winter, feel "The Dropbear Bard"s pint(er). > | > |The banded bear > |without a care, > |Banged on himself for e'er and e'er > | > |Farewell, dear collar bear

7 months, 2 weeks

userland exec -- wasn't exec that way originally?

by ron minnich

Do I remember correctly that the early linux exec as a userland exec? I think this came up before, I just can't recall. I just learned about: https://github.com/hardenedlinux/userland-exec

7 months, 2 weeks

Was the compressed dictionary used?

by arnold＠skeeve.com

Hi. The paper on compressing the dictionary was interesting. In the day of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is a big savings. Was the compressed dictionary put into use? I could imaging that spell(1) at least would have needed some library routines to return a stream of words from it. Just wondering. Thanks, Arnold

7 months, 2 weeks

Bergson Quote, Forward, BSTJ, 57:6 1978

by durtal

I am curious about the apposite Bergson quote (intelligence...tools) found at the beginning of the Forward mentioned in the subject. Specifically, I am wondering if the quote was originally discovered in _Creative Evolution_ as a part of a course or through private reading. I am interested in the diffusion of Continental ideas concerning technology in English speaking countries during the 20th Century. Dr Rick Hayes durtal(a)sdf.org SDF Public Access UNIX System - https://sdf.org

7 months, 3 weeks

Fwd: dmr DECtape Analysis, part N

by Warren Toomey

All, Yufeng Gao has done more amazing work at extracting binaries, source code and text documents from the DECtapes that Dennis Ritchie provided for the Unix Archive: https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ His latest e-mail is below. I've temporarily placed his attachments here: https://minnie.tuhs.org/wktcloud/index.php/s/aWkck2Ljay6c5sB He needs some help with formatting old *roff documents. If someone could offer him help, that would be great. His e-mail address is yufeng.gao AT uq.edu.au Cheers, Warren ----- Forwarded message from Yufeng Gao ----- Date: Tue, 31 Dec 2024 Subject: RE: UNIX DECtapes from dmr Hi Warren, Happy New Year! Here's another update. I found more UNIX bins on another tape ('ken-sky'). They appear to be between V3 and V4. I have attached them as "ken_sky_bins.tar". I have also attached an updated tarball of the V2/V3 bins recovered from the 'e-pi' tape (with a few names corrected), see "identified_v2v3_bins_r2.tar". So far, the rough timeline of UNIX binaries (RTM hereinafter refers to the exact version of the OS described by the preserved manuals) is as follows: Sys: V1 RTM <= unix-study-src < s1/s2 < V2 RTM < V3 RTM < nsys < V4 RTM Bin: V1 RTM < s1/s2 < epi-V2 < epi-V3 < ken-sky-bins < V4 RTM There is a possibility that the V2 bins from the 'e-pi' tape belong to V2 RTM, as they're all PDP-11/20 bins with V2 headers. In contrast, most of the bins from the s1/s2 tapes are V1 bins. Some of them are identical to those from the 's2' tape, and if the timestamps from the 's2' tape can be trusted, they're from May/June 1972. The V3 bins from the 'e-pi' tape are most likely from late 1972 or early 1973, but no later than Feb 1973, as they've been overwritten by files from Feb 1973. This suggests they're from a V3 beta, supported by the fact that some features described in the V3 manual are missing. The files were laid out in perfect alphabetical order on the tape. The bins from the 'ken-sky' tape fall somewhere between V3 RTM and V4 RTM. The directory structure and other elements match the V3 manual, as do the syscalls (e.g., the arguments for kill(2) differ between V3 and V4, and these bins use the V3 arguments). The features, however, are closer to V4. For example, nm(1) had already been rewritten in C and matches the V4 manual's description. The assembler also matches the V4 manual in terms of the number of temp files, and the C compiler refers to the assembler as 'nas.' The assembler is located physically between files starting with "n" and "o," and the files around it follow a weak alphabetical order, so it is logical to assume that it was named "nas". It is a bit difficult to version these binaries, especially without any timestamps. The lines between versions for early UNIX are blurry, and modern software versioning terms like "beta" and "RTM" don't really apply well. If these binaries are to be preserved (which I hope they will be, even though the kernels are long gone), I'd put the V2 bins from 'e-pi' under V2, the V3 bins from 'e-pi' under V3, and the bins from 'ken-sky' under V4 (I'd argue that nsys also falls under V4, as the biggest change between V3 and V4 was the kernel being rewritten in C). There are other overwritten files on the tapes, and I will address them later. There are quite a few patents, papers, and memos in *roff format, but I'm not entirely sure what to do with them. Among those, I have picked out some V4 distribution documents and attached them as a ZIP folder :-). If you know of ways to generate PDFs from these ancient *roff files accurately, please lend a hand - I'm struggling to get accurate results from groff. Sincerely, Yufeng ----- End forwarded message -----

7 months, 3 weeks

B programming language interpreter

by Jackson Helie G

I am currently looking for an interpreter for the B programming language. Can anyone provide one?

7 months, 3 weeks

On the uniqueness of DMR's C compiler

by Paul Ruizendaal

In the last months, I've spent a little time on curating John Walker's Unix clone and software stack, including an emulator to run it: https://gitlab.com/marinchip After creating a basic tool chain (edit, asm, link and a simple executive), John set out to find a compiler. Among the first programs were a port of the META 3 compiler-generator (similar to TMG on early Unix) and a port of Birch-Hansen’s Pascal compiler. META was used to create a compiler that generated threaded code. He found neither compiler good enough for his goals and settled on writing his Unix-like OS in assembler. As the 9900 architecture withered after 1980, this sealed the fate of this OS early on -- had he found a good compiler, the code might have competed alongside Coherent, Idris, and Minix during the 80’s. This made me realise once more how unique the Ritchie C compiler was. In my view its uniqueness combines three aspects: 1. The C language itself 2. The ability to run natively on small hardware (even an LSI-11 system) 3. Generating code with modest overhead versus handwritten assembler (say 30%) As has been observed before, working at a higher abstraction level makes it easier to work on algorithms and on refactoring, often earning back the efficiency loss. John Walkers work may be case in point: I estimate that his hand-coded kernel is 10% larger than an equivalent V6 Unix kernel (as compiled for the 9900 architecture). There are three papers on DMR’s website about the history of the compiler and a compare-and-contrast with other compilers of the era: https://www.bell-labs.com/usr/dmr/www/primevalC.html https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/hopl.html It seems to me that these papers rather understate the importance of generating good quality code. As far as I can tell, BCPL and BLISS came close, but were too large to run on a PDP-11 and only existed as cross-compilers. PL/M was a cross-compiler and generated poorer code. Pascal on small machines compiled to a virtual machine. As far as I can tell, during most of the 70s there was no other compiler that generated good quality code and ran natively on a small (i.e. PDP-11 class) machine. As far as I can tell the uniqueness was mostly in the “c1” phase of the compiler. The front-end code of the “c0” phase seems to use more or less similar techniques as many contemporary compilers. The “c1” phase seems to have been unique in that it managed to do register allocation and instruction selection with a pattern matcher and associated code tables squeezed into a small address space. On a small machine, other native compilers of the era typically proceeded to generate threaded code, code for a virtual machine or poor quality native code that evaluated expressions using stack operations rather than registers. I am not sure why DMR's approach was not more widely used in the 1970’s. The algorithms he used do not seem to be new and appear to have their roots in other (larger) compilers of the 1960’s. The basic design seems to have been in place from the very first iterations of his compiler in 1972 (see V2 tree on TUHS) and he does not mention these algorithms as being special or innovative in his later papers. Any observations / opinions on why DMR’s approach was not more widely used in the 1970’s?

7 months, 3 weeks

SCCS, TeamWare, BitKeeper, and Git

by Marc Rochkind

As I mentioned in another post, I'm writing an invited paper for an upcoming issue of IEEE Transactions on Software Engineering that will be a 50-year retrospective of my original 1975 SCCS paper ( mrochkind.com/aup/talks/SCCS-Slideshow.pdf) Can some people here review a couple of paragraphs for accuracy? *Decentralized Version Control (DVCS)* *While VCSs like CVS and Subversion were centralized and had pre-commit merging, a further advance was towards decentralization, with post-commit merging. Probably the first DVCS was Sun WorkShop TeamWare, created by Larry McVoy and announced in 1992 [sun]. It was implemented as a layer on top of SCCS. McVoy later commercialized a successor system called BitKeeper [Bitkeeper], which was layered on a re-implementation of SCCS, which he called BitSCCS. TeamWare and BitKeeper took advantage of the interleaved delta algorithm, also known as a weave, to implement an efficient way to represent merged deltas by reference, instead of reproducing code inside the repository. This is a lot more complicated to do with reverse deltas, introduced by RCS.* *In 2005 Linus Torvalds, creator of Linux [linux], invented the DVCS Git [git] for Linux development, and since then Git has become widely used and has supplanted BitKeeper.* [more about DVCS follows] I don't want to add more detail that would make these paragraphs any longer, but I do want them to be accurate. Thanks! Marc Rochkind -- *My new email address is mrochkind(a)gmail.com <mrochkind(a)gmail.com>*

8 months

Re: SCCS roach motel

by norman＠oclsc.org

Rob Pike: According to the Unix room fortunes file, the actual quote is SCCS: the source-code motel -- your code checks in but it never checks out. Ken Thompson ==== As a Unix-room-culture aside: I believe this quote was what inspired Andrew Hume to call his backup system the File Motel. Norman Wilson Toronto ON

8 months, 1 week

Re: mmap, was SCCS, TeamWare, BitKeeper, and Git

by Douglas McIlroy

>> Does anyone know whether there are implementations of mmap that >> do transparent file sharing? It seems to me that should be possible by >> making the buffer cache share pages with mmapping processes. > These days they all do. The POSIX rationale says: > ... When multiple processes map the same memory object, they can > share access to the underlying data. Notice the weasel word "can". It is not guaranteed that they will do so automatically without delay. Apparently each process may have a physically distinct copy of the data, not shared access to a single location. The Linux man page mmap(2), for example, makes it very clear that mmap has a cache-coherence problem, at least in that system. The existence of msync(2) is a visible symptom of the problem. [Weasel words of my own: I have not read the POSIX definition of mmap.] Doug

8 months, 1 week

Re: mmap, was SCCS, TeamWare, BitKeeper, and Git

by John R Levine

On Mon, 16 Dec 2024, Konstantin Belousov wrote: > On Mon, Dec 16, 2024 at 02:08:43PM -0500, John Levine wrote: >> PS: I can believe there are some versions of linux that screwed up disk cache >> coherency, but that just means they don't properly implement the spec, not for >> the first time. I mean, it's not *that* hard to make all the maps point to the >> same physical page frame, even on a machine like POWER with reverse page maps. > > This is not enough. There are (were ?) architectures, typically with the > virtually addressed caches, which require all mappings of the same page > to be suitably aligned, at least. ... > > If addresses of different mappings are not aligned, caches were not coherent. I think we're in "so don't do that" territory. mmap() normally lets the system pick the memory address to map so it can pick something suitably aligned. You can pass the MAP_FIXED flag to tell it to map at a particular address, but it can return EINVAL if the address doesn't work. The POSIX description says "The use of MAP_FIXED is discouraged, as it may prevent an implementation from making the most effective use of resources." It's not always trivial to make this work. On systems with reverse maps, a physical page can only be mapped to one virtual address at a time, so for shared pages it has to mark all of the aliases nonresident and on a fault remap the page into the map of the process that is running. But it's not rocket science, either. R's, John

8 months, 1 week

Re: M<some number> macros, wasRe: SCCS

by Douglas McIlroy

> "John Levine" <johnl(a)taugh.com> wrote: >> M4 was written in the 1970s by Kernighan and Ritchie in C ... > In private mail, BWK told me that it was DMR who wrote m4. He t> hen reimplemented it in Ratfor for "Software Tools". > Arnold The book says colorfully, "... [and] we are grateful to him for letting us steal it." Doug

8 months, 1 week

Re: SCCS, TeamWare, BitKeeper, and Git

by Douglas McIlroy

> well after Unix had fledged, its developers at CSRC found it necessary > and/or desirable to borrow back a Multics concept: they named it mmap(). As far as I know no Research version of Unix ever had mmap. Multics had a segmented universal memory. A process incorporated segments into its address space The universal memory was normally addressed via a hierachical segment-name directory. With enhancement to provide for multisegment "files", the directory could serve as a file system and file I/O became data transfer between segments. Unix originally imitated the Multics file system, but not the universal memory. mmap(2) weakly imitates universal memory by allowing a process to nominally incorporate a portion of a file into the process address space at page-level granularity. However, an update is guaranteed to be visible to the file and other processes only upon specific request. Does anyone know whether there are implementations of mmap that do transparent file sharing? It seems to me that should be possible by making the buffer cache share pages with mmapping processes. Doug

8 months, 1 week

BSD talk program?

by Dan Cross

I'm curious if anyone has any history they can share about the BSD "talk" program. I was fond of this back when it was still (relatively) common, but given the way it's architected I definitely see why it fell out of use as the Internet grew. Still, does anybody know what the history behind it is? Initially, I thought it was written by Mike Karels, but that was just my speculation from SCCS spelunking, and looking at the sources from 4.2, I see RCS header strings that indicate it was written by "moore" (Peter Moore?). talk.c says, "Written by Kipp Hickman". It seems to have arrived pretty early on with respect to the introduction of TCP/IP in BSD: the README alludes to some things coming up in 4.1c. Clem, you seem to have had a hand in it, and are credited (along with Peter Moore) for making it work on 4.1a. So I guess the question is, what was the motivation? Was it just to have a more pleasing user-to-user communications experience, or was discussion across the network an explicit goal? There's a note in talk.c ("Modified to run between hosts by Peter Moore, 8/19/82") that suggests this wasn't the original intent. Who thought up the character-at-a-time display mode? Thanks for any insights. - Dan C.

8 months, 1 week

SCCS roach motel

by Marc Rochkind

IEEE Transactions on Software Engineering has asked me to write a retrospective on the influence of SCCS over the last 50 years, as my SCCS paper was published in 1975. They consider it one of the most influential papers from TSE's first decade. There's a funny quote from Ken Thompson that circulates from time-to-time: "SCCS, the source motel! Programs check in and never check out!" But nobody seems to know what it means exactly. As part of my research, I asked Ken what the quote meant, sunce I wanted to include it. He explained that it refers to SCCS storing binary data in its repository file, preventing UNIX text tools from operating on the file. Of course, this is only one of SCCS's many weaknesses. If you have anything funny about any of the others, post it here. I already have all the boring usual stuff (e.g., long-term locks, file-oriented, no merging). Marc Rochkind mrochkind.com

8 months, 1 week

BSD Talk History -- Credit Where Credit is Due

by Clem Cole

I was thinking about this some more. IIRC: Peter and I sketched out the protocol for the sockets version on a whiteboard in our office one night after a beer and pizza run. Rick Spicklemeir, Tom Quarles, and Jim Kleckner also participated in those bull sessions. I started writing the program soon after that and had it working to a point in a couple of hours. I don't remember the issues, but a couple of them were when I left for the USENIX conference later that week. When I got back Peter had finished it and put it into RCS. The key is that the coding was primarily Peter and myself, but Rick, TQ, and Jim all had contributed in some manner, too, Although the famous bug of using a vax integer, you can squarely blame me — and as I said, having worked on networking for several years before my time at UCB, I should have known better. But did not even think about it. I failed Henry's ten programming commandments and concluded that the world was a Vax. Mei culpa. ᐧ

8 months, 1 week

Re: SCCS roach motel

by Marc Rochkind

On Fri, Dec 13, 2024 at 10:03 AM Mark Seiden <mseiden(a)gmail.com> wrote: > (I know there is a special place in hell for those who explain a joke, > but, you asked…) > > it’s just an allusion to the Black Flag Roach Motel product (still being > produced) > which has a trademark on the phrase “Roaches Check in… But they Don’t > Check Out”. > > Yeah, I knew that much. My question to Ken was about what this was saying about SCCS. Marc

8 months, 1 week

Re: SCCS roach motel

by norman＠oclsc.org

This is verging on COFF material, and I won't mind if someone moves the discussion thither: Clem Cole: As a satisfied user of SCCS (and later Bitkeeper), it's still my preferred choice. ==== I have to admit SCCS is one of the many pieces of software I tried for a week or two > 40 years ago and abandoned because I couldn't stand it. I don't think I ever tried RCS, because I could see it didn't what I saw as the underlying problems. CVS likewise. Subversion was the earliest version-control system that felt usable to me. What bugged me so much? The earlier systems were focussed entirely (or for CVS, almost entirely) on individual files. There was no way to link changes that affected more than one file: -- SCCS and RCS don't (so far as I can tell) understand any relation between files at all. When I'm working on a real project of any size, there is almost always more than one file, and there are often changes that affect multiple files at once: if an interface changes, the changes to definitions and uses really all should be a single commit, logged in one go and reversible as a single coordinated operation; if I refactor code, moving it between files and perhaps adding files or removing them, likewise. It is possible to check in a bunch of files at once and reuse the log message, but I couldn't find a way to make it a true coordinated single commit; and neither SCCS nor RCS has a way I could find to record, as a structured commit, that files are added or removed from a directory or directory tree. -- CVS can track adds and deletes and can bundle changes into a single commit on the command line, but the changes are still stored individually per file. -- None of the systems even tries to track file renames, something I also do occasionally as programs and especially documentation evolves. It wasn't until I discovered Subversion that I started using version control regularly in my own work. Ironically, a few years after I began using svn for myself, I ended up working in places that had great compost heaps of RCS and CVS. This would have made sense in the 1990s, but it was in the 2010s, and continues in the 2020s. I now use hg for my personal work, and have been attempting to drag my workplace into using git if only so new hires don't have to learn clumsy outdated stuff just to do their jobs. I expect to retire (not for this reason) before I really succeed, though. Norman Wilson Toronto ON

8 months, 1 week

[rick@rbsmith.com: Re: SCCS roach motel]

by Larry McVoy

----- Forwarded message from Rick Smith <rick(a)rbsmith.com> ----- Date: Fri, 13 Dec 2024 18:22:29 -0500 From: Rick Smith <rick(a)rbsmith.com> To: Larry McVoy <lm(a)mcvoy.com> Subject: Re: [TUHS] SCCS roach motel X-Mailer: Apple Mail (2.3826.300.87.4.3) Hi Larry, I likely can???t post to TUHS without joining, though I can read it fine. Anyway, feel free to edit and post: Marc, I remember in 1992 driving to the UCSD library to get that issue of TSE and make make copy of the article. I still have it and wrote about it on HN [1]. The link I posted at the end there is dead (wayback [2]). It is a post by J??rg Schilling about your post here on TUHS about SCCS. Yes, we could get lost in the weeds about choice of control-A, lack of merge bookkeeping and the corner cases with -i and -x when applying strict order to a partial order when computing the graph-to-set but in the big picture, the SCCS system is a huge contribution. Congratulations on writing one of the most influential papers in TSE's first decade! Certainly is that for me. Aside, Larry wrote: > ... He [Rick] did point out that my weave implementation was the only > one written such that I could have N serial sets in my hand, and do one > pass through the weave and get N different checked out files. I don't > think we ever used that but if we did it would be in smerge.c. The original makepatch() uses it in sccs_getdiffs() which walks the weave calling changestate() once to track weave structure and printstate() twice, generating a diff in one pass. While this is a hats off to Marc, there is also a hats off to Larry for extending the SCCS work with TeamWare and Bitkeeper. I studied SCCS (and other engines). Larry built systems. [1] https://news.ycombinator.com/item?id=26225001 [2] https://web.archive.org/web/20190403213137/http://sccs.sourceforge.net/sccs… ----- End forwarded message ----- -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat

8 months, 1 week

Interesting post about Microsoft and UNIX

by Marc Rochkind

I just came across a 1995 post from Gordon Letwin, early Microsoft employee and lead architect of OS/2, about the history of OS/2. There are a few paragraphs in it about Microsoft and UNIX. Here's Letwin's post: https://gunkies.org/wiki/Gordon_Letwin_OS/2_usenet_post And the UNIX-related paragraphs: *It's extremely hard to do development work on an operating system when someone else controls the standard. "Control" in this case is a matter of public perception. For example, Microsoft was once very big in the Unix world. In fact, we considered it our candidate for the future desktop operating system, when machines got powerful enough to run something good. We were the worlds biggest seller of Unix systems. DOS was, when we first wrote it, a one-time throw-away product intended to keep IBM happy so that they'd buy our languages.The UNIX contracts were all done when Bell Labs was regulated and couldn't sell Unix into the commerical marketplace. So although they wrote it and were paid royalties, they couldn't develop it in competition to us. But after a few years that changed. Bell was degregulated and now they were selling Unix directly, in competition to us! They might sell it for cheaper than we had to pay them in royalties! But that wasn't the real killer, the real killer was the Bell now controlled the standard. If we wrote an API extension that did X, and Bell wrote an incompatible one that did Y, which one would people write for? The ISVs know that AT&T was a very big company and that they'd written the original, so they'd believe that AT&T controlled the standard, not MS, and that belief would then define reality. So we'd always just be waiting for what AT&T announced and then frantically trying to duplicate it.Bill Gates knew, right away, that there was no strong future in Unix for us any more. Fortunately at that time, DOS was taking off and we were learning, along with everyone else, about the power of standards. So the primary OS team - the Unix guys - joined with the secondary OS team - the DOS guys - and the earliest versions of OS/2 were born. (This was before IBM came on board, so it wasn't called OS/2!)* Marc Rochkind

8 months, 1 week

A re-analysis of some DECtapes from dmr

by Warren Toomey

All, I received this detailed e-mail from Yufeng Gao who has done a great job at analysing some of the DECtapes that Dennis made available to the Unix Archive. I'm sure many of you would be interested and, possibly, could provide some feedback on his work. A tarball of his efforts are here: https://mega.nz/file/1cJFTJxT#BgszYuFc_ebSMaQXAIG5b2NtaGInPWMoaxExPM5Lr9Y Cheers, Warren P.S. I have a follow-up e-mail coming ... ----- Forwarded message from Yufeng Gao ----- Subject: UNIX DECtapes from Ritchie Hi Warren, I am writing you this email after seeing the DECtapes from Dennis Ritchie that you put up last year. I found them while playing around with the early C compilers on Ritchie's site. After some research into the tapes, I have written a parser to parse them and convert them into tarballs suitable for preservation. Most importantly, the 'dmr' tape and 's1' tape are currently not decoded properly. The biggest issue with the current decoding of the 's1' tape is, well, there is none. After quickly glancing over the tape, I have concluded that it is in fact not one of the middle tapes of an rkd(1) backup, but a copy of UNIX INIT DECtape from a version of UNIX between V1 and V2. I have extracted its contents: Mode UID GID Size Date Name ---------- --- --- ----- ------------------- ------------ -rw-rw-rw- 0 0 512 1970-01-01 00:00:00 [vcboot] -rw-rw-rw- 0 0 2048 1970-01-01 00:00:00 [bos] -rw-rw-rw- 0 0 12288 1970-01-01 00:00:00 [wunix] -rw-rw-rw- 0 0 12288 1970-01-01 00:00:00 [cunix] -rw-rw-rw- 0 0 3072 1970-01-01 00:00:00 [unassigned] -rwxr-xr-x 1 0 424 1970-01-01 00:00:00 /etc/init -rwxrwxrwx 3 0 446 1970-01-01 00:00:00 /etc/getty -rwxr-xr-x 3 0 82 1970-01-01 00:00:00 /bin/chmod -rwsr-xr-x 0 0 794 1970-01-01 00:00:00 /bin/date -rwsr-xr-x 0 0 1290 1970-01-01 00:00:00 /bin/login -rwsr-xr-x 0 0 232 1970-01-01 00:00:00 /bin/mkdir -rwxr-xr-x 1 0 954 1970-01-01 00:00:00 /bin/sh -rwsr-xr-x 0 0 3678 1970-01-01 00:00:00 /bin/tap -rwxr-xr-x 3 0 2010 1970-01-01 00:00:00 /bin/ls 578 blocks, 98 (16.96%) used, 480 (83.04%) free. B = boot; D = directroy; . = free; X = file data; O = bos; W = wunix; C = cunix; S = rf slack; U = unassigned program; |0123456789ABCDEF --+---------------- 00|BOOOOWWWWWWWWWWW 01|WWWWWWWWWWWWWCCC 02|CCCCCCCCCCCCCCCC 03|CCCCCUUUUUUSSSSS 04|SDXDXDXDXXDXXXDX 05|DXXDXXXXXXXXDXXX 06|XD.............. 07|................ <...> What is significant here is it contains the vcboot and bos programs mentioned in bproc(7), as well as a Warm and a Cold UNIX kernel. This version of UNIX appears to be between V1 and V2, which I believe is the earliest to exist in binary form. The reason why I say it's between V1 and V2 is its bos program accepts the following console switches compared to V1 and V2: | UNIX V1 | s1 | UNIX V2 ----------------------+----------+-------+--------- Warm boot | [1]73700 | ??? | ??? Cold boot | 1 | 1 | 1 Unassigned 3K prog | 2 | 2 | Dump core & halt | 10 | 10 | 10 Boot from RK | | 20 | 20 Dump core & warm boot | | 40 | 40 Boot from paper tape | 0 | 0 | 0 Load DEC loaders | 57500 | 57500 | 77500 ----------------------+----------+-------+--------- UNIX load address | 400 | 400 | 600 ----------------------+----------+-------+--------- The boot-from-unassigned-3K-program option was probably in the process of being depreciated, as the 3K of space is also loaded as a part of the Cold UNIX despite it not being used by the Cold UNIX kernel. The list of files on the 's1' tape also appear to be between V1 and V2: | V1 | s1 | V2 -----------+-----+-----+----- /etc/init | Yes | Yes | Yes /etc/getty | No | Yes | Y/N /bin/chmod | Yes | Yes | Yes /bin/chown | Yes | No | No /bin/date | No | Yes | Yes /bin/login | No | Yes | Yes /bin/cp | Yes | No | No /bin/ln | Yes | No | No /bin/ls | Yes | Yes | Yes /bin/mkdir | Yes | Yes | Yes /bin/mv | Yes | No | No /bin/rm | Yes | No | No /bin/rmdir | Yes | No | No /etc/mount | No | No | Yes /bin/sh | Yes | Yes | Yes /bin/stat | Yes | No | No /bin/tap | Yes | Yes | Yes -----------+-----+-----+----- Given that the files on this tape are identical to the same files on the 's2' tape and that the files on the 's2' tape are also sort of between V1 and V2, and that this tape is named 's1' while the other is named 's2', they are probably from the same version of UNIX. I have tried booting the 's1' tape using SIMH, but unfortunately it did not work and I have not yet attempted to debug it. Next I'm going to talk about the 'dmr' tape. It’s interesting, most of it was written by tap(1) running under UNIX V1-V2, but files in the ./paper directory were written by tap(1) running under UNIX V4. When decoded using the tap(1) program itself, the timestamps and access modes of those files are garbled. My program corrected the timestamps and access modes in the converted tar(1) archive. The same goes for the 'nsys' tape. The tar(1) conversion of 's2' (/Archive/Distributions/Research/1972_stuff/s2-bits.tar.gz) in the TUHS archives is missing some files in the /etc directory - compare it with mine and Ritchie's (Ritchie's has wrong timestamps and access modes, however). Speaking of timestamps and the 's2' tape, the timestamps outputted by tap(1) are inaccurate because 1972 is a leap year and the ctime(3) function hard coded 28 for the number of days in February. I have attached an archive of my tar(1) conversion of each tape, as well as tarballs containing all the slack space data and unused blocks which I dumped for data recovery and forensic analysis purposes. There are some interesting bits and pieces in the unused blocks of various tapes, but I have not had time to look into them in detail. Just a very quick summary: * The 'config' tape has leftover of a dictionary file. * The 'dmr' tape has some assembler manual ?roff leftover. * The 'dmr2' tape has some paper ?roff leftover. * The 'e-pi' tape has a lot of interesting binary stuff, including bits and pieces of a B compiler from what I can tell. * The 'ken' tape has some C source fragments and Thompson’s mail templates and some UNIX manual ?roff leftover. * The 'ken-du' tape has some paper ?roff leftover. * The 'ken-sky' tape has some binary leftover. * The 'nsys' tape has some source code leftover of what seems to be the kernel. * The 's1' tape has some source code leftover of what seems to be userland programs. * The 'scratch' tape has some binary and source listing and ?roff leftover. * The 'unix' tape has some binary leftover. I hope that these newly extracted stuff could be put up in the TUHS archives :). If the attachment in this email somehow doesn't come through, I have also uploaded the archive [1]here. I have a disassembly of vcboot and bos from 's1', they may help with the UNIX V1 reconstruction project - let me know if you need them. If you can get the 's1' kernel to boot, I'd like to also receive an update. Sincerely, Yufeng Gao ----- End forwarded message -----

8 months, 2 weeks

Re: A re-analysis of some DECtapes from dmr

by jnc＠mercury.lcs.mit.edu

> From: Yufeng Gao > This version of UNIX appears to be between V1 and V2 It's too bad it's not 'between V2 and V3', since the UNIX kernels V2 and V3 are missing. (V4 is the earlist one that we have, after the V2 and onward gap.) So, depending on how far from V1 (which we have) it is, it _might_ be worth dis-assenbling. It would be particularly worth having it if it suppports the KS11, since almost no documentation of that has survived; code that uses it would allow re-creation of a programming manual for it. > From: Lars Brinkhoff > Is the kernel for a PDP-11/20 or /45? I don't think it can be the /45; as of V2, the /45 was apparently expected in the near future, and this was before the V2. Noel

8 months, 2 weeks

After 50 years, what has the Impact of Unix been?

by sjenkin＠canb.auug.org.au

I was looking at the question of “impact of Unix" and thought that: initiating (Portable) Open Source Software including the BSD TCP/IP & Berkeley sockets libraries, the Unix -> Minix -> Linux -> Android sequence and BSD -> NeXtstep -> OS/X -> iOS sequence, plus running the Top 500 supercomputers and most of the Top 500 websites, including the infrastructure for trillion dollars companies, Facebook, Amazon (Netflix uses them), and Google plus so many embedded Linux / NetBSD based appliances even going into space - on small experiments or driving SpaceX’s Falcon 9 & presumably Starship, would be a slam-dunk for “really high impact” - dominating everywhere important, except Windows desktops. Unix wasn’t just a ’research project’, it was the result of years of work by a team of very capable, professional programmers, who weren’t looking for kudos or recognition, nor trying to add every conceivable ‘feature’ possible, but the inverse: how _small_ could it be and still be enough. When it left the Labs, Unix wasn’t just “Performant”, it came with a very useful set of tools for creating other tools (‘developing’) and while the kernel wasn’t perfect (some ‘panic’s), it was of “Production Quality”. For v6, I believe there were patches for 50-100 bugs circulating, perhaps the first demonstration of “no bug is intractable with ‘many eyeballs’”. All that in under 5 years of ‘development’, with the “initial release” stable & performant enough for cash-strapped Universities to gamble their reputations & budgets on running it. Imagine the grief academics would’ve got if their basic teaching systems failed continuously! This adoption path pushed Unix through another barrier: ’Security’ - with a lot of bright, bored & curious students banging on it as hard as they could for bragging rights. How long, in releases or years, did it take for other O/S’s to hit the “very stable” benchmark? I don’t know enough of Linux to answer that definitively, the *BSD’s grew there through usage and contribution, while Microsoft NT derivates widely suffered “Blue Screen of Death” for years. Even now, MS-Windows has serious Security / compromise issues, like the highly visible, global “Crowdstrike” event. Not a break-in or takeover, but an own-goal from Security perimeter control. ========== I now think Unix has had a much larger, direct and important impact - the C language and associated tools & libraries that begat modern toolchains and endless portability across platforms. In 1991, Bill Plauger had a year sabbatical at UNSW in Sydney, and happened to say : “C is wallpaper - people expect it everywhere”. C gained formal recognition with the POSIX standard, satisfying conservative users / enterprises that it wasn’t the work of a bunch of Hippies or ill-disciplined Hackers. Even Microsoft wrote 32-bit Windows NT in C, I presume starting by writing it’s own compiler and toolchain to start. Borland, Watcom and many others - including Microsoft - offered (Visual) C compile & build environments for Windows, directly responsible for creating the ’shrink-wrap’ third party software market that drove sales of Windows and x86 machines. Nobody had seen a market for a billion systems before, nor sold 300M+ CPU’s in a single year. People don’t buy Silicon Chips or nice Boxes, they buy Applications that solve their problems: Software drives Sales of Hardware - something that IBM deeply understood first with first the 1401 line, then 360-series. The other ’small’ achievement of C and Unix was creating the market for RISC chips. MIPS in the mid-1980’s was only able to design and build the first commercial RISC chip because it knew it could port Unix to it and find an immediate market - not at zero-cost, but a tiny fraction of what every other Vendor had done before reinventing the wheel from scratch to provide incompatible O/S & tools for their hardware. Unix on MIPS not only came with a host of proven software, that a large pool of people knew how to use, but it arrived as “Production Quality” - the porting team had to test their parts - compiler, linker, libraries - hard, but could trust the existing high-quality codebase. In "A New Golden Age for Computer Architecture”, 2019 by Hennessy & Patterson, make an aside: In today's post-PC era, x86 shipments have fallen almost 10% per year since the peak in 2011, while chips with RISC processors have skyrocketed to 20 billion. Today, 99% of 32-bit and 64-bit processors are RISC. i suggest this goes back to PCC followed by the MIPS R2000 - made possible by Dennis’ C language. The 1977 invention of ‘pcc’ and rewriting of Unix for cross-machine portability was the first time I’m aware of this being done. ( Miller @ UoW did a one-off hack, not to devalue his work, he ported, didn’t invent a multi-target portable compiler ) One of the effects of “portable C” was creating whole new industries for third party software developers or enabling niche products, like CISCO routers and the many embedded devices. C and Unix came with the tools to create new languages and new tools. AWK, sed (!) and shells are obvious examples, with Perl, Python & PHP very big in Internet of 2000. C was a new class of language - a tool to create tools. It creates a perfect mechanism to bootstrap any new language, tool or product, allowing to be refined & used enough to become reliable before being made self-hosting. Very widely used languages such as Python are written in C. ORACLE achieved its market dominance by providing ‘portability’ - exactly the same on every platform. Underpinned by portable C. The original 1127 team went on to create other systems and languages, not the least being a new Software Engineering tool, “Go” / golang, addressing a whole slew of deficiencies in the C/C++ approach and We’d have no Internet today without Apache written in C and being ported to every environment. Also, there’s a connection between C and ‘modern’ Software Engineering - distributed Repositories, automated builds & regression tests, and the many toolchains and tools used. They tended to be built in C to address problems (Open Source) developers were finding with existing toolchains. ‘make’ arose at Bell Labs to automate builds, along with PWB and Writers Workbench. There’s two questions / observations about 50 years of C in broad use: - Just how much C is out there and used ‘in production’? - C is ‘obviously’ a product of the 1970’s, not reflecting needs of modern hardware, networks, storage and systems, but _what_ can replace it? There is simply too much critical code written in C to convert it to another ‘better, modern’ language. Any new language that is a simple 1:1 rewriting of C cannot address any of the deficiencies, while any incompatible language requires redesign and reimplementation of everything - an unachievable goal. The Linux Kernel’s “rust” project shows the extent of the problem - even with the best team of the best developers, its a mammoth undertaking, with uncertain payoffs, unquantifiable effort & deadlines. My thesis is that portable, standard C: - not only co-evolved with other tools & needs to create the Modern Software Engineering environment, the basis for multiple Trillion dollar enterprises (FAANG) but - drove the biggest, most profitable software market ever seen (Wintel) - which drove sales volume of x86 chips (& DRAM, motherboards, LAN, GPU, monitors, peripherals…) over 2-3 decades, - which drove Silicon Valley, paying for new generations of Fabs and lowering chip prices further & further - and eventually created the Fabless RISC CPU company, which in the Post-PC era absolutely dominates chip sales. No Software, no Silicon… Gordon Moore, in an early comment on his 1968 startup with Robert Noyce, said: “we are the real revolutionaries" (vs Hippies & 1967 Summer of Love). I think Ken & Dennis [ and 1127/ Bell Labs folk ] can say the same. ========== I’ve written some notes, with links to Programming Languages, especially Jean Sammet’s Histories, and would like some critiques, suggestions & corrections if people have time and interest. Unix and C are intimately related - neither was possible or useful without the other. i think there’s an interesting article in there, but I’m not sure I have what it takes to write it, not in a finite time :) Very happy to help anyone who does! Did-C-lang-create-modern-software-industry.txt <https://drive.google.com/file/d/1k936sgqHc-vHBvfCdLoSxFhdT9NaijU2/view?usp=…> steve jenkin 04 - dec - 2024 ========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

8 months, 2 weeks

Xenix Distribution for PDP-11

by Henry Bent

Hello all, The recent discussion about Xenix has me curious: does any Xenix distribution for the PDP-11 survive? I've never seen one and it would be a fascinating historical artifact. That being said, I am not soliciting copyrighted software; I would be more than happy with a simple answer of, "yes, one has been archived." -Henry

8 months, 2 weeks

Re: Pipes (was Re: After 50 years, what has the Impact

by Steve Simon

helios supported DAG shell syntax. helios was a unix style os (was it actually posix compliant?) for networks of transputers. -Steve

8 months, 2 weeks

← Newer
1
...
4
5
6
7
8
9
10
...
263
Older →

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