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!
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!
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 theYeah, I would have expected 100s or 1000s of VUPS.
middle of next week, and then some.
My impression of a Pi Zero is that it would knock a PDP/11 into the
middle of next week, and then some.
On 12/11/2023 20:41, Paul Hardy wrote:
How does that compare with a real VAX or a PDP/11?
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!
My impression of a Pi Zero is that it would knock a PDP/11 into the
middle of next week, and then some.
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?
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.
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.
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 !
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 theYeah, I would have expected 100s or 1000s of VUPS.
middle of next week, and then some.
On an emulator?
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 theYeah, I would have expected 100s or 1000s of VUPS.
middle of next week, and then some.
On an emulator?
More than 30.
I don't really know the performance penalty of emulators.
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 theYeah, I would have expected 100s or 1000s of VUPS.
middle of next week, and then some.
On an emulator?
More than 30.
How does that compare with a real VAX or a PDP/11?
One VUPS is supposed to be one original VAX CPU running VMS.
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.
On 2023-11-13, Arne Vajhøj <arne@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.
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.
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 theYeah, I would have expected 100s or 1000s of VUPS.
middle of next week, and then some.
On an emulator?
More than 30.
That's a more realistic figure, and what has been observed (by me).
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.
On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
Ahem A Rivet's Shot <steveo@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.
Ahem A Rivet's Shot <steveo@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?
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 <steveo@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.
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.
On 13/11/2023 17:32, Charlie Gibbs wrote:
On 2023-11-13, Arne Vajhøj <arne@vajhoej.dk> wrote:That sounds like the Sinclair scientific calculator in the early 70s
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.
Looking back on it now. I think the strangest thing about VMS was the
Manual Set.
Looking back on it now. I think the strangest thing about VMS was the
Manual Set.
On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
Ahem A Rivet's Shot <steveo@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.
On Mon, 13 Nov 2023 17:36:53 +0000, Chris Townley wrote:
On 13/11/2023 17:32, Charlie Gibbs wrote:
On 2023-11-13, Arne Vajhøj <arne@vajhoej.dk> wrote:That sounds like the Sinclair scientific calculator in the early 70s
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.
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.
On Mon, 13 Nov 2023 17:36:53 +0000, Chris Townley wrote:
On 13/11/2023 17:32, Charlie Gibbs wrote:
On 2023-11-13, Arne Vajhøj <arne@vajhoej.dk> wrote:That sounds like the Sinclair scientific calculator in the early 70s
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.
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.
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 <steveo@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.
On Mon, 13 Nov 2023 16:06:59 -0500, Arne Vajhøj 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 <steveo@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.
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.
Is that a single CPU, as I stated?
On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
Ahem A Rivet's Shot <steveo@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.
On 13/11/2023 22:00, Martin Gregorie wrote:
On Mon, 13 Nov 2023 17:36:53 +0000, Chris Townley wrote:No this was the earlier scientific calculator, and a few years earlier.
On 13/11/2023 17:32, Charlie Gibbs wrote:
On 2023-11-13, Arne Vajhøj <arne@vajhoej.dk> wrote:That sounds like the Sinclair scientific calculator in the early 70s
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.
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.
When you pressed a function, the screen would go blank for about 7
seconds. |But at the time, and the price it was phenomenal!
On Sun, 12 Nov 2023 22:48:31 -0500
"56d.1152" <56d.1152@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.
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.
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.
On Mon, 13 Nov 2023 19:29:14 -0500, Arne Vajhøj wrote:
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 <steveo@eircom.net> wrote:
Right, so this is about a Vax 6000 or so, right?
How does that compare with a real VAX or a PDP/11?
One VUPS is supposed to be one original VAX CPU running VMS. >>>>>
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)
That''s why I qualified my statement with "(one CPU)"
On Tue, 14 Nov 2023 10:30:18 +0100, Johnny Billquist wrote:
On 2023-11-14 00:40, Martin Gregorie wrote:ICL: UDAS, OLDAS, George 1`,2 and 3, VME/B
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?
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 knifeUse it a lot, also apropos,
if you ever saw one...
On 11/14/2023 4:30 AM, 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?
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.
On 11/14/2023 10:07 AM, Bob Eager wrote:
On Mon, 13 Nov 2023 19:29:14 -0500, Arne Vajhøj wrote:
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 <steveo@eircom.net> wrote:
Right, so this is about a Vax 6000 or so, right?
How does that compare with a real VAX or a PDP/11?
One VUPS is supposed to be one original VAX CPU running VMS. >>>>>>
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)
That''s why I qualified my statement with "(one CPU)"
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.
It is a bit different than under Unix-like systems, since commands don't necessarily have a 1:1 mapping to a binary.
On Tue, 14 Nov 2023 18:05:21 +0100
Johnny Billquist <bqt@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.
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.
So in which way do you think VMS is so different than all of the above?
And with alias for things, along with symlinks, Unix isn't really any different there either.
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
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.
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.
With find it don't matter. Even the original is crazy. The one tool
where the Unix paradigm got completely lost...
With find it don't matter. Even the original is crazy. The one tool
where the Unix paradigm got completely lost...
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 ??).
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 very long time (1990 or thereabouts and thats the only VAX-
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.
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.
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.
On 13 Nov 2023 at 17:44:15 GMT, "Pancho" <Pancho.Jones@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!"
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...
$ 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?
On Mon, 13 Nov 2023 23:02:11 -0500
"56d.1152" <56d.1152@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.
On 2023-11-13, TimS <tim@streater.me.uk> wrote:
On 13 Nov 2023 at 17:44:15 GMT, "Pancho" <Pancho.Jones@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".
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 .....
On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:
$ purge foobar.txtYes, 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.
On 14/11/2023 23:58, Martin Gregorie wrote:
On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:
$ purge foobar.txtYes, 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.
On Wed, 15 Nov 2023 07:58:47 +0000
Pancho <Pancho.Jones@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.
Apparently there's an emulation of EVE available for Emacs.
On Tue, 14 Nov 2023 22:31:20 -0500
"56d.1152" <56d.1152@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.
On 2023-11-14, Johnny Billquist <bqt@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?
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.
On 2023-11-14 20:50, Jim Jackson wrote:
On 2023-11-14, Johnny Billquist <bqt@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?
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.
On 2023-11-15, Johnny Billquist <bqt@softjar.se> wrote:
On 2023-11-14 20:50, Jim Jackson wrote:
On 2023-11-14, Johnny Billquist <bqt@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?
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.
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.
Johnny Billquist <bqt@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. 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.
On Wed, 15 Nov 2023 16:59:23 +0100
Johnny Billquist <bqt@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.
Ahem A Rivet's Shot <steveo@eircom.net> writes:
Johnny Billquist <bqt@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.
On Wed, 15 Nov 2023 16:59:23 +0100
Johnny Billquist <bqt@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.
Ahem A Rivet's Shot <steveo@eircom.net> writes:
Johnny Billquist <bqt@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.
On Wed, 15 Nov 2023 16:59:23 +0100
Johnny Billquist <bqt@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.
Source management is usually handled by one single program, even on most systems today. Be that cvs, svn, git or whatever.
So there's no reason to expect Emacs to be a Unix style program.
On 2023-11-15 18:04, Richard Kettlewell wrote:
Ahem A Rivet's Shot <steveo@eircom.net> writes:
Johnny Billquist <bqt@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.
On 2023-11-15 17:06, Ahem A Rivet's Shot wrote:
Emacs springs to mind.
Well - Emacs don't really come from the Unix world to start with...
But systemd always comes to my mind...
On 15 Nov 2023 at 20:59:37 GMT, "Johnny Billquist" <bqt@softjar.se> wrote:
On 2023-11-15 18:04, Richard Kettlewell wrote:
Ahem A Rivet's Shot <steveo@eircom.net> writes:
Johnny Billquist <bqt@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.
On 14/11/2023 23:58, Martin Gregorie wrote:
On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:
$ purge foobar.txtYes, 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.
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
On Wed, 15 Nov 2023 21:57:45 +0100
Johnny Billquist <bqt@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.
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
On 15 Nov 2023 at 20:49:52 GMT, "Rich Alderson" <news@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.
On 2023-11-15 22:34, Ahem A Rivet's Shot wrote:
On Wed, 15 Nov 2023 21:57:45 +0100
Johnny Billquist <bqt@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.
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.
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.
In article <uj1tno$1lkjn$1@dont-email.me>,
Pancho <Pancho.Jones@proton.me> wrote:
On 14/11/2023 23:58, Martin Gregorie wrote:
On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:
$ purge foobar.txtYes, 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.
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
I use Linux. As a desktop just like I use Windows.
For real computing I use real OSes. :-)
On Wed, 15 Nov 2023 08:06:00 -0500
Arne Vajhøj <arne@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.
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
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 ?
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.
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.
IBM didn't pay big for RHEL to run it on laptops,
but on its mainframes ......
Decentralized usually = SLOW ... and INSECURE ... despite
claims.
On Wed, 15 Nov 2023 18:51:53 -0500 bill <bill.gunshannon@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.
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".
I use Linux. As a desktop just like I use Windows.
For real computing I use real OSes. :-)
Sorry, but McDonalds Corporate, BOA, US Mil, etc ... they
are NOT gonna work on Docker or Kubernetes on a bunch of
On Wed, 15 Nov 2023 21:57:45 +0100
Johnny Billquist <bqt@softjar.se> wrote:
On 2023-11-15 17:06, Ahem A Rivet's Shot wrote:
Emacs springs to mind.
Well - Emacs don't really come from the Unix world to start with...
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.
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 <arne@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.
Systemd will be fine now Poettering has finished pottering with it,
got
It's never going to be portable to anything but Linux, that's enough to write it off for me.
On 15/11/2023 21:34, Ahem A Rivet's Shot wrote:
On Wed, 15 Nov 2023 21:57:45 +0100
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.
Systemd will be fine now Poettering has finished pottering with it, got
Our former clients moved to "cloud solutions". They learned rather
quickly that they would not have their prior capabilities. Not sure
just how much business they can now handle, and, it's taking much more manpower. "But, it's what everyone else does." Really?
On Thu, 16 Nov 2023 11:02:52 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 15/11/2023 21:34, Ahem A Rivet's Shot wrote:
On Wed, 15 Nov 2023 21:57:45 +0100Systemd will be fine now Poettering has finished pottering with it, got
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.
It's never going to be portable to anything but Linux, that's
enough to write it off for me.
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.
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).
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 <arne@vajhoej.dk> wrote:
On 11/15/2023 2:44 AM, Ahem A Rivet's Shot wrote:Of course, these environments are built for that purpose and allow >> the systems developers to assume the Kubernetes infrastructure without
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.
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 ......
On 11/16/2023 6:38 AM, Ahem A Rivet's Shot wrote:
It's never going to be portable to anything but Linux, that's
enough to write it off for me.
Is it surprising that a startup system for Linux
is coupled with Linux?
Our former clients moved to "cloud solutions". They learned rather
quickly that they would not have their prior capabilities. Not sure just
how much business they can now handle, and, it's taking much more
manpower. "But, it's what everyone else does." Really?
The IBM systems are I/O machines. The CPU is just sitting there telling
the I/O controllers what to do and most of the real work is being done by other hardware outside the CPU. So you can have incredibly high
workloads and huge transation rates with relatively slow CPUs.
This was a huge win as late as a decade ago, but these days it's not that much of a win unless you have a write-mostly database that is inefficient
to distribute. Because CPU has become so damn cheap that we just throw
CPU at problems now.
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.
This is true, but Amazon and Google -are- still slow and insecure in ways that I don't think is apparently obvious. Instead of keeping one thing secure, you have thousands upon thousands to keep secure.
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).
This is where the scary part is, yes.
On Thu, 16 Nov 2023 08:00:11 -0500
Dave Froble <davef@tsoft-inc.com> wrote:
Our former clients moved to "cloud solutions". They learned rather
quickly that they would not have their prior capabilities. Not sure just
how much business they can now handle, and, it's taking much more
manpower. "But, it's what everyone else does." Really?
So they did it badly - not uncommon. Amazon could not function
without a distributed, scalable, fault tolerant system, there's no way you could run Amazon mainframe style. Even their core database is distributed, scalable and fault tolerant relying on guaranteed eventual consistency
rather than ACID which does not scale.
McDonald's did it well.
<https://www.ciodive.com/news/mcdonalds-cloud-ETL-talend-digital-transformation/523132/
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 11/16/2023 6:38 AM, Ahem A Rivet's Shot wrote:
It's never going to be portable to anything but Linux, that's enough
to write it off for me.
Is it surprising that a startup system for Linux is coupled with
Linux?
Yes given that Linux purports to be a unix which has always had portability as a major feature.
Ahem A Rivet's Shot <steveo@eircom.net> writes:
Johnny Billquist <bqt@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.
On 11/16/2023 9:59 AM, Ahem A Rivet's Shot wrote:
So they did it badly - not uncommon. Amazon could not function
without a distributed, scalable, fault tolerant system, there's no way
you could run Amazon mainframe style. Even their core database is distributed, scalable and fault tolerant relying on guaranteed eventual consistency rather than ACID which does not scale.
I believe Amazon is using many different databases.
McDonald's did it well.
<https://www.ciodive.com/news/mcdonalds-cloud-ETL-talend-digital-transformation/523132/
It seems that article is about DWH not operational data. Different.
Ahem A Rivet's Shot <steveo@eircom.net> writes:
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 11/16/2023 6:38 AM, Ahem A Rivet's Shot wrote:
It's never going to be portable to anything but Linux, that's enough
to write it off for me.
Is it surprising that a startup system for Linux is coupled with
Linux?
Yes given that Linux purports to be a unix which has always had portability as a major feature.
Portability to different CPUs, sure, but portability of system tools to
other kernels? Who ever said that was a goal of Linux as such?
Oh, and the kernel is an example, of course. Process management, memory management, hardware drivers, multiple quite different kinds of IO and
some other stuff, all in a single monolithic whole. Completely the
opposite of the “do one thing well” principle. The reasons for this aren’t terrible but let’s not pretend that the Unix kernel is an
examplar of the Unix philosophy l-)
On Thu, 16 Nov 2023 16:28:27 +0000
Richard Kettlewell <invalid@invalid.invalid> wrote:
Ahem A Rivet's Shot <steveo@eircom.net> writes:
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 11/16/2023 6:38 AM, Ahem A Rivet's Shot wrote:
It's never going to be portable to anything but Linux, that's enough >>>>> to write it off for me.
Is it surprising that a startup system for Linux is coupled with
Linux?
Yes given that Linux purports to be a unix which has always had
portability as a major feature.
Portability to different CPUs, sure, but portability of system tools
to other kernels? Who ever said that was a goal of Linux as such?
It's always been a goal in the unix world - which Linux seems to be
leaving.
Linux as an operating system exists because all the tools provided
by the GNU project and MIT X-Windows and ... were designed to be portable across every variant of unix extant at the time (a lot more than today).
Maybe. It was certainly convenient for certain components to be
portable, like X11 as you mention, but I think it’s a stretch to infer
that there was a widely shared goal that the lower-level system tools
should be portable too. Things like, say, package management and device driver handling have been very different across platforms for a very
long time (the former in fact even within Linux).
In the more recent case of systemd, a lot of the functionality depends
on Linux-specific interfaces. Porting it would presumably be a
non-starter until this existed in some form in other operating systems,
and nobody maintaining other operating systems seems to be interested in doing so.
Linux as an operating system exists because all the tools
provided by the GNU project and MIT X-Windows and ... were designed to
be portable across every variant of unix extant at the time (a lot more than today).
That doesn’t make it a goal _of Linux_, even if it was a goal of the GNU and X11 projects.
On Thu, 16 Nov 2023 11:02:52 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
Systemd will be fine now Poettering has finished pottering with it, got
It's never going to be portable to anything but Linux, that's
enough to write it off for me.
On 11/16/2023 8:00 AM, Dave Froble wrote:
Our former clients moved to "cloud solutions". They learned rather quickly >> that they would not have their prior capabilities. Not sure just how much >> business they can now handle, and, it's taking much more manpower. "But, it's
what everyone else does." Really?
I would think the capabilities depend on the software
and not on where it is hosted.
I assume they made two changes at the same time:
* dedicated physical system -> public cloud
* application X -> application Y
The loss of capabilities has to be because of the
second bullet.
If your application had been ported to VMS x86-64 and
the customers had deployed it in AWS/Azure/GCP/OCI then
it would have worked as well as always.
On Thu, 16 Nov 2023 01:13:21 -0500
"56d.1152" <56d.1152@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.
A decade or so ago, a program called 'monit' handled monitoring
and restarting of daemons quite nicely. However, I don't know
whether it's still maintained.
The lack of portability of systemd can hardly be an objection to it if
nobody in the platforms that it can’t be ported to is interested in adopting it anyway.
There’s still nothing there that demonstrates Linux ever had a goal of portable system-level tools. I get that you think it should do, but
wanting isn’t getting.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Maybe. It was certainly convenient for certain components to be
portable, like X11 as you mention, but I think it’s a stretch to infer
that there was a widely shared goal that the lower-level system tools
should be portable too. Things like, say, package management and device
driver handling have been very different across platforms for a very
long time (the former in fact even within Linux).
Package management is a relatively new feature of unix (it's about
half the age of unix) - but NetBSD's pkgsrc is designed to be portable
and can be used on pretty much any unix including Linux. The FreeBSD
ports system (one of the first) is written in make and the system (but
not the ports themselves) would be easy enough to get going on any
other unix with a BSD compatible make available.
Device drivers are of course largely kernel dependent and generally
not portable - notable exception for DRI/DRM which are surprisingly
portable. That being said it is quite common to port device drivers
between the BSDs despite the divergence in the kernels over the years,
none of them would take Linux device drivers because GPL.
In the more recent case of systemd, a lot of the functionality depends
on Linux-specific interfaces. Porting it would presumably be a
Apart from systemd every other init system is shell script based and reasonably easy to port, systemd is a huge departure from convention.
non-starter until this existed in some form in other operating systems,
and nobody maintaining other operating systems seems to be interested in
doing so.
Nobody maintaining other operating systems wants them to become Linux
based which is essentially what would be needed.
Linux as an operating system exists because all the tools
provided by the GNU project and MIT X-Windows and ... were designed to
be portable across every variant of unix extant at the time (a lot more
than today).
That doesn’t make it a goal _of Linux_, even if it was a goal of the GNU >> and X11 projects.
You missed the "and ...", Linux based OSs are the odd ones out in
this regard which is sad given that Linux as an OS owes its entire
existence to the fact that everyone else in the unix world cares about portability. Without the GNU project's portable utilities there would be no Linux distros, there wouldn't even be a compiler to build the kernel! If
MIT had chosen to make X11 tightly bound to a single kernel there would be
no Linux graphics.
On Thu, 16 Nov 2023 10:51:04 -0500
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 11/16/2023 9:59 AM, Ahem A Rivet's Shot wrote:
So they did it badly - not uncommon. Amazon could not function
without a distributed, scalable, fault tolerant system, there's no way
you could run Amazon mainframe style. Even their core database is
distributed, scalable and fault tolerant relying on guaranteed eventual
consistency rather than ACID which does not scale.
I believe Amazon is using many different databases.
AWS provides many databases. Dynamo was created to support Amazon's original core business of being a huge international shopping site.
McDonald's did it well.
<https://www.ciodive.com/news/mcdonalds-cloud-ETL-talend-digital-transformation/523132/
It seems that article is about DWH not operational data. Different.
It's about analytics that record every sale in every McDonald's in
the world and drives their decision making. The point is that it scales beyond anything that could be done on a mainframe.
On 17/11/2023 09:36, Richard Kettlewell wrote:
There’s still nothing there that demonstrates Linux ever had a goal of
portable system-level tools. I get that you think it should do, but
wanting isn’t getting.
Who will bell the cat?
The Natural Philosopher <tnp@invalid.invalid> wrote:Engineers don't do philosophy usually (I am the exception) except '
On 17/11/2023 09:36, Richard Kettlewell wrote:
There’s still nothing there that demonstrates Linux ever had a goal of >>> portable system-level tools. I get that you think it should do, but
wanting isn’t getting.
Who will bell the cat?
GNU always has as its primary goal that of providing portable system-level tools. For a long time, Linux was the kernel and GNU provided most of the actual environment in the distribution.
However, at some point the momentum built up until "Linux" as a concept
took off, and then everybody kind of forgot about GNU and the GNU environment and philosophy... then they forgot about the Unix environment and philosophy...
now it is just a mess.
--scott
However, at some point the momentum built up until "Linux" as a concept
took off, and then everybody kind of forgot about GNU and the GNU
environment and philosophy... then they forgot about the Unix environment
and philosophy... now it is just a mess.
However, at some point the momentum built up until "Linux" as a concept
took off, and then everybody kind of forgot about GNU and the GNU
environment and philosophy... then they forgot about the Unix environment
and philosophy... now it is just a mess.
On 17 Nov 2023 12:39:52 -0000
kludge@panix.com (Scott Dorsey) wrote:
However, at some point the momentum built up until "Linux" as a concept
took off, and then everybody kind of forgot about GNU and the GNU
environment and philosophy... then they forgot about the Unix environment
and philosophy... now it is just a mess.
I suspect that Richard Stallman trying to get everyone to call it GNU-Linux didn't help.
A philosophical statement
There is reality. This is what physicists and engineers deal with.
On Fri, 17 Nov 2023 14:26:53 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
A philosophical statement
There is reality. This is what physicists and engineers deal with.
Engineers deal with models that they hope correspond to reality but don't always
that correspond to reality but don't always (cf. contradictions between general relativity and quantum theory). Then there are chaotic systems and emergent phenomena which so far have proven extremely resistant to
modelling.
Nobody can prove that reality exists (cf. solipsism etc) but it is
the most useful assumption we can make.
prove that reality is logically consistent - it might all be the whim of
God you can't prove that it isn't - but it is the most useful assumption we can make and it hasn't (yet) been disproved.
The core unspoken (usually) theorems of physics are that reality
exists and that it is logically consistent. If you can prove either of them
I expect you're due a Nobel and an FRS at least.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 17/11/2023 09:36, Richard Kettlewell wrote:
There’s still nothing there that demonstrates Linux ever had a goal
of portable system-level tools. I get that you think it should do,
but wanting isn’t getting.
Who will bell the cat?
GNU always has as its primary goal that of providing portable
system-level tools.
For a long time, Linux was the kernel and GNU provided most of the
actual environment in the distribution.
However, at some point the momentum built up until "Linux" as a
concept took off, and then everybody kind of forgot about GNU and the
GNU environment and philosophy... then they forgot about the Unix
environment and philosophy... now it is just a mess.
On 17 Nov 2023 12:39:52 -0000
kludge@panix.com (Scott Dorsey) wrote:
However, at some point the momentum built up until "Linux" as a concept
took off, and then everybody kind of forgot about GNU and the GNU
environment and philosophy... then they forgot about the Unix environment
and philosophy... now it is just a mess.
I suspect that Richard Stallman trying to get everyone to call it
GNU-Linux didn't help.
In article <20231117130709.1798abc63c60b0f3291598eb@eircom.net>,
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On 17 Nov 2023 12:39:52 -0000
kludge@panix.com (Scott Dorsey) wrote:
However, at some point the momentum built up until "Linux" as a concept
took off, and then everybody kind of forgot about GNU and the GNU
environment and philosophy... then they forgot about the Unix environment >>> and philosophy... now it is just a mess.
I suspect that Richard Stallman trying to get everyone to call it
GNU-Linux didn't help.
No. In general, I think Stallman has done more harm than good to the
free software movement in recent years.
On 11/17/2023 4:06 PM, Scott Dorsey wrote:
In article <20231117130709.1798abc63c60b0f3291598eb@eircom.net>,
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On 17 Nov 2023 12:39:52 -0000
kludge@panix.com (Scott Dorsey) wrote:
However, at some point the momentum built up until "Linux" as a concept >>>> took off, and then everybody kind of forgot about GNU and the GNU
environment and philosophy... then they forgot about the Unix
environment
and philosophy... now it is just a mess.
I suspect that Richard Stallman trying to get everyone to call it >>> GNU-Linux didn't help.
No. In general, I think Stallman has done more harm than good to the
free software movement in recent years.
Because in recent years it has not been about software.
When RMS talk about software then some adore him and some hate him.
But when he talks about anything else then everybody hates him.
On 16 Nov 2023 13:36:17 -0000
kludge@panix.com (Scott Dorsey) wrote:
The IBM systems are I/O machines. The CPU is just sitting there telling
the I/O controllers what to do and most of the real work is being done by
other hardware outside the CPU. So you can have incredibly high
workloads and huge transation rates with relatively slow CPUs.
Yes you can but ...
This was a huge win as late as a decade ago, but these days it's not that
much of a win unless you have a write-mostly database that is inefficient
to distribute. Because CPU has become so damn cheap that we just throw
CPU at problems now.
Back in 1990 I was involved in designing a system that could not
have been run on the mainframes of the day because they had insufficient IO bandwidth but a distributed solution spread across twenty high end 88K machines did.
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.
This is true, but Amazon and Google -are- still slow and insecure in ways
that I don't think is apparently obvious. Instead of keeping one thing
secure, you have thousands upon thousands to keep secure.
Yes but instead of trying to secure each one individually you write rules which are used by the deployment engine (kubernetes usually).
A single instance implemented on virtual hardware is certainly
slower than the same thing implemented on bare metal - the win comes from having a scalable design. The artful part is making the design scalable and not putting bottlenecks in it. If the single instance is 1/10th the speed
of bare metal but you can run a thousand instances in parallel then you
have 100 times the speed of bare metal.
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).
This is where the scary part is, yes.
Yes it is - that's why my data lives at home. I don't need scalable solutions thankfully. Those who do and care a lot run their own.
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
In article <20231117130709.1798abc63c60b0f3291598eb@eircom.net>,
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On 17 Nov 2023 12:39:52 -0000
kludge@panix.com (Scott Dorsey) wrote:
However, at some point the momentum built up until "Linux" as a concept
took off, and then everybody kind of forgot about GNU and the GNU
environment and philosophy... then they forgot about the Unix environment >>> and philosophy... now it is just a mess.
I suspect that Richard Stallman trying to get everyone to call it
GNU-Linux didn't help.
No. In general, I think Stallman has done more harm than good to the
free software movement in recent years.
--scott
On Sat, 18 Nov 2023 01:16:41 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
Read this https://cloud.google.com/customers/revolut/
Revolut is one of the biggest banks.
On 11/18/23 3:01 AM, Ahem A Rivet's Shot wrote:
On Sat, 18 Nov 2023 01:16:41 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
Read this https://cloud.google.com/customers/revolut/
Revolut is one of the biggest banks.
But for HOW LONG if it uses insecure methods ? :-)
On Sat, 18 Nov 2023 01:16:41 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
Read this https://cloud.google.com/customers/revolut/
Revolut is one of the biggest banks.
On 11/18/2023 3:01 AM, Ahem A Rivet's Shot wrote:
On Sat, 18 Nov 2023 01:16:41 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
Read this https://cloud.google.com/customers/revolut/
Revolut is one of the biggest banks.
Revolut is not a big bank. It is a pretty small bank.
On Sun, 19 Nov 2023 16:33:38 -0500
Arne Vajh°j <arne@vajhoej.dk> wrote:
On 11/18/2023 3:01 AM, Ahem A Rivet's Shot wrote:
On Sat, 18 Nov 2023 01:16:41 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
Read this https://cloud.google.com/customers/revolut/
Revolut is one of the biggest banks.
Revolut is not a big bank. It is a pretty small bank.
Depends how you measure - by valuation ($33bn) it's bigger than
Deutsche Bank ($25bn).
On Sun, 19 Nov 2023 16:33:38 -0500
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 11/18/2023 3:01 AM, Ahem A Rivet's Shot wrote:
On Sat, 18 Nov 2023 01:16:41 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
Read this https://cloud.google.com/customers/revolut/
Revolut is one of the biggest banks.
Revolut is not a big bank. It is a pretty small bank.
Depends how you measure - by valuation ($33bn) it's bigger than Deutsche Bank ($25bn).
On 11/18/2023 3:01 AM, Ahem A Rivet's Shot wrote:
On Sat, 18 Nov 2023 01:16:41 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
Read this https://cloud.google.com/customers/revolut/
Revolut is one of the biggest banks.
Revolut is not a big bank. It is a pretty small bank.
But there are big banks using public cloud.
Deutsche Bank - Google cloud
HSBC - Amazon cloud
JP Morgan - multi cloud
Bank of America - IBM cloud
Goldman Sachs - Amazon cloud
UBS - Microsoft cloud
The US military also use public cloud. After spending
years on court room battles I believe DoD split the
contract between Amazon, Microsoft, Google and Oracle.
Arne
On Sat, 18 Nov 2023 23:15:11 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
On 11/18/23 3:01 AM, Ahem A Rivet's Shot wrote:
On Sat, 18 Nov 2023 01:16:41 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
Read this https://cloud.google.com/customers/revolut/
Revolut is one of the biggest banks.
But for HOW LONG if it uses insecure methods ? :-)
They've been operating since 2015,
had a data breach in 2022
resulting from a phishing attack which netted some personal data (about
5000 people) and a bug in their US payment system that let them (not their customers) lose $20m. Note carefully that neither of these was an infrastructure attack.
Pretty small potatoes compared to say the Capital One data breach
in 2019 that let 100 million credit card application details out or the JP Morgan Chase data breach of 83 million accounts or the Experian breach of
24 million customer's personal details or the ransomware attack on the US branch of ICBC (that's the world's biggest bank) or Flagstar bank which has had three data breaches in the last two years or the IBM Moveit data breach earlier this year that leaked medical records of 4.1 million people in Colerado. It's even small compared to Bank of Ireland's 22 data breaches
over six months leaking personal data of over 50,000 customers.
I'd say the evidence is that their security stacks up pretty well.
As anyone involved professionally in data security (hint that
includes me) knows the vast majority of compromises these days result from social engineering (various forms of phishing) not technical issues.
Peruse this https://tech.co/news/data-breaches-updated-list if you don't believe me.
On 19/11/2023 21:33, Arne Vajhøj wrote:
On 11/18/2023 3:01 AM, Ahem A Rivet's Shot wrote:I find that frightening, irresponsible and yet strangely believable.
On Sat, 18 Nov 2023 01:16:41 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:
Big banks/biz, govt/mil, need to err on the side of
security. Google can err on the side of high-volume.
Read this https://cloud.google.com/customers/revolut/
Revolut is one of the biggest banks.
Revolut is not a big bank. It is a pretty small bank.
But there are big banks using public cloud.
Big banks should be broken up. They have way too much power and take
fuck all responsibility.
Deutsche Bank - Google cloud
HSBC - Amazon cloud
JP Morgan - multi cloud
Bank of America - IBM cloud
Goldman Sachs - Amazon cloud
UBS - Microsoft cloud
The US military also use public cloud. After spending
years on court room battles I believe DoD split the
contract between Amazon, Microsoft, Google and Oracle.
| Sysop: | Xerxes |
|---|---|
| Location: | Azle, Texas |
| Users: | 119 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 136:37:16 |
| Calls: | 3,027 |
| Calls today: | 3 |
| Files: | 156 |
| U/L today: |
0 files (0K bytes) |
| D/L today: |
0 files (0K bytes) |
| Messages: | 294,134 |
| Posted today: | 0 |