VMS port to x86

[JF Mezei]

Was thinking about the Oracle allegations against HP.

HP did have plans to port HP-UX to x86 and started the work.
And I have been told that porting of VMS to x86 had also been started.

Neither of which would have been official projects since they couldn't
appear in any books since HP wanted very much to hide the fact that
IA64'S EOL was aready planned.


At some point, HP decided to not port to x86.

Then, VMS experienced engineering team is fired and replaced by newbie
programmers given 2 weeks of training.

Looks to me that once HP decided to end of line its proprietary OS at
same time as IA64, there was no point in keeping the experienced
engineering teams since they wouldn't be needed for the port.

I fear it may be too late to save VMS.

[Howard S Shubs]

In article <4f67e979$0$4672$c3e8da3$3a1a...@news.astraweb.com>,

JF Mezei <jfmezei...@vaxination.ca> wrote:

> I fear it may be too late to save VMS.

We can always hope they'll release the source code for some earlier
version, such as 7.3. Then we can have some fun.

--
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

[Steven Schweda]

> I fear it may be too late to save VMS.

F L A S H ! SUN RISES IN MORNING

[JF Mezei]

Steven Schweda wrote:

> F L A S H ! SUN RISES IN MORNING

Well, it is morning here already (01:18) and the sun has not risen. :-)

And towards end of june the sun doesn't rise at Inuvik and further
north. (neither does it set).

So that rule which you thought was unbreakable is in fact breakable. :-)

[Michael Kraemer]

JF Mezei schrieb:

>
> At some point, HP decided to not port to x86.
>

According to what I've read,
there was no customer demand for it.

>
> Looks to me that once HP decided to end of line its proprietary OS at
> same time as IA64, there was no point in keeping the experienced
> engineering teams since they wouldn't be needed for the port.
>
> I fear it may be too late to save VMS.

well, iirc, the source listing is available,
so feel free to start your own skunkworks project.

[David Froble]

Howard S Shubs wrote:
> In article <4f67e979$0$4672$c3e8da3$3a1a...@news.astraweb.com>,
> JF Mezei <jfmezei...@vaxination.ca> wrote:
>
>> I fear it may be too late to save VMS.
>
> We can always hope they'll release the source code for some earlier
> version, such as 7.3. Then we can have some fun.
>

There already exists a Macro32 compiler, used on both Alpha and itanic. Don't know what
language it's written in, but with recent trends, probably (hock, spit) C.

Same argument for Bliss.

Just being able to compile the code probably isn't the only requirements. There is most
likely some things that depend upon the underlying hardware. That's a conservative
assumption to make.

Not going to try to guess what all the problems might be, but, I've got to think that it's
not just a complete re-write.

[abrsvc]

As with previous ports, there are many things involved. Simply porting the compilers won't be enough. The Macro compiler and the bliss compiler use the GEM backend code generator. That too would need to be developed. Also, tehre are "hardware assists" that are used to implement some of the VMS "isms" that exist. For example, I don't think that the x86 has the concept of 4 operating priv modes.

Dan

[Michael Kraemer]

In article <543564.889.1332262058086.JavaMail.geo-discussion-forums@vbgx21>,
abrsvc <dansabr...@yahoo.com> writes:

>
> As with previous ports, there are many things involved. Simply porting the=
> compilers won't be enough. The Macro compiler and the bliss compiler use =
> the GEM backend code generator. That too would need to be developed. Also=
> , tehre are "hardware assists" that are used to implement some of the VMS "=
> isms" that exist. For example, I don't think that the x86 has the concept =

> of 4 operating priv modes.

Another aspect could be, that for a software product as complex as VMS,
one could imagine that over the decades,
the owners have accumulated a gazillion of
(regression) test cases to ensure proper functioning even for rare situations.
Unless these are released too, a lot of wheels would have to be reinvented.

[Bob Koehler]

In article <543564.889.1332262058086.JavaMail.geo-discussion-forums@vbgx21>, abrsvc <dansabr...@yahoo.com> writes:
>

> As with previous ports, there are many things involved. Simply porting the=
> compilers won't be enough. The Macro compiler and the bliss compiler use =
> the GEM backend code generator. That too would need to be developed. Also=
> , tehre are "hardware assists" that are used to implement some of the VMS "=
> isms" that exist. For example, I don't think that the x86 has the concept =

> of 4 operating priv modes.

Jees, how many times have we been over this. 80386 and later all
have the 4 modes needed by VMS. There are no "hardware assists"
added to Itanium just to make VMS work.

[David Froble]

Forget about modes and such, that's just details that could be addressed.

All I was trying to say is that there is much that would require little or no re-working.
As with NT, there was the code dealing with the OS, and there was what I think they
called the "hardware layer".

But VMS isn't just the OS. There are all the tools, languages, and such that make up the
total package. If you cannot get all of it, then why bother? Frankly, I'm more than a
bit tired of being told to "program in C and forget the other languages". If that's all I
wanted to do, I can do it on Unix and windoz. Some things I can do on Windoz much easier.

As pointed out, there is the back side of the GEM compilers. Sure, the front end stuff
should work, syntax checking and parsing and such, but you then have to produce code that
would run on the target hardware.

It would not be an easy job, or better to say it would not be a cheap job. If HP cannot
justify doing it, then I doubt anyone else could justify the cost.

In terms of cost, I cannot know what it would take. I have some ideas, but, there are
other issues. If HP would have retained the team that did the IA64 port, then perhaps
they could have done the job at a reasonable cost. But they didn't. And now it's
possible that the critical knowledge no longer exists at HP. That might be the real problem.

[Steven Schweda]

Because you know what I thought, it may be redundant to
point out that an event which does not occur everywhere at
every time can still be less than amazing.

[Neil Rieck]

Translation:

If OpenVMS is not ported to x86-64 then OpenVMS is toast!
If NonStop is not ported to x86-64 then NonStop is toast!
If HP-UX is not ported to x86-64 then HP-UX is toast!
If HP doesn't get back its technical talent to do these ports, HP will
be toast!

p.s. Here is a laugh from Wikipedia: Tandem was then (1998) midway in
porting its NonStop product line from MIPS R12000 microprocessors to
Intel's new Itanium Merced microprocessors. This project was restarted
with Alpha as the new target to align NonStop with Compaq's other
large server lines. But in 2001, Compaq terminated all Alpha
engineering investments in favor of the unproven Itanium
microprocessors. The Alpha version of NonStop died before shipping. So
the NonStop migration project was restarted yet again, targeting
Itanium McKinley.

Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/

[JF Mezei]

Neil Rieck wrote:

> If OpenVMS is not ported to x86-64 then OpenVMS is toast!
> If NonStop is not ported to x86-64 then NonStop is toast!
> If HP-UX is not ported to x86-64 then HP-UX is toast!

Correct. But HP has bet that it can survive by offering migration to
Linux or Windows on its own servers.

With HP now building 8086 based Superdomes which should be shipping
soon, HP should stay to unveil its true colours within the next 12
months. The Oracle documents said that customers would find out about he
EOL of Itanium in 2012 so that the 5 year period would correspond to the
end of support by Intel.


My gut tells me that the decision to gut VMS engineering came when HP
decided to abandon porting efforts. It is a shame because VMS could
probably be ported to X86 much cheaper and faster than HP-UX (endianness
issues for HP-UX).

It isn't clear what value HP-UX on x86 would bring that Linux couldn't
bring.

But VMS and NSK would still bring distinctive features not available on
Linux.


The big question is really NSK. It would not surprise me if this were
the only OS to survive the death of IA64. Those are high value and high
profile servers that, in many cases, control lives.


Another possibility is that HP will have its own distribution of linux
with proprietary HP add-ons. This would compete against the other Linux
distributiosn such as Red Hat etc

[Neil Rieck]

This comment is a little off topic, but may be worth mentioning. I
recently stumbled across "Compaq's source code for OpenSSL 1.1A" which
appears to have been written in 2003. While this product version was
targeted at Alpha and VAX, the scripts contain bread-crumbs showing
that OpenVMS engineering was playing with an Itanium cross compiler.
No surprise here, they always had a plethora of tools.

Why should anyone care? These people were much better at doing
software than anything else. If someone decided that OpenVMS should be
ported to x86-64 then it would be easy to begin. If HP was smart then
they've been doing this for a while.

###

Oracle has products running on every endian platform so I'm going to
assume "endian" is no longer the technical obstacle it once was.

According to wikipedia:
http://en.wikipedia.org/wiki/Endianness

These platforms are little endian:
OpenVMS on VAX, Alpha and Itanium
Solaris on x86, x86-64, PowerPC
Tru64 UNIX on Alpha
Windows on x86, x86-64, Alpha, PowerPC, MIPS and Itanium

...so it should be easier to port OpenVMS than HP (which is big endian
on the bi-endian Itanium)

[Johnny Billquist]

Neither do the Itanic...
But yes, porting to a new architecture is more work than just making
compilers run.

Johnny

[Johnny Billquist]

No, they don't. But VMS don't actually need four hardware modes in order
to work, which is what Itanium proves.

Johnny

[John Reagan]

"David Froble" wrote in message news:jka781$jpo$1...@dont-email.me...

>There already exists a Macro32 compiler, used on both Alpha and itanic.
>Don't know what language it's written in, but with recent trends, probably
>(hock, spit) C.

>Same argument for Bliss.

The Macro compiler is written in Macro-32 (uses the same pass1 parser as the
VAX Macro-32 assembler), C, and BLISS.

The BLISS frontend is BLISS.

GEM is a mixture of BLISS, C, and C++. (I'd say 60/40 in favor of BLISS)

[Bob Koehler]

In article <2cda01d4-8363-4198...@cj6g2000vbb.googlegroups.com>, Neil Rieck <n.r...@sympatico.ca> writes:

> If HP doesn't get back its technical talent to do these ports, HP will
> be toast!

HP has enough technical talent to procude ink and paper for a long,
long, time, without worrying about toast.

[Bob Koehler]

In article <jkcjcn$p3r$3...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> No, they don't.

Intel, not to mention every other reference I've seen, says they do:

http://www.intel.com/Assets/en_US/PDF/manual/253668.pdf?wapkw=cpu+architecture+mode+ring

Intel. 64 and IA-32 Architectures
Software Developer.s Manual
Volume 3A:
System Programming Guide, Part 1

"The processor.s segment-protection mechanism recognizes 4 privilege
levels, numbered from 0 to 3."

[VAXman-]

I wonder if INSQxIs will work on x86! :D ;)

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[John Wallace]

On Mar 21, 7:32 pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:

> In article <jkcjcn$p3...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> > No, they don't.
>
>    Intel, not to mention every other reference I've seen, says they do:
>

> http://www.intel.com/Assets/en_US/PDF/manual/253668.pdf?wapkw=cpu+arc...

>
>    Intel. 64 and IA-32 Architectures
>    Software Developer.s Manual
>    Volume 3A:
>    System Programming Guide, Part 1
>
>    "The processor.s segment-protection mechanism recognizes 4 privilege
>     levels, numbered from 0 to 3."

There's a discussion for anyone interested to have about how well the
AMD64 and IA64 protection mechanisms map onto the VMS-required
mechanisms, and how exploit-proof they might be in reality. My
recollection is that Alpha only had two protection levels in the
hardware, the rest was implemented in PALcode, but the Alpha
architecture and design and the VMS implementation appeared reasonably
leakproof, subject to the occasional near-inevitable software bug.

x86 wasn't really architected, just thrown together over a number of
years. AMD64 and IA64 attempted to address that but who knows how
successful they were technically?

The increasing use of HYPErvisors on AMD64 and elsewhere may make IT
people increasingly conscious of things like unauthorised privilege
escalation and information leakage. Or may not.

[John Reagan]

> I wonder if INSQxIs will work on x86! :D ;)

I'll have to ask Hoff. :)

[Richard B. Gilbert]

VMS has been dead, in some sense, for about thirteen years now!

I still have a couple of systems running VMS and I'll hang on to them.
I don't know that I'll DO anything with them, there seems to be very
little demand!

Face it. If VMS is not dead, it's on "life support".

[VAXman-]

In article <GfGdnWMIE92bq_fS...@earthlink.com>, "John Reagan" <johnr...@earthlink.net> writes:
>
>
>> I wonder if INSQxIs will work on x86! :D ;)
>
>I'll have to ask Hoff. :)

Now it's beginning to all make sense.

[Bob Gezelter]

VAXman,

I have not worked out the precise sequences, but IMHO the x86 certainly has the ISP (Instruction Set Processor) functionality to implement the INSQxIs instructions.

The original VAX implementation in microcode represented a reasonable decision reflecting the state of semiconductor technology ala 1977. The tradeoffs are different now, in favor of software implementations. The proof of this in any Computer Science text on architecture. All that is REQUIRED for multiprocessor synch is in effect a Test-and-Set (or Fetch-and-Add) primitive. Everything else can be constructed using that as a base.

- Bob Gezelter, http://www.rlgsc.com

[Johnny Billquist]

My bad. Anyway, you do not need four hardware levels in order p[
implement VMS. Two is what really is needed. The rest can be solved in
software, although having hardware makes it easier/more efficient.

Johnny

[John Wallace]

On Mar 22, 3:24 pm, Bob Gezelter <gezel...@rlgsc.com> wrote:
> On Wednesday, March 21, 2012 6:49:21 PM UTC-4, (unknown) wrote:

> > In article <GfGdnWMIE92bq_fSnZ2dnUVZ_jadn...@earthlink.com>, "John Reagan" <johnrrea...@earthlink.net> writes:
>
> > >> I wonder if INSQxIs will work on x86! :D ;)
>
> > >I'll have to ask Hoff. :)
>
> > Now it's beginning to all make sense.
>
> > --
> > VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
>
> > Well I speak to machines with the voice of humanity.
>
> VAXman,
>
> I have not worked out the precise sequences, but IMHO the x86 certainly has the ISP (Instruction Set Processor) functionality to implement the INSQxIs instructions.
>
> The original VAX implementation in microcode represented a reasonable decision reflecting the state of semiconductor technology ala 1977. The tradeoffs are different now, in favor of software implementations. The proof of this in any Computer Science text on architecture. All that is REQUIRED for multiprocessor synch is in effect a Test-and-Set (or Fetch-and-Add) primitive. Everything else can be constructed using that as a base.
>
> - Bob Gezelter,http://www.rlgsc.com

Bob,

I suspect you know better than that (you even said "in effect") but
here's a footnote or two for anyone who's interested.

1) It's not just for multiprocessor synch even though MP synch is the
classically quoted example. Unless I'm mistaken, it's also for
protecting any multi stage operation which is at risk of delivering
undesirable results if interrupted - for example, accessing a multi-
word datum in mainline code while some other bit of code in an ISR (or
in an AST, or in a different thread, or ...) might want to read (or
write) it and might get to run.

2) RISC processors tend not to use Test and Set because they tend to
have load/operate/store designs where only the loads and stores can
access memory and most opcodes only do registers. So on Alpha (and
iirc on ARM) and various others the same result is achieved using load-
locked/store-conditional instruction groups (or some equivalent with a
different name). It's written up in lots of places, for Alpha
including the VMS Programming Concepts manual or the freely
downloadable Alpha Architecture Handbook.

Every mainstream processor I know has this kind of capability one way
or another but I'm also aware of one obscure one that doesn't. On that
one you have to be careful about when non-atomic data can be accessed.
Great fun.

There is also a case to be made that these things can be done without
any underlying semaphore capability (semaphore is what T+S etc
provides) but it seems a fairly pointless argument in general.

[VAXman-]

In article <5819721.328.1332429897519.JavaMail.geo-discussion-forums@vbbfw10>, Bob Gezelter <geze...@rlgsc.com> writes:
>On Wednesday, March 21, 2012 6:49:21 PM UTC-4, (unknown) wrote:

>> In article <GfGdnWMIE92bq_fS...@earthlink.com>, "John Reagan=

>" <johnr...@earthlink.net> writes:
>> >
>> >
>> >> I wonder if INSQxIs will work on x86! :D ;)
>> >
>> >I'll have to ask Hoff. :)

>>=20
>> Now it's beginning to all make sense.=20
>>=20
>> --=20
>> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)=
>ORG
>>=20

>> Well I speak to machines with the voice of humanity.
>
>VAXman,
>

>I have not worked out the precise sequences, but IMHO the x86 certainly has=
> the ISP (Instruction Set Processor) functionality to implement the INSQxIs=
> instructions.=20
>
>The original VAX implementation in microcode represented a reasonable decis=
>ion reflecting the state of semiconductor technology ala 1977. The tradeoff=
>s are different now, in favor of software implementations. The proof of thi=
>s in any Computer Science text on architecture. All that is REQUIRED for mu=
>ltiprocessor synch is in effect a Test-and-Set (or Fetch-and-Add) primitive=
>.. Everything else can be constructed using that as a base.

Correct Bob, now if only it gets implemented properly unlike the INS/REM-QxIs
on another platform. :rolleyes:

[glen herrmannsfeldt]

John Wallace <johnwa...@yahoo.co.uk> wrote:

(snip)

> I suspect you know better than that (you even said "in effect") but
> here's a footnote or two for anyone who's interested.

> 1) It's not just for multiprocessor synch even though MP synch is the
> classically quoted example. Unless I'm mistaken, it's also for
> protecting any multi stage operation which is at risk of delivering
> undesirable results if interrupted - for example, accessing a multi-
> word datum in mainline code while some other bit of code in an ISR (or
> in an AST, or in a different thread, or ...) might want to read (or
> write) it and might get to run.

(snip on RISC processors and store conditional)

> Every mainstream processor I know has this kind of capability one way
> or another but I'm also aware of one obscure one that doesn't. On that
> one you have to be careful about when non-atomic data can be accessed.
> Great fun.

In the core memory days, where core has a destructive read and so
requires a write back, there were some processors that would do a
read-modify-write by delaying the write back to core. (That assumes
that there are read-modify-write instructions.)

DRAM also requires a write back, and I beleive that some early DRAM
users at least thought about delaying the write back.

> There is also a case to be made that these things can be done without
> any underlying semaphore capability (semaphore is what T+S etc
> provides) but it seems a fairly pointless argument in general.

IBM S/360 has TS (test and set), where S/370 added CS and CDS
(compare and swap, compare double and swap). There is some discussion
about the need to add new instructions without multiprocessing, but
that when they were shown to be needed even with a single processor
(in the case of interrupts), then they were allowed to be added.

-- glen

[Bob Koehler]

In article <00ABEAFB...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
>
> I wonder if INSQxIs will work on x86! :D ;)
>

How many instructions in lib$insqXi on IA64?

[Bob Koehler]

In article <c0ce4a20-dd64-4c50...@q11g2000vbu.googlegroups.com>, John Wallace <johnwa...@yahoo.co.uk> writes:
>
> There's a discussion for anyone interested to have about how well the
> AMD64 and IA64 protection mechanisms map onto the VMS-required
> mechanisms, and how exploit-proof they might be in reality. My
> recollection is that Alpha only had two protection levels in the
> hardware, the rest was implemented in PALcode, but the Alpha
> architecture and design and the VMS implementation appeared reasonably
> leakproof, subject to the occasional near-inevitable software bug.

Yes, there are some "OS defined" bits in Alpha where you might
expect support for twice as many modes.

Alpha modes aren't a perfect map to VAX, and neither are IA64,
but they are good enough and IA32 looks like it would be, too.

[John Reagan]

"Bob Koehler" wrote in message
news:ryFmpNcXtFN$@eisner.encompasserve.org...

> How many instructions in lib$insqXi on IA64?

The code checks for operand alignment, raises to IPL 14, disables
interrupts, uses the 'tak' instruction (an esoteric Itanium instruction to
look in translation buffers and page tables), locks the header, probes the
header, probes the predecessor, restores interrupts, lowers IPL, checks for
pending ASTs, etc.

I counted 60 bundles in the best case but there are retry paths if the 'tak'
fails, etc.

[VAXman-]

That's the count in LIB$INSQxI? Or, the {SYS/EXE}$PAL_INSQxI? I suppose I
could just count them for myself.

[Sprag]

On Mar 21, 3:32 pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:

> In article <jkcjcn$p3...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> > No, they don't.
>
>    Intel, not to mention every other reference I've seen, says they do:
>

> http://www.intel.com/Assets/en_US/PDF/manual/253668.pdf?wapkw=cpu+arc...

>
>    Intel. 64 and IA-32 Architectures
>    Software Developer.s Manual
>    Volume 3A:
>    System Programming Guide, Part 1
>
>    "The processor.s segment-protection mechanism recognizes 4 privilege
>     levels, numbered from 0 to 3."

Yep, for segemented 32 bit mode x86 has 4 levels. They don't map
directly to the vax levels, but there are 4 of them. In any case, in
x86-64 there are two levels because it doesn't use segmentation --
just page-level protection.

[John Reagan]

wrote in message news:00ABEC4B...@SendSpamHere.ORG...

>That's the count in LIB$INSQxI? Or, the {SYS/EXE}$PAL_INSQxI? I suppose I
>could just count them for myself.

I counted SYS$PAL_INSQTI. LIB$INSQTI is a small C routine that contains an
'__PAL_INSQTIL' built-in call in a while loop until it succeeds, then
returns a return value based on the return code from the PAL built-in. The
compiler turns that into a call to SYS$PAL_INSQTIL. So LIB$INSQTI would
involve an 'alloc', 'br.call', a handful of compares, 'br.ret' and not much
more. Another 10 bundles maybe. Any real overhead is in the SYS$ routine
to provide correct synchronization.

[onedbguru]

Sadly, I am not sure I would be that generous... Even though it still runs my home web server and offsite backups for a long-time customer who uses it daily - I am not sure what I will do when their DS10 dies as it has been running 24x7 since 1999 when it replaced a MVII that ran for equally as long. The custom app was "migrated" via VEST because the developer did not appear to keep the entire app source code on the customer system and subsequently was hit by a bus and there was no good backup before the old system died - except for the executables and some of the source code.

[JF Mezei]

I was just thinking.

If HP were to produce fault tolerant 8086s for NSK, those boxes could
also become quite usable as routers in enterprise (since there is now
some serious open sourced routing software) and HP could then provide
compelling products.

Sure, it would cannabalise some of the sales of its 3com unit, but it
could do serious harm to folks like cisco.

[JohnF]

onedbguru <oned...@yahoo.com> wrote:

> Richard B. Gilbert wrote:
>> >
>> > At some point, HP decided to not port to x86.
>> >
>> > Then, VMS experienced engineering team is fired and replaced by newbie
>> > programmers given 2 weeks of training.
>> >
>> > Looks to me that once HP decided to end of line its proprietary OS at
>> > same time as IA64, there was no point in keeping the experienced
>> > engineering teams since they wouldn't be needed for the port.
>> >
>> > I fear it may be too late to save VMS.
>>
>> VMS has been dead, in some sense, for about thirteen years now!
>>
>> I still have a couple of systems running VMS and I'll hang on to them.
>> I don't know that I'll DO anything with them, there seems to be very
>> little demand!
>>
>> Face it. If VMS is not dead, it's on "life support".
>
> Sadly, I am not sure I would be that generous... Even though
> it still runs my home web server and offsite backups for a
> long-time customer who uses it daily - I am not sure what
> I will do when their DS10 dies as it has been running 24x7
> since 1999 when it replaced a MVII that ran for equally as long.
> The custom app was "migrated" via VEST because the developer
> did not appear to keep the entire app source code on the
> customer system and subsequently was hit by a bus
> and there was no good backup before the old system died -
> except for the executables and some of the source code.

Literally hit by a bus??? If ever there was a metaphor...
--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

[Paul Sture]

Hit by a Q-bus, I assume. :-)

--
Paul Sture

[VAXman-]

or a UNIbus... or a BI bus... or an XMI bus... or a PCI bus... :)

Back to serious matters... Try AESTing the VESTed code and then see how it
functions on Itanium.

[John Reagan]

"JF Mezei" wrote in message
news:4f6d5a90$0$2201$c3e8da3$4605...@news.astraweb.com...

>I was just thinking.

>If HP were to produce fault tolerant 8086s for NSK, those boxes could

Any more fault tolerant than the Itaniums used by NSK today?

[John Wallace]

Exactly.

Tandem hasn't needed CPU lockstep since they dropped their own
proprietary processor architectures, and that's a LONG time ago in
processor history. This isn't a secret, but it may as well be as far
as the trade media and others are concerned.

In modern Tandem boxes, the synchronisation is not at instruction
level or even main-memory access level but conceptually more like "IO
access level" (or maybe process context switch level). The
synchronisation is not on the CPU chip, not even particularly close to
it, but is managed by a piece of complex external logic called the
Logical Synchronization Unit, which doesn't care about instruction-
level lockstep but does care that each processor's operations result
in the same IO with the outside world (and the same context if a
processor swap has to occur). The LSU also does a lot more than that,
which I won't go into here.

The 2006 Oztug presentation at [1] was given by one of Tandem's senior
architects, Hal Massey, and was an excellent intro to the internals of
Tandem boxes over the years. Sadly, it's fallen off the internet and I
haven't kept a copy and nor have I yet been able to find a suitable
replacement. Suggestions welcome for a definitive replacement - but
I'm
not holding my breath.

Don't take my word for it, work it out from first principles. Modern
chips have lots of RAS/availability features which result in many soft
errors being correctable, but errors may have an impact on timing -
sometimes software support is needed at the time or later, or the
error results in visibly different processor behaviour. For example, a
cache error which resulted in a reference to main memory in a chip
which can continue with other processing while it waits for the main
memory reference to arrive. If two chips didn't both have the same
correctable soft error at the same time (what are the odds of that),
they'd not both be executing the same instructions at the same time,
so they'd be out of sync. (Gross oversimplification alert, but
hopefully you get the drift).

hth
john

[1] www.oztug.org/events/2006/AdvancedArchitecture_Massey.pdf - now
vanished, sadly.

[yes this text may seem familiar]

[Richard B. Gilbert]

Metaphor or not, it's a good warning. If you don't have a copy of
the source for critical applications, and the tools needed to build them
or a viable vendor to support them you may be "hanging by a thread".

It is not wise to allow the lessons of 9/11/2001 to be forgotten.
The sky is full of aircraft and the supply of idiots never seems to run
short!

Can YOU do the Merrill-Lynch trick? They were off line for a whole four
minutes and did not lose a single transaction or a byte of data!
I hate to think what it must have cost but not spending that money would
have cost far more.

One company lost seventy percent of its staff! Think "corporate
lobotomy"! Could YOUR company survive a loss like that?

[Richard B. Gilbert]

Off with his head!

[seasoned_geek]

On Mar 21, 2:53 pm, John Wallace <johnwalla...@yahoo.co.uk> wrote:
> The increasing use of HYPErvisors on AMD64 and elsewhere may make IT
> people increasingly conscious of things like unauthorised privilege
> escalation and information leakage. Or may not.

Still, one would want to port to an AMD CPU not a CPU from has been
chip maker Intel. The AMD quad cores rock and are already 128-bit.

Itanic was simply HP and Intel trying to force VMS users to pay for
their multi-million (multi-billion?) dollar boondoggle.

I still expect 2 things to happen.

1) HP to make yet another appearance before yet another Congressional
committee.
2) HP being forced into either the Open Source release or (more
likely) the sale of OpenVMS. I'm 80% certain the buyer will come from
China if the platform is sold.

[Marven Lee]

Sprag wrote:

>Bob Koehler wrote:
>> Intel. 64 and IA-32 Architectures
>> Software Developer.s Manual
>> Volume 3A:
>> System Programming Guide, Part 1
>>
>> "The processor.s segment-protection mechanism recognizes 4 privilege
>> levels, numbered from 0 to 3."
>
> Yep, for segemented 32 bit mode x86 has 4 levels. They don't map
> directly to the vax levels, but there are 4 of them. In any case, in
> x86-64 there are two levels because it doesn't use segmentation --
> just page-level protection.

It's possible to implement more than 2 privilege levels in software
on systems that have only 2 privilege levels using a form of ring
compression and multiple page directories.

Let's say you had an address space with 4 rings.

--- 4gb
kernel
--- 3gb
ring 1
--- 2gb
ring 2
--- 1gb
ring 3
--- 0gb

Using 3 page directories you can have them mapped as:

Page Dir 1 - maps kernel (supervisor) + rings 1,2,3 (user)
Page Dir 2 - maps kernel (supervisor) + rings 2,3 (user)
Page Dir 3 - maps kernel (supervisor) + ring 3 (user)

In effect rings 1, 2 and 3 always run in user-mode, compressed
into a single hardware protection ring.

2 system calls in the kernel, call() and return() are used
to call into an return from a more privileged ring, implementing
a call-gate like mechanism and performing permission checks
before switching page directories and returning into the new
ring.

Of course it is more expensive than doing it in hardware,
you have the cost of entering and leaving the kernel each
time a call() and reply() system call is made as well as the
overhead of switching page directories.


--
Marv

[JohnF]

That was Cantor-Fitzgerald, where I had a contract from 1995-1997,
see http://www.forkosh.com/resume.html?cf1195 for details.
They had vms (on vax) at that time. Managers (and many traders)
were on high floors, where we had meetings every morning on 104.
But us peon computer contractors were generally cubicled on 30-33.
Everyone there (that I knew of) made it out on 9/11. I called a few weeks
later to volunteer some free time if they needed help picking up pieces.
But they had transferred much of the NY work to their London offices.

[Paul Sture]

You might want to consider this:

<http://tinyurl.com/3thwyvm>

'In China, business travelers take extreme precautions to avoid cyber-
espionage

...

Though no country was named, "it was really directed at countries like
China and Russia," Brenner said in a recent interview.

He based his 2008 warning on cases in which Chinese malware was remotely
inserted into cellphones; the malware then infected computer servers in
the United States. He said the networks in every major hotel are
monitored by Chinese security agencies.'


--
Paul Sture

[JF Mezei]

John Reagan wrote:

> Any more fault tolerant than the Itaniums used by NSK today?

I was under the impression that HP did build fault tolerant itaniums for
NSK. Is that not the case ?

[JF Mezei]

John Wallace wrote:

> Tandem hasn't needed CPU lockstep since they dropped their own
> proprietary processor architectures,

But building a fault tolerant system is much more than "lockstep". There
are many hardware designs (dual power, dual fans, dual disk controllers
etc etc).


Are you saying that NSK now runs on the same systems/model numbers as
HP-UX and VMS ?

[John Reagan]

"JF Mezei" wrote in message

news:4f6e15e0$0$463$c3e8da3$4db3...@news.astraweb.com...

Not that I'm aware of. Same chips, same disks, same memory, etc. The boxes
may have some additional RAS features but I think it is more about the
bundled support that comes with them. I'm not an expert however. I do know
that the Itanium chips are the same.

[JF Mezei]

John Reagan wrote:

> bundled support that comes with them. I'm not an expert however. I do know
> that the Itanium chips are the same.

The chips are but a small part of the "NSK" equation. Back in the days
of Tandem, their boxes had a lot of hardware features for not only
redundnacy, but also hot swappability of components whihout having to
stop the whole system.

disk drives were dual pathed for instance, and there were 2 controllers
for the disks.

The interconnects between systems were also quite different to allow for
memory exchanges and internode transactions etc.


Looking at the HP site, it appears HP still has NSK specific servers,
but the web pages are devoid of any real details on how they differ from
the "standard" IA64 servers for HP-UX and VMS.



http://h20223.www2.hp.com/NonStopComputing/cache/307953-0-0-0-121.html

Consider how different the VAXft was from normal VAXen.


The NSK software and hardware might be sufficiently unique that customer
would demand HP port NSK to x86 and build x86 servers with fault
tolerance features for NSK to run on.

HP even has a video on Nonstop:
http://h20621.www2.hp.com/video-gallery/us/en/adc2060c6ef0fd43d853202cbcc2985efefe93c8/r/video

They even pitch NSK as a solution for healthcare. (no mention of VMS there).


Looks to me like NSK might survive beyond the death of IA64.

[je...@virtual-vax-alpha.com]

On Mar 23, 7:36 pm, onedbguru <onedbg...@yahoo.com> wrote:
>
> Sadly, I am not sure I would be that generous... Even though it still runs my home web server and offsite backups for a long-time customer who uses it daily - I am not sure what I will do when their DS10 dies as it has been running 24x7 since 1999 when it replaced a MVII that ran for equally as long. The custom app was "migrated" via VEST because the developer did not appear to keep the entire app source code on the customer system and subsequently was hit by a bus and there was no good backup before the old system died - except for the executables and some of the source code
>

Have you considered emulation? You can run a virtual VAX or Alpha (or
both at the same time, if you wish) on just about any relatively
recent x86 (x86-64 for Alpha) system, including consumer desktops or
laptops. Even modest PC hardware configurations can provide better
(often much better) performance than desktop or deskside VAX or Alpha
systems with much less power consumption and heat generation. VAX/
Alpha virtualization won't be the right fit for everyone, of course,
but in many cases it can provide the best of both worlds - the
benefits of modern hardware while retaining the stability of your
software enviuronment - with a relatively quick and inexpensive
migration path.

Disclosure: I sell these emultor products. I also use them because I
like running VMS and they're much cheaper and easier to maintain than
15+ year old hardware. And I no longer have the patience to wait for
a real MVII, 3100, or 4100.

[JF Mezei]

je...@virtual-vax-alpha.com wrote:

> systems with much less power consumption and heat generation. VAX/
> Alpha virtualization won't be the right fit for everyone, of course,

SimH causes one core of an x86 to run at 100% all the time to emulate
the vax. A Mac Pro computer running at 100% consumes about as much
power as a DS10L.

If SimH could "capture" the idle loop and sleep the process instead,
then power consumption might be down, but not that much.

[John Wallace]

As John Reagan already said, not on the same HP model numbers as VMS
and HP/UX boxes, but on the same CPU chips. Contrary to some writeups
elsewhere in the past, no "lockstep CPUs" or lockstep memory are
needed - not at instruction level anyway.

The fault tolerance in modern NSK (ie in NonStop Advanced Architecture
systems) is provided largely by "logical synchonisation units" which
compare the results of chunks of calculations before they are written
to the outside world (disk, network, etc); they do not compare the
timing and results of individual instructions (that would not be
sensible in modern hardware).

Obviously that is a massive oversimplification. For more detail, see
what you can find to helpfully read about NonStop Advanced
Architecture and (as mentioned in my earlier post) Logical
Synchronisation Units.

As also mentioned in my earlier post, the Hal Massey (VP of Tandem)
presentation to OzTUG in 2006 which was the best I had found on the
subject, sadly seems to have vanished, I didn't keep a copy, and I
haven't found anything nearly as helpful anywhere else. Suggestions
for substitutes most welcome.

[John Wallace]

JF, have you tried the SIMH "SET CPU IDLE=VMS" command (as written up
in various places on the Internet) and found it wanting, or were you
just unaware of it?

In a commercial setup rather than hobbyist setup, a far greater
concern than using one of the multiple cores [often unnecessarily]
provided in many modern Window boxes would likely be the reliability
and availability of the underlying OS in comparison with the
reliability and availability which led to the choice (and retention)
of VMS.

[Howard S Shubs]

In article <00ABED1D...@SendSpamHere.ORG>,

Don't forget the MASSBUS. It strikes me (ha!) as being more MASSive.

--
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

[Johnny Billquist]

The cables certainly are... :-)

Johnny

[VAXman-]

In article <jkpldl$m3p$2...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>On 2012-03-26 03.19, Howard S Shubs wrote:

>The cables certainly are... :-)

ROFL. Those were pipes, not cables!

[Johnny Billquist]

On 2012-03-26 15.28, VAXman- @SendSpamHere.ORG wrote:

> In article<jkpldl$m3p$2...@Iltempo.Update.UU.SE>, Johnny Billquist<b...@softjar.se> writes:
>> On 2012-03-26 03.19, Howard S Shubs wrote:
>>> In article<00ABED1D...@SendSpamHere.ORG>,
>>> VAXman- @SendSpamHere.ORG wrote:
>>>
>>>> In article<snn049-...@news.sture.ch>, Paul Sture<pa...@sture.ch> writes:
>>>>> On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:
>>>>>> Literally hit by a bus??? If ever there was a metaphor...
>>>>>
>>>>> Hit by a Q-bus, I assume. :-)
>>>>
>>>> or a UNIbus... or a BI bus... or an XMI bus... or a PCI bus... :)
>>>
>>> Don't forget the MASSBUS. It strikes me (ha!) as being more MASSive.
>>
>> The cables certainly are... :-)
>
> ROFL. Those were pipes, not cables!

You could almost think so, except they were flexible, for some
definition of "flexible". :-)

It was/is hell to pull them into a cabinet and maneuver them in place
for the connector. A nice feature was that the connector could be set in
three different angles to the cable. That helped a lot.

Johnny

[Jerry Eckert]

On Mar 25, 3:48 am, John Wallace <johnwalla...@yahoo.co.uk> wrote:
> On Mar 25, 6:40 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
> > je...@virtual-vax-alpha.com wrote:
> > > systems with much less power consumption and heat generation. VAX/
> > > Alpha virtualization won't be the right fit for everyone, of course,
>
> > SimH causes one core of an x86 to run at 100% all the time to emulate
> > the vax.  A Mac Pro computer running at 100% consumes about as much
> > power as a DS10L.
>
> > If SimH could "capture" the idle loop and sleep the process instead,
> > then power consumption might be down, but not that much.
>
> "If SimH could "capture" the idle loop"
>
> JF, have you tried the SIMH "SET CPU IDLE=VMS" command (as written up
> in various places on the Internet) and found it wanting, or were you
> just unaware of it?
>

vtAlpha

[Jerry Eckert]

The vtAlpha Eco-App (not to be confused with an ECO-App) does just
this. The Eco-App is presently available for OpenVMS; the web site
indicates a Tru64 version is under development.

[Jerry Eckert]

On Mar 25, 3:48 am, John Wallace <johnwalla...@yahoo.co.uk> wrote:
>

> In a commercial setup rather than hobbyist setup, a far greater
> concern than using one of the multiple cores [often unnecessarily]
> provided in many modern Window boxes would likely be the reliability
> and availability of the underlying OS in comparison with the
> reliability and availability which led to the choice (and retention)
> of VMS.

If one dedicates a box to the emulation applications, which is the
recommendation of the vendors, many of the Windows services can be
disabled. This provides a significant improvement in the reliability
of the underlying OS. Since Windows network connectivity is for
management only, in most cases it should be possible to isolate it
from general network traffic, reducing exposure to the network
security vulnerabilities.

Another option is not to run the emulator under Windows. vtAlpha's
bare metalapproach, which is a bundled Linux kernel, works well
because the underlying OS is shipped stripped down and tested with the
application; there is no issue with OS upgrades applied on-site
introducing incompatabilities.

[Paul Sture]

On Mon, 26 Mar 2012 09:20:03 -0700, Jerry Eckert wrote:

> vtAlpha's bare
> metalapproach, which is a bundled Linux kernel, works well because the
> underlying OS is shipped stripped down and tested with the application;
> there is no issue with OS upgrades applied on-site introducing
> incompatabilities.

1. Can you point us at price lists for the various flavours of vtAlpha?
2. Are evaluation copies available?
3. Will vtAlpha run inside a virtual machine for initial valuation
purposes?


--
Paul Sture

[John Wallace]

On Mar 26, 1:44 pm, Johnny Billquist <b...@softjar.se> wrote:
> On 2012-03-26 15.28, VAXman- @SendSpamHere.ORG wrote:
>
>
>

> > In article<jkpldl$m3...@Iltempo.Update.UU.SE>, Johnny Billquist<b...@softjar.se>  writes:

> >> On 2012-03-26 03.19, Howard S Shubs wrote:

> >>> In article<00ABED1D.39A43...@SendSpamHere.ORG>,
> >>>    VAXman-  @SendSpamHere.ORG wrote:

>
> >>>> In article<snn049-87o....@news.sture.ch>, Paul Sture<p...@sture.ch>   writes:
> >>>>> On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:
> >>>>>> Literally hit by a bus??? If ever there was a metaphor...
>
> >>>>> Hit by a Q-bus, I assume. :-)
>
> >>>> or a UNIbus... or a BI bus... or an XMI bus... or a PCI bus...  :)
>
> >>> Don't forget the MASSBUS.  It strikes me (ha!) as being more MASSive.
>
> >> The cables certainly are... :-)
>
> > ROFL.  Those were pipes, not cables!
>
> You could almost think so, except they were flexible, for some
> definition of "flexible". :-)
>
> It was/is hell to pull them into a cabinet and maneuver them in place
> for the connector. A nice feature was that the connector could be set in
> three different angles to the cable. That helped a lot.
>
>         Johnny

I had a trip to a vendor in Leeds once, when my then employers were
looking to replace an 11/70 with an 11/780 (UK readers may know the
vendor I mean). The place we went sold "DEC compatible" kit, where
anything that didn't need to come direct from DEC was replaced with
cheaper alternatives (everything from industrial power supplies to
photocopied manuals to disk controllers and drives). Their idea of an
*external* MASSbus cable was what would now be called a rainbow ribbon
(twisted) cable. You could drive a fork truck over the DEC cables (and
more importantly drop a computer room floor tile on them) and they'd
survive. Not so with the "compatible" ones.

[John Wallace]

Oh dear, not that silliness again. Not running Windows may be better
than running Windows, but running a Linux layer underneath the
emulator doesn't make it a "bare metal" emulator.

Why is it so difficult for IT people to be honest these days?

HYPErvisor. With the emphasis on the first four letters.

[JF Mezei]

John Wallace wrote:

> Oh dear, not that silliness again. Not running Windows may be better
> than running Windows, but running a Linux layer underneath the
> emulator doesn't make it a "bare metal" emulator.

Not sure how much of linux is included in that vtAlpha "bare bones". But
it is quite possible to really have a bare metal linux and this is
commonly done for embedded systems, TVs, thermostats, TV decoders etc.

In fact, when you look at the iphone, it's got BDS Unix under the hood
but no command line utilities (and no command line). When you jailbreak
it, the first thing it does is add the ability to access a command line
and load all the standrad unix commands.

[Johnny Billquist]

Yes, and that is not properly "bare metal". Having Linux on which your
emulator runs, means it's running under Linux, not on the bare metal.
How hard can it be?

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Simon Clubley]

On 2012-03-26, JF Mezei <jfmezei...@vaxination.ca> wrote:
> John Wallace wrote:
>
>> Oh dear, not that silliness again. Not running Windows may be better
>> than running Windows, but running a Linux layer underneath the
>> emulator doesn't make it a "bare metal" emulator.
>
> Not sure how much of linux is included in that vtAlpha "bare bones". But
> it is quite possible to really have a bare metal linux and this is
> commonly done for embedded systems, TVs, thermostats, TV decoders etc.
>

In the embedded world, bare metal has a specific meaning. When your
application is directly addressing the hardware it's running on
without any operating system between the application and the hardware,
the application is running in bare metal mode.

When your application is talking to the hardware via a operating system
supplied API, that is not bare metal mode.

One specific example: one of the boards in front of me is a Atmel SAM7S256
board (this one: http://olimex.com/dev/sam7-h256.html in case you are
interested.) When my application directly talks to the hardware registers
on this board and handles the interrupts directly, then it's running in
bare metal mode.

If I write a BSP for a RTOS and modify the same application to run on this
board under that RTOS, then the application is no longer running in bare
metal mode.

If there's a cut down Linux between your application and the hardware,
then that application is not running in bare metal mode. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[JF Mezei]

Johnny Billquist wrote:

> Yes, and that is not properly "bare metal". Having Linux on which your
> emulator runs, means it's running under Linux, not on the bare metal.
> How hard can it be?

Except for IBM's LPARS (or whatever it is called) and Galaxy/Wildfire
class Alphas, are there hypervisors that allow multiple instances of an
OS directly on the hardware without some sort of host operating system ?

In the case of HP, the hypervisor they use on IA64 runs an instance of
HP-UX which then hosts other instances as glorified applications.

Anyone know what VMware really is ? It wouldn't susprise me if it had
linux under the hood.

Windows' offering is of course based on windows.

[Jan-Erik Soderholm]

But Linux runs on "bare metal". And if that part is builtin in whatever
the developer calles "the product", then what ? Doesn't "the product" then
run on "bare metal"? Yes, one component of "the product" is some parts
usualy called "Linux", but so what ? Why should the customer/user care ?

The customer buys something called "vtAlpha" that can be runed on a
new "bare metal" box without installing anything else before. Fine.

In the same way, if someone buys your SAM7 "application" with a
builtin runtime version of a RTOS, he could get a "bare metal"
sam7-h256 board from Olimex and run it on.

The term "bare metal" is more how the user/customer looks at it.

If the user can install product "X" without pre-installing anything
else, product "X" runs on "bare metal". Doesn't matter a bit (to the
customer) what product "X" is built from.

Jan-Erik.









> Simon.
>

[Michael Unger]

On 2012-03-26 22:19, "Simon Clubley" wrote:

> [...]

>
> If I write a BSP for a RTOS and modify the same application to run on this
> board under that RTOS, then the application is no longer running in bare
> metal mode.

I would suppose running a RTOS instead of Windows as the "base layer"
would be a real benefit, even if it is _not_ a "bare metal" solution.

> [...]

Michael

--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

[John Wallace]

Well yes, any piece of smart modern consumer electronics very likely
bases its software on a custom Linux kernel, and busybox (look it up
if you don't already know it), and a few other pieces of application-
specific software. Your TV, your set top box, your cable/DSL router,
your NAS box, your media centre, etc, as well as the obvious
smartphones etc. Plus all kinds of professional kit not widely seen.

Do any of these vendors running their software on top of a Linux see
any reason to mislead (and irritate and thus discourage) their
potential customers by meaninglessly saying their application software
is running in "bare metal" mode?

Don't get me wrong, things like VMware and QEMU look like marvellous
pieces of software, as probably are the various PDP11 and VAX and
Alpha emulators (the PDP11 in JavaScript from the author of QEMU,
booting Unix V6 from a web page, is particularly mindblowing).

But none of them are "bare metal" software, and no sensible person
would to attempt to describe them as such, whatever the "industry
standard" usage of the term may have deteriorated to.

Bare metal HYPErvisor. The emphasis is on the first syllable.

[Jerry Eckert]

> HYPErvisor. With the emphasis on the first four letters.- Hide quoted text -
>
> - Show quoted text -

The term "bare metal" is obviously from the user's perspective -- they
provide the appropriate hardware, no OS required.

Something has to provide the OS services: either the application can
bundle an existing OS (or the necessary portions of an OS), or the
application developers can write the code themselves. The latter is
obviously not feasible from either economic or reliability
perspectives. Anyone who understands the technology should understand
this.

[John Wallace]

The appropriate hardware for VMS is documented on the VMS SPD, isn't
it?

[Jerry Eckert]

On Mar 26, 3:19 pm, Simon Clubley <clubley@remove_me.eisner.decus.org-

Earth.UFP> wrote:
>
> In the embedded world, bare metal has a specific meaning. When your
> application is directly addressing the hardware it's running on
> without any operating system between the application and the hardware,
> the application is running in bare metal mode.
>

vtAlpha isn't targeted at embedded systems developers; I don't see why
one would expect the vendor to adhere to the terminology used in a
completely different market segment. The term "bare metal", as used
by vtAlpha, accurately describes the nature of the product from the
host system administrator's perspective -- they provide a box with no
OS and install the application product.

[John Wallace]

Yes various directly-bootable flavours of VMware have (historically)
had Linux under the hood. If I remember rightly they have ended up in
court because they weren't sticking to the licence (sorry, can't find
details right now).

I think as a result of those legal cases, VMware now runs on top of
something allegedly home grown which allegedly isn't Linux (so no GPL
to worry about) but from the bits I've seen written about, to anyone
with a bit of a clue it looks remarkably similar to what a kernel code
writer would see as Linux.

The difference between genuine "bare metal" and "thin OS" may matter
(not to everyone, but to some people). To some people it may matter
from a legal point of view, as VMware found out. And to some it may
matter from a practical point of view. E.g. to customers who are
retaining VMS because of its history of stability, when you put it on
top of a layer that introduces its own bugs and vulnerabilities. OK a
thinner layer than Windows, with fewer bugs than Windows, but not an
invisible layer.

The "not really bare metal" approach gives customers the flexibility
to install their VMS-machine emulator on a commodity box on which the
"not really bare metal" OS will almost certainly run OK much of the
time, but the "not really bare metal" OS will almost certainly not
have been tested and qualified to the level people used to expect from
VMS.

This "not really bare metal" OS will (presumably, as it's a thin
layer) not have the error recovery and diagnosis features which VMS
users have come to expect, right? If an intermittent disk error
occurs, how is it diagnosed? VMS managers running VMS on real hardware
know how. What happens in this environment, is there an error log in
the "not really bare metal" OS? Or does that kind of diagnosis in this
kind of environment require telepathetic skills?

There are lots of cases running simple legacy VMS apps where this kind
of stuff won't matter. Fine. But VMS often lives on in more complex
cases too, where it might matter more than is being admitted...

[Keith Parris]

On 3/24/2012 7:38 AM, John Wallace wrote:
> On Mar 24, 12:45 pm, "John Reagan"<johnrrea...@earthlink.net> wrote:
>> "JF Mezei" wrote in message
>>
>> news:4f6d5a90$0$2201$c3e8da3$4605...@news.astraweb.com...
>>
>>> I was just thinking.
>>> If HP were to produce fault tolerant 8086s for NSK, those boxes could
>>
>> Any more fault tolerant than the Itaniums used by NSK today?
>
> Exactly.

>
> Tandem hasn't needed CPU lockstep since they dropped their own

> proprietary processor architectures, and that's a LONG time ago in
> processor history. This isn't a secret, but it may as well be as far
> as the trade media and others are concerned.
>
> In modern Tandem boxes, the synchronisation is not at instruction
> level or even main-memory access level but conceptually more like "IO
> access level" (or maybe process context switch level). The
> synchronisation is not on the CPU chip, not even particularly close to
> it, but is managed by a piece of complex external logic called the
> Logical Synchronization Unit, which doesn't care about instruction-
> level lockstep but does care that each processor's operations result
> in the same IO with the outside world (and the same context if a
> processor swap has to occur). The LSU also does a lot more than that,
> which I won't go into here.
>
> The 2006 Oztug presentation at [1] was given by one of Tandem's senior
> architects, Hal Massey, and was an excellent intro to the internals of
> Tandem boxes over the years. Sadly, it's fallen off the internet and I
> haven't kept a copy and nor have I yet been able to find a suitable
> replacement. Suggestions welcome for a definitive replacement - but
> I'm not holding my breath.

> [1] www.oztug.org/events/2006/AdvancedArchitecture_Massey.pdf - now
> vanished, sadly.

I see the session description for Hal Massey's session at Archive.org:
http://web.archive.org/web/20060716110540/http://www.oztug.org/events/2006/Techsessions.cfm

"NonStop Advanced Architecture for Integrity NS Server, Hal Massey, HP

The NonStop Advanced Architecture (NSAA) is a new offering in the
NonStop world. It's so new that we are finding new ways to describe it,
new aspects of its advantages, and positve feedback from customers who
are utilizing it in their applications on Integrity NS-series servers.
The fundamentals that the NonStop division is famous for are showing up
in exciting new forms and functions. This is the session to learn about
how NSAA can make a difference in your world."

Does sound interesting. Maybe some of these will be helpful:

HP NonStop Advanced Architecture web page with FAQs and white paper:
http://h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html

NonStop Advanced Architecture, System Configuration and Site Planning,
Bob Kossler
ftp://ftp.hp.com/pub/nonstop/ccc/2005/jun0905.pdf

The NonStop Advanced Architecture Value Proposition: HP Integrity
NonStop Server Availability Compared to NonStop S-series Server, Bob Kossler
ftp://ftp.hp.com/pub/nonstop/ccc/2005/sep1505.pdf

Data Integrity in HP NonStop Servers
http://www.cs.uiuc.edu/class/sp06/cs523/nonstop-selse06.pdf

NonStop Advanced Architecture
http://www.cse.chalmers.se/~davidwh/eac/papers/karlsson5.pdf

NonStop Servers - The future (from 2003)
http://www.suntug.org/Articles/SE_RUG_Roadshow_V3_June_203.pdf

[John Wallace]

On Mar 26, 10:28 pm, Keith Parris <keithparris_deletet...@yahoo.com>
wrote:

> > [1]www.oztug.org/events/2006/AdvancedArchitecture_Massey.pdf- now
> > vanished, sadly.
>
> I see the session description for Hal Massey's session at Archive.org:http://web.archive.org/web/20060716110540/http://www.oztug.org/events...

>
> "NonStop Advanced Architecture for Integrity NS Server, Hal Massey, HP
>
> The NonStop Advanced Architecture (NSAA) is a new offering in the
> NonStop world. It's so new that we are finding new ways to describe it,
> new aspects of its advantages, and positve feedback from customers who
> are utilizing it in their applications on Integrity NS-series servers.
> The fundamentals that the NonStop division is famous for are showing up
> in exciting new forms and functions. This is the session to learn about
> how NSAA can make a difference in your world."
>
> Does sound interesting. Maybe some of these will be helpful:
>
> HP NonStop Advanced Architecture web page with FAQs and white paper:http://h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html
>
> NonStop Advanced Architecture, System Configuration and Site Planning,

> Bob Kosslerftp://ftp.hp.com/pub/nonstop/ccc/2005/jun0905.pdf

>
> The NonStop Advanced Architecture Value Proposition: HP Integrity

> NonStop Server Availability Compared to NonStop S-series Server, Bob Kosslerftp://ftp.hp.com/pub/nonstop/ccc/2005/sep1505.pdf

>
> Data Integrity in HP NonStop Servershttp://www.cs.uiuc.edu/class/sp06/cs523/nonstop-selse06.pdf
>

> NonStop Advanced Architecturehttp://www.cse.chalmers.se/~davidwh/eac/papers/karlsson5.pdf

>
> NonStop Servers - The future    (from 2003)http://www.suntug.org/Articles/SE_RUG_Roadshow_V3_June_203.pdf

Good stuff on that list, but the Hal Massey one is/was betterer (or so
my subjective memory tells me).

You might want to add (from 2008, so relatively recent):
http://www.availabilitydigest.com/public_articles/0308/ns_blades.pdf

[JF Mezei]

John Wallace wrote:
>
> You might want to add (from 2008, so relatively recent):
> http://www.availabilitydigest.com/public_articles/0308/ns_blades.pdf

This is the first document that provides real (non marketing
gobbledeegook) information. Many thanks.

I am interested thought in finding out what is different between the
C-class chassis/blades used for NonStop and the ones uses for HP-UX/VMS.

are the blade cards with CPU the same ? if not, what is different ?

It *looks* like HP is using its standard C class enclosures and blade
boards with slightly different firmware and some peripheral modules to
add the management and fault detection logic. Is that the case ?



Also, out of curiosity, would Tandem customers really want to take 4
different cabinets with 4 CPUs each and merge them into a single Class
blade system with all 16 processors in one box ? Seems to me that
having all their eggs in one blade enclosure seems more risky than
having at least 2 separate systems.

[Johnny Billquist]

That is a pretty meaningless definition. I could then just as well say
that my Firefox runs on bare metal.

It makes a big difference in that the underlying layer can and will hide
away and abstract away some parts of the underlying details.
That is the whole point of the underlying layer. Abstract away gritty
details of the hardware so that your software can be written in a more
general way and work on various different types of hardware.
But it comes at a costs. I no longer knows exactly what happens at the
hardware layer. That is handled by the middleware. As someone else
mentioned - what about hardware errors, as an example. I no longer get
reports of those, nor can my system perform actions to such errors. I'm
just presented with a preprocessed result to whatever request I made.
And if your expectations are that you are on the bare metal, then you
probably also expect all kind of potential hardware problems to be
visible. To *your* emulator, and not only to the underlying operating
system...

[Johnny Billquist]

Cool. So I can just call my target audience "foobars", and then I can
redefine known terms to mean what I want? Sounds like an excellent
opportunity to sell non-stop servers, machines that produce gold, and
oracle databases here...

[Simon Clubley]

On 2012-03-27, Johnny Billquist <b...@softjar.se> wrote:
> On 2012-03-26 23:11, Jerry Eckert wrote:
>> On Mar 26, 3:19 pm, Simon Clubley<clubley@remove_me.eisner.decus.org-
>> Earth.UFP> wrote:
>>>
>>> In the embedded world, bare metal has a specific meaning. When your
>>> application is directly addressing the hardware it's running on
>>> without any operating system between the application and the hardware,
>>> the application is running in bare metal mode.
>>>
>> vtAlpha isn't targeted at embedded systems developers; I don't see why
>> one would expect the vendor to adhere to the terminology used in a
>> completely different market segment. The term "bare metal", as used
>> by vtAlpha, accurately describes the nature of the product from the
>> host system administrator's perspective -- they provide a box with no
>> OS and install the application product.

I would expect it because the terminology is not tied to the market
segment, but is tied to the technology in use, regardless of the target
market.

We don't change the definition of operating system (for example) to mean
different things depending on the market segment. We include different
capabilities in the operating system depending on the market segment
but we don't change the definition itself.

Furthermore, how does the use of this hidden layer affect the realtime
capabilities of the emulation it provides ? If people are told it's bare
metal, then they may expect a much more deterministic response time than
they would expect from something running on a hidden OS.

In virtualisation there have been security issues with the guest operating
system been able to break through the virtualisation layer and compromise
the security or functionality of the virtualisation environment. Does
this hidden Linux layer also pose security risks, if say, a path exists
from the network to the Linux layer and a remote exploit is discovered in
the underlying Linux version ?

It would seem to me that if the Linux layer is network accessible then it
would have to be updated on a regular basis for any security issues, just
as my normal Linux servers and clients have to be.

If the box is been sold as a black box, is this updating done (assuming of
course the underlying functionality causes such updating to be required) ?

>
> Cool. So I can just call my target audience "foobars", and then I can
> redefine known terms to mean what I want? Sounds like an excellent
> opportunity to sell non-stop servers, machines that produce gold, and
> oracle databases here...
>

I agree. If the use of the term "bare metal" doesn't mean anything to
someone outside of the embedded world, then why is it used in the
advertising material for these products as a positive selling point ?

[Paul Sture]

On Mon, 26 Mar 2012 11:30:03 -0700, John Wallace wrote:

> I had a trip to a vendor in Leeds once, when my then employers were
> looking to replace an 11/70 with an 11/780 (UK readers may know the
> vendor I mean). The place we went sold "DEC compatible" kit, where
> anything that didn't need to come direct from DEC was replaced with
> cheaper alternatives (everything from industrial power supplies to
> photocopied manuals to disk controllers and drives). Their idea of an
> *external* MASSbus cable was what would now be called a rainbow ribbon
> (twisted) cable. You could drive a fork truck over the DEC cables (and
> more importantly drop a computer room floor tile on them) and they'd
> survive. Not so with the "compatible" ones.

Chuckle. As one customer found out the hard way, when you have fork
lifts rushing around you need to think of redundant comms gear around
your factory floor.

IBM also had very robust cables, some would say over-engineered, but then
IBM could get away with the prices.

Yes, your description of that UK vendor leaves me in no doubt who they
were. They even had a separate company devoted to selling the original
DEC kit that had been separated from bought systems.

--
Paul Sture

[Bob Koehler]

In article <4f70d44f$0$1746$c3e8da3$92d0...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>
> Anyone know what VMware really is ? It wouldn't susprise me if it had
> linux under the hood.

I think VMware is a product line. I know we're using it to host
WXP on top of Mac OS. Since they're both Intel user mode code on
WXP simply runs as user mode code on the CPU. Adds I hear for VMware
imply other, quite different products.

For us, VMware has to intercept WXP access to the underlying hardware,
and simulate interrupts from hardware, but I don't suspect anyone of
tossing a whole Linux kernel in there just for that.

[Bob Koehler]

In article <162d0e52-99d4-4859...@er9g2000vbb.googlegroups.com>, John Wallace <johnwa...@yahoo.co.uk> writes:
>
> The appropriate hardware for VMS is documented on the VMS SPD, isn't
> it?

Yes. I haven't looked for it in the SPD, but at least one VAX emulator
is also officially supported, if running on Windows on HP hardware.

[Bob Koehler]

In article <fefb398b-b9ee-439f...@gw9g2000vbb.googlegroups.com>, John Wallace <johnwa...@yahoo.co.uk> writes:
>
> This "not really bare metal" OS will (presumably, as it's a thin
> layer) not have the error recovery and diagnosis features which VMS
> users have come to expect, right? If an intermittent disk error
> occurs, how is it diagnosed? VMS managers running VMS on real hardware
> know how. What happens in this environment, is there an error log in
> the "not really bare metal" OS? Or does that kind of diagnosis in this
> kind of environment require telepathetic skills?

It's been a long time since the disks themselves have hidden that
information from VMS.

A thin layer of anything could mess up VMS' real-time capabilities
mightily. But the owner has long since stopped selling VMS to any
market that cares.

[Jan-Erik Soderholm]

Yes, if you could get a packed version of Firefox that includes
everything it needs to be installed on a "bare metal" box from
the shelf. You can't. You need to have a system with an OS up
and running to be able to install Firefox.

If one would build a combined Firefox/Linux distribution (where
Linux was more or less hidden from the user), then this would be
a Firefox kit that installs and runs on a "bare metal" box directly.

The rest below is "just" technical details that most users
just couldn't care less about anyway.

Jan-Erik.

[Bob Koehler]

In article <jkqkjv$p1i$1...@news.albasani.net>, Jan-Erik Soderholm <jan-erik....@telia.com> writes:
>
> But Linux runs on "bare metal". And if that part is builtin in whatever
> the developer calles "the product", then what ? Doesn't "the product" then
> run on "bare metal"? Yes, one component of "the product" is some parts
> usualy called "Linux", but so what ? Why should the customer/user care ?

Because the Linux kernel can't handle some of the hard real-time
applications that the user might have.

[Jan-Erik Soderholm]

But that is a completly different question.
It has nothing to do with the "bare metall" discussion.

[Johnny Billquist]

I think it has a lot of relevance if your "bare metal" actually
introduce a non-deterministic middle layer to your emulation.

The bare metal actually, by definition, do not have this property. So I
would expect something that runs on the bare metal to retain that
property, which to some is a very much wanted property. By falsely
claiming that a product is running on the bare metal, when it actually
is running on top of an operating system, they are in fact doing false
marketing, and implicitly claim properties of their system which they
can not back up.

"Bare metal" is not just a word... It *means* something.

Johnny

[Jan-Erik Soderholm]

Windows runs on "bare metal", still many would claim that Windows
is non-deterministic.

I could easily write some simple code that runs on "bare metal"
that would be (by design!) *very* non-deterministic... :-)

No, the only thing rellevant here is if you need to add any software
yourself (such as an "OS") before installing the actual "product".

[Keith Parris]

On 3/24/2012 11:40 PM, JF Mezei wrote:
> SimH causes one core of an x86 to run at 100% all the time to emulate
> the vax. A Mac Pro computer running at 100% consumes about as much
> power as a DS10L.
>
> If SimH could "capture" the idle loop and sleep the process instead,
> then power consumption might be down, but not that much.

SimH can detect the idle loop and throttle back. Hoff has a great
write-up on this at http://labs.hoffmanlabs.com/node/931

[John Wallace]

On Mar 27, 4:42 pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:

> In article <4f70d44f$0$1746$c3e8da3$92d0a...@news.astraweb.com>, JF Mezei <jfmezei.spam...@vaxination.ca> writes:
>
>
>
> > Anyone know what VMware really is ? It wouldn't susprise me if it had
> > linux under the hood.
>
>    I think VMware is a product line.  I know we're using it to host
>    WXP on top of Mac OS.  Since they're both Intel user mode code on
>    WXP simply runs as user mode code on the CPU.  Adds I hear for VMware
>    imply other, quite different products.
>
>    For us, VMware has to intercept WXP access to the underlying hardware,
>    and simulate interrupts from hardware, but I don't suspect anyone of
>    tossing a whole Linux kernel in there just for that.

" I think VMware is a product line."

The VMware brand covers multiple different products. Some of them run
on top of a very visible OS (often but not always Windows).

Some so-called bare metal ones run on top of a "not really bare metal"
OS, not unlike the discussion we're having here. This "not really bare
metal" OS provides facilities such as hardware independence for the
next layer up, remote management, resource allocation, scheduling, and
many of the other things that would normally be regarded as the
territory of a real OS.

The main difference between this and a real OS is that a real OS
usually offers a documented set of generic APIs so that customers can
write their own applications. The API(s) offered by VMware's ESX
family are, as far as I know, intended primarily to support the
management of the ESX product and not (for example) re-implementing
DECburger or All-in-1 or a stock exchange trading system.

[John Wallace]

On Mar 27, 2:47 pm, Jan-Erik Soderholm <jan-erik.soderh...@telia.com>
wrote:

> Johnny Billquist wrote 2012-03-27 12:25:
>
>
>
> > On 2012-03-26 22:46, Jan-Erik Soderholm wrote:
> >> Simon Clubley wrote 2012-03-26 22:19:

> >>> On 2012-03-26, JF Mezei<jfmezei.spam...@vaxination.ca> wrote:
> >>>> John Wallace wrote:
>
> >>>>> Oh dear, not that silliness again. Not running Windows may be better
> >>>>> than running Windows, but running a Linux layer underneath the
> >>>>> emulator doesn't make it a "bare metal" emulator.
>
> >>>> Not sure how much of linux is included in that vtAlpha "bare bones". But
> >>>> it is quite possible to really have a bare metal linux and this is
> >>>> commonly done for embedded systems, TVs, thermostats, TV decoders etc.
>
> >>> In the embedded world, bare metal has a specific meaning. When your
> >>> application is directly addressing the hardware it's running on
> >>> without any operating system between the application and the hardware,
> >>> the application is running in bare metal mode.
>
> >>> When your application is talking to the hardware via a operating system
> >>> supplied API, that is not bare metal mode.
>
> >>> One specific example: one of the boards in front of me is a Atmel
> >>> SAM7S256

> >>> board (this one:http://olimex.com/dev/sam7-h256.htmlin case you are

Probably not that difficult to do with a LiveLinux CD and a bit of
ingenuity. And when you take out the CD, it's gone, nothing to see.

When someone finishes installing a "not really bare metal" HYPErvisor,
it leaves plenty of evidence behind. E.g. something bootable that can
be executed when the hardware powers up.

Moving on: VMS on native hardware is well characterised.

A Linux can have a variety of characteristics depending on the
particular Linux and the particular configuration. Some of these
characteristics (not just the realtime ones) will likely affect the
characteristics of a VMS system running in a "not really bare metal"
environment.

When you say "users" may not care about them, it depends on whether
you mean end users ie non-IT people sitting at VT emulators, or
whether users means the people installing (that word again) the
emulator, the people trying to continue to use VMS to run an important
business application, who may have little vendor support for
diagnosing problems when something occasionally goes wrong at low
level.

[Simon Clubley]

You are missing the point. :-)

You don't get deterministic behaviour simply by running your software
on bare metal; your software has to be designed to have deterministic
behaviour. Running on bare metal is what allows you to maintain that
deterministic behaviour (in the absence of a dedicated RTOS).

In order to guarantee deterministic behaviour on a platform, you need
to make sure that everything about that platform behaves in a predictable
and deterministic manner.

It doesn't matter if your software, in it's native environment, is the
most predictable and deterministic software in the world if it's running
on top of a hidden OS layer which is non-deterministic.

[Paul Sture]

On Tue, 27 Mar 2012 09:42:02 -0600, Bob Koehler wrote:

> In article <4f70d44f$0$1746$c3e8da3$92d0...@news.astraweb.com>, JF
> Mezei <jfmezei...@vaxination.ca> writes:
>>
>> Anyone know what VMware really is ? It wouldn't susprise me if it had
>> linux under the hood.
>
> I think VMware is a product line. I know we're using it to host WXP
> on top of Mac OS. Since they're both Intel user mode code on WXP
> simply runs as user mode code on the CPU. Adds I hear for VMware
> imply other, quite different products.

Yes, VMware has a family of products. The one you are running on Mac OS
X is probably (but not necessarily) VMware Fusion.

It does add its own networking and allows you to talk to peripherals
which are only supported by Windows:

http://www.vmware.com/products/fusion/overview.html

> For us, VMware has to intercept WXP access to the underlying
> hardware, and simulate interrupts from hardware, but I don't suspect
> anyone of tossing a whole Linux kernel in there just for that.

It's probably hosting a virtual disk for the Windows system, easy to back
up, and will have snapshot facilities so you can roll back to a known
good point-

I have used the equivalent (known as VMware Workstation) on Windows and
Linux hosts. I am not sure how much that differs from the Mac version,
but you can seamlessly integrate desktops, make movies of your work adn
so on. VMware also has the means to build comprehensive virtual
networks, handy for those who want to test them out before deploying.

I did find a couple of performance problems with it *for my environment*:

a) It uses its own pagefiles. The advantage here is that you can have
n virtual machines which have total RAM exceeding the amount on
the host system. The drawback for me was that it used these pagefiles
even when I had plenty of real RAM free, and it slowed things up too
much.

b) It has its own allocation algorithms for hosted virtual disks, and
functionality to defragment these. You still have to do any
defragmentation that the Windows virtual machine requires itself
though.

Point a) is what persuaded me to look elsewhere on my hardware, I got
sick of the system grinding to a halt with the disk activity light on
solidly. I chose VirtualBox.

If you have the right combination of disks attached to the host, you can
set your virtual machines to use them as raw devices by their O/S.

I also looked at different Linux file systems when I was looking at VMware
Workstation. I wasn't particularly happy about the performance I got
with any of them*, and believe it or not, I ended up concluding that
Windows as a host provided me with better performance and a more stable
experience.

* I might try this again now that more work has been on of btrfs and XFS.
Those interested in file systems might wish to have a look at a couple of
presentations on these at a recent Australian Linux conference:

"I Can't Believe This is Butter! A tour of btrfs. - Avi Miller"

http://www.youtube.com/watch?v=hxWuaozpe2I

"XFS: Recent and Future Adventures in Filesystem Scalability - Dave
Chinner"

http://www.youtube.com/watch?v=5XDTQLa3NjE

Be ready with the pause button for these videos, as the video editor had
the unfortunate tendency to switch away from the slides before the
speaker had got to every point.

And to get the best enjoyment out of the XFS one, do watch the btrfs one
first so that you understand the bit at the end where he criticies btrfs
performance :-)

--
Paul Sture

[Paul Sture]

On Tue, 27 Mar 2012 17:23:10 +0200, Johnny Billquist wrote:

> I think it has a lot of relevance if your "bare metal" actually
> introduce a non-deterministic middle layer to your emulation.
>
> The bare metal actually, by definition, do not have this property. So I
> would expect something that runs on the bare metal to retain that
> property, which to some is a very much wanted property. By falsely
> claiming that a product is running on the bare metal, when it actually
> is running on top of an operating system, they are in fact doing false
> marketing, and implicitly claim properties of their system which they
> can not back up.
>
> "Bare metal" is not just a word... It *means* something.

Yes, as I pointed out in my other post, my evaluation of VMware
Workstation demonstrated that it introduced substantial amounts of paging
activity which brought my system to its knees. Someone told me it was
possible to switch this off, but only after my evaluation period had
finished. :-(



--
Paul Sture

[Keith Parris]

On 3/26/2012 5:17 PM, JF Mezei wrote:
> Also, out of curiosity, would Tandem customers really want to take 4
> different cabinets with 4 CPUs each and merge them into a single Class
> blade system with all 16 processors in one box ? Seems to me that
> having all their eggs in one blade enclosure seems more risky than
> having at least 2 separate systems.

Multiple boxes can be linked together with ServerNet, so just like an
OpenVMS Cluster customer might want to have at least two chassis for
redundancy, a NonStop customer could have multiple chassis.

[Johnny Billquist]

*Exactly* Which is why you would not want a product like a machine
emulator running on Windows (or Linux, which have the same problem), and
then have someone claim it runs on bare metal, which is not

non-deterministic.

> I could easily write some simple code that runs on "bare metal"
> that would be (by design!) *very* non-deterministic... :-)

Right. Not a problem at all. It is the opposite which is the problem,
and which you cannot do. And which is why running the emulator on top of
an OS instead of on the bare metal is a bad idea, for some.

> No, the only thing rellevant here is if you need to add any software
> yourself (such as an "OS") before installing the actual "product".

No. You are even missing your own point.

Johnny