Good opportunity for a free pascal operating system...

[Bogen85]

In retrospect, it is universally agreed that Ts'o overreacted. However I think it's fair to add that he should not be interpreted as accusing the Rust for Linux sub-project as "getting everyone to switch over to Rust": what he said was "switch over to the religion", not to the language.

Yeah.... That was quite the rant... I do get where he is coming from, however...

It was quite over the top and that is putting it mildly!

So as far as the Linux kernel is concerned, that particular episode was a bit of a storm in a teacup. However I think it also highlights something important which impinges on the Pascal community: there are software developers who still- after 50 years of gradual improvement in most languages- are resolutely opposed to the idea that strong type handling and well-defined APIs are actually there to help people.

Yes, completely agreed. Which is why so many are investing in new Rust development and also in porting code written in slower or less strict languages to Rust  (Amazon, Microsoft, Meta, and many others).

However, the void pascal would have had been (and to a lesser degree still might be) able to fill in the software development world is now overshadowed by the momentum and strong push towards Rust, which IS rapidly filling that void.

And Rust is far stricter than Pascal, and that strictness in enforced by the compiler to a much greater degree than it is in Pascal.

[MarkMLl]

Yes, completely agreed. Which is why so many are investing in new Rust development and also in porting code written in slower or less strict languages to Rust  (Amazon, Microsoft, Meta, and many others).

However, the void pascal would have had been (and to a lesser degree still might be) able to fill in the software development world is now overshadowed by the momentum and strong push towards Rust, which IS rapidly filling that void.

And Rust is far stricter than Pascal, and that strictness in enforced by the compiler to a much greater degree than it is in Pascal.

I came across https://lobste.rs/s/noerku/moving_my_game_project_from_c_odin earlier, where the language being discussed is basically a reinvented Pascal.

I've got reservations about Rust: in some ways it's moving too far from the ALGOL model where accessibility is defined by scope... until of course you start doing something with the heap :-/

I think that a minimised and cleaned up Pascal would have a lot going for it: no automatic type conversions except possibly for untyped numeric constants, take a very hard look at all heap usage to see what (if anything) can be learnt from Rust, and so on.

MarkMLl

[Bogen85]

I came across https://lobste.rs/s/noerku/moving_my_game_project_from_c_odin earlier, where the language being discussed is basically a reinvented Pascal.

I skimmed through it, I'll try to read it more later. Some of the points did pop out at me (npm style crates) as that has gotten out of hand. For the RHEL clones they attempt they contain that in EPEL (and regular Fedora) and bring some sanity to that chaos, but this does not help out all the Linux distros where devs have package supply chain trust concerns.

I've got reservations about Rust: in some ways it's moving too far from the ALGOL model where accessibility is defined by scope... until of course you start doing something with the heap :-/

I've got reservations about Rust as well. I understand what they are doing accessibility wise, but it took me a quite a while to get my head wrapped around it and understand what was being done and way, and to get it accept new code right away.

I think that a minimised and cleaned up Pascal would have a lot going for it: no automatic type conversions except possibly for untyped numeric constants, take a very hard look at all heap usage to see what (if anything) can be learnt from Rust, and so on.
MarkMLl

Agreed. Quite a bit of the resistance to rust is the extremes they went to control access and lifetimes, when it seems (to me) like their could have been a more relaxed way to achieve something just as safe.

[carl_caulkett]

I think that a minimised and cleaned up Pascal would have a lot going for it: no automatic type conversions except possibly for untyped numeric constants, take a very hard look at all heap usage to see what (if anything) can be learnt from Rust, and so on.

Did you ever come across Oxygene by RemObjects - https://www.remobjects.com/elements/oxygene/? That was an attempt to move Pascal beyond some of the pain points that we have just become accustomed to tolerate 😉

[duralast]

So many options! No one has to start from scratch!

There is Glendix, which is the Plan 9 userland and Linux kernel.
Plan 9 itself.
Inferno that Bell Labs based on Plan 9 for set top boxes.
Clive by Francisco Ballesteros which is based on Plan 9.
Nix, also by Francisco Ballesteros.
Octopus, another OS also from Francisco Ballesteros.
Plan B, yet another OS from Franciso Ballesteros.
9atom by Erik Quanstrom, based on Plan 9.
XINU by Douglas Comer.
9front, forked from Plan 9.
Minix by Andrew Tanenbaum.
Oberon, the operating system.
AOS/Bluebottle/A2 based on Oberon.
Jehanne based on Plan 9.
Harvey based on Plan 9.
Akaros based on Plan 9.
And the BSDs.
Bitrig was based on OpenBSD, but it didn't last long before maintaining it was dropped.
OpenIndiana based on OpenSolaris.
illumos was forked from OpenSolaris.
SmartOS which uses illumos.

In addition to the operating systems mentioned written in Pascal, of course.

Of course, those above would all have to be rewritten in Pascal since they are mostly written in C. Actually, I think Oberon and the AOS/Bluebottle/A2 are the only ones not written in C.

But importantly, none of them are fully fledged operating systems that can run the peripheral devices today. Minix hasn't been updated in something like three years, I believe after Tanenbaum retired. Akaros is another university project that I believe has stalled or ended. It takes a lot of effort to maintain an operating system.

As for the demise of Linux? Not going to happen. Too much relies on Linux now. And to create a new operating system and then get applications written for it is a decades long endeavor. OS X is only about 5% market share.

[duralast]

Almost forgotten the Apple Pascal Operating System?

https://en.wikipedia.org/wiki/Apple_Lisa
According to the Wiki article, Apple spent $50 million (in the late 70s/early 80s), to develop Lisa, which involved more than 90 people.

[duralast]

Which is why so many are investing in new Rust development and also in porting code written in slower or less strict languages to Rust  (Amazon, Microsoft, Meta, and many others).

Oxide Computer, started by Brian Cantrill, who was at one time a Solaris kernel developer for Sun Microsystems, uses Rust as their systems programming language.

https://www.p99conf.io/2022/09/19/bryan-cantrill-on-rust-and-the-future-of-low-latency-systems/
A video of Cantrill explaining why he believes the future of low-latency systems will include Rust programs in some surprising places.

[dbannon]

I think that a minimised and cleaned up Pascal would have a lot going for it: no automatic type conversions except possibly for untyped numeric constants.....

and variants, generics ....

Mind you, I was made to learn Ada at Uni, it felt like a "cleaned up" pascal. And, honestly, I hated it for that reason, it was boring to use. In theory, we were told, every programmer in the room would come up with the same code for a given function spec.

But, of course, I now program because I enjoy it, not to earn a living.

Davo

[PierceNg]

So many options! No one has to start from scratch!
Of course, those above would all have to be rewritten in Pascal since they are mostly written in C. Actually, I think Oberon and the AOS/Bluebottle/A2 are the only ones not written in C.

Instead of writing yet more operating systems from scratch, porting FPC (and then Lazarus?) to some of these already up-and-running operating systems to enable app and system programming in Pascal might also be interesting undertakings:

- https://serenityos.org/
- https://menuetos.net/
- http://kolibrios.org/en/index - This one has something called Pascal Pro

[duralast]

Clive is an operating system designed for distributed and cloud computing, and is based on Plan 9 and Nix (also based on Plan 9).

Clive uses a modified Go compiler.

Doesn't that also hold true for operating systems written in C or Pascal or another language, in that it requires a modified C or Pascal compiler?

[MarkMLl]

Did you ever come across Oxygene by RemObjects - https://www.remobjects.com/elements/oxygene/? That was an attempt to move Pascal beyond some of the pain points that we have just become accustomed to tolerate 😉

It's still a bit overlarge to my mind. We need to be stripping things down at the core language level so that the maintainers have (far) fewer problems with interactions etc.

MarkMLl

[MarkMLl]

So many options! No one has to start from scratch!

And have you every tried getting one of those to a state where it can run a browser sufficient to connect to somebody's bank account?

MarkMLl

[MarkMLl]

and variants, generics ....

Do we need generics in the core language, or could we do that using sets of types?

Mind you, I was made to learn Ada at Uni, it felt like a "cleaned up" pascal.

Hardly surprising, since the initial designers (contracted to the DoD) were the authors of the ALGOL-68 "Minority Report".

MarkMLl

[PascalDragon]

Aside from this event probably only being a footnote in the history of Linux, do you even have a remote idea of what amount of work goes into developing a general purpose operating system? Neither Linux nor Window nor macOS came into being as they are now in a short time, they've all been worked on for decades. At the company I work at we develop our own operating system (in C++) that is underpinning our products and it's definitely a more complete and general purpose operating system than many of the toy operating system around, but despite being twenty years old it still has some way to go.

Not sure about you, but I'd estimate that the basic bring-up for an arbitrary chip is 6 months for one person (i.e. to the point where it can trap exceptions without supplemental hardware debugging). Follow that with somebody working for another six months to get a basic process switcher working, and somebody else on the memory manager. Follow that with lots of people working for a week or so at a time for each basic peripheral... you're very rapidly getting into many man-years, and that's obviously with the benefit of "knowing how to do it" since many architectures have followed the same path over the last 50 years.

MarkMLl

We do not need to write many of the parts of the operating systems. We just need a system good enough to emulate the api's of other operating systems like windows and linux. i.e. win api and posix. Even have dosbox to run dos apps. kolibri uses dosbox to run dos apps. freebsd emulates the posix api's to run linux apps. So you just need a base system to map the api's.

And you think what is required to emulate the API of an existing operating system is nothing? Not to mention that you still require device drivers or enough infrastructure to be able to use existing driver which again comes back to the first part. So again, you're seriously underestimating the work involved.

[MarkMLl]

And you think what is required to emulate the API of an existing operating system is nothing? Not to mention that you still require device drivers or enough infrastructure to be able to use existing driver which again comes back to the first part. So again, you're seriously underestimating the work involved.

Linux originally had emulations for the dominant unix on each target, which is why the syscall numbers are inconsistent. I think that aspiration was dropped a decade or more ago.

Win-16 was eventually standardised by ECMA, well after it was obsolete. I'm still extremely skeptical that the standard was even minimally authoritative.

I'd be surprised if either Win-32 or Win-64 were ever standardised, at least while their broodmother considered them relevant to its business model... and I'd still be extremely skeptical that the standard was even minimally authoritative.

And as an internal API the device driver interface is somewhat fluid...

I'm definitely not rubbishing the original idea, any more than I would rubbish "peace on Earth, and goodwill to all men".

MarkMLl