Re: Explaining single level store to non i people

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

Hans Boldt wrote:
> But you also avoided the point I was making, which was that, at a
> programming level, there's really nothing about the underlying
> architecture of a single level store system that the programmer has to be
> aware of. From the programmer's perspective, programming is all about
> writing open, read, write, update, and close operations.
>   
I didn't avoid it - it's just irrelevant to *my* point.  Hiding the 
complexity of the hardware from the application programmer is something 
any operating system worth the name should do.  I'm talking about that 
part of the OS that lives between the application programmer and the 
hardware - that part is easier to reimplement for SLS than it is for any 
other architecture.
> To recap, here's your original statement:
>   
> > The essential goodness of SLS is that no part of the application is
> > ever involved with moving things between memory and disk. Everything
> > has an address, and when you access that address, the operating
> > system decides whether data is available or whether it needs to be
> > paged in.
> >     
>
> My point is simply that, strictly speaking, the same could be said about
> conventional O/S architectures. It's the job of the (modern) O/S to shield
> these details from the application programmer. (Then again, maybe we're
> just arguing semantic nuances here.)
>   

Maybe we are.  It's my contention that i5/OS would be easier to 
implement on a cloud (or on DNA-based circuitry, or whatever) than any 
other OS simply because you only have to rewrite the one piece of code 
that resolves an address and makes it available to the CPU.  In 
traditional architectures, this can require multiple resolutions, while 
with SLS it's a single operation.

Anywho, it's not an issue worth much more space.  Gotta go write an 
article about SQL ...

Joe