(After Wirt>
    For those interested in and a little bit of background on Wirt's
thinking(his own words) on the subject of a "MOST" operating system, and
with which I totally concur, please visit our very own archives at:

 http://raven.utc.edu/cgi-bin/WA.EXE?A2=ind9902B&L=hp3000-l&D=0&P=16113 

for a little bit of déjàvu.....


                             Eric Sand
                             [log in to unmask]


> Mark writes exactly what I would have written, and thus I'm going to
> repeat
> it all here again verbatim. Nonetheless, to help make the situation
> perhaps
> just a little clearer, let me also repeat a diagram I included in my first
> posting:
> 
>                   deep
>               philosophical
>                 firewall
>                     .
>       MPE apps      .        Linux apps
>          |          .            |
>          |          .            |
>       MPE O/S    <- . ->     Linux O/S
>          |          .\           |
>          |          . \          |
>          |_____________\_________|
>          |              \
>      Linux kernel        \ file sharing would be
>                            accomplished through
>                            file equations/links
> 
> Let me also point you to the following slides that are on Intel's website
> concerning the ARIES binary emulation of PA-RISC/HP-UX on the IPF (Itanium
> Processor Family)/IA-64 family of processors. Of the forty slides, I
> believe
> these two are the most important:
> 
>      http://www.intel.com/design/itanium/tranhp/sld009.htm
>      http://www.intel.com/design/itanium/tranhp/sld024.htm
> 
> although the slides begin at:
> 
>      http://www.intel.com/design/itanium/tranhp/sld001.htm
> 
> The right-hand column of slide 9 represents the totality of the reasons
> for
> generating a binary compatible PA-RISC emulator. The performance levels
> achieved vs. native PA-RISC performance appear in slide 24, which is
> summarized elsewhere as approximately 30 to 70% of PA-RISC's native mode
> performance.
> 
> If you have the time, I'd recommend looking at all of the slides, of
> course.
> After looking at the slides, the primary question that comes to mind of
> course is why wasn't this option offered CSY? Booting HP-UX can't be all
> that
> much different that booting MPE.
> 
> Wirt Atmar
> 
> 
> ======================================
> 
> Matt Shade ponders:
> > <To preface this, I just want to say that I'm trying to find
> > answers for my own peace of mind. I hate sounding like an old
> > stick in the mud, but I've been having problems coming to
> > grips with reason behind the cause. I'm also sure I'll get
> > flamed big time for this, but I need to get this off my chest.>
> 
> I cannot imagine anyone flaming you for such a well-reasoned and
> thoughtful
> post.
> 
> > Perhaps I'm just dense, or maybe behind a little in the
> > reasoning, but I just can't see the point in an OpenMPE
> > project based on an emulator. Unless it was purely for a
> > teaching tool, or a hobby, or a toy. I don't see an emulator
> > running on top of another OS (linux) running a company's business.
> 
> Well, if I understand Wirt correctly, it is not running on top of Linux,
> it
> uses the Linux kernel.  This is just the most basic of operating system
> services.  The kernel does not include the file system or a shell for
> example.  The point is to use parts of Linux that gives us the portability
> and saves us the time and trouble of writing things like device drivers.
> By
> doing this, we avoid the pain that CSY is experiencing.  I do not imagine
> booting up Linux and then typing MPE.  When you boot, the system would
> mount
> some MPE volume sets and start the PA-RISC emulator as a system service.
> As
> with any Lunix machine, your shell would then start.  Of course our shell
> would be the CI or MPE shell.  This shell would do all of the same
> functions
> that the CI would, system variables, file equations, etc.  The exception
> comes when one goes to run a program.  If the program is an MPE binary,
> the
> PA-RISC emulator executes the program.  If it is a regular Linux program,
> Linux runs it.
> 
> > I keep picturing some MIS director who's been sweating for a
> > couple years, wondering how to migrate all his financial and
> > manufacturing apps off his HP3000s, saying "Whew! Thank god!
> > Now I can just buy a couple high-end PCs, load up linux, and
> > then install MPE on top of them, and I won't have to migrate
> > to a new OS and I can keep my job!"
> 
> Good, that's what I envision too!  (Well, maybe with less sweating...)
> 
> > Yes, that's probably a ludicrous example, but I'm not sure
> > why there would be an OpenMPE if not for those cases.
> > Otherwise, what's the point?
> >
> > <snip> But I
> > can't see how, for example, a company could honestly justify
> > moving from an HP3000 with 300 users to a PC (or Sun box, or
> > HP9000, or whatever) running an MPE emulator on top of linux.
> 
> I can't see how a company could honestly justify moving from an HP3000
> with
> 300 users to Windows NT.  ;-)  But keep in mind that Linux runs on much
> bigger boxes than just high-end PCs 9as well as NT fo the record).  Maybe
> even Superdome... ;-)
> 
> > HP has had a hard enough time expanding or even keeping it's
> > HP3000 customer base. So what makes anyone think that
> > creating an MPE emulator will change that? Or is that even
> > the reason behind OpenMPE? Is the reason just because WE love
> > MPE so much and don't want to see it just fade away? Are we
> > hoping some underground movement will catch on, and soon
> > every linux distribution will include an MPE emulator? (I
> > KNOW that's not the case, but again, I'm just trying to get a
> > feel for it)
> 
> Right now we are in an either/or situation.  Either you run your apps on
> the
> HP3000 or on Linux.  I think the Santa Fe proposal gets you to the point
> where that isn't an issue anymore.  Maybe I have a app that runs great on
> MPE for one job but not another.  Now you can run an MPE app and Linux
> apps
> on the same machine at the same time.  Now we've killed another rap
> against
> the 3000, "I don't want to maintain multiple hardware platforms".  As for
> attracting new developers, you don't have to convert someone to do only
> MPE
> work.  WHEN Image is ready, it will be a welcome change for those who put
> their data in dbm (indexed) files.  IBM is already trying to get users to
> use their journalized file system.  Is the MPE file system better than
> IBM's?  So, yes, I do see a possibility of getting more users on the MPE
> bandwagon.
> 
> >With regards to the feasibility of an emulator, most of you have seen
> what
> I wrote in
> >reply to Wirt's proposed roadmap for OpenMPE.
> <snip />
> > But, IMHO, the amount of performance
> > that would be sacrificed would make the reason for having MPE
> > in the first place go away.
> 
> I am hoping that since there is much less graphics involved, which the
> emulators you mentioned must handle, that the performance issues won't be
> as
> bad.  Of course, I have no clue.
> 
> > Some people have said that the proprietary hardware is
> > exactly what we want to get away from, hence an emulator on
> > top of an OS that runs on multiple hardware platforms. Again,
> > you're sacrificing speed (regardless of the fact that
> > processors and memory are getting cheaper and faster) and
> > reliability for convenience and portability. While I'm all
> > for portability, I wouldn't see that option as a reason to
> > keep my enterprise applications on MPE.
> 
> Are you still running a 9X7 machine?  HP cannot make money when it's
> cheaper
> to drop off support and coast than it is to upgrade.  It's a different
> world
> out there in the hardware arena and we will have to adapt.
> 
> > Why do we like MPE anyway? Stability - OpenMPE's reliability
> > and stability would now stand on the underlying OS and the
> > emulator's interaction with that OS. Performance - just
> > removing MPE from the HP3000 already decreases that, but then
> > placing another layer between MPE and the hardware drops it
> > even further. Image - from what I understand, that's already
> > available on other platforms (Eloquence? I honestly don't know).
> 
> There is some stability in having MPE on the 3000.  But there's a
> different
> kind of instability when tied to a particular vendor's hardware.  (Does
> 11/14 ring a bell?)
> 
> > I'm sure an emulator could be created. I'm sure it could
> > handle all those things everyone likes about MPE, like file
> > equations, build, image, etc. But then what? Advertise it?
> > "You loved MPE...NOw get the next to next best thing!" I see
> > a FEW people wanting to run it, but not the multitudes that
> > some people feel there will be in order to fund and support it.
> 
> I agree, that approach won't work.  They will not come play in our
> sand-box.
> We need to invade their turf and show people how reliable computing really
> works.  It's the kind of marketing we have always wanted to do.  Why just
> go
> out and continue to preach to the choir.  (In my best John Belushi.  "Are
> you with me?  Did we sit back when the German's bombed Pearl Harbor?"
> Shhh,
> he's on a roll... "Let's go!!!"
> 
> > Again, maybe I'm just missing something and need some
> > handlholding to be able to understand it all. I don't want to
> > sound like I'm against anything. In fact, I'd support
> > whatever comes out of all this.
> 
> =======================================
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *