Reflection

[Anders Petersson]

Tril wrote:
>On Sun, 3 Jan 1999, Anders Petersson wrote:

[snip: reflective Linux kernel]
>> 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.

Yes, it would suit better in a no-kernel environment.

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

I was somewhat misleaded by the Linux example, reflection would not have to
be that way. I don't know how easy it will be to make a reflective
kernel... if only all parts are replacable in real-time, it shouldn't be
too hard.

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

So reflection is the single reason for TUNES?

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

My fault - I wasn't specific enough. By "underlaying structures" I meant
what the user view maps to.

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

Are all implementations low-level, and so hardware-dependant?

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

I agree. Users will want to have the flexibility decreased. Novices want
little flexibility, experienced users can handle more flexibility.
Such a flexible design we are looking for provides too little 'flesh' to
have a system implemented just going after the design. For example,
standard tree structures will have to be defined, since the design does not
enforce any special structure. Don't misunderstand me, programs must not
rely on such implicit standards, but users will feel more comfortable if
all computers they use look the same (like having applications in one
defined place and user files in another defined place).

No, that aspect was not quite what was discussed, but it was what I wanted
to say. :)

binEng