On Sun, 21 Feb 2021 at 03:51, <ken.dickey at whidbey.com> wrote:
>
> I responded directly to Liam, but noted a lof of interest on this list..

Did you? May I ask -- to which address?

> -------- Original Message --------
> ..
> Liam,
>
> I noted your post on the Squeak mailing list and enjoyed the FOSDEM
> slides.
>
> I happen to have been at Apple during the 90's and have experience
> writing in SK8Script, NewtonScript, Dylan, MacLisp,  ScriptX, and
> Smalltalk (among others).  Glad to see someone notice these things.

Oh my word, that's quite a back-catalogue! I am impressed.

I generally find -- and this time is no exception -- that Lisp folk
are _strongly_ resistant to any suggestion that perhaps a more
conventional syntax, layered on top of a conventional prefix-notation
Lisp, would make it a lot more accessible to a lot more people.

One objection to this is that it significantly impedes the use of Lisp
macros. On the other hand, many former Lispers are now enthusiastic
about various modern xNix scripting languages that in recent versions
include closures, lambda calculus and so on, and yet none of these can
use Lisp-type macros.

I suspect that while Lisp's macros are immensely powerful, at least
potentially, they might also make it very hard to read and debug
someone else's code, and therefore not be ideal for cooperative team
development... And that is a sad commercial necessity.

But this is not germane to the Smalltalk side of my proposal. ;-)

> A couple of thoughts..
>
> Device drivers are, for me, complex and painful.

I am sure you're not alone.

> Not considering device drivers as my value added area, my thought was to
> use a "shim" OS, so I got the vm-display-fbdev (frame-buffer display) up
> for use with Alpine Linux (MUSL + Busybox).  I am primarily a Cuis
> Smalltalk user (I like small; Note class counts in
> https://github.com/Cuis-Smalltalk/Learning-Cuis) but Squeak works here
> as well.

I have played around with Alpine a little, but even a lightweight
Linux is still a formidable amount of code, and therefore will still
need frequent updates and so on. That's part of what I wanted to break
away from.

Secondly, I was trying to look to the future, to an OS that could run
well on a machine with only RAM and persistent memory, without disk
drives or anything pretending to be disk drives.

I seriously think that in time PMEM could turn the notion of disk
drives into legacy technology, as obsolete as tape drives -- i.e.
still relevant for big enterprise servers, but completely gone from
typical end-user devices.

Thirdly, I suspect that keeping any element of existing technology
stacks -- for instance, such as a bare-metal shim OS implemented in C
-- will preserve some of the many problems with the existing stack,
and represent a temptation to import other bits of the stack as well.

> Ultibo.org is an interesting Free Pascal based unikernel for Raspberry
> Pi's.  Makes use of multicores.

I am aware of it. I have a copy, and have installed Free Pascal and
Lazarus, and am trying to revive dusty corroded memories of Pascal
coding in the 1980s...

I was hoping to resurrect my corroded skills -- meagre at the time --
by trying to do some bare-metal vintage-computer emulation. Both the
Sinclair QL and Atari ST operating systems have completely FOSS
derivatives these days, and getting them running on the RasPi would be
fun. But probably far beyond my skills... :-( There is not much
existing code to draw upon: Delphi was not a popular tool for writing
emulators.

> Detecting and recovering from driver SW and HW failures is critical to
> robustness.

This is true.

> Minix3.org is a microkernel whose Reincarnation Server can reload failed
> drivers.

It is, but it's still an *nix. _Heavily_ filesystem-centric,
implemented in C, not yet multicore capable, and anyway, it is its own
thing and doing just fine. Most widely-deployed x86 xNix as it is in
every recent Intel CPU.

> Erlang's HydrOS is meant to deal with HW failures
> (http://www.erlang-factory.com/static/upload/media/1498583896660864samwilliamshowtobuildanoswitherlang_awhistlestoptourofhydros.pdf
> )

OK, this one is new to me! Erlang is a bit niche, though, and as I
understand it, the price of its resilient multiprocess model is that
it is quite slow...

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