On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/31/2022 2:05 PM, Simon Clubley wrote:
>> Linux kernel in phones.
>
> That one I actually did mention.
>

Yes, you did. My mistake, sorry.

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/22 14:22, Simon Clubley wrote:
> 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.

Some of the Primos "Userland" was in Fortran. I have used a number of
editors that were written in Fortran. Also graphics libraries and
at least one database system.

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

Ratfor, actually. But that means a Fortran compiler. I just
mentioned STVOS a few messages earlier. For those who don't
know what that means, Software Tools Virtual Operating System.
POSIX before there was a POSIX. Ran on damn near anything
including VMS.

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

And, it has to be easy to bootstrap onto a new architecture. Unless
it's been decided that we have reached the end of that line and there
aren't going to be any new architectures. :-)

bill

On 1/31/22 14:33, Dave Froble 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.
>>
>>>
>>> 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?

Like choosing the wrong language for a task a "jack of all trades"
is famous for doing everything, but none of the tasks well. It is
not a compliment to be called one.

bill

In article <61f81e10$0$706$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

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

Considering that essentially all of Fortran 77 works in Fortran 90, then
a name change would be bad. I've heard about other new, popular
languages which don't respect backward compatibility. :-)

On 1/31/22 14:43, Simon Clubley wrote:
> 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.

You must have missed it. RSX was not designed to be portable but
someone was able to build a clone on the higher end Z80 family.

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

Linux was designed (if you can even say that) to imitate Unix,
nothing more. I seriously doubt Linus Torvald had any idea
that it would be running on anything other than Intel at the
time he was writing it.

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

And yet we have a clone of RSX and if I had the sources available
to me we would also have a clone of RSTS. And, if anyone was really
interested, I expect RT-11 could be cloned in a very short time, too.

Seriously, it's not rocket science. Unless one deliberately made the
hardware obscure and obtuse the OS is really going to be something
any CS grad could deal with. The only thing protecting proprietary
OSes is obscurity and a total lack of interest.

bill

On 1/31/2022 4:10 PM, Phillip Helbig (undress to reply) wrote:
> In article <61f81e10$0$706$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>
>> But Fortran 77 to 90 was more than the typical version change. I think
>> it could have justified a name change.
>
> Considering that essentially all of Fortran 77 works in Fortran 90, then
> a name change would be bad.

Fortran 77 code build with Fortran 90 compilers, but how Fortran 90 was
intended to be written is very different from Fortran 77, and a lot
of Fortran 77 features were declared obsolete and to be removed
in a future version (and some were actually removed in 95, other are
still waiting to be axed).

> I've heard about other new, popular
> languages which don't respect backward compatibility. :-)

Not so common.

Some accidental stuff when the keywords in new features collide with
user identifier in old code. A lot of Java developers had used 'enum'
as identifier before Java 5 in 2004.

Some old RTL functionality being removed. Classic is PHP
removal of mysql extension in PHP 7.

Real language breaking changes are rare.

Python division from 2.x to 3.x may be the best known example.

C# 7 to 8 non-nullable reference types was a big change but it
could be turned on/off at compilation.

Arne

On 1/31/22 14:35, Simon Clubley wrote:
> 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 ?
>

Paper was published in September 1980 CACM. Can't say when C spread
throughout the world but I can tell you by 1980 it ran on every
system I worked on except the Terak. :-)

And, it's irrelevant anyway. Your comment was that Fortran was
unsuitable and the fact that all of the userland and all of the
primitives needed to make this possible were, in fact, written
in Fortran.

bill

In article <61f854ec$0$692$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

> >> But Fortran 77 to 90 was more than the typical version change. I think
> >> it could have justified a name change.
> >
> > Considering that essentially all of Fortran 77 works in Fortran 90, then
> > a name change would be bad.
>
> Fortran 77 code build with Fortran 90 compilers, but how Fortran 90 was
> intended to be written is very different from Fortran 77, and a lot
> of Fortran 77 features were declared obsolete and to be removed
> in a future version (and some were actually removed in 95, other are
> still waiting to be axed).

Right, but changind the name would have been misleading.

> > I've heard about other new, popular
> > languages which don't respect backward compatibility. :-)
>
> Not so common.

Python is common. :-|

> Python division from 2.x to 3.x may be the best known example.

Right. It is also THE hip, hit-the-right-buzzword language for all the
young dudes.

On 1/31/2022 4:17 PM, Bill Gunshannon wrote:
> On 1/31/22 14:43, Simon Clubley wrote:
>> 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.
>
> Linux was designed (if you can even say that) to imitate Unix,
> nothing more.  I seriously doubt Linus Torvald had any idea
> that it would be running on anything other than Intel at the
> time he was writing it.

There is evidence to support that.

The original Linux announcement said:

<quote>
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.
....
It is NOT portable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that's all I have
</quote>

But it did get ported to Alpha and SPARC after 4 years. I believe
Digital gave him a DS20.

>> The DEC operating systems however were not designed with that level
>> of portability in mind due to the era in which they were designed.
>
> And yet we have a clone of RSX and if I had the sources available
> to me we would also have a clone of RSTS.  And, if anyone was really
> interested, I expect RT-11 could be cloned in a very short time, too.
>
> Seriously, it's not rocket science.  Unless one deliberately made the
> hardware obscure and obtuse the OS is really going to be something
> any CS grad could deal with.  The only thing protecting proprietary
> OSes is obscurity and a total lack of interest.

A simple 60's or 70's OS may not be a big task, but modern OS'es
has become very complex.

Expect something like 50 MLOC. And a price tag on the bad side
of 10 B$.

Arne

On 1/31/2022 4:35 PM, Phillip Helbig (undress to reply) wrote:
> In article <61f854ec$0$692$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>>> But Fortran 77 to 90 was more than the typical version change. I think
>>>> it could have justified a name change.
>>>
>>> Considering that essentially all of Fortran 77 works in Fortran 90, then
>>> a name change would be bad.
>>
>> Fortran 77 code build with Fortran 90 compilers, but how Fortran 90 was
>> intended to be written is very different from Fortran 77, and a lot
>> of Fortran 77 features were declared obsolete and to be removed
>> in a future version (and some were actually removed in 95, other are
>> still waiting to be axed).
>
> Right, but changind the name would have been misleading.

I don't agree.

>>> I've heard about other new, popular
>>> languages which don't respect backward compatibility. :-)
>>
>> Not so common.
>
> Python is common. :-|
>
>> Python division from 2.x to 3.x may be the best known example.
>
> Right. It is also THE hip, hit-the-right-buzzword language for all the
> young dudes.

True.

But the change was very public. So whoever needed
to change / to // hopefully got it changed.

I think the change was a mistake. But they did it.

And it was rather unique.

Arne

On 1/31/2022 3:26 PM, Bill Gunshannon wrote:
> On 1/31/22 14:33, Dave Froble 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.
>>>
>>>>
>>>> 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?
>
> Like choosing the wrong language for a task a "jack of all trades"
> is famous for doing everything, but none of the tasks well. It is
> not a compliment to be called one.

Why do you ass-u-me that just because a language is versatile, that it cannot do
things well? Do you have examples? Any real facts? Or just bullshit?

--
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 Monday, January 31, 2022 at 12:42:18 PM UTC-5, 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 <klu...@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
VMS Pascal will compile "Wirth" Pascal just fine. Borland/Delphi Pascal will not.

On 2022-01-31 18:39, Bill Gunshannon 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 Z80 RSX implementation has pretty little to do with the PDP-11 RSX
sources. So I think it's pretty incorrect to claim you need the sources
of X to do some implementation giving similar functionality on different
hardware.

But you are right that it does require the desire to do the work. Linux
is an example of this. Linus wanted something Unix like, but couldn't
use the existing software, so he rewrote it based on the public APIs.
User applications compile and work fine (usually) on both Linux and
Unix, even though the internals sometimes are rather different.

Johnny

On 2022-01-31 22:17, Bill Gunshannon wrote:
> On 1/31/22 14:43, Simon Clubley wrote:
>> 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.
>
> You must have missed it.  RSX was not designed to be portable but
> someone was able to build a clone on the higher end Z80 family.

No. It's not a port. It's a reimplementation.
Which is not even compatible in any meaningful sense of the word.

>> 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.
>
> Linux was designed (if you can even say that) to imitate Unix,
> nothing more.  I seriously doubt Linus Torvald had any idea
> that it would be running on anything other than Intel at the
> time he was writing it.

Correct.

>> The DEC operating systems however were not designed with that level
>> of portability in mind due to the era in which they were designed.
>
> And yet we have a clone of RSX and if I had the sources available
> to me we would also have a clone of RSTS.  And, if anyone was really
> interested, I expect RT-11 could be cloned in a very short time, too.

We covered this a long time ago. You don't need the RSTS/E sources to
write a new implementation of it. You just need time and energy.

Same as for that Z80 RSX implementation.
It's not a "clone". There are significant differences. Not the least
because the hardware is very different.

> Seriously, it's not rocket science.  Unless one deliberately made the
> hardware obscure and obtuse the OS is really going to be something
> any CS grad could deal with.  The only thing protecting proprietary
> OSes is obscurity and a total lack of interest.

Actually, making use of hardware specific features can be a big issue.
With RSX, plenty use is made of the MMU and you have basically no chance
of "porting" RSX to anything that don't have a very similar MMU.
Instead you will then need to do a reimplementation where some things
needs to be done rather differently.

Johnny

On 1/31/2022 9:28 AM, Arne Vajhøj wrote:
> On 1/31/2022 8:42 AM, 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.
>
> I am not aware of any OS done in Fortran.

Note: a few have been mentioned now - some that I had never heard of
and one that I was not aware was Fortran.

> And the world did not switch to C for OS development when C was
> invented. That happened 10-20 years later.

Clarification: when I wrote "the world" here I meant more than
just Unix that switched to C in 1973.

Arne

On 1/31/22 16:35, Phillip Helbig (undress to reply) wrote:
> In article <61f854ec$0$692$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>
>>>> But Fortran 77 to 90 was more than the typical version change. I think
>>>> it could have justified a name change.
>>>
>>> Considering that essentially all of Fortran 77 works in Fortran 90, then
>>> a name change would be bad.
>>
>> Fortran 77 code build with Fortran 90 compilers, but how Fortran 90 was
>> intended to be written is very different from Fortran 77, and a lot
>> of Fortran 77 features were declared obsolete and to be removed
>> in a future version (and some were actually removed in 95, other are
>> still waiting to be axed).
>
> Right, but changind the name would have been misleading.
>
>>> I've heard about other new, popular
>>> languages which don't respect backward compatibility. :-)
>>
>> Not so common.
>
> Python is common. :-|
>
>> Python division from 2.x to 3.x may be the best known example.
>
> Right. It is also THE hip, hit-the-right-buzzword language for all the
> young dudes.
>

PHP frequently broke old programs with new releases.

bill

On 1/31/22 19:04, Dave Froble wrote:
> On 1/31/2022 3:26 PM, Bill Gunshannon wrote:
>> On 1/31/22 14:33, Dave Froble 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.
>>>>
>>>>>
>>>>> 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?
>>
>> Like choosing the wrong language for a task a "jack of all trades"
>> is famous for doing everything, but none of the tasks well.  It is
>> not a compliment to be called one.
>
> Why do you ass-u-me that just because a language is versatile, that it
> cannot do things well?  Do you have examples?  Any real facts?  Or just
> bullshit?
>
>

I don't assume it. At one time, when languages were more domain
specific, it was a known factor of program development. There was
a reason why when I started in this business my title was not just
Programmer but Programmer/System Analyst. One would have hoped
that the formalization of "Software Engineering" would have kept
the idea in vogue, but, alas, no.

bill

On 1/31/22 19:53, Johnny Billquist wrote:
> On 2022-01-31 22:17, Bill Gunshannon wrote:
>> On 1/31/22 14:43, Simon Clubley wrote:
>>> 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.
>>
>> You must have missed it.  RSX was not designed to be portable but
>> someone was able to build a clone on the higher end Z80 family.
>
> No. It's not a port. It's a reimplementation.
> Which is not even compatible in any meaningful sense of the word.
>
>>> 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.
>>
>> Linux was designed (if you can even say that) to imitate Unix,
>> nothing more.  I seriously doubt Linus Torvald had any idea
>> that it would be running on anything other than Intel at the
>> time he was writing it.
>
> Correct.
>
>>> The DEC operating systems however were not designed with that level
>>> of portability in mind due to the era in which they were designed.
>>
>> And yet we have a clone of RSX and if I had the sources available
>> to me we would also have a clone of RSTS.  And, if anyone was really
>> interested, I expect RT-11 could be cloned in a very short time, too.
>
> We covered this a long time ago. You don't need the RSTS/E sources to
> write a new implementation of it. You just need time and energy.
>
> Same as for that Z80 RSX implementation.
> It's not a "clone". There are significant differences. Not the least
> because the hardware is very different.
>
>> Seriously, it's not rocket science.  Unless one deliberately made the
>> hardware obscure and obtuse the OS is really going to be something
>> any CS grad could deal with.  The only thing protecting proprietary
>> OSes is obscurity and a total lack of interest.
>
> Actually, making use of hardware specific features can be a big issue.
> With RSX, plenty use is made of the MMU and you have basically no chance
> of "porting" RSX to anything that don't have a very similar MMU.
> Instead you will then need to do a reimplementation where some things
> needs to be done rather differently.

But if you moved to a system with a large address space would
an MMU even be necessary? BSD on the PDP_11 uses overlays,
the VAX does not.

bill

On 1/31/22 19:48, Johnny Billquist wrote:
> On 2022-01-31 18:39, Bill Gunshannon 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 Z80 RSX implementation has pretty little to do with the PDP-11 RSX
> sources. So I think it's pretty incorrect to claim you need the sources
> of X to do some implementation giving similar functionality on different
> hardware.

That's true, but it would make it a lot easier. All you really need
is very good documentation of the internals (which is what I assume
the writer of RSX-120 used). I have never seen even that for RSTS
or RT-11.

>
> But you are right that it does require the desire to do the work. Linux
> is an example of this. Linus wanted something Unix like, but couldn't
> use the existing software, so he rewrote it based on the public APIs.
> User applications compile and work fine (usually) on both Linux and
> Unix, even though the internals sometimes are rather different.

Yeah, I never understood his reasoning. The BSD lawsuit was well
known to be DOA and development of BSD never paused. And then there
was MINIX with source published and even available on floppies. I
still have both my disk sets as well as the book.

bill

On 1/31/2022 8:31 PM, Bill Gunshannon wrote:
> On 1/31/22 19:53, Johnny Billquist wrote:
>> On 2022-01-31 22:17, Bill Gunshannon wrote:
>>> On 1/31/22 14:43, Simon Clubley wrote:
>>>> 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.
>>>
>>> You must have missed it. RSX was not designed to be portable but
>>> someone was able to build a clone on the higher end Z80 family.
>>
>> No. It's not a port. It's a reimplementation.
>> Which is not even compatible in any meaningful sense of the word.
>>
>>>> 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.
>>>
>>> Linux was designed (if you can even say that) to imitate Unix,
>>> nothing more. I seriously doubt Linus Torvald had any idea
>>> that it would be running on anything other than Intel at the
>>> time he was writing it.
>>
>> Correct.
>>
>>>> The DEC operating systems however were not designed with that level
>>>> of portability in mind due to the era in which they were designed.
>>>
>>> And yet we have a clone of RSX and if I had the sources available
>>> to me we would also have a clone of RSTS. And, if anyone was really
>>> interested, I expect RT-11 could be cloned in a very short time, too.
>>
>> We covered this a long time ago. You don't need the RSTS/E sources to write a
>> new implementation of it. You just need time and energy.
>>
>> Same as for that Z80 RSX implementation.
>> It's not a "clone". There are significant differences. Not the least because
>> the hardware is very different.
>>
>>> Seriously, it's not rocket science. Unless one deliberately made the
>>> hardware obscure and obtuse the OS is really going to be something
>>> any CS grad could deal with. The only thing protecting proprietary
>>> OSes is obscurity and a total lack of interest.
>>
>> Actually, making use of hardware specific features can be a big issue. With
>> RSX, plenty use is made of the MMU and you have basically no chance of
>> "porting" RSX to anything that don't have a very similar MMU.
>> Instead you will then need to do a reimplementation where some things needs to
>> be done rather differently.
>
> But if you moved to a system with a large address space would
> an MMU even be necessary? BSD on the PDP_11 uses overlays,
> the VAX does not.
>
> bill
>
>

There is a system that runs RSX without overlays. It's called VAX/VMS.

Don't people ever wonder what DEC people were thinking when they wrote VMS?

--
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 8:31 PM, Bill Gunshannon wrote:
> On 1/31/22 19:53, Johnny Billquist wrote:

>> We covered this a long time ago. You don't need the RSTS/E sources to write a
>> new implementation of it. You just need time and energy.

I really have to wonder, would anyone actually devote the time and resources to
re-implement RSTS/E?

What hardware would one choose?
What implementation language would one choose?
What would one do with it?

--
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 8:26 PM, Bill Gunshannon wrote:
> On 1/31/22 19:04, Dave Froble wrote:
>> On 1/31/2022 3:26 PM, Bill Gunshannon wrote:
>>> On 1/31/22 14:33, Dave Froble wrote:
>>>> What about a "jack of all trades" that can do any job?
>>>
>>> Like choosing the wrong language for a task a "jack of all trades"
>>> is famous for doing everything, but none of the tasks well.  It is
>>> not a compliment to be called one.
>>
>> Why do you ass-u-me that just because a language is versatile, that it
>> cannot do things well?  Do you have examples?  Any real facts?  Or
>> just bullshit?
>
> I don't assume it.  At one time, when languages were more domain
> specific, it was a known factor of program development.

> One would have hoped
> that the formalization of "Software Engineering" would have kept
> the idea in vogue, but, alas, no.

I see lots of specialization.

Most languages are only a big language within a few areas. And
even if a language is used within multiple areas then the
libraries/frameworks used are often very different).

OS - C/C++
containers - Go
servers (web, app, DB, MQ and Cache) - C/C++ or Java
client side web - JavaScript
Windows desktop apps - C# or C++
Mac desktop apps - Objective-C or Swift
iPhone and iPads - Swift
Android phones - Java or Kotlin
server side web - PHP, Python, Ruby, JavaScript, Java or C#
backend processing - Java, C++, C# or Python
data analysis - Python, R

Arne

On 1/31/22 21:37, Arne Vajhøj wrote:
> On 1/31/2022 8:26 PM, Bill Gunshannon wrote:
>> On 1/31/22 19:04, Dave Froble wrote:
>>> On 1/31/2022 3:26 PM, Bill Gunshannon wrote:
>>>> On 1/31/22 14:33, Dave Froble wrote:
>>>>> What about a "jack of all trades" that can do any job?
>>>>
>>>> Like choosing the wrong language for a task a "jack of all trades"
>>>> is famous for doing everything, but none of the tasks well.  It is
>>>> not a compliment to be called one.
>>>
>>> Why do you ass-u-me that just because a language is versatile, that
>>> it cannot do things well?  Do you have examples?  Any real facts?  Or
>>> just bullshit?
>>
>> I don't assume it.  At one time, when languages were more domain
>> specific, it was a known factor of program development.
>
>>                                            One would have hoped
>> that the formalization of "Software Engineering" would have kept
>> the idea in vogue, but, alas, no.
>
> I see lots of specialization.
>
> Most languages are only a big language within a few areas. And
> even if a language is used within multiple areas then the
> libraries/frameworks used are often very different).
>
> OS - C/C++
> containers - Go
> servers (web, app, DB, MQ and Cache) - C/C++ or Java
> client side web - JavaScript
> Windows desktop apps - C# or C++
> Mac desktop apps - Objective-C or Swift
> iPhone and iPads - Swift
> Android phones - Java or Kotlin
> server side web - PHP, Python, Ruby, JavaScript, Java or C#
> backend processing - Java, C++, C# or Python
> data analysis - Python, R

Don't confuse use for design intention. Most of those languages
had no particular purpose when designed and were just general
purpose languages.

bill

On 1/31/22 21:31, Dave Froble wrote:
> On 1/31/2022 8:31 PM, Bill Gunshannon wrote:
>> On 1/31/22 19:53, Johnny Billquist wrote:
>
>>> We covered this a long time ago. You don't need the RSTS/E sources to
>>> write a
>>> new implementation of it. You just need time and energy.
>
> I really have to wonder, would anyone actually devote the time and
> resources to re-implement RSTS/E?

I would. :-)

>
> What hardware would one choose?

Ideally, I would make it portable but initially probably PC Class
machines and a certain 6809 I have.

> What implementation language would one choose?

Probably C as that is the language I am most likely to find compilers
for on different machines.

> What would one do with it?

What do Hobbyists today do with any of the old OSes and systems they
have. I would play with it. I would look into adding networking and
probably X11.

It's all for fun anyway.

bill

On 2/1/22 08:17, Bill Gunshannon wrote:
> On 1/31/22 21:37, Arne Vajhøj wrote:
>> On 1/31/2022 8:26 PM, Bill Gunshannon wrote:
>>> On 1/31/22 19:04, Dave Froble wrote:
>>>> On 1/31/2022 3:26 PM, Bill Gunshannon wrote:
>>>>> On 1/31/22 14:33, Dave Froble wrote:
>>>>>> What about a "jack of all trades" that can do any job?
>>>>>
>>>>> Like choosing the wrong language for a task a "jack of all trades"
>>>>> is famous for doing everything, but none of the tasks well.  It is
>>>>> not a compliment to be called one.
>>>>
>>>> Why do you ass-u-me that just because a language is versatile, that
>>>> it cannot do things well?  Do you have examples?  Any real facts?
>>>> Or just bullshit?
>>>
>>> I don't assume it.  At one time, when languages were more domain
>>> specific, it was a known factor of program development.
>>
>>>                                            One would have hoped
>>> that the formalization of "Software Engineering" would have kept
>>> the idea in vogue, but, alas, no.
>>
>> I see lots of specialization.
>>
>> Most languages are only a big language within a few areas. And
>> even if a language is used within multiple areas then the
>> libraries/frameworks used are often very different).
>>
>> OS - C/C++
>> containers - Go
>> servers (web, app, DB, MQ and Cache) - C/C++ or Java
>> client side web - JavaScript
>> Windows desktop apps - C# or C++
>> Mac desktop apps - Objective-C or Swift
>> iPhone and iPads - Swift
>> Android phones - Java or Kotlin
>> server side web - PHP, Python, Ruby, JavaScript, Java or C#
>> backend processing - Java, C++, C# or Python
>> data analysis - Python, R
>
> Don't confuse use for design intention.  Most of those languages
Oops.. design for intention
> had no particular purpose when designed and were just general
> purpose languages.
>
> bill
>