- COFF - www.tuhs.org

Bell Labs vs "East Coast" Management style of AT&T

by steve jenkin

I was wondering if anyone close to Early Unix and Bell Labs would offer some comments on the evolution of Unix and the quality of decisions made by AT&T senior managers. Tom Wolfe did an interesting piece on Fairchild / Silicon Valley, where he highlights the difference between SV’s management style and the “East Coast” Management style. [ Around 2000, “Silicon Valley” changed from being ‘chips & hardware’ to ’software’ & systems ] [ with chip making, every new generation / technology step resets competition, monopolies can’t be maintained ] [ Microsoft showed that Software is the opposite. Vendor Lock-in & monopolies are common, even easy for aggressive players ] Noyce & Moore ran Fairchild Semiconductor, but Fairchild Camera & Instrument was ‘East Coast’ or “Old School” - extracting maximum profit. It seems to me, an outsider, that AT&T management saw how successful Unix was and decided they could apply their size, “marketing knowhow” and client lists to becoming a big player in Software & Hardware. This appears to be the reason for the 1984 divestiture. In another decade, they gave up and got out of Unix. Another decade on, AT&T had one of the Baby Bells, SBC, buy it. SBC had understood the future growth markets for telephony was “Mobile” and instead of “Traditional” Telco pricing, “What the market will bear” p[lus requiring Gross Margins over 90%, SBC adopted more of a Silicon Valley pricing approach - modest Gross Margins and high “pass through” rates - handing most/all cost reductions onto customers. If you’re in a Commodity market, passing on cost savings to customers is “Profit Maximising”. It isn’t because Commodity markets are highly competitive, but Volumes drive profit, and lower prices stimulate demand / Volumes. [ Price Elasticity of Demand ] Kenneth Flamm has written a lot on “Pass Through” in Silicon Chip manufacture. Just to close the loop, Bells Labs, around 1966, hired Fred Terman, ex-Dean of Stanford, to write a proposal for “Silicon Valley East”. The AT&T management were fully aware of California and perhaps it was a long term threat. How could they replicate in New Jersey the powerhouse of innovation that was happening in California? Many places in many countries looked at this and a few even tried. Apparently South Korea is the only attempt that did reasonably. I haven’t included links, but Gordon Bell, known for formulating a law of computer ‘classes’, did forecast early that MOS/CMOS chips would overtake Bipolar - used by Mainframes - in speed. It gave a way to use all those transistors on a chip that Moore’s Law would provide, and with CPU’s in a few, or one, chip, the price of systems would plummet. He forecast the cutover in 1985 and was right. The MIPS R2000 blazed past every other chip the year it was released. And of course, the folk at MIPS understood that building their own O/S, tools, libraries etc was a fool’s errand - they had Unix experience and ported a version. By 1991, IBM was almost the Last Man Standing of the original 1970’s “IBM & the BUNCH”, and their mainframe revenues collapsed. In 1991 and 1992, IBM racked up the largest corporate losses in US history to the time, then managed to survive. Linux has, in my mind, proven the original mid-1970’s position of CSRC/1127 that Software has to be ‘cheap’, even ‘free’ - because it’s a Commodity and can be ’substituted’ by others. ================================= 1956 - AT&T / IBM Consent decree: 'no computers, no software’ 1974 - CACM article, CSRC/1127 in Software Research, no commercial Software allowed 1984 - AT&T divested, doing commercial Software & Computers 1994 - AT&T Sells Unix 1996 - “Tri-vestiture", Bell Labs sold to Lucent, some staff to AT&T Research. 2005 - SBC buys AT&T, long-lines + 4 baby bells 1985 - MIPS R2000, x2 throughput at same clock speed. Faster than bipolar, CMOS CPU's soon overtook ECL ================================= Code Critic John Lions wrote the first, and perhaps only, literary criticism of Unix, sparking one of open source's first legal battles. Rachel Chalmers November 30, 1999 https://www.salon.com/test2/1999/11/30/lions_2/ "By the time the seventh edition system came out, the company had begun to worry more about the intellectual property issues and trade secrets and so forth," Ritchie explains. "There was somewhat of a struggle between us in the research group who saw the benefit in having the system readily available, and the Unix Support Group ... Even though in the 1970s Unix was not a commercial proposition, USG and the lawyers were cautious. At any rate, we in research lost the argument." This awkward situation lasted nearly 20 years. Even as USG became Unix System Laboratories (USL) and was half divested to Novell, which in turn sold it to the Santa Cruz Operation (SCO), Ritchie never lost hope that the Lions books could see the light of day. He leaned on company after company. "This was, after all, 25-plus-year-old material, but when they would ask their lawyers, they would say that they couldnt see any harm at first glance, but there was a sort of 'but you never know ...' attitude, and they never got the courage to go ahead," he explains. Finally, at SCO [ by July 1996 ], Ritchie hit paydirt. He already knew Mike Tilson, an SCO executive. With the help of his fellow Unix gurus Peter Salus and Berny Goodheart, Ritchie brought pressure to bear. "Mike himself drafted a 'grant of permission' letter," says Ritchie, "'to save the legal people from doing the work!'" Research, at last, had won. ================================= Tom Wolfe, Esquire, 1983, on Bob Noyce: The Tinkerings of Robert Noyce | Esquire | DECEMBER 1983.webarchive http://classic.esquire.com/the-tinkerings-of-robert-noyce/ ================================= Special Places IEEE Spectrum Magazine May 2000 Robert W. Lucky (Bob Lucky) https://web.archive.org/web/20030308074213/http://www.boblucky.com/reflect/… https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=803583 Why does place matter? Why does it matter where we live and work today when the world is so connected that we're never out of touch with people or information? The problem is, even if they get da Vinci, it won't work. There's just something special about Florence, and it doesn't travel. Just as in this century many places have tried to build their own Silicon Valley. While there have been some successes in Boston, Research Triangle Park, Austin, and Cambridge in the U.K., to name a few significant places, most attempts have paled in comparison to the Bay Area prototype. In the mid-1960s New Jersey brought in Fred Terman, the Dean at Stanford and architect of Silicon Valley, and commissioned him to start a Silicon Valley East. [ Terman reited from Stanford in 1965 ] ================================= -- 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

1 year, 8 months

3
2
0 0

October 2, 1991 - The Apple/IBM Alliance VHS discovered thanks to 512 byte C compiler

by Charles H Sauer (he/him)

https://www.youtube.com/watch?t=1&v=5HXLxtIfQhI backstory on how https://xorvoid.com/sectorc.html led to this rediscovery at https://notes.technologists.com/notes/2023/08/07/koko-keeping-warm/ Charlie -- voice: +1.512.784.7526 e-mail: sauer(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer

1 year, 8 months

1
0
0 0

1987 - Apollo Computer Inc Network Computing System VHS discovered thanks to 512 byte C compiler

by Charles H Sauer (he/him)

https://www.youtube.com/watch?v=WZBejHtLC-Y backstory on how https://xorvoid.com/sectorc.html led to this rediscovery at https://notes.technologists.com/notes/2023/08/07/koko-keeping-warm/ Charlie -- voice: +1.512.784.7526 e-mail: sauer(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer

1 year, 8 months

1
0
0 0

Re: [TUHS] Re: Unix game origins - stories similar to Crowther's Adventure

by Dan Cross

[TUHS to Bcc] On Wed, Feb 1, 2023 at 3:23 PM Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu> wrote: > > In the annals of UNIX gaming, have there ever been notable games that have operated as multiple processes, perhaps using formal IPC or even just pipes or shared files for communication between separate processes > > I don't know any Unix examples, but DTSS (Dartmouth Time Sharing > System) "communication files" were used for the purpose. For a fuller > story see https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf Interesting. This is now being discussed on the Multicians list (which had a DTSS emulator! Done for use by SIPB). Warren Montgomery discussed communication files under DTSS for precisely this kind of thing; apparently he had a chess program he may have run under them. Barry Margolin responded that he wrote a multiuser chat program using them on the DTSS system at Grumman. Margolin suggests a modern Unix-ish analogue may be pseudo-ttys, which came up here earlier (I responded pointing to your wonderful note linked above). > > This is probably a bit more Plan 9-ish than UNIX-ish > > So it was with communication files, which allowed IO system calls to > be handled in userland. Unfortunately, communication files were > complicated and turned out to be an evolutionary dead end. They had > had no ancestral connection to successors like pipes and Plan 9. > Equally unfortunately, 9P, the very foundation of Plan 9, seems to > have met the same fate. I wonder if there was an analogy to multiplexed files, which I admit to knowing very little about. A cursory glance at mpx(2) on 7th Edition at least suggests some surface similarities. - Dan C.

1 year, 8 months

2
1
0 0

Re: [TUHS] Re: Re: What Happened to Interdata?

by steve jenkin

Tom, it stands up very well, 1977 to 2023. > On 5 Aug 2023, at 13:46, Tom Lyon <pugs78(a)gmail.com> wrote: > > Here's my summer activity report on my work porting V6 code to the Interdata, working closely under Steve and Dennis. I left before the nasty bug was discovered. (I think). > https://akapugsblog.files.wordpress.com/2018/05/inter-unix_portability.pdf --

1 year, 9 months

1
0
0 0

What Happened to Interdata?

by segaloco

So I've been studying the Interdata 32-bit machines a bit more closely lately and I'm wondering if someone who was there at the time has the scoop on what happened to them. The Wikipedia article gives some good info on their history but not really anything about, say, failed follow-ons that tanked their market, significant reasons for avoidance, or anything like that. I also find myself wondering why Bell didn't do anything with the Interdata work after springboarding further portability efforts while several other little streams, even those unreleased like the S/370 and 8086 ports seemed to stick around internally for longer. Were Interdata machines problematic in some sort of way, or was it merely fate, with more popular minis from DEC simply spacing them out of the market? Part of my interest too comes from what influence the legacy of Interdata may have had on Perkin-Elmer, as I've worked with Perkin-Elmer analytical equipment several times in the chemistry-side of my career and am curious if I was ever operating some vague descendent of Interdata designs in the embedded controllers in say one of my mass specs back when. - Matt G. P.S. Looking for more general history hence COFF, but towards a more UNIXy end, if there's any sort of missing scoop on the life and times of the Bell Interdata 8/32 port, for instance, whether it ever saw literally any production use in the System or was only ever on the machines being used for the portability work, I'm sure that could benefit from a CC to TUHS if that history winds up in this thread.

1 year, 9 months

4
6
0 0

Inferno/Limbo Experiences

by segaloco

So as I was searching around for literature I came across someone selling a 2 volume set of Inferno manuals. I had never seen print manuals so decided to scoop them up, thinking they'd fit nicely with a 9front manual I just ordered too. That said, I hate to just grab a book for it to sit on my shelf, so I want to explore Inferno once I've got literature in hand. Does anyone here know the best way of VMing Inferno these days, if I can just expect to find a copy of distribution media somewhere that'll work in VirtualBox or QEMU or if there's some particular "path of righteousness" I need to follow to successfully land in an Inferno environment. Second, and I hope I don't spin up a debate with this, but is this something I'm investing good time in getting familiar with? I certainly don't hear as much about Inferno as I do about Plan9, but it does feel like it's one of the little puzzle pieces in this bigger picture of systems theory and development. Have there been any significant Inferno-adjacent developments or use cases in recent (past 10-15) years? - Matt G.

1 year, 9 months

2
1
0 0

Re: [TUHS] Re: the wheel of reincarnation goes sideways

by Dan Cross

I don't know if a thousand users ever logged in there at one time, but they do tend to have a lot of simultaneous logins. On Mon, Mar 13, 2023 at 6:16 PM Peter Pentchev <roam(a)ringlet.net> wrote: > > On Wed, Mar 08, 2023 at 02:52:43PM -0500, Dan Cross wrote: > > [bumping to COFF] > > > > On Wed, Mar 8, 2023 at 2:05 PM ron minnich <rminnich(a)gmail.com> wrote: > > > The wheel of reincarnation discussion got me to thinking: > [snip] > > > The evolution of platforms like laptops to becoming full distributed systems continues. > > > The wheel of reincarnation spins counter clockwise -- or sideways? > > > > About a year ago, I ran across an email written a decade or more prior > > on some mainframe mailing list where someone wrote something like, > > "wow! It just occurred to me that my Athlon machine is faster than the > > ES/3090-600J I used in 1989!" Some guy responded angrily, rising to > > the wounded honor of IBM, raving about how preposterous this was > > because the mainframe could handle a thousand users logged in at one > > time and there's no way this Linux box could ever do that. > [snip] > > For that matter, a > > thousand users probably _could_ telnet into the Athlon system. With > > telnet in line mode, it'd probably even be decently responsive. > > sdf.org (formerly sdf.lonestar.org) comes to mind... > > G'luck, > Peter > > -- > Peter Pentchev roam(a)ringlet.net roam(a)debian.org pp(a)storpool.com > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

1 year, 9 months

7
16
0 0

Typical Fate of Older Hardware

by segaloco

Howdy folks, I wanted to get some thoughts and experiences with regards to what sort of EOL handling of mainframe/mini hardware was typical. Part of this is to inform what and where to look for old hardware things. So the details may differ with era, but what I'm curious about is back in the day, when a mainframe or mini was essentially decommissioned, what was more likely to be done with the central unit, and peripherals if they weren't forward compatible with that user's new system. Were machines typically offloaded for money to smaller ops, or was it more common to simply dispose of/recycle components? As a more pointed example, if you worked in a shop that had IBM S/3x0, PDPs, larger 3B hardware, when those fell out of use, what was the protocol for getting rid of it? Were most machines "disposed of" in a complete way, or was it very typical to parts it out first, meaning most machines that reached EOL simply don't exist anymore, they weren't moved as a unit, rather, they're any number of independent parts floating around anywhere from individual collections to slowly decaying in a landfill somewhere. My fear is that the latter was more common, as that's what I've seen in my lab days; old instrumentation wasn't just auctioned off or otherwise gotten rid of complete, we'd typically parts the things out resulting in a chassis and some of the paneling going in one waste stream, unsalvageable parts like burnt out boards going in another, and anything reusable like ribbon cables and controller boards being stashed to replace parts on their siblings in the lab. I dunno if this is apples to oranges though because the main instruments I'm thinking of, the HP/Agilent 5890, 6890, and 7890 series, had different lifespan expectations than computing systems had, and share a lot more of the under the hood components like solenoids and gas tubing systems, so that may not be a good comparison, just the closest one I have from my own personal experience. Thoughts? - Matt G.

1 year, 9 months

7
14
0 0

Re: What Happened to Interdata?

by jnc＠mercury.lcs.mit.edu

> From: Greg 'groggy' Lehey > Interdata had instruction sets that were close to the IBM instruction > set, but my recollection was that they were different enough that IBM > software wouldn't run on them. Bitsavers doesn't have a wealth of Interdata documentation, but there is some: http://bitsavers.org/pdf/interdata/32bit/ Someone who's familiar with the 360 instruction set should be able to look at e.g.: http://bitsavers.org/pdf/interdata/32bit/8-32/8-32_Brochure_1977.pdf and see how compatible it is. Noel

1 year, 9 months

3
3
0 0

Wanted: 16-bit big-endian Unix-like environment and/or libc

by Warren Toomey

Hi all, I'm looking for a 16-bit big-endian Unix-like development environment with a reasonably new C compiler and a symbolic debugger. And/or, a libc with source code suitable for a 16-bit big-endian environment. Rationale: I've designed and built a 6809 single board computer (SBC) with 8K ROM, 2K I/O space for a UART and block storage, and 56K RAM. It's a big-endian platform and the C compiler has 16-bit ints by default. I've been able to take the filesystem code from XV6 and get it to fit into the ROM with a hundred bytes spare. The available Unix-like system calls are: dup, read, write, close, fstat, link, unlink, open, mkdir, chdir, exit, spawn and the spawn is like exec(). There is no fork() and no multitasking. I've got many of the existing XV6 userland programs to run along with a small shell that can do basic redirection. Now I'm trying to bring up a libc on the platform. I'm currently trying the libc from FUZIX but I'm not wedded to it, so alternative libc recommendations are most welcome. There's no debugging environment on this SBC. I do have a simulator that matches the hardware, but I can only breakpoint at addresses and single-step instructions. It makes debugging pretty tedious! So I was thinking of using an existing Unix-like platform to bring up the libc. That way, if there are bugs, I can use an existing symbolic debugger on the platform. I could use 2.11BSD as the dev platform but it's little-endian; I'm worried that there might be endian issues that stop me finding bugs that will arise on the 16-bit 6809 platform. As for which libc: I looked at the 2.11BSD libc/include and there's so much stuff I don't need (networking etc.) that it's hard to winnow down to just what I need. The FUZIX libc looks good. I just came across Elks and that might be a possible alternative. Are there others to consider? Anyway, thanks in advance for your suggestions. Cheers, Warren References: XV6: https://github.com/mit-pdos/xv6-public FUXIZ: https://github.com/EtchedPixels/FUZIX/tree/master/Library Elks: https://github.com/jbruchon/elks/tree/master/libc

1 year, 9 months

2
1
0 0

Seeking Some Books (Primarily Standards)

by segaloco

Good afternoon or whichever time of day you find yourself in. I come to you today in my search for some non-UNIX materials for a change. The following have been on my search list lately in no particular priority: - Standards: COBOL 68 C 89 C++ 98 Minimal BASIC 78 Full BASIC 87 SQL (any rev) IS0 9660 (CD FS, any rev) ISO 5807 (Flow Charts, any rev) - Manuals: PDP-11/20 Processor Handbook (EAE manual too if it's separate) WE32000 and family literature GE/Honeywell mainframe and G(E)COS documents The IBM 704 FORTRAN Manual (The -original- FORTRAN book) The Codasyl COBOL Report (The -original- COBOL book) Any Interdata 7 or 8/32 documentation (or other Interdata stuff really) The Ti TMS9918 manual The Philips "Red Book" CDDA standard If it's part of one, the Bell System Practices Issue containing, or separately otherwise, BSP 502-503-101 (2500 and 2554 reference) If any of these are burning a hole in your bookshelf and you'd like to sell them off, just let me know, I'll take em off your hands and make it worth your while. I'm not hurting for any of them, but rather, I see an opportunity to get things on my shelf that may facilitate expansion of some of my existing projects in new directions in the coming years. Also, I'm in full understanding of the rarity of some of these materials and would like to stress my interest in quality reference material. Of course, that's not to dismiss legitimate valuation, rather, simply to inform that I intend to turn no profit from these materials, and wherever they wind up after their (hopefully very long) tenure in my library will likely have happened via donation. - Matt G. P.S. On that last note, does anyone know if a CHM registration of an artifact[1] means they truly have a physical object in a physical archive somewhere? That's one of the sorts of things I intend to look into in however many decades fate gives me til I need to start thinking about it. [1] - https://www.computerhistory.org/collections/catalog/102721523

1 year, 9 months

2
1
0 0

Re: Seeking Some Books (Primarily Standards)

by jnc＠mercury.lcs.mit.edu

> From: Matt G. > PDP-11/20 Processor Handbook > (EAE manual too if it's separate) Yes and no. There are separate manuals for the EAE (links here: https://gunkies.org/wiki/KE11-A_Extended_Arithmetic_Element https://gunkies.org/wiki/KE11-B_Extended_Arithmetic_Element the -B is the same to program as the -A; its implementation is just a single board, though) but the -11/20 processor handbook (the second version; the one dated 1972) does have a chapter (Chapter 8; Part I) on the EAE. (For no reason I can understand, neither the -11/05 nor the -11/04 processor handbook covers the EAE, even though neither one has the EIS, and if you need multiply/etc in hardware on either one, the EAE is your only choice). Noel

1 year, 9 months

1
0
0 0

Requesting thoughts on extended regular expressions in grep.

by Grant Taylor

Hi, I'd like some thoughts ~> input on extended regular expressions used with grep, specifically GNU grep -e / egrep. What are the pros / cons to creating extended regular expressions like the following: ^\w{3} vs: ^(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) Or: [ :[:digit:]]{11} vs: ( 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|27|28|29|30|31) (0|1|2)[[:digit:]]:(0|1|2|3|4|5)[[:digit:]]:(0|1|2|3|4|5)[[:digit:]] I'm currently eliding the 61st (60) second, the 32nd day, and dealing with February having fewer days for simplicity. For matching patterns like the following in log files? Mar 2 03:23:38 I'm working on organically training logcheck to match known good log entries. So I'm *DEEP* in the bowels of extended regular expressions (GNU egrep) that runs over all logs hourly. As such, I'm interested in making sure that my REs are both efficient and accurate or at least not WILDLY badly structured. The pedantic part of me wants to avoid wildcard type matches (\w), even if they are bounded (\w{3}), unless it truly is for unpredictable text. I'd appreciate any feedback and recommendations from people who have been using and / or optimizing (extended) regular expressions for longer than I have been using them. Thank you for your time and input. -- Grant. . . . unix || die

1 year, 9 months

11
45
0 0

Butler Lampson's 1973 Xerox PARC memo "Why Alto?"

by steve jenkin

What struck me reading this is the estimated price (~$10K) to build an Alto, elsewhere I’ve seen $12K and 80 built in the first run. [ a note elsewhere says $4,000 on 128KB of RAM. 4k-bit or 16-kbit chips? unsure ] I believe the first "PDP-11” bought by 127 at Bell Labs was ~$65k fully configured (Doug M could confirm or not), although the disk drive took some time to come. Later, that model was called PDP-11/20. Why the price difference? PARC was doing DIY - it’s parts only, not a commercial production run with wages, space, tooling & R+D costs and marketing/sales to be amortised, with a 80%+ Gross Margin required, as per DEC. Why didn’t Bell Labs build their own “Personal Computer” like PARC? They had the need, the vision, the knowledge & expertise. I’d suggest three reasons: - The Consent Decree. AT&T couldn’t get into the Computer Market, only able to build computers for internal use. They didn’t need GUI PC’s to run telephone exchanges. - Bell Labs management: they’d been burned by MULTICS and, rightly, refused the CSRC a PDP-10 in 1969. - Nobody ’needed’ to save money building another DIY low-performance device. A home-grown supercomputer maybe :) It’s an accident of history that PARC could’ve, but didn’t, port Unix to the Alto in 1974. By V7 in 1978, my guess it was too late because both sides had locked in ‘commercial’ positions and for PARC to rewrite code wasn’t justified: “If it ain’t Broke”… Porting Unix before 1974 was possible: PARC are sure to have had close contact with UC Berkeley and the hardware/software groups there. Then 10 years later both Apple and Microsoft re-invent Graphical computing using commodity VLSI cpu’s. Which was exactly the technology innovation path planned by Alan Kay in 1970: build today what’ll be cheap hardware in 10 years and figure out how to use it. Ironic that in 1994 there was the big Apple v Microsoft lawsuit over GUI’s & who owned what I.P. Xerox woke up up midway through and filed their own infringement suit, and lost. [ dismissed because approx they'd waited too long ] <https://en.wikipedia.org/wiki/Apple_Computer,_Inc._v._Microsoft_Corp.> ============== PDF: <http://bwl-website.s3-website.us-east-2.amazonaws.com/38a-WhyAlto/Acrobat.p…> Other formats: <http://bwl-website.s3-website.us-east-2.amazonaws.com/38a-WhyAlto/Abstract.…> ============== -- 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

1 year, 9 months

3
2
0 0

Re: Butler Lampson's 1973 Xerox PARC memo "Why Alto?"

by jnc＠mercury.lcs.mit.edu

> From: steve jenkin > What struck me reading this is the estimated price (~$10K) to build an > .. [ a note elsewhere says $4,000 on 128KB of RAM. 4k-bit or 16-kbit > chips? unsure ] 16K (4116) - at least, in the Alto II I have images of. Maxc used 1103's (1K), but they were a few years before the Alto. > I believe the first "PDP-11" bought by 127 at Bell Labs was ~$65k fully > configured I got out my August 1971 -11/20 price sheet, and that sounds about right. The machine had "24K bytes of core memory .. and a disk with 1K blocks (512K bytes ... a single .5 MB disk .. every few hours' work by the typists meant pushing out more information onto DECtape, because of the very small disk." ("The Evolution of the Unix Time-sharing System"): 11,450 Basic machine CPU + 8KB memory 6,000 16KB memory (maybe 7,000, if MM11-F) 4,000 TC11 DECtape controller 4,700 TU56 DECtape transport 5,000 RF11 controller 9,000 RS11 drive 3,900 PC11 paper tape ------- 44,050 (Although Bell probably got a discount?) The machine later had an RK03: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u0.s but that wasn't there initially (they are 2.4MB, larger than the stated disk); it cost 5,900 (RK11 controller) + 9,000 (RK03 drive). Also, no signs of the KE11-A in the V1 code (1,900 when it eventually appeared). The machine had extra serial lines (on DC11's), but they weren't much; 750 per line. > Why the price difference? Memory was part of it. The -11/20 used core; $9,000 for the memory alone. Also, the machine was a generation older, the first DEC machine built out of IC's - all SSI. (It wasn't micro-coded; rather, a state machine. Cheap PROM and SRAM didn't exist yet.) Noel

1 year, 9 months

1
0
0 0

Bell System and the Video Game Industry?

by segaloco

So this evening I've been tinkering with a WECo 2500 I've been using for playing with telecom stuff, admiring the quality of the DTMF module, and it got me thinking, gee, this same craftsmanship would make for some very nice arcade buttons, which then further had me pondering on the breadth of the Bell System's capabilities and the unique needs of the video game industry in the early 80s. In many respects, the combination of Western Electric and Bell Laboratories could've been a hotbed of video game console and software development, what with WECo's capability to produce hardware such as coin slots, buttons, wiring harnesses for all sorts of equipment, etc. and then of course the software prowess of the Labs. Was there to anyone here's knowledge any serious consideration of this market by Bell? The famous story of UNIX's origins includes Space Travel, and from the very first manual, games of various kinds have accompanied UNIX wherever it goes. It seems that out of most companies, the Bell System would've been very well poised, what with their own CPU architecture and other fab operations, manufacturing and distribution chains, and so on. There's a looooot of R&D that companies such as Atari and Nintendo had to engage in that the Bell System had years if not decades of expertise in. Would anti-trust stuff have come into play in that regard? Bell couldn't compete in the computer market, and I suppose it would depend on the legal definitions applicable to video game hardware and software at the time. In any case, undercurrent here is the 2500 is a fine telephone, if the same minds behind some of this WECo hardware had gone into video gaming, I wonder how different things would've turned out. - Matt G.

1 year, 9 months

3
3
0 0

Advice sought: what to eventually do with my 1977 Lions Commentary?

by steve jenkin

I’ve no intention of selling these items and am definitely NOT disposing of them yet. No ‘offers’ please. In 1977, I took John’s “Operating Systems” course, and was one of 60-80 students who bought the first print run of the Commentary. I’m looking for suggestions of what to do with these three items pictured, some ideas of what to put in my will or donate before I go. Warren doesn’t need Yet Another Copy, he has some better copies already :) They aren’t in pristine condition and I made notes in both books, in pencil at least. The cover of the red book has slightly deteriorated. steve j PS: if the image is stripped by the list, a copy at: <http://members.tip.net.au/~sjenkin/SteveJ_Lions-Commentary.jpg> -- 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

1 year, 10 months

1
0
0 0

IBM SLT Module Identity?

by segaloco

Hello, today I have received an IBM binder from 1974 pertaining to IBM Skylab activities as well as a small IBM SLT, single wide, with four modules on it. Two of the modules are labeled: 361456 IBM WF 1 03S 215 And the other two are: 361453 IBM 22 1-009 415 From what I could find online, there is a close SLT card with 4 of the 361453's instead of 2, but that doesn't help much. That board is listed as 00211 in the reference this info is from[1]. Faintly on the connector I can make out: 00008 A 0 204 YM It is very, very faint in places though so that may not be correct. The specific little blocks on the board appear to show up on others, so nothing unheard of, although I wouldn't know where to start on identifying what this does precisely, all I can find are cursory references in a few places to the numbers on the chips re: SLT modules. - Matt G. [1] - https://ibm-slt-reference.fandom.com/wiki/SLT_Board_List (why is this a fandom.com wiki...) P.S. If you or a loved one are in possession of IBM mainframe hardware that would benefit from this SLT board, happy to send it to you, I probably won't do much with it unless I can figure out the pinout and do weird things over GPIO pins from one of my single boards.

1 year, 10 months

1
0
0 0

A slack clone in 5 lines of bash

by Edouard Klein

Dear Old Farts, I've written a chat system that relies at its core on UNIX's permission system. All the explanations are here: https://the-dam.org/docs/explanations/suc.html I thought it would be of interest to the list as it has one foot in the past (using system primitives from the 70's for access control) and one foot in the future: (optionally) using GNU Guix's declarative configuration to create the necessary users, groups, and files. I know most of you have used (and some maybe still do) talk et al. This system is even simpler, just a forever loop: while /usr/bin/true do read -r line || exit 0 # EOF /usr/bin/echo "$(/usr/bin/date --iso-8601=seconds)"\ "$(printf "%-9s" "$(/usr/bin/id --user --name --real)")" \ "$line" >> /var/lib/suc/"$1" done I'd be happy to hear any comments or to welcome you on the Dam, where we test this stuff. Cheers ! Edouard.

1 year, 10 months

1
0
0 0

Re: Esix SVR4

by William Corcoran

Hi Emanuel, I believe I may have the install disks for ESIX, SVR4. It actually was distributed in this beautiful box with over 100 5.25” floppy disks. As things progressed, ESIX was distributed on a streaming tape cartridge. That was so much faster than swapping floppy disks for the install. The nice thing about the ESIX SVR4 was the documentation. It was essentially the AT&T SVR4 books with a white ESIX cover slapped on it. If you want to copy the disks and make them accessible to our UNIX community, let me know. Since it’s part of my collection I would ask that you return them to me. Send me an email directly if you’re interested and I will see if I can locate them for you. Bill Corcoran > On Jun 11, 2023, at 8:47 AM, emanuel stiebler <emu(a)e-bbes.com> wrote: > Hi, > anybody still has the install media for that? > We used it in the office long ago, but I lost the install disk in my last moving :( > > THANKS!

1 year, 10 months

2
2
0 0

Shell script advice: using 'dd' to write multiple media

by steve jenkin

Apropos the ESIX SVR4 distro on floppies or streaming tape mentioned by Bill Corcoran <https://www.tuhs.org/mailman3/hyperkitty/list/coff@tuhs.org/message/WEJQQCJ…> In the mid 1980’s I worked for a small Australian outfit that did “Unix”. One of the things we did was distributing software, which required writing to many media. There was a very clever script that broke the distribution into many parts, if needed, to suit the size of the distribution media. [ tape, 3.5” floppy, 2.5” floppy, etc ] Over the years I’ve tried to recreate a version and not succeeded :( There was a ‘create the distro’ step of the pipeline which gathered the input, followed by a loop that used ‘dd’ to block the stream into media-sized parts. I’ve never figured out how to use ‘dd’ so it returns after a single block is written doesn’t close the input, killing the pipeline, or cause the rest of the data to be discarded. The script let our admin staff reliably create distros on whatever media was requested. Any suggestions or hints? I’m thinking this is obvious, but in the man pages i’ve read, not found an answer. It could be modern versions of ‘dd’ don’t have this behaviour. cheers steve -- 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

1 year, 10 months

9
14
0 0

Marketplaces for Vintage Tech Books, Etc.?

by segaloco

Good afternoon folks, I just wanted to ask if anyone is aware of online marketplaces I should be looking at in my constant scouring for historical documentation materials? Presently I've got a policy of checking eBay and Biblio pretty regularly for UNIX material, occasionally searching for a few other odds and ends subject-wise, but I'm starting to wonder if there are other avenues flying under my radar where folks might be more likely to be selling for instance 70s and 80s UNIX manuals, paper copies of old standards, hardware docs from IBM and DEC, etc. If you have any suggestions, especially those that don't require me to setup yet another account to keep track of, I'd surely appreciate it. Also consider this my way of saying if you have something to sell, I'll gladly consider it, although I am being pretty selective on matters of historical/research significance that are currently obscure, so sorry if I won't buy your twelfth copy of KnR C, even if it is signed! - Matt G.

1 year, 10 months

3
3
0 0

WECo/Bell Branded Computer Hardware

by segaloco

Hello, I've got a question I'm puzzling on that someone here may have some info on. Are there any known lists/promo material/price sheets from between 80-83 regarding WECo computing hardware such as the 3B20D and 3B20S? More broadly, is it documented at all what hardware models made it out before the removal of the Bell logo and transition from WECo to AT&T ownership of the 3B and related technologies? Aside from the cover illustration of a 3B20S on the UNIX 4.1 manual and having seen a MAC-Tutor on eBay once, I can't say I've seen any other WECo branded computation hardware with Bell logos. The only photos I can find of a 3B20D are a later AT&T branded issue. Any leads? Would it have just been BellMAC stuff and 3B20 systems before the change in logo? Based on the manual I recently received, the 3B5 may have also made it out during the WECo period but after dropping the Bell logo, somewhere between the consent degree being produced and the completion of divesting WECo. - Matt G. P.S. In the bigger picture, I'm slowly starting to aggregate info together on Bell/WECo's computer hardware activities tangential to but distinct from UNIX developments. Stuff like the 3B computers, BellMAC stuff, etc. If there's already a community/resources in this focused area I'd happily divert those efforts to a more focused collective.

1 year, 10 months

1
0
0 0

White Backgrounds on GUIs after Dark Backgrounds on Terminals?

by segaloco

Good afternoon everyone. I've been thinking about the color/contrast landscape of computing today and have a bit of a nebulous quandary that I wonder if anyone would have some insight on. So terminals, they started as typewriters with extra steps, a white piece of paper on a reel being stamped with dark ink to provide feedback from the machine. When video terminals hit the market, the display was a black screen with white, orange, green, or whatever other color of phosphor they bothered to smear on the surface of the tube. Presumably this display style was chosen as on a CRT, you're only lighting phosphor where there is actually an image, unlike the LCD screens of today. So there was a complete contrast shift from dark letters on white paper to light letters on an otherwise unlit pane of glass. Step forward to graphical systems and windows on the Alto? Light background with dark text. Windows on the Macintosh? Light background with dark text. Windows on MS Windows? Light backgrounds with dark text. Default HTML rendering in browsers? Light backgrounds with dark text. Fast forward to today, and it seems that dark themes are all the rage, light characters on an otherwise dark background. This would've made so much sense during the CRT era as every part of the screen representing a black pixel is getting no drawing, but when CRTs were king, the predominant visual style was dark on light, like a piece of paper, rather than light on dark, like a video terminal. Now in the day and age of LCDs, where every pixel is on regardless, now we're finally flipping the script and putting light characters on dark backgrounds, long after any hardware benefit (that I'm aware of) would be attained by minimizing the amount of "lit surface" on the screen. Anyone know if this has all been coincidental or if the decision for graphical user interfaces and such to predominantly use white/light colors for backgrounds was a relatively intentional measure around the industry? Or is it really just that that's how Xerox's system looked and it was all domino effect after that? At the end of the day I'm really just finding myself puzzling why computing jumped into the minimalism seen on terminal screens, keeping from driving CRTs super hard but then when GUIs first started appearing, they didn't just organically align with what was the most efficient for a CRT. I recognize this is based largely in subjective views of how something should look too, so not really expecting a "Person XYZ authoritatively decided on <date> that GUI elements shall overwhelmingly only be dark on light", just some thoughts on how we got going down this path with color schemes in computing. Thanks all! - Matt G.

1 year, 10 months

6
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF