Reflection

[Tril]

On Sun, 3 Jan 1999, Anders Petersson wrote:

> >On Fri, 1 Jan 1999, Anders Petersson wrote:
> The word that comes to my mind is "vague". And maybe "unrealistic", or
> "without contact with reality".

So?

> >Here is something to think about. How to make the Linux kernel reflective? 
> >Put a compiler in the kernel.  Put the source code in the kernel.  Put
> >functions to view and manipulate the source code in the kernel (I mean a
> >syntax-directed editor). Then put in the last tricky function, which
> >replaces the running kernel with a newly compiled one.  Presto, fully
> >self-contained system [wait, add source code to the compiler, too!].  (No,
> >you probably don't have enough RAM for this monster kernel to entirely
> >fit. But swapping code in from disk has been done already.)  BTW, if you
> >don't put any of this in the kernel, but you still have it all, you have a
> >reflective system (but not reflective kernel).  Only the last step is
> >really bad, because it requires rebooting :) 
> 
> All that in the kernel? No way. That rules reflective kernel out. Besides,
> I see no need to have all that in the kernel to replace it without rebooting.

Hehe.. yeah, a reflective kernel is kind of ridiculous.  But I favor a
no-kernel model, and reflection would make more sense there.

> >> Could mOS support reflection? It does have some properties that makes it
> >> more suitable for reflection. Each system is devided into lots and lots of
> >> small units, each one (or the vast majority) movable, and replacable in
> >> real-time. Updates are also noticed as they are done, not by a reboot.
> >
> >Sounds good so far.  Just consider the above example for mOS, instead of
> >Linux, and you will get an idea of what you are up against.
> 
> Keep your reflective hands off mOS. :) We're aiming for a small-sized
> kernel, not a reflective giant.

Ok.  Then how easy will it be to reflect on the kernel?

> >Remember, every system has reflection.  It's just how long the road is
> >(and how bumpy) from one system to the changed system. 
> 
> Don't forget that there's a prize for everything. Will the advantages with
> good reflection weight heavier than the disadvantages? (I bet you answer
> "yes"...)

I don't think anyone knows.  If there was a system with "good" (fast
turnaround rate) reflection, we wouldn't need to have a TUNES project!
So the advantages/disadvantages are what we will try to find out, by
making a running system.

> >> What speaks against is that mOS shows the user the true system topology. It
> >> is not as I understand Tunes does - to present the user with a view that is
> >> independent of the underlaying structures.
> >
> >There is a view that is independent of underlying structures, but the user
> >can cross it.  Normally there will just be a warning message that says,
> >"if you go here and change stuff, it won't be platform-independent
> >anymore."  You can still do stuff there, and it's all still objects.  I
> >expect lots of hackers to do this.  It will be necessary to spend time
> >here in order to find optimizations to make the system fast.
> 
> Blurry, blurry.
> Who was speaking about platform-dependence? Maybe the only thing in Tunes
> that's platform-independent is that user view? Well, in UniOS the true
> system is platform-independent, except for low-level drivers and maybe
> binary executables.

I interpreted your "underlying structures" as the platform-specific
structures (hardware, drivers, and so on).

There are two "true" toplogies.  The high level, platform indenpendent
part, and the low-level platform specific part.  The low-level topology
is the implementation of the high-level one.  Implementations are the
"underlying structure"... and the high-level specification is independent
of the implementation.  

> >> As reflection changes the way
> >> the system is structured, without any help from the user, reflection could
> >> confuse for the user by changing the way *the user* sees the system. 
> >
> >Well, it could be done with the help of the user.  Anything in Tunes can
> >be done either with, or without, the help of the user.  Usually the user
> >helps first, then when s/he is comfortable with what is going on, sets it
> >on autopilot.  (this is true for every action in the system, not just
> >reflective activities.)
> 
> I'm sorry, but without more concrete ideas, the above remains to be just
> words for me.

Let me try a different answer.  Of course reflection can change the way
the user sees the system!  That's the whole point!  People need to look at
information from different views, to understand it.  Changing views is
just another way of saying customization.  You in UniOS have the same
problem because you say flexibility is your #1 goal!  With all that
flexibility, of course the user might get confused.  But that's no reason
to leave out flexibility, now is it?  Tools CAN be added to manage
flexibility.  

David Manifold <dem@tunes.org>
This message is placed in the public domain.