[Info-vax] Vax Station 4000 VLC

[Stephen Hoffman]

On 2018-12-25 19:09:49 +0000, Scott Dorsey said:

> Dave Froble  <davef at tsoft-inc.com> wrote:
>> 
>> Ok, going aside for a moment, the biggest problem with WEENDOZE, from 
>> my perspective, is it's continual changing.  I understand that 
>> Microsoft  wants to sell OS licenses, and continuing changes is a 
>> method to do
>> that.  But I'm rather upset when I must use WEENDOZE 7, and I wiped the 
>>  disk on which I had installed WEENDOZE 10 because I REALLY didn't like 
>>  it.  I'm Ok with WEENDOZE XP, but it's no longer supported, and 
>> doesn't  have drivers for newer HW.  For me, there is no good options 
>> with WEENDOZE.
> 
> People at big sites don't administer Windows machines.  They administer 
> active directory which pushes policies down to Windows machines.  This 
> allows most of the administrative work to be done without actually 
> being on the computer.
> 
> In the Linux world, similar functionality is provided by remote 
> administration tools like puppet and chef.
> 
> People at small sites administer Windows machines directly, using a 
> gui, and most of them administer Linux machines the same way, again 
> using a gui.
> 
> But remote administration is standard in the industry and if you can't 
> be compatible with tools like chef and puppet you have a big problem 
> getting adoption.

Ayup.  The fewer times I have to deal specifically with a specific 
server, the better.  OpenVMS as presently constituted is the 
near-antithesis of this lights-out hands-off preference.  Hands-on, 
high-touch, manually-edited and tweaked, and with no non-bespoke means 
to initially load a server and no means to automatically acquire a 
software load and problematic network access.  No means to replicate 
app and server configurations, either as a copy or as a template.  No 
profiles for quotas and background server processes and no provisioning 
for entitled access and the rest.  Which means restoring whole-disk 
backups and disk imaging and related, and manual tweaks and edits, and 
all of which will run afoul of update frequencies as apps get changed.  
Sure.  Yes.  Cloning disks is good enough.  For now.  Building whole 
tool chains is the usual answer provided here—write everything, use EDT 
because that's the choice, tweak MODPARAMS.DAT, etc—though that 
approach doesn't scale and doesn't automate, and it's a whole lot more 
work and a whole lot more cost than using the existing tools for Linux 
and Windows.  For existing sites, we'll pay these costs.  Or we'll have 
to port.  For new sites?  The OpenVMS approach won't be nearly as 
interesting.  And the cherry at the top of this whole stupid sundae are 
details such as the effort involved in changing the host name.

As for apps as David is discussing, the HTML and JavaScript and WebASM 
HTTPS path for access from browser-based app clients is gets updated 
rather less.  Though that too is getting updated.  And there are 
compatibility issues across browsers.  This just as there are issues 
across different bespoke clients across different client operating 
system versions; whether across Microsoft Windows 10 and its updates, 
across Apple macOS and iOS, definitely across Android/AOSP, Linux and 
BSD and seL4 regular and embedded distros, and whatever other sorts of 
client operating systems might be interesting.

As for software updates, that's the treadmill we're all on.  There'll 
be client app updates and changes necessary.  Whether it's Microsoft 
Windows 10 and its updates, or Apple and its iOS and macOS updates, or 
SSL/TLS patches and updates, or different browsers and updates, or 
other issues.  Or across a whole different IP stack, as in the case of 
VSI.  Sitting on the same client app and design for twenty or thirty 
years just isn't going to happen.  Increasingly also for the server, 
too.

This all feeds back into how utterly anachronistic the current 
requirements around installing an app and configuring OpenVMS for that 
layered product and for that app is, too.  Whether for the 
administrator, or around the options (not) available for developers.


>> Back to VMS, I'd like some functionality to be presented in a GUI.
>> Looking at the disks, DIRECTORY, gives a better "picture" in a GUI.
>> Managing VMS using various GUI tools would be very nice to have.
> 
> Everybody today wants a file browser.  I hate file browsers, but they 
> have become a standard feature for users as well as for administrators. 
>  I don't think of the file browser as an administration tool... it's 
> part of the user UI.  And yes, in the 21st century it's something 
> everyone expects.

OpenVMS offers FileView for that.  FileView is part of DECwindows.  A 
part that most OpenVMS folks and even those using DECwindows probably 
don't use.  Or don't know about.

The command line is of interest to a subset of the developers and to a 
subset of the system administration folks, and—outside of debug and 
test—usually only then when something goes sideways.

And it'd be preferable if whatever went sideways uploaded the carcass 
via telemetry, and reloaded and restarted the guest.

>> So, what to do?  Put effort into DECwindows?  Or another option?  
>> Everything using a browser?  Don't really like that.  Use workstations, 
>>  WEENDOZE or other, with apps on the workstation to provide the GUI  
>> environment?
> 
> You need to be able to do remote administration, either using a 
> browser, or AD tools, or backends for chef, puppet, and the like.  You 
> also need a GUI for users.  These are two pretty much unrelated things.

Apps for GUI-based management for system administrators and other apps 
for end-users.  Apps that allow development from the GUI, too.  The 
apps are native clients for some environments, and are browser-based 
apps for others.

> Remote access over the web for users is a very cool thing that people 
> like and which is -not- effectively provided by most popular operating 
> systems.

There are folks actively working in this area, and there are some 
interesting ideas here.  For example: https://github.com/maxmcd/webtty

>> It's a tough question.  Having GUI based tools is desirable.  The 
>> details of getting there is the problem.
> 
> Take the existing gui tools and run with them.  But consider them for 
> users more than for administration.  Adapt remote administration tools 
> to work with vms.  This gives you a basic toehold to begin from.

The OpenVMS GUI DECwindows X11 APIs and tools are most charitably 
considered badly outdated, and remote X is just not going to be chosen 
as a GUI for new app work.  Not often enough to matter.

TL;DR: dealing with computers is itself increasingly computerized.  
Client and server.  With OpenVMS, not so much.  VSI has massive work 
ahead, just to keep OpenVMS servers installed where they're already 
installed.  And we're on a treadmill of updates and patches, even for 
the folks that might think or want a permanently-static configuration.  
Not past ~five years or so; past what passes for long-term support now 
at VSI and elsewhere.  The economics around keeping the old configs 
around just isn't there.  Not at the prices enough of us are willing to 
pay.




-- 
Pure Personal Opinion | HoffmanLabs LLC