On 1/31/2022 7:23 AM, Phillip Helbig (undress to reply) wrote:
> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> Fortran and COBOL are not suitable for writing operating system userland
>> tools.
>
> Why not?

They have features that OS userland utilities usually doesn't need.

They lack features that many OS userland utilities do need.

Variable length strings and dynamic sizing of arrays come
to my mind.

Arne

On 1/30/2022 10:07 PM, Bill Gunshannon wrote:
> On 1/30/22 22:01, Arne Vajhøj wrote:
>> On 1/30/2022 9:55 PM, Bill Gunshannon wrote:
>>> The only real C is that described in the K&R manual.
>>
>> 1st or 2nd edition?
>>
>> :-)
>
> I still use 1st.  :-)  It is the version of C that runs on a lot of
> the systems I still enjoy working on.

But practically all current systems are using ISO C aka 2nd edition.

Anyway back to the rename question then even though K&R C and ANSI/ISO C
have some differences then I don't think there were big enough to
justify a rename.

Arne

On 1/31/2022 8:13 AM, Simon Clubley wrote:
> On 2022-01-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/30/2022 7:20 PM, Simon Clubley wrote:
>>> On 2022-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> And it is not just me.
>>>>
>>>> The rust people are rewriting GNU Coreutils (C) in
>>>> rust.
>>>>
>>>> https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022
>>>>
>>>
>>> Let me know when the Rust compiler runs on all the architectures
>>> that Linux runs on. :-)
>>
>> They are missing some.
>>
>> Rust supports x86, x86-64, ARM, MIPS, PPC, RISC-V and mainframe.
>>
>> So they are missing Alpha, PA, Itanium, SPARC and several
>> lesser ones.
>>
>> But who actually runs Linux on one of those?
>>
>
> The point is that the Linux kernel is built around portability to
> whatever architecture you want to run it on.
>
> You can get a C compiler for everything someone could be interested
> in running the Linux kernel on. However, until you can make the same
> guarantee for Rust, then Rust will be restricted to the non-core
> parts of the Linux kernel (ie: some device drivers) because otherwise
> Rust suddenly becomes the reason why you can't run Linux on some
> specialist architecture.

It is obviously an issue.

And it is known that for now the focus is on drivers.

But Linux Torvalds said "Rust's primary first target seems
to be drivers, ..." and Greg Kroah-Hartman said "drivers are
probably the first place for an attempt like this ...".

Their usage of the word "first" indicate that Rust may
be used in other parts as well later.

Arne

On 1/31/2022 10:13 AM, John Dallman wrote:
> In article <61f7f125$0$694$14726298@news.sunsite.dk>, arne@vajhoej.dk
> (Arne Vajhøj) wrote:
>> To me it seems that the industry impact of Linux is very much
>> centered around x86-64 servers and ARM Android devices.
>>
>> Look at what Redhat and other actually support. There is a
>> reason for that.
>
> https://access.redhat.com/products/red-hat-enterprise-linux/#addl-arch
>
> As well as x86-64, which is unquestionably the most-used platform, they
> also support IBM Z, 64-bit Power and 64-bit ARM. The last of those is
> mostly used on cloud servers.

OK.

ARM is definitely future relevant.

And IBM z and p customers have money. :-)

Arne

On 1/31/2022 10:25 AM, Arne Vajhøj wrote:
> On 1/31/2022 10:13 AM, John Dallman wrote:
>> In article <61f7f125$0$694$14726298@news.sunsite.dk>, arne@vajhoej.dk
>> (Arne Vajhøj) wrote:
>>> To me it seems that the industry impact of Linux is very much
>>> centered around x86-64 servers and ARM Android devices.
>>>
>>> Look at what Redhat and other actually support. There is a
>>> reason for that.
>>
>> https://access.redhat.com/products/red-hat-enterprise-linux/#addl-arch
>>
>> As well as x86-64, which is unquestionably the most-used platform, they
>> also support IBM Z, 64-bit Power and 64-bit ARM. The last of those is
>> mostly used on cloud servers.
>
> OK.
>
> ARM is definitely future relevant.
>
> And IBM z and p customers have money. :-)

No, they HAD money. IBM has all of it now.

:-)

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

On 1/31/2022 7:23 AM, Phillip Helbig (undress to reply) wrote:
> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> Fortran and COBOL are not suitable for writing operating system userland
>> tools.
>
> Why not?
>

Cause Simon says so ...

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

On 1/31/2022 3:33 AM, Johnny Billquist wrote:
> On 2022-01-31 01:43, Arne Vajhøj wrote:
>> On 1/30/2022 7:19 PM, Simon Clubley wrote:
>>> On 2022-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 1/29/2022 1:53 AM, George Cornelius wrote:
>>>>>
>>>>> Works on Eisner.
>>>>>
>>>>> $ show sys/noproc
>>>>> OpenVMS V8.4-2L2 on node EISNER 29-JAN-2022 [...]
>>>>>
>>>>> Here's the memory layout synopsis from a linker map:
>>>>>
>>>>> Virtual memory allocated: 00010000 0005FFFF
>>>>> 00050000 (327680. bytes, 640. pages)
>>>>> 64-Bit Virtual memory allocated: 00000000 00000000 00000000
>>>>> 80000000 80010000
>>>>> 00010000 (65536. bytes, 128. pages)
>>>>>
>>>>> The example, though, shows too small an allocation to escape 32 bit address
>>>>> space.
>>>>
>>>> I consider 0000000080000000 to be 64 bit space.
>>>>
>>>> 0000000000000000 - 000000007FFFFFFF is P0 and P1 space
>>>> FFFFFFFF80000000 - FFFFFFFFFFFFFFFF is S0 and S1 space
>>>> 0000000080000000 and upward is P2 space
>>>>
>>>
>>> I think George's point is that this specific address can be
>>> represented in a 32-bit pointer.
>>
>> It can't.
>>
>> A 32 bit pointer with the value 80000000 will end up as
>> FFFFFFFF80000000.
>
> Since when are pointers considered to be signed and need sign extension?
>
> Johnny

When one is using a signed integer to store the value of the pointer.

Hey, you asked ...

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

On 1/31/22 08:42, Simon Clubley wrote:
> On 2022-01-31, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>> Fortran and COBOL are not suitable for writing operating system userland
>>> tools.
>>
>> Why not?
>>
>
> For the same reason that OS designers moved from Fortran to C as the
> system implementation language when C became available. C is simply
> a better language than Fortran for those kinds of tasks.

All of the userland in STVOS are implemented quite nicely in Fortran.
(Well, Ratfor actually, but then the Fortran compiler makes them
functional.)

>
> As for COBOL, I invite you to try implementing something like CDU or
> especially TPU in it. :-)

In one of it's earlier incantations Micro Focus did their COBOL
compiler in COBOL and that was with a version that did not even
support recursion.

Go look at some of the things that have been done in COBOL and Fortran
for Rosetta Code and then try to argue that these languages lack the
abilities of other languages.

bill

On 1/31/22 10:00, Arne Vajhøj wrote:
> On 1/30/2022 10:07 PM, Bill Gunshannon wrote:
>> On 1/30/22 22:01, Arne Vajhøj wrote:
>>> On 1/30/2022 9:55 PM, Bill Gunshannon wrote:
>>>> The only real C is that described in the K&R manual.
>>>
>>> 1st or 2nd edition?
>>>
>>> :-)
>>
>> I still use 1st.  :-)  It is the version of C that runs on a lot of
>> the systems I still enjoy working on.
>
> But practically all current systems are using ISO C aka 2nd edition.
>
> Anyway back to the rename question then even though K&R C and ANSI/ISO C
> have some differences then I don't think there were big enough to
> justify a rename.
>

And yet, when referencing them, they do have to use two different
names to differentiate them. "K&R C" and "ANSI C".

bill

On 1/31/22 03:25, Johnny Billquist wrote:
> On 2022-01-31 01:22, Simon Clubley wrote:
>> On 2022-01-29, Scott Dorsey <kludge@panix.com> wrote:
>>>
>>> Pascal is pretty limited but makes it hard to shoot yourself in the
>>> foot.
>>> And most implementations don't use null-terminated strings which are the
>>> most serious source of vulnerabilities in C code.
>>> --scott
>>>
>>
>> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>
> The problem is that the ISO standard for Pascal is pretty useless.

Pretty useless for what? Tasks for which the language was not designed?

> Which
> is why every useful Pascal have extensions...
> And they are all different...
> Which makes everything very non-standard...

Thus the reason they should have come up with new names and not called
themselves Pascal, which they were not.

>
> But Pascal is definitely not that bad a language. But it has it's warts...

Pascal is ideal for what it was designed for. Too bad people still
don't understand the concept of "choose the right tool for the job".

bill

On 1/31/22 08:36, Arne Vajhøj wrote:
> On 1/31/2022 3:25 AM, Johnny Billquist wrote:
>> On 2022-01-31 01:22, Simon Clubley wrote:
>>> On 2022-01-29, Scott Dorsey <kludge@panix.com> wrote:
>>>>
>>>> Pascal is pretty limited but makes it hard to shoot yourself in the
>>>> foot.
>>>> And most implementations don't use null-terminated strings which are
>>>> the
>>>> most serious source of vulnerabilities in C code.
>>>> --scott
>>>>
>>>
>>> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>>
>> The problem is that the ISO standard for Pascal is pretty useless.
>> Which is why every useful Pascal have extensions...
>> And they are all different...
>> Which makes everything very non-standard...
>>
>> But Pascal is definitely not that bad a language. But it has it's
>> warts...
>
> Pascal as in Wirth Pascal is a very good language for what it was
> intended for: teaching structured programming. It is just that real
> world programs need a bit more.

And, just maybe, the answer was to pick the right language for the job
and not try to modify the wrong language to make it fit. When you buy
your kid one of those toys with round, square and triangle blocks and
holes to match do you also buy them a saw so that any block can fit in
any hole?

bill

On 1/31/2022 12:25 PM, Bill Gunshannon wrote:
> On 1/31/22 10:00, Arne Vajhøj wrote:
>> On 1/30/2022 10:07 PM, Bill Gunshannon wrote:
>>> On 1/30/22 22:01, Arne Vajhøj wrote:
>>>> On 1/30/2022 9:55 PM, Bill Gunshannon wrote:
>>>>> The only real C is that described in the K&R manual.
>>>>
>>>> 1st or 2nd edition?
>>>>
>>>> :-)
>>>
>>> I still use 1st.  :-)  It is the version of C that runs on a lot of
>>> the systems I still enjoy working on.
>>
>> But practically all current systems are using ISO C aka 2nd edition.
>>
>> Anyway back to the rename question then even though K&R C and ANSI/ISO C
>> have some differences then I don't think there were big enough to
>> justify a rename.
>
> And yet, when referencing them, they do have to use two different
> names to differentiate them.  "K&R C" and "ANSI C".

K&R C, C 89, C99, C11

C++ 1.0, C++ 2.0, C++ 98. C++ 11, C++ 17

Java 5, 6, 7, 8, 11, 17

Python 2, 3

PHP 4, 5, 7, 8

Languages evolve and it makes sense to specify version.

But Fortran 77 to 90 was more than the typical version change. I think
it could have justified a name change.

Another candidate would be Ada 83 to 95. That was also a big change.

Arne

On 1/31/22 08:46, Arne Vajhøj wrote:
> On 1/30/2022 10:04 PM, Bill Gunshannon wrote:
>> On 1/30/22 19:49, Arne Vajhøj wrote:
>>> On 1/30/2022 7:20 PM, Simon Clubley wrote:
>>>> On 2022-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> And it is not just me.
>>>>>
>>>>> The rust people are rewriting GNU Coreutils (C) in
>>>>> rust.
>>>>>
>>>>> https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022
>>>>>
>>>>>
>>>>
>>>> Let me know when the Rust compiler runs on all the architectures
>>>> that Linux runs on. :-)
>>>
>>> They are missing some.
>>>
>>> Rust supports x86, x86-64, ARM, MIPS, PPC, RISC-V and mainframe.
>>>
>>> So they are missing Alpha, PA, Itanium, SPARC and several
>>> lesser ones.
>>>
>>> But who actually runs Linux on one of those?
>>>
>>
>> I still run it on a SPARC.  If I still had an Alpha I would
>> probably be running it n that, too.
>
> I would run Solaris on SPARC and I do run VMS on Alpha
> and keep Linux on x86-64. Are there any benefits
> from running Linux on a less common platform?
>

For me, I have the platform and the things I tend to run
require something better than Solaris. Actually, I am
much more likely to run a BSD but I do have disks with
Linux installed for the Sparc. I have Solaris, too but
don't remember the last time I used it. I wasn't happy
when they dumped SunOS in favor of Solaris. I don't see
where it ever really improved.

bill

On 1/31/22 09:02, Simon Clubley wrote:
> On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> I would run Solaris on SPARC and I do run VMS on Alpha
>> and keep Linux on x86-64. Are there any benefits
>> from running Linux on a less common platform?
>>
>
> One of the reasons Linux has taken off is that you can run it on
> pretty much every single thing that is physically capable of hosting
> it in terms of CPU power and memory/other resources.
>
> This includes large mainframes all the way down to tiny embedded boards
> running on some custom hardware/architecture.
>

The same is probably true of just about any OS. All it takes is
access to the source and a desire by someone to do the work. Why
do you think I would still like to see the source to RSTS released
into the wild. RSX which was very PDP-11 specific now has a version
running on later Z80 family processors. I have it running here at
my home and it works quite well.

bill

On 1/31/2022 12:29 PM, Bill Gunshannon wrote:
> On 1/31/22 03:25, Johnny Billquist wrote:
>> On 2022-01-31 01:22, Simon Clubley wrote:
>>> On 2022-01-29, Scott Dorsey <kludge@panix.com> wrote:
>>>>
>>>> Pascal is pretty limited but makes it hard to shoot yourself in the
>>>> foot.
>>>> And most implementations don't use null-terminated strings which are
>>>> the
>>>> most serious source of vulnerabilities in C code.
>>>> --scott
>>>>
>>>
>>> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>>
>> The problem is that the ISO standard for Pascal is pretty useless.
>
> Pretty useless for what?  Tasks for which the language was not designed?
>
>> Which is why every useful Pascal have extensions...
>> And they are all different...
>> Which makes everything very non-standard...
>
> Thus the reason they should have come up with new names and not called
> themselves Pascal, which they were not.

If they compile Wirth/ISO Pascal then it is somewhat justifiable
to call them Pascal.

But given how much the language get extended then it is
really necessary to specify dialect.

VMS Pascal, Object Pascal etc..

Borland took the consequence and eventually branded their
Object Pascal product as Delphi.

But I do not have a problem with the term "VMS Pascal".

Arne

On 1/31/2022 12:33 PM, Bill Gunshannon wrote:
> On 1/31/22 08:36, Arne Vajhøj wrote:
>> On 1/31/2022 3:25 AM, Johnny Billquist wrote:
>>> The problem is that the ISO standard for Pascal is pretty useless.
>>> Which is why every useful Pascal have extensions...
>>> And they are all different...
>>> Which makes everything very non-standard...
>>>
>>> But Pascal is definitely not that bad a language. But it has it's
>>> warts...
>>
>> Pascal as in Wirth Pascal is a very good language for what it was
>> intended for: teaching structured programming. It is just that real
>> world programs need a bit more.
>
> And, just maybe, the answer was to pick the right language for the job
> and not try to modify the wrong language to make it fit.  When you buy
> your kid one of those toys with round, square and triangle blocks and
> holes to match do you also buy them a saw so that any block can fit in
> any hole?

There are evolutions of Wirth/ISO Pascal that can be the right tool
for real world programs.

VMS Pascal and Object Pascal/Delphi as heavily extended flavors of Pascal.

Modula-2 and Ada 83 as new languages in Pascal style.

I like Modula-2 and VMS Pascal better than Delphi and Ada 83, but YMMV.

Arne

On 1/31/22 12:42, Arne Vajhøj wrote:
> On 1/31/2022 12:29 PM, Bill Gunshannon wrote:
>> On 1/31/22 03:25, Johnny Billquist wrote:
>>> On 2022-01-31 01:22, Simon Clubley wrote:
>>>> On 2022-01-29, Scott Dorsey <kludge@panix.com> wrote:
>>>>>
>>>>> Pascal is pretty limited but makes it hard to shoot yourself in the
>>>>> foot.
>>>>> And most implementations don't use null-terminated strings which
>>>>> are the
>>>>> most serious source of vulnerabilities in C code.
>>>>> --scott
>>>>>
>>>>
>>>> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>>>
>>> The problem is that the ISO standard for Pascal is pretty useless.
>>
>> Pretty useless for what?  Tasks for which the language was not designed?
>>
>>> Which is why every useful Pascal have extensions...
>>> And they are all different...
>>> Which makes everything very non-standard...
>>
>> Thus the reason they should have come up with new names and not called
>> themselves Pascal, which they were not.
>
> If they compile Wirth/ISO Pascal then it is somewhat justifiable
> to call them Pascal.

You are looking at it in the opposite direction from me.
If the Wirth Compiler compiles it then it is Pascal. If
I added a parser and code generator for FORTRAN to a Pascal
compiler would FORTRAN syntax then become Pascal?

>
> But given how much the language get extended then it is
> really necessary to specify dialect.

Too much of it went far beyond mere dialect.

>
> VMS Pascal, Object Pascal etc..
>
> Borland took the consequence and eventually branded their
> Object Pascal product as Delphi.

And, to this day, I still see people calling Delphi Pascal
even thought the creator tried to change the name.

>
> But I do not have a problem with the term "VMS Pascal".

I guess it doesn't matter what you call it. The problem is
when you tell someone "Here is how you do it in Pascal" and
then present a solution in a language that won't compile in
a Pascal Compiler on any other environment.

bill

On 1/31/22 12:48, Arne Vajhøj wrote:
> On 1/31/2022 12:33 PM, Bill Gunshannon wrote:
>> On 1/31/22 08:36, Arne Vajhøj wrote:
>>> On 1/31/2022 3:25 AM, Johnny Billquist wrote:
>>>> The problem is that the ISO standard for Pascal is pretty useless.
>>>> Which is why every useful Pascal have extensions...
>>>> And they are all different...
>>>> Which makes everything very non-standard...
>>>>
>>>> But Pascal is definitely not that bad a language. But it has it's
>>>> warts...
>>>
>>> Pascal as in Wirth Pascal is a very good language for what it was
>>> intended for: teaching structured programming. It is just that real
>>> world programs need a bit more.
>>
>> And, just maybe, the answer was to pick the right language for the job
>> and not try to modify the wrong language to make it fit.  When you buy
>> your kid one of those toys with round, square and triangle blocks and
>> holes to match do you also buy them a saw so that any block can fit in
>> any hole?
>
> There are evolutions of Wirth/ISO Pascal that can be the right tool
> for real world programs.
>
> VMS Pascal and Object Pascal/Delphi as heavily extended flavors of Pascal.
>
> Modula-2 and Ada 83 as new languages in Pascal style.
>
> I like Modula-2 and VMS Pascal better than Delphi and Ada 83, but YMMV.
>

Isn't it interesting that Wirth called his new language Modula and
not something like "New Pascal" or "Pascal-2".

bill

On 1/31/2022 12:53 PM, Bill Gunshannon wrote:
> On 1/31/22 12:48, Arne Vajhøj wrote:
>> On 1/31/2022 12:33 PM, Bill Gunshannon wrote:
>>> On 1/31/22 08:36, Arne Vajhøj wrote:
>>>> On 1/31/2022 3:25 AM, Johnny Billquist wrote:
>>>>> The problem is that the ISO standard for Pascal is pretty useless.
>>>>> Which is why every useful Pascal have extensions...
>>>>> And they are all different...
>>>>> Which makes everything very non-standard...
>>>>>
>>>>> But Pascal is definitely not that bad a language. But it has it's
>>>>> warts...
>>>>
>>>> Pascal as in Wirth Pascal is a very good language for what it was
>>>> intended for: teaching structured programming. It is just that real
>>>> world programs need a bit more.
>>>
>>> And, just maybe, the answer was to pick the right language for the job
>>> and not try to modify the wrong language to make it fit.  When you buy
>>> your kid one of those toys with round, square and triangle blocks and
>>> holes to match do you also buy them a saw so that any block can fit in
>>> any hole?
>>
>> There are evolutions of Wirth/ISO Pascal that can be the right tool
>> for real world programs.
>>
>> VMS Pascal and Object Pascal/Delphi as heavily extended flavors of
>> Pascal.
>>
>> Modula-2 and Ada 83 as new languages in Pascal style.
>>
>> I like Modula-2 and VMS Pascal better than Delphi and Ada 83, but YMMV.
>
> Isn't it interesting that Wirth called his new language Modula and
> not something like "New Pascal" or "Pascal-2".

He made some fundamental changes like the case sensitivity, so
he thought that it made sense.

I think it was the right decision. But some may disagree.

Arne

On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/31/2022 9:02 AM, Simon Clubley wrote:
>> On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> I would run Solaris on SPARC and I do run VMS on Alpha
>>> and keep Linux on x86-64. Are there any benefits
>>> from running Linux on a less common platform?
>>
>> One of the reasons Linux has taken off is that you can run it on
>> pretty much every single thing that is physically capable of hosting
>> it in terms of CPU power and memory/other resources.
>
> Is it?
>
> To me it seems that the industry impact of Linux is very much
> centered around x86-64 servers and ARM Android devices.
>
> Look at what Redhat and other actually support. There is a
> reason for that.
>
> Raspberry Pi is fun but it is not a B$ thing.
>

Your lack of imagination is showing, Arne. :-)

What you have listed above is just a very small section of the
Linux world. Some examples:

Linux in communications devices (routers, etc).

Linux in embedded devices in general (huge section, usage numbers wise).

Consumer distributions of Linux that people use in a home environment.

Linux kernel in phones.

Linux in teaching and research environments in general.

That last one is important for long-term growth. Why do you think DEC
and others in the old days fought so hard to get their equipment into
universities ?

It's because they turned out people familiar with the vendor's equipment
and comfortable with using it and recommending it in the workplace.
That Raspberry Pi and other things that you seem dismissive of are
part of a long-term movement that make people comfortable with using
Linux and recommending it for use elsewhere.

Simon.

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

On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/31/2022 8:42 AM, Simon Clubley wrote:
>>
>> For the same reason that OS designers moved from Fortran to C as the
>> system implementation language when C became available.
>
> I am not aware of any OS done in Fortran.
>

Anyone remember the Sperry V77 series with VORTEX II ?

I was exposed to it in secondary school. DASMR assembler for the kernel
and at least some of the userland stuff written in Fortran IV IIRC.

Also, didn't the first version of Software Tools use a Fortran version
within the book ? There was clearly a demand for it before C got established.

>
> C is a good language for OS kernel.
>
> I don't see it as particular well suited for user land utilities.
> C's low level features are not needed and just add risk.
>

Oh, I strongly agree that there are better options for userland stuff
than C. The only question is what is mainstream enough to be a viable
alternative when you consider the global nature of C and the fact that
there is a C compiler for _everything_ ?

Any alternative needs to be popular enough and have enough support
in general across multiple architectures and operating systems that
it becomes an asset to the operating systems using it and not a liability.

Simon.

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

On 1/31/2022 12:29 PM, Bill Gunshannon wrote:
> On 1/31/22 03:25, Johnny Billquist wrote:
>> On 2022-01-31 01:22, Simon Clubley wrote:
>>> On 2022-01-29, Scott Dorsey <kludge@panix.com> wrote:
>>>>
>>>> Pascal is pretty limited but makes it hard to shoot yourself in the foot.
>>>> And most implementations don't use null-terminated strings which are the
>>>> most serious source of vulnerabilities in C code.
>>>> --scott
>>>>
>>>
>>> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>>
>> The problem is that the ISO standard for Pascal is pretty useless.
>
> Pretty useless for what? Tasks for which the language was not designed?
>
>> Which is
>> why every useful Pascal have extensions...
>> And they are all different...
>> Which makes everything very non-standard...
>
> Thus the reason they should have come up with new names and not called
> themselves Pascal, which they were not.
>
>>
>> But Pascal is definitely not that bad a language. But it has it's warts...
>
> Pascal is ideal for what it was designed for. Too bad people still
> don't understand the concept of "choose the right tool for the job".

What about a "jack of all trades" that can do any job?

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

On 2022-01-31, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 1/31/22 08:42, Simon Clubley wrote:
>> On 2022-01-31, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>>> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley
>>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>> Fortran and COBOL are not suitable for writing operating system userland
>>>> tools.
>>>
>>> Why not?
>>>
>>
>> For the same reason that OS designers moved from Fortran to C as the
>> system implementation language when C became available. C is simply
>> a better language than Fortran for those kinds of tasks.
>
> All of the userland in STVOS are implemented quite nicely in Fortran.
> (Well, Ratfor actually, but then the Fortran compiler makes them
> functional.)
>

Was that before or after C became established in general use ?

Simon.

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

On 1/31/2022 2:05 PM, Simon Clubley wrote:
> On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/31/2022 9:02 AM, Simon Clubley wrote:
>>> On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> I would run Solaris on SPARC and I do run VMS on Alpha
>>>> and keep Linux on x86-64. Are there any benefits
>>>> from running Linux on a less common platform?
>>>
>>> One of the reasons Linux has taken off is that you can run it on
>>> pretty much every single thing that is physically capable of hosting
>>> it in terms of CPU power and memory/other resources.
>>
>> Is it?
>>
>> To me it seems that the industry impact of Linux is very much
>> centered around x86-64 servers and ARM Android devices.
>>
>> Look at what Redhat and other actually support. There is a
>> reason for that.
>>
>> Raspberry Pi is fun but it is not a B$ thing.
>
> Your lack of imagination is showing, Arne. :-)
>
> What you have listed above is just a very small section of the
> Linux world. Some examples:
>
> Linux in communications devices (routers, etc).
>
> Linux in embedded devices in general (huge section, usage numbers wise).
>
> Consumer distributions of Linux that people use in a home environment.

I don't know how much of that runs Linux vs VxWorks, IOS (not to be
confused with iOS) or something else. It is probably a lot
of units, but to me it i sort of "so what".

> Linux kernel in phones.

That one I actually did mention.

> Linux in teaching and research environments in general.
>
> That last one is important for long-term growth. Why do you think DEC
> and others in the old days fought so hard to get their equipment into
> universities ?
>
> It's because they turned out people familiar with the vendor's equipment
> and comfortable with using it and recommending it in the workplace.
> That Raspberry Pi and other things that you seem dismissive of are
> part of a long-term movement that make people comfortable with using
> Linux and recommending it for use elsewhere.

There were a lot of focus on that 30-40 years ago.

The world has changed.

There does not seem to be much correlation between what systems
people use during education and what enterprise IT is choosing.

People learn Windows, macOS, Android, iOS etc. and the companies
use Linux, containers, cloud etc..

Arne

On 2022-01-31, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 1/31/22 09:02, Simon Clubley wrote:
>> On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> I would run Solaris on SPARC and I do run VMS on Alpha
>>> and keep Linux on x86-64. Are there any benefits
>>> from running Linux on a less common platform?
>>>
>>
>> One of the reasons Linux has taken off is that you can run it on
>> pretty much every single thing that is physically capable of hosting
>> it in terms of CPU power and memory/other resources.
>>
>> This includes large mainframes all the way down to tiny embedded boards
>> running on some custom hardware/architecture.
>>
>
> The same is probably true of just about any OS. All it takes is
> access to the source and a desire by someone to do the work. Why
> do you think I would still like to see the source to RSTS released
> into the wild. RSX which was very PDP-11 specific now has a version
> running on later Z80 family processors. I have it running here at
> my home and it works quite well.
>

The OS needs to be designed to be portable and also with the architecture
specific features abstracted away into a lower level as much as possible
to stand any chance of that being true.

Linux was designed for that (and so were OS options such as the various
dedicated embedded operating systems). Windows NT was also originally
designed somewhat with portability in mind as well.

The DEC operating systems however were not designed with that level
of portability in mind due to the era in which they were designed.

Simon.

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