On 1/6/2024 3:11 PM, Lawrence D'Oliveiro wrote:
> So you see, on the Unix side, the vendors never thought to charge any
> different for the “workstation” versus “server” software, because it was
> the exact same software, with the exact same capabilities.

Commercial Unix was usually sold as systems - a bundle of HW and OS.

Making the distinction irrelevant.

> Today, the only OS in widespread use with this commonality of function
> across disparate hardware configurations is Linux.

I don't see the big difference between Linux and Windows in that regard.

MS has a NT kernel NN.N that end up in Windows MM and Windows Server YYYY.

Desktop and server Windows do share kernel. It is all the services
and tools on top that are different.

Linux kernel V.V end up in distro Zzzzz Server P.P and distro Zzzzz desktop.

Most commercial Linux distros have both a server version and a
desktop version. Including Redhat, SUSE and Ubuntu.

Arne

On Sat, 6 Jan 2024 15:30 +0000 (GMT Standard Time), John Dallman wrote:

> It can't be made fully 64-bit without breaking source-level
> compatibility with customer code.
> ...
> Obviously, DEC needed a 64-bit VMS. They also needed it /soon/, so they
> added 64-bit versions of the APIs that most needed to deal with lots of
> memory. Quite a lot of APIs that took pointers to user memory carried on
> taking 32-bit pointers, and thus could only deal with data in the bottom
> 2GB of a process address space.
>
> They probably intended to add 64-bit versions of all the other APIs, but
> this never happened, for reasons that probably included some of:
>
> * Lack of budget: DEC was never as successful in the 1990s as it
> had been in the 1980s.

Yes, but remember, at the same time, they were able to bring out their own
Unix OS for the same hardware, and make it fully 64-bit from the get-go.

Look at how the Linux kernel does it, on platforms (e.g. x86) where 32-bit
code still matters: it is able to be fully 64-bit internally, yet offer
both 32-bit and 64-bit APIs to userland.

By about 1996, there were 4 OSes that you might say were in common use on
Alpha: DEC Unix, OpenVMS, Windows NT, and Linux. Two of them (Unix and
Linux) were fully 64-bit; one (OpenVMS) was a hybrid of 32- and 64-bit
code; and Windows NT was 32-bit only.

On Sat, 6 Jan 2024 06:32:01 -0800 (PST), Neil Rieck wrote:

> The official CEO blurb from VSI is on their LinkedIn page:
>
> https://www.linkedin.com/company/vms-software-inc-/

“Specialties ... VMS Development and Disaster Recovery”

The two have nothing to do with each other, of course. ;)

In article <uncbv2$ns66$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@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@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.

On Sat, 6 Jan 2024 15:25:59 -0500, Arne Vajhøj wrote:

> On 1/6/2024 3:11 PM, Lawrence D'Oliveiro wrote:
>
>> So you see, on the Unix side, the vendors never thought to charge any
>> different for the “workstation” versus “server” software, because it
>> was the exact same software, with the exact same capabilities.
>
> Commercial Unix was usually sold as systems - a bundle of HW and OS.
>
> Making the distinction irrelevant.

Let me repeat the point: if you wanted server-type functionality, you
didn’t need to specifically buy a server box. You could do it with one of
their workstations.

This was true of all the Unix vendors, it was not true of Windows NT.

> Most commercial Linux distros have both a server version and a
> desktop version. Including Redhat, SUSE and Ubuntu.

That’s purely a difference of packaging, not functionality. For example,
if I run “desktop” Fedora, SUSE or Ubuntu, I am not limited in the number
of network shares, or the number of concurrent users, or what server
packages I can install (such as Samba, Kerberos, BIND, Apache, Nginx,
LDAP, MariaDB, PostgresQL, mail MTAs, NNTP servers, virtualization/
containerization, whatever). It’s all the same.

On 1/6/2024 3:27 PM, Lawrence D'Oliveiro wrote:
> On Sat, 6 Jan 2024 15:30 +0000 (GMT Standard Time), John Dallman wrote:
>> It can't be made fully 64-bit without breaking source-level
>> compatibility with customer code.

> Yes, but remember, at the same time, they were able to bring out their own
> Unix OS for the same hardware, and make it fully 64-bit from the get-go.

It was the same technical problem, but a different business context.

Changing all pointers from 32 to 64 bit would break a lot of legacy
code.

But DEC was making a lot of money from VMS VAX customers and wanted
to keep those customers, so VMS VAX code had build on VMS Alpha (and
actually allow converting VMS VAX executables to VMS Alpha executables
without source code).

No such concern was made for the Ultrix customers going to DEC OSF/1
aka DUNIX aka Tru64.

DEC made less money from Ultrix. Ultrix and OSF/1 was two different
Unixes so compatibility would have been difficult anyway. And porting
C code using a C API was easier anyway.

> Look at how the Linux kernel does it, on platforms (e.g. x86) where 32-bit
> code still matters: it is able to be fully 64-bit internally, yet offer
> both 32-bit and 64-bit APIs to userland.

> By about 1996, there were 4 OSes that you might say were in common use on
> Alpha: DEC Unix, OpenVMS, Windows NT, and Linux. Two of them (Unix and
> Linux) were fully 64-bit; one (OpenVMS) was a hybrid of 32- and 64-bit
> code; and Windows NT was 32-bit only.

32 and 64 bit on Linux (or Windows) is totally different from
32 and 64 bit on VMS Alpha/Itanium/x86-64.

They have 32 bit code with 32 bit pointers and 64 bit code with
64 bit pointers.

VMS has only 64 bit code but both 32 bit pointers and 64 bit pointers
(32 bit pointers getting extended to 64 bit addresses).

Arne

On Fri, 2024-01-05 at 22:10 +0000, Lawrence D'Oliveiro wrote:
> And yet they were never able to make VMS a fully 64-bit OS, even on
> their own fully 64-bit hardware.

Eh?! It's 100% 64 bits.
--
Tactical Nuclear Kittens

On Sat, 2024-01-06 at 02:33 +0000, Lawrence D'Oliveiro wrote:
> On Fri, 5 Jan 2024 09:23:36 -0500, Arne Vajhøj wrote:
>
> > Another example:
> >
> > SYS$SETPRV with PRV$M_SYSNAM  followed by SYS$CRELNM with
> > LNM$_TABLE as
> > "LNM$SYSTEM_TABLE".
> >
> > The API is not that complex. The semantics on VMS is well
> > documented.
> >
> > But the code does not really make any sense on Linux. So what to
> > do?
>
> We can emulate logical names on Linux beyond the per-process ones
> with a server process and communication via some IPC mechanism. D-Bus
> or Varlink might be good enough for this.

if setenv() and getenv() were thread-safe it'd be easier to use these.
--
Tactical Nuclear Kittens

On Sat, 06 Jan 2024 21:22:20 +0000, Single Stage to Orbit wrote:

> On Sat, 2024-01-06 at 02:33 +0000, Lawrence D'Oliveiro wrote:
>
>> We can emulate logical names on Linux beyond the per-process ones with
>> a server process and communication via some IPC mechanism. D-Bus or
>> Varlink might be good enough for this.
>
> if setenv() and getenv() were thread-safe it'd be easier to use these.

No, environment variables are no good (other than process-specific logical
names) because they do not affect processes other than the current one.

On Sat, 6 Jan 2024 15:09:25 -0500, Arne Vajhøj wrote:

> On 1/5/2024 11:52 PM, Lawrence D'Oliveiro wrote:
>
>> So that’s the second page done. I could keep going on, but do you want
>> to shortcut the process by pointing out where you think the traps lie?
>
> It becomes complex to maintain that process state in a VMS process style
> aka across image activations.

Not sure how that’s relevant to the question about $GETJPI.

On Sat, 6 Jan 2024 15:59:58 -0500, Arne Vajhøj wrote:

> No such concern was made for the Ultrix customers going to DEC OSF/1 aka
> DUNIX aka Tru64.
>
> DEC made less money from Ultrix. Ultrix and OSF/1 was two different
> Unixes so compatibility would have been difficult anyway. And porting C
> code using a C API was easier anyway.

You almost got the point, didn’t you? That POSIX had defined standard
types like “time_t” and “size_t”, and code that was written to adhere to
those types as appropriate was much easier to port between different
architectures. This applied to customer code, to third-party code ... to
all code.

And POSIX already existed when Dave Cutler commenced development on
Windows NT. Back when he was starting VMS, he could claim ignorance of
such techniques for avoiding obsolescence; what was his excuse this time?

> VMS has only 64 bit code but both 32 bit pointers and 64 bit pointers
> (32 bit pointers getting extended to 64 bit addresses).

Not sure how you can have 64-bit code without 64-bit addressing ... that
is practically the essence of 64-bit code.

Does that “64-bit” code on VMS still call LIB$EMUL?

On Sat, 6 Jan 2024 20:31:22 -0000 (UTC), Dan Cross wrote:

> But that's not what he actually said: you omitted the critical word,
> "kernel", as in _kernel resources_ used by different users.

Since *all* resources are defined (and managed) as such by the kernel, I
fail to see what the distinction is.

cgroups let you manage CPU time usage and CPU affinity (are CPUs a
“kernel” resource?), memory usage (is that a “kernel” resource?), I/O
usage (is that a “kernel” resource?), RDMA usage (is that a “kernel”
resource?), numbers of processes created (is that a “kernel” resource?)
etc etc.

Otherwise, feel free to explain what the distinction is between a “user”
resource and a “kernel” resource.

>>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.

The poster I was replying to already conceded this point.

> 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.

You are thinking of Docker. Which is just one kind of “container”
technology. Remember that “containers” as such do not exist as a built-in
primitive in the Linux kernel: they are constructed out of a bunch of
lower-level primitives, including cgroups and the various kinds of
namespaces. This allows for very different kinds of technologies to be
built that call themselves “containers”. And for them to coexist.

> Every Mac on the planet runs more or less a version of Mach+BSD.

And doesn’t exactly do so well. Back when Apple sold servers, I remember a
review of MySQL running on OS X Server versus Linux, on the same hardware.
Linux ran circles around Apple’s microkernel-based OS. On the company’s
own hardware.

> The Intel ME embedded in most Intel CPUs runs Minix3.

Bad, bad example.
<https://arstechnica.com/information-technology/2017/05/the-hijacking-
flaw-that-lurked-in-intel-chips-is-worse-than-anyone-thought/>

In article <uncc5u$ns66$2@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 6 Jan 2024 10:47:11 -0500, bill wrote:
>
>> On 1/5/2024 9:38 PM, Lawrence D'Oliveiro wrote:
>>
>>> For what I mean by “workstation”, look at the capabilities of the Unix
>>> workstations in the 1980s/1990s: remember, they ran the same OS as
>>> their respective companies’ server offerings, with all the same
>>> capabilities. It was Microsoft that came along and offered a
>>> “Workstation” OS that had cut-
>>> down capabilities compared to their “Server” offering, so they could
>>> charge less for the former ... and more for the latter.
>>
>> Not sure I agree with this at all. It's been a long time and my memory
>> may not be what it once was but I distinctly remember the only
>> difference between NT Server and NT Workstation was Registry Settings.
>
>You are remembering NT 3.51, I think it was, when somebody discovered
>that, indeed, all it took was a single Registry setting change to enable
>“Server” functionality on an NT “Workstation” installation.
>
>Microsoft fixed that in the next version. Remember, it was not in their
>interests to allow this sort of thing to continue, given the significant
>difference in price between the two products.
>
>So you see, on the Unix side, the vendors never thought to charge any
>different for the "workstation" versus "server" software, because it was
>the exact same software, with the exact same capabilities.

I remember pretty specifically maximum user limits on versions
of commercial Unix. Most of the time it didn't matter for a
workstation, where only one user at a time (generally) was
logged into the machine. For servers and timesharing hosts?
It was a big deal.

>Today, the only OS in widespread use with this commonality of function
>across disparate hardware configurations is Linux.

Or FreeBSD. Or OpenBSD.

- Dan C.

On Sat, 6 Jan 2024 23:42:26 -0000 (UTC), Dan Cross wrote:

> I remember pretty specifically maximum user limits on versions of
> commercial Unix.

How would such limits be enforced? Presumably they only applied to some
extra-cost “layered product”, not to the core OS.

Because consider that users are defined in /etc/passwd, which is just a
text file. How would you limit the number of lines in that? And the kernel
itself knows nothing of which user/group IDs are “valid” or “invalid”, it
will happily accept any numbers within the permissible ranges, regardless
of whether they appear in /etc/passwd or not. A network service (like
Telnet or SSH or file service) could limit the number of concurrent
connections, I suppose. But given there was open-source code available for
all of that anyway, it would be easy enough to bypass the limits by
replacing the vendor-provided code.

(Unless maybe you’re talking about IBM’s AIX. I am dimly aware that that
had its own proprietary ways of configuring things, that the traditional
*nix text-based configuration files were only a partial reflection of
that.)

>>Today, the only OS in widespread use with this commonality of function
>>across disparate hardware configurations is Linux.
>
> Or FreeBSD. Or OpenBSD.

I did say “widespread”. ;)

In article <uncqas$pust$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 6 Jan 2024 23:42:26 -0000 (UTC), Dan Cross wrote:
>
>> I remember pretty specifically maximum user limits on versions of
>> commercial Unix.
>
>How would such limits be enforced? Presumably they only applied to some
>extra-cost "layered product", not to the core OS.

No, they applied to the OS as a while.

>Because consider that users are defined in /etc/passwd, which is just a
>text file. How would you limit the number of lines in that?

Ignore lines after some predetermined maximum? Just not let
more than $n$ users at a time login? Just because you find it
difficult to conceive of how it was done does not mean that it
was not done.

>And the kernel
>itself knows nothing of which user/group IDs are "valid" or "invalid", it
>will happily accept any numbers within the permissible ranges,

Assuming it hasn't been modified. Remember, commercial Unix
vendors had the source code and modified it.

>regardless
>of whether they appear in /etc/passwd or not. A network service (like
>Telnet or SSH or file service) could limit the number of concurrent
>connections, I suppose. But given there was open-source code available for
>all of that anyway, it would be easy enough to bypass the limits by
>replacing the vendor-provided code.

Much of this was before SSH was invented, and way before "open
source" was the force it is today.

>(Unless maybe you're talking about IBM's AIX. I am dimly aware that that
>had its own proprietary ways of configuring things, that the traditional
>*nix text-based configuration files were only a partial reflection of
>that.)

AIX was a pretty standard port of System V at the kernel level,
but they made a lot of changes in userspace. But then, so did
most of the Unix vendors.

Regardless, even if you could get *around* it, you'd be
violating your license agreement, which isn't a great idea.

>>>Today, the only OS in widespread use with this commonality of function
>>>across disparate hardware configurations is Linux.
>>
>> Or FreeBSD. Or OpenBSD.
>
>I did say "widespread". ;)

Yes. So I mentioned FreeBSD and OpenBSD. You, undoubtedly,
simply aren't aware of just how widespread they are.

- Dan C.

In article <unck70$p3mp$4@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 6 Jan 2024 15:59:58 -0500, Arne Vajhøj wrote:
>
>> No such concern was made for the Ultrix customers going to DEC OSF/1 aka
>> DUNIX aka Tru64.
>>
>> DEC made less money from Ultrix. Ultrix and OSF/1 was two different
>> Unixes so compatibility would have been difficult anyway. And porting C
>> code using a C API was easier anyway.
>
>You almost got the point, didn't you? That POSIX had defined standard
>types like "time_t" and "size_t", and code that was written to adhere to
>those types as appropriate was much easier to port between different
>architectures. This applied to customer code, to third-party code ... to
>all code.

It took literally decades from the introduction of 64-bit Unix
machines until most software was 64-bit clean. I was there; it
was a painful time, and Linux was actually behind the curve
here compared to many of the commercial vendors.

The mere existence of those types a) didn't help the piles of
code that was sloppy and made assumptions about primitive types
and b) didn't help with binary compatibility during the
(lengthy) transition period. And yes, binary compatibility
mattered to a lot of people.

>And POSIX already existed when Dave Cutler commenced development on
>Windows NT. Back when he was starting VMS, he could claim ignorance of
>such techniques for avoiding obsolescence; what was his excuse this time?

What was Linux's?

>> VMS has only 64 bit code but both 32 bit pointers and 64 bit pointers
>> (32 bit pointers getting extended to 64 bit addresses).
>
>Not sure how you can have 64-bit code without 64-bit addressing ...

Of course you're not. "64-bit code" for something like x86
refers to details of the processor mode and e.g. the handling
of the REX prefix. On Alpha or Itanium, presumably that means
using the 64-bit ISA that uses e.g. 64-bit registers and so on.

But in either case, that's distinct from data pointers in
userspace are truncated represented as 32-bit values, as only
the low 2GiB of the address space is used by VMS applications.

>that is practically the essence of 64-bit code.

Nope.

- Dan C.

On 1/6/2024 5:28 PM, Lawrence D'Oliveiro wrote:
> On Sat, 6 Jan 2024 15:59:58 -0500, Arne Vajhøj wrote:
>> VMS has only 64 bit code but both 32 bit pointers and 64 bit pointers
>> (32 bit pointers getting extended to 64 bit addresses).
>
> Not sure how you can have 64-bit code without 64-bit addressing ... that
> is practically the essence of 64-bit code.

It has 64 bit addressing. It only has 64 bit addressing.

But pointers can be stored in RAM as both 32 bit pointers
and 64 bit pointers.

A 32 bit pointer with value 0x12345678 does not mean a
32 bit address of 0x12345678 but a 64 bit address of
0x0000000012345670.

And a 32 bit pointer with value 0x87654321 does not mean a
32 bit address of 0x87654321 but a 64 bit address of
0xFFFFFFFF87654321.

> Does that “64-bit” code on VMS still call LIB$EMUL?

LIB$EMUL multiply a 32 bit integer with a 32 bit integer
to give a 64 bit integer.

It is sort of obsolete because at the VAX to Alpha
move the languages got 64 bit integers.

The function still exist for compatibility reasons.

But it has nothing to do with addressing.

Arne

On 1/6/2024 4:22 PM, Single Stage to Orbit wrote:
> On Sat, 2024-01-06 at 02:33 +0000, Lawrence D'Oliveiro wrote:
>> On Fri, 5 Jan 2024 09:23:36 -0500, Arne Vajhøj wrote:
>>> Another example:
>>>
>>> SYS$SETPRV with PRV$M_SYSNAM  followed by SYS$CRELNM with
>>> LNM$_TABLE as
>>> "LNM$SYSTEM_TABLE".
>>>
>>> The API is not that complex. The semantics on VMS is well
>>> documented.
>>>
>>> But the code does not really make any sense on Linux. So what to
>>> do?
>>
>> We can emulate logical names on Linux beyond the per-process ones
>> with a server process and communication via some IPC mechanism. D-Bus
>> or Varlink might be good enough for this.
>
> if setenv() and getenv() were thread-safe it'd be easier to use these.

I see environment variables being closer to VMS symbols than to
VMS logicals.

But just closer not identical.

Arne

On 1/6/2024 7:27 PM, Dan Cross wrote:
> In article <unck70$p3mp$4@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 6 Jan 2024 15:59:58 -0500, Arne Vajhøj wrote:
>>> VMS has only 64 bit code but both 32 bit pointers and 64 bit pointers
>>> (32 bit pointers getting extended to 64 bit addresses).
>>
>> Not sure how you can have 64-bit code without 64-bit addressing ...
>
> Of course you're not. "64-bit code" for something like x86
> refers to details of the processor mode and e.g. the handling
> of the REX prefix. On Alpha or Itanium, presumably that means
> using the 64-bit ISA that uses e.g. 64-bit registers and so on.
>
> But in either case, that's distinct from data pointers in
> userspace are truncated represented as 32-bit values, as only
> the low 2GiB of the address space is used by VMS applications.

A VMS application with all pointers being 32 bit only
use the low 2 GB.

A VMS application with all 64 bit pointers or a mix of
32 bit and 64 bit pointers can use more (in theory 4 EB,
but I believe both HW and VMS has limits lower than that).

Arne

On Sun, 7 Jan 2024 00:27:15 -0000 (UTC), Dan Cross wrote:

> It took literally decades from the introduction of 64-bit Unix machines
> until most software was 64-bit clean.

I was doing Unix sysadmin work on DEC Alphas in the late 1990s until the
early 2000s, when the client saw the writing on the wall and moved to
Linux (and so did I).

They frequently asked me to download, build and install various items of
open-source software. I don’t recall ever having a problem with 64-bitness
per se.

> I was there; it was a painful
> time, and Linux was actually behind the curve here compared to many of
> the commercial vendors.

Jon “maddog” Hall shipped an Alpha to Linus Torvalds somewhere around
1995, and Linux was running native 64-bit on DEC Alpha in releasable form
by about 1996. That was only only the second hardware platform that Linux
had been implemented on, at that stage. So it went portable at the same
time it went 64-bit.

> The mere existence of those types a) didn't help the piles of code that
> was sloppy and made assumptions about primitive types ...

Piles of proprietary code, certainly.

In article <uncl7l$p3mp$5@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 6 Jan 2024 20:31:22 -0000 (UTC), Dan Cross wrote:
>
>> But that's not what he actually said: you omitted the critical word,
>> "kernel", as in _kernel resources_ used by different users.
>
>Since *all* resources are defined (and managed) as such by the kernel, I
>fail to see what the distinction is.

That is evident, but this is not the flex you think that it is.

>cgroups let you manage CPU time usage and CPU affinity (are CPUs a
>"kernel" resource?), memory usage (is that a "kernel" resource?), I/O
>usage (is that a "kernel" resource?), RDMA usage (is that a "kernel"
>resource?), numbers of processes created (is that "kernel" resource?)
>etc etc.
>
>Otherwise, feel free to explain what the distinction is between a "user"
>resource and a "kernel" resource.

Since you asked....

User resources: resources allocated to a user process for the
purpose of executing user code. Examples may include mapped
segments containing executable text, read-only or read/write
data, identifiers handed to userspace to identify resources
held by the kernel on a process's behalf (file and socket
descriptors, for example).

Kernel resources: Those allocated by the kernel for its internal
use. Examples may include page tables describing an address
space, the mapping of user-visible tokens to IO resources (e.g.,
the file array that maps file descriptors to the kernel's
representation of an open file or socket or pipe or whatever),
on Unix-y systems the set of signals pending delivery in the
process, etc. Other examples may include things like a
description of the buses and peripheral devices (e.g., the
complete enumeration of the PCIe topology), buffers associated
with IO devices and the filesystem, a page cache, etc.

Some things blur the line: is the `proc` structure describing a
process a kernel resource, even though it's sole purpose is to
describe a user process? Most kernel people would probably say
yes, particularly as (on Unix-y style systems) the proc
structure allocated to a process will outlive the process itself
(e.g., so that the parent can `wait` on it to collect its exit
status).

These are just a few examples.

>>>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.
>
>The poster I was replying to already conceded this point.

Yes, everyone has acknowledged that you don't understand the
issues involved.

>> 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.
>
>You are thinking of Docker.

No, I am not. I was there when containers were invented, and I
know very much what the original use case was.

>Which is just one kind of "container"
>technology. Remember that "containers" as such do not exist as a built-in
>primitive in the Linux kernel: they are constructed out of a bunch of
>lower-level primitives, including cgroups and the various kinds of
>namespaces. This allows for very different kinds of technologies to be
>built that call themselves "containers". And for them to coexist.

Yawn. Cool story, bro.

>> Every Mac on the planet runs more or less a version of Mach+BSD.
>
>And doesn't exactly do so well.

"For some specific use cases." FTFY.

>Back when Apple sold servers, I remember a
>review of MySQL running on OS X Server versus Linux, on the same hardware.
>
>Linux ran circles around Apple's microkernel-based OS. On the company's
>own hardware.

I remember when Linux acquired TCP/IP support. It was
consistently about 10% slower than BSD at the time. What's your
point? But if we're going to go there....

Why, after all these years, does USB audio on Linux fail so
miserably so often? Why do they still have problems with
suspend and resume on laptops? Why does Linux panic when you
turn on built-in features, like AX.25? Why is it such a pain to
partition disks? Why does the `ss` command still not show
routing tables for lesser-used protocols? Why are the debugging
tools so primitive compared to what Sun was doing 20 years ago
with dtrace? Why don't they have something as robust and
functional as ZFS? Why can't the amazingly resourced Linux
repeat what a group of like 5 engineers at Sun did in 18 months
20 years ago?

You seem to think that Linux is so great, and the irony is that
you're actually _right_. But it's obvious that you don't have
the first clue about _why_ you think that, or what makes Linux
great.

>> The Intel ME embedded in most Intel CPUs runs Minix3.
>
>Bad, bad example.
><https://arstechnica.com/information-technology/2017/05/the-hijacking-
>flaw-that-lurked-in-intel-chips-is-worse-than-anyone-thought/>

Yup. They had a pretty bad flaw. Do you think it hasn't been
fixed? And do you think that's the fault of the kernel that
runs on the ME? That was, after all, in an application program
that ran on that OS: should we start comparing to CVEs in
programs that run under Linux? For that matter, should we start
comparing CVEs between Minix and Linux?

I notice you elided my other examples, as they did not support
your point.

- Dan C.

On Sun, 7 Jan 2024 00:19:43 -0000 (UTC), Dan Cross wrote:

> Much of this was before SSH was invented, and way before "open source"
> was the force it is today.

Open source was there practically from the beginning of the Unix
workstation era (say, mid-1980s onwards). The first thing any seasoned
Unix sysadmin did on a new machine was download, build and install the GNU
tools. In the pre-RISC era, GCC was known for generating better code than
the vendors’ own compilers. And in any case, Bash was almost always a
better shell than whatever buggy version of sh or csh the vendor provided.
GNU tools tended to have more functionality than vendor-specific ones. And
so on.

On 1/6/2024 5:23 PM, Lawrence D'Oliveiro wrote:
> On Sat, 6 Jan 2024 15:09:25 -0500, Arne Vajhøj wrote:
>> On 1/5/2024 11:52 PM, Lawrence D'Oliveiro wrote:
>>> So that’s the second page done. I could keep going on, but do you want
>>> to shortcut the process by pointing out where you think the traps lie?
>>
>> It becomes complex to maintain that process state in a VMS process style
>> aka across image activations.
>
> Not sure how that’s relevant to the question about $GETJPI.

GETJPI retrive that info, so that the info is correct per VMS
semantics is important for GETJPI, and VMS semantics are a bit
tricky because of the differences between VMS and *nix.

Arne

In article <uncrcr$q371$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/6/2024 4:22 PM, Single Stage to Orbit wrote:
>> On Sat, 2024-01-06 at 02:33 +0000, Lawrence D'Oliveiro wrote:
>>> On Fri, 5 Jan 2024 09:23:36 -0500, Arne Vajhøj wrote:
>>>> Another example:
>>>>
>>>> SYS$SETPRV with PRV$M_SYSNAM  followed by SYS$CRELNM with
>>>> LNM$_TABLE as
>>>> "LNM$SYSTEM_TABLE".
>>>>
>>>> The API is not that complex. The semantics on VMS is well
>>>> documented.
>>>>
>>>> But the code does not really make any sense on Linux. So what to
>>>> do?
>>>
>>> We can emulate logical names on Linux beyond the per-process ones
>>> with a server process and communication via some IPC mechanism. D-Bus
>>> or Varlink might be good enough for this.
>>
>> if setenv() and getenv() were thread-safe it'd be easier to use these.
>
>I see environment variables being closer to VMS symbols than to
>VMS logicals.
>
>But just closer not identical.

Eh. Emulation of logical names would likely be done by
maintaining and consulting symbol tables in the DCL "shell" (or
whatever emulated DCL in this frankenstein "VMS on Linux"
monstronsity) for user mode logicals and a symbol table
maintained in a region of shared memory owned by some DSO-like
shared object for the others.

The idea of using some service that one communicates with via
dbus to emulate logical names is absurd.

- Dan C.

In article <uncsed$q65q$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sun, 7 Jan 2024 00:27:15 -0000 (UTC), Dan Cross wrote:
>> It took literally decades from the introduction of 64-bit Unix machines
>> until most software was 64-bit clean.
>
>I was doing Unix sysadmin work on DEC Alphas in the late 1990s until the
>early 2000s, when the client saw the writing on the wall and moved to
>Linux (and so did I).

Your anecdotal evidence is not terribly convincing.

I was working on Alphas in the early 90s, shortly after they
were released. Most of the open source world wasn't ready.

I was also working on 64-bit SGI machines running Irix 6 (on
the MIPS R4000) before the Alpha; similar problem.

>They frequently asked me to download, build and install various items of
>open-source software. I don't recall ever having a problem with 64-bitness
>per se.

Sounds like you had very limited experience.

>> I was there; it was a painful
>> time, and Linux was actually behind the curve here compared to many of
>> the commercial vendors.
>
>Jon "maddog: Hall shipped an Alpha to Linus Torvalds somewhere around
>1995,

Yes. I already posted that factoid in this newsgroup a couple
of days ago.

>and Linux was running native 64-bit on DEC Alpha in releasable form
>by about 1996.
>That was only only the second hardware platform that Linux
>had been implemented on, at that stage. So it went portable at the same
>time it went 64-bit.

....and you think there weren't bugs.

>> The mere existence of those types a) didn't help the piles of code that
>> was sloppy and made assumptions about primitive types ...
>
>Piles of proprietary code, certainly.

Nope. You underestimate the amount of code that tried to e.g.
pun an `int` for a pointer in those days. I ran into this
porting an APL interpreter to x86_64 as late as 2010.

- Dan C.