[Info-vax] Anyone interested in another public access system

[Bill Gunshannon]

In article <49DF7A1A.EB9E7656 at spam.comcast.net>,
	David J Dachtera <djesys.no at spam.comcast.net> writes:
> Bill Gunshannon wrote:
>> 
>> In article <49DD40D5.3F95722D at spam.comcast.net>,
>>         David J Dachtera <djesys.no at spam.comcast.net> writes:
>> > Bill Gunshannon wrote:
>> >>
>> >> In article <49D6D457.A96B7D25 at spam.comcast.net>,
>> >>         David J Dachtera <djesys.no at spam.comcast.net> writes:
>> >> > [snip]
>> >> > Need I go on?
>> >>
>> >> No, when your measure of modern computing is whatever is VMS-style
>> >> I guess anything that isn't VMS is deficient.
>> >
>> > What would you prefer as a "gold standard" against which to measure?
>> 
>> I'm not arguing for any standard.  I am merely pointing out that if you
>> make VMS the standard, then any OS other than VMS is going to be rather
>> deficient because VMS is VMS and every other OS is not. 
> 
> ...and, of course, the counter-argument could be made about <mumble>
> features not being available in non-<mumble>.

Not having something that no one wants is not a shortcoming.

> 
>> That's kind of
>> like saying the standard for good literature is what is written in
>> english. 
> 
> Not a valid comparison. It might be for programming language vs.
> programming language, but not o.s. vs. o.s.

Why not?  You are using an irrelevant standard for comparison, just
like using language as a standard for literature using VMS as a
"standard" for what an OS provides is just plain silly.  Actually,
there is a standard for what an OS should provide.  It's called POSIX.
Which OS come closer?

> 
> A better comparison might be two-seater vs. a mini-bus or a ranch vs.
> two-story home. Different feature sets underlying the upper-layers.

Actually, those are all equal comparisons.  I am quite certain that a
person who drives a "two-seater" does not consider it somehow defficient
cause it doesn't have the features of a mini-bus.  And, being the owner
and driver of a Mazda Miata and an MGB, I speak from experience.

> 
>> By that standard ther eis no good german or french literature.
>> I think the world would disagree.  And, as can be seen by example, the
>> industry has rejected VMS as a standard for which all computing must
>> strive.
> 
> Well, actually no, it hasn't. Over-generalization - invalid asssumption.
> You can't reject what you've never known about. 

Are you saying that the industry never knew about VMS?  Boy are you
mistaken.  There was a time when the names VAX and VMS were guarenteed
proposal wins even when the competition won all the benchmarks.  And,
I also learned that through direct, first-person experience!!  There was
a time when VMS was as common in academia as Unix was.  That was definitely
the case when I got her at the University of Scranton.  And when I was
at West Point (which is much more a college campus than an Army base)
the Computer Science Departement was a VAX/VMS shop.  We had Unix on
the administrative side years before it started showing up on the academic
side.  No, the IT industry was well aware of VMS before it rejected it.

> 
> See http://www.merriam-webster.com/dictionary/marketing
> 
>> > [snip]
>> > It Depends. Define "success".
>> 
>> How do you define it?  Market share?   Annual profits?  Number of systems?
>> Number of Users?  Industry familiarity? 
> 
> Yes.
> 
>> Where exactly does VMS exceed

Based on your answer above, why didn't you answer this one? (Rhetorical
question!)

>> Unix (or just about any other major OS today) other than in meeting the VMS
>> standard?
> 
> Feature richness (VMS) vs. being feature-impoverished (UN*X, DOS,
> Windows, etc.).

Back to that argument.  An OS is not "feature-impoverished" because it
doesn't offer features that its user base is not interested in.  You
are aware of the history of Unix, aren't you?  Features are added all
the time.  Journaling File Systems, Software RAID, IPSEC, IPv6.  None
of this was in the original Unix.  But as the users decided they needed
it, it was added.  And should the users ever decide they really need
some of the stuff that VMS has, it, too, will be added.  But not having
capabilities no one wants is not a shortcoming.

> 
>> >
>> >> How many times do you need to be told that Unix is adaptable enough that
>> >> pretty much any of the things you mentioned could have been (and still
>> >> could be) added except that Unix users don't see them as something to
>> >> be bothered about.
>> >
>> > Probably until they actually come about. Are you volunteering?
>> 
>> Why would I?  Like other Unix users I don't see a need for most of this
>> stuff so why invest time and effort delivering a product no one, appaerntly,
>> need and no one wants.  Make more profit selling refrigerators to eskimos.
> 
> See http://www.merriam-webster.com/dictionary/marketing

What does that have to do with anything?  Are you saying we should market
features no one wants so that someone will add them to Unix?  Seems to me
that it makes more sense to just wait until someone actually needs them.

> 
> Running joke about my brother-in-law (great b.s.-er): He could sell ice
> cubes to an eskimo for the eskimo's last dollar, and the eskimo would
> leave thanking him for it.

Old joke, don't see the point in this context except as stated above.

> 
>> >
>> >> >
>> >> > I've no way to know whether there is any hope of ever getting any new
>> >> > blood in OpenVMS engineering, but I'm hoping someone, somewhere, perhaps
>> >> > in VMS V10.0-1 will solve the "fork()" problem and in doing so solve
>> >> > many of the incompatibilities between UN*X and VMS, perhaps even merge
>> >> > UN*X and VMS into something that brings the best of both worlds to EDP.
>> >>
>> >> Personally, I don't think the fork() problem will ever be solved.  I
>> >> think there is just too much difference at a very low level to make it
>> >> possible.
>> >
>> > Oh, I'm sure it could be done, just not in the ways one might
>> > traditionally think from either a UN*X or VMS point of view.
>> 
>> If you don't do it the wya Unix does it then is isn't a Unix compatable
>> fork() and accomplishes nothing. 
> 
> It Depends. If looks like a fork, acts like a fork and provides the same
> functionality as a fork, then its a _ _ _ _ (fill in the blank).

Isn't that what I said?  If it does do the same thing as Unix fork() then
it it would be "a Unix compatable fork()".

> 
> Why would the upper layer software care what happens "under the hood" of
> SYS$FORK(), it is existed?

If it did the same as a Unix fork(), it wouldn't.  But, I believe the
show-stopper is that it can't.  I seem to recall that copying all the
open file descriptors was one of the things that VMS couldn't do.  If
I am remembering right, that's a show-stopper as I can show you at
least one program right now for which that capability is an explicit
requirement.

> 
>> A lot of the OpenSource programs that
>> people keep asking for on VMS rely heavily on fork() doing exactly what
>> it does on Unix.  If they didn't then VMS SPAWN would accomplish the
>> task.
>> 
>> People need to come to grips with the idea that, from the viewpoint of
>> the IT industry, VMS is not better than Unix, it is only different.
> 
> Here again, the counter-argument is also true: UN*X is not better than
> VMS(, DOS, Windows, etc.), only different.
> 
> Rather like comparing a wrench to channel-locks or a vise-grip: - its a
> question of the right tool for the job.

No arguemnt from me there.  But, sadly, there seems to be less and less
jobs where people see VMS as the right tool.  With all its supposed
advantages, its shortcomings compared to other OSes seem to be really
holding it back.  

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>