[Info-vax] Kernel Transplantation (was: Re: New CEO of VMS Software)

[Dan Cross]

In article <uncbv2$ns66$1 at dont-email.me>,
Lawrence D'Oliveiro  <ldo at nz.invalid> wrote:
>On Sat, 6 Jan 2024 13:36:59 -0500, Stephen Hoffman wrote:
>
>> On 2024-01-06 02:48:42 +0000, Lawrence D'Oliveiro said:
>> 
>>> That can be blamed on the limitations of Mach. People still seem to
>>> think microkernels are somehow a good idea, but they really don’t help
>>> much, do they?
>> 
>> With current hardware including cores and performance and with newer
>> message-passing designs such as OKL4 and ilk, some things are looking
>> rather better.
>
>Hope springs eternal in the microkernel aficionado’s breast. ;)
>
>>>> As another example, it was not possible to emulate VMS’ strong
>>>> isolation of kernel resource usage by different users.
>>> 
>>> Would the Linux cgroups functionality (as commonly used in the various
>>> container schemes) help with this?
>> 
>> No.
>> 
>> Designers of VAX/VMS chose a memory management model closer to that of
>> Multics, where much of the rest of hardware and software in the industry
>> diverged from that lotsa-rings memory management design.
>
>Seems you are confusing two different things here. I am aware of the user/
>supervisor/exec/kernel privilege-level business, but you did say "resource 
>usage by different *users*". cgroups are indeed designed to manage that.

But that's not what he actually said: you omitted the critical
word, "kernel", as in _kernel resources_ used by different
users.  cgroups are designed to manage _userspace_ resources;
they still exist in fundamentally the same kernel space.

>Remember that my proposal for adopting the Linux kernel would get rid of 
>every part of VMS that currently runs at higher than user mode. It's only 
>their own user-mode code that customers would care about.

You think that's easy, but it is clear that you really don't
understand the issues involved.

>> Containers are arguably fundamentally about product-licensing arbitrage,
>> too.
>
>I don't use them that way. I use them as a cheap way to run up multiple 
>test installations of things I am working on, instead of resorting to full 
>VMs. Typically it only takes a few gigabytes to create a new userland for 
>a container. E.g. on this machine I am using now:

Containers started as a way to run multiple versions of some
very large programs with disparate library and other
dependencies on a single system, and grew into a mechanism for
managing resources generally.

>    root at theon:~ # du -ks /var/lib/lxc/*/rootfs/
>    1700060 /var/lib/lxc/debian10/rootfs/
>    7654028 /var/lib/lxc/debian11/rootfs/
>    876568  /var/lib/lxc/debian12/rootfs/
>
>> Microkernels are in use all over the place nowadays, seL4-, L4-, and
>> OKL4-derived.
>
>Really?? Can you name some deployments? How would performance compare with 
>Linux? Because, let's face it, Linux is the standard for high-performance 
>computing.

He gave you examples.

He pointed you to seL4, which is used in plenty of safety
critical systems.

Additionally, QNX runs nuclear power plants.  Every Mac on the
planet runs more or less a version of Mach+BSD.  The Intel ME
embedded in most Intel CPUs runs Minix3.

Such a shame that the Linux team, despite their vast resources,
are incapable of delivering an effective microkernel.  I guess
they just can't pull it off. (/s)

>> For a small development team—and VSI is tiny—kernel transplantation
>> doesn't gain much from a technical basis, once the platform port is
>> completed. It might help with future ports, sure.
>
>Which was my point all along: if they'd done this for the AMD64 port from 
>the beginning, they would have shaved *years* off the development time.

So you say.  People who know better disagree.

>And likely ended up with a somewhat larger (remaining) customer base than 
>they have now.

You have yet to articulate any measurable way in which this
would have made a difference to customers.  It seems clear that
this is because you yourself have no idea other than, "lol Linux
is better."

	- Dan C.