TUHS

tuhs@tuhs.org

12 participants
6534 discussions

OT: TUHS mails not going to Outlook & Hotmail. Help!

by Warren Toomey

All, e-mails from the TUHS server are not making it to Hotmail or Outlook. I've not changed anything. Is there anybody with some MTA/ISP experience who might be able to help diagnose the problem? Thanks, Warren

2 years, 2 months

The Gnome and Its "Secret Place"

by segaloco

In the midst of my documentation research, I've done a little analysis on the life and times of this whimsical little phrase which first appeared in the "HOW TO GET STARTED" or basinf section of the Third Edition manual (a derivative of the original login(VII) page): "When you type to UNIX, a gnome deep in the system is gathering your characters and saving them in a secret place." Aside from the wonderful imagery of the terminal interrupt driver as a little gnome, I've found that this line has some implications regarding UNIX documentation lineages. This exact verbiage survives in the research line through the Sixth Edition, and is slightly edited prior to the Seventh: "When you type characters, a gnome deep in the system gathers your characters and saves them in a secret place." The latter of the two changes holds with a trend over time of using progressive rather than continuous language. That aside, simple change of "to UNIX" to "characters". Seems simple enough, reduce redundancy and make it more clear what is happening. In this same breath, basinf was merged into intro. Checking the Tenth Edition manpage sources on the source tree, this version then seems to persist for the rest of the research lifetime. Peering across into BSD-land, I had to pull a paper copy for this one because I can't find the intro document in the tree, but it likewise has the same exact text, so this version also persisted through the remainder of the UCB development period. When you start to look into other Bell lineages, things get a little more interesting. Let's start with MERT Release 0. This manual was produced in October, 1977, and has a "gnome" message identical to that in the Sixth Edition manual, so presumably by this time, the old text could very well have still been up in research. Unfortunately we only have scans of this manual, so I can't say whether the merge from intro and basinf to just intro has happened yet. Additionally, this may not reflect the case with USG Program Generic 3 (or any of those) as the intro is one of the sections marked as modified from the USG manual. Next let's check the situation with PWB 1.0. To start, the intro and basinf documents have been merged into a document titled "introduction", which may very well indicate that this manual page at least was produced after the merge in the research line, and given this was July 1977, that's a case for the MERT 0 page likewise probably being a merged page. However, the text reads: "When you type to UNIX, a gnome deep in the system is gathering your characters and saving them." So a different modification of the Sixth Edition text, we still have "to UNIX" and the continuous "is gathering...and saving". What does change is we no longer know where the gnome is saving those characters. We've now lost the secret place, research and BSD carry on knowing the real story, and MERT 0 kept this intact as well. Taking a look further afield, in the System III manuals, originally produced in 1980, we see the same as PWB, a merged intro document (now just named intro again), and the same text, the Sixth Edition text minus the secret place commentary. So whatever merges of documentation took place between PWB 1.0 and 3.0, it seems the updated text from the Seventh Edition was never picked up, and the modified line persisted through to this point. Checking forward, this text persists into the release of PWB 5.0. The first release of System V only changes "UNIX" to "the UNIX System", consistent with nomenclature changes throughout documentation in the PWB 5.0->System V transition. Taking a little peek aside into yet another lineage, the CB-UNIX 2.3 manuals circa 1981 likewise carry this same text, with the "secret place" removed. Unfortunately we don't have any other versions of CB-UNIX manuals to compare with, but the specific page in question actually lists CB-UNIX 2.1 in the footer with a date of November 1979, so the PWB-ish text in that lineage dates to at least that point. There are a few different variations circa SVR2, with the 1983 BTL version and 1984 DEC processors versions of the manual changing the first bit to "When you type to UNIX system", whereas the 1986 HRW tradebook manuals state "When you type to the UNIX system." So the "the" is dropped, "system" is lower-cased, but then the "the" is added back between 1984 and 1986. Finally, there is one more variation on this line, the saddest one of all, that appears circa System V Release 3 material in 1987: "When you type to the UNIX system, your individual characters are being gathered and temporarily saved." "Pay no attention to the gnome behind the curtain," says AT&T, removing all whimsy from the equation. This persists into SVR4. Can't say what happens in SVR4.2, I don't have one of those user's manuals, but in any case, it's probably save to assume Novell didn't resurrect the gnome. So just to review the strange and wonderful journey our little gnome has been on: - Introduced in Third Edition - intro and basinf documents merged between Sixth and Seventh Edition - MERT 0 takes the old text - PWB line takes the old text and drops the reference to a "secret place" - Seventh Edition adjusts the text to drop UNIX redundancy and use progressive language - PWB line keeps rolling with their modified text, CB-UNIX takes it up (or vice versa? can't conclude anything there) - PWB to System V process converts most references of "UNIX" to "the UNIX System" - Along the way, the "System" is ultimately lowercased, the "the" gets lost for a while and comes back - AT&T finally removes the gnome reference in SVR3/1987 - Research and BSD keep the Seventh Edition text to the end Granted, this is a very trivial detail, but one that does demonstrate some flow of documentation revisions and what sorts of changes different groups were making to their documents, what with research making changes to the grammatical style while the PWB-then-commercial line grew more sterile in this presentation over time. This then shows at least one instance of a lack of merging of aspects of the Seventh Edition documentation back into the PWB line after the split of 1.0. Eventually I hope to illuminate many more such areas through the diffing and historical analysis I'm performing. By the way, I believe a few list members had indicated at some point or another being in possession of some USG Program Generic manuals. If you happen to catch this, and have the time, I'd be ever so curious which of the above, if any, variations on the text they contain. This particular line is immediately following the "How to communicate through your terminal" heading the "HOW TO GET STARTED" section. Anywho, I hope this was an entertaining diversion. While most of the analysis I'm performing concerns software details and version differences, it's also nice to take a closer look at some of the other sorts of changes that have happened in the lifetime of the system's growth and diversification. - Matt G.

2 years, 2 months

Re: Corbato dead

by Douglas McIlroy

Although it dates from four years ago, MIT's obituary for Corbató was still interesting to reread. It couldn't bring itself to mention Unix--only the latecomer Linux. It also peddled some mythology about Whirlwind from the decade before timesharing. "Whirlwind was ... a rather clunky machine. Researchers often had trouble getting much work done on it, since they had to take turns using it for half-hour chunks of time. (Corbató said that it had a habit of crashing every 20 minutes or so.)" "Clunky" perhaps refers to Whirlwind's physical size. It occupied two stories of the Barta Building, not counting the rotating AC/DC motor-generators in the basement. But it was not ponderous; its clean architecture prefigured "RISC" by two decades. Only a few favored people got "chunks" of (night) time on Whirlwind for interactive use. In normal business hours it was run by dedicated operators, who fed it user-submitted code on punched paper tape. Turnaround time was often as short as an hour--including the development of microfilm, the main output medium. Hardware crashes were rare--much rarer than experience with vacuum-tube radios would lead one to expect--thanks to "marginal testing", in which voltages were ramped up and down once a day to smoke out failing tubes before they could affect real computing. My recollection is that crashes happened on a time scale of days, not minutes. "Clunky" would better describe the interface of the IBM 704, which displaced Whirlwind in about 1956. How backward the 60-year-old uppercase-only Hollerith card technology seemed, after the humane full Flexowriter font we had enjoyed on Whirlwind. But the 704 had the enormous advantages of native floating-point (almost all computing was floating-point in those days) and FORTRAN. (Damn those capital letters!) Doug

2 years, 2 months

Corbato dead

by Rich Salz

https://www.csail.mit.edu/news/fernando-corby-corbato-1926-2019. He invented time-sharing, passwords, and ran Project MAC.

2 years, 2 months

Senior moment

by Douglas McIlroy

Apologies for once again posting an item for the groff list to tuhs, re: "Any reason the removal/renaming of read-only registers should be permitted?" Doug

2 years, 2 months

Any reason the removal/renaming of read-only registers should be permitted?

by Douglas McIlroy

I think Clark was justified in deviating from Ossanna. The prime rationale for allowing removal of read-only registers is uniformity--a powerful argument. It simplifies documentation and relieves a burden on users' understanding. It probably simplifies the code, too. This kind of special-casing is AI in the service of some perception that "no one would want to do that.". If "that" is the clear meaning of some specified action, then so be it. We are not dealing with physical hazards here. > even if they don't screw up the formatter internally, > they will become unrecoverably useless for documents > and macro packages, The same argument could be made about \applying .rm to any standard request, and I would disagree for the same reason as above. (A disappointing experimental discovery in this regard: .de seems to be immune to removal.) A change that I *would* welcome is warning about writing into a read-only register. (Also make .rm work on .de--a near reversal of the original proposal.) Doug

2 years, 2 months

BSD question: Kurt Shoens, or Kurt Schoens?

by Steffen Nurpmeso

Hello. Even in these rusty times (oh what complicated chemical processes there are!) a question that i hope someone can answer. In both Spinellis' UNIX history repo as well as the CSRG one (via robohack/ucb-csrg-bsd.git) one can find two ways of writing Kurt Shoen's name, and whereas i, who always refer to Mail and its "usr.bin/mail/def.h" (aac48ec10b56f59b321fb033a36bca2114ef061b): [ Author: Kurt Shoens <kas> AuthorDate: 1980-10-08 08:53:34 -0800] + * Author: Kurt Shoens (UCB) March 25, 1978 one can find the name "Kurt Schoens" as early as 4.2 BSD (curses, twinkle1), and then in a growing number of files, especially after 1993 when Keith Bostic and then Kirk McKusick did admin/admin/contrib/address.list and admin/admin/contrib/contrib and share/man/man0/title.cdrom But one can also see the commit Author: Kurt A. Schoens <kas(a)ucbvax.Berkeley.EDU> AuthorDate: 1980-10-09 02:48:47 -0800 and that is strange, as i presume all-automatic version control conversions here? Schoens .. is a bug? Thank you. --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) |~~ |..and in spring, hear David Leonard sing.. | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure |~~ |Farewell, dear collar bear

2 years, 2 months

Revisiting 6th Edition: rxv64

by Dan Cross

I've mentioned tangentially this a few times, but over the weekend I finally got around to dusting off the code and getting it running: https://github.com/dancrossnyc/rxv64.git rxv64 is a rewrite of MIT's xv6, which in turn, reimagines 6th Edition as a purely pedagogical system, implemented in ISO C for 32-bit SMP x86 machines. Building on xv6, rxv64 is implemented in Rust and targets 64-bit x86_64. It works well enough to boot up, run a shell, and run commands, but it doesn't really have much of a userland at present. I started this as a pedagogical tool, being something that one could point working engineers at as an example of a "real" operating system implemented on real hardware in Rust. The code could surely be made safer and more comprehensible, but cycles are short at present, and it's better to just get it out there. Have fun. - Dan C.

2 years, 2 months

I have unsubscribed my original address from the list

by Gregg Levine

Hello! For some time now I've had both this address, and my original address which was on another service altogether subscribed to this list. And starting some time earlier, it would not show a full thread, it would show partial contents, the latest was the work by Dan Cross. In fact With that being last, ah, straw I decided to do that. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

2 years, 2 months

Re: UNIX "Machine Layer"

by Steve Simon

“soldering iron…” i do remember the fun of changing the baud rate of an async line on the Honeywell level 66 mainframe at college. This required shutting the whole machine down, removing one of the cards, and the (very careful) use of a wire wrap tool. -Steve

2 years, 2 months

UNIX Usage for Bell Telecom Typesetting

by segaloco

Good evening folks, I'm doing some research lately into the typesetting style apparent in the various UNIX System V guides I've scanned to archive.org. Their typesetting style is unlike that of the MM papers published with 3.0 and 4.0, but the contents seem to have continuity with the text in these collections. Well, in my searches sometimes telecom documents from the Bell System come up too and in materials from the 70s and 80s I started noticing that familiar typesetting in telecom stuff such as that hosted here https://www.telephonecollectors.info/index.php/browse/bsps-bell-system/bsp-… The earliest example I could find is 1969, so certainly at least a publication style that predates UNIX, but what I can't tell from my searches alone is if this style implies some non-UNIX typesetting system through and through or if there was a macro package dreamed up at some point between 1969 and 1982 that was in place by the time of the System V documentation. Just to detail specifics of the publication style, the commonalities I've found are the use of specifically bold numbers for page numbers, having the doc title and call number in the outer upper corner of pages, and just the fonts themselves look very similar. As an added note, the fonts used in the telecom documents and System V guidance documentation also resemble those in the copyright statement pasted on the cover of the extant PDF of the fifth edition UNIX manual. There is also some resemblance to the visual style observable in USG Program Generic and adjacent documentation (for instance the 1976 kernel description of PG 2 or the MERT 0 documents). This typesetting style is not seen in known research, CB, nor PWB until 5.0. Was there some separate typesetting system used in the broader System that, say, WECo may have taken up when they took over documentation between 3.0 and SVR2? - Matt G.

2 years, 2 months

S2-bits V2 Source Code Restoration

by segaloco

Hi folks, sharing another project that I've been tinkering on for a little bit since I like having a lot of irons in the fire: https://gitlab.com/segaloco/v2src After the link is a repository which over time will be accumulating the results of disassembly and analysis of files found in the s2-bits.tar.gz file in the archive. Details of my process are contained in the repository's readme. The short of it is I'm disassembling the binaries one by one, and where possible am comparing them with known sources to massage these into a pretty close restoration of the original sources. A few discoveries I've made in the process thus far: - These binaries appear to represent a version between the first and second editions. The binaries themselves are a mix of "naked" binaries as well as V1 and V2 a.out formats. Where it matters, things are much closer in character to V2 than V1. - All section 1 content that would be gone by V2 is removed here. Curiously, mount(1), type(1), and umount(1) which are in both V1 and V2 are absent from the s2-bits. - The sources marked "V2" in the UNIX source tree may be a bit closer in character to V3. Notable examples are that, while string references to /etc/uids remain, all data references have been updated to /etc/passwd, and several mathematical operations in the disassembled binaries map to KE-11 Extended Arithemtic Element registers where in the sources labeled "V2" in the tree have instead shifted to doing these calculations differently, presumably as these sources target the 11/45, not the 11/20. Additionally, the cat.s in "V2" on the tree contains the '-' stdin option, which was first documented in V3. The most likely story is that they're somewhere between, just like the s2-bits are between V1 and V2, but all of these observed differences thus far have aligned the sources with their descriptions in the third edition manual. Anywho, as usual, if anyone spots anything amiss or that could be done better, happy to accept contributions, or fork it and tinker away. Also, if anyone has already done this, speak up and tell me now so I don't double up on something so involved =P - Matt G.

2 years, 2 months

Re: UNIX "Machine Layer" Standards

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > something like a boot rom only became the norm in the late > 70's. Before that, one keyed in two dozen words with a tiny program to > load the first boot stage. A little wrong on that date. Even the PDP-11/20 (the first -11) had a boot ROM: https://gunkies.org/wiki/BM792_ROM which appreared in mid-1971 (about a year after the release of the /20). DEC sold them pre-programmed, but one could 'program' one onself, if one wanted - with a soldering iron! (Check out the image! I actually did that to one that I was given, that had been eviscerated by someone.) From then on (follow the category link), the rest used PROM chips. > From: Warner Losh > Oftentimes, the interrupt vector was in the lowest core addresses It's worth remembering that in the early period, that restriction to low addresses was built into the hardware (in an amusing way :-). Take the DL11: https://gunkies.org/wiki/DL11_asynchronous_serial_line_interface which was sort of mandatory as the 'console' serial interface on most early -11's (until the DL11-W appeared; more on its big improvement in a second). It set the interrupt vector with _jumpers_. (You want to change the interrupt vector? Dig out your soldering iron! :-) There were only 6 jumpers - one each for address bits 3 through 8. So the largest vector you could set was 0770. The DL11-W was a big step forward - it replaced the jumpers with a DIP switch! :-) Still only six bits, though. :-) Noel

2 years, 2 months

Re: UNIX "Machine Layer" Standards

by Paul Ruizendaal

Hi Matt, I’ve responded on list about the early unix development process as I understand it, but I want to avoid discussing things that are not directly related to the history of Unix. Hence this PM as well. > Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations. I have a similar interest, working with early Unix and modern RiscV hardware for a compare and contrast experience. - My development targets are (i) an FPGA based RV32 SoC implementation, (ii) a Sipeed D1 RV64GC board and shortly (iii) a Pine64 Pinetab-V. - My software targets are: (a) xv6-rv, (b) SysIII, (c) Linux, (d) experiments around SysIII Linux is for me a secondary target, just for comparison and to see if ideas are “Linux capable”. I’m not overly interested in Arm at the moment. My ideas are still evolving, but currently more or less along the below lines: - Boot rom loads SPL, this is custom in each case and set by the SoC's designers. - SPL initialises DRAM system and loads next stage. Unfortunately, this too would seem to be quite system specific, but the BSP should provide the baseline for this. As BSP’s are often a mess, milage may vary. - The next stage is a hybrid of BBL, OpenSBI and Virtio. The idea is to provide a standard abstraction layer that all of my software targets can work with. This idea is used for the FPGA target and allows booting a Linux kernel with just the generic Virtio device drivers (so far just disk and console). - The last layer is the classical OS layer. If I get it right, each OS can run on all h/w targets without customisation. At the moment I’m playing with USB, and how that might layer into the structure of V7, SysIII or 8th Edition -- and also the above.

2 years, 2 months

Re: UNIX "Machine Layer" Standards

by Paul Ruizendaal

> Date: Mon, 10 Apr 2023 18:27:51 +0000 > From: segaloco > ... or was there no single guiding principle and each machine came up, at that level at least, in a relative vacuum, with only the machine interface to UNIX being the guiding principle? I stumbled into the same question last year, when doing my SysIII to RV64 port. I managed to turn that into a somewhat chaotic discussion, mixing old and new, and history with ideas. From that chaotic discussion I got the impression that it was indeed mostly ad hoc. In context, hardware was much easier to boot and drive back then -- it probably was not seen as complex enough to warrant much research into layering and abstraction. Also bear in mind that something like a boot rom only became the norm in the late 70’s. Before that, one keyed in two dozen words with a tiny program to load the first boot stage. That said, there is an implicit layering in v7 and beyond: - “low.s" does hardware setup, incl. such stuff as setting up interrupt tables. As this is closely tied to the hardware, it would have been a custom job in each case. - “mch.s” (later also mch.c) has the basic routines that are hardware dependent (switching stacks, changing priority levels and modes, etc.). It also has emulation for ‘missing’ instructions, such as floating point ops where this is not available in hardware. Same as above, I think. Maybe h/w related memory protection operations should live here as well, but the hardware was still quite divergent in this area in the 70’s and early 80’s. - low-level device drivers live in the ‘dmr’ or (later) ‘io’ directory. Here there is some standardisation, as all device drivers must conform to the (char/block) device switch APIs. It seems to me that most of these drivers were written by taking one that was similar to what needed to be written and to start from there. Maybe this is still how it works in Linux today. - To the extent that there is such a thing as 'high-level device drivers’ in early Unix, the structure is less clearly visible. The file system (and there was only one at the time of v7) is placed between the block device switch and the mount table so to speak. This was structured enough that splicing in other file systems seems to have been fairly easy in the early 80’s (the splicing in, not the writing of the file system itself, of course). Starting with 8th edition, the ‘file system switch’ created a clear API for multiple file systems. Arguably, the ‘tty’ subsystem is also a ‘high-level device driver’, but this one lives as custom code together with the serial port device drivers. Also in 8th Edition, ‘streams' were introduced. One could think of this as a structured approach to high-level device drivers for character mode devices, incl. the ’tty’ subsystem. - I don’t think there was ever anything in early Unix that merged ’streams’ and the 'file system switch' into a single abstraction (but maybe 9P did?). > Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations. I have a similar interest, but to avoid the same chaos as I created before, I’ll respond to this with a pm.

2 years, 2 months

UNIX Manual Cover Art Origins?

by Douglas McIlroy

> Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals? The Bell Labs publication department at Whippany did the physical design for the bound versions of the Research Unix manual--from v7 as a trade brook through v10, also a trade book.. They did the cover designs for v8-v10 in house. I am not sure whether they did the v7 cover, farmed it out, or left it up to Holt Rinehart. Whippany handled the printing of v8 and v9. Saunders College Publishing did it for v10. Unfortunately, I do not remember whom I dealt with in Whippany, and my records of the interactions are long gone. Doug

2 years, 2 months

UNIX SVR2 User's Manual BTL Edition Additions and References

by segaloco

Good evening, I'd like to share a listing I've taken of the various extra pages present in the BTL version of the SVR2 User's Manual I picked up a little while ago. https://pastebin.com/18uTzyfS Like the Release 5.0 BTL version before it, many of the added pages are DIV 452 standard pages for Writer's Workbench as well as the Basic-16/BELLMAC-4/BELLMAC-8 development environments. To quote the preface: "This manual was designed through a cooperative effort of the BTL Computer Centers in Division 452. It represents a collection of nearly all the commands that are running on any Computer Center UNIX machine. ... The header of each manual page identifies the classification of the command along with any machine or site dependencies. ... Any page marked LOCAL indicates the sites that are running that command. ... Pages marked DIV 452 STD are from the collection of Computer Center standard commands, and are available on machines administered by Division 452 Computer Centers. The pages that are designated as INTERIM or 5.0 are those commands which are scheduled to be included in a separate WECo software add-on package." This manual is just sections 1 and 6, presumably 1m, 7, and 8 are in a corresponding administrator's manual and 2, 3, 4, 5 are in a programmer's manual, making SVR2 the start of the user's manual being further subdivided. I seem to recall one or the other of this same issue of manuals show up on eBay at some point, I'm kicking myself for not springing for it at the time, but hopefully one or the other (or both) turn up again to be documented someday. Additionally included in the above listing is a list of references from various "SEE ALSO" sections throughout the manual, as well as some other odds and ends from the text. Finally, there is a short listing of teach(1) classes as provided by a couple variants of the application. If any particular page piques an interest, let me know and I can scan it for you, otherwise this one is a ways away on my scan backlog. - Matt G.

2 years, 2 months

UNIX Manual Cover Art Origins?

by segaloco

Good day everyone, I'm in search of a bit of esoteric information regarding published UNIX works. Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals? Some that come to mind: The alphabet blocks cover of the HRW V7 Manuals The simple 70's Bell-style cover of the UNIX System III manual The nice 3B-20 picture on the UNIX 4.1 manual The grid patterns design on the UNIX System V documentation The blue "big V" SVR4 manuals (given the time disparity, these could have totally different underpinnings) Where I'm particularly curious is how these covers were actually set, defined, the image data to print on them stored, formatted, etc. In other words, <???>:troff::covers:manpages where ??? may also represent more than just the specific tools/formats. Anyone have the scoop on the actual raw materials and technologies used for preparing the covers and/or if any of those original assets, in their raw form, would potentially still exist somewhere? To be honest, I am particularly interested in the original, highest fidelity possible image of the 3B-20 from the corresponding manual (https://commons.wikimedia.org/wiki/Category:Unix_Manuals#/media/File:UNIX4.…) but am happy with any info illuminates what went into the actual physical production. Thanks all! - Matt G. P.S. If it provides any leads, the closest thing I've found in actual document sources to material related to these aspects of physical publication are the files M.folio and M.tabs here: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/tools

2 years, 2 months

Free books

by Rich Salz

I figure it won't cost me much more than $5 to ship domestically, which I'll pay for. International is more hassle so let's discuss. BSTJJuly-August 1978 ("the" issue) Elements of Programming Style 2nd Ed, Kernighan and Plauger The UNIX Programming Environment, Kernighan and Pike The C Programming Language 2nd Ed, Kernighan and Ritchie (includes printout of errata posted by dmr(a)alice.JUCP "5 Jun 89")

2 years, 2 months

UNIX "Machine Layer" Standards

by segaloco

Good day everyone. I'm taking a bit of a break from my documentation stuff and veering back towards some embedded systems work and have the burning question on my mind this morning: Was there any coordination between different groups engaged in porting efforts at Bell regarding machine layer implementations? In other words, was there any sort of common design of "get a stack pointer, do <XYZ> on the protection hardware, move the binary to address <ABC>, clear bss, etc." that was followed as lore when working up new machine bootstraps, or was that sort of work a bit more siloed? For instance, when working on the VAX port, was the crew more likely stepping through mch replicating things based on what the PDP-11 was doing, was the startup more derived from DEC literature, or was there no single guiding principle and each machine came up, at that level at least, in a relative vacuum, with only the machine interface to UNIX being the guiding principle? Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations. What I don't know is if I'm barking up the wrong tree and it was already settled in the 70s that machines are sufficiently different enough that you can't really just set forth one abstract "machine startup" design that actually includes all those CPU-level concerns such as protection, stack config, context switching, etc. I know even today peering into sources of stuff like Linux and seL4, the "ml" for each seems to have been built by a different person/group rather than someone setting out with a CPU bootstrap design and implementing the same on each chip. So boiled down to a one liner: Was there a guiding document/design/memoranda for the mch/ml components of UNIX in Bell, or was each one designed more "on-the-fly" as the particulars of the hardware were sorted out? - Matt G.

2 years, 3 months

Latest 2.9BSD and 2.11BSD

by Warner Losh

Greetings, What's the canonical source for patches to 2.9BSD and 2.11BSD? I see we have 2.11BSD patch 469 dated last month in the archive. Where does it come from? Has anybody climbed the hill to import all the patches into a git repo? I've found some mirrors, but moe.2bsd.org has been down for me for ages... How does Warren keep things up to date? I also have a (maybe faulty) memory of a similar series of patches to 2.9BSD because it was the last BSD to support non-split I&D space machines. yet a quick google search turns up nothing other than a set of patches dated August 1985 (also in our archive) and some changes for variants of hardware (pro, mscp). Is that it? Warner

2 years, 3 months

CWRU Univac artifacs

by Lars Brinkhoff

Hello, I received word from someone who went to Case Wester Reserve Univsersity, and is willing to send early 1970s ephemera to someone interested in going through it. The description is: "I've go stuff from my course work done on our Univac 1108/ChiOS system, program listing, cpu code cards, etc." Any takers? Best regards, Lars Brinkhoff

2 years, 3 months

Warren Toomey interviewed by Rik Farrow.

by Dan Cross

Enjoy this interview with our own wkt! https://www.usenix.org/publications/loginonline/interview-warren-toomey-fou…

2 years, 3 months

2.9BSD PUCC

by Henry Bent

Hello all, I am working on restoring the 2.9BSD PUCC distribution as provided on the CSRG CD/DVD set, hopefully as closely as possible to the original system. I am at a point where I have a setup that boots 95% of the way to multiuser but I have encountered some difficulties with the final few steps. I would appreciate it if anyone who is familiar with the login procedure could contact me off-list. -Henry

2 years, 3 months

administrivia: redirects from minnie?

by Royce Williams

I see that all the old minnie links: https://minnie.tuhs.org/pipermail/* ... break, and archived post are now at: https://www.tuhs.org/pipermail/* Could we get a courtesy redirect for pipermail/* ? -- Royce

2 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