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
--
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.
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.
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
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.
> 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
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
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
> 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_Elementhttps://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
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
