TUHS

tuhs@tuhs.org

6 participants
6532 discussions

by Steve Simon

hi all, maybe of interest, in the early 1990s i worked at UNSW and met several people in the computer science dept who knew John Lions. i *was* the character on the cover of the reprint, i have a photocopy of the original pamphlet, complete with hand written annotations by someone who attended Lyons course. perhaps everyone on tuhs has their own photocopy, but if anyone wants this one, give me a shout. -Steve

1 year, 9 months

Lions' commentary updated

by Greg 'groggy' Lehey

No, sorry, there hasn't been a new edition, just corrections. The original version contained a number of scan errors, and thanks to Conway Yee I have now applied a number of corrections. You can find the document in various forms at http://www.lemis.com/grog/Documentation/Lions/. I've scanned through the output, and it seems correct. If you find any further errors, please let me know. Also thanks to Brian Foley, who sent me similar corrections 10 years ago, but which I never got round to incorporating. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php

1 year, 9 months

Re: 7th ed local man pages

by jnc＠mercury.lcs.mit.edu

> From: Douglas McIlroy > The union table of man pages in "A Research Unix Reader', CSTR 139, > marks with "L" local man pages that were not distributed outside of > research. Does anyone have a copy of those pages? ... would love to get > them all The CB-UNIX manual has a bunch of xL "Local" pages, e.g. the Section 3 ones here: https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man3/ I know this is CB-UNIX, but perhaps they are the same? Noel

1 year, 9 months

7th ed local man pages

by Douglas McIlroy

The union table of man pages in "A Research Unix Reader', CSTR 139, marks with "L" local man pages that were not distributed outside of research. Does anyone have a copy of those pages? I'm particularly interested in galloc(3), but would love to get them all, which I unwittingly trashed when I retired. Doug

1 year, 9 months

Re: custom NS and NE man(7) macros

by Douglas McIlroy

> You didn't say, but I reckon this is a survey of man(7) macros that > might be considered extensions? My presentation was too cute for my own good. I pointed out the consistency of xS/xE for various x. I apologized for EX/EE, which varied from that form (as UR/UE did more recently), and I questioned OQ/CQ, which utterly breaks it. The intended point was that one should have a strong rationale for deviating from established custom, and thereby fostering mental overload. Doug

1 year, 9 months

Re: UNIX Influence on Teletype and Vice Versa

by Douglas McIlroy

I omitted one crucial fact from my post about Joe Ossanna's influence on the TTY 37. That happened not in connection with Unix, but with Multics. When Unix came on the scene, model 37 was already in production. Doug

1 year, 9 months

Project Idea: The UNIX Programmer's Manual: Heritage Edition

by segaloco

I haven't known when or how to bring up this project idea, but figure I might as well start putting feelers out since my Dragon Quest project is starting to slow down and I might focus back on UNIX manual stuff. So something painfully missing from my and I'm sure plenty of other folks' libraries is a nice, modern paper UNIX manual that takes the past few decades into consideration. The GNU project, BSDs, etc. ship manpages of course, and there's the POSIX manpages, but I'm a sucker for a good print manual. Something I'm thinking of producing as a "deliverable" of sorts from my documentation research is a new-age UNIX manual, derived as closely as possible from the formal UNIX documentation lineages (so Research, SysV, and BSD pages), but: 1. Including subsequent POSIX requirements 2. Including an informational section in each page with a little history and some notes about current implementations, if applicable. This would include notes about "dead on the vine" stuff like things plucked from the CB-UNIX, MERT/PG, and PWB lines. The history part could even be a separate book, that way the manual itself could stay tight and focused. This would also be a good place for luminaries to provide reflections on their involvement in given pieces. One of the main questions that I have in mind is what the legal landscape of producing such a thing would entail. At the very least, to actually call it a UNIX Programmer's Manual, it would probably need to pass some sort of compliance with the materials The Open Group publishes. That said, the ownership of the IP as opposed to the trademarks is a little less certain, so I would be a bit curious who all would be involved in specifically getting copyright approval to publish anything that happened the commercial line after the early 80s, so like new text produced after 1982. I presume anything covered by the Caldera license at least could be published at-cost, but not for a profit (which I'm not looking for anyway.) Additionally, if possible, I'd love to run down some authorship information and make sure folks who wrote stuff up over time are properly credited, if not on each page ala OWNER at least in a Acknowledgements section in the front. As far as production, I personally would want to do a run with a couple of different cover styles, comb bound, maybe one echoing the original Bell Laboratories UNIX User's Manual-style cover complete with Bell logo, another using the original USENIX Beastie cover, etc. but that also then calls into question more copyrights to coordinate, especially with the way the Bell logo is currently owned, that could get complicated. Anywho, anyone know of any such efforts like this? If I actually got such a project going in earnest, would folks find themselves interested in such a publication? In any case I do intend to start on a typesetter sources version of this project sometime in the next year or so, but ideally I would want it to blossom into something that could result in some physical media. This idea isn't even half-baked yet by the way, so just know I don't have a roadmap in place, it's just something I see being a cool potential project over the coming years. - Matt G.

1 year, 9 months

shell escapes in utilities

by ron minnich

I got to wondering, based on the sendmail discussions, how many shell escapes have appeared over the years? uucp sendmail xdvi : "The "allowShell" option enables the shell escape in PostScript specials" There must be a lot of them, however.

1 year, 9 months

CRC calculation in the 1980s

by Paul Ruizendaal

When looking at old xmodem code I noticed that it calculated its CRC bit-by-bit, switching to byte-wise using a table in the late 80’s. It never seems to have used the byte-wise, “on-the-fly” algorithm. This seems to match a pattern: I often come across bit-wise and table implementations, but rarely on-the-fly implementations if any. The on-the-fly algorithm was known at least since 1983, following a paper by Perez: http://www.bitsavers.org/components/fairchild/_appNotes/Byte-wise_CRC_Jun83… The paper was noted, for example it is on the citation list of RFC1134, describing the PPP protocol. Today, a wikipedia page gives implementations for various polynomials: https://en.wikipedia.org/wiki/Computation_of_cyclic_redundancy_checks#Paral… Now, it would seem to me that on memory constrained personal computers and PDP-11’s the “on-the-fly” algorithm would have been a good choice, being just a few lines of code and maybe 30-50% slower than table lookup. The tables aren’t big, but a kilobyte is a lot when you only have 64. Any suggestions as to why the on-the-fly algorithm did not catch on more in the 1980’s? Maybe it was simply less well known than I think?

1 year, 9 months

Re: CRC calculation in the 1980s

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > Any suggestions as to why the on-the-fly algorithm did not catch on > more in the 1980's? Maybe it was simply less well known than I think? I can't answer that directly, but I will point you at IEN-56, "CRC Checksum Calculation", by Dave Reed (11-Sep-78): https://www.rfc-editor.org/ien/ien56.pdf Dave wanted the INWG to use a more powerful (in terms of detecting errors) CRC, instead of the simple summation eventually adopted, in TCP and IP. So he produced code to implement a particular CRC, to show people that it would not be particularly expensive (whether in time, or space, I don't alas recall definitively; speed would have been an important consideration, when competing with the summation, though). This would have been close to the leading edge of our knowledge at the time; Dave liked playing around with math, and at about that time he did a very fast DES implementation. Noel

1 year, 9 months

UNIX 4.0 Typesetter Docs on eBay

by segaloco

Howdy all, just passing along this auction I spotted on eBay: https://www.ebay.com/itm/256216372208 This is a subset of papers from the Documents for UNIX 4.0 set compiled as a handy volume (and likely a forerunner to the packaged volumes released with System V.) Missing is the Typing Documents with MM pamphlet which is listed in the TOC of these issues. I've already got one of these or I'd scoop it up myself. Enjoy! - Matt G. P.S. I have seen this and its companion document (Programming Starter Package) with the AT&T deathstar in the upper right rather than Bell Labs and the Bell logo. What I don't know is if it's an exact repackaging just with a change in logo or if those versions have revisions to any of the papers. Most notably as far as version association, the Programming Starter Package includes the Documentation Roadmap, which in my Bell Labs-branded copy, indicates it is for use with UNIX 4.0. I'd be curious if the AT&T variant retains the UNIX 4.0 reference. I'll continue to keep my eye out for an AT&T-branded set, it might reveal some differences.

1 year, 9 months

CRC calculation in the 1980s

by Paul Ruizendaal

>> Any suggestions as to why the on-the-fly algorithm did not catch on more in the 1980’s? Maybe it was simply less well known than I think? > > Could it have been the per-cpu-second billing that was (fairly?) common at the time. I was only getting in to Unix in the early 90s but saw the tail end of that. Good point, but wasn’t per-cpu-second billing mostly used for big iron? For machines without memory constraint the table method makes the most sense, also if billing was not a factor. >> Any suggestions as to why the on-the-fly algorithm did not catch on more in the 1980’s? Maybe it was simply less well known than I think? > > The CRC algorithm I'm familiar with shows up in Dragon Quest for the Famicom in 1986[1], written in 6502 assembly. Admittedly though I only recognized it due to the EOR with 0x1021 on lines 318-323. That I then only know from a quick and dirty CRC I threw in an XMODEM-CRC client [2] I did to accommodate for a bug in the JH7100 RISC-V board's recovery ROM implementation. Not sure if this is along the lines of the approach you're talking about ... > > [1] - https://gitlab.com/segaloco/dq1disasm/-/blob/master/src/chr3/start_pw.s > [2] - https://gitlab.com/segaloco/riscv-bits/-/blob/master/util/sxj.c Both of these are what I call the bit-wise method: a loop iterating over bytes, with an inner loop iterating over bits. An example of the table method is here: https://github.com/u-boot/u-boot/blob/master/lib/crc16-ccitt.c and an example of the on-the-fly method is here: https://github.com/tio/tio/blob/master/src/xymodem.c#L44-L54 Note how the latter also only has one loop iterating over the bytes, but effectively calculates the table entry ‘on the fly’ for each byte. That is only a handful of instructions more than doing the table lookup. Maybe it is a “stuck in the middle” solution that was quickly forgotten.

1 year, 9 months

x/y/zmodem on Unix

by Paul Ruizendaal

Last december Matt brought up xmodem and recently I needed it for an almost identical use case. Studied it a bit and in the context of Unix, it is an interesting piece of software history. Although xmodem originated on CP/M in 1977, it seems to have arrived on Unix soon thereafter. The first Unix implementation seems to have gone by the name of “rbsb” and must have originated when V7 was prevalent: it uses alarm() to simulate non-blocking I/O. Over the course of the 80’s ymodem and zmodem were added and the package became lrzsz; the source continued to have a very V7-ish feel to it at least to the early 90’s. In the mid-90’s it was converted to ansi-C and had some other modernization, but it looks like it would still have run on SysIII (apart from the ansi).The last update to the upstream source package appears to be from 1998, i.e. 25 years ago. It is still packaged today for FreeBSD and major Linux distros. On Unix it must be one the oldest code bases still in regular use, with the 1980 source still recognizable in its current incarnation. Any other contenders come to mind? I had always associated x/y/zmodem with CP/M and MSDOS, not so much with Unix. Last December Clem already pointed out that it was popular for file exchange in the Unix scene as well, along with several other similar tools. Also, the ymodem approach to file metadata is very unix oriented, suggesting it originated on Unix or at least that Unix users were an important user demographic. Yet, I could find little trace of x/y/zmodem in the TUHS Unix Tree. The search tool finds it in 2.11BSD, in Minix 1.5 and 2.0 and in V10. Kermit is in those as well, and in 4.3BSD and 4.4BSD on top. Maybe these programs were commonly pulled from a bulletin board and hence not on distribution media. Not sure how that would be bootstrapped, although the 2.11BSD files for x/y/zmodem include “minirb.c”, a 175 line implementation to receive files using the ymodem protocol. It is possible that this was transferred as plain text as a first step, or even retyped. Any recollections?

1 year, 9 months

Re: UNIX Influence on Teletype and Vice Versa

by Douglas McIlroy

Joe Ossanna worked diligently to see that WECo's ASCII teletype really would come to market and would meet the needs of Unix. He famously estimated that Bell Labs alone was a sizable market: 777 machines. He also leaned on WECo to make the return key issue a single newline. And he specified what non-ascii characters would fill out the 128 positions on the Bell Labs type boxes. This requires encoding 7-bit ASCII in 8 bits. I don't know whether WECo had been planning to do so anyway. Doug

1 year, 9 months

UNIX Influence on Teletype and Vice Versa

by segaloco

Good morning folks, something I've been pondering on this morning is the potential close connection between UNIX development and Teletype interfacing designs as the 70s and 80s marched on. Seeing as Teletype was a part of the Bell System (albeit a little less obviously in marketing than it's kin), was there any sort of official rapport between folks working on UNIX and those designing subsequent Teletypes, Dataspeed terminals, etc? For instance, would there have been any influence an up-and-coming Teletype design would've had on developments in the UNIX tty drivers, or would particulars of UNIX tty drivers "rub off" on specifics of terminals being developed? Or were those units so distant from one another that there would've been little cross-talk between teams? Granted, an argument could be made for specifically avoiding any significant knowledge of internals, that way UNIX tty driver folks don't potentially paint into a Teletype corner and vice versa. Still, with the tightly integrated nature of Bell System R&D, manufacturing, supply, etc. it would be very "Bell System" for there to be some sort of interplay between Teletype and UNIX. Anyone got the scoop on whether Teletype hardware enjoyed a special place in UNIX tty-interfacing considerations or vice versa, or if they were just two relatively insular developments from one another in the same general field from the same big umbrella organization? - Matt G.

1 year, 9 months

Re: TUHS

by Will Senn

All, My apologies to you for sending a note to the entire list that was meant to be sent only to Warren. I definitely had not intended to send it to the entire list (reply list... ugh.). If I were to get a mulligan, I would make it clear that I do not take issue with anyone's signature, including Mary Ann's. Signatures, in my view, are a matter of free speech. I would simply state my preference that we keep the discussion to a more technical level and consider moving cultural topics to another list altogether. Thanks, Will

1 year, 9 months

Re: The AWK Programming Language, 2nd Ed.: What's new?

by arnold＠skeeve.com

Hello All. For whoever's interested, the csv code has been merged into the master branch of the Git repo. Have fun! Arnold > From: arnold at skeeve.com (arnold at skeeve.com) > Date: Sun, 10 Sep 2023 13:41:34 -0600 > Subject: [TUHS] The AWK Programming Language, 2nd Ed.: What's new? > > Hi. > > markus schnalke <meillo at marmaro.de> wrote: > > > Hoi, > > > > I just discovered that one of my favorite computer books about my > > best liked programming language (besides C) releases in a second > > edition. Does anyone know what the differences of 1st and 2nd > > edition are? > > > > As the original book is almost perfect, the only rework and > > extension direction I can think of is towards different > > implementations like gawk, mawk, portability and such things. > > > > Does anyone know more about it? Maybe some inside information? ;-) > > > > meillo > > Inside information? As it happens, yes, I do have some. :-) > (I was a reviewer.) > > [In the below, "awk" means Brian Kernighan's awk.] > > In the 36 (!) years since the first edition was published, awk > has undergone, shall we say, a large number of small changes. These > are listed in the FIXES file currently in the master branch of > https://github.com/onetrueawk/awk. > > In addition, Brian Kernighan decided to add support for UTF-8 input, > which is what awk now expects, and support for CSV input files when > invoked with the --csv option. Furthermore, there is a new \u escape > sequence which must be followed by 1-8 hexadecimal digits for specifying > Unicode code points. > > The book itself has been carefully revised. The large second chapter > which was a reference to the full language was moved to an appendix. > Many of the example programs from the first edition were retained > and updated, but there is also quite of lot of pleasing new material. > > There is mention of, and occasional comparison with, gawk, mawk and > Ben Hoyt's GoAwk, but by and large the focus is on the authors' version. > > The new code is currently in the "csv" branch of the above Github > repo. The maintainer is in the process of tidying up the repo (dealing > with issues and pull requests) and will merge the csv branch into > master sometime in the very near future. > > I'm told that the printed books with get to the publisher's warehouse > towards the end of September. The book is available now on O'Reilly's > Safari learning site (safari.oreilly.com) for anyone who has a > subscription. > > Matching code (--csv and \u) are in gawk's master branch now. I will > make a release this fall, after the new code has moved into master > in BWK's awk. > > I heartily recommend the book; it is totally up to Brian Kernighan's > usual very high standard. > > Enjoy, > > Arnold >

1 year, 9 months

Re: The AWK Programming Language, 2nd Ed.: What's new?

by norman＠oclsc.org

To the Attention of Warren Toomey (and all who stay in his hotel): I don't care enough to weigh in on any issues that don't interest me, but I am the most important person in the world, and whatever I say goes, so you better listen or you'll be sorry. It is my very important opinion that only things I want to hear about should be discussed on this mailing list. I want to hear about Unix and awk, but not about perl. No one must talk about any shell except Ken's original. The sun scares me, forcing me to hack all night and sleep all day (never mind the malicious stories that I press wild flowers); therefore there must never be any mention of Sun Microsystems or Solaris. I am also worried that a comet will fall on my house and damage my Twinkie stockpile, so no discussion of the VAX-11/750 is allowed, nor of work done by the Bell Labs Computing Science Research Center during the 1980s when much of their work was done on systems of that model, which were even named (ewwwww!!!) after comets. Any mention of non-nerd-approved(TM) subjects is also forbidden, including Agricola, ferrets, mimes (which are even scarier than comets!), Lions (and Tigers and Bears), lurgi, csv files, and gannets (they wet their nests). Not to mention Bazonka. I hereby direct the moderators of this list, who must obey my every command, to terminate with extreme prejudice anyone who dares even to think of violating these rules. Viva la revolution! Yeliz Gardinovich Bimmler (Mrs) Port Morton, Alabama, CUS

1 year, 9 months

TUHS

by Will Senn

Hi Warren, I don't care to weigh in on the transgender flag issue, but I also don't want to hear about it. Please remove me from the list. All due respect to you and Mary Ann. Monica Helms is not a Unix hero. Thanks, Will

1 year, 9 months

Some BSP Numbers Related to 3B/1A "Attached Processor Interface"

by segaloco

Hello, today I've received a 3B/1A "Attached Processor Interface" or "API" (as I will refer to it in this email, note API will not mean Application Programming Interface in my contributions to this discussion) pamphlet, published by WECo in November 1981, concerning installation and maintenance of the API. From the introductory page: > This lesson is a self-paced package that can be administered individually or in a classroom environment. There is a helpful glossary in the back of this booklet that you may use while going through the material. > > At the conclusion of this lesson, the installer will be able to: > > - State the purpose of the API as it applies to the 3B Processor. > > - Identify the different types of circuit packs used in the API. > > - List the number of API diagnostic phases. > > - Name the API circuit pack that interfaces the Dual Serial Channel in the 3B Processor. Among the many pages (which I'll be doing a formal scan on in the future) are some references to BSPs and schematic drawings relevant to this information, I wanted to get that information out in the email archive now so the bibliographic references are preserved somewhere: 3B Processor: 254-001-031 - Test Equipment List 254-301-000 - System Documentation 254-301-005 - General Description 254-301-115 - TTY System 254-301-010 - Central Control 254-301-020 - Power Systems 254-301-100 - Input Output Interfaces 254-301-105 - Input Output Processor 254-301-110 - Input Output Processor Peripheral Controller 254-301-200 - Main Store 254-301-210 - Moving Head Disk Drive 254-301-215 - Disk File Controller 254-301-220 - Magnetic Tape System 254-301-800 - Emergency Action Procedures 254-301-809 - Acceptance Test Plan 254-301-811 - Task Oriented Practice-Routine 254-301-812 - Task Oriented Practice-Trouble Clearing 254-341-000 - DMERT 254-341-220 - MTCE Management and Diagnostics API: 234-100-020 - APS Description and Theory 254-201-003 - API Frame Theory 254-280-114 - APS Software Description 254-281-030 - API Growth Misc: 234-153-055 - File Store Relocation 3B Schematics: SD-4C050-01 - 3B Control Frame, DMA Unit, CC Unit, MASM 0, MASM 1, Power Unit, Cooling Unit, Filter Unit SD-4C059-02 - 3B Peripheral Control Frame SD-4C052-01 - IOP Basic SD-4C049-01 - IOP Growth SD-4C051-01 - DFC Unit SD-4C056-01 - Disk Inverter Frame SD-4C058-01 - Tape Transport Frame SD-4C057-01 - Inverter Unit SD-4C070-02 - Inverter Control Unit SD-4C054-01 - Duct & Cabling SD-4C053-01 - Power Distributing, AC Requirements SD-4C069-01 - Micro Level Test Set SD-4C065-01 - Port Switch API Schematics: SD-5A056-01 - API Frame SD-5A055-01 - API Unit There are then references to a few "Handbooks": HB 309 - 3B Proc HB 263(A) - API ITS (Mainly mentions tests and diagnostic stuff) HB 264(A) - API Generic (Not sure what ITS and Generic distinguish here) Finally, a bit of fun. Towards the back of the pamphlet is a small crossword puzzle concerning the API: https://i.imgur.com/0pLcK9p.jpg Answers to come when I do a scan of this. If anyone has any particular information they want me to try and find in it sooner rather than later just let me know, it's 88 pages but small form. - Matt G.

1 year, 9 months

Unix install & "standalone" package

by norman＠oclsc.org

I don't remember any special many-programs-in-one binary like busybox in any Unix from the days when Unix was simple enough for me to understand. That covers the entire lifetime of the Research systems, but also System V and the BSDs and their sundry offspring up into at least the 1990s. I'm pretty sure OpenBSD at least still has nothing like busybox. The nearest thing was to make sure certain programs were linked statically (or existed in alternate statically- linked versions) so they would work before shared libraries were available. (It seems to be common wisdom that `sbin' means `system bin' these days, but I remember once, long ago, being told it stood for `static bin'.) Perhaps the question to ask is why such a magic program is needed at all. Is it just because programs like the shell have become so large and unwieldy that they won't fit in a small environment suitable for loading into an initramfs? Older UNIXes, even on the VAX, didn't use an initramfs. the boot code had just enough understanding of devices and file systems to load the kernel and to point it at the real root file system. The VAX hardware designers had a clever scheme on many (but, strangely, not all) VAX variants by which the hardware had several little boot ROMs, each containing a bare-bones read-only device driver for a particular device along with a few instructions to read the first sector into memory and start it, with pointers to the boot-rom driver and device ID in specified registers. That was enough to support a device-independent Unix boot block that could read unix (or another file name typed on the console) from the root of the file system at the start of the disk. I know it was because I wrote such a boot block, though I don't know whether anyone else did. (Other systems, I think, just used it to load /boot, a larger and more-capable program.) Maybe it was just that the boot environment was simpler in older systems, without the need to load kernel modules or support multiple locations and means of access for the root? Norman Wilson Toronto ON

1 year, 9 months

Re: nassau smelting was Re: Current Ownership of 3B/WECo Computer IPs

by Douglas McIlroy

> i’m having trouble identifying “Agricola”. See WIkipedia on "De re metallica", or for the real thing https://www.gutenberg.org/files/38015/38015-h/38015-h.htm On Mon, Sep 11, 2023 at 4:29 PM Mark Seiden <mis(a)seiden.com> wrote: > > i’m so happy you replied. > > have you considered a memoir? > > your writing is very vivid (and literate). > > but i’m having trouble identifying “Agricola”. > > the strategy board game? the roman emperor? the farm to table restaurant in princeton? > > > > > > > > On Sep 11, 2023, at 3:58 PM, Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu> wrote: > > > > Way off topic, but too nostalgic to pass up. I was involved in > > after-hours training courses and persuaded Bob Morris to organize the > > first one ever to be held off campus, "Bell System with field trips". > > The highlight of the series was Nassau Smelting and Refining. They > > proudly told us about their new environmental consciousness: aqua > > regia (used to reclaim gold) was now being adjusted to pH 7 before > > being dumped into the Kill van Kull, and stack emissions of lead had > > been reduced from hundreds of pounds per year to eight. > > > > The scene was almost straight out of Agricola. An enormous steel > > jousting pole mounted on a backhoe was used to shove scrap copper and > > live-cut tree trunks into a ferocious green-flaming furnace. Men in > > moon suits and respirators puddled slag floating on open vats of > > molten lead. A Dickensian crone snipped gold tips off the old relays > > cradled in her lap. Clothes, including shoes, exchanged at the door of > > the gloomy gold room, were collected periodically and thrown into the > > aqua regia pots to extract every last milligram. > > > > The only process that really deviated from Agricola was pyrolysis, for > > reclaiming modern cable cladding. But he surely would have been > > impressed by the mechanism for casting continuous copper bar and > > collecting it on a giant spool. They delighted in telling about the > > time the spool stopped turning while the copper feed continued, > > filling the hall with an enormous tangle of 1" copper stock. > > > > Doug > > > > > > On Mon, Sep 11, 2023 at 1:47 PM Mark Seiden <mis(a)seiden.com> wrote: > >> > >> hi, old friends (and i mean that both figuratively and literally) > >> > >> the recent/continuing brouhaha involving lead sheathed cables made me wonder about > >> nassau smelting and refining in staten island (a sub of WEco which ended up with Lucent) > >> (and apparently another location at W. 29th st which was a superfund site for a while.) > >> > >> wonderful chaplainesque photo: > >> > >> https://www.facebook.com/classicstatenisland/photos/a.286586221935407/51668… > >> > >> also regarding the Staten Island location, quoting from > >> > >> https://www.silive.com/news/2020/02/former-nassau-smelting-site-sells-for-3… > >> > >> "The cleanup was to entail covering 450,000 cubic yards of contaminated soil with a thick, unbreakable plastic liner, as well as layers of clean soil.” > >> > >> (hah, what could go wrong with that?) > >> > >> On Sep 11, 2023, at 11:34 AM, Paul Winalski <paul.winalski(a)gmail.com> wrote: > >> > >> Regarding the possible Western Electric -> Lucent -> Nokia IP path, > >> has anyone tried contacting Nokia's legal department and asking > >> whether they think they own the rights to the 3B/WECo computer IP, and > >> if not, do they know who does (or might) own it? > >> > >> -Paul W. > >> > >> >

1 year, 9 months

Current Ownership of 3B/WECo Computer IPs

by segaloco

Hello folks, I'm here today with a question that sprung off of some 3B20 research. When 1984 happened and ATTIS rose from the ashes of former Bell System computing efforts, presumably ATTIS received all IP rights from Western Electric for 3B processors, WE32000, and so on, and continued to sell related products through to the 3B2 line. Is this the case, is ATTIS the formal recipient of both computing software *and* hardware IPs after the breakup? Given that, plus subsequent market flow, "old AT&T" scooped up and paraded around in effigy by SBC, other old Bell stuff cannibalized by other RBOCs, spinoffs of stuff to Novell, then Caldera/SCO on the other side...who all wound up with the hardware IPs? The story as it "concludes" concerning UNIX is of course tied up in all the subsequent lawsuits, what with Novell and Caldera conflicts on ownership, transfer to the Open Group, so on and so forth, and SCO and progeny wind up with the Sys V "trunk." Is there a clear, current owner of these WECo hardware IPs, or have those waters grown even murkier than those of UNIX in the times after AT&T proper? Thanks everyone! - Matt G. P.S. As an aside (even though it's the more directly UNIX thing...) is anything after SVR4 developments that would've involved the same folks as were working up to that point in the USL group? Or did the transfer of System V to Novell also involve their own in house folks starting to take it over, then over to SCO, is there anything post SVR4 (4.2, 5, UnixWare stuff) that would even remotely be considered the logical next step by the same folks that engineered SVR4, or was it basically just another face in the crowd of "UNIX <xyz>" when USL wasn't involved anymore? Probably not the first time this has been asked either so to a finer point I'm basically fishing for whether anything post the initial SVR4 releases in the early 90s is generally considered "pure" in any way or if the Bell streams pretty much terminate with Research V10 and SVR4, (and IX) at the turn of the 90s.

1 year, 9 months

The AWK Programming Language, 2nd Ed.: What's new?

by markus schnalke

Hoi, I just discovered that one of my favorite computer books about my best liked programming language (besides C) releases in a second edition. Does anyone know what the differences of 1st and 2nd edition are? As the original book is almost perfect, the only rework and extension direction I can think of is towards different implementations like gawk, mawk, portability and such things. Does anyone know more about it? Maybe some inside information? ;-) meillo

1 year, 9 months

Unix install & "standalone" package

by Paul Ruizendaal

Recently, I was looking into the “Das U-Boot” boot loader package. Summarised with great simplification, u-boot bundles device drivers, file systems, commands and a Bourne-like shell into a standalone package. Normally it auto-runs a script that brings up a system, but when used in interactive mode it allows a great deal of poking around. It made me think of the “standalone” set of programs for installing early Unix. On 16-bit understandably each basic command has to be a separate standalone program, but after the shift to 32-bit bundling more functionality in a single binary would have become possible. How did the Unix “standalone” package evolve in the 80’s, both in the research and BSD lineages? Is there any retrospective paper about that? Or is it a case of “Use the source, Luke”?

1 year, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS