OPENMPE Archives

September 2006

OPENMPE@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Thu, 14 Sep 2006 14:35:21 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
Mark writes: 
> Aren't there products like MP-UX that already do this? IIRC, there is/
> were at least two (and I know that I as well as Stan have our own set
> of "intrinsic" work-a-like that run on various *ix thingies). Aren't
> you re-inventing the wheel here?

Worse than that, the problem with putting MPE into Linux is that there's
really no place for it to go.

Linix/UNIX has a nice separation between the programming API (kernel calls
or C library depending on what level you want to look at), and things like
the implementation of a specific file system.  So it's really easy to
replace, for example, one file system with another.

But for, say, an MPE file system, the problem is that this modularity
doesn't help you because you need to replace *both* the programming API
*and* the file system.

The MPE file system would require things that the Linux kernel has no
concept of, and using that file system would require new programming APIs.

If you suggest the features of an MPE file system to a "UNIX person" they'll
look at you like you're from Mars and patiently explain why having all files
just be a stream of bytes is so superior to something that actually cares
about things like record width.  Chances are good that you'd never get the
Linux kernel people to accept any of the stuff Pete is suggesting, even if
you handed them a complete implementation.

So you're left with a user-mode implementation that would look a lot like
MPUX, and wouldn't get you any of the benefits of being "designed into the
kernel".

Thus I don't think the "add MPE to Linux" strategy is viable, as the host
(Linux) is likely to violently reject the transplant (MPE functionality).

There are two sets of people who want to see MPE thrive (or at least
survive) at the moment.  There are the people who are "homesteading" on the
platform (continuing to use it past HP's "best if used by" date) and there
are people who feel that the world is a poorer place without MPE in it and
who wish they had something other than Windows and Linux to develop on.

The homesteaders are pretty much all set at the moment, as even without new
hardware there is enough "ecosystem" left to support them for many years.
Things like a hardware-simulation emulator may yet turn up before the
hardware they're using today falls apart completely.  Developments like
progress on the OpenMPE front can do nothing by make things better for them.

Unfortunately the people who want MPE to have a life beyond homesteading are
kinda screwed.  Without an HP-sized company fully behind it, you're just not
going to be able to prop up MPE as a viable general-purpose operating system
any more.  But if you look at what you really liked about MPE, it may be
possible to see that what you really want is not MPE, but the *attributes*
of MPE.  Things like simplicity and reliability (the latter generally
following automatically from the former).  MPE provided a limited number of
building blocks for constructing applications where other operating systems
say "oh, look, we have hundreds of ways of doing things, you can have it any
way (or even every way) that you like!".

So, personally, I think if you really want MPE to survive that you'd be
better off either promoting the development of something entirely new that
happens to be designed based on the good ideas that MPE had, or simply
identify what it was about MPE that you liked and learn to use today's tools
in such a way that you get the same benefits.  

Just as a programmer who first learned FORTRAN may tend to write programs
that look very much like FORTRAN even when they move on to other languages,
someone who grew up writing MPE applications should be able to continue to
design and develop applications on Windows or Linux that feel in many ways
like an MPE application.  For example, just because they offer you 1,000
different ways to do something doesn't mean you can't stick to just one.
Don't let them convince you that you don't know anything about designing and
running a business solution!

There's also a third class of people who want MPE to survive.  These are the
people who are effectively saying "please make MPE survive so that I don't
have to learn anything new".  For these people I would say you really need
to get out and learn something new.  You might even have fun :-)

G.

ATOM RSS1 RSS2