From Newsgroup: comp.os.vms


Here a a couple doozies for the collective knowledge here.

Is the current Mimer DB derived from the on that ran on PDP-11's
and the VAX back in the mid 80's?

And here's a more obscure one. Anybody here familiar with
EUNICE? I only got to access it as a user in my very first
days of VAX/VMS exposure. According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD. It ran on top of VMS. VMS can not do fork().
How did EUNICE do fork()?

And one last non-technical one. Is there anyone from the
old Wollongon Groups still around? Is there any chance of
getting a copy of EUNICE and permission to run it? It does
not have any commercial value that I can imagine (for obvious
reasons) and After all these years I would love to play with
it again. I assume running on one of my Vaxstation it would
be screamer compared to when I ran it on an 11/750. :-)

bill
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 6/28/2026 7:30 PM, bill wrote:

Is the current Mimer DB derived from the on that ran on PDP-11's
and the VAX back in the mid 80's?

Believe so.

https://en.wikipedia.org/wiki/Mimer_SQL#History

https://groups.google.com/g/pidp-11/c/xDUlCFx-G0s

And here's a more obscure one.-a Anybody here familiar with
EUNICE?-a I only got to access it as a user in my very first
days of VAX/VMS exposure.-a According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD.-a It ran on top of VMS.-a VMS can not do fork().
How did EUNICE do fork()?

And one last non-technical one. Is there anyone from the
old Wollongon Groups still around? Is there any chance of
getting a copy of EUNICE and permission to run it? It does
not have any commercial value that I can imagine (for obvious
reasons) and After all these years I would love to play with
it again. I assume running on one of my Vaxstation it would
be screamer compared to when I ran it on an 11/750. :-)

I remember having heard about it before.

https://en.wikipedia.org/wiki/Eunice_(software) says:

<quote>
Eunice was criticized for its performance problems and not quite
complete Unix compatibility. Eunice's reputation for poor compatibility inspired the "Congratulations. You aren't running Eunice." message
included in the Perl configure script.
</quote>

:-)

Why would you want to run Eunice??

1990's VMS 6.x Posix is newer and likely more compatible as it had
to pass Posix certification.

GNV is almost modern.

Arne



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sun, 28 Jun 2026 20:39:46 -0400, Arne Vajh|+j wrote:

1990's VMS 6.x Posix is newer and likely more compatible as it had
to pass Posix certification.

Yeah, but so did Windows NT
<https://www.youtube.com/watch?v=BOeku3hDzrM>.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

bill <bill.gunshannon@gmail.com> wrote:

And here's a more obscure one. Anybody here familiar with
EUNICE? I only got to access it as a user in my very first
days of VAX/VMS exposure. According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD. It ran on top of VMS. VMS can not do fork().
How did EUNICE do fork()?

It did it very, very, very slowly.

EUNICE was a bad idea all around. However, the Software Tools environment
from gatech gave you a reasonably unixlike interface on top of Pr1mos and
later VMS without making any of the underlying stuff unixlike.

And one last non-technical one. Is there anyone from the
old Wollongon Groups still around? Is there any chance of
getting a copy of EUNICE and permission to run it? It does
not have any commercial value that I can imagine (for obvious
reasons) and After all these years I would love to play with
it again. I assume running on one of my Vaxstation it would
be screamer compared to when I ran it on an 11/750. :-)

Jerry Scott is still on linkedin.
--scott

"Wollongong, it's gone all wrong."
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 6/28/2026 8:39 PM, Arne Vajh|+j wrote:

On 6/28/2026 7:30 PM, bill wrote:

Is the current Mimer DB derived from the on that ran on PDP-11's
and the VAX back in the mid 80's?

Believe so.>
https://en.wikipedia.org/wiki/Mimer_SQL#History

https://groups.google.com/g/pidp-11/c/xDUlCFx-G0s

Interesting. Wonder why only RSX at that point in time as there were
a lot of serious businesses running RSTS.

And here's a more obscure one. Anybody here familiar with
EUNICE? I only got to access it as a user in my very first
days of VAX/VMS exposure. According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD. It ran on top of VMS. VMS can not do fork().
How did EUNICE do fork()?

And one last non-technical one. Is there anyone from the
old Wollongon Groups still around? Is there any chance of
getting a copy of EUNICE and permission to run it? It does
not have any commercial value that I can imagine (for obvious
reasons) and After all these years I would love to play with
it again. I assume running on one of my Vaxstation it would
be screamer compared to when I ran it on an 11/750. :-)

I remember having heard about it before.

https://en.wikipedia.org/wiki/Eunice_(software) says:

<quote>
Eunice was criticized for its performance problems and not quite
complete Unix compatibility. Eunice's reputation for poor compatibility inspired the "Congratulations. You aren't running Eunice." message
included in the Perl configure script.
</quote>

Everyone knew about the poor performance. But EUNICE wasn't the only
poor performer. Whenever someone ran Ada on the system I was using
everyone else just logged off and found some other way to occupy their
time. :-)

Like many other things at that time the software was too far ahead of
the hardware.

:-)

Why would you want to run Eunice??

Why would I want to run a VAX? It's fun. It's interesting. It's
nostalgic.

1990's VMS 6.x Posix is newer and likely more compatible as it had
to pass Posix certification.

Not interested in POSIX. I used that when it first came out on the
VAX and wasn't impressed. It had been done better by STVOS but, sadly,
like most academic endeavors the grad student graduated. The project
withered on the vine and we waited a couple decades for someone to try
and reinvent (badly) the wheel.

GNV is almost modern.

Isn't GNV nothing but a handful of userland utilities common to
Unix? Not hardly the same as a functional Unix OS running on top
of VMS.

bill

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 6/28/2026 8:39 PM, Arne Vajh|+j wrote:

On 6/28/2026 7:30 PM, bill wrote:

Is the current Mimer DB derived from the on that ran on PDP-11's
and the VAX back in the mid 80's?

Believe so.>
https://en.wikipedia.org/wiki/Mimer_SQL#History

https://groups.google.com/g/pidp-11/c/xDUlCFx-G0s

Interesting. Wonder why only RSX at that point in time as there were
a lot of serious businesses running RSTS.

And here's a more obscure one. Anybody here familiar with
EUNICE? I only got to access it as a user in my very first
days of VAX/VMS exposure. According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD. It ran on top of VMS. VMS can not do fork().
How did EUNICE do fork()?

And one last non-technical one. Is there anyone from the
old Wollongon Groups still around? Is there any chance of
getting a copy of EUNICE and permission to run it? It does
not have any commercial value that I can imagine (for obvious
reasons) and After all these years I would love to play with
it again. I assume running on one of my Vaxstation it would
be screamer compared to when I ran it on an 11/750. :-)

I remember having heard about it before.

https://en.wikipedia.org/wiki/Eunice_(software) says:

<quote>
Eunice was criticized for its performance problems and not quite
complete Unix compatibility. Eunice's reputation for poor compatibility inspired the "Congratulations. You aren't running Eunice." message
included in the Perl configure script.
</quote>

Everyone knew about the poor performance. But EUNICE wasn't the only
poor performer. Whenever someone ran Ada on the system I was using
everyone else just logged off and found some other way to occupy their
time. :-)

Like many other things at that time the software was too far ahead of
the hardware.

:-)

Why would you want to run Eunice??

Why would I want to run a VAX? It's fun. It's interesting. It's
nostalgic.

1990's VMS 6.x Posix is newer and likely more compatible as it had
to pass Posix certification.

Not interested in POSIX. I used that when it first came out on the
VAX and wasn't impressed. It had been done better by STVOS but, sadly,
like most academic endeavors the grad student graduated. The project
withered on the vine and we waited a couple decades for someone to try
and reinvent (badly) the wheel.

GNV is almost modern.

Isn't GNV nothing but a handful of userland utilities common to
Unix? Not hardly the same as a functional Unix OS running on top
of VMS.

bill

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 6/28/2026 8:39 PM, Arne Vajh|+j wrote:

On 6/28/2026 7:30 PM, bill wrote:

Is the current Mimer DB derived from the on that ran on PDP-11's
and the VAX back in the mid 80's?

Believe so.>
https://en.wikipedia.org/wiki/Mimer_SQL#History

https://groups.google.com/g/pidp-11/c/xDUlCFx-G0s

Interesting. Wonder why only RSX at that point in time as there were
a lot of serious businesses running RSTS.

And here's a more obscure one. Anybody here familiar with
EUNICE? I only got to access it as a user in my very first
days of VAX/VMS exposure. According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD. It ran on top of VMS. VMS can not do fork().
How did EUNICE do fork()?

And one last non-technical one. Is there anyone from the
old Wollongon Groups still around? Is there any chance of
getting a copy of EUNICE and permission to run it? It does
not have any commercial value that I can imagine (for obvious
reasons) and After all these years I would love to play with
it again. I assume running on one of my Vaxstation it would
be screamer compared to when I ran it on an 11/750. :-)

I remember having heard about it before.

https://en.wikipedia.org/wiki/Eunice_(software) says:

<quote>
Eunice was criticized for its performance problems and not quite
complete Unix compatibility. Eunice's reputation for poor compatibility inspired the "Congratulations. You aren't running Eunice." message
included in the Perl configure script.
</quote>

Everyone knew about the poor performance. But EUNICE wasn't the only
poor performer. Whenever someone ran Ada on the system I was using
everyone else just logged off and found some other way to occupy their
time. :-)

Like many other things at that time the software was too far ahead of
the hardware.

:-)

Why would you want to run Eunice??

Why would I want to run a VAX? It's fun. It's interesting. It's
nostalgic.

1990's VMS 6.x Posix is newer and likely more compatible as it had
to pass Posix certification.

Not interested in POSIX. I used that when it first came out on the
VAX and wasn't impressed. It had been done better by STVOS but, sadly,
like most academic endeavors the grad student graduated. The project
withered on the vine and we waited a couple decades for someone to try
and reinvent (badly) the wheel.

GNV is almost modern.

Isn't GNV nothing but a handful of userland utilities common to
Unix? Not hardly the same as a functional Unix OS running on top
of VMS.

bill

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 6/29/2026 8:55 AM, bill wrote:

On 6/28/2026 8:39 PM, Arne Vajh|+j wrote:

GNV is almost modern.

Isn't GNV nothing but a handful of userland utilities common to
Unix?-a Not hardly the same as a functional Unix OS running on top
of VMS.

I believe that Eunice, Posix shell and GNV are all just a shell and
utilities - not an OS. Nothing in the Wine/WSL2/XDE category.

OK - Eunice and Posix also came with library support, but
VMS C RTL out of the box today are probably more compatible
with modern *nix SW than they were - things evolve and
lot of effort has been put in making VMS C RTL reasonable
compatible (sometimes by defining some magical logicals).

Arne



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 6/29/2026 6:57 AM, Scott Dorsey wrote:

bill <bill.gunshannon@gmail.com> wrote:

And here's a more obscure one. Anybody here familiar with
EUNICE? I only got to access it as a user in my very first
days of VAX/VMS exposure. According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD. It ran on top of VMS. VMS can not do fork().
How did EUNICE do fork()?

It did it very, very, very slowly.

Not necessarily EUNICE's fault. As I said in my response to Arne,
that was a time when software was too far ahead of hardware.

EUNICE was a bad idea all around.

I don't see why. Just too far ahead of it's time like many ideas
of that era.

However, the Software Tools environment from gatech gave you a reasonably unixlike interface on top of Pr1mos and later VMS without making any of the underlying stuff unixlike.

I am very familiar with STVOS. Worked with it pretty much from the
beginning and liked it. Still play with it today. If it's development
had continued at the time there would probably never have been a need
for POSIX except as a standard for STVOS.

As for the methodology behind EUNICE, remember PRIMIX? That was Pr1me's attempt at the same thing. It's performance was as dismal as EUNICE and
it also gave Pr1me a reason to withdraw permission from the project to
do a native mode Unix on the 50 series which was just about to be
announced and released.

And one last non-technical one. Is there anyone from the
old Wollongon Groups still around? Is there any chance of
getting a copy of EUNICE and permission to run it? It does
not have any commercial value that I can imagine (for obvious
reasons) and After all these years I would love to play with
it again. I assume running on one of my Vaxstation it would
be screamer compared to when I ran it on an 11/750. :-)

Jerry Scott is still on linkedin.

I wonder if he even remembers EUNICE. :-)

bill


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 6/29/2026 9:20 AM, bill wrote:

I am very familiar with STVOS.-a Worked with it pretty much from the beginning and liked it.-a Still play with it today.-a If it's development
had continued at the time there would probably never have been a need
for POSIX except as a standard for STVOS.

As for the methodology behind EUNICE, remember PRIMIX?-a That was Pr1me's attempt at the same thing. It's performance was as dismal as EUNICE and
it also gave Pr1me a reason to withdraw permission from the project to
do a native mode Unix on the 50 series which was just about to be
announced and released.

I accidentally left this part out.

In order to show what it had accomplished and what it likely
could have accomplished, STVOS was not just on VMS and Primos.
It ran to some level on over 50 different systems ranging from
Mainframes to Microcomputers offering an unbelievable (at the time)
source level compatibility.

bill



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <6a41bed2$0$665$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 6/28/2026 7:30 PM, bill wrote:

[snip]
And here's a more obscure one.-a Anybody here familiar with
EUNICE?-a I only got to access it as a user in my very first
days of VAX/VMS exposure.-a According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD.-a It ran on top of VMS.-a VMS can not do fork().
How did EUNICE do fork()?

And one last non-technical one. Is there anyone from the
old Wollongon Groups still around? Is there any chance of
getting a copy of EUNICE and permission to run it? It does
not have any commercial value that I can imagine (for obvious
reasons) and After all these years I would love to play with
it again. I assume running on one of my Vaxstation it would
be screamer compared to when I ran it on an 11/750. :-)

I remember having heard about it before.

https://en.wikipedia.org/wiki/Eunice_(software) says:

<quote>
Eunice was criticized for its performance problems and not quite
complete Unix compatibility. Eunice's reputation for poor compatibility >inspired the "Congratulations. You aren't running Eunice." message
included in the Perl configure script.
</quote>

I think it actually predates that.

I suspect Larry Wall introduced it with `rn`, his news reader,
before Perl. The `Configure` script that came with `trn` has
the same text, and that was a fork (essentially) of `rn`.

Indeed, one sees it in old from volume 1 of `comp.unix.sources`,
posted in 1985; Wall didn't publish Perl until 1987:

https://sources.vsta.org/comp.sources.unix/volume1/rn/part02

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 6/29/26 10:35 AM, Dan Cross wrote:

In article <6a41bed2$0$665$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 6/28/2026 7:30 PM, bill wrote:

[snip]
And here's a more obscure one.-a Anybody here familiar with
EUNICE?-a I only got to access it as a user in my very first
days of VAX/VMS exposure.-a According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD.-a It ran on top of VMS.-a VMS can not do fork().
How did EUNICE do fork()?

And one last non-technical one. Is there anyone from the
old Wollongon Groups still around? Is there any chance of
getting a copy of EUNICE and permission to run it? It does
not have any commercial value that I can imagine (for obvious
reasons) and After all these years I would love to play with
it again. I assume running on one of my Vaxstation it would
be screamer compared to when I ran it on an 11/750. :-)

I remember having heard about it before.

https://en.wikipedia.org/wiki/Eunice_(software) says:

<quote>
Eunice was criticized for its performance problems and not quite
complete Unix compatibility. Eunice's reputation for poor compatibility
inspired the "Congratulations. You aren't running Eunice." message
included in the Perl configure script.
</quote>

I think it actually predates that.

I suspect Larry Wall introduced it with `rn`, his news reader,
before Perl. The `Configure` script that came with `trn` has
the same text, and that was a fork (essentially) of `rn`.

Indeed, one sees it in old from volume 1 of `comp.unix.sources`,
posted in 1985; Wall didn't publish Perl until 1987:

https://sources.vsta.org/comp.sources.unix/volume1/rn/part02

Interesting, I didn't know how much he took from previous projects. The
eunice stuff in Configure matches very closely what's in the Perl 1.0
sources:

https://github.com/Perl/perl5/blob/16421f70f5b26ada5762d8a85272ac582fe2f9a5/Configure#L2419
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-06-29, bill <bill.gunshannon@gmail.com> wrote:

On 6/28/2026 8:39 PM, Arne Vajhoj wrote:

GNV is almost modern.

Isn't GNV nothing but a handful of userland utilities common to
Unix? Not hardly the same as a functional Unix OS running on top
of VMS.

They are the same thing (at least according to the Wikipedia link posted
about Eunice). They both provide a compatibility library so that a Unix userland can be run on top of a foreign operating system (ie: VMS).

You are not running "a functional Unix OS" on top of VMS. You are running userland tools by means of an interface layer and, if anything (based on
the comments in this discussion), it sounds like the modern approaches to implementing that interface layer provide better solutions.

It's really no different from the fact that I am running an Alpine Linux userland on my Android phone by means of an interface layer so I can use various Unix programs directly on the phone.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 6/28/26 19:30, bill wrote:

And here's a more obscure one.-a Anybody here familiar with
EUNICE?-a I only got to access it as a user in my very first
days of VAX/VMS exposure.-a According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD.-a It ran on top of VMS.-a VMS can not do fork().
How did EUNICE do fork()?

And one last non-technical one.-a-a Is there anyone from the
old Wollongon Groups still around?-a Is there any chance of
getting a copy of EUNICE and permission to run it?-a It does
not have any commercial value that I can imagine (for obvious
reasons)-a and After all these years I would love to play with
it again.-a I assume running on one of my Vaxstation it would
be-a screamer compared to when I ran it on an 11/750.-a :-)

Bill, just FYI, we at LSSM recovered EUNICE v3.1 from tape a couple
of years ago, along with manuals. We've not tried to run it on anything
but we believe it to be a complete distribution.

-Dave
--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

bill <bill.gunshannon@gmail.com> writes:

And here's a more obscure one. Anybody here familiar with
EUNICE? I only got to access it as a user in my very first
days of VAX/VMS exposure. According to the write-up in the
VAX Software Sourcebook it was capable of everything found
in BSD 4.1 BSD. It ran on top of VMS. VMS can not do fork().
How did EUNICE do fork()?

I just remember that Perl's Configure script said,
rCLCongratulations. YourCOre not running Eunice.rCY

Kragen
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

bill <bill.gunshannon@gmail.com> writes:

On 6/29/2026 6:57 AM, Scott Dorsey wrote:

It did it very, very, very slowly.

Not necessarily EUNICE's fault. As I said in my response to Arne,
that was a time when software was too far ahead of hardware.

You could run Unix on a PDP-11. You couldnrCOt do that with VMS.

Kragen
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Dave McGuire <mcguire@lssmuseum.org> writes:

Bill, just FYI, we at LSSM recovered EUNICE v3.1 from tape a couple
of years ago, along with manuals. We've not tried to run it on
anything but we believe it to be a complete distribution.

ThatrCOs fantastic news! I don't suppose you can release it legally, can
you?

Kragen
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <87h5jqpu4f.fsf@debian>,
Kragen Javier Sitaker <kragen@canonical.org> wrote:

bill <bill.gunshannon@gmail.com> writes:

On 6/29/2026 6:57 AM, Scott Dorsey wrote:

It did it very, very, very slowly.

Not necessarily EUNICE's fault. As I said in my response to Arne,
that was a time when software was too far ahead of hardware.

You could run Unix on a PDP-11. You couldnrCOt do that with VMS.

Apples and oranges, I'm afraid. You could run early versions of
research Unix on PDP-11s, sure, but that's not really comparable
to VMS: VMS compares more closely to 4BSD, which would _not_ run
on a PDP-11.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <87h5jqpu4f.fsf@debian>,
Kragen Javier Sitaker <kragen@canonical.org> wrote:

bill <bill.gunshannon@gmail.com> writes:

On 6/29/2026 6:57 AM, Scott Dorsey wrote:

It did it very, very, very slowly.

Not necessarily EUNICE's fault. As I said in my response to Arne,
that was a time when software was too far ahead of hardware.

You could run Unix on a PDP-11. You couldnrCOt do that with VMS.

Apples and oranges, I'm afraid. You could run early versions of
research Unix on PDP-11s, sure, but that's not really comparable
to VMS: VMS compares more closely to 4BSD, which would _not_ run
on a PDP-11.

Plus, Unix did run on a VAX, both BSD and a rather dodgy version
from AT&T (no paging, just swapping). I used the later circa 1981.

The first VMS releases actually included several RSX-M utilities
(e.g. PIP) running in compatability mode because the native
commands weren't available yet.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <EUiqS.3$GI1.2@fx01.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >Plus, Unix did run on a VAX, both BSD and a rather dodgy version

from AT&T (no paging, just swapping). I used the later circa 1981.

Other variations too, like BRL Unix from the Army Ballistics Research Lab
which was BSD with some radical modifications.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/15/26 08:38, Kragen Javier Sitaker wrote:

bill <bill.gunshannon@gmail.com> writes:

On 6/29/2026 6:57 AM, Scott Dorsey wrote:

It did it very, very, very slowly.

Not necessarily EUNICE's fault. As I said in my response to Arne,
that was a time when software was too far ahead of hardware.

You could run Unix on a PDP-11. You couldnrCOt do that with VMS.

Kragen

Comparing hardware to software.
You could run Unix on the VAX.
And EUNICE did exactly that. It was Unix on VMS.
kinda like what we do today with VM's but to far ahead for the
capabilities of the hardware.

Still, it was fun to try.

bill
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/15/26 13:35, Dan Cross wrote:

In article <87h5jqpu4f.fsf@debian>,
Kragen Javier Sitaker <kragen@canonical.org> wrote:

bill <bill.gunshannon@gmail.com> writes:

On 6/29/2026 6:57 AM, Scott Dorsey wrote:

It did it very, very, very slowly.

Not necessarily EUNICE's fault. As I said in my response to Arne,
that was a time when software was too far ahead of hardware.

You could run Unix on a PDP-11. You couldnrCOt do that with VMS.

Apples and oranges, I'm afraid. You could run early versions of
research Unix on PDP-11s, sure, but that's not really comparable
to VMS: VMS compares more closely to 4BSD, which would _not_ run
on a PDP-11.

- Dan C.

More than early research versions. Version 7 was
pretty complete. And then you had Ultrix-11 which
had a pretty good choice of production software
available to it.

What could you do on 4BSD that can't be done on 2.11?
Other than run programs too big to fit on a PDP-11.

bill

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

Comparing hardware to software.
You could run Unix on the VAX.
And EUNICE did exactly that. It was Unix on VMS.
kinda like what we do today with VM's but to far ahead for the
capabilities of the hardware.

And now, to the tune of Yellow Rose of Texas:

Hardware compared to software
Unix can run on the VAX.
And Eunice really does that
It's Unix on VMS..

--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <118cdvo$bh$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:

In article <EUiqS.3$GI1.2@fx01.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>Plus, Unix did run on a VAX, both BSD and a rather dodgy version

from AT&T (no paging, just swapping). I used the later circa 1981.

Other variations too, like BRL Unix from the Army Ballistics Research Lab >which was BSD with some radical modifications.

Unix was rather more fluid back in those days. :-)

Later versions of System V did grow demand paging; internally,
inside of AT&T, they had demand-paged, virtual memory support
before BSD, though I don't think that particular VM system made
it out of Bell labs; the 1127 guys chose to re-port 4.1BSD (or
thereabouts) as the basis for 8th Edition and later, but their
version was always rather different than what USG/USL were
doing.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <ngvfqgFiaqvU2@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

On 9/15/26 13:35, Dan Cross wrote:

In article <87h5jqpu4f.fsf@debian>,
Kragen Javier Sitaker <kragen@canonical.org> wrote:

bill <bill.gunshannon@gmail.com> writes:

On 6/29/2026 6:57 AM, Scott Dorsey wrote:

It did it very, very, very slowly.

Not necessarily EUNICE's fault. As I said in my response to Arne,
that was a time when software was too far ahead of hardware.

You could run Unix on a PDP-11. You couldnrCOt do that with VMS.

Apples and oranges, I'm afraid. You could run early versions of
research Unix on PDP-11s, sure, but that's not really comparable
to VMS: VMS compares more closely to 4BSD, which would _not_ run
on a PDP-11.

- Dan C.

More than early research versions. Version 7 was
pretty complete. And then you had Ultrix-11 which
had a pretty good choice of production software
available to it.

I consider pretty much everything up through and including 32/V
an "early version of Research unix." Sure, the system call
interface was ok, but there was no IPC to speak of beyond pipes
and multiplexed files, which never caught on (RIP Greg Chesson),
and the filesystem was pretty anemic, etc.

What could you do on 4BSD that can't be done on 2.11?
Other than run programs too big to fit on a PDP-11.

2.11 is also a bit of an unfair comparison; that was something
of a back-port of 4BSD back to the PDP-11. Certainly, a primary
motivation for moving to 32-bit paged memories was supporting
larger programs (part of the DARPA grant stuff was supporting
large Lisp systems on VAXen).

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <ngvficFiaqvU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

On 9/15/26 08:38, Kragen Javier Sitaker wrote:

bill <bill.gunshannon@gmail.com> writes:

On 6/29/2026 6:57 AM, Scott Dorsey wrote:

It did it very, very, very slowly.

Not necessarily EUNICE's fault. As I said in my response to Arne,
that was a time when software was too far ahead of hardware.

You could run Unix on a PDP-11. You couldnrCOt do that with VMS.

Comparing hardware to software.
You could run Unix on the VAX.
And EUNICE did exactly that. It was Unix on VMS.
kinda like what we do today with VM's but to far ahead for the
capabilities of the hardware.

Still, it was fun to try.

I interpreted the message you responded to as a bit of a dig on
VMS; as in, you could run Unix directly on both PDP-11 and VAX,
but VMS only ran on the VAX, thus Unix was more flexible or
portable.

My "Apples and Oranges" comment was highlighting that the
comparison isn't very good; at the time VMS was introduced,
contemporary Unix versions were comparatively primitive in how
they took advantage (or rather, did not take advantage) of the
hardware.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/15/26 08:39, Kragen Javier Sitaker wrote:

Bill, just FYI, we at LSSM recovered EUNICE v3.1 from tape a couple
of years ago, along with manuals. We've not tried to run it on
anything but we believe it to be a complete distribution.

ThatrCOs fantastic news! I don't suppose you can release it legally, can you?

Legally...maybe, maybe not. I've not researched the copyright
status. I'm guessing the company is long gone, though.

But at least it's not lost.

-Dave
--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-09-18, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

I interpreted the message you responded to as a bit of a dig on
VMS; as in, you could run Unix directly on both PDP-11 and VAX,
but VMS only ran on the VAX, thus Unix was more flexible or
portable.

My "Apples and Oranges" comment was highlighting that the
comparison isn't very good; at the time VMS was introduced,
contemporary Unix versions were comparatively primitive in how
they took advantage (or rather, did not take advantage) of the
hardware.

Also, think about the applications running on top of these
operating systems.

In the PDP-11 DEC OS world, if you wanted to run larger applications
(by the standards of the PDP-11, not the VAX), you were into TKB
overlays. [*] :-(

How did PDP-11 Unix handle this problem ?

Simon.

[*] This was a method, used during linking, in which you described an
overlay map, and the OS then mapped in and out various segments of your application at runtime as various parts of it were called by the rest
of the application.

The :-( is because I have direct personal experience of having to do
this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/24/26 14:27, Simon Clubley wrote:

On 2026-09-18, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

I interpreted the message you responded to as a bit of a dig on
VMS; as in, you could run Unix directly on both PDP-11 and VAX,
but VMS only ran on the VAX, thus Unix was more flexible or
portable.

My "Apples and Oranges" comment was highlighting that the
comparison isn't very good; at the time VMS was introduced,
contemporary Unix versions were comparatively primitive in how
they took advantage (or rather, did not take advantage) of the
hardware.

Also, think about the applications running on top of these
operating systems.

In the PDP-11 DEC OS world, if you wanted to run larger applications
(by the standards of the PDP-11, not the VAX), you were into TKB
overlays. [*] :-(

How did PDP-11 Unix handle this problem ?

Ultrix-11 had overlays. I always ran an overlayed kernel on most of my
bigger PPD-11's. But then, seems I had less trouble doing overlays than
other folks. :-)

Simon.

[*] This was a method, used during linking, in which you described an
overlay map, and the OS then mapped in and out various segments of your application at runtime as various parts of it were called by the rest
of the application.

The :-( is because I have direct personal experience of having to do
this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Never saw it as much of a problem. Actually helped a lot in making
more efficient programs.

bill


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-09-15 12:38:24 +0000, Kragen Javier Sitaker said:

You could run Unix on a PDP-11. You couldnrCOt do that with VMS.

Reality is a little weirder: you can VMS on a box that is also a PDP-11.

The -11 in VAX-11 indicates hardware PDP-11 support.

A large chunk of early VMS was RSX giblets.

SYE was one of the last remaining RSX giblets, last part of VMS V3.
--
Pure Personal Opinion | HoffmanLabs LLC

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/25/2026 5:57 AM, Stephen Hoffman wrote:

On 2026-09-15 12:38:24 +0000, Kragen Javier Sitaker said:

You could run Unix on a PDP-11.-a You couldnrCOt do that with VMS.

Reality is a little weirder: you can VMS on a box that is also a PDP-11.

The -11 in VAX-11 indicates hardware PDP-11 support.

A large chunk of early VMS was RSX giblets.

SYE was one of the last remaining RSX giblets, last part of VMS V3.

And now the same physical hardware runs OS/2 and VMS, sometimes both at
once. The world is really a strange place.
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 25 Sep 2026 12:25:07 +0800
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:

On 9/25/2026 5:57 AM, Stephen Hoffman wrote:

On 2026-09-15 12:38:24 +0000, Kragen Javier Sitaker said:

You could run Unix on a PDP-11.-a You couldnrCOt do that with VMS.

Reality is a little weirder: you can VMS on a box that is also a
PDP-11.

The -11 in VAX-11 indicates hardware PDP-11 support.

A large chunk of early VMS was RSX giblets.

SYE was one of the last remaining RSX giblets, last part of VMS V3.

And now the same physical hardware runs OS/2 and VMS, sometimes both
at once.

That's not particularly new.
We were running VMS, in supported manner, nonetheless, on OS/2 capable
hardware ~20 years. Not that anybody had a reason to try to run OS/2 on
this hardware, but it was technically possible.
Of course, VMS was running on top of Charon-VAX.
Even back then it was not considered a new tech or very exciting.

The world is really a strange place.

She said "Curiouser and curiouser!"
But only for those of us that are willing to be curious.
I am unfortuntely closer to less willing.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <1193q2b$2tr67$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2026-09-18, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

I interpreted the message you responded to as a bit of a dig on
VMS; as in, you could run Unix directly on both PDP-11 and VAX,
but VMS only ran on the VAX, thus Unix was more flexible or
portable.

My "Apples and Oranges" comment was highlighting that the
comparison isn't very good; at the time VMS was introduced,
contemporary Unix versions were comparatively primitive in how
they took advantage (or rather, did not take advantage) of the
hardware.

Also, think about the applications running on top of these
operating systems.

In the PDP-11 DEC OS world, if you wanted to run larger applications
(by the standards of the PDP-11, not the VAX), you were into TKB
overlays. [*] :-(

How did PDP-11 Unix handle this problem ?

PDP-11 Unix (well, I suppose 2BSD) supported overlays. From
what I was told, it "just worked" and was rather automatic, so
that it worked better than on the DEC OSes; I don't know whether
that is true or not, nor can I recall who said that to me, or
what their criteria was.

[*] This was a method, used during linking, in which you described an
overlay map, and the OS then mapped in and out various segments of your >application at runtime as various parts of it were called by the rest
of the application.

The :-( is because I have direct personal experience of having to do
this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Yeah, there's something to be said for large virtual address
spaces.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <nhlautF2k3mU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

[snip]

[*] This was a method, used during linking, in which you described an
overlay map, and the OS then mapped in and out various segments of your
application at runtime as various parts of it were called by the rest
of the application.

The :-( is because I have direct personal experience of having to do
this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Never saw it as much of a problem. Actually helped a lot in making
more efficient programs.

Efficient in what regard?

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/28/2026 10:49 AM, Dan Cross wrote:

In article <nhlautF2k3mU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

[snip]

[*] This was a method, used during linking, in which you described an
overlay map, and the OS then mapped in and out various segments of your
application at runtime as various parts of it were called by the rest
of the application.

The :-( is because I have direct personal experience of having to do
this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Never saw it as much of a problem. Actually helped a lot in making
more efficient programs.

Efficient in what regard?

- Dan C.

Not efficient!

I will allow that it can be educational. I learned to become very modular in my
work, in those days. A separate subprogram for every little operation. I still
like that type of design. Keeps things simple, and easy to identify issues.

But overlays are a thing best left in the past.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/28/26 10:49, Dan Cross wrote:

In article <nhlautF2k3mU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

[snip]

[*] This was a method, used during linking, in which you described an
overlay map, and the OS then mapped in and out various segments of your
application at runtime as various parts of it were called by the rest
of the application.

The :-( is because I have direct personal experience of having to do
this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Never saw it as much of a problem. Actually helped a lot in making
more efficient programs.

Efficient in what regard?

The programmer had to learn a bit more about his program in order
to make the overlays work properly and it kinda force you to look
at things like program flow and structure more closely. Another
facet of programming that has been lost in the age of Vibe Coding.

bill


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/28/26 13:12, Dave Froble wrote:

On 9/28/2026 10:49 AM, Dan Cross wrote:

In article <nhlautF2k3mU1@mid.individual.net>,
Bill Gunshannon-a <bill.gunshannon@gmail.com> wrote:

[snip]

[*] This was a method, used during linking, in which you described an
overlay map, and the OS then mapped in and out various segments of your >>>> application at runtime as various parts of it were called by the rest
of the application.

The :-( is because I have direct personal experience of having to do
this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Never saw it as much of a problem.-a Actually helped a lot in making
more efficient programs.

Efficient in what regard?

-a-a-a-a- Dan C.

Not efficient!

I will allow that it can be educational.-a I learned to become very
modular in my work, in those days.-a A separate subprogram for every
little operation.-a I still like that type of design.-a Keeps things
simple, and easy to identify issues.

But overlays are a thing best left in the past.

Except for those of us who still enjoy the wonders of the early
age of computing. :-)

bill


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <119e75n$2hsub$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:

On 9/28/2026 10:49 AM, Dan Cross wrote:

In article <nhlautF2k3mU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

[snip]

[*] This was a method, used during linking, in which you described an
overlay map, and the OS then mapped in and out various segments of your >>>> application at runtime as various parts of it were called by the rest
of the application.

The :-( is because I have direct personal experience of having to do
this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Never saw it as much of a problem. Actually helped a lot in making
more efficient programs.

Efficient in what regard?

Not efficient!

I will allow that it can be educational. I learned to become very modular in my
work, in those days. A separate subprogram for every little operation. I still
like that type of design. Keeps things simple, and easy to identify issues.

But overlays are a thing best left in the past.

Agreed on all counts.

I can certainly see overlays forcing the program to think more
critically about a program, but I can't imagine how the system
juggling overlays around in memory to compensate for a teeny
address space is efficient in terms of using the machine.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <nhvlnvFmcs4U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

On 9/28/26 10:49, Dan Cross wrote:

In article <nhlautF2k3mU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

[snip]

[*] This was a method, used during linking, in which you described an
overlay map, and the OS then mapped in and out various segments of your >>>> application at runtime as various parts of it were called by the rest
of the application.

The :-( is because I have direct personal experience of having to do
this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Never saw it as much of a problem. Actually helped a lot in making
more efficient programs.

Efficient in what regard?

The programmer had to learn a bit more about his program in order
to make the overlays work properly and it kinda force you to look
at things like program flow and structure more closely.

Ok, I get that, but that's not describing efficiency. Rather,
it is describing a programming process that forces engaging with
software on a deeper level, because otherwise, the program won't
run.

Another
facet of programming that has been lost in the age of Vibe Coding.

No argument there. LLMs can be useful, but only if you already
know what you're doing. If you don't, you're going to have a
bad time.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/28/26 20:45, Dan Cross wrote:

In article <nhvlnvFmcs4U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

On 9/28/26 10:49, Dan Cross wrote:

In article <nhlautF2k3mU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

[snip]

[*] This was a method, used during linking, in which you described an >>>>> overlay map, and the OS then mapped in and out various segments of your >>>>> application at runtime as various parts of it were called by the rest >>>>> of the application.

The :-( is because I have direct personal experience of having to do >>>>> this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Never saw it as much of a problem. Actually helped a lot in making
more efficient programs.

Efficient in what regard?

The programmer had to learn a bit more about his program in order
to make the overlays work properly and it kinda force you to look
at things like program flow and structure more closely.

Ok, I get that, but that's not describing efficiency. Rather,
it is describing a programming process that forces engaging with
software on a deeper level, because otherwise, the program won't
run.

I think the idea was enable more with less, due to the real limits
on hardware back in the day. Have used overlays on RT11 in the past,
and much later, 6 x 8k fixed lookup tables for an 8051 series
embedded project. A bit tortuous, but worked fine. Keil C for 8051
was great in that respect. A bit easier for the RT11 case, where an
8k data buffer was shared with temporarily unused code.

But yes, does make one think a lot more about design.

Another
facet of programming that has been lost in the age of Vibe Coding.

No argument there. LLMs can be useful, but only if you already
know what you're doing. If you don't, you're going to have a
bad time.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <119e75n$2hsub$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:

On 9/28/2026 10:49 AM, Dan Cross wrote:

In article <nhlautF2k3mU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

[snip]

[*] This was a method, used during linking, in which you described an >>>>> overlay map, and the OS then mapped in and out various segments of your >>>>> application at runtime as various parts of it were called by the rest >>>>> of the application.

The :-( is because I have direct personal experience of having to do >>>>> this multiple times... :-) Never, ever, ever, again. :-)

I was very glad to get to VAX and leave all that behind.

Never saw it as much of a problem. Actually helped a lot in making
more efficient programs.

Efficient in what regard?

Not efficient!

I will allow that it can be educational. I learned to become very modular in my
work, in those days. A separate subprogram for every little operation. I still
like that type of design. Keeps things simple, and easy to identify issues. >>
But overlays are a thing best left in the past.

Agreed on all counts.

I can certainly see overlays forcing the program to think more
critically about a program, but I can't imagine how the system
juggling overlays around in memory to compensate for a teeny
address space is efficient in terms of using the machine.

Overlays, in this context, are similar in overhead to
paging in modern virtual memory environments; albeit with
a variable "page" size with associated allocation issues
which sometimes required moving memory regions or rolling
them out to drum/disk/pack. The code couldn't be pure
as it wasn't re-entrant and passed parameters by
placing them inline in code immediately after an
NTR (subroutine call) or BCT (Branch Communicate to MCP)
instruction.

The Burroughs B3500 (1965) had a million digit (500 KB)
app address space, and overlays were common (and fully
supported syntactically by all the languages, including
COBOL) since the branch instructions could only reach
the first 99999 digits (100KB) due to the
most significant operand digit indicating
the optional index register to sum with the operand address
(fixed in the next generation, the B4700 by the extended
addressing feature).

The extended addressing feature allowed full data access
to the million digits, but still restricted branches to
the first 300,000 digits.

The B4800 MCP could be configured with a "quick pool" which
cached overlays in memory - worked really well in reducing
runtimes for heavily overlayed applications.

The MCP itself needed to fit in the first 300k digits
(150KB) of memory; it used overlays for most infrequently
used functionality. A portion of the quick pool
was reserved for frequently used MCP overlays.

MCP/VS 2.0 (Released in 1985) included a hardware
architecture update to support direct addressing
to millions of segments by an application without
the need to support overlays, although code files
from 1965 would still execute corrrectly.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-09-28, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <nhvlnvFmcs4U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:

The programmer had to learn a bit more about his program in order
to make the overlays work properly and it kinda force you to look
at things like program flow and structure more closely.

Ok, I get that, but that's not describing efficiency. Rather,
it is describing a programming process that forces engaging with
software on a deeper level, because otherwise, the program won't
run.

Agreed. If we were talking about programming languages, it's like
having to think with an assembly language mindset, instead of being
able to think with an higher-level more abstracted programming language mindset.

Another
facet of programming that has been lost in the age of Vibe Coding.

No argument there. LLMs can be useful, but only if you already
know what you're doing. If you don't, you're going to have a
bad time.

Oh, I _so_ agree. :-)

They have no understanding of the world they are describing.
Unfortunately, they are good at making the uninitiated think that
they do.

Reading between the lines, it appears that the current safety fuss
is less to do with safety and more to do with:

1) locking in the dominance of the current players in the market,
along with escaping liability for the actions of their products and

2) trying to stop investors from thinking that the current approaches
may not deliver on the initial "oh we can replace lots of people" and
related promises.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.22a-Linux NewsLink 1.2