It's always amazing to me to see all the hype around containerization and build once, run anywhere, and a lot of the tech trends happening now and realize that we've been reinventing the wheel, since products like AS/400 (a.k.a System/38 a.k.a iSeries) have been doing it since before PCs were ever a thing. It's perhaps even more funny when the reimplementation is inferior to the original product (which seems to happen with some level of regularity). It's a shame mid-range IBM iron is both expensive and sort of vendor-locked as it's really often a rather nice system to build for; system/38 really was revolutionary and really has influence more than I think we often give it credit for.
I grew up with computing in the 70's and 80's, and I truly think the 90's were a period of devolution in the computer industry - desktop (Microsoft) computing came a long and gave computing to the masses, but the cost was that a lot of technical advances that were being made in the industry as a whole got swept under the covers - for various reasons, either it confused users, or Microsoft just didn't have the technology chops to get it into their OS, or whatever.
But I definitely think we make many, many advances in computing that get washed away by the mass-market mechanics required to get things out there in a way that satisfies the bean counters.
I remember being able to freeze/defrost process on MIPS Risc/OS back in the day .. I even used it as part of my development/test process, since security policies in the computer rooms I was working in the 80's meant that some systems (operational) were not allowed to have compilers - the only way I could test my new build was to run the process, freeze it to disk, send it over to the test-ops machines, and defrost them. I did this so often that it just became commonplace - yet the ability to do this just faded during the 90's when I moved to other environment. I still can't do this easily on any of our existing systems, although there's cryopid and company - but it strike me as amusing that these sorts of capabilities are being touted as new and ground-breaking. More often than not, the discoveries of a unicorn comp-sci grad who just spent 5 years on themselves seem to be re-inventing things they were ignoring all the while were standard, in the rush to push the past aside and no longer deal with dinosaurs.
Its a funny business we're in. I look forward to the next cycle of devo/evo-lution.
That's called checkpointing or checkpoint/restore these days, and it's sadly mostly limited to HPC and cluster environments. That said, there are some projects (at least for Linux) like DMTCP and CRIU which try to offer it as userspace tools, if somewhat finicky.
DragonFly BSD has had kernel-level checkpointing through sys_checkpoint(2) since 2005, but it has limitations with multithreaded programs.
Thanks for the pointer about Dragonfly, I'm not at all surprised that it has solid checkpointing, since its developers are definitely hard-metal types.
For my part, I treat my Docker files as my own little server-farm, and production is of course managed else-wise, so its all just an amusing analog of how things worked 'in the good old days' ..
Cryopid on Linux looked interesting for a while, but I guess its not really relevant as a feature in this age of hardware. In the good old days, it was necessary to checkpoint to get out of the way of the other jobs the computing facility had to perform .. endless tapes of checkpoints, hanging on the wall, waiting to be spooled, re-spooled, etc.
Many a recent discovery in science have been thanks to someone glancing over the mental partitions between fields of study and going "hey, i recognize that. We have a decade old solution for it".
The problem is that IBM shot themselves in the foot on this (just as Cisco seems to be hell bent on doing). As near as I can tell it goes like this:
(1) Companies want hardware they can find people with experience on
(2) The only way to get IBM big iron experience is to have big iron hardware (ongoing scuffles with emulation: https://www.google.com/search?q=ibm+sues+emulatorhttps://en.wikipedia.org/wiki/Hercules_%28emulator%29 )
(3) IBM mainframes are expensive compared to commodity hardware
(4) Universities don't choose to run IBM mainframes
(5) A tiny minority of people coming out of university actually have experience
(6) Companies are worried about the lack of inexpensive employees with experience
They have amazing features in their OS's, for sure, but no amount of marketing budget makes up for "I can throw this on my PC in some fashion that I can learn about those features."
Bingo. And why you see the likes of Apple, Adobe and Microsoft bend over backwards to offer students deep discounts.
Heck, MS has been using their personal computing market share in their business sales pitches. This in the form of "total cost of ownership". More specifically that people will be accustomed to MS interfaces from their home use, and so less training is needed as new employees.
I agree, though a correction: PCs very much did exist by the time of AS/400, and particularly when OS/400 (IBM i) introduced LPARs, though analogues have been around in plenty of IBM's prior systems.
A predecessor of the AS/400, the System/36 PC was available in very similar chassis to the IBM AT. It used an IBM 5150 ( aka PC ) as the console with a special interface card.
Yeah, you're right. I made a perhaps bad/loose equivocation for System/38, which I think predates IBM PCs, to AS/400, which showed up in the late 80's.
I currently work on an iSeries, while there is some vendor lock we have run unix programs through PASE, we run a full suite of web enabled applications some of which reuse code that has been around forever. Even RPG has gone modern with fully free form code, procedures, embedded sql, and with ILE the ability to be bound with modules written in any other supported language.
The deployed base is very large and across a great many industries because of resilience, ease of programming, minimal support staff required, and simply because with most big systems it just works. Its not flawless but db2 is far easier to manage than oracle and the iSeries we have operate with much smaller staffs than the AIX/Oracle setups.
Overall the biggest failing is IBM's lack of direction. They tend to push systems which generate the biggest kickback and such, usually meaning their AIX fare.
No matter how many times efforts were put in place to move off the i or even z it just came down to, it works, its modern, and for businesses having something you know is many times better than going with the newest thing.
Chronologically, it was actually S/32 => S/34 => S/38 => S/36. Though S/36 was more a successor to S/34, built on more modern hardware but didn't really offer anything new in terms of OS architecture.
It wasn't IBM - IBM actually made fun of virtual memory while their engineers caught up with the competition.
I know that the RCA Spectra series had virtual memory in the 70's. The Spectra series was a 360 clone with the same instruction set. RCA developed virtual memory and converted their TSOS (Time Sharing Operating System) to VMOS. Univac bought the Spectra line and converted VMOS to VS/9. I worked for Univac at the time.
Virtual memory may have been used earlier by the Scientific Data Systems (SDS) Sigma series, later bought by Xerox. I was once a peripheral device to a Sigma, hooked up for an ECG.
I believe it was Burroughs who first did virtual memory. This was before the IBM Model 67 and the research at University of Michigan.
So my first major gig was a startup called Telemed located first in Park Ridge then in Chicago, in an office building at the end of runway 27 L. We built this system of collecting ECG data over the phone line in three-channel FM, converted to digital and then processed by Sigma 5! Sounds like the same system that you were hooked up to. How about that.
The Sigma5 didn't have virtual memory, but the Sigma 7 did. But this was well after both Burroughs and IBM had commercial offerings.
The Sigma series was produced by Scientific Data Systems, later bought by Xerox. Made Max Plaevsky the largest Xerox until Xerox bought University Microfilms.
I think, the Atlas was the first machine to support virtual memory (https://en.wikipedia.org/wiki/Atlas_%28computer%29), but I am not entirely sure when Burroughs first released a machine with virtual memory. Atlas was - according to Wikipedia - first operational in 1962.
