• Desirable features for VMS

    From Simon Clubley@21:1/5 to Dave Froble on Thu Jan 25 13:21:38 2024
    On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
    On 1/24/2024 8:13 AM, Simon Clubley wrote:
    On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:

    What is really rude is talking about Linux on c.o.v ...


    Unless you consider VMS to be perfect and not in need of any improvement,
    other operating systems offer some good ideas that it would be nice to
    see in VMS, especially around security and internal isolation in general.


    Then discuss the ideas and concepts ...


    OK.

    A random sample of things from Linux/Unix I would like to see in VMS:

    Mandatory Access Controls (my preference) or jails (Stephen's preference).

    A shell with decent modern functionality such as:

    Proper command history retention and merging from multiple sessions
    Easy searching of command history
    Tab completion
    Editing long command lines
    Globbing

    Proper package management and management of updates.

    Loadable and unloadable kernel modules, with device driver/filesystem/etc functionality available from within these modules.

    ASLR and KASLR support.

    Proper timezone management. (Everything is always UTC based, and your
    timezone is merely a local session property with no effect on the
    on-disk timestamps).

    The last one is policy-based, not technical:

    A vendor that has proper security reporting mechanisms.

    Does anyone have any others to add to the list ?

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to clubley@remove_me.eisner.decus.org- on Thu Jan 25 15:31:55 2024
    In article <uotn92$2ais1$1@dont-email.me>,
    Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
    On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
    On 1/24/2024 8:13 AM, Simon Clubley wrote:
    On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:

    What is really rude is talking about Linux on c.o.v ...


    Unless you consider VMS to be perfect and not in need of any improvement, >>> other operating systems offer some good ideas that it would be nice to
    see in VMS, especially around security and internal isolation in general. >>>

    Then discuss the ideas and concepts ...


    OK.

    A random sample of things from Linux/Unix I would like to see in VMS:

    Mandatory Access Controls (my preference) or jails (Stephen's preference).

    A shell with decent modern functionality such as:

    Proper command history retention and merging from multiple sessions
    Easy searching of command history
    Tab completion
    Editing long command lines
    Globbing

    Proper package management and management of updates.

    Loadable and unloadable kernel modules, with device driver/filesystem/etc >functionality available from within these modules.

    ASLR and KASLR support.

    Proper timezone management. (Everything is always UTC based, and your >timezone is merely a local session property with no effect on the
    on-disk timestamps).

    The last one is policy-based, not technical:

    A vendor that has proper security reporting mechanisms.

    Does anyone have any others to add to the list ?

    Some sort of userspace pluggable filesystem support.
    FUSE, 9P + a mount driver, whatever.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Simon Clubley on Thu Jan 25 15:20:09 2024
    On 1/25/2024 8:21 AM, Simon Clubley wrote:
    A random sample of things from Linux/Unix I would like to see in VMS:

    Mandatory Access Controls (my preference) or jails (Stephen's preference).

    The market want containers.

    I suspect that means Hoff jails with a marketing label of "container"
    instead of "jail".


    A shell with decent modern functionality such as:

    Proper command history retention and merging from multiple sessions
    Easy searching of command history
    Tab completion
    Editing long command lines
    Globbing

    +better control structures
    +better data types

    But I doubt it makes sense business wise.

    VMS got:
    * DCL for backwards compatibility
    * GNV bash for *nix compatibility
    * Python and Perl for more programmatic scripting

    Even though DCL2 or XDCL would be nice then I don't think it
    will increase VMS sale.

    Proper package management

    Traditional Linux package management at the OS level would
    be the wrong path. The result is a mess.

    The right approach is package management at the application level.

    maven, nuget, pypi, npm, composer etc. not yum, dnf etc..

    For managing the truly OS stuff relative little is needed. PCSI2
    or XPCSI.

    and management of updates.

    An option for more automated updates of VMS would be nice.

    Loadable and unloadable kernel modules, with device driver/filesystem/etc functionality available from within these modules.

    Nice.

    But again I doubt it will increase VMS sale.

    ASLR and KASLR support.

    That would probably come as part of ongoing security enhancements
    at some point in time.

    Proper timezone management. (Everything is always UTC based, and your timezone is merely a local session property with no effect on the
    on-disk timestamps).

    Nice but tricky to implement without breaking stuff.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Dan Cross on Thu Jan 25 15:24:04 2024
    On 1/25/2024 10:31 AM, Dan Cross wrote:
    Some sort of userspace pluggable filesystem support.
    FUSE, 9P + a mount driver, whatever.

    That would also be nice.

    But how many potential VMS users will consider "userspace
    pluggable filesystem support" important in decision process?

    I suspect: practically none.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From kludge@panix.com@21:1/5 to arne@vajhoej.dk on Thu Jan 25 22:28:37 2024
    =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
    On 1/25/2024 10:31 AM, Dan Cross wrote:
    Some sort of userspace pluggable filesystem support.
    FUSE, 9P + a mount driver, whatever.

    That would also be nice.

    But how many potential VMS users will consider "userspace
    pluggable filesystem support" important in decision process?

    On production systems, I don't think it's all that useful for users to
    be able to mount and dismount filesystems, or to install their own new filesystem drivers of their own design.

    I -do- think that there is some security benefit in having the filesystem support in user space, but I also think the performance penalty is usually
    not worth it.

    What -would- be useful would be the ability to plug new filesystems easily
    into the kernel, along with ntfs and various fat drivers supplied as needed.
    Do I need to be able to do this dynamically from user space? Not really. --scott

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Hoffman@21:1/5 to All on Thu Jan 25 18:59:22 2024
    On 2024-01-25 20:20:09 +0000, Arne Vajhøj said:

    On 1/25/2024 8:21 AM, Simon Clubley wrote:
    A random sample of things from Linux/Unix I would like to see in VMS:

    Mandatory Access Controls (my preference) or jails (Stephen's preference).

    The market want containers.

    I suspect that means Hoff jails with a marketing label of "container"
    instead of "jail".


    Jails / sandboxes can be used as a component of containers, but—as I've commented elsewhere—containers are far too reminiscent of licensing arbitrage. Which can somewhat dampen vendor enthusiasm.

    Getting a working jail / sandbox on OpenVMS is no small project, both
    for VSI, and for the app developers adopting jails / sandboxes.

    Still involved but smaller in scope would be some variation of the
    pledge(2) mechanism. An aeon or two ago, I'd discussed that and the
    related trade-offs with a then-VSI developer. Deets: https://man.openbsd.org/pledge.2

    What OpenVMS traditionally implements as system-wide stuff like
    usernames doesn't map all that well.

    Jails / sandboxes can be built upon some of the parts of mandatory
    access controls, but I ~never want to have to use a system configured
    for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.



    A shell with decent modern functionality such as:

    Proper command history retention and merging from multiple sessions
    Easy searching of command history
    Tab completion
    Editing long command lines
    Globbing

    +better control structures
    +better data types

    But I doubt it makes sense business wise.

    VMS got:
    * DCL for backwards compatibility
    * GNV bash for *nix compatibility
    * Python and Perl for more programmatic scripting

    Even though DCL2 or XDCL would be nice then I don't think it will
    increase VMS sale.


    Likely not perceived as an increase sales. Though as happened with DII
    COE, sometimes major customers will establish requirements here.

    There are a lot of things in this same general category too, which is
    the other side of facilitating and encouraging new adoptions.


    Proper package management

    Traditional Linux package management at the OS level would
    be the wrong path. The result is a mess.


    OpenVMS packaging and installation is already a spectacular mess, but
    then I'm in a charitable mood today.

    And the packaging ties into installation, upgrades, removal, app
    isolation, startup, shutdown, code-signing, and jails / sandboxes.
    Among other areas.

    And any new scheme will have to contend with apps arriving via cargo,
    nix, pip, cpan, or another installation system, as well.


    The right approach is package management at the application level.

    maven, nuget, pypi, npm, composer etc. not yum, dnf etc..

    For managing the truly OS stuff relative little is needed. PCSI2 or XPCSI.

    and management of updates.

    An option for more automated updates of VMS would be nice.


    It'll be nice to implement some of the many features that have become
    common in the years since the existing 1988-era designs, yes.



    Loadable and unloadable kernel modules, with device
    driver/filesystem/etc functionality available from within these modules.

    Nice.

    But again I doubt it will increase VMS sale.

    ASLR and KASLR support.

    That would probably come as part of ongoing security enhancements at
    some point in time.


    Stack canaries might be easier.


    Proper timezone management. (Everything is always UTC based, and your
    timezone is merely a local session property with no effect on the
    on-disk timestamps).

    Nice but tricky to implement without breaking stuff.


    That's been the compatibility hobgoblin ~forever. The quadword format
    is embedded all over the place. For some sites, switching to UTC as the
    base works fine.

    I've run OpenVMS servers set to UTC at various installations, too,
    ("Oh, that? Yeah. The server is in England." usually suffices.)

    Downside is that saved dates can be off by a day pending a rewrite,
    which can absolutely be a non-starter for some sites.



    PS: The discussion of ASLR/KASLR and buffer-overflow protections
    reminds me of this XPM exploit (whether it also hits XBM?) recently
    discovered: https://jfrog.com/blog/xorg-libx11-vulns-cve-2023-43786-cve-2023-43787-part-two/



    --
    Pure Personal Opinion | HoffmanLabs LLC

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Stephen Hoffman on Thu Jan 25 19:18:38 2024
    On 1/25/2024 6:59 PM, Stephen Hoffman wrote:
    On 2024-01-25 20:20:09 +0000, Arne Vajhøj said:
    On 1/25/2024 8:21 AM, Simon Clubley wrote:
    Mandatory Access Controls (my preference) or jails (Stephen's
    preference).

    The market want containers.

    I suspect that means Hoff jails with a marketing label of "container"
    instead of "jail".

    Jails / sandboxes can be used as a component of containers, but—as I've commented elsewhere—containers are far too reminiscent of licensing arbitrage. Which can somewhat dampen vendor enthusiasm.

    "containers" is what sells.

    Jails / sandboxes can be built upon some of the parts of mandatory
    access controls, but I ~never want to have to use a system configured
    for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.

    SEVMS-style MAC was targeting the 1980's requirements.

    A shell with decent modern functionality such as:

        Proper command history retention and merging from multiple sessions >>>     Easy searching of command history
        Tab completion
        Editing long command lines
        Globbing

    +better control structures
    +better data types

    But I doubt it makes sense business wise.

    VMS got:
    * DCL for backwards compatibility
    * GNV bash for *nix compatibility
    * Python and Perl for more programmatic scripting

    Even though DCL2 or XDCL would be nice then I don't think it will
    increase VMS sale.

    Likely not perceived as an increase sales. Though as happened with DII
    COE, sometimes major customers will establish requirements here.

    There are a lot of things in this same general category too, which is
    the other side of facilitating and encouraging new adoptions.

    Very few people work at the command prompt today. I doubt "shell power"
    will become a requirement.

    ASLR and KASLR support.

    That would probably come as part of ongoing security enhancements at
    some point in time.

    Stack canaries might be easier.

    I believe LLVM support it, so ...

    Proper timezone management. (Everything is always UTC based, and your
    timezone is merely a local session property with no effect on the
    on-disk timestamps).

    Nice but tricky to implement without breaking stuff.

    That's been the compatibility hobgoblin ~forever.  The quadword format
    is embedded all over the place. For some sites, switching to UTC as the
    base works fine.

    I've run OpenVMS servers set to UTC at various installations, too, ("Oh, that? Yeah. The server is in England." usually suffices.)

    Downside is that saved dates can be off by a day pending a rewrite,
    which can absolutely be a non-starter for some sites.

    For backwards compatibility the old saying applies:

    "I'll be damned if I do, I'll be damned if I don't"

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Jan-Erik_S=C3=B6derholm?=@21:1/5 to All on Fri Jan 26 12:50:03 2024
    Den 2024-01-26 kl. 12:45, skrev Chris Townley:
    On 26/01/2024 00:18, Arne Vajhøj wrote:

    Very few people work at the command prompt today. I doubt "shell power"
    will become a requirement.


    Not sure that is true. MS Servers don't have a GUI, Most Linux servers are installed without a GUI

    GUI is for userspace


    I think that, what Arne ment, was that very few users are working at the OS level at all today. Most are application-users and couldn't care les about
    how the base system is managed.

    Personally, I see little value in/payback from investments in DCL.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to All on Fri Jan 26 11:45:12 2024
    On 26/01/2024 00:18, Arne Vajhøj wrote:

    Very few people work at the command prompt today. I doubt "shell power"
    will become a requirement.


    Not sure that is true. MS Servers don't have a GUI, Most Linux servers
    are installed without a GUI

    GUI is for userspace

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Chris Townley on Fri Jan 26 08:07:21 2024
    On 1/26/2024 6:45 AM, Chris Townley wrote:
    On 26/01/2024 00:18, Arne Vajhøj wrote:
    Very few people work at the command prompt today. I doubt "shell power"
    will become a requirement.

    Not sure that is true. MS Servers don't have a GUI, Most Linux servers
    are installed without a GUI

    System managers (what the rest of the world tend to call sys admins)
    and developers frequently use command prompt and scripting.

    But the end users do not. They may rely on something on the VMS
    system, but they do not work with DCL and the vast majority
    of them do not even know what DCL is. Heck - some of them may
    never have seen a command prompt on any OS.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to arne@vajhoej.dk on Fri Jan 26 13:16:06 2024
    On 2024-01-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/25/2024 6:59 PM, Stephen Hoffman wrote:
    Jails / sandboxes can be built upon some of the parts of mandatory
    access controls, but I ~never want to have to use a system configured
    for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.

    SEVMS-style MAC was targeting the 1980's requirements.


    When I talk about MAC, I am talking about SELinux style MAC, not SEVMS.

    I've read the public SEVMS documentation and it is way too limiting for
    today's world. SELinux fits right in however. One of the things I like
    about SELinux is just how fine-grained and how wide-ranging the control
    is. For example, you can allow a service to make outgoing TCP connections
    on some ports and deny it access to everything other TCP port.

    That way, even if the service gets compromised, the shellcode _still_
    can't make an outgoing connection on any TCP port the service has been
    denied access to.

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Simon Clubley on Fri Jan 26 09:42:13 2024
    On 1/26/2024 8:16 AM, Simon Clubley wrote:
    On 2024-01-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/25/2024 6:59 PM, Stephen Hoffman wrote:
    Jails / sandboxes can be built upon some of the parts of mandatory
    access controls, but I ~never want to have to use a system configured
    for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.

    SEVMS-style MAC was targeting the 1980's requirements.

    When I talk about MAC, I am talking about SELinux style MAC, not SEVMS.

    I've read the public SEVMS documentation and it is way too limiting for today's world. SELinux fits right in however. One of the things I like
    about SELinux is just how fine-grained and how wide-ranging the control
    is. For example, you can allow a service to make outgoing TCP connections
    on some ports and deny it access to everything other TCP port.

    That way, even if the service gets compromised, the shellcode _still_
    can't make an outgoing connection on any TCP port the service has been
    denied access to.

    Is that even MAC? Elsewhere it is called a software firewall.

    It is certainly a well known feature. Windows also got it.

    In theory it does enhance security. With no other mitigations
    in place it can prevent some problems. Like Log4Shell.

    But I don't know about how much impact it has in real life.
    Secure servers are already behind a firewall that by default
    blocks, so outgoing traffic is blocked. And users of
    not-so-secure PC's tend to open ports when asked without
    thinking.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Dorsey@21:1/5 to news@cct-net.co.uk on Fri Jan 26 15:48:22 2024
    Chris Townley <news@cct-net.co.uk> wrote:
    On 26/01/2024 00:18, Arne Vajhøj wrote:

    Very few people work at the command prompt today. I doubt "shell power"
    will become a requirement.

    Not sure that is true. MS Servers don't have a GUI, Most Linux servers
    are installed without a GUI

    GUI is for userspace

    Unfortunately it is true. I have met a lot of Microsoft-Trained Windows Experts who have no real understanding of powershell and who either just
    type in commands that they have been given or use a gui tool that sends powershell commands to the remote machine.

    However, I do not think this state of affairs is good. In fact I think it
    is probably the one thing most likely to destroy our computer infrastructure today. So I think that having better and more powerful shells is very important, but I also think that teaching people to use them is just as important.

    The nice thing about bash is that there are a lot of good training resources out there. When I was learning DCL there were some wonderful grey training manuals too. Times have changed, though.
    --scott

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to Simon Clubley on Fri Jan 26 10:33:20 2024
    On 1/25/2024 8:21 AM, Simon Clubley wrote:
    On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
    On 1/24/2024 8:13 AM, Simon Clubley wrote:
    On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:

    What is really rude is talking about Linux on c.o.v ...


    Unless you consider VMS to be perfect and not in need of any improvement, >>> other operating systems offer some good ideas that it would be nice to
    see in VMS, especially around security and internal isolation in general. >>>

    Then discuss the ideas and concepts ...


    OK.

    I've been reading the posts on this topic for a while. What I think is that any
    such ideas and concepts might need to be divided into two categories, 1) workstation/user interface/development/etc, and 2) production. And so, some comments.

    A random sample of things from Linux/Unix I would like to see in VMS:

    Mandatory Access Controls (my preference) or jails (Stephen's preference).

    A shell with decent modern functionality such as:

    Proper command history retention and merging from multiple sessions
    Easy searching of command history
    Tab completion
    Editing long command lines
    Globbing

    Here is where I have to ask, what is the actual worth of the above, and is it worth doing?

    For any production system, is any of the above helpful? I'd say not helpful. On any production system, normal operations would all be in command files. Never anything that required some person to come into work and start or modify any processes. After all, what happens to production in such an implementation when that person gets run over by a bus?

    Would the above be useful in a workstation/user interface/development and such system? Absolutely. Is VSI in any position to devote resources to such? Absolutely not. Took years for the x86 port, which is still not complete.

    Be a bit reasonable Simon ...


    --
    David Froble Tel: 724-529-0450
    Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
    DFE Ultralights, Inc.
    170 Grimplin Road
    Vanderbilt, PA 15486

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to arne@vajhoej.dk on Fri Jan 26 18:36:17 2024
    On 2024-01-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/26/2024 8:16 AM, Simon Clubley wrote:
    On 2024-01-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/25/2024 6:59 PM, Stephen Hoffman wrote:
    Jails / sandboxes can be built upon some of the parts of mandatory
    access controls, but I ~never want to have to use a system configured
    for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.

    SEVMS-style MAC was targeting the 1980's requirements.

    When I talk about MAC, I am talking about SELinux style MAC, not SEVMS.

    I've read the public SEVMS documentation and it is way too limiting for
    today's world. SELinux fits right in however. One of the things I like
    about SELinux is just how fine-grained and how wide-ranging the control
    is. For example, you can allow a service to make outgoing TCP connections
    on some ports and deny it access to everything other TCP port.

    That way, even if the service gets compromised, the shellcode _still_
    can't make an outgoing connection on any TCP port the service has been
    denied access to.

    Is that even MAC? Elsewhere it is called a software firewall.


    Yes, it absolutely is. It's part of the SELinux policy and has nothing
    to do with the internal firewall that Linux systems also have.

    It's just that SELinux has access to a _wide_ range of objects to control,
    not just the traditional file-based access you may be familiar with from
    older MAC systems, and a TCP port is just another internal object that
    can be controlled by the SELinux policy, including your own extensions
    to that policy.

    It is certainly a well known feature. Windows also got it.

    In theory it does enhance security. With no other mitigations
    in place it can prevent some problems. Like Log4Shell.

    But I don't know about how much impact it has in real life.
    Secure servers are already behind a firewall that by default
    blocks, so outgoing traffic is blocked.


    That's one of the reasons it's part of a MAC policy, standalone from
    any external firewall. The next outgoing connection from the shellcode
    might be to a port on IP address 127.0.0.1 as part of a chained attack
    so that external firewall never sees that connection attempt.

    For anyone unfamiliar with SELinux, I just found this document that gives
    a top-level overview of it. I wish VMS had something like this:

    https://access.redhat.com/solutions/7032454

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Dave Froble on Fri Jan 26 18:41:11 2024
    On 2024-01-26, Dave Froble <davef@tsoft-inc.com> wrote:

    Be a bit reasonable Simon ...


    Mandatory Access Controls or jails can absolutely be a _direct_ part of
    a production environment.

    I also notice you left out all the other things in my list. They can also
    be a direct part of a production environment. :-)

    I am being reasonable, and the list is a very reasonable list for
    production environments.

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to kludge@panix.com on Fri Jan 26 19:42:17 2024
    In article <uounal$fvn$1@panix1.panix.com>, <kludge@panix.com> wrote: >=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
    On 1/25/2024 10:31 AM, Dan Cross wrote:
    Some sort of userspace pluggable filesystem support.
    FUSE, 9P + a mount driver, whatever.

    That would also be nice.

    But how many potential VMS users will consider "userspace
    pluggable filesystem support" important in decision process?

    On production systems, I don't think it's all that useful for users to
    be able to mount and dismount filesystems, or to install their own new >filesystem drivers of their own design.

    Perhaps. I worked on a system where applications were delivered
    to prod as small ext4 filesystems that were accessed read-only
    via iSCSI and mounted into a container with a ramfs overlay for
    temporary files.

    Such arrangements are common at e.g. hyperscalers.

    I -do- think that there is some security benefit in having the filesystem >support in user space, but I also think the performance penalty is usually >not worth it.

    There's a fair amount of prior art here that shows decent
    performance. Plan 9, for example, implemented the window system
    as a file system. For that matter, the graphics device was
    exposed as a filesystem as well, though that was in the kernel.

    What -would- be useful would be the ability to plug new filesystems easily >into the kernel, along with ntfs and various fat drivers supplied as needed. >Do I need to be able to do this dynamically from user space? Not really.

    YMMV. It's been my experience that once you go down the route
    of allowing it, however, you find surprising application areas
    and it's actually very useful.

    Enough to wrangle new customers? No, not likely.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Fri Jan 26 21:38:20 2024
    On Fri, 26 Jan 2024 08:07:21 -0500, Arne Vajhøj wrote:

    ... some [users] may never have seen a command prompt on any OS.

    Might be becoming more common on Windows <https://www.theregister.com/2024/01/12/microsoft_update_for_bitlocker_vuln/>.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to Simon Clubley on Sat Jan 27 00:42:06 2024
    On 1/26/2024 1:41 PM, Simon Clubley wrote:
    On 2024-01-26, Dave Froble <davef@tsoft-inc.com> wrote:

    Be a bit reasonable Simon ...


    Mandatory Access Controls or jails can absolutely be a _direct_ part of
    a production environment.

    Agreed ...

    I also notice you left out all the other things in my list. They can also
    be a direct part of a production environment. :-)

    That's because I was only addressing those ideas that would usually be applicable in a non-production environment.

    I am being reasonable, and the list is a very reasonable list for
    production environments.

    Simon.



    --
    David Froble Tel: 724-529-0450
    Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
    DFE Ultralights, Inc.
    170 Grimplin Road
    Vanderbilt, PA 15486

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Marc Van Dyck on Sun Jan 28 08:32:22 2024
    On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
    Simon Clubley formulated the question :
    Does anyone have any others to add to the list ?

    Yes. Some kind of automatic disaster recovery. That is, if a process,
    or a set of processes, run on a system that crashes, those processes are automatically restarted on another cluster member, transparently, with
    no manual intervention, and continue from the point they were at when
    the system crashed. No transaction lost of any kind, and without having
    to add anything in the code that those processes are running. The
    operating system (or layered product) does all the work transparently.
    Should work with code written 30 years ago, with ACMS applications,
    anything.

    Something like Tandem NonStop lock-step?

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Van Dyck@21:1/5 to All on Sun Jan 28 14:25:51 2024
    Simon Clubley formulated the question :
    On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
    On 1/24/2024 8:13 AM, Simon Clubley wrote:
    On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:

    What is really rude is talking about Linux on c.o.v ...


    Unless you consider VMS to be perfect and not in need of any improvement, >>> other operating systems offer some good ideas that it would be nice to
    see in VMS, especially around security and internal isolation in general. >>>

    Then discuss the ideas and concepts ...


    OK.

    A random sample of things from Linux/Unix I would like to see in VMS:

    Mandatory Access Controls (my preference) or jails (Stephen's preference).

    A shell with decent modern functionality such as:

    Proper command history retention and merging from multiple sessions
    Easy searching of command history
    Tab completion
    Editing long command lines
    Globbing

    Proper package management and management of updates.

    Loadable and unloadable kernel modules, with device driver/filesystem/etc functionality available from within these modules.

    ASLR and KASLR support.

    Proper timezone management. (Everything is always UTC based, and your timezone is merely a local session property with no effect on the
    on-disk timestamps).

    The last one is policy-based, not technical:

    A vendor that has proper security reporting mechanisms.

    Does anyone have any others to add to the list ?

    Simon.

    Yes. Some kind of automatic disaster recovery. That is, if a process,
    or a set of processes, run on a system that crashes, those processes
    are
    automatically restarted on another cluster member, transparently, with
    no manual intervention, and continue from the point they were at when
    the system crashed. No transaction lost of any kind, and without having
    to add anything in the code that those processes are running. The
    operating system (or layered product) does all the work transparently.
    Should work with code written 30 years ago, with ACMS applications,
    anything.

    --
    Marc Van Dyck

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Van Dyck@21:1/5 to All on Sun Jan 28 19:27:44 2024
    Arne Vajhøj wrote on 28/01/2024 :
    On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
    Simon Clubley formulated the question :
    Does anyone have any others to add to the list ?

    Yes. Some kind of automatic disaster recovery. That is, if a process,
    or a set of processes, run on a system that crashes, those processes are
    automatically restarted on another cluster member, transparently, with
    no manual intervention, and continue from the point they were at when
    the system crashed. No transaction lost of any kind, and without having
    to add anything in the code that those processes are running. The
    operating system (or layered product) does all the work transparently.
    Should work with code written 30 years ago, with ACMS applications,
    anything.

    Something like Tandem NonStop lock-step?

    Arne

    Indeed. But not with the 30 years old look...

    --
    Marc Van Dyck

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to All on Sun Jan 28 14:42:29 2024
    On 1/28/2024 8:32 AM, Arne Vajhøj wrote:
    On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
    Simon Clubley formulated the question :
    Does anyone have any others to add to the list ?

    Yes. Some kind of automatic disaster recovery. That is, if a process,
    or a set of processes, run on a system that crashes, those processes are
    automatically restarted on another cluster member, transparently, with
    no manual intervention, and continue from the point they were at when
    the system crashed. No transaction lost of any kind, and without having
    to add anything in the code that those processes are running. The
    operating system (or layered product) does all the work transparently.
    Should work with code written 30 years ago, with ACMS applications,
    anything.

    Something like Tandem NonStop lock-step?

    Arne



    Well, no, not really. What I'd envision would be what I'd call an application monitor, for lack of a better name, that would be able to know what the applications should be doing, to monitor that activity, and to do whatever necessary to continue the activity, should anything happen to that activity. Yeah, non-stop, but not the Tandem design.

    Just a concept, and design and implementation might be "interesting".

    I'd just note that the OSs would be included as applications, so re-starting them from where they were interrupted would be included in the concept. So, yeah, the monitor would be outside/over the OSs. Perhaps something like happens
    with VMs. Except VMs want to move the activity to another system, not recover on the same system.

    --
    David Froble Tel: 724-529-0450
    Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
    DFE Ultralights, Inc.
    170 Grimplin Road
    Vanderbilt, PA 15486

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Van Dyck@21:1/5 to All on Mon Jan 29 16:36:17 2024
    Dave Froble formulated the question :
    On 1/28/2024 8:32 AM, Arne Vajhøj wrote:
    On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
    Simon Clubley formulated the question :
    Does anyone have any others to add to the list ?

    Yes. Some kind of automatic disaster recovery. That is, if a process,
    or a set of processes, run on a system that crashes, those processes are >>> automatically restarted on another cluster member, transparently, with
    no manual intervention, and continue from the point they were at when
    the system crashed. No transaction lost of any kind, and without having
    to add anything in the code that those processes are running. The
    operating system (or layered product) does all the work transparently.
    Should work with code written 30 years ago, with ACMS applications,
    anything.

    Something like Tandem NonStop lock-step?

    Arne



    Well, no, not really. What I'd envision would be what I'd call an application monitor, for lack of a better name, that would be able to know what the applications should be doing, to monitor that activity, and to do whatever necessary to continue the activity, should anything happen to that activity. Yeah, non-stop, but not the Tandem design.

    Just a concept, and design and implementation might be "interesting".

    I'd just note that the OSs would be included as applications, so re-starting them from where they were interrupted would be included in the concept. So, yeah, the monitor would be outside/over the OSs. Perhaps something like happens with VMs. Except VMs want to move the activity to another system, not recover on the same system.

    Whatever the design and implementation, this would be a really useful
    and marketable addition to the OpenVMS cluster concept. Clusters were
    invented 40 years ago to implement horizontal scalability, because
    vertical scalability was impossible, technically or financially. This
    issue has mostly disappeared today, current hardware being able to
    deliver any power we might want. Today's clusters are essentially
    put in place for redundancy or disaster recovery purposes ; the next
    logical step should be to provide this redundancy in a transparent way
    to the system user.

    This should also be, as opposed to simple user niceties, something that
    allows VSi to make money with.

    --
    Marc Van Dyck

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Van Dyck@21:1/5 to Simon Clubley on Mon Jan 29 16:58:41 2024
    Simon Clubley wrote on 25/01/2024 :
    On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
    On 1/24/2024 8:13 AM, Simon Clubley wrote:
    On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:

    What is really rude is talking about Linux on c.o.v ...


    Unless you consider VMS to be perfect and not in need of any improvement, >>> other operating systems offer some good ideas that it would be nice to
    see in VMS, especially around security and internal isolation in general. >>>

    Then discuss the ideas and concepts ...


    OK.

    A random sample of things from Linux/Unix I would like to see in VMS:

    Mandatory Access Controls (my preference) or jails (Stephen's preference).

    A shell with decent modern functionality such as:

    Proper command history retention and merging from multiple sessions
    Easy searching of command history
    Tab completion
    Editing long command lines
    Globbing

    Proper package management and management of updates.

    Loadable and unloadable kernel modules, with device driver/filesystem/etc functionality available from within these modules.

    ASLR and KASLR support.

    Proper timezone management. (Everything is always UTC based, and your timezone is merely a local session property with no effect on the
    on-disk timestamps).

    The last one is policy-based, not technical:

    A vendor that has proper security reporting mechanisms.

    Does anyone have any others to add to the list ?

    Simon.

    One of the slogans that were used to sell OpenVMS is "When downtime is
    not an option". Yes we still need to reboot the system each time we
    install a new operating system or major patch. There should be a way to
    perform those operations without shutting down the service. If this is
    not possible, rolling upgrades across clusters remain an alternative,
    but then we need a way to move a process or a set of processes from one
    cluster member to another without any impact or user visibility.

    --
    Marc Van Dyck

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Hans Bachner on Mon Jan 29 19:00:42 2024
    On 1/29/2024 6:21 PM, Hans Bachner wrote:
    Marc Van Dyck schrieb am 29.01.2024 um 16:36:
    Dave Froble formulated the question :
    I'd just note that the OSs would be included as applications, so
    re-starting them from where they were interrupted would be included
    in the concept.  So, yeah, the monitor would be outside/over the OSs.
    Perhaps something like happens with VMs.  Except VMs want to move the
    activity to another system, not recover on the same system.

    Whatever the design and implementation, this would be a really useful
    and marketable addition to the OpenVMS cluster concept. Clusters were
    invented 40 years ago to implement horizontal scalability, because
    vertical scalability was impossible, technically or financially. This
    issue has mostly disappeared today, current hardware being able to
    deliver any power we might want. Today's clusters are essentially
    put in place for redundancy or disaster recovery purposes ; the next
    logical step should be to provide this redundancy in a transparent way
    to the system user.

    This should also be, as opposed to simple user niceties, something that
    allows VSi to make money with.

    Would OpenVMS Service Control cover your needs?

    <https://vmssoftware.com/products/service-control/>

    Service Control was originally developed by Wolfgang Burger at HP in
    Vienna and later adopted by VSI. As far as I know it is (still) offered
    as a service, not a product - but only VSI can tell.

    This indeed seems like the app<--->VMS equivalent of
    VM<--->ESXi.

    You define an app to be running on one node in the cluster
    and if something happens then the software start the app
    on another node.

    Like you define a VM to be running on one ESXi server in the
    cluster and if something happens then VMWare spin up
    the VM on another ESXi server.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hans Bachner@21:1/5 to Marc Van Dyck on Tue Jan 30 00:21:56 2024
    Marc Van Dyck schrieb am 29.01.2024 um 16:36:
    Dave Froble formulated the question :
    On 1/28/2024 8:32 AM, Arne Vajhøj wrote:
    On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
    Simon Clubley formulated the question :
    Does anyone have any others to add to the list ?

    Yes. Some kind of automatic disaster recovery. That is, if a process,
    or a set of processes, run on a system that crashes, those processes
    are
    automatically restarted on another cluster member, transparently, with >>>> no manual intervention, and continue from the point they were at when
    the system crashed. No transaction lost of any kind, and without having >>>> to add anything in the code that those processes are running. The
    operating system (or layered product) does all the work transparently. >>>> Should work with code written 30 years ago, with ACMS applications,
    anything.

    Something like Tandem NonStop lock-step?

    Arne



    Well, no, not really.  What I'd envision would be what I'd call an
    application monitor, for lack of a better name, that would be able to
    know what the applications should be doing, to monitor that activity,
    and to do whatever necessary to continue the activity, should anything
    happen to that activity. Yeah, non-stop, but not the Tandem design.

    Just a concept, and design and implementation might be "interesting".

    I'd just note that the OSs would be included as applications, so
    re-starting them from where they were interrupted would be included in
    the concept.  So, yeah, the monitor would be outside/over the OSs.
    Perhaps something like happens with VMs.  Except VMs want to move the
    activity to another system, not recover on the same system.

    Whatever the design and implementation, this would be a really useful
    and marketable addition to the OpenVMS cluster concept. Clusters were invented 40 years ago to implement horizontal scalability, because
    vertical scalability was impossible, technically or financially. This
    issue has mostly disappeared today, current hardware being able to
    deliver any power we might want. Today's clusters are essentially
    put in place for redundancy or disaster recovery purposes ; the next
    logical step should be to provide this redundancy in a transparent way
    to the system user.

    This should also be, as opposed to simple user niceties, something that allows VSi to make money with.


    Would OpenVMS Service Control cover your needs?

    <https://vmssoftware.com/products/service-control/>

    Service Control was originally developed by Wolfgang Burger at HP in
    Vienna and later adopted by VSI. As far as I know it is (still) offered
    as a service, not a product - but only VSI can tell.

    Hans.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to All on Tue Jan 30 01:50:02 2024
    On 1/29/2024 7:00 PM, Arne Vajhøj wrote:
    On 1/29/2024 6:21 PM, Hans Bachner wrote:
    Marc Van Dyck schrieb am 29.01.2024 um 16:36:
    Dave Froble formulated the question :
    I'd just note that the OSs would be included as applications, so re-starting
    them from where they were interrupted would be included in the concept. So,
    yeah, the monitor would be outside/over the OSs. Perhaps something like >>>> happens with VMs. Except VMs want to move the activity to another system, >>>> not recover on the same system.

    Whatever the design and implementation, this would be a really useful
    and marketable addition to the OpenVMS cluster concept. Clusters were
    invented 40 years ago to implement horizontal scalability, because
    vertical scalability was impossible, technically or financially. This
    issue has mostly disappeared today, current hardware being able to
    deliver any power we might want. Today's clusters are essentially
    put in place for redundancy or disaster recovery purposes ; the next
    logical step should be to provide this redundancy in a transparent way
    to the system user.

    This should also be, as opposed to simple user niceties, something that
    allows VSi to make money with.

    Would OpenVMS Service Control cover your needs?

    <https://vmssoftware.com/products/service-control/>

    Service Control was originally developed by Wolfgang Burger at HP in Vienna >> and later adopted by VSI. As far as I know it is (still) offered as a service,
    not a product - but only VSI can tell.

    This indeed seems like the app<--->VMS equivalent of
    VM<--->ESXi.

    You define an app to be running on one node in the cluster
    and if something happens then the software start the app
    on another node.

    Like you define a VM to be running on one ESXi server in the
    cluster and if something happens then VMWare spin up
    the VM on another ESXi server.

    Arne

    Well, there are apps, and then there are other apps ...

    Ok, a web server handling connection requests. Perhaps one or more connections are disrupted before finishing. A re-start will begin to again handle connection requests. Perhaps reasonable.

    Then, an example from one of my old customers:

    Orders were build interactively, and the data was stored in an intermediate file. When done building, the intermediate file is then queued to a poster that
    processes the data and performs updates to all pertinent database files, then deletes the intermediate file.

    Ok, what happens when the system crashes during processing of an order? Things are left incomplete and a nasty mess. Re-starting the poster will make things worse. So, just restarting is not such a good idea.

    In the example, best not to process the order that was interrupted. Thankfully,
    this almost never happened. Thank you VMS and DEC hardware and battery backup UPS. But, it was still a possibility.

    The partial solution was to build checkpoints into the design. At each specific
    point in the poster, a flag was set, and forced to disk, as each file update occurred. The poster was set up to respect the checkpoint flags. Worked sort of well. Thee was still the possibility the checkpoint flags weren't written to
    disk. I didn't have an app that reviewed the information, and automatically re-queued it telling the poster where to re-start. That was a tedious manual task.

    Hey, with most things, there is a point of diminishing returns on efforts. Just
    not worth the cost.

    Please don't start ranting about a database with 2 stage commits. Didn't have one.

    But my point is, just re-starting an application isn't always a solution.

    --
    David Froble Tel: 724-529-0450
    Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
    DFE Ultralights, Inc.
    170 Grimplin Road
    Vanderbilt, PA 15486

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Van Dyck@21:1/5 to Dave Froble on Tue Jan 30 11:20:04 2024
    Dave Froble wrote on 30/01/2024 :
    On 1/29/2024 7:00 PM, Arne Vajhøj wrote:
    On 1/29/2024 6:21 PM, Hans Bachner wrote:
    Marc Van Dyck schrieb am 29.01.2024 um 16:36:
    Dave Froble formulated the question :
    I'd just note that the OSs would be included as applications, so
    re-starting
    them from where they were interrupted would be included in the concept. >>>>> So,
    yeah, the monitor would be outside/over the OSs. Perhaps something like >>>>> happens with VMs. Except VMs want to move the activity to another
    system,
    not recover on the same system.

    Whatever the design and implementation, this would be a really useful
    and marketable addition to the OpenVMS cluster concept. Clusters were
    invented 40 years ago to implement horizontal scalability, because
    vertical scalability was impossible, technically or financially. This
    issue has mostly disappeared today, current hardware being able to
    deliver any power we might want. Today's clusters are essentially
    put in place for redundancy or disaster recovery purposes ; the next
    logical step should be to provide this redundancy in a transparent way >>>> to the system user.

    This should also be, as opposed to simple user niceties, something that >>>> allows VSi to make money with.

    Would OpenVMS Service Control cover your needs?

    <https://vmssoftware.com/products/service-control/>

    Service Control was originally developed by Wolfgang Burger at HP in
    Vienna
    and later adopted by VSI. As far as I know it is (still) offered as a
    service,
    not a product - but only VSI can tell.

    This indeed seems like the app<--->VMS equivalent of
    VM<--->ESXi.

    You define an app to be running on one node in the cluster
    and if something happens then the software start the app
    on another node.

    Like you define a VM to be running on one ESXi server in the
    cluster and if something happens then VMWare spin up
    the VM on another ESXi server.

    Arne

    Well, there are apps, and then there are other apps ...

    Ok, a web server handling connection requests. Perhaps one or more connections are disrupted before finishing. A re-start will begin to again handle connection requests. Perhaps reasonable.

    Then, an example from one of my old customers:

    Orders were build interactively, and the data was stored in an intermediate file. When done building, the intermediate file is then queued to a poster that processes the data and performs updates to all pertinent database files, then deletes the intermediate file.

    Ok, what happens when the system crashes during processing of an order? Things are left incomplete and a nasty mess. Re-starting the poster will make things worse. So, just restarting is not such a good idea.

    In the example, best not to process the order that was interrupted. Thankfully, this almost never happened. Thank you VMS and DEC hardware and battery backup UPS. But, it was still a possibility.

    The partial solution was to build checkpoints into the design. At each specific point in the poster, a flag was set, and forced to disk, as each file update occurred. The poster was set up to respect the checkpoint flags.
    Worked sort of well. Thee was still the possibility the checkpoint flags weren't written to disk. I didn't have an app that reviewed the information, and automatically re-queued it telling the poster where to re-start. That was a tedious manual task.

    Hey, with most things, there is a point of diminishing returns on efforts. Just not worth the cost.

    Please don't start ranting about a database with 2 stage commits. Didn't have one.

    But my point is, just re-starting an application isn't always a solution.

    No, just restarting isn't the solution. And engineering the application
    to support random restarts isn't either. Just select a process from a
    system window, drag and drop it in another system window, and it
    continues to run on the other system as if nothing happened. That's
    what
    I'm after...


    --
    Marc Van Dyck

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael S@21:1/5 to Simon Clubley on Tue Jan 30 14:42:19 2024
    On Thu, 25 Jan 2024 13:21:38 -0000 (UTC)
    Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

    On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
    On 1/24/2024 8:13 AM, Simon Clubley wrote:
    On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:

    What is really rude is talking about Linux on c.o.v ...


    Unless you consider VMS to be perfect and not in need of any
    improvement, other operating systems offer some good ideas that it
    would be nice to see in VMS, especially around security and
    internal isolation in general.

    Then discuss the ideas and concepts ...


    OK.

    A random sample of things from Linux/Unix I would like to see in VMS:

    Mandatory Access Controls (my preference) or jails (Stephen's
    preference).

    A shell with decent modern functionality such as:

    Proper command history retention and merging from multiple
    sessions Easy searching of command history
    Tab completion
    Editing long command lines
    Globbing

    Proper package management and management of updates.

    Loadable and unloadable kernel modules, with device
    driver/filesystem/etc functionality available from within these
    modules.

    ASLR and KASLR support.

    Proper timezone management. (Everything is always UTC based, and your timezone is merely a local session property with no effect on the
    on-disk timestamps).

    The last one is policy-based, not technical:

    A vendor that has proper security reporting mechanisms.

    Does anyone have any others to add to the list ?

    Simon.


    RDP ?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Marc Van Dyck on Tue Jan 30 19:05:28 2024
    On 1/30/2024 5:20 AM, Marc Van Dyck wrote:
    Dave Froble wrote on 30/01/2024 :
    Ok, a web server handling connection requests.  Perhaps one or more
    connections are disrupted before finishing.  A re-start will begin to
    again handle connection requests.  Perhaps reasonable.

    Then, an example from one of my old customers:

    Orders were build interactively, and the data was stored in an
    intermediate file.  When done building, the intermediate file is then
    queued to a poster that processes the data and performs updates to all
    pertinent database files, then deletes the intermediate file.

    Ok, what happens when the system crashes during processing of an
    order? Things are left incomplete and a nasty mess.  Re-starting the
    poster will make things worse.  So, just restarting is not such a good
    idea.

    In the example, best not to process the order that was interrupted.
    Thankfully, this almost never happened.  Thank you VMS and DEC
    hardware and battery backup UPS.  But, it was still a possibility.

    The partial solution was to build checkpoints into the design.  At
    each specific point in the poster, a flag was set, and forced to disk,
    as each file update occurred.  The poster was set up to respect the
    checkpoint flags.  Worked sort of well.  Thee was still the
    possibility the checkpoint flags weren't written to disk.  I didn't
    have an app that reviewed the information, and automatically re-queued
    it telling the poster where to re-start.  That was a tedious manual task. >>
    Hey, with most things, there is a point of diminishing returns on
    efforts. Just not worth the cost.

    Please don't start ranting about a database with 2 stage commits.
    Didn't have one.

    But my point is, just re-starting an application isn't always a solution.

    No, just restarting isn't the solution. And engineering the application
    to support random restarts isn't either. Just select a process from a
    system window, drag and drop it in another system window, and it
    continues to run on the other system as if nothing happened. That's what
    I'm after...

    There are different models for HA:
    A) application managed - the application store state somewhere where
    a new instance can pick it up - this is not that hard to implement
    but the application need to be written for it
    B) system managed - the system store state somewhere where
    a new instance can pick it up - this is hard to implement
    but the application doesn't need to be written for it
    A2) same as A with a feature where the system can move the application
    from one node to another node - don't schedule the
    processes/threads, copy memory content to other node, get various
    files/network connections opened on the other node, schedule the
    processes/threads on the new node, kill the instance on the
    old node - harder than A but easier than B

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to All on Tue Jan 30 23:25:20 2024
    On 1/30/2024 7:05 PM, Arne Vajhøj wrote:
    On 1/30/2024 5:20 AM, Marc Van Dyck wrote:
    Dave Froble wrote on 30/01/2024 :
    Ok, a web server handling connection requests. Perhaps one or more
    connections are disrupted before finishing. A re-start will begin to again >>> handle connection requests. Perhaps reasonable.

    Then, an example from one of my old customers:

    Orders were build interactively, and the data was stored in an intermediate >>> file. When done building, the intermediate file is then queued to a poster >>> that processes the data and performs updates to all pertinent database files,
    then deletes the intermediate file.

    Ok, what happens when the system crashes during processing of an order?
    Things are left incomplete and a nasty mess. Re-starting the poster will >>> make things worse. So, just restarting is not such a good idea.

    In the example, best not to process the order that was interrupted.
    Thankfully, this almost never happened. Thank you VMS and DEC hardware and >>> battery backup UPS. But, it was still a possibility.

    The partial solution was to build checkpoints into the design. At each
    specific point in the poster, a flag was set, and forced to disk, as each >>> file update occurred. The poster was set up to respect the checkpoint flags.
    Worked sort of well. Thee was still the possibility the checkpoint flags >>> weren't written to disk. I didn't have an app that reviewed the information,
    and automatically re-queued it telling the poster where to re-start. That >>> was a tedious manual task.

    Hey, with most things, there is a point of diminishing returns on efforts. >>> Just not worth the cost.

    Please don't start ranting about a database with 2 stage commits. Didn't >>> have one.

    But my point is, just re-starting an application isn't always a solution. >>
    No, just restarting isn't the solution. And engineering the application
    to support random restarts isn't either. Just select a process from a
    system window, drag and drop it in another system window, and it
    continues to run on the other system as if nothing happened. That's what
    I'm after...

    There are different models for HA:
    A) application managed - the application store state somewhere where
    a new instance can pick it up - this is not that hard to implement
    but the application need to be written for it
    B) system managed - the system store state somewhere where
    a new instance can pick it up - this is hard to implement
    but the application doesn't need to be written for it
    A2) same as A with a feature where the system can move the application
    from one node to another node - don't schedule the
    processes/threads, copy memory content to other node, get various
    files/network connections opened on the other node, schedule the
    processes/threads on the new node, kill the instance on the
    old node - harder than A but easier than B

    "B" is what I had in mind in my earlier post.

    But, what will the customers pay for?

    In the example I posted earlier, I didn't get paid for the checkpointing work. Customer didn't care about little glitches. It offended my sensibilities concerning "right and wrong". After I thought about the solution, I just implemented it, for my own satisfaction. I felt much better.

    :-)

    --
    David Froble Tel: 724-529-0450
    Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
    DFE Ultralights, Inc.
    170 Grimplin Road
    Vanderbilt, PA 15486

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)