VMS on Raspberry Pi 5

[Paul Hardy]

Just an FYI.

I recently ran VMS (5.5-2) as a VaxStation 3100M38 under OpenSimH on a
Raspberry Pi 5!.

I got VUPS rating of 30 or 31 from VUPs.com and VUPs2.com. Not bad on a
credit card sized computer for £60!

It ran a digital mapping application from the 1980s successfully, other
than a long-standing font corruption problem in the GPX device simulation.

Regards,

[Arne Vajhøj]

On 11/12/2023 3:41 PM, Paul Hardy wrote:
> I recently ran VMS (5.5-2) as a VaxStation 3100M38 under OpenSimH on a
> Raspberry Pi 5!.
>
> I got VUPS rating of 30 or 31 from VUPs.com and VUPs2.com. Not bad on a
> credit card sized computer for £60!

The IT world has evolved.

What would 30 780's have costed 45 years ago?

Arne

[The Natural Philosopher]

On 12/11/2023 20:41, Paul Hardy wrote:
>
>
> Just an FYI.
>
> I recently ran VMS (5.5-2) as a VaxStation 3100M38 under OpenSimH on a
> Raspberry Pi 5!.
>
> I got VUPS rating of 30 or 31 from VUPs.com and VUPs2.com. Not bad on a
> credit card sized computer for £60!
>

How does that compare with a real VAX or a PDP/11?
My impression of a Pi Zero is that it would knock a PDP/11 into the
middle of next week, and then some.

--
There is nothing a fleet of dispatchable nuclear power plants cannot do
that cannot be done worse and more expensively and with higher carbon
emissions and more adverse environmental impact by adding intermittent
renewable energy.

[Pancho]

On 12/11/2023 21:05, The Natural Philosopher wrote

> My impression of a Pi Zero is that it would knock a PDP/11 into the
> middle of next week, and then some.
>

Yeah, I would have expected 100s or 1000s of VUPS.

[Bob Eager]

On an emulator?

[Bob Eager]

On Sun, 12 Nov 2023 21:05:02 +0000, The Natural Philosopher wrote:

> On 12/11/2023 20:41, Paul Hardy wrote:
>>
>>
>> Just an FYI.
>>
>> I recently ran VMS (5.5-2) as a VaxStation 3100M38 under OpenSimH on a
>> Raspberry Pi 5!.
>>
>> I got VUPS rating of 30 or 31 from VUPs.com and VUPs2.com. Not bad on a
>> credit card sized computer for £60!
>>
>>
> How does that compare with a real VAX or a PDP/11?
> My impression of a Pi Zero is that it would knock a PDP/11 into the
> middle of next week, and then some.

A VAX 11/780 defined 1 VUP.

[Ahem A Rivet's Shot]

On Sun, 12 Nov 2023 21:05:02 +0000

The Natural Philosopher <t...@invalid.invalid> wrote:

> On 12/11/2023 20:41, Paul Hardy wrote:
> >
> >
> > Just an FYI.
> >
> > I recently ran VMS (5.5-2) as a VaxStation 3100M38 under OpenSimH on a
> > Raspberry Pi 5!.
> >
> > I got VUPS rating of 30 or 31 from VUPs.com and VUPs2.com. Not bad on a
> > credit card sized computer for £60!
> >
>
> How does that compare with a real VAX or a PDP/11?

One VUPS is supposed to be one original VAX CPU running VMS.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

[Ahem A Rivet's Shot]

Running native sure, but it's running a software emulated processor.

[56d.1152]

On 11/12/23 3:41 PM, Paul Hardy wrote:
>
>
> Just an FYI.
>
> I recently ran VMS (5.5-2) as a VaxStation 3100M38 under OpenSimH on a
> Raspberry Pi 5!.

Ok ... impressed !

> I got VUPS rating of 30 or 31 from VUPs.com and VUPs2.com. Not bad on a
> credit card sized computer for £60!
>
> It ran a digital mapping application from the 1980s successfully, other
> than a long-standing font corruption problem in the GPX device simulation.

I always liked VMS - well ahead of its time.
HOPING some basement-dwelling guru will create
a Pi-runnable version with some more "modern"
features added.

Hey, there's a Plan-9 for Pi ... there could be
a VMS as well !

BUT - where did you get the OS images ? They USED
to be available but the current owners pulled them
off the net years ago.

[Ahem A Rivet's Shot]

On Sun, 12 Nov 2023 22:48:31 -0500
"56d.1152" <56d....@ztq9.net> wrote:

> I always liked VMS - well ahead of its time.
> HOPING some basement-dwelling guru will create
> a Pi-runnable version with some more "modern"
> features added.
>
> Hey, there's a Plan-9 for Pi ... there could be
> a VMS as well !

Plan 9 was designed to be portable and released as source code. VMS
was designed for the VAX and while it has been ported to the PC the source
code has not been released. Any port to the Pi would have to be done by VMS
Software who make their money selling commercial VMS licenses.

[Pancho]

More than 30.

I don't really know the performance penalty of emulators. AIUI a lot of
the performance improvement of modern computers is due to software,
working with pipelines, predictive branching, etc. Processor clock is
only about 1000 times faster.

I first learnt of RISC when I was given a DECstation 3100 (Mips/Ultrix
not a VAXStation) to work on. Circa 1991. Much faster than VMS, but
already losing the battle to the PC.

[Arne Vajhøj]

On 11/13/2023 5:26 AM, Pancho wrote:
> On 12/11/2023 21:47, Bob Eager wrote:
>> On Sun, 12 Nov 2023 21:43:35 +0000, Pancho wrote:
>>
>>> On 12/11/2023 21:05, The Natural Philosopher wrote
>>>
>>>> My impression of a Pi Zero is that it would knock a PDP/11 into the
>>>> middle of next week, and then some.
>>>>
>>>>
>>> Yeah, I would have expected 100s or 1000s of VUPS.
>>
>> On an emulator?
>
> More than 30.
>
> I don't really know the performance penalty of emulators.

The overhead of a non-JIT instruction set emulation
must be huge.

Arne

[Bob Eager]

On Mon, 13 Nov 2023 10:26:30 +0000, Pancho wrote:

> On 12/11/2023 21:47, Bob Eager wrote:
>> On Sun, 12 Nov 2023 21:43:35 +0000, Pancho wrote:
>>
>>> On 12/11/2023 21:05, The Natural Philosopher wrote
>>>
>>>> My impression of a Pi Zero is that it would knock a PDP/11 into the
>>>> middle of next week, and then some.
>>>>
>>>>
>>> Yeah, I would have expected 100s or 1000s of VUPS.
>>
>> On an emulator?
>
> More than 30.

That's a more realistic figure, and what has been observed (by me).

[Scott Dorsey]

Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>
>> How does that compare with a real VAX or a PDP/11?
>
> One VUPS is supposed to be one original VAX CPU running VMS.

Right, so this is about a Vax 6000 or so, right?

Note that the Raspberry Pi has a whole lot more I/O bandwidth than
comparable 32-bit DEC systems, so the performance will actually be better
than the VUPS measurement would indicate.

Mind you, the I/O bandwidth on the vax systems was pretty pitiful and they
should never have discontinued the Decsystem-20....

But when the computer security people ask me to describe a raspberry pi,
I explain to them that it's about the performance of an old vax, except
that it fits in your shirt pocket.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Ahem A Rivet's Shot]

On 13 Nov 2023 16:26:19 -0000

klu...@panix.com (Scott Dorsey) wrote:

> But when the computer security people ask me to describe a raspberry pi,
> I explain to them that it's about the performance of an old vax, except
> that it fits in your shirt pocket.

More like the performance of an old Cray when it's running native
code.

[Charlie Gibbs]

Back in my Amiga days, I played with the Transformer, a
software emulation of an 8088 on a 68000. It would run
MS-DOS, but very slowly - I figured about a 10x slowdown.
Once just for giggles I ran Z80MU (a Z80 emulation for
MS-DOS) under the Transformer. Under these two levels
of emulation I fired up the CP/M BASIC interpreter and
typed "PRINT SIN(whatever)". It came back with the
correct answer - 7 seconds later.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgi...@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

[Chris Townley]

On 13/11/2023 17:32, Charlie Gibbs wrote:
> On 2023-11-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
>> On 11/13/2023 5:26 AM, Pancho wrote:
>>
>>> I don't really know the performance penalty of emulators.
>>
>> The overhead of a non-JIT instruction set emulation
>> must be huge.
>
> Back in my Amiga days, I played with the Transformer, a
> software emulation of an 8088 on a 68000. It would run
> MS-DOS, but very slowly - I figured about a 10x slowdown.
> Once just for giggles I ran Z80MU (a Z80 emulation for
> MS-DOS) under the Transformer. Under these two levels
> of emulation I fired up the CP/M BASIC interpreter and
> typed "PRINT SIN(whatever)". It came back with the
> correct answer - 7 seconds later.
>

That sounds like the Sinclair scientific calculator in the early 70s

--
Chris

[Pancho]

Observed figures are always more realistic, they are, after all, real.

Apparently, my rPi5 has arrived today, but I'm not going to test the
emulator. I'm happy to leave the VMS part of my life, in the past.

Looking back on it now. I think the strangest thing about VMS was the
Manual Set.

[Ahem A Rivet's Shot]

On Mon, 13 Nov 2023 17:32:45 GMT
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:

> Back in my Amiga days, I played with the Transformer, a
> software emulation of an 8088 on a 68000. It would run
> MS-DOS, but very slowly - I figured about a 10x slowdown.
> Once just for giggles I ran Z80MU (a Z80 emulation for
> MS-DOS) under the Transformer. Under these two levels
> of emulation I fired up the CP/M BASIC interpreter and
> typed "PRINT SIN(whatever)". It came back with the
> correct answer - 7 seconds later.

There's a PC emulation written in JavaScript that can boot Linux
(slowly). Presumably it would be possible to run Hercules in it and produce
a truly painfully slow mainframe emulation.

[Bob Eager]

On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:

> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>>
>>> How does that compare with a real VAX or a PDP/11?
>>
>> One VUPS is supposed to be one original VAX CPU running VMS.
>
> Right, so this is about a Vax 6000 or so, right?

No. Original VAX. An 11/780.

A VAX 6000 (one CPU) was about 7 VUPs, as I recall.

[Arne Vajhøj]

I think he meant that the VAX 6000 was about 30 VUPS.

It depends on what 6000. A 6n0 is 32 VUPS but a 4n0 is 7 VUPS.

Arne

[Bob Eager]

Is that a single CPU, as I stated?

[Martin Gregorie]

I had one of the really small 4 function calculators in 1975. IIRC it
wasn't all that slow (similar speed to a slide rule if each calculation
required both slide and cursor to be moved for each calculation) but its
main drawbacks was being really too small and fiddly, I used to be pretty
good with the mechanical, electrically driven FACIT desktop calculators
and I'd say the Sinclairs were just a little faster than those Facits.

However, I got an HP 21 (RPN0 calculator in 1977 and that was much faster
AND much stronger and better made: still have it and it still works, but
got an HP 21 (programmable too). That got replaced by an HP 28s in 1990
and is still in daily use.


--

Martin | martin at
Gregorie | gregorie dot org

[TimS]

On 13 Nov 2023 at 17:44:15 GMT, "Pancho" <Pancho...@proton.me> wrote:

> Looking back on it now. I think the strangest thing about VMS was the
> Manual Set.

Chap I shared an office with at SLAC back in the 80s was one of these
hoarders. We not only had the current set of VMS doc in the office, but the
complete previous set too, while he had the set before that in his garage at
home.

He was the sort of chap who, if you asked him for the 3-page doc that you'd
loaned him a month previously, could unerringly poke into the 3-foot high pile
(er, one of the piles, sorry), on his desk and pull it out straight away, with
zero search time. This made complaining about the paper piles futile. "Works
for me!"

--
Tim

[Martin Gregorie]

On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:

> Looking back on it now. I think the strangest thing about VMS was the
> Manual Set.

I was part of one, fairly large, project on VAX/VMS. I thought the oddest
part of it was the way the usual collection of programmer's utilities were
implemented as a handful of multi-function development tools, i.e. one
program that handled all source file management tasks, another to take
care of all comms tasks, etc. I've never met any other OS that was
structured that way.

Several years later I did another project on DEC Alpha Servers running
Tru64 UNIX, which I preferred to VMS, being a UNIX fanatic. Tru64 UNIXwas
pretty much a straight-forward port of UNIX System V functions and
programing tools onto a MACH-based kernel. This was amazingly fast for the
era and fairly bullet-proof.

[Chris Townley]

No this was the earlier scientific calculator, and a few years earlier.
When you pressed a function, the screen would go blank for about 7
seconds. |But at the time, and the price it was phenomenal!

--
Chris

[Scott Dorsey]

In article <krfh9m...@mid.individual.net>,

Bob Eager <news...@eager.cx> wrote:
>On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>
>> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>>>
>>>> How does that compare with a real VAX or a PDP/11?
>>>
>>> One VUPS is supposed to be one original VAX CPU running VMS.
>>
>> Right, so this is about a Vax 6000 or so, right?
>
>No. Original VAX. An 11/780.

That's one VUPS. But the Pi emulator is about thirty.

>A VAX 6000 (one CPU) was about 7 VUPs, as I recall.

Hmm, I remember it as being faster. Which machine was about 30 VUPS?

[Martin Gregorie]

Correction: the HP 21 is nor programmable but the HP 28S is.

[Arne Vajhøj]

Yes.

But VUPS benchmarks are usually/always single-threaded
so it would not run much faster with 6 CPU's. 6 CPU's
is 6 x 7 or 6 x 32 VUPS not 42 or 192 VUPS.

Arne

[Dave Froble]

On 11/13/2023 4:03 PM, Bob Eager wrote:

The 6000 used the NVAX, correct? On a VAXstation 4000 Model 90A I get 26-27
VUPS. I'd think the 6000 would be similar.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 11/13/2023 7:25 PM, Dave Froble wrote:
> On 11/13/2023 4:03 PM, Bob Eager wrote:
>> On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>>> Ahem A Rivet's Shot  <ste...@eircom.net> wrote:
>>>>>
>>>>> How does that compare with a real VAX or a PDP/11?
>>>>
>>>>     One VUPS is supposed to be one original VAX CPU running VMS.
>>>
>>> Right, so this is about a Vax 6000 or so, right?
>>
>> No. Original VAX. An 11/780.
>>
>> A VAX 6000 (one CPU) was about 7 VUPs, as I recall.
>
> The 6000 used the NVAX, correct?  On a VAXstation 4000 Model 90A I get
> 26-27 VUPS.  I'd think the 6000 would be similar.

Depends on what 6000.

200 models - 2.8
300 models - 3.9
400 models - 7
500 models - 13
600 models - 32

(1-6 CPU's)

Arne

[Martin Gregorie]

The HP21 came out in 1975 was functionally identical to the earlier HP35,
but was a bit smaller and using a different case design and runs off two
AA NiCd cells.

The HP28S came out in 1988 and is quite flat (160 x 90 x 19 mm) and runs
for around a year on a set of three N-batteries.

[56d.1152]

On 11/13/23 1:26 AM, Ahem A Rivet's Shot wrote:
> On Sun, 12 Nov 2023 22:48:31 -0500
> "56d.1152" <56d....@ztq9.net> wrote:
>
>> I always liked VMS - well ahead of its time.
>> HOPING some basement-dwelling guru will create
>> a Pi-runnable version with some more "modern"
>> features added.
>>
>> Hey, there's a Plan-9 for Pi ... there could be
>> a VMS as well !
>
> Plan 9 was designed to be portable and released as source code. VMS
> was designed for the VAX and while it has been ported to the PC the source
> code has not been released. Any port to the Pi would have to be done by VMS
> Software who make their money selling commercial VMS licenses.

Alas yes ........

Hmmmm - but WHO is buying such licenses, and for WHAT ???
VMS is allegedly WELL obsolete, yet they're making money
from ports.

Admittedly it will be difficult to separate VMS from the
hardware/peripherials it was written for. However if it
can be ported, more or less, to i86 then it should be less
of a prob to port THAT to ARM.

Plan-9 was writ to be "more portable". It is kinda hard to
deal with regardless of underlying hardware however. It was
intended for "distributed systems", not use on a single
box/processor, so you get that added complexity thrown in
for free.

There are some "ancient systems" that still see use. DOS
is one of them - compact/efficient and still fair for
embedded projects. CP/M derivs are also seen. OS9 is another -
and yes it's still developed and for-sale. Most of the
"big iron" systems from the 60s/70s went away however.
"Simplicity" seems to play a role in "longevity". VMS ...
well, it was REALLY GOOD ... so, somewhere, it's hanging
on - enough so people will PAY for it.

[Ahem A Rivet's Shot]

On Mon, 13 Nov 2023 23:02:11 -0500
"56d.1152" <56d....@ztq9.net> wrote:

> There are some "ancient systems" that still see use. DOS
> is one of them - compact/efficient and still fair for
> embedded projects. CP/M derivs are also seen. OS9 is another -
> and yes it's still developed and for-sale. Most of the
> "big iron" systems from the 60s/70s went away however.

Z/OS is still around and capable of running OS-360 binary
applications as well as more modern unix based systems.

[Johnny Billquist]

Depending on the instructions and data, the overhead is somewhere
between 10:1 to 100:1. In some extreme cases it can be way worse.

Johnny

[Johnny Billquist]

On 2023-11-14 00:40, Martin Gregorie wrote:
> On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:
>
>> Looking back on it now. I think the strangest thing about VMS was the
>> Manual Set.
>
> I was part of one, fairly large, project on VAX/VMS. I thought the oddest
> part of it was the way the usual collection of programmer's utilities were
> implemented as a handful of multi-function development tools, i.e. one
> program that handled all source file management tasks, another to take
> care of all comms tasks, etc. I've never met any other OS that was
> structured that way.

What other OSes do you have experience with?

Source management is usually handled by one single program, even on most
systems today. Be that cvs, svn, git or whatever.

And have you ever looked at find under Unix? That's a swiss army knife
if you ever saw one...

Johnny

[The Natural Philosopher]

No, that came back with the *wrong* answer...if it worked at all.


--
“But what a weak barrier is truth when it stands in the way of an
hypothesis!”

Mary Wollstonecraft

[Martin Gregorie]

On Tue, 14 Nov 2023 10:30:18 +0100, Johnny Billquist wrote:

> On 2023-11-14 00:40, Martin Gregorie wrote:
>> On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:
>>
>>> Looking back on it now. I think the strangest thing about VMS was the
>>> Manual Set.
>>
>> I was part of one, fairly large, project on VAX/VMS. I thought the
>> oddest part of it was the way the usual collection of programmer's
>> utilities were implemented as a handful of multi-function development
>> tools, i.e. one program that handled all source file management tasks,
>> another to take care of all comms tasks, etc. I've never met any other
>> OS that was structured that way.
>
> What other OSes do you have experience with?
>

ICL: UDAS, OLDAS, George 1`,2 and 3, VME/B
Stratus: VOS
IBM: OS/400
DEC: VAX/VMS, TruUNIX (Alpha server)
PC: DOS, Windows, Unix, RedHat Linux
6809, FLEX, OS/9
68000: OS/9 68000
Stratus: VOS
Tandem: Nonstop OS
RPI: Debian Linux
.

Source management is usually handled by one single program, even on most
> systems today. Be that cvs, svn, git or whatever.
>

Indeed, I used CVS for years, now using Git

> And have you ever looked at find under Unix? That's a swiss army knife
> if you ever saw one...
>

Use it a lot, also apropos,

[Arne Vajhøj]

On 11/14/2023 7:39 AM, Martin Gregorie wrote:
> On Tue, 14 Nov 2023 10:30:18 +0100, Johnny Billquist wrote:
>> Source management is usually handled by one single program, even on most
>> systems today. Be that cvs, svn, git or whatever.
>
> Indeed, I used CVS for years, now using Git

Last one among the common with separate executables was probably RCS.

But I really don't see the big difference between:

vcsname vcscommand ... running vcsname.exe

and

vcscommand ... running vcscommand.exe

Arne

[bill]

Do you mean Unix find or Gnu find? Gnu people lost track of the Unix
Paradigm long ago.

bill

[Dave Froble]

Well, when looking back, I'd think that one might remember the latest version of
any line of computers. For example, the VAXstation 4000 line had multiple
versions of the NVAX CPU, and the 90A I referenced was a later, but not the
latest, version. The model 96 was the last and best.

Not that I have any use for one, but I've always desired to acquire a MicroVAX
3100 model 98. Same CPU as the VAXstation 4000 model 96.

[Bob Eager]

That''s why I qualified my statement with "(one CPU)"

[Single Stage to Orbit]

On Tue, 2023-11-14 at 09:43 -0500, bill wrote:
> > Source management is usually handled by one single program, even on
> > most systems today. Be that cvs, svn, git or whatever.
> >
> > And have you ever looked at find under Unix? That's a swiss army
> > knife if you ever saw one...
> >
>
> Do you mean Unix find or Gnu find?  Gnu people lost track of the Unix
> Paradigm  long ago.

I'd have loved to have grep on VMS. I had to keep lookign through all
my directories to find what I needed. Does VMS have anything like this?

Many thanks,
Alex
--
Tactical Nuclear Kittens

[Arne Vajhøj]

Just to be sure that everybody agrees about numbers.

200/300/400/500/600 are generational models independent of number
of CPU's.

A 210 is a 200 model with 1 CPU. 1 x 2.8 VUPS.

A 420 is 400 model with 2 CPU's. 2 x 7 VUPS.

A 660 is a 600 model with 6 CPU's. 6 x 32 VUPS.

Arne

[Johnny Billquist]

On 2023-11-14 13:39, Martin Gregorie wrote:
> On Tue, 14 Nov 2023 10:30:18 +0100, Johnny Billquist wrote:
>
>> On 2023-11-14 00:40, Martin Gregorie wrote:
>>> On Mon, 13 Nov 2023 17:44:15 +0000, Pancho wrote:
>>>
>>>> Looking back on it now. I think the strangest thing about VMS was the
>>>> Manual Set.
>>>
>>> I was part of one, fairly large, project on VAX/VMS. I thought the
>>> oddest part of it was the way the usual collection of programmer's
>>> utilities were implemented as a handful of multi-function development
>>> tools, i.e. one program that handled all source file management tasks,
>>> another to take care of all comms tasks, etc. I've never met any other
>>> OS that was structured that way.
>>
>> What other OSes do you have experience with?
>>
> ICL: UDAS, OLDAS, George 1`,2 and 3, VME/B
> Stratus: VOS
> IBM: OS/400
> DEC: VAX/VMS, TruUNIX (Alpha server)
> PC: DOS, Windows, Unix, RedHat Linux
> 6809, FLEX, OS/9
> 68000: OS/9 68000
> Stratus: VOS
> Tandem: Nonstop OS
> RPI: Debian Linux

So in which way do you think VMS is so different than all of the above?
I only know a few of the ones you list, but I do know a bunch of others.
And to me, there is nothing I would say is strange, unique or even
special about how VMS does things.

It is a bit different than under Unix-like systems, since commands don't
necessarily have a 1:1 mapping to a binary. But apart from that, I fail
to see much of a difference.

And with alias for things, along with symlinks, Unix isn't really any
different there either.

> Source management is usually handled by one single program, even on most
>> systems today. Be that cvs, svn, git or whatever.
>>
> Indeed, I used CVS for years, now using Git
>
>> And have you ever looked at find under Unix? That's a swiss army knife
>> if you ever saw one...
>>
> Use it a lot, also apropos,

Well, apropos is just a simple tool for one thing. Which is just a way
to search man-pages. find on the other hand can be used for almost
anything, and the number of switches/options available is more than any
person can memorize. Admittedly, all the operations are related to
files, but then again, almost anything is a file under Unix. ;-)

Johnny

[Johnny Billquist]

With find it don't matter. Even the original is crazy. The one tool
where the Unix paradigm got completely lost...

GNU have indeed gone crazy with options to programs as well, I admit.
Not to mention the added craziness of Red Hat...

Johnny

[Johnny Billquist]

Good to point out. I'm getting the feeling people did not understand.

Johnny

[Ahem A Rivet's Shot]

On Tue, 14 Nov 2023 18:05:21 +0100
Johnny Billquist <b...@softjar.se> wrote:

> It is a bit different than under Unix-like systems, since commands don't
> necessarily have a 1:1 mapping to a binary.

Neither do unix commands (eg. ex and vi are the same binary as are
more and less) the extreme case is busybox, or indeed anything built with
crunchgen (such as almost the entire contents of /rescue on this FreeBSD
box). Then there are shell aliases and functions.

[Johnny Billquist]

On 2023-11-14 18:54, Ahem A Rivet's Shot wrote:
> On Tue, 14 Nov 2023 18:05:21 +0100
> Johnny Billquist <b...@softjar.se> wrote:
>
>> It is a bit different than under Unix-like systems, since commands don't
>> necessarily have a 1:1 mapping to a binary.
>
> Neither do unix commands (eg. ex and vi are the same binary as are
> more and less) the extreme case is busybox, or indeed anything built with
> crunchgen (such as almost the entire contents of /rescue on this FreeBSD
> box). Then there are shell aliases and functions.

Well, I would argue that there is a difference when you have the same
binary with different names. From a shell point of view, that's
completely separate commands, as basically commands are binaries, and
there is a 1:1 mapping there. But of course there are exceptions. Things
that deal with shell internal commands are all not related to any binary
at all, and as noted, aliases muddy the water way more.

And behind the scene you certainly have the fact that it might be the
same binary, and the way it behaves just depends on the content of argv[0].

But like I said - in the end I do not really think that VMS is any
different, and I was questioning Martin, who was the one saying that VMS
was so different.

Johnny

[sc...@alfter.diespammersdie.us]

In comp.sys.raspberry-pi Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> Back in my Amiga days, I played with the Transformer, a
> software emulation of an 8088 on a 68000. It would run
> MS-DOS, but very slowly - I figured about a 10x slowdown.
> Once just for giggles I ran Z80MU (a Z80 emulation for
> MS-DOS) under the Transformer. Under these two levels
> of emulation I fired up the CP/M BASIC interpreter and
> typed "PRINT SIN(whatever)". It came back with the
> correct answer - 7 seconds later.

...and I thought TI BASIC on the 99/4A was slow. :)

"Let's build a 16-bit computer...but hobble it with an 8-bit bus, and make
it access most of the available RAM through a one-byte window into memory
that's only directly attached to the video processor, and implement BASIC in
a pseudocode-like language that itself gets interpreted at runtime on the
CPU. What could possibly go wrong?"

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

[Martin Gregorie]

On Tue, 14 Nov 2023 18:05:21 +0100, Johnny Billquist wrote:

> So in which way do you think VMS is so different than all of the above?
>

Its been a long time, but as I already said,

VMS seemed to have a few portmanteau commands where the other OSen had a
host of single function commands. For instance, to access the equivalents
of the Unix commands rm, cp, less and ls under VAX/VMS you first logged in
(same as unix) but then you had to start a package (sorry, but I don't
remember its name) to access its own command line and then run the UNIX-
like comands.

That's stuck with me because no UNIX or Linux system works that way.and
logging to every other OS I've used has given immediate access to a
command line. The main deviation from this plot are IBM's OS/400 and ICL's
2900 series running under VME/B,

Both these have much more rational command naming systems than either
Unix/Linux or an excellent command look-up system: command names are so
regular and that's backed a special key that shows your full screen prompt
with help text and default parameter values already filled in and
mandatory ones left blank. Any Invalid parameters you enter are merely
flagged up ready for correction.

VME/B commands had two names, one abbreviated and a bit cryptic for direct
input to the command line and the other much longer and intended for use
in command scripts. For instance, 'x' always meant 'delete' and 'f' always
meant 'file', so the command to delete a file could be entered as either
"xf myfile" or as deletefile("myfile");

OS/400 is quire similar here, except that command and file names could
never be more than 9 characters long and so often appeared to like line
noise. For instance and there were no just three letter groups so:

crtrpgpgm is the RPG3 compiler (Create RPG program)
crtplipgm is the PL/1 compiler
crtcblpgm is the COBOL compiler

To OS/400 'rpg' means RPG and 'pgm' always means 'program,
ie once you understand the naming system, you can often
guess what a command would be called.

Also, both systems also had a 'search by name' ability that could be run
from the command line or from the text editor if you were editing a
command file.

The major failing of both OS is that neither had a hierarchic filing
system, such as both UNIX/Linux and Windows (and even DOS) provide.

I always thought this was odd, since George 3 had a hierarchical filing
system way back in 1970, when I first got my hands on it, but then again
VME/B and OS/400 (which AFAIK was a resurrected version of IBM's Future
Series which was killed off in about 1971) were first conceived somewhere
in the early 1970s, i.e. after MULTICS was up and running, and which DID
have a hierarchic filing system.

> And with alias for things, along with symlinks, Unix isn't really any
> different there either.
>

True enough, provided you exclude dinosaurs like S/360, AS/400, 2903s
(been there too, but its just an ICL 1900 emulator running on box
containing an ICL 2900 disk controller). Hierarchic filing systems as we
know then now, seem to have originated with MULTICS, and maybe the ICL
1900 George 3 OS (Manually operated 1900s and 2903/4 all had flat filing
systems like MSDOS, FLEX, etc).

My guess is that development of the 1900 and S/360 and all the other early
mainframes started just a bit too early for their designers to have seen
MULTICS and decided that hierarchic filing systems were the way to go.

> Well, apropos is just a simple tool for one thing. Which is just a way
> to search man-pages.
>

Sure, but I wouldn't be surprised to fins that 'apropos' is just a wrapper
round 'find'.

> find on the other hand can be used for almost anything
>

These days I mostly use 'locate' because its faster thanks to its
associated overnight index update, for anything a bit more complex, i.e.
with a bit of formatting included, 'awk / gawk' is my tool of choice.

[Arne Vajhøj]

On 11/14/2023 1:21 PM, Martin Gregorie wrote:
> Its been a long time, but as I already said,
>
> VMS seemed to have a few portmanteau commands where the other OSen had a
> host of single function commands. For instance, to access the equivalents
> of the Unix commands rm, cp, less and ls under VAX/VMS you first logged in
> (same as unix) but then you had to start a package (sorry, but I don't
> remember its name) to access its own command line and then run the UNIX-
> like comands.
>
> That's stuck with me because no UNIX or Linux system works that way.and
> logging to every other OS I've used has given immediate access to a
> command line.

Now I am confused.

If you login to VMS you have immediate access to DCL commands.

If you want to use *nix commands you need to start something
(very old Eunice, old posix or new GNV bash or something similar).

If you login to Linux you have immediate access to *nix
commands.

If you want to use DCL commands you need to start some
third party DCL implementation (Sector 7 ??).

What is the difference?

Arne

[bill]

On 11/14/2023 1:21 PM, Martin Gregorie wrote:

> On Tue, 14 Nov 2023 18:05:21 +0100, Johnny Billquist wrote:
>
>> So in which way do you think VMS is so different than all of the above?
>>
> Its been a long time, but as I already said,
>
> VMS seemed to have a few portmanteau commands where the other OSen had a
> host of single function commands. For instance, to access the equivalents
> of the Unix commands rm, cp, less and ls under VAX/VMS you first logged in
> (same as unix) but then you had to start a package (sorry, but I don't
> remember its name) to access its own command line and then run the UNIX-
> like comands.

Oh my god.... I think he is equating Eunice with VMS.....

:-)

bill

[Ahem A Rivet's Shot]

On Tue, 14 Nov 2023 18:09:05 +0100
Johnny Billquist <b...@softjar.se> wrote:

> With find it don't matter. Even the original is crazy. The one tool
> where the Unix paradigm got completely lost...

Not so sure about that - the one thing it does well is walk a
directory tree looking for matching entries. Arguable -exec wasn't needed
but perhaps it predated xargs.

[Jim Jackson]

On 2023-11-14, Johnny Billquist <b...@softjar.se> wrote:
>
> With find it don't matter. Even the original is crazy. The one tool
> where the Unix paradigm got completely lost...

I'm baffled by this.

find finds stuff in the filesystem that match some conditions.

What else does it do?

[Martin Gregorie]

On Tue, 14 Nov 2023 13:41:27 -0500, Arne Vajhøj wrote:

> On 11/14/2023 1:21 PM, Martin Gregorie wrote:
>> Its been a long time, but as I already said,
>>
>> VMS seemed to have a few portmanteau commands where the other OSen had
>> a host of single function commands. For instance, to access the
>> equivalents of the Unix commands rm, cp, less and ls under VAX/VMS you
>> first logged in (same as unix) but then you had to start a package
>> (sorry, but I don't remember its name) to access its own command line
>> and then run the UNIX- like comands.
>>
>> That's stuck with me because no UNIX or Linux system works that way.and
>> logging to every other OS I've used has given immediate access to a
>> command line.
>
> Now I am confused.
>
> If you login to VMS you have immediate access to DCL commands.
>

Its been a very long time (1990 or thereabouts and thats the only VAX-
based project I was on, but I distinctly remember that login gave you a
command line, but if you wanted to, say, get rid of old versions of a few
files you had to start a a portmanteau program that gave access to all the
file and directory manipulation functions via its own command line, and
once you'd done all that, toy exited from that program to get back to the
command line where logging in had left you.

> If you want to use *nix commands you need to start something (very old
> Eunice, old posix or new GNV bash or something similar).
>

At that time I'd not yet seen UNIX, but was familiar with a UNIX-like
command line, first for seven years (1970-77) on ICL's George 3 OS (1900
hardware) and then another three years (1978-1981) on ICL's VME/B OS (2960
hardware).

> If you login to Linux you have immediate access to *nix commands.
> If you want to use DCL commands you need to start some third party DCL
> implementation (Sector 7 ??).
>

Pass. While I'd been (amongst other things) a COBOL and assembler
programmer and George 3 sysadmin on ICL 1900 kit and designed and written
database systems on an ICL 2960 in COBOL using an IDMSX Codasyl database
system, I was just a database developer on the VAX system, so had no
knowledge of much about it apart from what I needed to write COBOL and
interface that with DEC's relational database system.

[Arne Vajhøj]

On 11/14/2023 3:10 PM, Martin Gregorie wrote:
> On Tue, 14 Nov 2023 13:41:27 -0500, Arne Vajhøj wrote:
>> On 11/14/2023 1:21 PM, Martin Gregorie wrote:
>>> VMS seemed to have a few portmanteau commands where the other OSen had
>>> a host of single function commands. For instance, to access the
>>> equivalents of the Unix commands rm, cp, less and ls under VAX/VMS you
>>> first logged in (same as unix) but then you had to start a package
>>> (sorry, but I don't remember its name) to access its own command line
>>> and then run the UNIX- like comands.
>>>
>>> That's stuck with me because no UNIX or Linux system works that way.and
>>> logging to every other OS I've used has given immediate access to a
>>> command line.
>>
>> Now I am confused.
>>
>> If you login to VMS you have immediate access to DCL commands.
>>
> Its been a very long time (1990 or thereabouts and thats the only VAX-
> based project I was on, but I distinctly remember that login gave you a
> command line, but if you wanted to, say, get rid of old versions of a few
> files you had to start a a portmanteau program that gave access to all the
> file and directory manipulation functions via its own command line, and
> once you'd done all that, toy exited from that program to get back to the
> command line where logging in had left you.

Sounds like a very custom setup. Back in the days various
captive scripts existed to limit users exposure to full DCL.
But most offered a menu system. And if not fully captive DCL
access was a menu item.

Usually you just login and issue DCL commands.

If you want to get rid of old versions of foobar.txt:

$ purge foobar.txt

> I was just a database developer on the VAX system, so had no
> knowledge of much about it apart from what I needed to write COBOL and
> interface that with DEC's relational database system.

VMS + Cobol + Rdb was a common combo - it is till used today.

Did you use embedded SQL or Rdb module feature?

Arne

[Charlie Gibbs]

On 2023-11-13, TimS <t...@streater.me.uk> wrote:

> On 13 Nov 2023 at 17:44:15 GMT, "Pancho" <Pancho...@proton.me> wrote:
>
>> Looking back on it now. I think the strangest thing about VMS was the
>> Manual Set.
>

> Chap I shared an office with at SLAC back in the 80s was one of these
> hoarders. We not only had the current set of VMS doc in the office, but the
> complete previous set too, while he had the set before that in his garage at
> home.

The one time I would hang on to old versions of manuals was when the
vendor decided there were things you no longer needed to know (e.g.
low-level I/O access), and deleted them from the new version.

> He was the sort of chap who, if you asked him for the 3-page doc that you'd
> loaned him a month previously, could unerringly poke into the 3-foot high pile
> (er, one of the piles, sorry), on his desk and pull it out straight away, with
> zero search time. This made complaining about the paper piles futile. "Works
> for me!"

I do this frighteningly often. Of course, the whole thing falls apart when
someone helpfully decides to "straighten things out".

I don't believe it!
There she goes again!
She's tidied up and I can't find anything!
-- Thomas Dolby: She Blinded Me with Science

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgi...@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

[druck]

On 13/11/2023 23:40, Martin Gregorie wrote:
> Several years later I did another project on DEC Alpha Servers running
> Tru64 UNIX, which I preferred to VMS, being a UNIX fanatic. Tru64 UNIXwas
> pretty much a straight-forward port of UNIX System V functions and
> programing tools onto a MACH-based kernel. This was amazingly fast for the
> era and fairly bullet-proof.

I loved the Alpha, if there was any justice in the world it would have
beaten the x86, but legal machinations and unexplicable madness
happened. But not before DEC sprinkled some of their Alpha magic on the
ARM to give us the StrongARM. Without which the architecture may not
have been as widely adopted and we wouldn't have the Pi. Of course being
wildly optimistic we could yet see ARM displacing x86, given the
traction ARM is gaining in the data centre and on the desktop with
Apple's M series - which was created by some of the design team of the
Alpha - what goes around, comes around!

---druck

[John Aldridge]

In article <uj0u59$1dlnh$1...@dont-email.me>, ne...@druck.org.uk says...

> I loved the Alpha, if there was any justice in the world it would have

> beaten the x86...

Yup. There was a lovely few months when the fastest x86 processor was
actually an Alpha running the FX!32 x86 emulator :)

--
John

[Martin Gregorie]

On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:

X> $ purge foobar.txt
>
Yes, I remember those periodic purges.

I did like the customisable editor too and, IIRD, the ability to attach
customisations to file types. If there was an open source version of that
editor I might even be using it still.

>> I was just a database developer on the VAX system, so had no
>> knowledge of much about it apart from what I needed to write COBOL and
>> interface that with DEC's relational database system.
>
>
> VMS + Cobol + Rdb was a common combo - it is till used today.
>

Worked well too - one of the better COBOL implementations

.
> Did you use embedded SQL or Rdb module feature?
>

The Rdb module.

The one real thumbs-down feature of the project, and the one that sank it,
was the bloody awful James Martin Associates system design method and its
almost equally poor diagramming rules. I mean, how can a usable Data
Structure Diagram ever be built when the overall system design rules
forbid you from adding any data items to entities but still let you insert
relationships between entities? Straight away this means you have:
(a) no way of verifying that the relationship is needed
(b) no way of validating end-to-end data flows through the system DSD.

IOW there's no way that you can verify the DSD, let alone get it reviewed
and signed off.

...and meanwhile we, the database design team, were never able to build
built a schema because the system designers never did hand us a usable DSD
to work from.

That surprised me because I'd bought a copy of James Martin's "Design of
Man-Computer Dialogs" - IMO one of the best books on application system
design I've ever seen. I bought my copy about ten years prior to that
fiasco and used it extensively when a small team of us were building BBC
Radio Three's music planning system: This was a complex system that had to
track and record every stage of building and broadcasting a concert from
the producer's original idea, checking that it wasn't too similar to any
other concert that would be broadcast around the target date, tracking and
booking all the performers and then, after the broadcast, making sure they
were paid as well as handling the repeat fees paid to performers if any
parts of a concert are rebroadcast later.

I doubt that this system, known as Orpheus, would have gone together half
so well without the ideas in that book,

For the record, it was built on an ICL 2966 mainframe, written in COBOL
and using IDMSX, a Codasyl database, as its data store. A BBC internal
team, with me as an external member, had completed that that about ten
years before the fiasco on the VAX.

IIRC there were even JMA consultants on the team that failed complete the
financial system on the VAX, but despite their presence, We never did get
a completed data structure to work from before the project collapsed.

[56d.1152]

On 11/14/23 2:09 AM, Ahem A Rivet's Shot wrote:
> On Mon, 13 Nov 2023 23:02:11 -0500
> "56d.1152" <56d....@ztq9.net> wrote:
>
>> There are some "ancient systems" that still see use. DOS
>> is one of them - compact/efficient and still fair for
>> embedded projects. CP/M derivs are also seen. OS9 is another -
>> and yes it's still developed and for-sale. Most of the
>> "big iron" systems from the 60s/70s went away however.
>
> Z/OS is still around and capable of running OS-360 binary
> applications as well as more modern unix based systems.


Had forgotten about Z/OS ... a bit out of my
price range at this point alas :-)

Most of those old Big Iron systems were very
well designed. No reason to completely throw
them away. Unix is rather "aged" these days
too - but it's still an inspired model, still
suited to build upon.

There's still a market for mainframes. McDonalds
Corp does NOT run on a iPad. Worldwide biz,
supply/financial logistics, soon you're using
SERIOUS computing power and need a SERIOUS
super-reliable/flexible OS to make it go. Wire a
few of those big black IBM boxes together .....

If VMS has a future, it's going to start with
those sorts of uses.

[56d.1152]

On 11/14/23 4:27 PM, Charlie Gibbs wrote:
> On 2023-11-13, TimS <t...@streater.me.uk> wrote:
>
>> On 13 Nov 2023 at 17:44:15 GMT, "Pancho" <Pancho...@proton.me> wrote:
>>
>>> Looking back on it now. I think the strangest thing about VMS was the
>>> Manual Set.
>>
>> Chap I shared an office with at SLAC back in the 80s was one of these
>> hoarders. We not only had the current set of VMS doc in the office, but the
>> complete previous set too, while he had the set before that in his garage at
>> home.
>
> The one time I would hang on to old versions of manuals was when the
> vendor decided there were things you no longer needed to know (e.g.
> low-level I/O access), and deleted them from the new version.
>
>> He was the sort of chap who, if you asked him for the 3-page doc that you'd
>> loaned him a month previously, could unerringly poke into the 3-foot high pile
>> (er, one of the piles, sorry), on his desk and pull it out straight away, with
>> zero search time. This made complaining about the paper piles futile. "Works
>> for me!"
>
> I do this frighteningly often. Of course, the whole thing falls apart when
> someone helpfully decides to "straighten things out".

Heh, heh ... I didn't let them "straighten out" anything
for nearly 40 years. Found a floppy set of Windows For
Workgroups the other day - KNEW I had those SOMEWHERE :-)

I'll have to see if I can install them on VirtualBox ...

Found a photo of my office done over 20 years ago ...
a lot of the same books still on the shelf.

Got my MS Access 1.x manual, my Turbo Pascal v1 manual
and IBM/MS Pascal manual. A 300 page VMS manual, a
VIC-20 programming guide, several books on PICs back when
the 16x series was top of the line. Lots of electronics
books, some of which include vacuum tube diagrams that
parallel the "newfangled" transistor circuits. Even
have an IBM-PC Technical Reference Manual (with all those
things "you don't need to know" ....

In any case, I practice the "archeological" filing
method ... older = deeper in the piles :-)

[Pancho]

On 14/11/2023 23:58, Martin Gregorie wrote:
> On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:
>
> X> $ purge foobar.txt
>>
> Yes, I remember those periodic purges.
>
> I did like the customisable editor too and, IIRD, the ability to attach
> customisations to file types. If there was an open source version of that
> editor I might even be using it still.
>

If you mean EVE based on Vax/TPU it was ported to Unix, circa ~1995,
SunOS, or possibly Solaris. So it is possible there is a version
floating about.

[Ahem A Rivet's Shot]

On Tue, 14 Nov 2023 22:31:20 -0500
"56d.1152" <56d....@ztq9.net> wrote:

> There's still a market for mainframes. McDonalds
> Corp does NOT run on a iPad. Worldwide biz,
> supply/financial logistics, soon you're using
> SERIOUS computing power and need a SERIOUS
> super-reliable/flexible OS to make it go. Wire a
> few of those big black IBM boxes together .....

I don't know about McDonald's but these days a lot of really big
systems run as a large (and variable) number of micro-services in
containers under Kubernetes. Scalability is the watchword today. Sometimes
they run on Z/OS machines (usually running Linux) otherwise they run on a
mix of blade servers (CPU and RAM tightly packed) and SAN storage (lots of
NVMe SSDs) connected with 40Gb or 100Gb ethernet. Infrastructure as a
service they call it.

[Ahem A Rivet's Shot]

Apparently there's an emulation of EVE available for Emacs.

[Arne Vajhøj]

On 11/15/2023 2:44 AM, Ahem A Rivet's Shot wrote:
> On Tue, 14 Nov 2023 22:31:20 -0500
> "56d.1152" <56d....@ztq9.net> wrote:
>> There's still a market for mainframes. McDonalds
>> Corp does NOT run on a iPad. Worldwide biz,
>> supply/financial logistics, soon you're using
>> SERIOUS computing power and need a SERIOUS
>> super-reliable/flexible OS to make it go. Wire a
>> few of those big black IBM boxes together .....
>
> I don't know about McDonald's but these days a lot of really big
> systems run as a large (and variable) number of micro-services in
> containers under Kubernetes. Scalability is the watchword today. Sometimes
> they run on Z/OS machines (usually running Linux) otherwise they run on a
> mix of blade servers (CPU and RAM tightly packed) and SAN storage (lots of
> NVMe SSDs) connected with 40Gb or 100Gb ethernet. Infrastructure as a
> service they call it.

Most run such workloads in AWS/Azure/GCP/OCI.

Arne

[Arne Vajhøj]

On 11/15/2023 3:18 AM, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 07:58:47 +0000
> Pancho <Pancho...@proton.me> wrote:
>> On 14/11/2023 23:58, Martin Gregorie wrote:
>>> I did like the customisable editor too and, IIRD, the ability to attach
>>> customisations to file types. If there was an open source version of
>>> that editor I might even be using it still.
>>>
>>
>> If you mean EVE based on Vax/TPU it was ported to Unix, circa ~1995,
>> SunOS, or possibly Solaris. So it is possible there is a version
>> floating about.

There was also nuTPU for PC. Was as in "35 years ago". I don't think
they exist anymore.

> Apparently there's an emulation of EVE available for Emacs.

EVE <> TPU

Mapping EVE keyboard definition in Emacs should be piece of cake.

Getting TPU code interpreted in Emacs is a different thing. TPU
is Pascal like not Lisp like. :-)

Arne

[Johnny Billquist]

Well, the question is - what does it do beyond walking the file system.
Because it don't stop there.
But first of all, it can walk the file system in different ways, and it
can do selections while walking the file systems in myriads of ways.
But then when it does match things, it can do all kind of stuff.
Do you even understand how to use "prune" for example? If you do, try it
and see if it actually gives the result you expect. (Yes, it is possible
to use in the way one thinks, but it's not trivial to understand how it
can be used.)

But in the end, find can then run any arbitrary command, might not even
be related to the files matched, but you can also make it run commands
with the matching file name put into the command line.

Johnny

[Jim Jackson]

Yes it can ANOTHER command, big deal - vi is an editor and you can run
a command from it, so what.

As I said above find finds stuff in the filesystem that match some conditions.
The fact that the filesystem is complex, so the condition matching is
complex is by-the-by.

Find does one thing and does it well.

[Ahem A Rivet's Shot]

Of course, these environments are built for that purpose and allow
the systems developers to assume the Kubernetes infrastructure without
having to maintain it. But it is possible to run such workloads in a
private data centre - "TrueNAS Scale" is one fairly easy way.

[Johnny Billquist]

Well. I don't fully agree with that, but I'm fine with just disagreeing
without getting into any further discussions. I can certainly dig up
other tools under Unix which left the "unix paradigm" behind a long time
ago, if you want.

COPY under VMS only does one thing as well, which is just copying files.
So I still do not think VMS is really much different from Unix. The OP
seems to have been using VMS with some additional layer which conflated
the view, and don't really expose how one normally interacts with VMS.
And that twisted experiece seems to have been the reason for the comment
to start with. So I think we can lay this whole thread down.

Johnny

[Ahem A Rivet's Shot]

On Wed, 15 Nov 2023 16:59:23 +0100
Johnny Billquist <b...@softjar.se> wrote:

> Well. I don't fully agree with that, but I'm fine with just disagreeing
> without getting into any further discussions. I can certainly dig up
> other tools under Unix which left the "unix paradigm" behind a long time
> ago, if you want.

Emacs springs to mind.

[Richard Kettlewell]

Ahem A Rivet's Shot <ste...@eircom.net> writes:
> Johnny Billquist <b...@softjar.se> wrote:
>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>> without getting into any further discussions. I can certainly dig up
>> other tools under Unix which left the "unix paradigm" behind a long time
>> ago, if you want.
>
> Emacs springs to mind.

Originated outside Unix, I think.

dd seems like a good example. Present at least as far back as V5 Unix
but its interface is belligerently different from any other Unix tool,
and it’s at best an uneasy fit with the “do one thing well” approach of
many of its siblings.

--
https://www.greenend.org.uk/rjk/

[Rich Alderson]

Ahem A Rivet's Shot <ste...@eircom.net> writes:

> On Wed, 15 Nov 2023 16:59:23 +0100
> Johnny Billquist <b...@softjar.se> wrote:

>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>> without getting into any further discussions. I can certainly dig up
>> other tools under Unix which left the "unix paradigm" behind a long time
>> ago, if you want.

> Emacs springs to mind.

Emacs is not a native Unix program.

It originated as a library of functions written in an enhanced TECO for the
PDP-10 that ran under ITS (MIT), TENEX (BBN), and TOPS-20 (TENEX with the
serial numbers filed off by DEC).

It was ported to an MIT dialect of LISP running under Multics, then versions
for the MIT inspired Lisp machines came along.

The C ports (including GNU) hark back to these Lisp versions.

So there's no reason to expect Emacs to be a Unix style program.

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[Rich Alderson]

Richard Kettlewell <inv...@invalid.invalid> writes:

> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>> Johnny Billquist <b...@softjar.se> wrote:
>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>>> without getting into any further discussions. I can certainly dig up
>>> other tools under Unix which left the "unix paradigm" behind a long time
>>> ago, if you want.

>> Emacs springs to mind.
>
> Originated outside Unix, I think.

Indeed.

> dd seems like a good example. Present at least as far back as V5 Unix
> but its interface is belligerently different from any other Unix tool,
> and it's at best an uneasy fit with the "do one thing well" approach of
> many of its siblings.

dd was intentionally designed to mimic the behavior of OS/360 Job Control
Language's Data Definition (DD) cards. It does that thing, and that thing
only, very well.

So dd has the Unix Nature (R).

[Johnny Billquist]

On 2023-11-15 17:06, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 16:59:23 +0100
> Johnny Billquist <b...@softjar.se> wrote:
>
>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>> without getting into any further discussions. I can certainly dig up
>> other tools under Unix which left the "unix paradigm" behind a long time
>> ago, if you want.
>
> Emacs springs to mind.

Well - Emacs don't really come from the Unix world to start with...

But systemd always comes to my mind...

Johnny

[Johnny Billquist]

On 2023-11-15 18:04, Richard Kettlewell wrote:
> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>> Johnny Billquist <b...@softjar.se> wrote:
>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>>> without getting into any further discussions. I can certainly dig up
>>> other tools under Unix which left the "unix paradigm" behind a long time
>>> ago, if you want.
>>
>> Emacs springs to mind.
>
> Originated outside Unix, I think.

Yes. PDP-10s. If it was ITS or TOPS-20 at the start, I dare not say.
Written in TECO.

> dd seems like a good example. Present at least as far back as V5 Unix
> but its interface is belligerently different from any other Unix tool,
> and it’s at best an uneasy fit with the “do one thing well” approach of
> many of its siblings.

I have some recollection that dd's interface comes from something like
IBMs OS/360. But I could be very wrong on that one.

Johnny

[bill]

On 11/15/2023 11:06 AM, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 16:59:23 +0100
> Johnny Billquist <b...@softjar.se> wrote:
>
>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>> without getting into any further discussions. I can certainly dig up
>> other tools under Unix which left the "unix paradigm" behind a long time
>> ago, if you want.
>
> Emacs springs to mind.
>

Emacs has nothing to do with Unix other than the fact that
someone ported it late in the game.

bill

[druck]

On 14/11/2023 09:30, Johnny Billquist wrote:
> Source management is usually handled by one single program, even on most
> systems today. Be that cvs, svn, git or whatever.

git is actually a collection of programs, when you run

git command args

it actually runs

git-command args

You can even write your own git utilities, call them git-something and
put them on PATH, and they will run when you do

git something

---druck

[TimS]

On 15 Nov 2023 at 20:49:52 GMT, "Rich Alderson"

<ne...@alderson.users.panix.com> wrote:

> So there's no reason to expect Emacs to be a Unix style program.

I don't expect Emacs any more than I expect the Spanish Inquisition.

--
Tim

[TimS]

On 15 Nov 2023 at 20:59:37 GMT, "Johnny Billquist" <b...@softjar.se> wrote:

> On 2023-11-15 18:04, Richard Kettlewell wrote:
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>> Johnny Billquist <b...@softjar.se> wrote:
>>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>>>> without getting into any further discussions. I can certainly dig up
>>>> other tools under Unix which left the "unix paradigm" behind a long time
>>>> ago, if you want.
>>>
>>> Emacs springs to mind.
>>
>> Originated outside Unix, I think.
>
> Yes. PDP-10s. If it was ITS or TOPS-20 at the start, I dare not say.
> Written in TECO.

In commands that look like line-noise.

>> dd seems like a good example. Present at least as far back as V5 Unix
>> but its interface is belligerently different from any other Unix tool,
>> and it’s at best an uneasy fit with the “do one thing well” approach of
>> many of its siblings.
>
> I have some recollection that dd's interface comes from something like
> IBMs OS/360. But I could be very wrong on that one.

Fortunately I was able to avoid that.

--
Tim

[Ahem A Rivet's Shot]

True - Teco editing macros originally.

> But systemd always comes to my mind...

I try not to let it <shudder> - anyway that's a Linux thing not seen
on any other unix (it's one reason I tend to avoid Linux). Apparently it's
not even remotely portable.

[Johnny Billquist]

Nobody...

Johnny

[Johnny Billquist]

On 2023-11-15 22:44, TimS wrote:
> On 15 Nov 2023 at 20:59:37 GMT, "Johnny Billquist" <b...@softjar.se> wrote:
>
>> On 2023-11-15 18:04, Richard Kettlewell wrote:
>>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>>> Johnny Billquist <b...@softjar.se> wrote:
>>>>> Well. I don't fully agree with that, but I'm fine with just disagreeing
>>>>> without getting into any further discussions. I can certainly dig up
>>>>> other tools under Unix which left the "unix paradigm" behind a long time
>>>>> ago, if you want.
>>>>
>>>> Emacs springs to mind.
>>>
>>> Originated outside Unix, I think.
>>
>> Yes. PDP-10s. If it was ITS or TOPS-20 at the start, I dare not say.
>> Written in TECO.
>
> In commands that look like line-noise.

It has been described as a write-only language. Not undeservedly.

That said - I do like to use TECO once in a while. It's still a pretty
good tool.

Johnny

[Johnny Billquist]

On 2023-11-15 22:34, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 21:57:45 +0100
> Johnny Billquist <b...@softjar.se> wrote:
>
>> But systemd always comes to my mind...
>
> I try not to let it <shudder> - anyway that's a Linux thing not seen
> on any other unix (it's one reason I tend to avoid Linux). Apparently it's
> not even remotely portable.

Yeah. It's a monster. And tries to do all kind if stuff. Talk about
breaking the Unix paradigm...

Yes, I try to avoid Linux myself as well.

Johnny

[Johnny Billquist]

Yes. Some extensions are done that way. But the git binary itself is
reponsible for the most core things, like committing, pushing, pulling...

So no, there is no git-pull, no git-add, no git-merge and so on. But
there are some git-<command> binaries.

Maybe you could possibly call git a hybrid in this context.

Johnny

[Scott Dorsey]

In article <uj1tno$1lkjn$1...@dont-email.me>,

It wasn't so much ported as rewritten from the bottom up when the
folks at Boston Business Computing released nu/TPU which was a
TPU-compatible package. It works really well, too.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Richard Kettlewell]

druck <ne...@druck.org.uk> writes:
> Johnny Billquist wrote:
>> Source management is usually handled by one single program, even on
>> most systems today. Be that cvs, svn, git or whatever.
>
> git is actually a collection of programs, when you run
>
> git command args
>
> it actually runs
>
> git-command args

Might have been once, but not any more.

$ strace -etrace=execve -f git clone whatever
execve("/usr/bin/git", ["git", "clone", "whatever"], 0x7fffeebfa9e0 /* 54 vars */) = 0
fatal: repository 'whatever' does not exist
+++ exited with 128 +++

> You can even write your own git utilities, call them git-something and
> put them on PATH, and they will run when you do
>
> git something

I think that remains true.

--
https://www.greenend.org.uk/rjk/

[bill]

I use Linux. As a desktop just like I use Windows.
For real computing I use real OSes. :-)

bill

[Single Stage to Orbit]

On Wed, 2023-11-15 at 21:34 +0000, Ahem A Rivet's Shot wrote:
> > But systemd always comes to my mind...
>
>         I try not to let it <shudder> - anyway that's a Linux thing
> not seen on any other unix (it's one reason I tend to avoid Linux).
> Apparently it's not even remotely portable.

I've banned systemd from all my Linux systems. Some things should not
exist. This is one of them.
--
Tactical Nuclear Kittens

[Single Stage to Orbit]

[Chris Townley]

Is nu/TPU still available anywhere. Sector 7 web site doesn't give any
details, except that another produced it and the company that I found a
link to elsewhere seemed to be no more

--
Chris

[Ahem A Rivet's Shot]

On Wed, 15 Nov 2023 18:51:53 -0500
bill <bill.gu...@gmail.com> wrote:

> I use Linux. As a desktop just like I use Windows.

I use FreeBSD and MacOS for desktops.

> For real computing I use real OSes. :-)

For real computing I use FreeBSD.

[56d.1152]

On 11/15/23 9:43 AM, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 08:06:00 -0500
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
>> On 11/15/2023 2:44 AM, Ahem A Rivet's Shot wrote:
>
>>> I don't know about McDonald's but these days a lot of really big
>>> systems run as a large (and variable) number of micro-services in
>>> containers under Kubernetes. Scalability is the watchword today.
>>> Sometimes they run on Z/OS machines (usually running Linux) otherwise
>>> they run on a mix of blade servers (CPU and RAM tightly packed) and SAN
>>> storage (lots of NVMe SSDs) connected with 40Gb or 100Gb ethernet.
>>> Infrastructure as a service they call it.
>>
>> Most run such workloads in AWS/Azure/GCP/OCI.
>
> Of course, these environments are built for that purpose and allow
> the systems developers to assume the Kubernetes infrastructure without
> having to maintain it. But it is possible to run such workloads in a
> private data centre - "TrueNAS Scale" is one fairly easy way.

Sorry, but McDonalds Corporate, BOA, US Mil, etc ... they
are NOT gonna work on Docker or Kubernetes on a bunch of
tablets. IBM didn't pay big for RHEL to run it on laptops,
but on its mainframes ......

Decentralized usually = SLOW ... and INSECURE ... despite
claims.

[56d.1152]

Now, now .... systemd *does* have some good
uses. The downside is that how/what it does
is a bit ... well ... complicated. Not AS bad
as the Winders registry, but getting there.

I like it because it'll monitor/restart daemons
and start them at the right phase of things. Sure,
you CAN do that all yourself, but, now, WHY ?

OTOH I'll not knock those who stick with the old
methods - those work too and are WELL documented
and versatile.

These are two APPROACHES to a number of common
issues. Neither is 'evil', neither is 'wrong'.

As for Linux/Unix though - THE issue is the
"library version problem". I've seen NO good
fixes for that. It's becoming a serious prob.
I think it's the reason we're seeing more and
more apps appearing as executables rather than
as typical linix/unix "packages/ports".

Hate to say it, but I
*encourage* this - after an experience trying
to install an alt version of FFMPEG, the
"requires" tree was just TOO damned much, TOO
damned destructive. Gimme something compiled
with all it needs built right in rather than
trying to compile from scratch with no slack
in *exactly* what it expects to be co-installed.

In this respect Winders IS actually "better".
Hell, through XP/Vista I could still run ANCIENT
apps, No Problem. The main prob became not
Winders, but Intel dropping 8/16

[Ahem A Rivet's Shot]

On Thu, 16 Nov 2023 01:13:21 -0500
"56d.1152" <56d....@ztq9.net> wrote:

> Now, now .... systemd *does* have some good
> uses. The downside is that how/what it does
> is a bit ... well ... complicated. Not AS bad
> as the Winders registry, but getting there.
>
> I like it because it'll monitor/restart daemons
> and start them at the right phase of things. Sure,
> you CAN do that all yourself, but, now, WHY ?

BSD rc plus daemontools does everything I have ever needed in that
regard - granted SysV rc is a mess.

> As for Linux/Unix though - THE issue is the
> "library version problem". I've seen NO good
> fixes for that. It's becoming a serious prob.

FreeBSD ports and NetBSD pkgsrc both work well. I've not had a
library version issue in a *long* time - except at work where I have to
deal with Linux.

[Ahem A Rivet's Shot]

On Thu, 16 Nov 2023 00:47:55 -0500
"56d.1152" <56d....@ztq9.net> wrote:

> On 11/15/23 9:43 AM, Ahem A Rivet's Shot wrote:
> > On Wed, 15 Nov 2023 08:06:00 -0500

> > Of course, these environments are built for that purpose and
> > allow the systems developers to assume the Kubernetes infrastructure
> > without having to maintain it. But it is possible to run such workloads
> > in a private data centre - "TrueNAS Scale" is one fairly easy way.
>
> Sorry, but McDonalds Corporate, BOA, US Mil, etc ... they
> are NOT gonna work on Docker or Kubernetes on a bunch of
> tablets.

No most corporate use of Kubernetes is on data centres full of
blades, NVMe based SANs, NetApps and Isilon clusters. This is the world
that pays my wages - I know how big it is and who uses it, including
outfits the size you're talking about, many of them are customers of my
current and previous employers.

> IBM didn't pay big for RHEL to run it on laptops,
> but on its mainframes ......

Yes they are popular with banks and the like because they *also*
run their old OS-360 stuff without recompiling it, but to anyone who
doesn't need that they are very expensive for little gain. Guess what many
of their customers run in the RHEL environments - yep kubernetes and docker.

> Decentralized usually = SLOW ... and INSECURE ... despite
> claims.

Tell that to Amazon, Google etc. look into the architecture of
Amazon Dynamo and marvel at the way it scales and handles machine failures
and network outages. Mainframes are great up to a point, right up until you
can't get one big enough and then you *need* a scalable solution.
kubernetes is an easy way to get one.

I was involved in doing it the hard way back in 1990 when the UK
Inland Revenue had a problem their ICL mainframe team declared impossible,
twenty high end 88k boxes and a distributed architecture made it possible.
No mainframe could match the IO bandwidth or CPU power of that solution,
using it effectively took careful design.

SAAS is huge in the large corporate world, it all runs on
virtual machines and docker containers orchestrated by kubernetes. It's
only insecure if you don't know how to secure it, the most security
sensitive run it all in their own datacentres on hypervisors that they
control. The rest trust the contractual obligations of the companies that
run the data centres (Microsoft, Google and Amazon mostly).

The big trend in large users these days is micro-services in docker
containers. Instead of an OS image running in the container there is only
the application and support libraries running on bare virtual metal.

[Bob Eager]

On Thu, 16 Nov 2023 01:22:45 +0000, Ahem A Rivet's Shot wrote:

> On Wed, 15 Nov 2023 18:51:53 -0500 bill <bill.gu...@gmail.com>
> wrote:
>
>> I use Linux. As a desktop just like I use Windows.
>
> I use FreeBSD and MacOS for desktops.
>
>> For real computing I use real OSes. :-)
>
> For real computing I use FreeBSD.

+1

[Pancho]

On 15/11/2023 23:51, bill wrote:

>
> I use Linux.  As a desktop just like I use Windows.
> For real computing I use real OSes.  :-)
>

For any computing, I like to have good driver support.

For real computing, I use Docker.