[Info-vax] Reinventing VMS logical names (Fuchsia & Win NT)

[Stephen Hoffman]

On 2023-11-07 18:58:17 +0000, Jake Hamby (Solid State Jake) said:

> If I were hired to work on the future of OpenVMS, the one non-obvious 
> direction I'd explore (anticipating what customers aren't yet asking 
> for) would be to extend logical name tables and VMS's existing concept 
> of multiple object classes with common security attributes to provide a 
> secure way for processes to grant capabilities to each other via 
> special mailbox messages or special LNM entries in a shared table.
> 
> Not only is this similar to how newer systems like Fuchsia, 
> microkernels, and exokernels work, but you've been able to pass file 
> descriptors and other security credentials across process boundaries in 
> UNIX, at least on the BSDs and Linux, using UNIX domain sockets for 
> some time.

There's a foundational question or three awaiting:
... compatibility with OpenVMS. Lots and lots of stuff is possible. 
Rather less of it is possible with upward-compatibility. Once you start 
to break stuff a little, you might as well create a plan and 
incrementally break, err, change more. (e.g. VAX architecture to Alpha 
architecture.) Which quite possibly leaves you with a MICA-like design 
or the Apple 32- and 64-bit design or a Dragonfly userland kernel, and 
all that preferably with a path to encourage moving the old apps 
forward.
... how much of a market is available for this new platform, and what 
part or multiplier of a billion dollars and a decade do you want to 
spend to get closer to serving that predicted market. Operating systems 
are enormous projects, nowadays.

There's certainly the potential (horrible as it might be?) aggregation 
and re-design possible here, among the antediluvian PDP-11 logical name 
scheme, the OpenVMS updates to that scheme and the misuses of same, of 
LDAP, DNS and mDNS, property list files, registry files, Plan 9 and its 
fondness for objects, and I'm not at all sure where these sorta-related 
features might then evolve when hypothetically aggregated together. 
This all hopefully obviously ties into fixing the DEC C logical name 
mess, too. A whole lot of this stuff is really quite reminiscent of 
LDAP, too.

Dragonfly is a fork of BSD with a whole lot of new work happening 
within, not the least of which is HAMMER2 (a BSD file system 
implementation influenced by zfs), and where some of the other work is 
sort-of following above capabilities-related suggestions:
https://lists.dragonflybsd.org/pipermail/commits/2023-October/922780.html 
(note how many modules the change touched, too.)

One hypothetical path forward would involve loading OpenVMS into a 
subsystem within Dragonfly. Yeah. But that's not happening. Ever.

Possibly apropos, some related tooling: https://github.com/rpetrich/callander

And yeah, Fuchsia is among the more interesting re-thinkings happening 
past or prescient, save for the understandable concerns about another 
habit of the Chocolate Factory: https://killedbygoogle.com


PS: unrelated to the above, lots of fodder for finding latent security 
bugs that might exist within their OpenVMS implementations continues to 
become available, too: https://links.hackliberty.org/post/134157


-- 
Pure Personal Opinion | HoffmanLabs LLC