On Monday, July 10, 2023 at 4:49:37 PM UTC-7, Stephen Fuld wrote:
> ISTM that there is some conflation of two things here. One is the
> ability to provide greater isolation between applications than a single
> OS can provide (though the single OS side could argue that a well
> designed OS could provide all that you need), and the ability adjust
> compute capacity on the fly, to meet varying demand.
While containers supposedly provide greater isolation, I don't see that as something that Mr. Duncan is really pushing.
Instead, ISTM that it's just another selling point to supposedly make the case that implementing something container-like on OS2200 is A Good Thing.
What I see Mr. Duncan trying to do is to come up with something that will increase OS2200's desirability.
I can't fault him for that, but I don't see the value of what he's proposing economically.
I keep remembering when some of the Blue Bell suits came to talk to the troops in the Building 2 cafeteria and one of them basically said, "We can't cost-cut our way to profitability ... we have to grow our markets.".
I took that to mean that if the Company wanted to do more than just barely survive, it had to find other people to sell our products to (in particular, 1100/2200 hardware) to lots of people who weren't already our customers.
I still think that's the "correct" strategy, but at this point, I just don't know if there's anyone else to sell to and adding containers to OS2200 doesn't change that.
> If you really wanted more separation among instances of OS 2200, I don't
> think there is any technical barriers preventing you from running
> multiple instances of Linux each with its own copy of the emulator and
> OS/2200 to gain that separation. [...]
I don't think there's anything (aside from cost) to running 2200 emulator software directly on a Intel software with no hypervisor or a type-2 (bare metal) hypervisor rather than on a type-1 KVM Linux hypervisor.
But while doing so might make an emulated 2200 system more secure, I just don't see that as being economically worthwhile either.
(I've spent some time wondering how difficult it would be to get BOOTBOOT to load up a 2200 emulator on bare metal directly, but that's something that a hobbyist can do, not a for-profit company with a limited body count.)
> [...] I know that Unisys modified Linux in
> some way to make OS/2200 run better on it, but I don't know if it is
> technically possible or not to run multiple copies of the emulator on a
> single Linux, or multiple copies of OS/2200 on a single copy of the
> emulator. That would achieve the separation. But all of that is not
> related to the varying the amount of CPU power available.
It is my understanding that the Company has a modified Linux kernel as the hypervisor (which it calls SAIL if you want to look up the Unisys documentation for it) upon which its emulated 2200 software runs.
Since the Company tweaked it, I would kinda suspect that it not just a bog-standard KVM Linux.
> No matter what OS you have, if you need more compute capacity, you need
> additional hardware. A single customer seems to me to be unlikely to
> have additional hardware available "just in case", so that requirement
> is met by some sort of "rent capacity as required" from some company
> that has lots of extra capacity to make available to different customers
> as needed, i.e. a "cloud computing facility". Having that seems to me
> to be independent of what software you run on that cloud. For example,
> assume that a business case could be made for it, I don't think there is
> any substantial technical problem from getting extra X86 computer power
> from a cloud, running Linux on that new CPU with OS2200 on top of that
> Linux.
I agree which is why trying to modify OS2200 to support something container-like doesn't make much sense to me.
ISTM that it might if you had a server farm of 2200s (emulated or real) with a lot of excess compute capacity that you wanted to be able to re-purpose on the fly, but for some reason, I doubt that's what current Unisys customers have laying around.
> Of course, there are business issues that I am not competent to discuss.
I disagree. I think that people who are actually familiar with the good or service that a company sells are as competent as those who "run" a company but don't have a clue what that company really sells (because everything is a "widget").
> On a related note, regarding the separation issue (again, not the
> varying capacity issue), how is the solution different from something
> like IBM's VM, which has been around since the 1970s?
If you're referring to how a container is different from a VM, then I would say my understanding is that they are both functionally equivalent, but that containers are supposedly "lighter weight" when it comes to the underlying resources, quicker to spin up, and (usually?) faster.
Meanwhile, VMs are supposedly more secure.
Keep in mind that I'm just a poor dumb former Bootstrap programmer though who has no experience with containers and so anything I say on the subject should probably be taken with a large salt lick.
> And I may be misremembering, but I vaguely recall an aborted attempt by
> Univac/Sperry to add a VM like capability in the form of a specialized
> instruction to aid that, perhaps in the 1110? Am I just having a fever
> dream??
I would think that it would take more than a single instruction to add VM support to the 1100 architecture, although I supposed that one could do it with a VERY modified "execute" instruction.
FWIW, Once upon a time, I recall hearing that some processor (not a Univac/Sperry one) was going to have a "execute alternate architecture" instruction.
I don't know who was supposedly going to make it or whether or not anything actually became real.
I gather that IBM's "Future System" CPUs could be reprogrammed to be function specific CPUs.
Of course, at least some Burroughs machines could be loaded up with different instruction sets for programs written in different HLLs.
The only thing that kinda-sorta-vaguely strikes me as the same thing was Roanoake.
If you come up with more details, I would be interested in hearing them.