[Info-vax] VSI strategy for OpenVMS

[chris]

On 09/14/21 16:45, Arne Vajhøj wrote:
> On 9/14/2021 11:26 AM, chris wrote:
>> On 09/14/21 15:17, Arne Vajhøj wrote:
>>> On 9/14/2021 10:04 AM, Bill Gunshannon wrote:
>>>> I doubt that is true, but maybe.  And then you have so  many calling
>>>> for VMS to find a way back into academia.  Without a real desktop and
>>>> a decent browser that is never going to happen (not that it is likely
>>>> to happen anyway).  The user community you will find  in academia today
>>>> is not going to want to work with a CLI or vt-class editors.
>>>
>>> EDT/EVE will probaly not cut it today.
>>>
>>> But VS Code should be fine.
>>>
>>> And they can use that (VMS IDE).
>>>
>>> I don't think the students will have a problem with ssh and
>>> a bit of command line work.
>>>
>>> That is common other platforms as well.
>
>> I'm still using makefiles for all my code, but quite have
>> three or four terminal / shell windows, file mgr and one or two
>> tabbed full screen editor windows open typically. Still
>> coommand line, but the gui provides so much more flexibility
>> and can't imagein going back to edt and vt class terminels,
>> far too restrictive.
>
> A mix of GUI and command line is common.
>
> I do that on Windows and Linux as well.
>
> Mostly JEdit (I do not like VS Code) and command windows.
>
>> One thing that might be useful for vms would be a vnc server
>> to allow remote access. use that a lot here for headless
>> machines and is more than fast enough with modern processors...
>
> Interesting thought.
>
> I assume you want GUI not CLI. CLI should be fine with SSH.
>
> As I remember VNC (been some years) then it duplicates
> the GUI.
>
> Many VMS systems will not have a graphic capable console, so
> nothing to duplicate.
>
> But it does not really need to duplicate. Being original
> GUI would be fine.
>
> A pseudo device connected to the "VNC like server"
> exposing a GUI to the client could work.
>
> I know that it is possible to tunnel X over SSH,
> but I believe that is a complicated exercise in
> todays network.
>
> Start a "VNC like client" and getting a DECWindows
> console could be cool.
>
> I do do still not see the point in running a browser there.
>
> But file manager or a GUI editor.
>
> Not sure how much effort to make DECWindows use a pseudo
> device connected to a TCP server, but it may
> not be so bad.
>
> Arne
>
>

The original vnc was quite slow on the machines of the 1990's,
but orders of magnitude faster processors and networks now make
it very usable and in some tests here, was subjectively just as
fast as an on board low end frame buffers such as the Radeon 2200
or 2250. Doing some work on FreeBSD Sparc a couple of years back,
almost none existent frame buffer support, so looked again at vnc.

The original Xvnc had a built in X server, which means it doesn't
need an X install on the system to run. Some later versions do, but
I chose Xvnc to get round some package issues and it runs very
well. Got as far as an xfce4 desktop and utilities, but failed at
the time with the Firefox build, too many package dependencies and
version number requirements.

In a way, vms deficiencies are similar to the FreeBSD Sparc
issues I found, but can't believe it would be that difficult to
get a vnc server running, which would make it far more useful.
One alternative is the microsoft rdp, but would shudder at that
idea.

In the modern world, comms and methods of access across the network
are key requirements, so vms will need a good chunk of that to be
taken seriously. As for decwindows, that was an X system, so must
have had all the low level X networking suport built in for remote
application display. Yes, other than for tcp/ip support, vms was
quite up to date even 30 years ago...

Chris


>
>