On Sun, 21 Feb 2021 at 19:44, tim Rowledge <tim at rowledge.org> wrote:
>
> I'm pretty sure that with sufficient time, determination, staff, and luck, one could write a full stack of software in any language at all. I mean, I've been involved in a few (partial) attempts over the decades.

Point conceded. I would submit that the core thing is perhaps a
_single_ language, and one that is simple and accessible enough for
children, adult learners, amateurs, part-timers and so on. One that
won't blow your foot of if you fail to dereference a pointer or access
the 42nd element of a 40-element array.

>  RISC OS was almost entirely written in ARM assembler, even a lot of the applications.

Sure, but that's not really a good thing, IMHO.

It remains possible; e.g.
http://www.kolibrios.org/en/
http://menuetos.net/

That it's possible doesn't mean it's a good idea. Remember, Acorn
originally tried using Modula-2:
https://en.wikipedia.org/wiki/ARX_(operating_system)


> The Interval MediaPad was Smalltalk all the way down to process scheduling and interrupt handling. And so on.

Do tell? Google draws a blank.

> I guess that my engineering/designer ethos is simply happier to suggest that saving time by avoiding the tedious bits someone has already done is a good way of getting to do the fun bits. Of course, it does depend on what one considers 'the fun bits'. For me, that is doing stuff in Smalltalk, frequently the doing stuff *to* Smalltalk part.
>
> I'm content to consider those lowest level bits as very large primitives and then just use them. There's absolutely no reason I can think of why we shouldn't have a world where lower level bits get gradually replaced by Smalltalk whilst other users keep on 'talking. Indeed I remember a nice example from ... a long time ago... when Eliot realised that the RISC OS filesystem code provided sufficiently low level commands that he could make a DOS format read/write filestream class for an OS that used a decidedly 'interesting' file format natively.

Interesting!

> Consider this as a suggestion to remember the protocol for eating an Elephant (not that one should actually do that; they get quite annoyed) - don't try to swallow it all at once. We have a rather good language system in Smalltalk. Linux is a not appalling stratum to build over; start by perhaps replacing some of the insane numbers of unix applications filling /usr/bin etc. Gradually infiltrate and push down and out and up. Eventually there's nothing left but the POST and initial loader, the rest just gets garbage collected.

I disagree.

For instance, firstly, this does seem to be what the systemd project
is largely doing. It is causing a lot of alienation and anger.

Secondly, this way you can never escape from the core assumptions,
which is precisely what I am trying to do.

As a parallel example: ISTM that the GNOME team are trying to design a
simple, almost smartphone-like desktop for Linux by slowly & gradually
rewriting a Windows-95 like desktop, implemented in plain ol' C,
removing features that they do not use and therefore deem unnecessary.
Personally I find the result an unusable mess and it's caused a lot of
people to desert to other desktops, massively splintering the Linux
desktop space and seriously damaging Linux. Worse still, due to
absence of ideas and knowledge, most of the new alternatives are just
other rip-offs of Win95. Poor ones, but with a lot of chrome.

> Yes, the idiotic tyranny of the unix 'everything is a file' approach has a long tail and needs winding up and hanging in the back of the 'weird ideas from the primitive past' cupboard.

Well, ISTM that you won't ever get there by piecemeal replacing bits
of Linux, file-by-file.

> The one thing good about it is that the *consistency* provided a lot of leverage. Rather like the consistency of 'everything is an object; yes, even that' for Smalltalk.

Plan 9 took this a lot further. It got nowhere, to a first approximation.

> I am minded of a Wise Saying from the Very Wise Alan Knight -
>
> `One of the great leaps in OO is to be able to answer the question “How does this work?” with “I don’t care”.`[1]
>
> Sometimes it is more practical to accept there isn't enough time to know it all. I had to give up trying to understand the details of CPU design some years ago and just let it be something I use. Now, I will certainly cheer loudly if someone comes up with a way to simplify things enough to solve all this; I'm just not going to hold my breath since blue is such a bad choice of colour for my face.

Which again flies in the face of C, which wants you to know and
understand how CPUs work. Worse still, the CPU in question being a
mid-1970s PDP-11.

> My thought these days is to skip the attempts to have a single memory space shared between threads/cores/whatever and have many separate systems running and communicating. Yes, it may be 'less performant' to pass bits down whatever variety of damp string required, but so what. Computers are better than 10 million times faster today than they were when we did BrouHaHa on RISC OS and the Active Book. Let's have a 512 core AARCH64 machine running 1500 images. In your pocket (admittedly right now a fairly large and well cooled pocket).

Sounds good but I lack enough knowledge of Smalltalk (yet, if I'm
lucky) to judge how feasible it is.

My objectives were to try to propose a new way to build a new OS based
solidly on existing FOSS tools and technology, and not to reinvent yet
more wheels.

> I'd also point back to some of Alan's early writings about Smalltalk being a like collection of biological cells with the 'cell walls' isolating each from the other and communication being by (chemical) messages. Separate worlds seem much better implemented in separate memory spaces to me.

Perhaps so.

> [1] My most famous Wise Saying is probably "An x86 cpu is a waste of perfectly good sand", dating from circa 1985 when I first got ARMed. People laughed back then. Not so much now.

:-)

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lproven at cix.co.uk – gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053