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
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
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.
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
> 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.
> >>
> >>
>
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.
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
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”?
I’ve been playing around trying to link the OpenSolaris launch commit to various pieces in the Unix History Repository, and it’s making me wonder if we’ll ever have a chance to see the history of the systems.
I’m less concerned about HPUX, AIX and SCO’s offerings since I presume someone has copy inside these companies. But what about A/UX, Irix, Tru64? Did these ever get sold with licenses to source tapes? Are there copies we need to preserve in-camera so something can exist 120 years after creation or whenever copyright expires?
--
Joseph Holsten
http://josephholsten.com
mailto:joseph@josephholsten.com
tel:+1-360-927-7234