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:
Jim Chance <[log in to unmask]>
Reply To:
Jim Chance <[log in to unmask]>
Date:
Thu, 14 Sep 2006 14:47:09 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (160 lines)
Well said. Especially the 9th thru 12 paragraphs.

--- Gavin Scott <[log in to unmask]> wrote:

> 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.
> 


-----------------------------------------------------------------------------------------------------------------------------------
  Seeking PERMANENT employment within a shop that has any of the following: HP3000, Macola, Jobscope, MS SQL in the states of: OH, TN, GA, NC, SC, FL. 
   
  Titles of:
Senior P/A, S/A
MS SQL Admin.
IT Director, Manager, project leader

OR >>>> HP3000 Contract/Consulting anywhere in US. 

Can you help me out?

419-651-6704   or [log in to unmask] 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

ATOM RSS1 RSS2