TUHS

tuhs@tuhs.org

12 participants
6534 discussions

Re: [TUHS] Failing Memory of an Algol Based System from years ago

by Nelson H. F. Beebe

The posting of the link http://bitsavers.org/pdf/regnecentralen/RC_4000_Reference_Manual_Jun69.pdf brought back old memories. When I moved to Aarhus University in Denmark in December 1973, I found that the Department of Chemistry where I worked had a Regnecentralen RC-4000 minicomputer with paper tape input that was used to manage the department's accounting. It had a dedicated operator who kept in running nicely until at least after I left in 1977. It had too little physical memory to be considered practical for the quantum chemistry work that I was then engaged in, and may not even have had a Fortran compiler; instead, we used the campus CDC 6400 for our research. In memory of the RC-4000, and Per Brinch Hansen's (13 Nov 1938--31-Jul-2007) many contributions to the literature of computer science, programming language design, and parallel computing, I prepared an enhancement of its manual, available here: http://www.math.utah.edu/~beebe/RC-4000/ The Web page that comes up gives a directory of the available files, and documents the steps needed to produce them. The result is a searchable document, with a single page image per PDF page, rather than the mixed bitmap scan of 1-up and 2-up pages in the original PDF file. Despite my 40+ year engagement in the TeX community, I only recently learned via the texhax mailing of some PDFTeX internals that allow one to construct a file that can retypeset n-up files into 1-up format. I therefore make this posting in the hope that someone else might be encouraged to tackle similar document improvements in the bitsavers archives. Although it takes a bit of experimentation, with the exception of the OCR conversion, the entire operation can be done with free software on pretty much any modern computing platform, thanks to the portability of the needed software. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

6 years, 4 months

Failing Memory of an Algol Based System from years ago

by Rudi Blom

>Date: Sat, 9 Mar 2019 15:29:11 -0700 >From: "Nelson H. F. Beebe" <beebe(a)math.utah.edu> >To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> >Subject: Re: [TUHS] Failing Memory of an Algol Based System from years ago >Message-ID: <CMM.0.95.0.1552170551.beebe(a)gamma.math.utah.edu> ... snip ... > http://www.math.utah.edu/~beebe/RC-4000/ > >The Web page that comes up gives a directory of the available files, >and documents the steps needed to produce them. The result is a >searchable document, with a single page image per PDF page, rather >than the mixed bitmap scan of 1-up and 2-up pages in the original PDF >file. >Despite my 40+ year engagement in the TeX community, I only recently >learned via the texhax mailing of some PDFTeX internals that allow one >to construct a file that can retypeset n-up files into 1-up format. > >I therefore make this posting in the hope that someone else might be >encouraged to tackle similar document improvements in the bitsavers. >archives. Although it takes a bit of experimentation, with the >exception of the OCR conversion, the entire operation can be done with >free software on pretty much any modern computing platform, thanks to >the portability of the needed software. A bit off topic (sorry) but wondering about that PDF conversion. This may be a dumb question but did you ever try the PDF conversion in calibre ( https://calibre-ebook.com )? I like the PDF to htmlz conversion even if mostly the result still needs (a lot of) extra work. Cheers, uncle rubl

6 years, 4 months

Re: [TUHS] Failing Memory of an Algol Based System from years ago

by Doug McIlroy

Clem, I think the "Algol machine" you have in mind is the RC-2000 (not quite sure of the designation--could look it up in the attic if it matters) designed by Per Brinch Hansen for Regencentralen (again, the name may not be quite right). The manual used Algol as a hardware description language. The instruction set was not unusual. It has come up before in TUHS. I have the manual if you need more info. Doug

6 years, 4 months

sticky tapes

by Steve Simon

i have worked in tv, developing systems for archive restoration for many years. if you have valuable sticky tapes i suggest you try and contact a lical video archivist, there are other tricks than just baking that can help - old tapes can present complex problems. <story> there was a sticky valuable rolling stones 24 track master tape i heard of. it was sent for analysis, and they discovered the stickiness was “vodka and coke” :-). </story> -Steve

6 years, 4 months

more/BSD

by Kevin Bowling

I have a hungry hp300. Does anyone have Mt Xinu's creation, more/BSD, archived? Regards, Kevin

6 years, 4 months

1983 UBC PDP-11 Unix tools distribution

by Al Kossow

Today's tape recovery gem. UBC's PDP-11 UNIX tools distribution ca. 1983 which includes UBC BASIC and their RT-11 emulation. It has a couple of bad blocks, but I couldn't find another copy of this anywhere. http://bitsavers.org/bits/UBC/ If anyone has a complete copy, it would be good to replace it, but most is better than none of it.

6 years, 4 months

"Women" topic moved to COFF

by Warren Toomey

All, I've locked the "Women in Computing" topic in the TUHS list as it's not specifically Unix and liable to be contentious. Feel free to continue it over on the COFF list. E-mail me if you'd like to join the COFF list. Cheers, Warren

6 years, 4 months

Re: [TUHS] Women in computing

by jnc＠mercury.lcs.mit.edu

> From: Deborah Scherrer > In the early days of Usenix, I used to keep track of the women. > Initially, about 30% of the organization was female. That dropped every > year. Interesting. Any ideas/thoughts on what was going on, what caused that? Noel

6 years, 4 months

Women in computing

by John P. Linderman

https://www.nytimes.com/2019/02/13/magazine/women-coding-computer-programmi…

6 years, 4 months

"Re: [groff] modernize -T ascii rendering of opening single quote"

by Doug McIlroy

Unless my leg is being pulled, I sent that for pure amusement. Gcc has a very open mind on the subject, using both options in the same sentence. ----------------------------------------------------------- > Doug wrote: > > A diagnostic from gcc chimes in: > > 'mktemp' is deprecated: the use of `mktemp' is dangerous; use `mkstemp' ... > https://www.gnu.org/prep/standards/standards.html#Quote-Characters My impression was Doug was passing on a warning about the continued used of mktemp(3) rather than the continued use of ASCII.

6 years, 4 months

Re: [TUHS] OSI stack (Was: Posters)

by jnc＠mercury.lcs.mit.edu

> From: Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> > Seeing as how this is diverging from TUHS, I'd encourage replies to > the COFF copy that I'm CCing. Can people _please_ pick either one list _or_ the other to reply to, so those on both will stop getting two copies of every message? My mailbox is exploding! Noel

6 years, 5 months

Re: [TUHS] OSI stack (Was: Posters)

by jnc＠mercury.lcs.mit.edu

> On Wed, Feb 06, 2019 at 10:16:24AM -0700, Warner Losh wrote: > In many ways, it was a classic second system effect because they were > trying to fix everything they thought was wrong with TCP/IP at the time I'm not sure this part is accurate: the two efforts were contemporaneous; and my impression was they were trying to design the next step in networking, based on _their own_ analysis of what was needed. > without really, truly knowing the differences between actual problems > and mere annoyances and how to properly weight the severity of the issue > in coming up with their solutions. This is I think true, but then again, TCP/IP fell into some of those holes too: fragmentation for one (although the issue there was unforseen problems in doing it, not so much in it not being a real issue), all the 'unused' fields in the IP and TCP headers for things that never got really got used/implemented (Type of Service, Urgent, etc). ` Noel

6 years, 5 months

Re: [TUHS] OSI stack (Was: Posters)

by jnc＠mercury.lcs.mit.edu

> From: Kevin Bowling > t just doesn't mesh with what I understand Ah, sorry, I misunderstood your point. Anyway, this is getting a little far afield for TUHS, so at some point it would be better to move to the 'internet-history' list if you want to explore it in depth. But a few more... > Is it fair to say most of the non-gov systems were UNIX during the next > handful of years? I assume you mean 'systems running TCP/IP'? If so, I really don't know, because for a while during that approximate period one saw many internets which weren't connected to the Internet. (Which is why the capitalization is important, the ill-educated morons at the AP, etc notwithstanding.) I have no good overall sense of that community, just anecdotal (plural is not 'data'). For the ones which _were_ connected to the Internet, then prior to the advent of the DNS, inspection of the host table file(s) would give a census. After that, I'm not sure - I seem to recall someone did some work on a census of Internet machines, but I forget who/were. If you meant 'systems in general' or 'systems with networking of some sort', alas I have even less of an idea! :-) Noel

6 years, 5 months

Re: [TUHS] OSI stack (Was: Posters)

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > TCP/IP was the first wide spread networking stack that you could get > from a pile of different vendors, Sun, Dec, SGI, IBM's AIX, every kernel > supported it. Well, not quite - X.25 was also available on just about everything. TCP/IP's big advantage over X.25 was that it worked well with LAN's, whereas X.25 was pretty specific to WAN's. Although the wide range of TCP/IP implementations available, as well as the multi-vendor support, and its not being tied to any one vendor, was a big help. (Remember, I said the "_principle_ reason for TCP/IP's success" [emphasis added] was the size of the community - other factors, such as these, did play a role.) The wide range of implementations was in part a result of DARPA's early switch-over - every machine out there that was connected to the early Internet (in the 80s) had to get a TCP/IP, and DARPA paid for a lot of them (e.g. the BBN one for VAX Unix that Berkeley took on). The TOPS-20 one came from that source, a whole bunch of others (many now extinct, but...). MIT did one for MS-DOS as soon as the IBM PC came out (1981), and that spun off to a business (FTP Software) that was quite successful for a while (Windows 95 was, IIRC, the first uSloth product with TCP/IP built in). Etc, etc. Noel

6 years, 5 months

Re: [TUHS] OSI stack (Was: Posters)

by jnc＠mercury.lcs.mit.edu

> From: Kevin Bowling > Seems like a case of winners write the history books. Hey, I'm just trying to pass on my best understanding as I saw it at the time, and in retrospect. If you're not interested, I'm happy to stop. > There were corporate and public access networks long before TCP was set > in stone as a dominant protocol. Sure, there were lots of alternatives (BITNET, HEPNET, SPAN, CSNET, along with commercial systems like TYMNET and TELENET, along with a host of others whose names now escape me). And that's just the US; Europe had an alphabet soup of its own. But _very_ early on (1 Jan 1983), DARPA made all their fundees (which included all the top CS departments across the US) convert to TCP/IP. (NCP was turned off on the ARPANET,and everyone was forced to switch over, or get off the network.) A couple of other things went for TCP/IP too (e.g. NSF's super-computer network). A Federal ad hoc inter-departmental committee called the FRICC moved others (e.g. NASA and DoE) in the direction of TCP/IP, too. That's what created the large user community that eventually drove all the others out of business. (Metcalfe's Law.) Noel

6 years, 5 months

Re: [TUHS] OSI stack (Was: Posters)

by jnc＠mercury.lcs.mit.edu

> From: Kevin Bowling > I think TCP was a success because of BSD/UNIX rather than its own > merits. Nope. The principle reason for TCP/IP's success was that it got there first, and established a user community first. That advantage then fed back, to increase the lead. Communication protocols aren't like editors/OS's/yadda-yadda. E.g. I use Epsilon - but the fact that few others do isn't a problem/issue for me. On the other hand, if I designed, implemented and personally adopted the world's best communication protocol... so what? There'd be nobody to talk to. That's just _one_ of the ways that communication systems are fundamentally different from other information systems. Noel

6 years, 5 months

Re: [TUHS] OSI stack (Was: Posters)

by Warner Losh

On Mon, Feb 4, 2019 at 8:43 PM Warner Losh <imp(a)bsdimp.com> wrote: > > > On Sun, Feb 3, 2019, 8:03 AM Noel Chiappa <jnc(a)mercury.lcs.mit.edu wrote: > >> > From: Warner Losh >> >> > a bunch of OSI/ISO network stack posters (thank goodness that didn't >> > become standard, woof!) >> >> Why? >> > > Posters like this :). OSI was massively over specified... > oops. Hit the list limit. Posters like this: https://people.freebsd.org/~imp/20190203_215836.jpg which show just how over-specified it was. I also worked at The Wollongong Group back in the early 90's and it was a total dog on the SysV 386 machines that we were trying to demo it on. A total and unbelievable PITA to set it up, and crappy performance once we got it going. Almost bad enough that we didn't show it at the trade show we were going to.... And that was just the lower layers of the stack plus basic name service. x.400 email addresses were also somewhat overly verbose. In many ways, it was a classic second system effect because they were trying to fix everything they thought was wrong with TCP/IP at the time without really, truly knowing the differences between actual problems and mere annoyances and how to properly weight the severity of the issue in coming up with their solutions. So x.400 vs smtp mail addresses: "G=Warner;S=Losh;O=WarnerLoshConsulting;PRMD=bsdimp;A=comcast;C=us" vis " imp(a)bsdimp.com" (assuming I got all the weird bits of the x.400 address right, it's been a long time and google had no good examples on the first page I could just steal...) The x.400 addresses were so unwieldy that a directory service was added on top of them x.500, which was every bit as baroque IIRC. TP4 might not have been that bad, but all the stuff above it was kinda crazy... Warner

6 years, 5 months

Re: [TUHS] OSI stack (Was: Posters)

by jnc＠mercury.lcs.mit.edu

> From: Grant Taylor > I'm not quite sure what you mean by naming a node vs network interface. Does one name (in the generic high-level sense of the term 'name'; e.g. an 'address' is a name for a unit of main memory) apply to the node (host) no matter how many interfaces it has, or where it is/moves in the network? If so, that name names the node. If not... > But I do know for a fact that in IPv4, IP addresses belonged to the > system. No. Multi-homed hosts in IPv4 had multiple addresses. (There are all sorts of kludges out there now, e.g. a single IP address shared by a pool of servers, precisely because the set of entity classes in IPvN - hosts, interfaces, etc - and namespaces for them were not rich enough for the things that people actually wanted to do - e.g. have a pool of servers.) Ignore what term(s) anyone uses, and apply the 'quack/walk' test - how is it used, and what can it do? > I don't understand what you mean by using "names" for "path selection". Names (in the generic sense above) used by the path selection mechanism (routing protocols do path selection). > That's probably why I don't understand how routes are allocated by a > naming authority. They aren't. But the path selection system can't aggregate information (e.g. routes) about multiple connected entities into a single item (to make the path selection scale, in a large network like the Internet) if the names the path selection system uses for them (i.e. addresses, NSAP's, whatever) are allocated by several different naming authorities, and thus bear no relationship to one another. E.g. if my house's street address is 123 North Street, and the house next door's address is 456 South Street, and 124 North Street is on the other side of town, maps (i.e. the data used by a path selection algorithm to decide how to get from A to B in the road network) aren't going to be very compact. Noel

6 years, 5 months

Re: [TUHS] Happy birthday, Ken Thompson!

by Doug McIlroy

> Ken wrote ... ed(before regexp ed) Actually Ken wrote a regexp qed (for Multics) before he wrote ed. He wrote about it here, before the birth of Unix: Programming Techniques: Regular expression search algorithm Ken Thompson June 1968 Communications of the ACM: Volume 11 Issue 6, June 1968 This is the nondetermistic regexp recognizer that's been used ever since. Amusingly a reviewer for Computing Reviews panned the article on the grounds that everybody already knew how to write a deterministic recognizer that runs in linear time. There's no use for this slower program. What the reviewer failed to observe is that it may take time exponential in the size of the regexp (and ditto for space) to make such a recognizer. In real life for a one-shot recognizer that can easily be the dominant cost. The problem of exponential construction time arose in Al Aho's egrep. I was an early adopter--for the calendar(1) daemon. The daemon generated a date recognizer that accepted most any (American style) date. The regular expresssions were a couple of hundred bytes long, full of alternations. Aho was chagrinned to learn that it took about 30 seconds to make a recognizer that would be used for less than a second. That led Al to the wonderful invention of a lazily-constructed recognizer that would only construct the states that were actually visited during recognition. At last a really linear-time algorithm! This is one of my favorite examples of the synergy of having sytems builders and theoreticians together in one small department. Doug

6 years, 5 months

Software Archeology: QED

by Christopher Browne

Sorry to drop in on the thread a bit late, and, strictly speaking, not (according to headers) connected to the thread; I am well acquainted with David Tilbrook, who is sadly not doing too well; it is not surprising that Leah Neukirchen was unable to get a hold of him as he hasn't been using email for some number of years > 1, and is definitely not programming. Hugh Redelmeier and I are looking into trying to do some preservation of his QEF toolset that included the QED port. Neither Hugh nor I are ourselves QED users; I'm about 30 years into my Emacs learning curve, albeit using Remacs (the Rust implementation) lately, while Hugh maintains JOVE to the extent to which it remains maintained. http://www.cs.toronto.edu/pub/hugh/jove-dev/ -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"

6 years, 5 months

Happy birthday, Ken Thompson!

by Dave Horsfall

Co-inventor of Unix, he was born on this day in 1943. Just think: without those two, we'd all be running M$ Windoze and thinking that it's wonderful (I know, it's an exaggeration, but think about it). -- Dave

6 years, 5 months

Re: [TUHS] Commercial UNIX was other stuff before

by Clem Cole

On Sun, Feb 3, 2019 at 2:59 PM Cág <ca6c(a)bitmessage.ch> wrote: > [Hockey Pucks and AIX are alive, Wikipedia says. > The problem could be that neither support amd64 and/or Be careful. The history of proprietary commercial UNIX implementations is that they were developed by HW manufacturers that had proprietary ISAs. So that fact that UX was Itanium and AIX was Power (or Tru64 in its day was Alpha) should not be surprising. It was the way the market developed. Each vendor sold a unique ecosystem and tried very hard to keep you in it. Portability was designed as an >>import<< idea, and they tried to keep you from exporting by getting you to use 'value add.' I remember during the reign of terror that Solaris created. Take as an example, the standard portable threading library was pThreads. But Solaris threads were faster and Sun did everything it could get the ISV's write using Solaris Threads. Guess what -- they did. So at DEC we found ourselves implementing a Solaris Threads package for Tru64, so the ISVs could run their code (I don't know if IBM or HP did it too, because at the time, our competition was Sun). BTW: this attitude was nothing new. I've said it before, the greatest piece of marketing DEC ever did was convince the world that VMS Fortran was Fortran-77. It was not close. And when you walked into most people writing real production code (in Fortran of course), you discovered they had used all of the VMS Fortran extensions. When the UNIX folks arrived on the scene the f77 in Seventh Edition was not good enough. You saw first Masscomp in '85, then a year later Apollo and 2 years after that, Sun develop really, really good Fortran's -- all that were VMS Fortran compatible. nobody cares about commercial Unix systems anymore. > This is a bit of blind and sweeping statement which again, I would take some care. There are very large commercial sites that continue to run proprietary UNIX on those same proprietary ISAs, often with ISV and in-home developed applications that are quite valuable. For instance, a lot of the financial and insurance industries live here. The question comes to how to value and count it. Just because the hackers don't work there, does not mean there are not a lots firms doing it. Those sites are extremely large and represent a lot of money. The number of them is unlikely to be growing last time I looked at the numbers. In fact, in some cases, they >>are<< being displaced by Intel*64 systems running a flavor of Linux. The key driver for this was the moving the commercial applications such as Oracle and SAP to Linux and in particular, Linux running on VMs. But a huge issue was code reuse. To reuse, Henry's great line about BSD, Linux is just like Unix; only different. Simply has the cost of maintaining your own ISA and complete SW ecosystem for it continues to rise and in fact is getting more and more expensive as the market shrinks. At this point, the only ones left are HP, IBM and the shadow of Sunoracle. They are servicing a market that is fixed. > > As far as commercial systems go, even CentOS has a far larger market > share on the supercomputer territory than RHEL does, according to > TOP500. > Again be careful. In fact this my world that I have lived for about 40+ years. The Top100 system folks really do not want any stinking OS between their application and the hardware. They never have. Don't kid yourself. This is why systems like mOS (Rolf Riesen's MultiOS slides <https://wrome.github.io/slides/rome16_riesen.pdf> and github sources <https://github.com/intel/mOS/wiki>) are being developed. Simply put, the HPC folks have always wanted the OS out the way. Unix was a convenience for them and Linux just replaced UNIX. The RHEL licensing scheme is per CPU and on a Beowulf style cluster, it does not make a lot of sense. I know a lot of the Linux community likes to crow about the supers using Linux. They really don't Its what runs on the login node and the job scheduler. It could be anything as long as its cheap, fast and the physicists can hack on it. This is a behavior that goes back the Manhatten Project and its unchanged. The 'capability' systems are a high-end world that is tuned for a very specific job. You can learn a lot in that area, but because about making generalizations. As I like to say -- Fortran still pays my salary. These folks codes are unchanged since my father's time as a 'computer' at Rocket Dyne in the 1950s. What has changed is the size of the datasets. But open up those codes and you'll discover the same math. They tend to be equation solvers. We just have a lot more variables. Clem

6 years, 5 months

Re: [TUHS] OSI stack (Was: Posters)

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > a bunch of OSI/ISO network stack posters (thank goodness that didn't > become standard, woof!) Why? The details have faded from my memory, but the lower 2 layers of the stack (CLNP and TP4) I don't recall as being too bad. (The real block to adoption was that people didn't want to get snarled up in the ISO standards process.) It at least managed (IIRC) to separate the concepts of, and naming for, 'node' and 'network interface' (which is more than IPv6 managed, apparently on the grounds that 'IPv4 did it that way', despite lengthy pleading that in light of increased understanding since IPv4 was done, they were separate concepts and deserved separate namespaces). Yes, the allocation of the names used by the path selection (I use that term because to too many people, 'routing' means 'packet forwarding') was a total dog's breakast (allocation by naming authority - the very definition of 'brain-damaged') but TCP/IP's was not any better, really. Yes, the whole session/presentation/application thing was ponderous and probably over-complicated, but that could have been ditched and simpler things run directly on TP4. {And apologies for the non-Unix content, but at least it's about computers, unlike all the postings about Jimmy Page's guitar; typical of the really poor S/N on this list.) Noel

6 years, 5 months

Re: [TUHS] Happy Birthday Ken Thompson!

by Doug McIlroy

> without those two we'd all be running M$ Windoze Apropos of which, I complained to Walter Isaacson about his writing them out of "The Innovators"--Turing Award, National Medal of Technology, Japan Prize and all. I suppose I should not be surprised that he didn't deign to answer. Doug

6 years, 5 months

Wanted: AT&T System V Release 3.2.{1,2,3} Source Code

by Seth J. Morabito

[Cross-posted from the 3B2 mailing list] Hi folks, I'm in search of source code for AT&T's System V Release 3.2.1, 3.2.2, and/or 3.2.3 for the 3B2. Does this exist? Has anyone ever seen it? Note that I'm not looking for the System V Release 3.2 Source Code Provision for the 3B2 /310 and /400 -- I already have that. It was absolutely invaluable when I was writing my 3B2/400 emulator. The reason I'm so keen on getting access is that I have ROM images from a 3B2/1000, and I'd like to add support for it to my 3B2 emulator. The system board memory map seems a bit different than the /300, /310, and /400. These max out at SVR 3.2. I can't imagine trying to add 3B2/1000 support without the 3.2.x source code. I imagine there's some tape image somewhere that's a delta of files that take you from 3.2 to 3.2.1, 3.2.2 or 3.2.3? -Seth -- Seth Morabito Poulsbo, WA, USA web(a)loomcom.com

6 years, 5 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