[Info-vax] OT: news from the trenches (re: Solaris)

[Bill Gunshannon]

In article <me7q3p$vvt$1 at dont-email.me>,
	David Froble <davef at tsoft-inc.com> writes:
> lists at openmailbox.org wrote:
>> On Fri, 13 Mar 2015 07:46:39 -0700 (PDT)
>> johnwallace4--- via Info-vax <info-vax at rbnsn.com> wrote:
>> 
>>> OK, thanks for that. Rather terse answer here as I need to be elsewhere...
>> 
>> No fair! Ask and run!
>> 
>>> 1) I do see where you're coming from. 
>>>
>>> 2) Much x86 carp is, as you acknowledge, hidden from most users, admins,
>>> programmers. But not all. Depends on hardware and depends on OS, and
>>> depends on your area of interest.
>> 
>> Yes, that's it. I don't believe anything I wrote is important to OS
>> customers generally. We're talking about the shortcomings of Intel and there
>> are plenty. But I do feel that at least in my professional circles it is
>> universally agreed Intel is commodity crapware and I think that part does
>> affect VMS's future since it is going to be targeted at a platform which is
>> known to be subprime in the industry.
>> 
>> But the platform does have an effect on the developers that write the OS
>> and products that run on it. I think Intel brings out the worst in those
>> groups, for a few reasons. One, it's a sloppy non-architecture so it
>> promotes nearsightedness and good enough is good enough solutions. It's low
>> end so people realize it's not worth putting out the best quality anything
>> since Intel is about speed uberalles and has a sad history of breaking
>> upward compatability. If they wanted quality they would go with another
>> platform. That's why Intel seems to me a very bad marriage for VMS. Two, I
>> think the way things are working today are the tail wagging the dog. If you
>> think about OS and hardware combinations that developers loved you're going
>> to think about closely coupled hardware and OS that were designed from the
>> beginning to work symbiotically. The way things are today that process is
>> very badly broken in most mainstream OS- basically it's Intel and AMD tying
>> to outdo each other on speed or other features and then the OS people
>> usually have to exploit this or that new feature just so they can say they
>> did. This is rats on a treadmill and not nearly as productive as having the
>> hardware and OS design in house and having the hardware guys providing what
>> the OS needs, not the hardware guys driving the OS. We see other successful
>> ecosystems where the OS and program product needs drive hardware features
>> and this is the way it should be.
>> 
>> The way things work today with Intel there are several major OS running on
>> it and the hardware is optimized for all of them then it's not optimized for
>> any of them. With Linux that's fine because it really exploits little in
>> the way of hardware on most platforms, with Linux it's more about running
>> everywhere than running well anywhere. But other OS that *only* run on
>> Intel like Windows and OS/X are chasing the hardware. That isn't how things
>> should be done.
>> 
>> Adding VMS to the mix and what do you get? Do you really think what VMS
>> needs is going to be a priority with Intel? No, we have already heard Intel
>> has all the great stuff VMS needs. And when it doesn't, then what? What
>> choices will VMS have when running on commodity hardware where it is a
>> small fish in a big pond?
>> 
>> VMS needs to run on a premium platform and control the whole ecosystem.
>> That is the only successful model (I mean in terms of longevity and
>> quality) we have seen. And that includes Wintel which because of Mutually
>> Assured Destruction (look at Intel's preliminary financials this quarter-
>> the warnings are coming) Intel and Microsoft work together. The others, less
>> and less so.
>> 
>>> 3) You're new to VMS. Welcome. Before drawing conclusions on how much
>>> of this legacy-x86 baggage will be visible in a nuVMS world, maybe get
>>> yourself a bit more familiar with how the architectural differences
>>> have been hidden (or not) in the previous VMS ports? Maybe? VMS is not
>>> UNIX. Compatibility has been a long term goal (though sometimes long
>>> term compatibility brings challenges too; a change of platform could
>>> be a good time to look at some of those things).
>> 
>> Thanks and again I agree the OS end-user or application developer is not
>> affected directly by these issues although I do believe there is fallout
>> both tangible and intangible as I mentioned, and it's significant.
>> 
>> Anyway, for somebody who writes systems code in assembler what interested
>> me in VMS was that it ran on platforms I have no knowledge of, and that are
>> also supposed to be good and now our hopes are dashed on the rocks on Intel
>> crapware again. It's depressing to see what a small world it's becoming,
>> where everybody talks about choice but there really is almost none. Anything
>> we can do to change that is A Good Thing.
>> 
>>> And then once you know how much platform-specific stuff has historically
>>> been (in)visible, we can start guessing how much it will *matter* to the
>>> people with the chequebooks.
>> 
>> Agreed.
>> 
>> But I'll continue to run old versions of VMS if I do at all, because I have
>> no interest in spending any time with Intel.
>> 
> 
> Much of what you write is correct.  Consider VAX and Alpha.  Both were 
> set up to co-exist with VMS.  Much more VAX than Alpha.
> 
> But, just as people won't pay for security, they also didn't pay for 
> quality.  VAX and Alpha and any potential follow-ons no longer exist.
> 
> Reminds me of one of the Sci-Fi movies, where every restaurant was Taco 
> Bell.  Like that concept, I don't see any viable alternatives.  If the 
> choices are VMS on Intel chips, or no VMS, I'll take what I can get.

That was "Demolition Man",  a Sylvester Stalone movie and the whole
thing was so tongue-in-cheek it bordered on the absurd.  Kinda like
the Twinkie scene in Ghost Rider 2.

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>