Discussion:
Graphics Update - Opportunity for ISV/ third party / developers?
Add Reply
Kerry Main
2017-03-26 13:45:58 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> IanD via Info-vax
> Sent: November 25, 2016 12:01 AM
> To: info-***@rbnsn.com
> Cc: IanD <***@gmail.com>
> Subject: Re: [Info-vax] Hoff's Boot Camp report available
>
> On Friday, November 25, 2016 at 12:47:48 AM UTC+11, Phillip Helbig
> (undress to reply) wrote:
> > In article
> <561c9cb1$0$8242$b1db1813$***@news.astraweb.com>, JF
> > Mezei <***@vaxination.ca> writes:
> >
> > > However, I wouldn't so quickly dismiss graphics and I would
prefer
> > > to see VSI saying they are going to listen to customers and
> > > potential customers for what the priorities should me. This is
more
> > > "politically correct" and doesn't close doors that could
possibly
> > > pan out as being very profitable.
> >
> > VSI has said that they would support the on-chip graphics, so I
can
> > still run DECwindows under CDE. :-) Is it worth trying to
compete in
> > high-end graphics?
>
> Compete in the high end workstation market? No point going there
> IMO
>
> Compete in the really high end, as in the HPC camp with GPU farms,
> that's been won by the linux camp mostly and the HPC camp buy eco
> systems, not just an OS in isolation
>
> If VSI is willing to extend OpenVMS to be a hybrid OS with GPU's
> making up it's compute offerings, then maybe but I doubt they are
> going to be in a position to do this for a very long time
>
> There's even work being done on bringing back vector processing into
> the IT picture! Didn't the Vax have some support for vector
operation
> support?
>
> It's the synergy of having access to all these technologies that
add's
> value.
>
> VMS has got a lot of work to catch up on in the areas it abandoned
long
> ago but at least we are moving forward - gotta be grateful for this
at
> least :-)

Interesting update on Vulkan - the emerging open graphics standard:

Note this is imho, not of direct interest to VSI, but rather a
potential area where a third party or ISV or someone looking for a
niche area to build on, can use open standard API's in Vulkan to offer
additional graphics drivers for OpenVMS.

Intel launches Vulkan driver support: Feb 14, 2017 (industry support
growing)

http://www.bit-tech.net/news/hardware/2017/02/14/intel-vulkan/1
"Announced back in 2015, Vulkan builds on technology developed during
the GLnext programme and by AMD as part of its own short-lived Mantle
API with one primary goal in mind: reducing driver overhead and
providing developers with access closer to the metal as a means of
boosting performance, particularly on lower-end hardware. Designed to
work alongside OpenGL, Vulkan has won support from both AMD and Nvidia
- and now you can count Intel as an official Vulkan adopter."

[yes, we all know the port needs to complete first]


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Stephen Hoffman
2017-03-26 16:32:21 UTC
Reply
Permalink
Raw Message
On 2017-03-26 13:45:58 +0000, Kerry Main said:

> Interesting update on Vulkan - the emerging open graphics standard:
>
> Note this is imho, not of direct interest to VSI, but rather a
> potential area where a third party or ISV or someone looking for a
> niche area to build on, can use open standard API's in Vulkan to offer
> additional graphics drivers for OpenVMS.

FWIW....

OpenGL and Vulkan aren't protocols used to communicate between the host
hardware and the graphics controller via the I/O bus, they're intended
for communications between host applications and the graphics
processors via a lower-level path. In OpenVMS terms, this is the
difference between Alpha to KDM70 and the hardware bus, and MSCP
operating via that previous software path. OpenGL, for instance,
allows me a way to write code that OpelGL then compiles for the
particular graphics controller, and passes that over into the graphics
processor for execution. But I'm not writing any code that accesses
I/O bus registers or performs programmed I/O or direct memory access
(DMA) transfers, that's all below the level of OpenGL or Vulkan. This
means that adding Vulkan support — akin to the existing and older
OpenGL support that can be installed on OpenVMS — is largely
application-level library or framework-related work and what is
sometimes called a "driver" on other platforms — and that there is a
separate and large hunk of development for the hardware device driver —
what OpenVMS traditionally considers a device driver — to allow the
higher-level software using the Vulkan or OpenGL or Motif or Wayland or
other abstractions — to communicate with the graphics hardware.

As for getting into the business of graphics or other specialized
device drivers, y'all need to accumulate a bunch of boards as stock,
access to the OpenVMS internals and build environment — graphics
drivers interfaces are not documented — and are traditionally built for
each OpenVMS release; this is why there used to be two
DECwindows-related kits around, one with the system-dependent portions
of DECwindows and one with the version-independent parts of DECwindows.
Also with either customizing the boards to make copying the drivers
harder, or some other form of copy protection — LMF never got as far as
implementing driver license checks, though there was some thought given
to that.

Then y'all have to make enough money to recoup the development costs
for all this effort, and local graphics support pretty clearly hasn't
been a big seller for folks using OpenVMS servers. (Not that I think
server-generated graphics — beyond a Windows-style server-management
graphics console and usually accessed via RDP or VNC from remote
systems, and those paths are almost never used as the production
interfaces into servers — is going to be a big seller in general,
though there will undoubtedly be some niche OpenVMS users that might
want local graphics.) Which usually makes the product purchase prices
high. Which usually makes the sales volumes low. And OpenVMS sales
volumes haven't been appreciable in recent years. (This is part of
why the graphics vendors aren't developing drivers for more than
Microsoft Windows and maybe then one or two other platforms if any
others beyond Windows, too. And that most folks — other than hardware
and OS vendors — use existing OpenGL or Vulkan or DirectX or Metal
interfaces over existing hardware device drivers, and usually don't try
to implement their own stacks.)

Probably the only hardware-level device drivers I can see having a shot
here with OpenVMS would be for the Intel HD Graphics and Intel Iris
interfaces. That's a moving target certainly, but that's integrated
and avoids the shelf-life-of-a-fruit-fly add-on graphics hardware, but
that's all a faster-moving target than has been traditional for OpenVMS
software providers. But that's fodder for another day and another
discussion.

Most folks are using client-local interfaces or web-based interfaces as
the front-ends for most server-based applications. Yes, OpenVMS folks
are still using serial terminal sessions, but I'd wager most folks with
those implementations would want to move to local client front-ends or
web-based front-ends, if presented with a sizable investment of funds
and time for that sort of user interface work. Not a local and
hardware-specific graphics driver...

Isn't Stark a gaming and graphics company? Aren't you and folks
you're working with at Stark familiar with OpenVMS and related software
development? If you believe this is a ripe opportunity, certainly
have at... Expect to be doing both the Intel HD or Intel Iris
drivers, and the Vulkan or OpenGL bits — APIs and that graphics
cross-compiler, et al — as well as figuring out how to get VSI to
export and document and support the interfaces and APIs and definitions
and build environments necessary for all that to be reasonably useful
to end-users... But I'd expect this to be a Really Small Niche, and
one with Very Expensive Products...


--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2017-03-26 17:42:56 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: March 26, 2017 12:32 PM
> To: info-***@rbnsn.com
> Cc: Stephen Hoffman <***@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 2017-03-26 13:45:58 +0000, Kerry Main said:
>
> > Interesting update on Vulkan - the emerging open graphics standard:
> >
> > Note this is imho, not of direct interest to VSI, but rather a
> > potential area where a third party or ISV or someone looking for a
> > niche area to build on, can use open standard API's in Vulkan to offer
> > additional graphics drivers for OpenVMS.
>
> FWIW....
>

[snip..]

>
> Isn't Stark a gaming and graphics company? Aren't you and folks
> you're working with at Stark familiar with OpenVMS and related
> software
> development? If you believe this is a ripe opportunity, certainly
> have at... Expect to be doing both the Intel HD or Intel Iris
> drivers, and the Vulkan or OpenGL bits — APIs and that graphics cross-
> compiler, et al — as well as figuring out how to get VSI to export and
> document and support the interfaces and APIs and definitions and
> build environments necessary for all that to be reasonably useful to
> end-users... But I'd expect this to be a Really Small Niche, and one
> with Very Expensive Products...
>

Graphics in gaming is usually done on the client (whatever the client OS). Not my worry.

The back end systems are simply the collectors of various inputs from the clients and distribute these updates to the clients participating in that specific game.

Gamers could not care less what the back end systems are running as long as the end result is fast response on their client as well as back end stability and availability (most back end systems in todays gamer world is anything but stable and available).

Never say never .. industry is constantly changing.

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Stephen Hoffman
2017-03-26 18:33:15 UTC
Reply
Permalink
Raw Message
On 2017-03-26 17:42:56 +0000, Kerry Main said:

> Graphics in gaming is usually done on the client (whatever the client
> OS). Not my worry.
>
> The back end systems are simply the collectors of various inputs from
> the clients and distribute these updates to the clients participating
> in that specific game.
>
> Gamers could not care less what the back end systems are running as
> long as the end result is fast response on their client as well as back
> end stability and availability (most back end systems in todays gamer
> world is anything but stable and available).


That networking and lag doesn't (directly) effect local rendering, and
games without MMO/multiplayer/online capabilities entirely avoid
problems with lag, though most games do have some form of online gaming.

Gaming is one of the better spots to learn about very fast and
variously clever networking, as well as about using servers as a
fundamental part of application copy protection and anti-reversing and
anti-cheats; about security, oddly enough.

Online gaming really hammers on the network links, too... I've links
to some discussions on network latency and remote operations — lag, use
of UDP or TCP tuning — in online and multiplayer gaming. Here's a
general intro to some of what can be involved:

https://web.wpi.edu/Pubs/E-project/Available/E-project-031214-091747/unrestricted/imcneil-mbeyler-mqpreport.pdf


Here's some background on the topic in a client operating system,
including a discussion of the really-handy Network Link Conditioner
tool:

https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/WhyNetworkingIsHard/WhyNetworkingIsHard.html


Here's Unreal 3 (old engine, but handy link) networking....

https://docs.unrealengine.com/udk/Three/NetworkingOverview.html

Unreal, Unity and such, or the platform-specific clients such as what's
in macOS with GameplayKit or other platforms.

As for OpenVMS.... Some folks I've dealt with were using an OpenVMS
server they had access to — and some Perl code — to DoS remote folks,
and it would not be surprising to learn the targets were gamers.

BTW, for those not familiar with what's involved in developing and
deploying a major online game, here are some not-entirely-current and
very brief write-ups on the scale of the investment...

https://www.gamespot.com/articles/this-is-how-much-the-witcher-3-cost-to-make/1100-6430409/

http://www.leviathyn.com/2013/04/12/the-costs-of-aaa-games-development/

Semi-related to the gaming, here's a dangling link from a
programming-related discussion that occurred elsewhere recently...
Clean C++ (gaming) code...

http://www.phoronix.com/scan.php?page=news_item&px=MTI3NDQ



--
Pure Personal Opinion | HoffmanLabs LLC
IanD
2017-03-26 19:54:47 UTC
Reply
Permalink
Raw Message
On Monday, March 27, 2017 at 5:33:19 AM UTC+11, Stephen Hoffman wrote:
> On 2017-03-26 17:42:56 +0000, Kerry Main said:
>
> > Graphics in gaming is usually done on the client (whatever the client
> > OS). Not my worry.
> >
> > The back end systems are simply the collectors of various inputs from
> > the clients and distribute these updates to the clients participating
> > in that specific game.
> >
> > Gamers could not care less what the back end systems are running as
> > long as the end result is fast response on their client as well as back
> > end stability and availability (most back end systems in todays gamer
> > world is anything but stable and available).
>
>
> That networking and lag doesn't (directly) effect local rendering, and
> games without MMO/multiplayer/online capabilities entirely avoid
> problems with lag, though most games do have some form of online gaming.
>
> Gaming is one of the better spots to learn about very fast and
> variously clever networking, as well as about using servers as a
> fundamental part of application copy protection and anti-reversing and
> anti-cheats; about security, oddly enough.
>
> Online gaming really hammers on the network links, too... I've links
> to some discussions on network latency and remote operations — lag, use
> of UDP or TCP tuning — in online and multiplayer gaming. Here's a
> general intro to some of what can be involved:
>
> https://web.wpi.edu/Pubs/E-project/Available/E-project-031214-091747/unrestricted/imcneil-mbeyler-mqpreport.pdf
>
>
> Here's some background on the topic in a client operating system,
> including a discussion of the really-handy Network Link Conditioner
> tool:
>
> https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/WhyNetworkingIsHard/WhyNetworkingIsHard.html
>
>
> Here's Unreal 3 (old engine, but handy link) networking....
>
> https://docs.unrealengine.com/udk/Three/NetworkingOverview.html
>
> Unreal, Unity and such, or the platform-specific clients such as what's
> in macOS with GameplayKit or other platforms.
>
> As for OpenVMS.... Some folks I've dealt with were using an OpenVMS
> server they had access to — and some Perl code — to DoS remote folks,
> and it would not be surprising to learn the targets were gamers.
>
> BTW, for those not familiar with what's involved in developing and
> deploying a major online game, here are some not-entirely-current and
> very brief write-ups on the scale of the investment...
>
> https://www.gamespot.com/articles/this-is-how-much-the-witcher-3-cost-to-make/1100-6430409/
>
> http://www.leviathyn.com/2013/04/12/the-costs-of-aaa-games-development/
>
> Semi-related to the gaming, here's a dangling link from a
> programming-related discussion that occurred elsewhere recently...
> Clean C++ (gaming) code...
>
> http://www.phoronix.com/scan.php?page=news_item&px=MTI3NDQ
>
>
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

What's referred to as netcode in Unreal engine terms makes or breaks an online game

I play UT4 (previously UT3/ UT2004)

While folks think gaming is for 'kids', it might surprise them that the average age for gamers keeps ratcheting up, it is currently 31 worldwide and 38 in the US (as of 2014) and the gender split is 50/50

If your talking money, then gaming revenue in 2014 hit 84 billion, surpassing movies by a long way (the cross over happened a number of years ago). However, movies through DVD / merchandise etc earns more in total, or at least it used to

The gaming industry has twitch which it is trying to work into a full blown spectator / channel streaming service. It was very popular a few years ago but I have not followed it recently. However popular games have spectators easily eclipsing any physical arena by many orders of magnitude

Netcode is highly sophisticated and highly optimised. It is no simply compressing or factoring command sequences (acms remote used simplistic compression did it not?). Online games like UT4 and Quake are highly integrated optimised distributed systems. Aspects like games sound, synchronisation techniques, hit scans / detection all play a part.

Epic games, the owner of what would be considered the worlds most popular gaming engine invests a lot of time into games like it's up and coming UT4 game. It is in games that they hone their development of their gaming engines and show it off to future purchasers of the engine

I posted elsewhere, a long time ago it seems about Epic and how it has totally open sourced it's gaming engine! This is a company who had the lions share of the gaming engine market yet they saw the need to open source their product, a product they charged 1000's for. Epic saw the need to get communities on-board to help them develop their engine at a rate beyond their competition - they turned to open source to do it. They license their engine for free but charge a revenue of profit beyond a certain threshold

Preventing game cheating has direct parallels to the security industry in that how does one secure a client code base while integrating with a server and sharing with others

Anyone who thinks online gaming is a simple affair obviously are oblivious to it's complexities and why graduates from game design higher education institutions are sought after - it's not just about the games

A complex online games like UT4 takes years to develop and hone before release. The lower the latency requirements the more optimised the game needs to be at all levels. UT4 is one of the most latency affected games. In competitive arenas, a 10ms latency between equally matched plyers is very noticeable and can make the difference between winning and loosing. There are ping compensators around but these skew game dynamics and only introduce delays in other areas. Aspects like screen tearing and other aspects all come into play

A highly optimised game played at the tournament level is akin to an extreme audiophile who will go out of their way to optimise every last aspect end to end of the music pathway to obtain the purest sound. Online gaming is no different. Mechanical keyboards with specially picked cherry switches to high rate monitors, to panel monitor selection to specific mice choice to input monitor lag (which can be very difficult to tease out of monitor manufacturers). CPU's overclocked, ram overclocked, placing components in certain slots on the motherboards, to motherboard and even chipset overclocking are all standard practice at the competition level for gaming. This is just on the individual level too, then there is clan gaming which involves training sessions. It's a whole different world out there in gaming!

This is one area where Linux does not dominate. Mac is the least sought after area for gaming. Even mobile has recently lost to PC gaming as has consoles. VR is coming. PC's / windows dominate the high end of gaming. It has taken many years to get gaming to the level it currently is on PC's (multi gpu support etc).

Graphics wise, VMS is so far out of touch that it would be dead money to invest in it for VMS. Would / could it benefit from the technology and methods of highly optimised gaming? of course but the revenue streams needed to support such research would be too great

What a shame. How many areas has VMS retreated from to the point where it cannot renter those market segments again I wonder? Education? Scientific? Finance? and how many more new one's is it not flexible enough to enter? Mobile? Embedded? Gaming?
Kerry Main
2017-03-26 22:49:00 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> IanD via Info-vax
> Sent: March 26, 2017 3:55 PM
> To: info-***@rbnsn.com
> Cc: IanD <***@gmail.com>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On Monday, March 27, 2017 at 5:33:19 AM UTC+11, Stephen Hoffman
> wrote:
> > On 2017-03-26 17:42:56 +0000, Kerry Main said:
> >
> > > Graphics in gaming is usually done on the client (whatever the
> > > client OS). Not my worry.
> > >
> > > The back end systems are simply the collectors of various inputs
> > > from the clients and distribute these updates to the clients
> > > participating in that specific game.
> > >
> > > Gamers could not care less what the back end systems are running
> as
> > > long as the end result is fast response on their client as well as
> > > back end stability and availability (most back end systems in todays
> > > gamer world is anything but stable and available).
> >
> >
> > That networking and lag doesn't (directly) effect local rendering, and
> > games without MMO/multiplayer/online capabilities entirely avoid
> > problems with lag, though most games do have some form of online
> gaming.
> >
> > Gaming is one of the better spots to learn about very fast and
> > variously clever networking, as well as about using servers as a
> > fundamental part of application copy protection and anti-reversing
> and
> > anti-cheats; about security, oddly enough.
> >
> > Online gaming really hammers on the network links, too... I've links
> > to some discussions on network latency and remote operations —
> lag, use
> > of UDP or TCP tuning — in online and multiplayer gaming. Here's a
> > general intro to some of what can be involved:
> >
> > https://web.wpi.edu/Pubs/E-project/Available/E-project-031214-
> 091747/u
> > nrestricted/imcneil-mbeyler-mqpreport.pdf
> >
> >
> > Here's some background on the topic in a client operating system,
> > including a discussion of the really-handy Network Link Conditioner
> > tool:
> >
> >
> https://developer.apple.com/library/content/documentation/Networ
> kingIn
> >
> ternetWeb/Conceptual/NetworkingOverview/WhyNetworkingIsHard/
> WhyNetwork
> > ingIsHard.html
> >
> >
> > Here's Unreal 3 (old engine, but handy link) networking....
> >
> >
> https://docs.unrealengine.com/udk/Three/NetworkingOverview.html
> >
> > Unreal, Unity and such, or the platform-specific clients such as
> > what's in macOS with GameplayKit or other platforms.
> >
> > As for OpenVMS.... Some folks I've dealt with were using an
> OpenVMS
> > server they had access to — and some Perl code — to DoS remote
> folks,
> > and it would not be surprising to learn the targets were gamers.
> >
> > BTW, for those not familiar with what's involved in developing and
> > deploying a major online game, here are some not-entirely-current
> and
> > very brief write-ups on the scale of the investment...
> >
> > https://www.gamespot.com/articles/this-is-how-much-the-witcher-
> 3-cost-
> > to-make/1100-6430409/
> >
> > http://www.leviathyn.com/2013/04/12/the-costs-of-aaa-games-
> development
> > /
> >
> > Semi-related to the gaming, here's a dangling link from a
> > programming-related discussion that occurred elsewhere recently...
> > Clean C++ (gaming) code...
> >
> >
> http://www.phoronix.com/scan.php?page=news_item&px=MTI3NDQ
> >
> >
> >
> > --
> > Pure Personal Opinion | HoffmanLabs LLC
>
> What's referred to as netcode in Unreal engine terms makes or breaks
> an online game
>
> I play UT4 (previously UT3/ UT2004)
>
> While folks think gaming is for 'kids', it might surprise them that the
> average age for gamers keeps ratcheting up, it is currently 31
> worldwide and 38 in the US (as of 2014) and the gender split is 50/50
>
> If your talking money, then gaming revenue in 2014 hit 84 billion,
> surpassing movies by a long way (the cross over happened a number
> of years ago). However, movies through DVD / merchandise etc earns
> more in total, or at least it used to
>

These CBS / CNN links sum it up nicely .. in a nutshell, there is a parallel universe out there with most non-gaming folks our age not even knowing it is there.

http://www.cbsnews.com/news/the-competitive-world-of-esports/

http://www.cnn.com/videos/tv/2016/05/28/world-of-esports-ws-pkg-riddell.cnn/video/playlists/esports/

Also note that the predominant dev language used for highly scalable games is C++ (not an issue for OpenVMS)

And for those who believe hockey is cool, check out recent happenings in last few days with NHL and eSports:
http://www.gamesindustry.biz/articles/2017-03-22-nhl-sizing-up-esports-opportunity

> The gaming industry has twitch which it is trying to work into a full
> blown spectator / channel streaming service. It was very popular a few
> years ago but I have not followed it recently. However popular games
> have spectators easily eclipsing any physical arena by many orders of
> magnitude
>
> Netcode is highly sophisticated and highly optimised. It is no simply
> compressing or factoring command sequences (acms remote used
> simplistic compression did it not?). Online games like UT4 and Quake
> are highly integrated optimised distributed systems. Aspects like
> games sound, synchronisation techniques, hit scans / detection all play
> a part.
>
> Epic games, the owner of what would be considered the worlds most
> popular gaming engine invests a lot of time into games like it's up and
> coming UT4 game. It is in games that they hone their development of
> their gaming engines and show it off to future purchasers of the
> engine
>
> I posted elsewhere, a long time ago it seems about Epic and how it has
> totally open sourced it's gaming engine! This is a company who had the
> lions share of the gaming engine market yet they saw the need to
> open source their product, a product they charged 1000's for. Epic saw
> the need to get communities on-board to help them develop their
> engine at a rate beyond their competition - they turned to open
> source to do it. They license their engine for free but charge a revenue
> of profit beyond a certain threshold
>
> Preventing game cheating has direct parallels to the security industry in
> that how does one secure a client code base while integrating with a
> server and sharing with others
>

https://www.gamespot.com/articles/esl-reveals-plan-to-clean-up-doping-corruption-and/1100-6439781/?utm_campaign=gamespace_f&utm_content=footer&utm_medium=partner&utm_source=gamefaqs

Simply google "esports cheating" to see what a huge issue it is - on the client and the back end servers.

> Anyone who thinks online gaming is a simple affair obviously are
> oblivious to it's complexities and why graduates from game design
> higher education institutions are sought after - it's not just about the
> games
>

Part of the challenge facing some game designers is that they are still in the traditional (ok, I call it legacy) shared nothing, heavily distributed network architecture designs.

In addition, game developers need to address data consistency, availability, node mgmt., replication, HA, DR etc. in their application code, which makes the app developers role much more complex.

The world is rapidly moving towards a combo of regional based zones (dual sites in AP, NA, EMEA), with heavily centralized, high throughput, ultra low latency server designs in each of these zones.

With OpenVMS clusters, a great deal of the App developers tasks are simplified because a number of these developer activities (data consistency, node mgmt., replication, HA, etc.) are handled at the OS level. The developer can focus on code optimization, quality i.e. spend more time on their App which is where their core focus should be.

> A complex online games like UT4 takes years to develop and hone
> before release. The lower the latency requirements the more
> optimised the game needs to be at all levels. UT4 is one of the most
> latency affected games. In competitive arenas, a 10ms latency
> between equally matched plyers is very noticeable and can make the
> difference between winning and loosing. There are ping compensators
> around but these skew game dynamics and only introduce delays in
> other areas. Aspects like screen tearing and other aspects all come into
> play
>
> A highly optimised game played at the tournament level is akin to an
> extreme audiophile who will go out of their way to optimise every last
> aspect end to end of the music pathway to obtain the purest sound.
> Online gaming is no different. Mechanical keyboards with specially
> picked cherry switches to high rate monitors, to panel monitor
> selection to specific mice choice to input monitor lag (which can be
> very difficult to tease out of monitor manufacturers). CPU's
> overclocked, ram overclocked, placing components in certain slots on
> the motherboards, to motherboard and even chipset overclocking are
> all standard practice at the competition level for gaming. This is just on
> the individual level too, then there is clan gaming which involves
> training sessions. It's a whole different world out there in gaming!
>

The concept to be addressed is "solution latency" which as you highlighted above, distance is only one component.

> This is one area where Linux does not dominate. Mac is the least
> sought after area for gaming. Even mobile has recently lost to PC
> gaming as has consoles. VR is coming. PC's / windows dominate the
> high end of gaming. It has taken many years to get gaming to the level
> it currently is on PC's (multi gpu support etc).
>

MAC server's are non-existent in enterprise DC's.

> Graphics wise, VMS is so far out of touch that it would be dead money
> to invest in it for VMS. Would / could it benefit from the technology
> and methods of highly optimised gaming? of course but the revenue
> streams needed to support such research would be too great
>

Graphics is not required for server side of eSports - its done on the client platform (in most online games anyway).

Back end server requirements are scalability, availability, security and high throughput, low latency interconnects for east-west traffic (server-to-server).

> What a shame. How many areas has VMS retreated from to the point
> where it cannot renter those market segments again I wonder?
> Education? Scientific? Finance? and how many more new one's is it not
> flexible enough to enter? Mobile? Embedded? Gaming?
>

A biggie holding it back is lack of X86-64 server support and up-front licensing costs.

Both of which will hopefully be addressed soon.

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-03-27 00:36:15 UTC
Reply
Permalink
Raw Message
On 2017-03-26, Kerry Main <***@gmail.com> wrote:
>
> Also note that the predominant dev language used for highly scalable games is
> C++ (not an issue for OpenVMS)
>

Actually, that's a major issue for VMS if you want a modern version of
C++. Look at all the "fun" John is going through with his bring up of
LLVM on VMS and the reason why it's a multi-stage approach.

Also, what about any support libraries in use in this ecosystem ?

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Kerry Main
2017-03-27 01:15:45 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Simon Clubley via Info-vax
> Sent: March 26, 2017 8:36 PM
> To: info-***@rbnsn.com
> Cc: Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 2017-03-26, Kerry Main <***@gmail.com> wrote:
> >
> > Also note that the predominant dev language used for highly
scalable
> > games is
> > C++ (not an issue for OpenVMS)
> >
>
> Actually, that's a major issue for VMS if you want a modern version
of
> C++. Look at all the "fun" John is going through with his bring up
of
> LLVM on VMS and the reason why it's a multi-stage approach.
>
> Also, what about any support libraries in use in this ecosystem ?
>
> Simon.
>

Like all environments, I guess it would depend on what the requirement
is to meet latest C++ standards?


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-03-27 01:27:51 UTC
Reply
Permalink
Raw Message
On 2017-03-27, Kerry Main <***@gmail.com> wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> Simon Clubley via Info-vax
>> Sent: March 26, 2017 8:36 PM
>> To: info-***@rbnsn.com
>> Cc: Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP>
>> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
>> party / developers?
>>
>> Actually, that's a major issue for VMS if you want a modern version
> of
>> C++. Look at all the "fun" John is going through with his bring up
> of
>> LLVM on VMS and the reason why it's a multi-stage approach.
>>
>> Also, what about any support libraries in use in this ecosystem ?
>>
>
> Like all environments, I guess it would depend on what the requirement
> is to meet latest C++ standards?
>

John's got two issues IIRC. The most recent is that ./configure is
no longer supported in current versions (so he needs to get cmake
working at some point), but an issue with earlier LLVM versions is
that the LLVM team has decided to start using current C++ features
in their codebase.

If a compiler which is supposed to be portable is doing this, then
I imagine this is a general trend in the C++ ecosystem as well.

Simon.

PS: I know I've mentioned it before, but could you please have
another look at how you are quoting messages ? It's harder to read
messages which have single words broken out onto lines of their
own as has happened to my above message that you quoted. Thanks.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Kerry Main
2017-03-27 01:57:18 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Simon Clubley via Info-vax
> Sent: March 26, 2017 9:28 PM
> To: info-***@rbnsn.com
> Cc: Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 2017-03-27, Kerry Main <***@gmail.com> wrote:
> >> -----Original Message-----
> >> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Simon
> >> Clubley via Info-vax
> >> Sent: March 26, 2017 8:36 PM
> >> To: info-***@rbnsn.com
> >> Cc: Simon Clubley <***@remove_me.eisner.decus.org-
> Earth.UFP>
> >> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/
third
> >> party / developers?
> >>
> >> Actually, that's a major issue for VMS if you want a modern
version
> > of
> >> C++. Look at all the "fun" John is going through with his bring
up
> > of
> >> LLVM on VMS and the reason why it's a multi-stage approach.
> >>
> >> Also, what about any support libraries in use in this ecosystem ?
> >>
> >
> > Like all environments, I guess it would depend on what the
> requirement
> > is to meet latest C++ standards?
> >
>
> John's got two issues IIRC. The most recent is that ./configure is
no
> longer supported in current versions (so he needs to get cmake
> working at some point), but an issue with earlier LLVM versions is
that
> the LLVM team has decided to start using current C++ features in
their
> codebase.
>
> If a compiler which is supposed to be portable is doing this, then I
> imagine this is a general trend in the C++ ecosystem as well.
>
> Simon.
>
> PS: I know I've mentioned it before, but could you please have
> another look at how you are quoting messages ? It's harder to read
> messages which have single words broken out onto lines of their own
> as has happened to my above message that you quoted. Thanks.
>

Feedback from others is that their reader is ok with my Outback email
client formatting.

What client / reader do you use?

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-03-27 07:05:22 UTC
Reply
Permalink
Raw Message
On 2017-03-27, Kerry Main <***@gmail.com> wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> Simon Clubley via Info-vax
>> Sent: March 26, 2017 9:28 PM
>> To: info-***@rbnsn.com
>> Cc: Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP>
>> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
>> party / developers?
>>
>> PS: I know I've mentioned it before, but could you please have
>> another look at how you are quoting messages ? It's harder to read
>> messages which have single words broken out onto lines of their own
>> as has happened to my above message that you quoted. Thanks.
>>
>
> Feedback from others is that their reader is ok with my Outback email
> client formatting.
>
> What client / reader do you use?
>

slrn, which is a standard news client.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Hans Bachner
2017-03-29 20:19:30 UTC
Reply
Permalink
Raw Message
Kerry Main schrieb am 27.03.2017 um 03:57:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> Simon Clubley via Info-vax
>> Sent: March 26, 2017 9:28 PM
>> To: info-***@rbnsn.com
>> Cc: Simon Clubley <***@remove_me.eisner.decus.org-Earth.UFP>
>> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
>> party / developers?
>>
>> On 2017-03-27, Kerry Main <***@gmail.com> wrote:
>>>> -----Original Message-----
>>>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> Simon
>>>> Clubley via Info-vax
>>>> Sent: March 26, 2017 8:36 PM
>>>> To: info-***@rbnsn.com
>>>> Cc: Simon Clubley <***@remove_me.eisner.decus.org-
>> Earth.UFP>
>>>> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/
> third
>>>> party / developers?
>>>>
>>>> Actually, that's a major issue for VMS if you want a modern
> version
>>> of
>>>> C++. Look at all the "fun" John is going through with his bring
> up
>>> of
>>>> LLVM on VMS and the reason why it's a multi-stage approach.
>>>>
>>>> Also, what about any support libraries in use in this ecosystem ?
>>>>
>>>
>>> Like all environments, I guess it would depend on what the
>> requirement
>>> is to meet latest C++ standards?
>>>
>>
>> John's got two issues IIRC. The most recent is that ./configure is
> no
>> longer supported in current versions (so he needs to get cmake
>> working at some point), but an issue with earlier LLVM versions is
> that
>> the LLVM team has decided to start using current C++ features in
> their
>> codebase.
>>
>> If a compiler which is supposed to be portable is doing this, then I
>> imagine this is a general trend in the C++ ecosystem as well.
>>
>> Simon.
>>
>> PS: I know I've mentioned it before, but could you please have
>> another look at how you are quoting messages ? It's harder to read
>> messages which have single words broken out onto lines of their own
>> as has happened to my above message that you quoted. Thanks.
>>
>
> Feedback from others is that their reader is ok with my Outback email
> client formatting.
>
> What client / reader do you use?

I use Thunderbird and observe the same strange formatting of your posts
as Simon. I left the complete quote in this reply so you can see (sort
of) what I see. All lines prefixed with a single ">" (or whatever your
client uses for marking quotes) except for the last 5 lines indicate
strange line breaks introduced in your quote.

On a similar topic - as you are aware, longer links in your posts are
equally broken across lines. Try to enclose a quote in angle brackets
("<" and ">"), maybe that helps.

Regards,
Hans.
Arne Vajhøj
2017-03-27 01:46:14 UTC
Reply
Permalink
Raw Message
On 3/26/2017 9:15 PM, Kerry Main wrote:
>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> Simon Clubley via Info-vax
>> On 2017-03-26, Kerry Main <***@gmail.com> wrote:
>>> Also note that the predominant dev language used for highly scalable
>>> games is
>>> C++ (not an issue for OpenVMS)
>>>
>>
>> Actually, that's a major issue for VMS if you want a modern version of
>> C++. Look at all the "fun" John is going through with his bring up of
>> LLVM on VMS and the reason why it's a multi-stage approach.
>>
>> Also, what about any support libraries in use in this ecosystem ?
>
> Like all environments, I guess it would depend on what the requirement
> is to meet latest C++ standards?

It may be required in some cases.

And even if it is not required then if everything else is
equal then they will pick the platform with the best compiler
support (and support for newer standards is part of compiler
support).

And note that it is not just the specific application.
But also all the libraries it use.

If it is 1 application and 20 libraries, then if just if 1 out
of the 21 requires a super uptodate C++ then ...

Arne
Kerry Main
2017-03-27 02:06:38 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Arne Vajhøj via Info-vax
> Sent: March 26, 2017 9:46 PM
> To: info-***@rbnsn.com
> Cc: Arne Vajhøj <***@vajhoej.dk>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 3/26/2017 9:15 PM, Kerry Main wrote:
> >> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Simon
> >> Clubley via Info-vax On 2017-03-26, Kerry Main
> >> <***@gmail.com> wrote:
> >>> Also note that the predominant dev language used for highly
> scalable
> >>> games is
> >>> C++ (not an issue for OpenVMS)
> >>>
> >>
> >> Actually, that's a major issue for VMS if you want a modern
version
> >> of
> >> C++. Look at all the "fun" John is going through with his bring
up of
> >> LLVM on VMS and the reason why it's a multi-stage approach.
> >>
> >> Also, what about any support libraries in use in this ecosystem ?
> >
> > Like all environments, I guess it would depend on what the
> requirement
> > is to meet latest C++ standards?
>
> It may be required in some cases.
>

And it may not be required.

> And even if it is not required then if everything else is equal then
they
> will pick the platform with the best compiler support (and support
for
> newer standards is part of compiler support).
>

Assuming developers are free to pick whatever tools and/or platforms
and/or products they feel are coolest for them.

> And note that it is not just the specific application.
> But also all the libraries it use.
>
> If it is 1 application and 20 libraries, then if just if 1 out of
the 21
> requires a super uptodate C++ then ...
>
> Arne
>

Or you look for alternative approaches. There is always more than 1
way to implement anything.

Using the latest and greatest versions of everything can potentially
have a hidden cost as well i.e. those who break trails are the ones to
receive the first arrows.

That is why many shops will implement a N-1 version strategy, not only
because the N-1 issues are well known, but there are sometimes new
licensing costs for the upgrades.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Arne Vajhøj
2017-03-27 03:06:42 UTC
Reply
Permalink
Raw Message
On 3/26/2017 10:06 PM, Kerry Main wrote:
>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> Arne Vajhøj via Info-vax
>> On 3/26/2017 9:15 PM, Kerry Main wrote:
>>> Like all environments, I guess it would depend on what the
>> requirement
>>> is to meet latest C++ standards?
>>
>> It may be required in some cases.
>
> And it may not be required.
>
>> And even if it is not required then if everything else is equal then they
>> will pick the platform with the best compiler support (and support for
>> newer standards is part of compiler support).
>
> Assuming developers are free to pick whatever tools and/or platforms
> and/or products they feel are coolest for them.

No - assuming that management are concerned about
the future viability of the technologies chosen.

>> And note that it is not just the specific application.
>> But also all the libraries it use.
>>
>> If it is 1 application and 20 libraries, then if just if 1 out of the 21
>> requires a super uptodate C++ then ...
>
> Or you look for alternative approaches. There is always more than 1
> way to implement anything.

Yes. But having to pick second choice because first choice is not
available decreases the chance that the platform get chosen.

> Using the latest and greatest versions of everything can potentially
> have a hidden cost as well i.e. those who break trails are the ones to
> receive the first arrows.
>
> That is why many shops will implement a N-1 version strategy, not only
> because the N-1 issues are well known, but there are sometimes new
> licensing costs for the upgrades.

True.

Leading edge can easily become bleeding edge.

But I don't think that is the case here.

I believe the problem is that the compiler here
is based on C++98 aka a 19 years old standard.

C++11 should not be considered bleeding edge
anymore.

Implementing C++17 draft would be bleeding edge.

Arne
Kerry Main
2017-03-28 03:00:43 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Arne Vajhøj via Info-vax
> Sent: March 26, 2017 11:07 PM
> To: info-***@rbnsn.com
> Cc: Arne Vajhøj <***@vajhoej.dk>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 3/26/2017 10:06 PM, Kerry Main wrote:
> >> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Arne
> >> Vajhøj via Info-vax On 3/26/2017 9:15 PM, Kerry Main wrote:
> >>> Like all environments, I guess it would depend on what the
> >> requirement
> >>> is to meet latest C++ standards?
> >>
> >> It may be required in some cases.
> >
> > And it may not be required.
> >
> >> And even if it is not required then if everything else is equal
then
> >> they will pick the platform with the best compiler support (and
> >> support for newer standards is part of compiler support).
> >
> > Assuming developers are free to pick whatever tools and/or
> platforms
> > and/or products they feel are coolest for them.
>
> No - assuming that management are concerned about the future
> viability of the technologies chosen.
>
> >> And note that it is not just the specific application.
> >> But also all the libraries it use.
> >>
> >> If it is 1 application and 20 libraries, then if just if 1 out of
the
> >> 21 requires a super uptodate C++ then ...
> >
> > Or you look for alternative approaches. There is always more than
1
> > way to implement anything.
>
> Yes. But having to pick second choice because first choice is not
> available decreases the chance that the platform get chosen.
>
> > Using the latest and greatest versions of everything can
potentially
> > have a hidden cost as well i.e. those who break trails are the
ones to
> > receive the first arrows.
> >
> > That is why many shops will implement a N-1 version strategy, not
> only
> > because the N-1 issues are well known, but there are sometimes
> new
> > licensing costs for the upgrades.
>
> True.
>
> Leading edge can easily become bleeding edge.
>
> But I don't think that is the case here.
>
> I believe the problem is that the compiler here is based on C++98
aka a
> 19 years old standard.
>
> C++11 should not be considered bleeding edge
> anymore.
>
> Implementing C++17 draft would be bleeding edge.
>
> Arne
>

Imho, one does not choose something as critical as a platform based
solely on a compiler version issue.

The exception would be if the platform provider stated they had no
plans to upgrade that compiler.

Solutions engineering looks at the top to bottom solution not just the
developer driven wish lists.

John would have to comment on where he see's C++11 support on OpenVMS.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Stephen Hoffman
2017-03-28 14:49:42 UTC
Reply
Permalink
Raw Message
On 2017-03-28 03:00:43 +0000, Kerry Main said:

> Imho, one does not choose something as critical as a platform based
> solely on a compiler version issue.

Solely? No. In practice? It's a fundamental part of most selection
decisions, because it shows how serious the vendor is about application
development.

You are very comfortable with what amounts to trailing-edge tech, and
you're skeptical about even established tools and practices; DVCS,
hosted providers, etc.

If that works for Stark, great. For folks doing new deployments and
wholly new applications, old tools and command-line development and
older API support is not going to be a big draw.

VSI knows more than a few updates are needed, and moving to Clang
directly will address many of those issues for C and C++ support in the
compilers — though not source-level compatibility with the older
OpenVMS extensions, and the updates for the standard library and the
updates and additions of the now-common add-on libraries are each large
projects.



--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2017-04-01 14:31:54 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: March 28, 2017 10:50 AM
> To: info-***@rbnsn.com
> Cc: Stephen Hoffman <***@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 2017-03-28 03:00:43 +0000, Kerry Main said:
>
> > Imho, one does not choose something as critical as a platform based
> > solely on a compiler version issue.
>
> Solely? No. In practice? It's a fundamental part of most selection
> decisions, because it shows how serious the vendor is about
> application development.
>

ROTFL .. when an application developer has the power to state we need to change our entre platform strategy because they want to use a cool new compiler or tool feature that is only available on a specific platform that is considered non-strategic to the companies current IT platform strategy, then you know the IT dept. is in trouble.

> You are very comfortable with what amounts to trailing-edge tech, and
> you're skeptical about even established tools and practices; DVCS,
> hosted providers, etc.
>

The IT world is currently recovering from a heavily distributed, wild west world to one in which there is a much greater balanced focus on what is better done centralized vs. what is better done distributed. Huge increases in compute, memory and storage capacities and speeds are big factors in this trend as well as the need to improve resource security, mgmt. and costs.

Imho, source code mgmt. is one aspect that can be done much more securely in a more centralized multi-site HA, active-active environment, but each Customer needs to determine which is best for their environment.

This is an argument that has been ongoing for decades.

> If that works for Stark, great. For folks doing new deployments and
> wholly new applications, old tools and command-line development
> and older API support is not going to be a big draw.
>
> VSI knows more than a few updates are needed, and moving to Clang
> directly will address many of those issues for C and C++ support in the
> compilers — though not source-level compatibility with the older
> OpenVMS extensions, and the updates for the standard library and
> the updates and additions of the now-common add-on libraries are
> each large projects.
>

Every platform has pro's and con's.

Each company needs to make their own decisions on their platform choice for their critical applications.

For many companies, having the absolute latest and coolest compilers and tools is not a primary factor in those decisions.

YMMV.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Stephen Hoffman
2017-04-01 19:57:59 UTC
Reply
Permalink
Raw Message
On 2017-04-01 14:31:54 +0000, Kerry Main said:

>
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> Stephen Hoffman via Info-vax
>> Sent: March 28, 2017 10:50 AM
>> To: info-***@rbnsn.com
>> Cc: Stephen Hoffman <***@hoffmanlabs.invalid>
>> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
>> party / developers?
>>
>> On 2017-03-28 03:00:43 +0000, Kerry Main said:
>>
>>> Imho, one does not choose something as critical as a platform based
>>> solely on a compiler version issue.
>>
>> Solely? No. In practice? It's a fundamental part of most selection
>> decisions, because it shows how serious the vendor is about application
>> development.
>
> ROTFL .. when an application developer has the power to state we need
> to change our entre platform strategy because they want to use a cool
> new compiler or tool feature that is only available on a specific
> platform that is considered non-strategic to the companies current IT
> platform strategy, then you know the IT dept. is in trouble.

So... The folks in those other environments and making those selection
decisions are going to be selecting or moving to OpenVMS, because
OpenVMS provides... um... worse?

Yes, there are trade-offs. Yes, the tools are never the only reason.
Vendor perceptions are a big part of migrations. What leads to those
vendor perceptions? Well... Among other details... available
compilers. The tools are never the sole factor. But problematic
development tools? Those are never popular with ISVs or developers.

As for the existing folks using OpenVMS, they're operating within the
existing constraints. They — like the folks that might consider
moving to OpenVMS — are not making these decisions lightly. But I'm
still dealing with sites that are moving off of OpenVMS. Yes, the
folks at the sites are fully aware of VSI and the port, too.

> Every platform has pro's and con's.
>
> Each company needs to make their own decisions on their platform choice
> for their critical applications.
> For many companies, having the absolute latest and coolest compilers
> and tools is not a primary factor in those decisions.

Ayup, But then not having those features is a problem for all but the
installed base.


--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2017-04-01 20:00:59 UTC
Reply
Permalink
Raw Message
On 2017-04-01 19:57:59 +0000, Stephen Hoffman said:

> ...But then not having those features is a problem for all but the
> installed base.

And over time... increasingly for various in the installed base, too.
The dependency chains involved in cross-platform and porting to
OpenVMS are getting longer and more complex, for instance.

--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2017-04-01 20:31:32 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: April 1, 2017 4:01 PM
> To: info-***@rbnsn.com
> Cc: Stephen Hoffman <***@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 2017-04-01 19:57:59 +0000, Stephen Hoffman said:
>
> > ...But then not having those features is a problem for all but the
> > installed base.
>
> And over time... increasingly for various in the installed base,
too.
> The dependency chains involved in cross-platform and porting to
> OpenVMS are getting longer and more complex, for instance.
>

Your opinion.

One could also argue that all of the work VSI is doing in terms of
things like LLVM, VSI/community open source porting, adopting X86-64
standards, and working with vendors like eCube will make the gaps
smaller over time.

Given that 2017-2020 are transition "establish a beach head" years, In
the 2020+ timeframe, will the gaps be as large as they are today?

Imho, no, but then, everyone is entitled to their own opinion.

And yes, we all know there are lots of speed bumps ahead.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Forster, Michael
2017-04-05 22:56:54 UTC
Reply
Permalink
Raw Message
All these great efforts ideally may enable some sites to remain. Others need to migrate to leading market share vendors. Regardless of virtues. Sad.


Michael Forster
Enterprise Storage and IDX Architect | Information Services
Medical College of Wisconsin
O: (414) 955-4967 | ***@mcw.edu


________________________________________
From: Info-vax <info-vax-***@rbnsn.com> on behalf of Kerry Main via Info-vax <info-***@rbnsn.com>
Sent: Saturday, April 1, 2017 3:31:32 PM
To: 'comp.os.vms to email gateway'
Cc: Kerry Main
Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third party / developers?

> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: April 1, 2017 4:01 PM
> To: info-***@rbnsn.com
> Cc: Stephen Hoffman <***@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 2017-04-01 19:57:59 +0000, Stephen Hoffman said:
>
> > ...But then not having those features is a problem for all but the
> > installed base.
>
> And over time... increasingly for various in the installed base,
too.
> The dependency chains involved in cross-platform and porting to
> OpenVMS are getting longer and more complex, for instance.
>

Your opinion.

One could also argue that all of the work VSI is doing in terms of
things like LLVM, VSI/community open source porting, adopting X86-64
standards, and working with vendors like eCube will make the gaps
smaller over time.

Given that 2017-2020 are transition "establish a beach head" years, In
the 2020+ timeframe, will the gaps be as large as they are today?

Imho, no, but then, everyone is entitled to their own opinion.

And yes, we all know there are lots of speed bumps ahead.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Kerry Main
2017-04-06 00:14:44 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Forster, Michael [mailto:***@mcw.edu]
> Sent: April 5, 2017 6:57 PM
> To: comp.os.vms to email gateway <info-***@rbnsn.com>
> Cc: Kerry Main <***@gmail.com>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> All these great efforts ideally may enable some sites to remain.
Others
> need to migrate to leading market share vendors. Regardless of
> virtues. Sad.
>
>
> Michael Forster
> Enterprise Storage and IDX Architect | Information Services Medical
> College of Wisconsin
> O: (414) 955-4967 | ***@mcw.edu
>

Well, unfortunately, the "follow the lemmings " strategy is hard to
combat.

Similar to another lemmings strategy i.e. "Public Clouds will solve
all our issues and will be much more cost effective that what we have
now", sometimes its like talking to teenagers who think they know
better.

These types are often well meaning, but they just have to find out for
themselves that the grass is not always greener on the other side.

Heck, just look at those who thought they were going to get better AND
cheaper health care in the US with Trumpcare.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
David Froble
2017-04-06 02:16:12 UTC
Reply
Permalink
Raw Message
Kerry Main wrote:

> Heck, just look at those who thought they were going to get better AND
> cheaper health care in the US with Trumpcare.

So, what's your problem? The proposal was going to get cheaper (less) and
better for the medical insurance companies. You just got to know who Trump is
talking to.
Kerry Main
2017-04-06 13:23:04 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> David Froble via Info-vax
> Sent: April 5, 2017 10:16 PM
> To: info-***@rbnsn.com
> Cc: David Froble <***@tsoft-inc.com>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> Kerry Main wrote:
>
> > Heck, just look at those who thought they were going to get better
> AND
> > cheaper health care in the US with Trumpcare.
>
> So, what's your problem? The proposal was going to get cheaper
(less)
> and better for the medical insurance companies. You just got to
know
> who Trump is talking to.
>

OT>
I am just not a fan of bait and switch politicians who prey on the
little guy, build up their hopes and then crush them with the reality
of what their whole intent really was (making $'s for big business and
say anything to win).

No one is talking about it yet, but after such a big build up, and
even though they will try and put on a good face, Trump supporters are
in for a world of disappointment.
End OT>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Jan-Erik Soderholm
2017-04-06 14:11:04 UTC
Reply
Permalink
Raw Message
Den 2017-04-06 kl. 15:23, skrev Kerry Main:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> David Froble via Info-vax
>> Sent: April 5, 2017 10:16 PM
>> To: info-***@rbnsn.com
>> Cc: David Froble <***@tsoft-inc.com>
>> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
>> party / developers?
>>
>> Kerry Main wrote:
>>
>>> Heck, just look at those who thought they were going to get better
>> AND
>>> cheaper health care in the US with Trumpcare.
>>
>> So, what's your problem? The proposal was going to get cheaper
> (less)
>> and better for the medical insurance companies. You just got to
> know
>> who Trump is talking to.
>>
>
> OT>
> I am just not a fan of bait and switch politicians who prey on the
> little guy, build up their hopes and then crush them with the reality
> of what their whole intent really was (making $'s for big business and
> say anything to win).
>
> No one is talking about it yet, but after such a big build up, and
> even though they will try and put on a good face, Trump supporters are
> in for a world of disappointment.
> End OT>
>

I think that Trump actually belived in what he was promising.
He was never trying to mislead anyone, he was simply wrong.

Of course the peolple voting for him (having the same misbeliefs
as Trump) are to be blaimed (if anyone is to be blaimed).
David Froble
2017-04-06 15:01:56 UTC
Reply
Permalink
Raw Message
Kerry Main wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> David Froble via Info-vax
>> Sent: April 5, 2017 10:16 PM
>> To: info-***@rbnsn.com
>> Cc: David Froble <***@tsoft-inc.com>
>> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
>> party / developers?
>>
>> Kerry Main wrote:
>>
>>> Heck, just look at those who thought they were going to get better
>> AND
>>> cheaper health care in the US with Trumpcare.
>> So, what's your problem? The proposal was going to get cheaper
> (less)
>> and better for the medical insurance companies. You just got to
> know
>> who Trump is talking to.
>>
>
> OT>
> I am just not a fan of bait and switch politicians who prey on the
> little guy, build up their hopes and then crush them with the reality
> of what their whole intent really was (making $'s for big business and
> say anything to win).
>
> No one is talking about it yet, but after such a big build up, and
> even though they will try and put on a good face, Trump supporters are
> in for a world of disappointment.
> End OT>

Yes, off topic, but a good real life lesson for people.

People need to look at actions more, and listen to promises less.

I may have been heard saying back on election day that perhaps things had to get
worse before they get better. Looks like that's so.

A democracy isn't always a good thing for those who think they are in charge,
when they need to depend on the votes of the people. The Democratic Party
leadership thought they could dictate to the electorate just who they had to
vote for. Didn't work out too well for them. They are the real problem.

I could go on for pages, but, sadly, I don't think it matters ....
Bob Koehler
2017-04-07 13:32:01 UTC
Reply
Permalink
Raw Message
In article <oc5l3f$emv$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>
> A democracy isn't always a good thing for those who think they are in charge,
> when they need to depend on the votes of the people. The Democratic Party
> leadership thought they could dictate to the electorate just who they had to
> vote for. Didn't work out too well for them. They are the real problem.
>

There's a difference? Seems like the Republican party heads didn't
exactly pick Donald.
David Froble
2017-04-07 14:31:44 UTC
Reply
Permalink
Raw Message
Bob Koehler wrote:
> In article <oc5l3f$emv$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
>> A democracy isn't always a good thing for those who think they are in charge,
>> when they need to depend on the votes of the people. The Democratic Party
>> leadership thought they could dictate to the electorate just who they had to
>> vote for. Didn't work out too well for them. They are the real problem.
>>
>
> There's a difference? Seems like the Republican party heads didn't
> exactly pick Donald.
>

Yes Bob, there is a difference. The Dems tried to force Hillery down our
throats. The Republicans didn't want Donald, but, the people did. Now, you
tell me whose ass is sitting in the White House?
e***@gmail.com
2017-04-07 14:46:59 UTC
Reply
Permalink
Raw Message
On Friday, 7 April 2017 15:31:47 UTC+1, David Froble wrote:

> Yes Bob, there is a difference. The Dems tried to force Hillery down our
> throats. The Republicans didn't want Donald, but, the people did. Now, you
> tell me whose ass is sitting in the White House?

The one who lost the popular vote? He won the election fairly but it is disingenuous of you to claim he is the candidate the people wanted.
Kerry Main
2017-04-07 15:25:45 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> ergamenes--- via Info-vax
> Sent: April 7, 2017 10:47 AM
> To: info-***@rbnsn.com
> Cc: ***@gmail.com
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On Friday, 7 April 2017 15:31:47 UTC+1, David Froble wrote:
>
> > Yes Bob, there is a difference. The Dems tried to force Hillery
down
> > our throats. The Republicans didn't want Donald, but, the people
> did.
> > Now, you tell me whose ass is sitting in the White House?
>
> The one who lost the popular vote? He won the election fairly but it
is
> disingenuous of you to claim he is the candidate the people wanted.

OT ON>
While hind sight showed there was certainly lots wrong with the Dem's
strategy, even after the bus tapes, and all of the other Trump
mishaps, the religious right (men and women) held their noses and
voted for Trump for one reason only - the ultra conservative Supreme
Court pick. All the craziness over email released by Russians was
simply fodder to more easily justify picking Trump.

They know Trump will likely be gone in 4 years (or less), but their
ultra-conservative Supreme court pick will be in place for 30+ years.
Time will tell what impact this pick has on things like corporations
vs. little guy, women's rights etc.

As some have stated, the GOP did not win, the Dem's lost. If Biden or
even Bernie Sanders had been the Dem's pick, there would have been a
different party in the White House. Likely a landslide.

Anyway, water under the bridge, time to move on. Hopefully, Trump can
adapt and learn.
OT OFF>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Bob Koehler
2017-04-10 13:35:36 UTC
Reply
Permalink
Raw Message
In article <mailman.3.1491578809.15672.info-***@rbnsn.com>, "Kerry Main" <***@gmail.com> writes:
>
> As some have stated, the GOP did not win, the Dem's lost. If Biden or
> even Bernie Sanders had been the Dem's pick, there would have been a
> different party in the White House. Likely a landslide.

IIRC, a little over 8 years ago, the Democratic leadership was
supporting Hillary, and she lost that one, too.

I still think there are better women in bother parties to be
president that Hillary.
Kerry Main
2017-04-10 18:30:46 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of Bob
> Koehler via Info-vax
> Sent: April 10, 2017 9:36 AM
> To: info-***@rbnsn.com
> Cc: Bob Koehler <***@eisner.nospam.decuserve.org>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third party
> / developers?
>
> In article <mailman.3.1491578809.15672.info-
> ***@rbnsn.com>, "Kerry Main"
> <***@gmail.com> writes:
> >
> > As some have stated, the GOP did not win, the Dem's lost. If Biden or
> > even Bernie Sanders had been the Dem's pick, there would have been
> a
> > different party in the White House. Likely a landslide.
>
> IIRC, a little over 8 years ago, the Democratic leadership was
> supporting Hillary, and she lost that one, too.
>
> I still think there are better women in bother parties to be
> president that Hillary.
>

OT ON>

>From outsider looking in>

Would have been an interesting period if Dem's had won. Bernie likely head of Education Dept, and Elizabeth Warren likely head of Treasury Dept (SEC/Wall Street would have had a fit).

Just think of all the $'s saved on weekly golf fee's!

Ah well, 2018 will be interesting year to see if GOP in Congress can drop 24M US voters health care and then expect to get re-elected. By then, the FBI will also likely have released results of Russian criminal investigation as well. Anyone want to bet against certain tax returns going to be subpoenaed?
OT OFF>

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Bob Koehler
2017-04-11 13:15:54 UTC
Reply
Permalink
Raw Message
In article <mailman.8.1491849107.15672.info-***@rbnsn.com>, "Kerry Main" <***@gmail.com> writes:
>
> Ah well, 2018 will be interesting year to see if GOP in Congress can =
> drop 24M US voters health care and then expect to get re-elected. By =
> then, the FBI will also likely have released results of Russian criminal =
> investigation as well. Anyone want to bet against certain tax returns =
> going to be subpoenaed?

We don't have to wait. There's a special election to replace one of
Trump's folks, in Koch's home town, where Trump won by a 27% margin,
and the Republican "shoe in" candidate is in real trouble with the
voters.
David Froble
2017-04-07 22:45:17 UTC
Reply
Permalink
Raw Message
***@gmail.com wrote:
> On Friday, 7 April 2017 15:31:47 UTC+1, David Froble wrote:
>
>> Yes Bob, there is a difference. The Dems tried to force Hillery down our
>> throats. The Republicans didn't want Donald, but, the people did. Now, you
>> tell me whose ass is sitting in the White House?
>
> The one who lost the popular vote? He won the election fairly but it is disingenuous of you to claim he is the candidate the people wanted.

From a Republican perspective, he was who the people picked. The overall
majority voting against him just shows how bad a choice we had.

I blame the Dem leaders, and the "super delegates". And the people who voted
for Hilary in the primary election, just because she was a woman. Makes you
wonder just what some people think the leader of a country should be, and what
qualifications should be important.
Bob Koehler
2017-04-10 13:33:41 UTC
Reply
Permalink
Raw Message
In article <oc87mp$3pq$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:

> Yes Bob, there is a difference. The Dems tried to force Hillery down our
> throats. The Republicans didn't want Donald, but, the people did.

Nope. Don't see the difference. The Democractic leadership wanted
Hillary and the Republicans wanted anybody but Donald. Democatic
leadership lost, and Republican leadership lost.

And the people voted for Hilary, whether the electoral collage liked
it or not.
Bob Koehler
2017-04-07 13:30:50 UTC
Reply
Permalink
Raw Message
In article <oc487m$qq8$***@dont-email.me>, David Froble <***@tsoft-inc.com> writes:
> Kerry Main wrote:
>
>> Heck, just look at those who thought they were going to get better AND
>> cheaper health care in the US with Trumpcare.
>
> So, what's your problem? The proposal was going to get cheaper (less) and
> better for the medical insurance companies. You just got to know who Trump is
> talking to.

So when he said everybody would be covered, we should have heard
"Every S.O.B. out there will be paying you money".
John Reagan
2017-03-28 15:42:12 UTC
Reply
Permalink
Raw Message
On Monday, March 27, 2017 at 11:05:04 PM UTC-4, Kerry Main wrote:

>
> John would have to comment on where he see's C++11 support on OpenVMS.
>

The roadmap says that is for x86 (still no plans for Itanium or Alpha work). As I've mentioned, we'll be using clang as our C++ compiler for x86. And as Hoff reinforced, that also means library work for the STL, add-ons, retrofitting OpenVMS features into clang as needed, and more header changes (C header files have to work for both our C frontend and the clang frontend for example). We've already been doing early design/work in that area.

Beyond that, the debugger will need some serious pounding. I've been thinking about replacing/augmenting the VMS debugger with LLDB but that comes with some serious dependencies as well (it is VERY Python centric and relies heavily on the LLVM JIT). Not sure how that might pan out.
Stephen Hoffman
2017-03-29 13:00:30 UTC
Reply
Permalink
Raw Message
On 2017-03-28 15:42:12 +0000, John Reagan said:

> On Monday, March 27, 2017 at 11:05:04 PM UTC-4, Kerry Main wrote:
>
>>
>> John would have to comment on where he see's C++11 support on OpenVMS.
>>
>
> The roadmap says that is for x86 (still no plans for Itanium or Alpha
> work). As I've mentioned, we'll be using clang as our C++ compiler for
> x86. And as Hoff reinforced, that also means library work for the STL,
> add-ons, retrofitting OpenVMS features into clang as needed, and more
> header changes (C header files have to work for both our C frontend and
> the clang frontend for example). We've already been doing early
> design/work in that area.
>
> Beyond that, the debugger will need some serious pounding. I've been
> thinking about replacing/augmenting the VMS debugger with LLDB but that
> comes with some serious dependencies as well (it is VERY Python centric
> and relies heavily on the LLVM JIT). Not sure how that might pan out.

That's an easy one. You've decided to get on the llvm path. Get all
the way onto the path. llvm/lldb/Python. Beyond any benefits of
familiarity to the installed base? Being different and being less
isn't a selling point. Being competitive or being better is. With
llvm/lldb/Python, VSI or third-party IDE providers are better able to
integrate the compiler and the debugger, likely largely by following
what Xcode has done. Plus we get Python in the base distro. Win,
win, win. Yeah, we get to learn a new command syntax for the
debugger, too. But... Python in the debugger. Python in the distro.

But as you already well know, I'm more than willing to chuck the old
VAX C stuff. DEC/Compaq/HP/HPE/VSI C increasingly looking like VAX
C, too. The old morass of headers and the giblets for Alpha and
Itanium servers should all be headed for deprecation and eventual
replacement with C11 and C++17 support via clang, with the minimal
necessary extensions. Simplify, don't add more conditionals. With
that, you're able to move forward more quickly. Yeah, we get to drag
our C and C++ code forward. Given we're running ~C99 and C++98, we
already need to do that. We get easier and faster source code ports
in and out, too.

Porting forward to current-generation tools is still easier than
porting off of OpenVMS, too.

In for a pfennig, in for a £. Or in for a €. Whatever.




--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-03-30 00:08:30 UTC
Reply
Permalink
Raw Message
On 2017-03-29, Stephen Hoffman <***@hoffmanlabs.invalid> wrote:
> On 2017-03-28 15:42:12 +0000, John Reagan said:
>>
>> Beyond that, the debugger will need some serious pounding. I've been
>> thinking about replacing/augmenting the VMS debugger with LLDB but that
>> comes with some serious dependencies as well (it is VERY Python centric
>> and relies heavily on the LLVM JIT). Not sure how that might pan out.
>

And relies on clang as well IIRC.

BTW John, are you planning on using LLD or the VMS linker on x86-64 ?

> That's an easy one. You've decided to get on the llvm path. Get all
> the way onto the path. llvm/lldb/Python. Beyond any benefits of
> familiarity to the installed base? Being different and being less
> isn't a selling point. Being competitive or being better is. With
> llvm/lldb/Python, VSI or third-party IDE providers are better able to
> integrate the compiler and the debugger, likely largely by following
> what Xcode has done. Plus we get Python in the base distro. Win,
> win, win. Yeah, we get to learn a new command syntax for the
> debugger, too. But... Python in the debugger. Python in the distro.
>

I suspect John is discovering that some of the LLVM projects are not
as portable to different environments as the core libraries are.

I don't remember the details, but I do remember that I had problems
building lldb and some of the other add-on projects on an older
version of Linux and I eventually gave up and just built the core
LLVM libraries and clang instead.

It looks to me like some of the LLVM add-on projects developers are
stuffing the very latest OS features into the code base even when
they may not be strictly required. Certainly, building gcc/binutils
and gdb on these same older Linux versions "just works".

I also suspect, given the rapid development pace of some of these
add-on projects, that John is probably thinking about waiting until
he's on the current LLVM versions. (IIRC, current lldb versions
require a current LLVM toolchain version.)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
John Reagan
2017-03-30 03:49:42 UTC
Reply
Permalink
Raw Message
On Wednesday, March 29, 2017 at 8:11:30 PM UTC-4, Simon Clubley wrote:
> On 2017-03-29, Stephen Hoffman <***@hoffmanlabs.invalid> wrote:
> > On 2017-03-28 15:42:12 +0000, John Reagan said:
> >>
> >> Beyond that, the debugger will need some serious pounding. I've been
> >> thinking about replacing/augmenting the VMS debugger with LLDB but that
> >> comes with some serious dependencies as well (it is VERY Python centric
> >> and relies heavily on the LLVM JIT). Not sure how that might pan out.
> >
>
> And relies on clang as well IIRC.

and that is why adding support for the other languages is non-trivial

>
> BTW John, are you planning on using LLD or the VMS linker on x86-64 ?

The VMS linker. There are too many OpenVMS-isms (symbol vectors, options files, and such) to want to use LLD. The VMS Itanium linker already knows ELF so the work for x86 isn't that much this time around.

>
> > That's an easy one. You've decided to get on the llvm path. Get all
> > the way onto the path. llvm/lldb/Python. Beyond any benefits of
> > familiarity to the installed base? Being different and being less
> > isn't a selling point. Being competitive or being better is. With
> > llvm/lldb/Python, VSI or third-party IDE providers are better able to
> > integrate the compiler and the debugger, likely largely by following
> > what Xcode has done. Plus we get Python in the base distro. Win,
> > win, win. Yeah, we get to learn a new command syntax for the
> > debugger, too. But... Python in the debugger. Python in the distro.
> >
>
> I suspect John is discovering that some of the LLVM projects are not
> as portable to different environments as the core libraries are.
>
> I don't remember the details, but I do remember that I had problems
> building lldb and some of the other add-on projects on an older
> version of Linux and I eventually gave up and just built the core
> LLVM libraries and clang instead.
>
> It looks to me like some of the LLVM add-on projects developers are
> stuffing the very latest OS features into the code base even when
> they may not be strictly required. Certainly, building gcc/binutils
> and gdb on these same older Linux versions "just works".
>
> I also suspect, given the rapid development pace of some of these
> add-on projects, that John is probably thinking about waiting until
> he's on the current LLVM versions. (IIRC, current lldb versions
> require a current LLVM toolchain version.)
>
> Simon.
>
> --
> Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world
Kerry Main
2017-04-01 14:46:04 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> John Reagan via Info-vax
> Sent: March 28, 2017 11:42 AM
> To: info-***@rbnsn.com
> Cc: John Reagan <***@gmail.com>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On Monday, March 27, 2017 at 11:05:04 PM UTC-4, Kerry Main wrote:
>
> >
> > John would have to comment on where he see's C++11 support on
> OpenVMS.
> >
>
> The roadmap says that is for x86 (still no plans for Itanium or
Alpha
> work). As I've mentioned, we'll be using clang as our C++ compiler
for
> x86. And as Hoff reinforced, that also means library work for the
STL,
> add-ons, retrofitting OpenVMS features into clang as needed, and
> more header changes (C header files have to work for both our C
> frontend and the clang frontend for example). We've already been
> doing early design/work in that area.
>
> Beyond that, the debugger will need some serious pounding. I've
> been thinking about replacing/augmenting the VMS debugger with
> LLDB but that comes with some serious dependencies as well (it is
> VERY Python centric and relies heavily on the LLVM JIT). Not sure
how
> that might pan out.
>

Nice update.

Btw, my vote would be to do minimal major compiler fixes to Alpha /
Itanium platforms.

Imho, the focus should be on future and improving all the compilers on
OpenVMS X86-64.

Similar to the stake in the ground like Oracle has i.e. "terminal
release" strategy for OpenVMS Alpha V8.4-2L1, adopt a similar strategy
for the various Alpha/Itanium compilers. Pick a version, and other
than serious bug fixes, that's it.

Here is Oracles view of a terminal release and terminal release patch:
http://www.oracleappshub.com/aol/oracle-terminal-releases-and-terminal
-patchsetscpu/

If Alpha/Itanium Customers are that concerned about having the latest
compiler versions in the future, then they should be looking at
migrating to OpenVMS X86-64.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Arne Vajhøj
2017-03-27 00:41:07 UTC
Reply
Permalink
Raw Message
On 3/26/2017 6:49 PM, Kerry Main wrote:
> Part of the challenge facing some game designers is that they are
> still in the traditional (ok, I call it legacy) shared nothing,
> heavily distributed network architecture designs.
>
> In addition, game developers need to address data consistency,
> availability, node mgmt., replication, HA, DR etc. in their
> application code, which makes the app developers role much more
> complex.
>
> The world is rapidly moving towards a combo of regional based zones
> (dual sites in AP, NA, EMEA), with heavily centralized, high
> throughput, ultra low latency server designs in each of these zones.
>
>
> With OpenVMS clusters, a great deal of the App developers tasks are
> simplified because a number of these developer activities (data
> consistency, node mgmt., replication, HA, etc.) are handled at the OS
> level. The developer can focus on code optimization, quality i.e.
> spend more time on their App which is where their core focus should
> be.

Hmmmm.

Shared file systems, DLM etc. are available on other platforms
as well.

Various libraries provide much more sophisticated cluster
features than VMS does.

I can not imagine application developers saving a single
line of code by using VMS.

Sure they may need some libraries. But so what. The
application developer does not care much whether it is
the OS vendor or Apache that provides the functionality.

Arne
Kerry Main
2017-03-27 01:54:03 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Arne Vajhøj via Info-vax
> Sent: March 26, 2017 8:41 PM
> To: info-***@rbnsn.com
> Cc: Arne Vajhøj <***@vajhoej.dk>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 3/26/2017 6:49 PM, Kerry Main wrote:
> > Part of the challenge facing some game designers is that they are
> > still in the traditional (ok, I call it legacy) shared nothing,
> > heavily distributed network architecture designs.
> >
> > In addition, game developers need to address data consistency,
> > availability, node mgmt., replication, HA, DR etc. in their
> > application code, which makes the app developers role much more
> > complex.
> >
> > The world is rapidly moving towards a combo of regional based
zones
> > (dual sites in AP, NA, EMEA), with heavily centralized, high
> > throughput, ultra low latency server designs in each of these
zones.
> >
> >
> > With OpenVMS clusters, a great deal of the App developers tasks
are
> > simplified because a number of these developer activities (data
> > consistency, node mgmt., replication, HA, etc.) are handled at the
OS
> > level. The developer can focus on code optimization, quality i.e.
> > spend more time on their App which is where their core focus
should
> > be.
>
> Hmmmm.
>
> Shared file systems, DLM etc. are available on other platforms as
well.
>

Linux/GFS is still a rather immature implementation from what I have
seen.

> Various libraries provide much more sophisticated cluster features
> than VMS does.
>
> I can not imagine application developers saving a single line of
code by
> using VMS.
>

So how do you think App developers manage the addition /loss of
servers in their environment?

Answer - in their app code.

How do they manage data consistency across many nodes if not in their
application code?

> Sure they may need some libraries. But so what. The application
> developer does not care much whether it is the OS vendor or Apache
> that provides the functionality.
>
> Arne

Suggest reading / viewing the following for how distributed app
developers need to build into their App code many of the things that
OpenVMS developers do not have to worry about because it is handled at
the OS level.

http://highscalability.com/blog/2015/10/12/making-the-case-for-buildin
g-scalable-stateful-services-in-t.html

https://www.youtube.com/watch?v=H0i_bXKwujQ


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Arne Vajhøj
2017-03-27 02:54:57 UTC
Reply
Permalink
Raw Message
On 3/26/2017 9:54 PM, Kerry Main wrote:
>> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
>> Arne Vajhøj via Info-vax
>> Sure they may need some libraries. But so what. The application
>> developer does not care much whether it is the OS vendor or Apache
>> that provides the functionality.
>
> Suggest reading / viewing the following for how distributed app
> developers need to build into their App code many of the things that
> OpenVMS developers do not have to worry about because it is handled at
> the OS level.
>
> http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html

????

The two main concepts here are:
* distributed cache
* and an actor model framework

Which have something in common:
* VMS does not provide them
* various libraries do provide them

Arne
Kerry Main
2017-03-27 03:09:39 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Arne Vajhøj via Info-vax
> Sent: March 26, 2017 10:55 PM
> To: info-***@rbnsn.com
> Cc: Arne Vajhøj <***@vajhoej.dk>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> On 3/26/2017 9:54 PM, Kerry Main wrote:
> >> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> Arne
> >> Vajhøj via Info-vax Sure they may need some libraries. But so
what.
> >> The application developer does not care much whether it is the OS
> >> vendor or Apache that provides the functionality.
> >
> > Suggest reading / viewing the following for how distributed app
> > developers need to build into their App code many of the things
that
> > OpenVMS developers do not have to worry about because it is
> handled at
> > the OS level.
> >
> > http://highscalability.com/blog/2015/10/12/making-the-case-for-
> buildin
> > g-scalable-stateful-services-in-t.html
>
> ????
>
> The two main concepts here are:
> * distributed cache
> * and an actor model framework
>
> Which have something in common:
> * VMS does not provide them
> * various libraries do provide them
>
> Arne
>

Extract: "You’ll recognize most of the ideas--Sticky Sessions, Data
Shipping Paradigm, Function Shipping Paradigm, Data Locality, CAP,
Cluster Membership, Gossip Protocols, Consistent Hashing,"

All of these need to be done at the App code level in a shared nothing
distributed model. The video explains how the App developers can do
these functions - in their code.

Most of this can be done at the OS level in a centralized, shared disk
A-A cluster with a DLM, HBVS, and A-A DB.

To better explain the differences / benefits between shared disk and
shared nothing arch's, check out this WP:
http://www.scaledb.com/wp-content/uploads/2015/11/Shared-Nohing-vs-Sha
red-Disk-WP_SDvSN.pdf


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
David Froble
2017-03-27 03:52:49 UTC
Reply
Permalink
Raw Message
Kerry Main wrote:

> Extract: "You’ll recognize most of the ideas--Sticky Sessions, Data
> Shipping Paradigm, Function Shipping Paradigm, Data Locality, CAP,
> Cluster Membership, Gossip Protocols, Consistent Hashing,"
>
> All of these need to be done at the App code level in a shared nothing
> distributed model. The video explains how the App developers can do
> these functions - in their code.
>
> Most of this can be done at the OS level in a centralized, shared disk
> A-A cluster with a DLM, HBVS, and A-A DB.
>
> To better explain the differences / benefits between shared disk and
> shared nothing arch's, check out this WP:
> http://www.scaledb.com/wp-content/uploads/2015/11/Shared-Nohing-vs-Sha
> red-Disk-WP_SDvSN.pdf

The problems with your arguments Kerry is that you're trying to "Sell" last
year's solutions. "Shared disk" ????

Maybe better to think about selling tomorrow's solutions. Shared byte
addressable NVM memory, cluster wide DLM with numeric range locking, and perhaps
some other benefits that might fall out of such advances.

Steve is right, the target is 2022 and beyond. The undiscovered country ....

:-)
Kerry Main
2017-03-28 02:41:38 UTC
Reply
Permalink
Raw Message
> -----Original Message-----
> From: Info-vax [mailto:info-vax-***@rbnsn.com] On Behalf Of
> David Froble via Info-vax
> Sent: March 26, 2017 11:53 PM
> To: info-***@rbnsn.com
> Cc: David Froble <***@tsoft-inc.com>
> Subject: Re: [Info-vax] Graphics Update - Opportunity for ISV/ third
> party / developers?
>
> Kerry Main wrote:
>
> > Extract: "You'll recognize most of the ideas--Sticky Sessions,
Data
> > Shipping Paradigm, Function Shipping Paradigm, Data Locality, CAP,
> > Cluster Membership, Gossip Protocols, Consistent Hashing,"
> >
> > All of these need to be done at the App code level in a shared
> nothing
> > distributed model. The video explains how the App developers can
> do
> > these functions - in their code.
> >
> > Most of this can be done at the OS level in a centralized, shared
disk
> > A-A cluster with a DLM, HBVS, and A-A DB.
> >
> > To better explain the differences / benefits between shared disk
and
> > shared nothing arch's, check out this WP:
> > http://www.scaledb.com/wp-content/uploads/2015/11/Shared-
> Nohing-vs-Sha
> > red-Disk-WP_SDvSN.pdf
>
> The problems with your arguments Kerry is that you're trying to
"Sell"
> last year's solutions. "Shared disk" ????
>

There are basically only two cluster models today - shared nothing and
shared disk (or shared everything using past OpenVMS terms)

One could expand this concept to shared data (shared disk) via memory
based storage vs. non-shared data (shared nothing) models that would
need to address locking/sync designs other than todays models.

> Maybe better to think about selling tomorrow's solutions. Shared
byte
> addressable NVM memory, cluster wide DLM with numeric range
> locking, and perhaps some other benefits that might fall out of such
> advances.
>
> Steve is right, the target is 2022 and beyond. The undiscovered
> country ....
>
> :-)

Yes, its great and proper to investigate new technologies. VSI has
stated which ones it is looking at in its roadmap.

However, for most companies, unless you have large Lab / R&D budgets,
these technologies need to be at least available before one starts
investigating them.

There is a danger to start spending excessive amounts of todays
resources investigating technologies that may not ever make it to
market.

Case in point - HPE's "The Thing" (now dead).

Another example - HP-UX shared disk clustering (adapted from
Tru64).... never made it to market.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Loading...