From: seaohveh@hoffmanlabs.invalid   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)