Will x86-64 VMS run on a laptop ?

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?
However, it opens up a range of questions including graphics
adapter and other hardware support, battery power management
and maybe Wifi/mobile communications device support.
I can also see problems unless the new VMS filesystem will play
nicely with other filesystems and operating systems installed on
other partitions on the laptop's hard drive.
IOW, will the new VMS filesystem be installable into a partition
on a hard drive or will it still require the full drive as
ODS-2/ODS-5 do ?
There's not really going to be a major market for VMS on a laptop,
but I can see it being useful for various things, including software
development and demos when you are moving between locations.

I think VSI should go for supporting it under a specific VM
using container files as disks. That would solve a lot of
technical issues.

Arne

David Froble

2017-02-23 19:14:38 UTC

I think VSI should go for supporting it under a specific VM
using container files as disks. That would solve a lot of
technical issues.
Arne

Yes, it would. But there still might be issues with device drivers for the
display, keyboard, mouse, and such.

VSI has indicated that they were definitely going to support VMS on VMs.

Arne Vajhøj

2017-02-23 19:34:03 UTC

I think VSI should go for supporting it under a specific VM
using container files as disks. That would solve a lot of
technical issues.

Yes, it would. But there still might be issues with device drivers for
the display, keyboard, mouse, and such.

Wouldn't that be handled by the VM software, so that VMS sees a
standard device no matter what the actual device is.

Post by David Froble
VSI has indicated that they were definitely going to support VMS on VMs.

But does that mean VMWare ESXi or something desktop?

Arne

Paul Sture

2017-02-23 23:23:00 UTC

I think VSI should go for supporting it under a specific VM
using container files as disks. That would solve a lot of
technical issues.

That's how I anticipate it. VMware, VirtualBox and the others present a
known set of hardware devices (video, ethernet/wireless device, disk
types etc) to the client.

No matter what the underlying physical hardware is, VM clients only need
to be able to talk to the subset provided by the virtual machine
environment.

Disk containers bring other advantages such as ease of backups and
portability from one place to another. Snapshots can also be done
either by the host VM software or where supported by the host's own file
system (ZFS, btrfs, Apple's upcoming file system when that arrives).

--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher

David Froble

2017-02-23 19:12:42 UTC

I cannot imagine software development on a notebook, unless remote monitor,
keyboard, and mouse are used, and then why have a notebook?

Bill Gunshannon

2017-02-23 19:30:42 UTC

I cannot imagine software development on a notebook, unless remote
monitor, keyboard, and mouse are used, and then why have a notebook?

Might be handy for that sales visit from a VMS VAR.

bill

Arne Vajhøj

2017-02-23 19:37:44 UTC

I cannot imagine software development on a notebook, unless remote
monitor, keyboard, and mouse are used, and then why have a notebook?

I would think most development today are done on laptops.

One laptop with your stuff.

Three monitors + keyboard & mouse in office.

At least one monitor + keyboard and mouse at home.

Hopefully one monitor + keyboard and mouse in companies other
facilities.

Hopefully one monitor + keyboard and mouse at customer sites.

Arne

Alexander Schreiber

2017-02-28 20:40:21 UTC

I cannot imagine software development on a notebook, unless remote
monitor, keyboard, and mouse are used, and then why have a notebook?

I would think most development today are done on laptops.

I wouldn't be so sure. There are companies with explicit "no source code
on laptops" policies (yes, even with full disk encryption) on the grounds
that mobile devices can occasionally be more mobile than their owners want
them to be ... of course, then you need to provide suitable environments
where using the laptop as a glorified mobile terminal for development
is actually feasible. And yes, such setups do exist.

Kind regards,
Alex.

--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Arne Vajhøj

2017-03-02 02:33:08 UTC

Post by Alexander Schreiber

I cannot imagine software development on a notebook, unless remote
monitor, keyboard, and mouse are used, and then why have a notebook?

I would think most development today are done on laptops.

I am sure that they exist.

But I am pretty sure that it is not over 50%.

Below 5% seems more likely.

Arne

Phillip Helbig (undress to reply)

2017-02-23 19:57:31 UTC

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?

Why not? Define "laptop". Define "server". Define "workstation".
Things aren't as clear-cut as they were.

Post by Simon Clubley
However, it opens up a range of questions including graphics
adapter

VSI said that they would support (only?) the on-chip graphics. Good
enough for me. :-)

Post by Simon Clubley
and other hardware support,

Such as?

Post by Simon Clubley
battery power management

Something VMS needs to be concerned about?

Post by Simon Clubley
and maybe Wifi/mobile communications device support.

Isn't that just another network card to VMS?

The most important thing: support a proper keyboard! It should be
possible to plug in a USB LK keyboard and have it just work out of the
box like an LK worked on VAX or Alpha with no hoops to jump through.

Post by Simon Clubley
There's not really going to be a major market for VMS on a laptop,
but I can see it being useful for various things, including software
development and demos when you are moving between locations.

There was the Tadpole. I think that many people would buy one if they
were cheap enough.

Simon Clubley

2017-02-24 03:06:50 UTC

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?

Why not? Define "laptop". Define "server". Define "workstation".
Things aren't as clear-cut as they were.

Actually, yes they are as they have very different sets of hardware
built into them.

Post by Simon Clubley
However, it opens up a range of questions including graphics
adapter

VSI said that they would support (only?) the on-chip graphics. Good
enough for me. :-)

Depends on whether they mean VGA/SVGA type resolution in framebuffer
mode only or whether they mean hardware accelerated 2-D graphics.

Post by Simon Clubley
and other hardware support,

Such as?

Onboard comms devices such as Wifi and Ethernet for one. There might
also be integrated chipsets to deal with. I'm not sure if the latter
one, on laptops built over the last 2-3 years, is still the problem
it once was.

Post by Simon Clubley
battery power management

Something VMS needs to be concerned about?

Unless you want your battery drained quickly and your hardware running
at 100% of capacity all the time then yes it is.

Post by Simon Clubley
and maybe Wifi/mobile communications device support.

Isn't that just another network card to VMS?

Yes and No.

The mobile broadband USB dongles should be quite easy to get working
with a modern VMS as they have mostly standards based interfaces.
The older ones present a dial-up PPP interface so you would need dialup
software on VMS (ie: a VMS version of something like kppp).

The newer ones implement the USB NCM protocol so they just look like
another Ethernet port and you typically manage the device via a
web browser. The main problem is sending the right SCSI command to
do the mode switch and that is pretty much a (mostly) solved problem.

Wifi however is a very different matter. As Bob says, it's a complicated
protocol stack, but the real problem is that the hardware programming
information is simply very hard to come by unless you are a major
player. It's a world of strict NDAs and there's no real public datasheets
with detailed programming information I have ever been able to find.

As Arne and co have said, the only real chance here is to run VMS in
a VM and have the drivers supplied by the VM itself.

Post by Phillip Helbig (undress to reply)
The most important thing: support a proper keyboard! It should be
possible to plug in a USB LK keyboard and have it just work out of the
box like an LK worked on VAX or Alpha with no hoops to jump through.

That should be a HID driver issue only.

There was the Tadpole. I think that many people would buy one if they
were cheap enough.

I would like to see VMS running directly on the hardware and be just
another boot menu entry on the laptop boot screen but due to the
driver situation and the issues with multiple partitions it's
probably going to have to run within a VM.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Jan-Erik Soderholm

2017-02-24 12:28:03 UTC

Post by Simon Clubley
I would like to see VMS running directly on the hardware and be just
another boot menu entry on the laptop boot screen but due to the
driver situation and the issues with multiple partitions it's
probably going to have to run within a VM.
Simon.

My guess is that we will simply never see VMS native on a laptop.
Too much work and probably no business case for VSI.

If at all, it will run in a VM. A VM environment on a laptop is not
differnt (from VMS point of view) then the same VM on a large server.
So if VMS can run in a VM (at all), it will also "run" on a laptop,
if that specific VM is also supported on laptops.

j***@yahoo.co.uk

2017-02-24 16:35:39 UTC

My guess is that we will simply never see VMS native on a laptop.
Too much work and probably no business case for VSI.
If at all, it will run in a VM. A VM environment on a laptop is not
differnt (from VMS point of view) then the same VM on a large server.
So if VMS can run in a VM (at all), it will also "run" on a laptop,
if that specific VM is also supported on laptops.

You're probably right, as is everyone else that's said "focus
on VSIVMS in virtual machines".

That said, what's a laptop in recent years?

If you forget consumer-class stuff (which typically has a
sales lifetime of a few weeks and a support lifetime not
that much longer, and therefore enterprise class usage is
not going to happen) and look instead at business-class
stuff, the picture may change a little. Better design,
more robust build, longer lifetime, range of options (esp
processor, screen resolution, maybe docking station), etc.

Obviously the price (when new) of business class stuff
tends to be rather more expensive than new consumer stuff,
which might be a problem to some. For the budget-conscious
e.g. hobbyist there have historically been decent deals
available on refurbished business class stuff which has
come to the end of its original owner's useful life.

Business class laptops typically also come with the option
of Win7 rather than Win10, and some are even qualified for
use with OSes other than Windows. Imagine that.

Never had one where VMware didn't work, though licencing
changes ($$$ for Player?) mean VMware is not currently of
interest to me.

I've used this tactic for years, for personal use, but
it may not suit everyone.

Just a thought.

Corbin, Brian (CSC RTCC BCS Server)

2017-02-23 19:56:08 UTC

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?

Interesting question, I would counter how many people run Windows server
2012 on a Laptop and why would they?

I speculate the initial target market for X86 OpenVMS with be the high
volume server market. In HPE systems like DL servers and BL blades
and hopefully they can get in on the Synergy market and other vendors
X86 servers.

Rather than scale down to the single user systems with a few cores , I
think a better question would be how large a system can OpenVMS scale
up to? Can it run on an 8 socket or higher platform like a DL980G7, or
an MC990x or Superdome X platforms with cpu counts up into the 200+
range and terabytes of Memory and lots of fast PCIe IO devices.

It would be nice to see a SAP HANA port to x86 OpenVMS , that would be a
great niche market for OpenVMS

Brian

Arne Vajhøj

2017-02-23 20:53:56 UTC

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?

Interesting question, I would counter how many people run Windows server
2012 on a Laptop and why would they?

But they don't need to because they can develop/test things on
a Windows 7 or 10 and use that on a 2012 server.

That is not an option for VMS.

Arne

Paul Sture

2017-02-23 23:37:22 UTC

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?

Interesting question, I would counter how many people run Windows server
2012 on a Laptop and why would they?

I'm going back 5-6 years here, but plenty of folks doing SQL Server
development were using multicore laptops with 24GB or greater RAM, often
with more than one disk. Moving to today, those folks are probably
using similar kit but with SSDs; almost certainly some of them will
be renting resources on the likes of Amazon as well.

--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher

IanD

2017-02-24 02:32:56 UTC

Post by Paul Sture

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?

Interesting question, I would counter how many people run Windows server
2012 on a Laptop and why would they?

About 6 years ago I ran multiple VM's on an HP Elitebook with 16 gb of memory

A few years after I purchased it I upgraded the HDD to an SDD and gave it a new lease of life. It's still fast enough to do most things I want except it's a heater :-(

I purchased one at the same time for a friend who used it do do Ms software development on. He now uses a Surface pro and does his development work on an Azure instance instead

There are laptops around that you can kit out with 32 or even 64 gb of ram now

ESXi is very finicky about hardware. I find esxi tends to come unstuck on cheaper commodity noname hardware brands, especially network / raid cards

I run (or did, a while ago) run a small VMS cluster on an HP microserver with 16gb of ram (alpha, double virtualised). It's ok for playing around with VMS

I'd love to run a small VMS cluster on a fully kitted out x86 laptop in the future but I seriously doubt we will see VMs run native on one and even under esxi it might be a challenge to find a laptop that esxi works well with. Perhaps Zen might be better? (I confess I have only used Zen, never tried installing it)

VMS on x86 laptops as a stepping stone on the way to VMS on mobile (native) :-)

Alexander Schreiber

2017-02-28 20:41:56 UTC

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?

Interesting question, I would counter how many people run Windows server
2012 on a Laptop and why would they?

The same reason why laptops with SPARC CPUs even existed: for field
engineers and VARs, mostly.

Kind regards,
Alex.

--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

David Froble

2017-02-28 22:19:08 UTC

Post by Alexander Schreiber

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?

Interesting question, I would counter how many people run Windows server
2012 on a Laptop and why would they?

The same reason why laptops with SPARC CPUs even existed: for field
engineers and VARs, mostly.
Kind regards,
Alex.

Yes, when you need to take your tools to a customer site, when you want to demo
something, and such. But not for writing 20,000 lines of code.

Bob Gezelter

2017-02-23 20:30:04 UTC

Simon,

Most likely, under various VM packages (e.g., VMware, Virtual Box). It has been said for a long time that the VM world is a target.

Direct support of laptop hardware is a challenge as there are numerous devices, often changing quickly. WiFi drivers are relatively complex. "Just another adapter" is true, but the code size for the Windows drivers belies the point. These are large drivers with additional complexities. Linux, which has far bigger exposure at the moment, is often chronically behind on laptop device support.

As to viability of laptop-based development. My present laptop (which is neither the fastest nor the largest) has more resources in all dimensions than most of my OpenVMS stations. Running an emulated Alpha environment, it is a more than adequate workstation when I am on the road.

- Bob Gezelter, http://www.rlgsc.com

Scott Dorsey

2017-02-23 23:18:38 UTC

Post by Simon Clubley
The question is simple enough: will x86-64 VMS run on a laptop ?

Easy answer: no.

More detailed answer: likely some things will work but probably enough things
won't work that it won't boot.

Explanation: VSI has said in public that they wish to support a small number
of hardware devices with controlled configurations.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Dirk Munk

2017-02-24 20:53:20 UTC

We had this topic before in the group.

It would be possible for VSI to design a notebook/desktop version of
OpenVMS. Modern Intel desktop and mobile CPU's have excellent emebedded
GPU's, no need for an extra graphics card.

The chipsets for these CPU's have alomost everything you need, SATA
controller, NIC, USB etc.

So there is a well defined set of hardware that would make it
*relatively* easy for VSI.

However.....

Running it on a VM would be better. You could use any notebook/desktop
that is supported by the VM, and you could run Linux or Windows at the
same time. That would give you a browser also, VMS has no browser.

A long time ago VMS had Mozilla and its successor Seamonkey as browser,
Today that is no longer viable. Maintaining a browser with the necessary
add-ons is very labour intensive and expensive. No need for that, but
you do need a browser on your notebook.

So a VM with VMS, Windows and/or Linux is the best solution. A modern
quadcore notebook CPU can handle 64GB, more than sufficient for such a
configuration.

Phillip Helbig (undress to reply)

2017-02-25 09:43:19 UTC

Post by Dirk Munk
Running it on a VM would be better. You could use any notebook/desktop
that is supported by the VM, and you could run Linux or Windows at the
same time.

But then you would also have to run the underlying OS.

Post by Dirk Munk
That would give you a browser also, VMS has no browser.
A long time ago VMS had Mozilla and its successor Seamonkey as browser,
Today that is no longer viable. Maintaining a browser with the necessary
add-ons is very labour intensive and expensive. No need for that, but
you do need a browser on your notebook.

An entire OS and various layered products are ported to a completely
different hardware platform---doable. A modern browser---undoable?

Maybe there is a middle path: a browser which doesn't support all addons
but is good enough for 95%.

Jan-Erik Soderholm

2017-02-25 10:56:49 UTC

Post by Dirk Munk
Running it on a VM would be better. You could use any notebook/desktop
that is supported by the VM, and you could run Linux or Windows at the
same time.

But then you would also have to run the underlying OS.

An entire OS and various layered products are ported to a completely
different hardware platform---doable. A modern browser---undoable?

It is not an techincal issue. Its about having a business case or not.

Noone (a slightly rounded number) asks for a native browser on VMS.
In particular if you ask paying customers.

Scott Dorsey

2017-02-25 12:32:56 UTC

Post by Dirk Munk
A long time ago VMS had Mozilla and its successor Seamonkey as browser,
Today that is no longer viable. Maintaining a browser with the necessary
add-ons is very labour intensive and expensive. No need for that, but
you do need a browser on your notebook.

An entire OS and various layered products are ported to a completely
different hardware platform---doable. A modern browser---undoable?

The "modern browser" is a moving target.

Post by Phillip Helbig (undress to reply)
Maybe there is a middle path: a browser which doesn't support all addons
but is good enough for 95%.

The problem is that today's 95% is tomorrow's 10%. Somebody has to be
constantly adding crap to it in order to keep up to date.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

c***@gmail.com

2017-02-25 13:33:00 UTC

An entire OS and various layered products are ported to a completely
different hardware platform---doable. A modern browser---undoable?

The "modern browser" is a moving target.

Post by Phillip Helbig (undress to reply)
Maybe there is a middle path: a browser which doesn't support all addons
but is good enough for 95%.

The problem is that today's 95% is tomorrow's 10%. Somebody has to be
constantly adding crap to it in order to keep up to date.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

RE: laptops

We are not doing anything to prevent VMS from running on laptops, after all they are just more HW platforms. But being a real personal system with the expected graphics involves a number of things that are just not in the cards for us in the foreseeable future. Our resources are better spent elsewhere where VMS has a more obvious role.

RE: virtual machines

As we have said from the very beginning we intend to run as a virtual machine on as many hosts as we can. This may sound easy put it is proving to be difficult, not insurmountable but a lot of work. We currently use Fusion (VMware on MAC), kvm on Proliant, and Virtual Box on MAC for testing. The challenge is that the default for most hypervisors is still BIOS with UEFI as an option but each hypervisor has it own incantation of what it thinks simulates UEFI. We are gaining on it but it is a struggle. There are big differences between the uefi you get in platform FW versus what you get from hypervisors. HW versus hypervisors should be irrelevant to the OS but the world is far less than perfect.

RE: partitioned disks

We now create three partitions when we initialize a disk, one for uefi and two (why it is not one is a complicated story) for the file system. The Boot Manager recognizes the uefi partition and SYSBOOT and the file system recognize the other two as VMS. While we do not do it today there is no reason why in the future, with the appropriate work, that VMS would not init the entire disk and thus leave room for partitions for other file systems. All the necessary low-level work is in place today and we do think about this so we do not do anything to prevent it.

Kerry Main

2017-02-25 15:46:17 UTC

-----Original Message-----
clairgrant71--- via Info-vax
Sent: February 25, 2017 8:33 AM
Subject: Re: [Info-vax] Will x86-64 VMS run on a laptop ?

Post by Dirk Munk
A long time ago VMS had Mozilla and its successor Seamonkey as
browser, Today that is no longer viable. Maintaining a browser

with

Post by Dirk Munk
the necessary add-ons is very labour intensive and expensive. No
need for that, but you do need a browser on your notebook.

An entire OS and various layered products are ported to a

completely

Post by Phillip Helbig (undress to reply)
different hardware platform---doable. A modern browser---

undoable?

Post by Scott Dorsey
The "modern browser" is a moving target.

Post by Phillip Helbig (undress to reply)
Maybe there is a middle path: a browser which doesn't support all
addons but is good enough for 95%.

The problem is that today's 95% is tomorrow's 10%. Somebody has

to be

Post by Scott Dorsey
constantly adding crap to it in order to keep up to date.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Perfect .. what better initial porting platform than some older laptops kicking around that can be configured as OpenVMS servers in a small OpenVMS cluster?

Imho, its similar to the strategy of VAX's not being supported in an Alpha/IA64 cluster, but VAX's work just fine in these clusters.

In addition, contrary to the many graphics adapters of the past, many of the next gen graphics adapters are adopting more open standards like Vulkan which will make it easier for a third party company to offer add on products to OpenVMS / X86-64 Customers.

Case in point - Microsoft offers a basic Backup utility, but few seldom use and instead purchase third party products. The same could be stated for VSI and OpenVMS i.e. Offer a basic capability, but work with Partners/ISV's to offer value add options.

VSI can not be expected to address all of the features folks want anymore than Microsoft or Apple offer all solutions for their platforms.

RE: virtual machines
As we have said from the very beginning we intend to run as a virtual
machine on as many hosts as we can. This may sound easy put it is
proving to be difficult, not insurmountable but a lot of work. We
currently use Fusion (VMware on MAC), kvm on Proliant, and Virtual
Box on MAC for testing. The challenge is that the default for most
hypervisors is still BIOS with UEFI as an option but each hypervisor has
it own incantation of what it thinks simulates UEFI. We are gaining on it
but it is a struggle. There are big differences between the uefi you get
in platform FW versus what you get from hypervisors. HW versus
hypervisors should be irrelevant to the OS but the world is far less than
perfect.

This is a great strategy as can be seen by a recent next gen DC program (very large, govt based) which is really looking hard (actually implementing) at software defined networks (SDN) and software defined datacenters (SDD). There is huge push to get rid of dedicated physical servers for everything except where required e.g. VMware, Hyper-V host servers. There are some environments that still require dedicated physical HW for compute/IO etc., but these are rapidly decreasing.

Even networking features are being integrated into the Host hypervisors e.g. VMware NSX.

I addition, for SW companies like VSI, Microsoft etc., they do not care as they still get the same licensing $'s whether it is on a Virt or Phys based OS.

The days of running a piece of server HW in a DC that is only 25-50% busy (or much less) at peak times is rapidly disappearing. This likely applies to 75% of the OpenVMS Cust base.

Being able to say OpenVMS will run in a VMware, Hyper-V and KVM environment would be huge. These are the big three (in decreasing order of priority). Running on MAC would be nice to have, but I have not seen MAC's being used in any DC environment for a long time.

Btw, when looking at VMware vs. Hyper-V, it is a bit like comparing an NHL hockey player (VMware is not inexpensive, but has likely 80+% of the virtual market) to a Peewee hockey player like Hyper-V. Yes, they both have skates, have protective equipment and carry a stick but the level of capabilities is vastly different.

RE: partitioned disks
We now create three partitions when we initialize a disk, one for uefi
and two (why it is not one is a complicated story) for the file system.
The Boot Manager recognizes the uefi partition and SYSBOOT and the
file system recognize the other two as VMS. While we do not do it
today there is no reason why in the future, with the appropriate work,
that VMS would not init the entire disk and thus leave room for
partitions for other file systems. All the necessary low-level work is in
place today and we do think about this so we do not do anything to
prevent it.

On a similar vein, here is my vote for bootable LD containers.

Download a profile specific LD container (e.g. customized Dev env with development languages and selected open source prod's), boot, run some minor custom start-up gui/script and away you go.

Perhaps it would make it much easier in a VMware world which uses templates to create custom VM's?

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

John Reagan

2017-02-25 15:53:54 UTC

Post by Kerry Main
Perfect .. what better initial porting platform than some older laptops kicking around that can be configured as OpenVMS servers in a small OpenVMS cluster?

For some definition of "older". Certainly the chips need to be 64-bit capable and SSE4.1 at least. So don't expect that old Gateway laptop sitting in your basement to have a chance of working.

Kerry Main

2017-02-25 16:17:38 UTC

-----Original Message-----
John Reagan via Info-vax
Sent: February 25, 2017 10:54 AM
Subject: Re: [Info-vax] Will x86-64 VMS run on a laptop ?

Post by Kerry Main
Perfect .. what better initial porting platform than some older laptops

kicking around that can be configured as OpenVMS servers in a small
OpenVMS cluster?
For some definition of "older". Certainly the chips need to be 64-bit
capable and SSE4.1 at least. So don't expect that old Gateway laptop
sitting in your basement to have a chance of working.

Do people still have those?

😊

No - Since most laptops get replaced (or mine anyway) every 3 years, the laptops I would be looking at using are within 3 years old.

Heck, a new I5 64b laptop is less than $500 these days anyway. Even a more capable laptop (modern I7 etc.) with 8GB memory is less than a $1000 - pretty cheap porting gear.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-02-25 17:49:10 UTC

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.

LD is the "ripping a CD" or "downloading a disk image" stage — little
more than distribution of the bits, and quite possibly unsigned — of
what's involved with containers.

https://blog.engineyard.com/2015/linux-containers-isolation
https://blog.engineyard.com/2015/isolation-linux-containers
https://linuxcontainers.org/lxc/introduction/

As for the "away you go", there's a whole pile of work behind that
which will be needed to authenticate, and to keep what's in those
containers from getting tangled together. The environment classic
OpenVMS system mangers are experienced with — bespoke startups,
prefixes and conventions, and the rest — is not effective in this era;
not at any particular scale, nor is the present environment even
remotely proof against stupid app coding mistakes, much less against
vulnerable and hijacked apps or rogue app code. Don't get me started
about UIC collisions and the rest...

--
Pure Personal Opinion | HoffmanLabs LLC

Kerry Main

2017-02-25 18:18:19 UTC

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: February 25, 2017 12:49 PM
Subject: Re: [Info-vax] Will x86-64 VMS run on a laptop ?

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.

Like "cloud", "container" is a generic term that anyone can use to describe just about anything.

Just because it may not fit the Linux purists definition, it does not mean other uses of the term is not appropriate.

A CD image, ok, signed CD image, can certainly be called a container.

As for the "away you go", there's a whole pile of work behind that
which will be needed to authenticate, and to keep what's in those
containers from getting tangled together. The environment classic
OpenVMS system mangers are experienced with — bespoke startups,
prefixes and conventions, and the rest — is not effective in this era;
not at any particular scale, nor is the present environment even
remotely proof against stupid app coding mistakes, much less against
vulnerable and hijacked apps or rogue app code. Don't get me started
about UIC collisions and the rest...

Translated - yes, there would be some work involved.

But other platforms have similar issues, so pretending that they don't is just OS bashing.

Case in point - I remember a 50+ page Windows build document that one of my Windows SME's on a project a few years back put together in an effort to standardize our project Windows builds.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-02-25 20:50:11 UTC

Post by Kerry Main
Translated - yes, there would be some work involved.

Ayup. Isolating containers — providing more than what OpenVMS has
offered here for decades — is a whole lot more work than most realize,
both for the OS folks as well as for the folks developing and deploying
tools and apps for use in those containers. I don't see us in a
position to trust the contents of even the containers we've acquired
and loaded, either. But then I've chased down these same problems
without having containers around, whether it's a DEC C feature logical
name or some other collision or conflict or vulnerability.

Post by Kerry Main
But other platforms have similar issues,

In various cases, "had". OpenVMS is rather lacking in some of the
related and fundamental infrastructure for app isolation and automated
deployments and upgrades, unfortunately.

Post by Kerry Main
so pretending that they don't is just OS bashing.

Ignoring or (arguably worse) pretending that other platforms don't have
good and variously better ideas — and why folks might pick those
platforms over some other operating system — seems a problematic
approach for long-term product success, though.

Post by Kerry Main
Case in point - I remember a 50+ page Windows build document that one
of my Windows SME's on a project a few years back put together in an
effort to standardize our project Windows builds.

Swimming in a municipal sewage treatment pond is probably preferable to
swimming in a reactor core cooling pool. Doesn't make me like either
option.

Again, pointing out the worst of something can be a good reference for
what not to do — or what to do differently, if the idea was actually
almost useful — but unrelated making comparisons against problematic
parts of the competitive landscape is usually a poor source of
enhancements and improvements. It's not a good view. I'm not a
proponent of making overly rosy comparisons, whether the data is
intended for advanced development or as fodder accrued for
intentionally deceptive marketing.

--
Pure Personal Opinion | HoffmanLabs LLC

Simon Clubley

2017-02-27 02:08:13 UTC

Post by Stephen Hoffman
Swimming in a municipal sewage treatment pond is probably preferable to
swimming in a reactor core cooling pool. Doesn't make me like either
option.

Depends on whether you want some super powers or not. :-)

Although I can't imagine what a VMS person's super power would be...

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Arne Vajhøj

2017-02-26 03:53:19 UTC

Post by Kerry Main

Post by Stephen Hoffman
LD is the "ripping a CD" or "downloading a disk image" stage — little
more than distribution of the bits, and quite possibly unsigned — of
what's involved with containers.
https://blog.engineyard.com/2015/linux-containers-isolation
https://blog.engineyard.com/2015/isolation-linux-containers
https://linuxcontainers.org/lxc/introduction/

Like "cloud", "container" is a generic term that anyone can use to
describe just about anything.
Just because it may not fit the Linux purists definition, it does
not
mean other uses of the term is not appropriate.
A CD image, ok, signed CD image, can certainly be called a
container.

Sure. A large steel thingy used to ship things from China to the US
can also be called a container.

But software containers have a reasonable well defined
meaning that does not include LD images.

Arne

Kerry Main

2017-02-26 04:39:18 UTC

-----Original Message-----
Arne Vajhøj via Info-vax
Sent: February 25, 2017 10:53 PM
Subject: Re: [Info-vax] Will x86-64 VMS run on a laptop ?
LD is

Post by Kerry Main

Post by Stephen Hoffman
the "ripping a CD" or "downloading a disk image" stage — little

Post by Kerry Main

Post by Stephen Hoffman
than distribution of the bits, and quite possibly unsigned — of
what's involved with containers.
https://blog.engineyard.com/2015/linux-containers-isolation
https://blog.engineyard.com/2015/isolation-linux-containers
https://linuxcontainers.org/lxc/introduction/

Like "cloud", "container" is a generic term that anyone can use to
describe just about anything.
Just because it may not fit the Linux purists definition, it does not
mean other uses of the term is not appropriate.
A CD image, ok, signed CD image, can certainly be called a container.

Sure. A large steel thingy used to ship things from China to the US can
also be called a container.
But software containers have a reasonable well defined meaning that
does not include LD images.
Arne

https://en.wikipedia.org/wiki/Docker_(software)

"Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server."

Close enough definition to a LD image for me ....

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-02-27 16:17:42 UTC

Sure. A large steel thingy used to ship things from China to the US can
also be called a container.
But software containers have a reasonable well defined meaning that
does not include LD images.

But... But... Hyper-connected adaptable-software-undefined-notworking
cloudfront panamax docker-worker container-ship support is all in the
Kubernetes magic pentagram octant!

--
Pure Personal Opinion | HoffmanLabs LLC

John E. Malmberg

2017-02-28 13:46:58 UTC

[Second posting attempt]

Post by Arne VajhÃ¸j
Sure. A large steel thingy used to ship things from China to the US
can also be called a container.
But software containers have a reasonable well defined meaning that
does not include LD images.

But... But... Hyper-connected adaptable-software-undefined-notworking
cloudfront panamax docker-worker container-ship support is all in the
Kubernetes magic pentagram octant!

And it is possible now to implement non-privilege container type
environments on VMS that share the host networking.

You just need to know the logical names to set, and you can also assist
by manipulating the command tables.

Most of the logical names are documented or easily determined, so it is
just a SMOP for creating the script.

So a container implementation on VMS would simply need a script that
references the shared images and simulated directories for the desired
environment.

Adding a TCPIP NAT environment would be a bit more work.

And this has been doable since at least VMS 4.X. It just has not been
made into an easy to use product/package.

Remember, with a container, all system services are actually handled by
the host OS, so some operations may not work the same as on a native system.

One should be able to write a script that can setup a mounted VMS
installation disk for use as a container for building or running
programs against, as long as they were the same architecture.

Regards,
-John
***@qsl.net_work

Stephen Hoffman

2017-02-28 14:39:48 UTC

Post by John E. Malmberg
[Second posting attempt]

But... But... Hyper-connected adaptable-software-undefined-notworking
cloudfront panamax docker-worker container-ship support is all in the
Kubernetes magic pentagram octant!

And it is possible now to implement non-privilege container type
environments on VMS that share the host networking.
You just need to know the logical names to set, and you can also assist
by manipulating the command tables.
Most of the logical names are documented or easily determined, so it is
just a SMOP for creating the script.
So a container implementation on VMS would simply need a script that
references the shared images and simulated directories for the desired
environment.
Adding a TCPIP NAT environment would be a bit more work.
And this has been doable since at least VMS 4.X. It just has not been
made into an easy to use product/package.
Remember, with a container, all system services are actually handled by
the host OS, so some operations may not work the same as on a native system.
One should be able to write a script that can setup a mounted VMS
installation disk for use as a container for building or running
programs against, as long as they were the same architecture.
Regards,
-John

How do two different containers on the same box both utilize port 443?
Or sequences the startups, for that matter? Because if nobody looks
at the whole of keeping the containers separate against potentially
hostile activity, and if the apps aren't themselves then
potentially-substantially modified and shipped with support for the
subset environment within the containers, this only ends in a very
large molten crater. Because "LD as a container" as it exists now is
not substantially better than what PCSI now provides, or what PCSI
should provide.

--
Pure Personal Opinion | HoffmanLabs LLC

John E. Malmberg

2017-03-01 00:29:02 UTC

Post by John E. Malmberg
And it is possible now to implement non-privilege container type
environments on VMS that share the host networking.
You just need to know the logical names to set, and you can also
assist by manipulating the command tables.
Most of the logical names are documented or easily determined, so it
is just a SMOP for creating the script.
So a container implementation on VMS would simply need a script that
references the shared images and simulated directories for the desired
environment.
Adding a TCPIP NAT environment would be a bit more work.
And this has been doable since at least VMS 4.X. It just has not been
made into an easy to use product/package.
Remember, with a container, all system services are actually handled
by the host OS, so some operations may not work the same as on a
native system.
One should be able to write a script that can setup a mounted VMS
installation disk for use as a container for building or running
programs against, as long as they were the same architecture.>

How do two different containers on the same box both utilize port 443?

Non-privileged containers do not bind to server ports.

The two ways of addressing that is either to allocate a unique network
address to the container or set up a NAT system.

I have not tried this, but it looks like TCPIP Services will allow
assigning multiple IP addresses to an interface.

A non-privileged container would be like setting up a cross build
environment. It is just that "container" is the new buzzword for it.

Post by Stephen Hoffman
Or sequences the startups, for that matter?

What is the startup for a container? It is simply a wrapper of
libraries and overlay of directories that run on a Host OS.

Something must set up the wrappers and overlays.

On VMS it could be a program or script provided as a layered product
that looks for a description file on a disk, or the entire program could
be contained in a logical disk, or something like the unzip
self-extracting executable could be used to make the container look like
an executable.

Post by Stephen Hoffman
Because if nobody looks
at the whole of keeping the containers separate against potentially
hostile activity, and if the apps aren't themselves then
potentially-substantially modified and shipped with support for the
subset environment within the containers, this only ends in a very large
molten crater. Because "LD as a container" as it exists now is not
substantially better than what PCSI now provides, or what PCSI should
provide.

That gets into the arguments about how secure a container is, and how
much isolation and transparency are provided. These discussions are
going on in the Linux community now, and as they try to "fix" these
things in containers. My Ubuntu 14.04 lxd container running SimH/VAX
will not work on Ubuntu 16.04 because they now require the container to
declare the privileges it will use, but did not provide the required
version of libvirt library that is needed to for that to happen.

So containers even on Linux are still in flux.

LD is not a container. I could build a container that is hosted on a
logical disk though.

My point is that VMS since at least version 4.1, if not earlier allows
non-privileged users to set up environments that fit the definition of
some of the containers in use on Linux.

What no one has done is packaged the method for fun or fame.

For highly isolated privileged containers, that would take some higher
level programming. But for common container uses, there is really
nothing needed to be added to VMS.

Regards,
-John
***@qsl.net_work

Stephen Hoffman

2017-03-01 01:11:25 UTC

Post by Stephen Hoffman
How do two different containers on the same box both utilize port 443?

Non-privileged containers do not bind to server ports.

Ignoring the distinction of privileged ports here, containers are going
to have to be able to do that, or (for instance) running Apache or a
DNS server in a container (and sandbox) won't work.

Post by John E. Malmberg
The two ways of addressing that is either to allocate a unique network
address to the container or set up a NAT system.

Yes, and keep going....

Post by John E. Malmberg
I have not tried this, but it looks like TCPIP Services will allow
assigning multiple IP addresses to an interface.

And now

Post by John E. Malmberg
A non-privileged container would be like setting up a cross build
environment. It is just that "container" is the new buzzword for it.

A non-privileged container is somewhere less than completely useful,
though. Which also gets into discussions of keeping privileged apps
from colliding.

Post by Stephen Hoffman
Or sequences the startups, for that matter?

What is the startup for a container? It is simply a wrapper of
libraries and overlay of directories that run on a Host OS.
Something must set up the wrappers and overlays.
On VMS it could be a program or script provided as a layered product
that looks for a description file on a disk, or the entire program
could be contained in a logical disk, or something like the unzip
self-extracting executable could be used to make the container look
like an executable.

Ayup. Startup, shutdown, file cleanups on removal, dependency checks,
digital signature and integrity checks, etc.

Post by Stephen Hoffman
Because if nobody looks at the whole of keeping the containers separate
against potentially hostile activity, and if the apps aren't themselves
then potentially-substantially modified and shipped with support for
the subset environment within the containers, this only ends in a very
large molten crater. Because "LD as a container" as it exists now is
not substantially better than what PCSI now provides, or what PCSI
should provide.

Ayup. Part of the declarations tie into what system services can be
accessed, whether or not networking is available, and a whole host of
other details. Basically, provisioning and signatures. Mechanisms
which are already available on some systems.

Post by John E. Malmberg
So containers even on Linux are still in flux.

IT is in flux. Only going to be going faster, too. And security has
been dealing with fast flux for a while too, but I digress. OpenVMS
will have to compete with Linux and other platforms, too — with LXC or
otherwise, and what follows those. This if OpenVMS is going to
continue to target security, as has been recent fodder for more than a
little VSI marketing. This to avoid VSI products and VSI marketing
being at a disadvantage in competitive situations, that is.

Post by John E. Malmberg
LD is not a container.

Ayup. I'd agree. Some others here don't.

Post by John E. Malmberg
I could build a container that is hosted on a logical disk though.

Sure. But digging deeper, there's more than a little

Post by John E. Malmberg
My point is that VMS since at least version 4.1, if not earlier allows
non-privileged users to set up environments that fit the definition of
some of the containers in use on Linux.

This isn't about the past. This isn't about whether or not somebody
can build a repeatable build system over on some older Windows version.
This isn't about whether or not scripting works well with MS-DOS.
My interest in this is about 2022, 2027, and beyond, and what will be
expected of applications by then. Because that isn't LD, nor adding a
few decorations to PCSI.

Post by John E. Malmberg
What no one has done is packaged the method for fun or fame.

Because it's little different and little better than what PCSI provides.

Post by John E. Malmberg
For highly isolated privileged containers, that would take some higher
level programming. But for common container uses, there is really
nothing needed to be added to VMS.

Sure, but then having dragged around containers on OpenVMS — Python is
but one example that does this — there's all the fun of storing
transient files (somewhere), dealing with installs and removals (and
cleanups), and a host of other tasks that are best automated. This if
it's non-privileged, and there's no particular interest in restricting
access. Because all of this stuff is presently manual, error-prone,
and we are not operating in a time where we can add more manual effort,
more errors, overhead, processing, more breaches, and the rest.

--
Pure Personal Opinion | HoffmanLabs LLC

Simon Clubley

2017-03-02 00:05:58 UTC

Post by John E. Malmberg
I have not tried this, but it looks like TCPIP Services will allow
assigning multiple IP addresses to an interface.

Yes you can, but what actually happens is that you create a pseudo
interface for each IP address and the pseudo interface is a child
of the main interface.

I've used it before when collapsing parts of what was previously
part of a regional WAN back into a local LAN.

And for goodness sake be careful when doing it as it's all too easy
to typo and mess up the wrong interface; I was always very seriously
careful when doing this. Make sure you first have a way of getting
back into your VMS system if you are trying to configure a VMS system
remotely.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Bart Zorn

2017-03-02 07:04:50 UTC

Post by John E. Malmberg
I have not tried this, but it looks like TCPIP Services will allow
assigning multiple IP addresses to an interface.

Yes you can, but what actually happens is that you create a pseudo
interface for each IP address and the pseudo interface is a child
of the main interface.
I've used it before when collapsing parts of what was previously
part of a regional WAN back into a local LAN.
And for goodness sake be careful when doing it as it's all too easy
to typo and mess up the wrong interface; I was always very seriously
careful when doing this. Make sure you first have a way of getting
back into your VMS system if you are trying to configure a VMS system
remotely.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world

Yes, you can apply more than one IP address to an interface. But whether or not a pseudo interface is created for this purpose depends on how you define the adresses. When you use the TCPIP command utility, you get the pseudo interfaces. But when you (only) use the ifconfig command, you do not get them. I believe that the latter gives you a cleaner configuration.

Bart

Paul Sture

2017-03-04 08:42:18 UTC

Post by Stephen Hoffman
How do two different containers on the same box both utilize port 443?

Wouldn't a front end reverse proxy server solve this problem?

"One IP address, multiple SSL sites? Beating the great IPv4 squeeze"

<https://www.theregister.co.uk/2017/03/01/nginx_and_the_end_of_ip4/>

FWIW I'm currently looking at using nginx to cache both individual
software packages and container (of sorts) images which are quite large.

--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher

IanD

2017-02-26 06:54:36 UTC

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.

LD is the "ripping a CD" or "downloading a disk image" stage — little
more than distribution of the bits, and quite possibly unsigned — of
what's involved with containers.

<snip>

LD isn't in the same ballpark as fully fledged containers are but they are useful IMO, certainly more flexible than having to deal with physical disks alone

For them to be more useful, they would need in my view the following...

- Encryption

- Some form of authentication mechanism (as you have pointed out)

- Partitioning (across multiple volumes. Perhaps this could be how we get software RAID on VMS ?)

- Compression (then they could be used as a viable staged backup mechanism. I was looking to use LD recently for staged backup storage but the lack of compression ruled it out quickly - having to wind through savesets in serial on an LTO4 is painful. It must be infuriating dealing with the likes of higher LTO forms, even with partitioning - lol, even tapes support partitioning!! Past time for VMS to do the same)

- Live changes (including expansion / reduction). Obviously difficult to achieve but if a vision is set then as you make changes along the way you can put in attributes to make the vision a reality 'one day' (VMDK and others support dynamic expansion already I believe)

- Interoperability with other OS's. Supporting different disk file types such as VDI or VMDK will mean better ability to transfer data back/forth etc.

- Snapshots (that can deal with processes with inflight data updates so that a 100% guaranteed image can be obtained)

LD, while ok, needs more work to be really useful IMO. Hopefully most of the above is being addressed as VMS moves to support virtualisation properly on x86

David Froble

2017-02-26 10:19:06 UTC

Post by IanD

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.

LD is the "ripping a CD" or "downloading a disk image" stage — little
more than distribution of the bits, and quite possibly unsigned — of
what's involved with containers.

<snip>
LD isn't in the same ballpark as fully fledged containers are but they are useful IMO, certainly more flexible than having to deal with physical disks alone
For them to be more useful, they would need in my view the following...
- Encryption
- Some form of authentication mechanism (as you have pointed out)
- Partitioning (across multiple volumes. Perhaps this could be how we get software RAID on VMS ?)
- Compression (then they could be used as a viable staged backup mechanism. I was looking to use LD recently for staged backup storage but the lack of compression ruled it out quickly - having to wind through savesets in serial on an LTO4 is painful. It must be infuriating dealing with the likes of higher LTO forms, even with partitioning - lol, even tapes support partitioning!! Past time for VMS to do the same)
- Live changes (including expansion / reduction). Obviously difficult to achieve but if a vision is set then as you make changes along the way you can put in attributes to make the vision a reality 'one day' (VMDK and others support dynamic expansion already I believe)
- Interoperability with other OS's. Supporting different disk file types such as VDI or VMDK will mean better ability to transfer data back/forth etc.
- Snapshots (that can deal with processes with inflight data updates so that a 100% guaranteed image can be obtained)
LD, while ok, needs more work to be really useful IMO. Hopefully most of the above is being addressed as VMS moves to support virtualisation properly on x86

Discussing disks is interesting, just as discussing other things of the past.
Looking forward, discussing NV memory seems to be more interesting.

Kerry Main

2017-02-26 14:06:36 UTC

-----Original Message-----
IanD via Info-vax
Sent: February 26, 2017 1:55 AM
Subject: Re: [Info-vax] Will x86-64 VMS run on a laptop ?

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.

LD is the "ripping a CD" or "downloading a disk image" stage — little
more than distribution of the bits, and quite possibly unsigned — of
what's involved with containers.

Bootable LD's that support AES 256 level encryption that is also compatible with existing and planned BIOS level security mechanisms would keep me happy for this specific area.

- Encryption
- Some form of authentication mechanism (as you have pointed out)
- Partitioning (across multiple volumes. Perhaps this could be how we
get software RAID on VMS ?)
- Compression (then they could be used as a viable staged backup
mechanism. I was looking to use LD recently for staged backup storage
but the lack of compression ruled it out quickly - having to wind
through savesets in serial on an LTO4 is painful. It must be infuriating
dealing with the likes of higher LTO forms, even with partitioning - lol,
even tapes support partitioning!! Past time for VMS to do the same)

With single 60TB SSD flash and 8TB NV disks now available (and greater sizes coming), do we need compression and tapes?

Google "60TB Seagate"

- Live changes (including expansion / reduction). Obviously difficult to
achieve but if a vision is set then as you make changes along the way
you can put in attributes to make the vision a reality 'one day' (VMDK
and others support dynamic expansion already I believe)

With TB level NV system disks, does one need to expand a system volume in the next number of years?

- Interoperability with other OS's. Supporting different disk file types
such as VDI or VMDK will mean better ability to transfer data
back/forth etc.

The way one transfers data between guest OS's on VMware / Hyper-V is via the network.

- Snapshots (that can deal with processes with inflight data updates so
that a 100% guaranteed image can be obtained)

With VMware, the guest OS is simply a single file, so their answer is to quiet the guest, copy the file and resume the OS.

Once mounted, LD images can be updated just like any other disk.

LD, while ok, needs more work to be really useful IMO. Hopefully most
of the above is being addressed as VMS moves to support
virtualisation properly on x86

With hyper converged strategies, the world is rapidly moving to virtualized OS instances.

Companies like VSI and Microsoft are not going to care what HW their OS is running on because their license and/or support charges are the same regardless.

For those not familiar with these emerging hyper converged strategies, I highly recommend reading up because this is happening big time today.

A few links to the more popular hyper converged options currently being deployed in big DC's today:
https://www.nutanix.com/

http://www.dell.com/ca/business/p/hyper-converged-infrastructure

https://www.vmware.com/radius/five-things-come-hyper-converged-infrastructure/

https://www.hpe.com/us/en/integrated-systems/hyper-converged.html

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-02-27 16:32:50 UTC

Post by IanD

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.

LD is the "ripping a CD" or "downloading a disk image" stage — little>
more than distribution of the bits, and quite possibly unsigned — of>
what's involved with containers.

<snip>
LD isn't in the same ballpark as fully fledged containers are but they
are useful IMO, certainly more flexible than having to deal with
physical disks alone

Sure, but then we're discussing what was available twenty years ago and
not what's available now, much less what will be available in five or
ten years from now. If you're producing products, you have to aim
years into the future for any substantial work — end-users are largely
focused on what they've seen and what's available. (This is also why
asking end-users for their input on new product features and
capabilities is difficult, as they'll tell you what they have and know
about, and not what they really want, or features they really could
use. Or they'll ask for something that the producer might never be
able to provide at a profit, as can easily happen.)

Post by IanD
For them to be more useful, they would need in my view the following...
,,,
LD, while ok, needs more work to be really useful IMO. Hopefully most
of the above is being addressed as VMS moves to support virtualisation
properly on x86

You're missing more than a few bits around making this sort of stuff
useful and manageable and isolatable, much less making it competitive
with what's already out there. Creating the containers, storing and
managing and loading the containers, automated inventory of the servers
hosting the containers, restarting, dealing with the startups and not
having to edit OpenVMS startup files manually, keeping the containers
from getting tangled up due to stupid coding or software
vulnerabilities or malicious code from a supplier, and a whole host of
other details. Software containers are a form of automation, and you
really need to provide the pieces to allow that, or integrate with some
tool or framework that provides that — very much akin to how containers
revolutionized transportation decades ago, there's a whole lot involved
beyond the variously-sized big steel boxes.) Simply catching up with
what's already available now on other platforms — and I'm not referring
to comparisons with the difficulties of achieving repeatable Windows
software builds here, though that is a surprisingly good metaphor for
the difficulties involved with automating software deployments on
OpenVMS — is not an easy problem, either.

--
Pure Personal Opinion | HoffmanLabs LLC

David Froble

2017-02-25 19:12:42 UTC

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.
Download a profile specific LD container (e.g. customized Dev env with development languages and selected open source prod's), boot, run some minor custom start-up gui/script and away you go.
Perhaps it would make it much easier in a VMware world which uses templates to create custom VM's?

Many things can be considered "nice" ....

Ok, on a VM you might more easily be able to boot from a container file.

As most containers are now handled, it's all software. That's fine, when you
can run the software. But for booting from HW, the software is not yet runable.
Now you're back to special device drivers. You know, those things which don't
exist for many things as far as VMS is concerned. Now you want to expand the
list of required device drivers? It's not just one. It's maybe a driver for
every device you wish to boot a container file from.

At some point you got to stop and ask yourself, how do you access a file, when
the file system isn't yet running?

To use containers, as they are now normally implemented, you first got to get
some form of OS and file system running, right? Sort of like "chicken and egg".

Not saying it cannot be done, but, I have to question the value vs cost.

Jan-Erik Soderholm

2017-02-25 23:41:05 UTC

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.
Download a profile specific LD container (e.g. customized Dev env with
development languages and selected open source prod's), boot, run some
minor custom start-up gui/script and away you go.
Perhaps it would make it much easier in a VMware world which uses
templates to create custom VM's?

Many things can be considered "nice" ....
Ok, on a VM you might more easily be able to boot from a container file.
As most containers are now handled, it's all software. That's fine, when
you can run the software. But for booting from HW, the software is not yet
runable. Now you're back to special device drivers. You know, those
things which don't exist for many things as far as VMS is concerned. Now
you want to expand the list of required device drivers? It's not just
one. It's maybe a driver for every device you wish to boot a container
file from.
At some point you got to stop and ask yourself, how do you access a file,
when the file system isn't yet running?

Are you talkning about the host system (probably Windows or Linux) file
system or the guest (VMS) file system?

In the case of the container file for a guest OS, the basic file
access is done by the host OS. It in turn preents the container
to the guest OS as it it had been a hardware disk. And the guest
OS simply boot from it using it's standard and normal drivers.

Post by David Froble
To use containers, as they are now normally implemented, you first got to
get some form of OS and file system running, right?

Sure, that is usualy a Windows or Linux host system.

Post by David Froble
Sort of like "chicken and egg".

No, not at all. For VMS, It is just booting as usual.

Post by David Froble
Not saying it cannot be done, but, I have to question the value vs cost.

The value is to be able to run on a hardware that you do not have
support for. The hardware support is handled by the VM.

David Froble

2017-02-26 05:41:33 UTC

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.
Download a profile specific LD container (e.g. customized Dev env with
development languages and selected open source prod's), boot, run some
minor custom start-up gui/script and away you go.
Perhaps it would make it much easier in a VMware world which uses
templates to create custom VM's?

Many things can be considered "nice" ....
Ok, on a VM you might more easily be able to boot from a container file.

You missed this Jan-Erik. Everything below was talking about on HW, not a VM.

Post by David Froble
As most containers are now handled, it's all software. That's fine, when
you can run the software. But for booting from HW, the software is not yet
runable. Now you're back to special device drivers. You know, those
things which don't exist for many things as far as VMS is concerned. Now
you want to expand the list of required device drivers? It's not just
one. It's maybe a driver for every device you wish to boot a container
file from.
At some point you got to stop and ask yourself, how do you access a file,
when the file system isn't yet running?

Are you talkning about the host system (probably Windows or Linux) file
system or the guest (VMS) file system?
In the case of the container file for a guest OS, the basic file
access is done by the host OS. It in turn preents the container
to the guest OS as it it had been a hardware disk. And the guest
OS simply boot from it using it's standard and normal drivers.

Post by David Froble
To use containers, as they are now normally implemented, you first got to
get some form of OS and file system running, right?

Sure, that is usualy a Windows or Linux host system.

Post by David Froble
Sort of like "chicken and egg".

No, not at all. For VMS, It is just booting as usual.

Post by David Froble
Not saying it cannot be done, but, I have to question the value vs cost.

The value is to be able to run on a hardware that you do not have
support for. The hardware support is handled by the VM.

Jan-Erik Soderholm

2017-02-26 08:55:25 UTC

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.
Download a profile specific LD container (e.g. customized Dev env with
development languages and selected open source prod's), boot, run some
minor custom start-up gui/script and away you go.
Perhaps it would make it much easier in a VMware world which uses
templates to create custom VM's?

Many things can be considered "nice" ....
Ok, on a VM you might more easily be able to boot from a container file.

You missed this Jan-Erik. Everything below was talking about on HW, not a VM.

Then I do not understand your question. On HW, whatever you are booting
does need to understand the real HW, of course. Did you ask about that?

You can not "boot the HW" directly from a "container file", if the HW
doesn't have support to read them directly, of course.

If that was what you ment, you were stating the obviouse. Fine.

As you can see from the reply from Arne, it looked like you was

Post by David Froble
Nice explanation Steve. But, now back to my question, about booting an
OS that is in a container file, as if it was on a disk (or other)
device, and using VMS utilities, such as MOUNT, with them. Remember
that question?

I believe that is what most virtualization software that runs on a
host OS instead of directly on the metal does.
And the virtualization software make it look like areal disk.
Arne

David Froble

2017-02-26 10:24:14 UTC

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.
Download a profile specific LD container (e.g. customized Dev env with
development languages and selected open source prod's), boot, run some
minor custom start-up gui/script and away you go.
Perhaps it would make it much easier in a VMware world which uses
templates to create custom VM's?

Many things can be considered "nice" ....
Ok, on a VM you might more easily be able to boot from a container file.

You missed this Jan-Erik. Everything below was talking about on HW, not a VM.

Then I do not understand your question. On HW, whatever you are booting
does need to understand the real HW, of course. Did you ask about that?
You can not "boot the HW" directly from a "container file", if the HW
doesn't have support to read them directly, of course.
If that was what you ment, you were stating the obviouse. Fine.

Yes, that was thew discussion. I could have been more explicit. Need to do
that to avoid misunderstanding.

I could see firmware being able to access a file system. I just don't see that
it would be all that cost effective. Also it would usually be chasing a moving
target as HW and file systems change.

Post by Jan-Erik Soderholm
As you can see from the reply from Arne, it looked like you was

I believe that is what most virtualization software that runs on a
host OS instead of directly on the metal does.
And the virtualization software make it look like areal disk.
Arne

Kerry Main

2017-02-26 20:48:06 UTC

-----Original Message-----
David Froble via Info-vax
Sent: February 26, 2017 5:24 AM
Subject: Re: [Info-vax] Will x86-64 VMS run on a laptop ?

Post by Kerry Main
On a similar vein, here is my vote for bootable LD containers.
Download a profile specific LD container (e.g. customized Dev

env

Post by Kerry Main
with development languages and selected open source prod's),

boot,

Post by Kerry Main
run some minor custom start-up gui/script and away you go.
Perhaps it would make it much easier in a VMware world which

uses

Post by Kerry Main
templates to create custom VM's?

Many things can be considered "nice" ....
Ok, on a VM you might more easily be able to boot from a

container

Post by David Froble
file.

You missed this Jan-Erik. Everything below was talking about on

HW,

Post by David Froble
not a VM.

Then I do not understand your question. On HW, whatever you are
booting does need to understand the real HW, of course. Did you

ask

about that?

Post by Jan-Erik Soderholm
You can not "boot the HW" directly from a "container file", if the HW
doesn't have support to read them directly, of course.
If that was what you ment, you were stating the obviouse. Fine.

Yes, that was thew discussion. I could have been more explicit.

Need

to do that to avoid misunderstanding.
I could see firmware being able to access a file system. I just

don't see

that it would be all that cost effective. Also it would usually be

chasing

a moving target as HW and file systems change.

Post by Jan-Erik Soderholm
As you can see from the reply from Arne, it looked like you was

Post by David Froble
Nice explanation Steve. But, now back to my question, about

booting an >> OS that is in a container file, as if it was on a

disk

Post by Jan-Erik Soderholm
(or other) >> device, and using VMS utilities, such as MOUNT,

with

Post by Jan-Erik Soderholm
them. Remember >> that question?

Post by David Froble
I believe that is what most virtualization software that runs on a
host OS instead of directly on the metal does.
And the virtualization software make it look like areal disk.
Arne

For those not familiar with LD disk capabilities (like virtual tape
support, IO tracing etc)

https://www.digiater.nl/lddriver.html
https://www.digiater.nl/downloads/lddriver_technical_journal_jun2005.p
df

Btw, LD is now integrated with VSI releases.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

2017-02-26 21:13:02 UTC

Post by Jan-Erik Soderholm
Then I do not understand your question. On HW, whatever you are booting
does need to understand the real HW, of course. Did you ask about that?
You can not "boot the HW" directly from a "container file", if the HW
doesn't have support to read them directly, of course.
If that was what you ment, you were stating the obviouse. Fine.

Yes, that was thew discussion. I could have been more explicit. Need
to do that to avoid misunderstanding.
I could see firmware being able to access a file system. I just don't
see that it would be all that cost effective. Also it would usually be
chasing a moving target as HW and file systems change.

Not directly from the HW, but with the help of a loader like grub, which
- as already said - needs to support the file system where your
"container file" is:

menuentry "Fedora 25" {
set isofile="/images/f25.iso"
loopback loop $isofile
linux (loop)/isolinux/vmlinuz iso-scan/filename=$isofile
root=live:CDLABEL=Fedora-WS-Live-25-1-3 rootfstype=auto ro rd.live.image
rhgb rd.luks=0 rd.md=0 rd.dm=0 rd.live.overlay.thin=1
initrd (loop)/isolinux/initrd.img
}

Stephen Hoffman

2017-02-25 17:38:16 UTC

Post by Dirk Munk
A long time ago VMS had Mozilla and its successor Seamonkey as browser,
Today that is no longer viable. Maintaining a browser with the
necessary add-ons is very labour intensive and expensive. No need for
that, but you do need a browser on your notebook.

An entire OS and various layered products are ported to a completely>

Post by Dirk Munk
different hardware platform---doable. A modern browser---undoable?

The "modern browser" is a moving target.

So is the rest of the modern desktop, and the modern UI — looking at
graphics in isolation is a fool's errand — as there's far more than
just supporting Intel HD graphics or Intel Iris, or the AMD Ryzen
equivalent, or suchlike. Phillip prefers the command line as the UI,
but that's not something that really even needs graphics controller
support.

Maybe there is a middle path: a browser which doesn't support all
addons> >but is good enough for 95%.

The problem is that today's 95% is tomorrow's 10%.

One look at the increasing scope of WebKit or Edge or otherwise would
make that clear, certainly.

Post by Scott Dorsey
Somebody has to be constantly adding crap to it in order to keep up to date.

And securing various pieces and parts of the browsers, too.

Post by c***@gmail.com
RE: laptops
We are not doing anything to prevent VMS from running on laptops, after
all they are just more HW platforms. But being a real personal system
with the expected graphics involves a number of things that are just
not in the cards for us in the foreseeable future. Our resources are
better spent elsewhere where VMS has a more obvious role.

Ayup. Having graphics support is a rounding error in what folks then
expect a desktop to provide.

Post by c***@gmail.com
RE: virtual machines
As we have said from the very beginning we intend to run as a virtual
machine on as many hosts as we can. This may sound easy put it is
proving to be difficult, not insurmountable but a lot of work. We
currently use Fusion (VMware on MAC), kvm on Proliant, and Virtual Box
on MAC

"MAC" is a network address construct or a cosmetics company, among other uses.

Post by c***@gmail.com
for testing. The challenge is that the default for most hypervisors is
still BIOS with UEFI as an option but each hypervisor has it own
incantation of what it thinks simulates UEFI. We are gaining on it but
it is a struggle. There are big differences between the uefi you get in
platform FW versus what you get from hypervisors. HW versus hypervisors
should be irrelevant to the OS but the world is far less than perfect.

Last I checked, the macOS-based virtual machines can present BIOS, but
also allow UEFI.

Here's a good resource for this area of macOS and Dell/EMC VMware
products: http://www.virtuallyghetto.com

There are VM packages for macOS that are built on the Apple hypervisor
frameworks, for those interested in that topic:
https://developer.apple.com/reference/hypervisor
https://veertu.com
https://github.com/mist64/xhyve

No idea whether that'll be useable or even stable with OpenVMS or with
any other particular operating system guest, but Veertu and xhyve are
available and the related source code is posted on github.

Post by c***@gmail.com
RE: partitioned disks
We now create three partitions when we initialize a disk, one for uefi
and two (why it is not one is a complicated story) for the file system.

OpenVMS uses up to five GPT partitions. It's also not a particularly
complicated story, either. It's because OpenVMS does not support disk
partitioning, and I hacked together a very nasty workaround to account
for the boot and system drivers not including the necessary integer
math in the lower reaches of the I/O path.

Post by c***@gmail.com
The Boot Manager recognizes the uefi partition and SYSBOOT and the file
system recognize the other two as VMS. While we do not do it today
there is no reason why in the future, with the appropriate work, that
VMS would not init the entire disk and thus leave room for partitions
for other file systems. All the necessary low-level work is in place
today and we do think about this so we do not do anything to prevent it.

Up to five partitions are present for the boot and (when present)
maintenance partition, with up to three additional partitions
interspersed — how many depends on where the boot and maintenance
partitions are located relative to the beginning, to each other, and to
end of the available disk storage — these to protect the entirety of
the disk from being considered unallocated by console-level disk
information and partitioning tools, and all this hackery to allow
OpenVMS to consider the disk as a single unpartitioned unit of storage.
(There's added hackery here around the default boot file system
support being FAT for EFI/UEFI. While adding a file system module
into UEFI to support partitions containing ODS-2/ODS-5/VAFS boot
volumes would be technically possible, it's more effort and more
complexity.)

--
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman

2017-02-25 18:04:15 UTC

Post by Stephen Hoffman
OpenVMS uses up to five GPT partitions. It's also not a particularly
complicated story, either. It's because OpenVMS does not support disk
partitioning, and I hacked together a very nasty workaround to account
for the boot and system drivers not including the necessary integer
math in the lower reaches of the I/O path.

That includes the lack of partitioning support in MOUNT and DISMOUNT,
and the lack of partitioning support in other related tools needed to
analyze and maintain and repartition storage, and keeping track of
which volumes are mounted when the physical disk is to be yanked, and
the documentation for it all. This is not complex, but — like
graphics support — there's more than a little code that's not
immediately apparent. So — like the hybrid 32- and 64-bit addressing
design, or various other compromises to upward-compatibility —
tradeoffs are made. That's part of shipping most any complex product,
too.

--
Pure Personal Opinion | HoffmanLabs LLC

David Froble

2017-02-25 19:21:38 UTC

Post by Stephen Hoffman
OpenVMS uses up to five GPT partitions. It's also not a particularly
complicated story, either. It's because OpenVMS does not support
disk partitioning, and I hacked together a very nasty workaround to
account for the boot and system drivers not including the necessary
integer math in the lower reaches of the I/O path.

That includes the lack of partitioning support in MOUNT and DISMOUNT,
and the lack of partitioning support in other related tools needed to
analyze and maintain and repartition storage, and keeping track of which
volumes are mounted when the physical disk is to be yanked, and the
documentation for it all. This is not complex, but — like graphics
support — there's more than a little code that's not immediately
apparent. So — like the hybrid 32- and 64-bit addressing design, or
various other compromises to upward-compatibility — tradeoffs are
made. That's part of shipping most any complex product, too.

Curiosity ...

LD containers are usable on VMS. How, if such happens, do the VMS utilities
work with such things? I haven't done much with LD containers, can't remember
if the stuff implementing them does all such work.

I could probably find out most answers, but, I am just so incredibly lazy ..

:-)

Stephen Hoffman

2017-02-25 20:20:00 UTC

Curiosity ...
LD containers are usable on VMS. How, if such happens, do the VMS
utilities work with such things? I haven't done much with LD
containers, can't remember if the stuff implementing them does all such
work.
I could probably find out most answers, but, I am just so incredibly lazy ..

Kerry is extolling the virtues of here seems utterly indistinguishable
from a CD or DVD containing an app, an InfoServer service offering a
disk share, or a partition containing an app.

OpenVMS has offered these capabilities for decades, and Python
currently does exactly this using LD rather than dealing with the
limitations of what PCSI provides.

Using containers or using LD certainly includes the limitations and
problems inherently involved with trying to keep apps separate, adding
app-specific users for integrated server processes, preventing logical
name collisions, allocating privileges or IP addresses or ports or
whatever, restricting access to other containers or to random parts of
the system or network environment the app has no business accessing,
verifying whether the data and the apps are signed by a trusted entity,
licensing whatever components are integrated, dependencies and
integration and access across multiple distros when there's a suite of
related products or a product with dependencies on some other
container, getting the startups coordinated and sequenced, etc.

Then there's further along the path, of maintaining an inventory of
containers arrived or tested or ready for deployment or archived for
future use, and tools to add or upgrade or remove or relocate the apps
in the containers, and to deal with the bureaucratic baggage such as
licensing. Beyond isolation and reproducibility and the rest, many
of the folks also expect better automation around using the containers.

All certainly possible, but keeping semi-trusted apps from getting
tangled isn't easy. Semi-trusted? Sure, you might trust who you got
the app from, but what happens if there's a mistake or a vulnerability
in the app code, or some dependency underneath the container or the DVD
or whatever; how to you isolate the damage?

If there's a significant difference between container sprawl and VM
sprawl, I just don't see it. There are differences in how tools or
layered products or databases are licensed to a server, and how similar
licensing within or across containers might or will arise. I'm
certainly expecting to have to license products that are baked into the
container, if they're not licensed system-wide. Which means the
biggest current differences are in server-wide licensing for the OS or
the products, and — if containers become ubiquitous — I just don't see
equally or potentially more expensive licenses for containers arising.
DEC had system-wide and per-user licensing, per-core and per-socket
licensing, capacity on demand, and a plethora of other programs.
TL;DR: Containers are a form of licensing arbitrage. Whether there's
enough of an efficiency gain from containers and intro-OS sharing
versus parallel VM guests to trade off the complexity of trying to
write OS and end-user code for and then keep apps from getting tangled,
only testing will show.

--
Pure Personal Opinion | HoffmanLabs LLC

Kerry Main

2017-02-25 21:27:25 UTC

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: February 25, 2017 3:20 PM
Subject: Re: [Info-vax] Will x86-64 VMS run on a laptop ?

Post by Stephen Hoffman
OpenVMS uses up to five GPT partitions. It's also not a

particularly

Post by Stephen Hoffman
complicated story, either. It's because OpenVMS does not

support disk

Post by Stephen Hoffman
partitioning, and I hacked together a very nasty workaround to
account for the boot and system drivers not including the

necessary

Post by Stephen Hoffman
integer math in the lower reaches of the I/O path.

That includes the lack of partitioning support in MOUNT and

DISMOUNT,

Post by Stephen Hoffman
and the lack of partitioning support in other related tools needed to
analyze and maintain and repartition storage, and keeping track of
which volumes are mounted when the physical disk is to be yanked,

and

Post by Stephen Hoffman
the documentation for it all. This is not complex, but — like
graphics support — there's more than a little code that's not
immediately apparent. So — like the hybrid 32- and 64-bit

addressing

Post by Stephen Hoffman
design, or various other compromises to upward-compatibility —
tradeoffs are made. That's part of shipping most any complex

product,

Post by Stephen Hoffman
too.

Curiosity ...
LD containers are usable on VMS. How, if such happens, do the VMS
utilities work with such things? I haven't done much with LD
containers, can't remember if the stuff implementing them does all
such work.
I could probably find out most answers, but, I am just so incredibly

lazy ..
Kerry is extolling the virtues of here seems utterly indistinguishable
from a CD or DVD containing an app, an InfoServer service offering a
disk share, or a partition containing an app.
OpenVMS has offered these capabilities for decades, and Python
currently does exactly this using LD rather than dealing with the
limitations of what PCSI provides.

[snip..]

Something to consider .. each VMware guest OS is basically a single file on the SAN.

When they move a VM host to another system, they simply provide the pointer to the file on the other system, save process info and then restart the process with the file pointer on the other system.

A bit simplified, but that’s it in a nutshell.

Yes, there are no doubt big differences in terms of where OpenVMS LD is today, but the single file per guest OS is at the core of VMware arch and strategy.

VMDK file - VMDK (Virtual Machine Disk) is a file format that describes containers for virtual hard disk drives to be used in virtual machines.

How VMware dynamically transfers a Guest OS from one server to another with close to zero impact on clients:
https://en.wikipedia.org/wiki/VMware_ESXi

"Live migration (vMotion) in ESX allows a virtual machine to move between two different hosts. Live storage migration (Storage vMotion) enables live migration of virtual disks on the fly. During vMotion Live Migration (vLM) of a running virtual machine (VM) the content of the (RAM) memory of the VM is sent from the running VM to the new VM (the instance on another host that will become the running VM after the vLM). The content of memory is by its nature changing all the time. ESX uses a system where the content is sent to the other VM and then it will check what data is changed and send that, each time smaller blocks. At the last moment it will very briefly 'freeze' the existing VM, transfer the last changes in the RAM content and then start the new VM. The intended effect of this process is to minimize the time during which the VM is suspended; in a best case this will be the time of the final transfer plus the time required to start the new VM"

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-02-27 15:24:52 UTC

Post by Kerry Main
Something to consider .. each VMware guest OS is basically a single file on the SAN.
When they move a VM host to another system, they simply provide the
pointer to the file on the other system, save process info and then
restart the process with the file pointer on the other system.

That's the basis of containers, as well. Though containers require
reimplementing the isolation inherently provided by the VM and separate
guest instances within the operating system, if you want to keep the
apps from getting tangled. If the developers are willing to continue
with the usually home-grown and far too often manually-managed and
non-isolated implementation we've all been dealing with for the last
~twenty years and with home-grown tools for upgrades and data
migrations, then using LD works, too.

Post by Kerry Main
"Live migration (vMotion) in ESX allows a virtual machine to move
between two different hosts.

OpenVMS tried to get there some years ago, but the run-time environment
was too complex to migrate processes, and the environment to restart on
another server with full consistency requires application assistance.
It'll be interesting to see whether OpenVMS can be migrated as a VM
guest; a subset of supported OpenVMS configurations will probably work
with some caveats, but some SDN assistance will probably be required.

--
Pure Personal Opinion | HoffmanLabs LLC

Hans Bachner

2017-02-28 00:58:15 UTC

Post by Stephen Hoffman
[...]
OpenVMS tried to get there some years ago, but the run-time environment
was too complex to migrate processes, and the environment to restart on
another server with full consistency requires application assistance.
It'll be interesting to see whether OpenVMS can be migrated as a VM
guest; a subset of supported OpenVMS configurations will probably work
with some caveats, but some SDN assistance will probably be required.

OpenVMS can be moved perfectly from one hypervisor host to another if
you run it in one of the major emulators. Just tested this during the
last weekend - moved a VM with 2 CHARON-AXP instances (running as a
cluster) without any issues.

There are only rare cases where migration is not feasible, e.g. if a
node running a database updates its caches in memory faster than VMware
can copy memory contents to a different host. But this case probably
isn't VMS-specific.

Hans.

Stephen Hoffman

2017-02-28 13:57:28 UTC

Post by Hans Bachner

OpenVMS can be moved perfectly from one hypervisor host to another if
you run it in one of the major emulators. Just tested this during the
last weekend - moved a VM with 2 CHARON-AXP instances (running as a
cluster) without any issues.
There are only rare cases where migration is not feasible, e.g. if a
node running a database updates its caches in memory faster than VMware
can copy memory contents to a different host. But this case probably
isn't VMS-specific.

As I stated, a subset of these migrations will probably work. Tried
this with a member of a cluster? With SAN storage active?

I fully expect that most any active system will have caches active and
might or will run afoul of that caveat you've mentioned, too.

Which means in aggregate we're back to the same sort of a "solution"
that the storage folks have been trying out since the 1980s —
clustering or continous backups at the hardware level, without host
introspection — and that they've been failing.

If the VM has hooks to quiesce stuff — same mess as online backups, BTW
— then this VM migration will be rather more reliable.

Coordination with host activity and the related introspection are hard
problems, so they get ignored, so we get mostly-solutions that
mostly-work.

Interestingly, history tends to be a hard problem in IT, too. Past
failures and why those failures occurred is not something most of us
spend much time learning about. We often either ignore those, or we
"cargo cult" the solutions we have previously used.

--
Pure Personal Opinion | HoffmanLabs LLC

Hans Bachner

2017-02-28 21:32:39 UTC

Post by Hans Bachner

Post by Stephen Hoffman
[...]
OpenVMS tried to get there some years ago, but the run-time
environment was too complex to migrate processes, and the environment
to restart on another server with full consistency requires
application assistance. It'll be interesting to see whether OpenVMS
can be migrated as a VM guest; a subset of supported OpenVMS
configurations will probably work with some caveats, but some SDN
assistance will probably be required.

OpenVMS can be moved perfectly from one hypervisor host to another if
you run it in one of the major emulators. Just tested this during the
last weekend - moved a VM with 2 CHARON-AXP instances (running as a
cluster) without any issues.
There are only rare cases where migration is not feasible, e.g. if a
node running a database updates its caches in memory faster than
VMware can copy memory contents to a different host. But this case
probably isn't VMS-specific.

As I stated, a subset of these migrations will probably work. Tried
this with a member of a cluster? With SAN storage active?

I'll be able to test that soon at another cuatomer's site.

Post by Stephen Hoffman
I fully expect that most any active system will have caches active and
might or will run afoul of that caveat you've mentioned, too.

With vMotion, the caches go with the moved instance.

To solve the problem I mentioned above (fast updates on large parts of
the memory), there are two ways:

- use faster interconnects so memory contents can be copied over faster
(we get improvements here all the time)

- quiesce the application, which obviously needs application assistence

Post by Stephen Hoffman
Which means in aggregate we're back to the same sort of a "solution"
that the storage folks have been trying out since the 1980s — clustering
or continous backups at the hardware level, without host introspection —
and that they've been failing.
If the VM has hooks to quiesce stuff — same mess as online backups, BTW
— then this VM migration will be rather more reliable.

I agree that backup is a completely different topic. Without quiescing
(or shutting down') the applications, you never get a 100% "clean" backup.

Post by Stephen Hoffman
Coordination with host activity and the related introspection are hard
problems, so they get ignored, so we get mostly-solutions that mostly-work.

which are "good enough" in many cases. You don't need a Corvette's brake
for a sub-compact.

Post by Stephen Hoffman
Interestingly, history tends to be a hard problem in IT, too. Past
failures and why those failures occurred is not something most of us
spend much time learning about. We often either ignore those, or we
"cargo cult" the solutions we have previously used.

Hans.

David Froble

2017-02-25 23:46:22 UTC

Post by Stephen Hoffman
OpenVMS uses up to five GPT partitions. It's also not a
particularly complicated story, either. It's because OpenVMS does
not support disk partitioning, and I hacked together a very nasty
workaround to account for the boot and system drivers not including
the necessary integer math in the lower reaches of the I/O path.

That includes the lack of partitioning support in MOUNT and DISMOUNT,
and the lack of partitioning support in other related tools needed to
analyze and maintain and repartition storage, and keeping track of
which volumes are mounted when the physical disk is to be yanked, and
the documentation for it all. This is not complex, but — like
graphics support — there's more than a little code that's not
immediately apparent. So — like the hybrid 32- and 64-bit
addressing design, or various other compromises to
upward-compatibility — tradeoffs are made. That's part of shipping
most any complex product, too.

Curiosity ...
LD containers are usable on VMS. How, if such happens, do the VMS
utilities work with such things? I haven't done much with LD
containers, can't remember if the stuff implementing them does all
such work.
I could probably find out most answers, but, I am just so incredibly lazy ..

Kerry is extolling the virtues of here seems utterly indistinguishable
from a CD or DVD containing an app, an InfoServer service offering a
disk share, or a partition containing an app.
OpenVMS has offered these capabilities for decades, and Python currently
does exactly this using LD rather than dealing with the limitations of
what PCSI provides.
Using containers or using LD certainly includes the limitations and
problems inherently involved with trying to keep apps separate, adding
app-specific users for integrated server processes, preventing logical
name collisions, allocating privileges or IP addresses or ports or
whatever, restricting access to other containers or to random parts of
the system or network environment the app has no business accessing,
verifying whether the data and the apps are signed by a trusted entity,
licensing whatever components are integrated, dependencies and
integration and access across multiple distros when there's a suite of
related products or a product with dependencies on some other container,
getting the startups coordinated and sequenced, etc.
Then there's further along the path, of maintaining an inventory of
containers arrived or tested or ready for deployment or archived for
future use, and tools to add or upgrade or remove or relocate the apps
in the containers, and to deal with the bureaucratic baggage such as
licensing. Beyond isolation and reproducibility and the rest, many of
the folks also expect better automation around using the containers.
All certainly possible, but keeping semi-trusted apps from getting
tangled isn't easy. Semi-trusted? Sure, you might trust who you got
the app from, but what happens if there's a mistake or a vulnerability
in the app code, or some dependency underneath the container or the DVD
or whatever; how to you isolate the damage?
If there's a significant difference between container sprawl and VM
sprawl, I just don't see it. There are differences in how tools or
layered products or databases are licensed to a server, and how similar
licensing within or across containers might or will arise. I'm
certainly expecting to have to license products that are baked into the
container, if they're not licensed system-wide. Which means the
biggest current differences are in server-wide licensing for the OS or
the products, and — if containers become ubiquitous — I just don't see
equally or potentially more expensive licenses for containers arising.
DEC had system-wide and per-user licensing, per-core and per-socket
licensing, capacity on demand, and a plethora of other programs.
TL;DR: Containers are a form of licensing arbitrage. Whether there's
enough of an efficiency gain from containers and intro-OS sharing versus
parallel VM guests to trade off the complexity of trying to write OS and
end-user code for and then keep apps from getting tangled, only testing
will show.

Nice explanation Steve. But, now back to my question, about booting an OS that
is in a container file, as if it was on a disk (or other) device, and using VMS
utilities, such as MOUNT, with them. Remember that question?

:-)

Jan-Erik Soderholm

2017-02-25 23:56:05 UTC

Post by David Froble
But, now back to my question, about booting an OS
that is in a container file, as if it was on a disk (or other) device, and
using VMS utilities, such as MOUNT, with them. Remember that question?
:-)

Since the host OS/VM environment presents the container file to
the guest OS just as if it had been a hardware disk, everything
works just as usual. You INIT, MOUNT, ANA/DISK and so on just
as if it had been a hardware disk.

The only difference today is that the current LD containers
are MOUNT'ed from within VMS after it has been booted, you
can not boot directly from them.

I can MOUNT and "use" the VMS 8.4 ISO container file using LD
today, but you can not boot directly from it, becuse there is
nothing today that presents the file as a device to the VMS
boot routines. That is what the VM does.

Arne Vajhøj

2017-02-26 03:56:48 UTC

I believe that is what most virtualization software that runs on a
host OS instead of directly on the metal does.

And the virtualization software make it look like areal disk.

Arne

Stephen Hoffman

2017-02-27 16:14:11 UTC

Bootstrap of a disk image can happen indirectly via InfoServer and the
network bootstrap path. That's how I've booted various installers on
remote Itanium systems, for instance — set up one local system as an
InfoServer, load the kits on that, boot the other boxes via the
network. There's no direct support for bootstraps from a disk image,
though a two-stage boot as was used on some VAX systems aeons ago would
also be feasible. No support for booting from partitions in OpenVMS,
either. Booting via EFI would also be feasible with some added file
system work, as EFI already supports access to the FAT file system in
the base distro and various EFI implementations have additions support
access into other file systems. Or booting from a partition, as EFI
already knows about those. Nothing (technically) precludes EFI
accessing ODS-2 or ODS-5 or VAFS and performing a container boot from
that. The bootstrap on OpenVMS is a hack that presents a partition to
EFI and presents as a contiguous, no-move disk file to OpenVMS. As
for MOUNT and the rest, the LD giblets look and work as regular disks.
Following further down the rabbit hole, containers are not necessarily
whole operating systems — that'd incur the licensing charges that folks
are seeking to arbitrage — they can be self-contained packages of apps
and related dependencies, though it's not very far from a container
with an operating system and booting that.
https://pewpewthespells.com/blog/setup_docker_on_mac.html

--
Pure Personal Opinion | HoffmanLabs LLC

c***@gmail.com

2017-02-27 21:25:14 UTC

Post by Stephen Hoffman
Up to five partitions are present for the boot and (when present)
maintenance partition, with up to three additional partitions
interspersed — how many depends on where the boot and maintenance
partitions are located relative to the beginning, to each other, and to
end of the available disk storage — these to protect the entirety of
the disk from being considered unallocated by console-level disk
information and partitioning tools, and all this hackery to allow
OpenVMS to consider the disk as a single unpartitioned unit of storage.
(There's added hackery here around the default boot file system
support being FAT for EFI/UEFI. While adding a file system module
into UEFI to support partitions containing ODS-2/ODS-5/VAFS boot
volumes would be technically possible, it's more effort and more
complexity.)

Things are much different on x86 now that we always boot from memory disk. There are always three partitions.

Also, the Boot Manager only has to know about one file structure, now and into the future, because the only file it ever reads is the memory disk file which VMS creates. (We chose ODS5). Same goes for the primitive file system in SYSBOOT; it only has to read the memory disk file. We don't encounter the structure of the boot device itself until it is mounted with the runtime drivers and the appropriate file system code - ODS2, ODS5, new file system, etc. This was one of the 3 main goals of the "always boot from memory disk" project - never need to touch the primitive file system again.

Stephen Hoffman

2017-02-28 00:24:32 UTC

Things are much different on x86 now that we always boot from memory
disk. There are always three partitions.
Also, the Boot Manager only has to know about one file structure, now
and into the future, because the only file it ever reads is the memory
disk file which VMS creates. (We chose ODS5). Same goes for the
primitive file system in SYSBOOT; it only has to read the memory disk
file. We don't encounter the structure of the boot device itself until
it is mounted with the runtime drivers and the appropriate file system
code - ODS2, ODS5, new file system, etc. This was one of the 3 main
goals of the "always boot from memory disk" project - never need to
touch the primitive file system again.

Somebody will probably be ripping that out and replacing it with a
console-native-boot implementation (eventually), but the memory disk
approach will server as a quite workable compromise and a good
intermediate step... Once the rest of the necessary environment within
OpenVMS is in place to perform that migration, but that won't be for
five or ten years, if then. There are certainly very good reasons to
not go to a console native boot and to use the memory boot, but — like
most of these sequences and decisions and trade-offs — the results tend
to be more complex. It's unfortunate, but necessary.

--
Pure Personal Opinion | HoffmanLabs LLC

David Froble

2017-02-25 16:13:03 UTC

Post by Dirk Munk
Running it on a VM would be better. You could use any notebook/desktop
that is supported by the VM, and you could run Linux or Windows at the
same time.

But then you would also have to run the underlying OS.

An entire OS and various layered products are ported to a completely
different hardware platform---doable. A modern browser---undoable?
Maybe there is a middle path: a browser which doesn't support all addons
but is good enough for 95%.

Some things to realize, like them or not.

Can VMS be ported to x86? Not done yet. Hopefully it will happen. If so,
there might be enough revenue to make it worth while.

A browser is a user interface, normally for a workstation or personal use type
of system. VSI has sort of mentioned that for now VMS is to be considered a
"server" OS. It will be a great accomplishment if they can do that little thing.

Can a really great browser be implemented? Sure. All it takes is money. You
got the money to do that? It's easy to suggest spending, when it's someone
else's money.

This entire discussion reminds me of Jack Kennedy. He was once heard to say,
"ask not what your country can do for you, ask what you can do for your
country". Perhaps we are at such a time with VSI. If you want VMS in the
future, perhaps it's time for VMS users to "ask not what VSI can do for you, ask
what you can do for VMS"?

What's stopping Philip from developing a "modern browser" to run on x86 VMS?

Arne Vajhøj

2017-02-26 03:49:25 UTC

Post by David Froble
This entire discussion reminds me of Jack Kennedy. He was once heard to
say, "ask not what your country can do for you, ask what you can do for
your country". Perhaps we are at such a time with VSI. If you want VMS
in the future, perhaps it's time for VMS users to "ask not what VSI can
do for you, ask what you can do for VMS"?

That is unfortunately one of VMS'es problems.

There is a lot of people wanting something.

But most of those people do not want to or do not have time or skills
necessary to do some things.

VMS support for various open source projects has been suffering from
this for many years now.

Arne

IanD

2017-02-26 09:45:03 UTC

That is unfortunately one of VMS'es problems.
There is a lot of people wanting something.
But most of those people do not want to or do not have time or skills
necessary to do some things.
VMS support for various open source projects has been suffering from
this for many years now.
Arne

I would certainly like to be able to help out with open source on VMS but I lack the skills

A couple of problems overall though

1. Skills required
It seems to me, that the whole open source paradigm on VMS is so different to say picking up a package on Linux that you quickly run into porting issues. The depth of technical knowledge required to solve these porting issues are such that it involves in-depth knowledge

2. Build environments
Open source typically is not commercial unless coupled with service.
Developing on VMS requires a VMS environment kitted out with up to date compilers and OS.
There are Alpha emulators available for free and HP will lend you fairly up to date compilers but VMS has moved on.
I hear talk of, but as yet await eagerly a VSI hobbyist program (especially now that Alpha is also under their wing).
Itanium emulators that can boot VMS are as frequent as a squadron of pigs flying over my place at midday! and this is never going to change, so forget Itanium.
This leaves people hanging out for x86 and hoping that a hobbyist program also pops out of the woodwork

3. Mentorship / training / documentation
I'm a big advocate of mentoring. It's the fastest way to transfer knowledge and transfer any inbuilt philosophy of design of a system also. It takes time, both of the apprentice and of the mentor - lots of time!
Mentorship goes beyond training - it's akin to the ideas one picks up if you listen hard enough to the experienced people on this forum. Compressed years of wisdom and experience in choice sentence's. It takes time to 'hear it'.
There is no mentorship program available and I doubt the folks here have the time to invest in one either, most of them have full time roles to look after and a few have had personal hardships to deal with to boot.
Official training cost big dollars, way too much for me. I did lots of it many years ago when companies valued such things but these days they seem reluctant to invest in it. Training as in fronting up to a classroom to me doesn't hold a lot of value beyond locking yourself away in a room and progressing through a workbook.
I looked at MOOCS and the feasibility of setting up an Intro to VMS under one (why not, Microsoft are using this platform to push it's products) but I don't have the time or equipment to test all the examples one would want to take people through if conducting training.
Documentation. Enough said... Until VSI get their own site up and running we are stuck with HP's last rendition which doesn't cover anything under VSI and sadly has dropped most of the html format.

I think a mentorship program OR MOOC style course would give the biggest return on time invested to help bring others up to speed on VMS open source porting - anyone going to raise their hand to run such a program? I'll sign up and I'd also put some coin towards being a participant too

John E. Malmberg

2017-03-01 05:02:37 UTC

Post by IanD

Post by Arne VajhÃ¸j
There is a lot of people wanting something.
But most of those people do not want to or do not have time or skills
necessary to do some things.
VMS support for various open source projects has been suffering from
this for many years now.
Arne

I would certainly like to be able to help out with open source on VMS but I lack the skills

Not all skills required are programming. Helping out with proof
reading, web page organization, etetera, are also helpful.

Post by IanD
A couple of problems overall though
1. Skills required
It seems to me, that the whole open source paradigm on VMS is so
different to say picking up a package on Linux that you quickly run into
porting issues. The depth of technical knowledge required to solve these
porting issues are such that it involves in-depth knowledge

That is a matter of how you approach things. And most GNU projects are
very consistent on what they do for the generation of configure or
gnulib that they are using. So once a solution is found, it carries
over to many other projects.

Help is needed to keep GNV applications that have been ported to make
sure that the fixes needed are using common code, and to document what
hacks were used.

There are skills needed, and it turns out that knowing how to debug a
configure script and maintain a GNU building environment is a skill in
demand, and seems to pay very well. My last two jobs were in Linux
environments because of the skills learned getting the GNV environment
improved on VMS.

What I am doing is also what Bill Pedersen has stated. I am creating an
environment where you can start with the unmodified OpenSource
distribution and build it on VMS with no manual edits.

Once you understand how to set that up, projects can be ported very
quickly. We had shell shock fixed bash kits out with in 48 hours of the
official patch releases.

What I am not doing is taking the time to get the VMS specific changes
merged back to the upstream repositories, if the project does not
currently support VMS. It takes a lot of time to do that, and that is
something that help is needed. It takes someone that can learn what the
requirements of the upstream repository.

The other thing that I am doing is trying to make sure that the ports
are as complete as possible. Many open source ports to VMS are
incomplete where functionality is missing.

One of the hardest things is usually to update a port where there is a
VMS/DCL behavior that is in use that conflicts with what is needed to
use the same utility on GNV. In many times this can be resolved,

In a lot of cases the existing VMS code is either obsolete for VMS 5.4
only or earlier, or was never even correct for the original port.

Post by IanD
2. Build environments
Developing on VMS requires a VMS environment kitted out with up to date compilers and OS.
There are Alpha emulators available for free and HP will lend you
fairly up to date compilers but VMS has moved on.
I hear talk of, but as yet await eagerly a VSI hobbyist program
(especially now that Alpha is also under their wing).

My current build targets are VAX 7.3 where easily done, Alpha VMS
8.3/8.4, and IA64 8.4, all HP Hobbyist media distributions. While this
is missing some ECOs, the resulting code will run on VSI releases.

VSI has also released some evaluation kits.

Post by IanD
Itanium emulators that can boot VMS are as frequent as a squadron of
pigs flying over my place at midday! and this is never going to change,
so forget Itanium.

For most projects, an Itanium uses the same source code as Alpha.

For the updated GNV packages, committing a source code change to the
repository triggers a build on my Jenkins system within 24 hours.

So if someone just has Alpha 8.3 and gets a fix pushed, everything up to
building a kit will get tested on Alpha 8.3, 8.4, Itanium 8.4, and if
the project supports a VAX build, VAX 7.3.

Currently I have no way to make the Jenkins web pages available to the
public. I am looking at various solutions to that.
The easiest may be to send an e-mail update of successful builds to the
GNV developer list.

Post by IanD
This leaves people hanging out for x86 and hoping that a hobbyist
program also pops out of the woodwork

x86 is a ways away for hobbyists. For hobbyists, some of this is just
keeping the old equipment or emulations of it running.

Hopefully a lot of the CRTL hacks that are needed for porting will go
away with VMS 9.x. I expect that for VAX/Alpha/Itanium, if it will run
the the media for hobbyists it will run anywhere.

The power bill is what is the issue for keeping the older hardware
running now. I have required and eithernet controlled power switch, and
a future project will be to see how fast I can get the physical hardware
to boot on demand when needed for a build, or for a project to use.

Post by IanD
3. Mentorship / training / documentation I'm a big advocate of
mentoring. It's the fastest way to transfer knowledge and transfer
any inbuilt philosophy of design of a system also. It takes time,
both of the apprentice and of the mentor - lots of time!
Mentorship goes beyond training - it's akin to the ideas one picks
up if you listen hard enough to the experienced people on this forum.
Compressed years of wisdom and experience in choice sentence's. It
takes time to 'hear it'.
There is no mentorship program available and I doubt the folks here
have the time to invest in one either, most of them have full
time roles to look after and a few have had personal hardships to
deal with to boot.

Yes. I have been through 3 layoffs while working on VMS Open Source.
Each one resulted in a higher paying job, just not in VMS anymore.

But each layoff has also cost time in working on the ports.

But it was because I learned these skills, I am currently employed.

Post by IanD
Official training cost big dollars, way too much for me. I did lots
of it many years ago when companies valued such things but these days they
seem reluctant to invest in it. Training as in fronting up to a
classroom to me doesn't hold a lot of value beyond locking yourself away
in a room and progressing through a workbook.

It is my understanding that some of the commercial VMS training is quite
good.

For OpenSource though a good way is to get into building it and
deploying it and using the free tutorials on the wild wild web.

We have WIKIs on Sourceforge GNV and VMS-PORTS projects, but little
contributions to them.

Post by IanD
I think a mentorship program OR MOOC style course would give the
biggest return on time invested to help bring others up to speed on
VMS open source porting - anyone going to raise their hand to run
such a program? I'll sign up and I'd also put some coin towards being
a participant too

The closest we have is Bill's conference calls. And the participation
on them has been dropping off.

Regards,
-John
***@qsl.net_work

Moai

2017-02-27 01:59:57 UTC

There's nothing you can do for VMS itself since it's closed-source.

Post by David Froble
What's stopping Philip from developing a "modern browser" to run on x86 VMS?

You can do stuff for the VMS ecosystem though, which is what you meant.

Paul Sture

2017-03-04 07:34:41 UTC

Post by David Froble
Can a really great browser be implemented? Sure. All it takes is
money. You got the money to do that? It's easy to suggest spending,
when it's someone else's money.

Time and money.

Post by David Froble
This entire discussion reminds me of Jack Kennedy. He was once heard to say,
"ask not what your country can do for you, ask what you can do for your
country". Perhaps we are at such a time with VSI. If you want VMS in the
future, perhaps it's time for VMS users to "ask not what VSI can do
for you, ask what you can do for VMS"?

That one rather falls down when your own government is trying to export
your job.

Post by David Froble
What's stopping Philip from developing a "modern browser" to run on x86 VMS?

Time and more time. There's a huge learning curve to support the
latest stuff, and the existing browsers have a lot of code supporting
older websites, many of which contain broken code themselves.

--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher

Simon Clubley

2017-02-27 01:53:55 UTC

Post by Phillip Helbig (undress to reply)
An entire OS and various layered products are ported to a completely
different hardware platform---doable. A modern browser---undoable?

A modern browser is more complex than some operating systems.

Read the HTML 4 and CSS 2.1 specifications to see how complex even
older browsers needed to be and then look at HTML 5 and CSS 3 to see
how much more complex they have become on top of that.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Simon Clubley

2017-02-27 01:49:18 UTC

Post by Dirk Munk
Running it on a VM would be better. You could use any notebook/desktop
that is supported by the VM, and you could run Linux or Windows at the
same time. That would give you a browser also, VMS has no browser.
A long time ago VMS had Mozilla and its successor Seamonkey as browser,
Today that is no longer viable. Maintaining a browser with the necessary
add-ons is very labour intensive and expensive. No need for that, but
you do need a browser on your notebook.

I am actually seriously considering Seamonkey (or Pale Moon) as one
of my options when Firefox becomes unusable at the end of the year
(and when Classic Theme Restorer (which provides a usable Firefox UI)
will also stop working).

By this time next year, there's going to be major churn in the
browser market thanks to Mozilla's stupidity. Who knows, maybe
a new portable web browser might even come out of it and maybe
it might be portable to VMS. :-)

As for current browser options, I have in the past suggested maybe
porting Dillo to VMS, but it has no Javascript support and these
days even the web server interface on simple devices tends to require
Javascript.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Phillip Helbig (undress to reply)

2017-02-27 06:18:14 UTC

Post by Simon Clubley
I am actually seriously considering Seamonkey (or Pale Moon) as one
of my options when Firefox becomes unusable at the end of the year
(and when Classic Theme Restorer (which provides a usable Firefox UI)
will also stop working).
By this time next year, there's going to be major churn in the
browser market thanks to Mozilla's stupidity. Who knows, maybe
a new portable web browser might even come out of it and maybe
it might be portable to VMS. :-)

I'm clueless. What is happening to Firefox?

Simon Clubley

2017-02-27 08:20:05 UTC

I'm clueless. What is happening to Firefox?

Support for XUL based extensions is being removed from Firefox.

The replacement functionality is incompatible with existing XUL
extensions and only supports a subset of XUL functionality.

It simply will not be possible to implement some existing popular
Add-ons in the new Firefox even if the author was inclined to
spend the effort to write a new version of their Add-on.

Simon,

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

j***@yahoo.co.uk

2017-02-27 08:56:55 UTC

I'm clueless. What is happening to Firefox?

Support for XUL based extensions is being removed from Firefox.
The replacement functionality is incompatible with existing XUL
extensions and only supports a subset of XUL functionality.
It simply will not be possible to implement some existing popular
Add-ons in the new Firefox even if the author was inclined to
spend the effort to write a new version of their Add-on.
Simon,
--
Microsoft: Bringing you 1980s technology to a 21st century world

OK, but whether that is a good thing or a bad
thing rather depends on what folk want from a
browser. Is a browser a device independent
execution environment (a modern descendent
of UCSD Pascal and/or ANDF and a whole lot
more), with all the 'fun' (CVEs etc) which
that implies? This has been an increasingly
important (but often ignored) question as
more and more people understandably use
various flavours of script blocker.

Or is a browser sometimes just a limited (and
hopefully more robust) device independent
presentation environment, a modern replacement
for VT100 character graphics and ReGIS and a
little bit more? That need still exists, some
use cases were discussed a few weeks ago here.

I still use Firefox at the moment but it does
appear to be on a slippery slope away from
relevance.

The idea that a self contained PDP11 emulator
can run inside a browser is impressive, in
some strange kind of way. At least one of
those was around in 2011. Is that what browsers
should really be about?

Simple is often a good starting point for secure
(for various meanings of secure).

Dirk Munk

2017-02-27 10:13:14 UTC

I'm clueless. What is happening to Firefox?

Support for XUL based extensions is being removed from Firefox.
The replacement functionality is incompatible with existing XUL
extensions and only supports a subset of XUL functionality.
It simply will not be possible to implement some existing popular
Add-ons in the new Firefox even if the author was inclined to
spend the effort to write a new version of their Add-on.
Simon,

Binary extensions will indeed be removed from Firefox *and* Seamonkey.
Both browsers are very closely related.

Binary extensions are already impossible with the 64 bit versions of
these browsers, with the exception of Flash and some similar Microsoft
extension (forgot the name).

The Java extension for instance doesn't exist for the 64 bit version of
these two browsers.

j***@yahoo.co.uk

2017-02-27 12:35:17 UTC

I'm clueless. What is happening to Firefox?

Support for XUL based extensions is being removed from Firefox.
The replacement functionality is incompatible with existing XUL
extensions and only supports a subset of XUL functionality.
It simply will not be possible to implement some existing popular
Add-ons in the new Firefox even if the author was inclined to
spend the effort to write a new version of their Add-on.
Simon,

Binary extensions will indeed be removed from Firefox *and* Seamonkey.
Both browsers are very closely related.
Binary extensions are already impossible with the 64 bit versions of
these browsers, with the exception of Flash and some similar Microsoft
extension (forgot the name).
The Java extension for instance doesn't exist for the 64 bit version of
these two browsers.

And the lack of a Java extension in a browser in 2017 and
beyond is a bad thing, or is a good thing, or maybe depends
on the circumstances? Is it the *idea* of an interesting
extension that's a good thing? Does the reality match up?

I quite like the *concept* of add-ons and extensions. I'm
*a lot* less keen on many of the implementations I've seen.

Further reading (Mozilla's point of view, with developer
comments):
https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/

Dirk Munk

2017-02-27 13:08:04 UTC

Post by j***@yahoo.co.uk

I'm clueless. What is happening to Firefox?

Support for XUL based extensions is being removed from Firefox.
The replacement functionality is incompatible with existing XUL
extensions and only supports a subset of XUL functionality.
It simply will not be possible to implement some existing popular
Add-ons in the new Firefox even if the author was inclined to
spend the effort to write a new version of their Add-on.
Simon,

Binary extensions will indeed be removed from Firefox *and* Seamonkey.
Both browsers are very closely related.
Binary extensions are already impossible with the 64 bit versions of
these browsers, with the exception of Flash and some similar Microsoft
extension (forgot the name).
The Java extension for instance doesn't exist for the 64 bit version of
these two browsers.

And the lack of a Java extension in a browser in 2017 and
beyond is a bad thing, or is a good thing, or maybe depends
on the circumstances? Is it the *idea* of an interesting
extension that's a good thing? Does the reality match up?
I quite like the *concept* of add-ons and extensions. I'm
*a lot* less keen on many of the implementations I've seen.
Further reading (Mozilla's point of view, with developer
https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/

With regard to Java, Oracle itself isn't supporting Java applets any
more, and deprecated their use over a year ago. You should use Web Start
instead.

You can still use and program add-ons, but not *binary* extensions.

Simon Clubley

2017-02-27 13:31:40 UTC

Post by j***@yahoo.co.uk
And the lack of a Java extension in a browser in 2017 and
beyond is a bad thing, or is a good thing, or maybe depends
on the circumstances? Is it the *idea* of an interesting
extension that's a good thing? Does the reality match up?
I quite like the *concept* of add-ons and extensions. I'm
*a lot* less keen on many of the implementations I've seen.

I hope you are not confusing the binary plugins with all the
additional functionality which the Firefox addons give you.

Post by j***@yahoo.co.uk
Further reading (Mozilla's point of view, with developer
https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/

With regard to Java, Oracle itself isn't supporting Java applets any
more, and deprecated their use over a year ago. You should use Web Start
instead.
You can still use and program add-ons, but not *binary* extensions.

No, you will not be able to write Firefox addons any longer to
the level of functionality which you have been able to do in
the past and in the process _all_ the existing XUL based
extensions will no longer work as-is and many will simply not
be implementable in the new extension infrastructure.

Please READ the article at the above link _BEFORE_ replying and
_PLEASE_ the comments for that article if you are still in any doubt.

And people, please stop confusing binary plugins with Firefox
extension addons. They are two very different things.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Arne Vajhøj

2017-02-27 19:24:27 UTC

Post by Dirk Munk
With regard to Java, Oracle itself isn't supporting Java applets any
more, and deprecated their use over a year ago. You should use Web Start
instead.

Oracle announced in January 2016 that Java applets will be deprecated
in Java 9.

Java 9 is expected to be released July 2017.

It will still work until it get removed in a future version. Java 10
in 2019-2020 or Java 11 in 2021-2023 or whatever.

But browsers will have removed support for it long before that.

And It has been relative useless for several years due to a
gazillion "do you really want to run this?" questions.

Arne

Simon Clubley

2017-02-27 13:19:56 UTC

Post by Simon Clubley
Support for XUL based extensions is being removed from Firefox.
The replacement functionality is incompatible with existing XUL
extensions and only supports a subset of XUL functionality.
It simply will not be possible to implement some existing popular
Add-ons in the new Firefox even if the author was inclined to
spend the effort to write a new version of their Add-on.

Binary extensions will indeed be removed from Firefox *and* Seamonkey.
Both browsers are very closely related.

I said _nothing_ about binary plugins but only talked about XUL extensions.

Post by Dirk Munk
Binary extensions are already impossible with the 64 bit versions of
these browsers, with the exception of Flash and some similar Microsoft
extension (forgot the name).
The Java extension for instance doesn't exist for the 64 bit version of
these two browsers.

These plugins are absolutely nothing to do with XUL extensions.

What Mozilla are doing is to make all the XUL extensions (for example,
NoScript, DownThemAll, Classic Theme Restorer, any XUL based versions
of the Ad blockers, etc) all unusable in Firefox after the end of this
year.

Some extensions (ie: NoScript) will be able to continue in a re-written
form in next year's version of Firefox, but many others, such as Classic
Theme Restorer, simply cannot be implemented in the new extension
framework (due to lack of functionality) even if the authors were
inclined to spend their time rewriting their extensions.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Phillip Helbig (undress to reply)

2017-02-27 18:54:12 UTC

Post by Simon Clubley
Support for XUL based extensions is being removed from Firefox.

Why?

Post by Simon Clubley
The replacement functionality is incompatible with existing XUL
extensions and only supports a subset of XUL functionality.
It simply will not be possible to implement some existing popular
Add-ons in the new Firefox even if the author was inclined to
spend the effort to write a new version of their Add-on.

Does this affect Live-Click?

Stephen Hoffman

2017-02-27 22:55:41 UTC

Post by Simon Clubley
Support for XUL based extensions is being removed from Firefox.

Why?

Interestingly, for reasons similar to why the containers being
discussed in various threads increasingly involve implementations with
better protection — and why OpenVMS would need work around isolating
apps, for that matter — because there's insufficient isolation between
the pieces and parts, and too many ways for the contents of the plugins
to do things not in the best interests of the users. Sandboxes and
related pieces, automatic startup handling, mechanisms to prevent apps
from accessing components they shouldn't, digital signatures and
provisioning, etc. We are operating in much more hostile times, and
are increasingly dealing with even legitimate software that is found
vulnerable and with consequences ranging from denials of service to
remote command execution, and when the security breaches and the
exposures escalate far more quickly and far more widely. We're way
past when ACLs and identifiers and unencrypted data and unsandboxed and
unrestricted access is viable...

https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

--
Pure Personal Opinion | HoffmanLabs LLC

Simon Clubley

2017-02-28 08:28:25 UTC

Post by Simon Clubley
Support for XUL based extensions is being removed from Firefox.

Why?

One of the claims is that XUL is incompatible with the multi-process
model that Firefox is moving to. Unfortunately, if that were the only
reason, then Mozilla would have at least made sure that the replacement
framework had all the functionality of the XUL framework before ripping
out XUL.

The real reason is that the current Firefox developers only care about
making Firefox a clone of Chrome and don't care about the existing
Firefox power users who take full advantage of what the Firefox
ecosystem currently offers.

It's basically the same kind of thinking that gave us Gnome 3 as
a replacement for Gnome 2.

Does this affect Live-Click?

If this is the addon you are talking about:

http://projects.protej.com/liveclick/comments/liveclick_150/

then the following quote from that page will be of interest:

|Please Note: Due to changes coming soon to Firefox, LiveClick may not
|be compatible beyond the next Firefox ESR (currently Fx45).

This quote ties in with the fact that the next ESR version will be
the last one with XUL extension support and will be supported for
several months after the mainstream Firefox branch has dropped XUL
support.

Your only chance is that the replacement extension framework offers
the functionality that your addon author needs and that they are
motivated to rewrite their addon to use it.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Richard Maher

2017-02-27 13:10:39 UTC

I am actually seriously considering Seamonkey (or Pale Moon) as one
of my options when Firefox becomes unusable at the end of the year
(and when Classic Theme Restorer (which provides a usable Firefox UI)
will also stop working).
By this time next year, there's going to be major churn in the
browser market thanks to Mozilla's stupidity. Who knows, maybe
a new portable web browser might even come out of it and maybe
it might be portable to VMS. :-)
As for current browser options, I have in the past suggested maybe
porting Dillo to VMS, but it has no Javascript support and these
days even the web server interface on simple devices tends to require
Javascript.
Simon.

Why don't you 'seriously consider' boot to geko B2G and the billions
wasted on FirefoxOS which may or may not appear as some crappy TV OS.

When will all you wankers stop wasting time on the VMS-client mirage???

Stephen Hoffman

2017-02-27 17:05:03 UTC

By this time next year, there's going to be major churn in the browser
market thanks to Mozilla's stupidity. Who knows, maybe a new portable
web browser might even come out of it and maybe it might be portable to
VMS. :-)

Mozilla is updating their design for better security and reliability,
and removing bits and pieces that tend to cause crashes and
vulnerabilities. The Tor Browser Bundle (TBB) is a very big target
for attacks, for instance.

Over on OpenVMS, I'd expect (hope) to see giblets added akin to cURL
and HTTPie and suchlike, integrated Apache, and some related and common
dependencies such as libsodium, maybe SQLite and PostgreSQL. At most.
Bits and pieces that a server would need for REST and for secure
network communications. Not a web browser much past Lynx. Yes, it'd
be nice to have a readily-updated WebKit browser or such. But "OpenVMS
is for servers", as has been the refrain.

--
Pure Personal Opinion | HoffmanLabs LLC

Simon Clubley

2017-02-28 08:17:31 UTC

Unfortunately Stephen, given the lack of functionality in the replacement
framework, that's kind of like saying we will fix Windows security issues
by making everyone go back to MS-DOS.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Henry Crun

2017-02-28 11:54:13 UTC

Unfortunately Stephen, given the lack of functionality in the replacement
framework, that's kind of like saying we will fix Windows security issues
by making everyone go back to MS-DOS.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes! YES!!

Post by Simon Clubley
Simon.

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691

Stephen Hoffman

2017-02-28 14:28:32 UTC

Unfortunately Stephen, given the lack of functionality in the
replacement framework, that's kind of like saying we will fix Windows
security issues by making everyone go back to MS-DOS.

OpenVMS needs some work before it becomes more easily feasible to port
various open-source to the platform, and the open source communities
are presently moving faster than the OpenVMS community can port.
Increasingly faster, from what I've seen of it in recent years,
including the need to push out security patches and to integrate
remediation efforts into the platforms and tools. But I digress.

A different comparison than MS-DOS would be continuing to allow access
to problematic and insecure frameworks, and the associated uproar that
arose around Windows Vista; when Microsoft got rather more serious
about security and stability. (Yes, they still have issues. But
having been looking at the lengths and complexities of the exploit
chains now in use, Windows security is far better than it used to be.
But they're still one of the biggest targets this side of Android and
iOS, so the folks in Redmond will continue to have to work on security.)

This is the same sort of consternation that'll arise within the OpenVMS
community if (when?) VSI decides to move to more modern and more
resistant-to-brute-forcing cryptographic password hashes and to a
modern LDAP and Kerberos-based login and deprecate Purdy and the SYSUAF
mess, and thus disrupt compatibility for apps that make direct access
to the effected constructs, too.

As for alternative browsers? Edge reportedly does quite well these
days, not that I've used Microsoft Windows in some years. Or maybe
there are enough updates to OpenVMS to allow somebody ports Chrome?
(They've been working to isolate and secure that browser, too.) Or
switch to macOS and Safari or Brave.

But I don't expect OpenVMS to be a desktop. It was a pain to use
OpenVMS for that a decade ago — and I knew and still know how to do
that — and the delta between what's offered and what's expected by
folks has only increased. Folks not steeped in the command line and
text files and non-MIME-MCS-mail as the user interface, that is.

--
Pure Personal Opinion | HoffmanLabs LLC

Craig A. Berry

2017-02-28 15:45:21 UTC

Post by Stephen Hoffman
As for alternative browsers? Edge reportedly does quite well these
days, not that I've used Microsoft Windows in some years.

That was true until yesterday:

<https://arstechnica.com/security/2017/02/high-severity-vulnerability-in-edgeie-is-third-unpatched-msft-bug-this-month/>

Maybe will be again tomorrow or the next day. As you said, things move fast these days.

Stephen Hoffman

2017-02-28 16:40:08 UTC