11.3 resource allocation

[Chris Harris]

  > = Mike Prince

> Our OS is meant to exist in a very distributed environment.
> 	This is our GLOBAL layer.
> It is composed of everything out there. This exists, period.  Lets name it.

Deal.

> Software will be distributed to users.
> 	I call these TOOLBOXES.
> Remember, this is not the programming side, but the distribution side.  I 
> have the feeling Fare believes that once I get a TOOLBOX from vendor X, I 
> should be able to add functionality to it by inheriting its properties a 
> la OO programming.  Is this true?  If it is we either need access to the 
> source code, or our distribution format needs to be rich with information 
> about our a TOOLBOXES internal routine names, data structures, etc.  This 
> will slow re-compilation during migration of code to different 
> computers.  It will also make our distributions fat.  I am leery about 
> making such a compromise.
> 
> The alternative, is to have TOOLBOXES be black-boxes of functionality 
> with multiple entry points and a versatile data-passing mechanism.

If we are to have a OO OS, as I am all for, this ability you do not seem 
to appriciate is VERY important.  If we do not let the users/developers 
modify their system as much as they feel they need, we really haven't 
progressed much farther than unix....

> Stacks provide us this versatile data-passing method; almost anything can 
> be handed in and given out.

Okay, but I also think we should be able to pass lists, objects, dna 
samples from a local rubber puppy, whatever.  If these can be captured 
inside a stack, without making it too complicated, this might still work.

> The multiple entry points coupled with a tool boxes ability to 
> advertise entry points and their capabilities.

Sounds good, but the user should be able to modify them, if they suddenly 
get a brilliant idea as to how this object could better fit into their 
hiarchy.

> Finally, if we break code up into discrete toolboxes we can manage 
> migration more easily.

True, but do we necesarily want generic migration?  Seems to me we'd want 
support for partial migration, anything to get the maximum efficiency out 
of the stuff.  Recursive representations might help us more easily move 
sub-sub-sub agents around the place, if we so desire....

> Fare, please address how OO programming practices would influence 
> distribution format of code.  I.e does an application come in one big 
> package, or is it a collection of code fragments that can be farmed out?

Applications don't exist.  My philosophy anyhow.  If we got users used to 
OO technology, applications might seem like a let-down.  We're starting 
to see this in OLE and OpenDoc now, but that's just for documents.  If we 
made the whole world revolve around objects, code re-use could happend on 
a much larger scale, and word processors wouldn't take 20 megs and 
include every feature under the sun.

> These are implementational issues that must be addressed.  We cannot look 
> at the ideal pure OO language.  We are looking at an *operating system*.
> Everything must work together; programmers, hardware, users, etc.

Quite true, but this doesn't prevent us from having fairly low-level OO 
stuff.  The flip side of most of the arguments you're present here (based 
on speed) is how the USERS percieve speed.  Sure, objects might not be 
the most efficient way to run long computations, but something can surely 
be said for the drastic reduction in development time that would take 
place, and how much more productive the users might feel.  A happy user 
working a bit slower is better than an unhappy user working at full speed....

> > So what I want to say is *NO ARBITRARY F?CKING LAYERS* in the system:
> > what we need is not layers, but services. You don't build a hierarchy just
> > for the sake of administratrivia. Your build an administration because you
> > need services. Let's model the possible layers according to the actual
> > needs measured, and not provide resources according to some administration's
> > capabilities. That's liberalism vs. collectivism.

> 
> Mike

-Chris