[Info-vax] Porting to Linux instead of x86-64 VMS, was: Re: 3rd party SATA SSD usage on RX2660+P400 in a production environment?

[Neil Rieck]

On Wednesday, July 3, 2019 at 8:46:56 AM UTC-4, John Reagan wrote:
> On Wednesday, July 3, 2019 at 7:43:12 AM UTC-4, Neil Rieck wrote:
> > On Tuesday, July 2, 2019 at 1:22:47 PM UTC-4, Simon Clubley wrote:
> > > On 2019-07-02, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> > > >
> > > > And in two or three years, we'll either be starting to replace these 
> > > > existing servers with x86-64 and ports to that, or we'll be starting up 
> > > > the Linux ports again.
> > > >
> > > 
> > > Are people actually talking about doing the latter ?
> > > 
> > > If so, is this due to the current VMS on x86-64 timescales or is
> > > it due to some lack of information coming out of VSI ?
> > > 
> > > If it's the latter, is there anything VSI can do at the moment to
> > > give both management and technical customer employees more confidence
> > > in the future of VMS ?
> > > 
> > > Simon.
> > > 
> > > -- 
> > > Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> > > Microsoft: Bringing you 1980s technology to a 21st century world
> > 
> > IMHO, the thing that will slow the adoption of new software on OpenVMS is the tool set. And here I am talking about VMS-C and VMS-C++ which do not yet support the C11 or C18 standards. For example, I have heard from several people that both MySQL and MariaDB applications after version 5 require C11.
> > 
> > I have been told that VSI is aware of this and is working on C11 as we speak. This whole problem was caused by HP (now HPE) who decided to let this fruit die on the vine.
> > 
> > Neil Rieck
> > Waterloo, Ontario, Canada.
> > http://neilrieck.net
> 
> Uh, are you confusing C11 with C++11?
> 
> https://mysqlserverteam.com/mysql-8-0-source-code-improvements/

IMHO, the Linux community is responsible for most of the confusion. While most of the world correctly treats C and C++ as separate languages, the "gcc" and "c++" commands on most Linux platforms pull up the same application. Check this out on one of my fully-patched CentOS-7 systems:

[neil at kawc4n ~]$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
Copyright (C) 2015 Free Software Foundation, Inc.

[neil at kawc4n ~]$ g++ --version
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
Copyright (C) 2015 Free Software Foundation, Inc.

To complicate things further, for quite some time now, "gcc" has meant "gnu compiler collection" rather than "gnu c compiler" although I continually hear people use "gnu c compiler" at local IEEE meetings. (coffee shops; not formal speech from the lectern)

Anyway, changes have been made to both C and C++ which (it is claimed) cause both these compilers to generate safer executables provided the developer is compiling with those extensions enabled. Ditching the "gets()" i/o function seemed like a good idea since it is the source of many exploits. I am also intrigued by the promise of (optionally) including bounds checking to arrays. (I have only mentioned two changes of many).

Anyway, the OpenVMS community is now in this dilemma because HP didn't want to further develop the DEC-C and DEC-C++ compilers so now we've got a problem: open source programs developed in "that other larger ecosystem" are no longer "easily" ported to OpenVMS. 

Anyway, I have 100% confidence in VSI modernizing VSI-C and VSI-C++ because both C/C++ will continue to evolve (The C standard seems to change every ~ 10 years whilst C++ standard seems to change every 3 years). Whether we like it or not, these two languages are the most important languages on the planet today.   

Neil Rieck
Waterloo, Ontario, Canada.