Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stephen Hoffman <seaohveh@hoffmanlabs.invalid>
Newsgroups: comp.os.vms
Subject: Re: Bootcamp
Date: Fri, 11 Jul 2025 17:58:56 -0400
Organization: HoffmanLabs LLC
Lines: 58
Message-ID: <104s1f0$1ndbh$1@dont-email.me>
References: <mchom4F15kcU1@mid.individual.net> <mckld9Fg08sU1@mid.individual.net> <10465mq$62th$1@dont-email.me> <104cgf1$vk0k$1@paganini.bofh.team> <104dri4$11oku$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 11 Jul 2025 23:58:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c51077b6fab71e0182e283603f5040cc";
	logging-data="1815921"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19IBab0NH3bKBfzZTJqteJKf3yGyJ7UZZk="
User-Agent: Unison/2.2
Cancel-Lock: sha1:S2QDkBN925jhAA/ZEN6e29hrrW8=

On 2025-07-06 12:52:22 +0000, Waldek Hebisch said:

> There are no indicatianos of substantial reimplementation.  Official 
> info says that new or substantially reworked code is in C.  But w also 
> have information that amount of Macro32 and Bliss did not substantially 
> decrease.  So, (almost all) old code is still in use.
> It could be that small changes to old code took a lot of time. It could 
> be that some new pieces were particularly tricky. However, you should 
> understand that porting really means replicating exisiting behaviour on 
> new hardware.  Replicating behaviour gets more tricky if you change 
> more parts and especially if you want to target a high level interface.

You're correct. Reworking existing working code is quite often an 
immense mistake.

It usually fails. If not always fails.

And bringing a source-to-source translation tooling or an LLM can be 
helpful, and can also introduce new issues and new bugs.

About the only way a global rewrite can succeed — absent a 
stratospheric-scale budget for the rewrite, and maybe not even then — 
is an incremental rewrite, as the specific modules need more than 
trivial modifications.

Reworking a project of the scale of OpenVMS — easily a decade-long 
freeze — and for little benefit to VSI.

Some bozo once wrote: "...VSI spends years creating an 
inevitably-somewhat-incomplete third-party Linux porting kit for 
customer OpenVMS apps, and the end goal of the intended customers then 
inexorably shifts toward the removal of that porting kit, and probably 
in the best case the whole effort inevitably degrades into apps ported 
top and running on VSI Linux. Or to porting to and running on some 
other not-VSI Linux. That's certainly a service business opportunity,  
providing customers assistance porting their OpenVMS apps to VSI Linux. 
 It does get VSI out of maintaining a kernel, but does not reduce much 
else. And that at no small cost and no small investment, and at a cost 
of a number of other opportunities..."

Yeah, I'm sure some customers would like assistance porting their 
native OpenVMS apps to native Linux, but that's already an opportunity 
for services organizations, albeit without the code sharing.

And I'd be willing to bet money VSI will need a number of modifications 
to the Linux kernel, too.  And the new OpenVMS kernel will then have to 
be maintained on an ongoing basis, and it'll have to comply with GPL2 
and potentially other licenses. If you're going to dream, maybe to to 
seL4 or some other kernel intended for this sort of thing.

But again, this has all been discussed before: 
https://groups.google.com/g/comp.os.vms/c/1etAx5jJoNM/m/nUY5infiAgAJ



-- 
Pure Personal Opinion | HoffmanLabs LLC