[Info-vax] MONO (.NET) for VMS

[Stephen Hoffman]

On 2015-01-29 13:34:03 +0000, John E. Malmberg said:

> On 1/27/2015 4:38 PM, Richard Maher wrote:
>> Has anyone tried or heard of anyone trying to port MONO to VMS?
> 
> The last time I looked, it needed a whole load of support libraries 
> ported just to get started.
> 
> Now that GNV has been improved, it may be more practical to start 
> porting those.
> 
> I have not looked in a while, but you probably need a current ncurses, 
> and all the components for a current GTK+, which has been the biggest 
> blocker to porting major open source programs to VMS with the needed 
> functionality to be used.  Not lack of fork(), not OS features, just 
> get current versions of those libraries, and a ton of useful 
> applications will almost just compile and go.

I'd probably add cmake to that list, but yes.

> 
>> Two changes in Windows IIS application deployment I see happening at 
>> the moment is: -
>> 
>> 1) Shared servers are back in vogue with web-farms and web-gardens. But 
>> a shared/single system-disk would really help here!!!

Out of curiosity, how would having a single, shared system disk help sell VMS?

That's not intended snark.   I do have some slight understanding of 
clustering, and of how deployments are done on some other platforms.

With the ability to do client thin imaging or alternatives such as 
loading and booting a VM image, and with deployment tools including 
Munki, ARD, Puppet or Chef, and with the ability to share settings via 
easily-installed profiles and particularly using distributed services 
such as LDAP, with servers such as CalDAV, and particularly with 
integration with Exchange Server or alternatives such as Kerio, and 
integration with SharePoint or alternatives such as Igloo Software, 
rapid, end-user-customized deployment is very easy.

With InfoServer, folks have been using imaging with VMS for most of 
twenty years.  Really great for testing purposes, among other uses.  
Easy to reset to a clean install, and easy to load whatever common base 
version or configuration is necessary.

In short, getting the OS bits loaded is pretty easy, and the sort of 
sharing that clustering has available is — as far as I can tell — 
available using different means.

Now as for issues, VMS is not particularly adept at what profiles can 
be used for; the ability to acquire and load — for instance — the host 
name and the host address into the disk image, and the ability to 
capture the MAC address or serial number, configuration, errors, and 
other tracking data.  VMS also lacks tools to easily load applications 
and layered products and compilers — as wasteful as application bundles 
can be, we're not in the same disk storage world as we were decades 
ago.  This means that shared system disks are useful for VMS, but — if 
you can easily and quickly load that stuff, via drag-and-drop or by 
deployment script or otherwise — the advantages of installing stuff 
once and sharing it just isn't as great as it once was.

Put another way, sharing a disk is certainly nice and can be useful — 
and common in a VMS context — but doesn't look like a huge advantage 
given some of the available alternative approaches.  Single system 
image also means that one corrupted disk volume or some sort of 
infestation will take out multiple boxes, and it means that folks will 
either need specialized links and hardware, or will be slinging 
operating system tools and data over Ethernet.

Then there's the whole idea of trying to compete anywhere near head-on 
with Microsoft and Windows, even with how much smaller the Microsoft 
marketshare of client devices is.  Are there going to be enough new C# 
and .Net/Mono deployments on VMS to matter, and to be worth the 
investment?  But then, I've posted a few hair-brained gonzo suggestions 
here, certainly.  So...  Sell me on how having C# and Mono and shared 
system disks would help me?  Or, how would this help VSI move more VMS 
licenses?


>> 2) People seem to be deprecating (nay completely ignoring) the GAC. Now 
>> every application has to ship a copy of everything it needs bar the 
>> core OS.

These are what are sometimes called bundles on other platforms.  Why 
try to resolve the prerequisites, when you can create a package that 
contains and isolates all the dependencies for an application?    Yes, 
and the OS is just a dependency for the application, too.

Sharing dependencies was very important when disk space was tiny and 
expensive, or when memory was short, or when the dependencies are huge, 
but disk space and memories and cores are rather less of a constraint 
nowadays.  There's been the VMS DLL hell involving OpenSSL in recent 
years, and other open source projects will encounter the same, as their 
APIs evolve.

Years ago, many folks — including myself — were grumbling about how 
applications written in higher-level tools and frameworks were using 
more and more memory, and more and more processor, and more disk.   
Remember the discussions around how much larger Alpha images were, than 
VAX, and how much larger Itanium images were than Alpha?  Or for the 
old folks here, the grumbling over the use of high-level languages, 
rather than using a proper assembler, or the wastefulness of 4GLs 
rather than 3GLs?     Well, we now have a whole lot more memory, and a 
whole lot more cores, and a whole lot more disk space — and we still 
don't like paying for it, of course.

In comparison with the Good Old Days, my phone now has more storage and 
more memory and more cores and faster graphics than many of the early 
Alpha systems, and more than most of the VAX systems.

Are there still cases where disk or memory or cores are short, or when 
scaling means managing a whole lot of systems and guests, many of which 
are running less than fully configured?  Sure.  Solve those cases and 
those problems, and you'll a product that might interest some folks.  
But then, I don't think you're going to get there with single system 
image, nor with app stacking as it's currently done — there are too 
many unresolved dependencies and collisions lurking.

Getting back to my question, solving current problems is interesting.  
How does single system image and sharing a disk help, given how easy it 
is to blast in a new disk image?  The firmware in the computers I'm 
using can perform the equivalent of a MOP bootstrap and a software 
install over an Internet link, after all.

>> VMS certainly looks well placed to solve (1)?
> 
> Shared hosting for a partitioned linux host (simulated VM) is about $1 
> U.S./month.  This looks like a real server to most applications, but is 
> actually isolated using security features....

Mr Maher is likely referring to the resource and data sharing of 
clustering, here.  Not to shared hosting.

> For VMS to get its foot in the door for that market, the provider may 
> need to be able to meet those entry price points.

While intended to refer to shared hosting and not clustering, his 
comment definitely applies to anybody that's trying to chase Windows.  
Even if VMS comes free with the x86-64 box, folks are going to want 
some prerequisite applications, and will want their own applications.  
Having Mono isn't nearly enough to get even a toe-hold.


-- 
Pure Personal Opinion | HoffmanLabs LLC