[Cuis-dev] VectorEnginePlugin: parts in motion

Phil B pbpublist at gmail.com
Mon Aug 9 15:06:50 PDT 2021


Ken,

On Mon, Aug 9, 2021, 5:20 PM <ken.dickey at whidbey.com> wrote:

> On 2021-08-09 09:53, Phil B via Cuis-dev wrote:
>
> > While I appreciate the dream of a Smalltalk NOS environment, I don't
> > think most people who embark on it really think through the reality of
> > the limitations the resulting environment will end up with (both in
> > terms of device support and resulting image capabilities) or the amount
> > of work required to get there and keep it running on modern hardware.
>
> Note that there is a huge, and confusing, range of literature on "bare
> metal OS" design.
>

I've typically stuck with the traditional 'no host OS of any kind' as
that's basically what people seem to be longing to recreate (i.e. an Alto
or Lisp Machines type of experience).  You'd still have microcode and
firmware as that's unavoidable on most modern hardware unless you build
your own (i.e. FPGA etc.)


> I found a fairly clean and small open-source microkernel with good
> explanatory documentation.
>
> http://phoenix-rtos.com/documentation/README.md
>
> It only runs on a few embedded systems (arm 32 and risc-v 64), but the
> code base is compact and looks clean.
>

I wouldn't consider a RTOS a 'NOS' but see why it might be viewed as a fine
compromise vs a 'full' OS.  However, it still leaves you with most of the
same portability and device driver issues.  They wrote it for architecture
X and you need to run it on Y?  Have fun porting.  Having a predefined
device driver model doesn't really help you get your wifi device working if
no driver for it has previously been written.  IMO, that's probably what
kills most NOS initiatives: the platform and device driver support (even
for a 'minimal' subset of devices) is a hideous amount of low level work
and there's a lot more of it than most people think especially if one is
starting from fond memories of the 80s where the hardware was much less
complex.

>
> When I find the explanations confusing, I find it helpful to read the
> code, and vise versa.
>
> FYI,
> -KenD
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210809/a004f868/attachment.htm>


More information about the Cuis-dev mailing list