Some VAX configurations booted using a virtual disk. It's not at all
a new approach for the bootstrap, even with OpenVMS.
What is being implemented would be excellent fodder for some future
article in Sue's eventual technical journal offering. This as details
of the bootstrap are always interesting to some technical folks, and
marketing benefits can be accrued. Would have been nice to record the
boot camp sessions that discussed this stuff and post that, too. But
backing up a step or three, these details are about as fundamentally
relevant to most folks that will be using OpenVMS on x86-64 as the
innards of how IPB interacts with EFI are relevant to folks using
OpenVMS on Itanium.
The new boot manager that's been discussed once or twice and at boot
camp, and that the new boot manager hopefully reduces the exposure to
the EFI user interface? Now that's far more interesting to
(experienced) system managers, because we're going to be dealing
directly with that. It's also a good spot to build some package and
patch management, as well as access to backup and other
maintenance-related tools. (The client and server systems I commonly
use have this capability already, provide more than I've discussed
here, works very nicely, and completely avoids the need to visit EFI.)
> Clair appears to be doing something very similar with the memory disk
> and it raises the very interesting question about if it would be
> possible to run a normal but customised site specific VMS environment
> from it without ever needing to load any other files during the boot.
They're keeping the boot disk around for crashes, too. It's how the
crashdumps can access what should be a valid and uncorrupted system,
and write the encrypted crash data out to the local disk or the local
dump server host, or (eventually, hopefully, opt-in, yada yada) encrypt
the dump and write the most interesting bits to some remote crash
server at VSI. I'm working with systems that already (user-optionally)
upload application crash data and system crash data, too.
>
>> i.e.
>> I can order OpenVMS with C, C++ compiler and a list of say other
>> layered products and I can then grab an ISO of that exact configuration
>> so that I don't need to install the base and the roll forward
>> installing all the products individually?
>
> No. That's what a decent package manager is for. BTW, PCSI does not
> qualify as a decent package manager by today's standards.
Package and dependency management, or containers. Where appropriate,
client systems can further implement self-service here via Munki or
otherwise, and authorized folks can load packages on servers.
Folks are getting away from monolithic disk images, too. That works
certainly, but it's a morass of permutations, and you're going to be
regenerating the images every time you change something and whenever
you're deploying security patches and updates; OpenSSL or ISC BIND or
Apache and any number of other hunks commonly found on OpenVMS can get
rush updates, and some packages and some environments follow more
frequent or even continuous deployment strategies, even for their own
applications. But whether you use monolithic images, or thin images,
or self-service, or if you customize the OpenVMS installation DVDs with
your own bits, or the (why is this even separate from the base
installation?) factory-installed-software FIS installation approach,
use what works best for your local needs.
https://www.munki.org/munki/
https://github.com/wdas/reposado
http://blog.techtalklive.org/ttlblog/Pages/Imaging-Strategies-for-Mac-OS-X.aspx
Etc.