On Thu, Mar 10, 2005 at 09:53:29PM +0100, Ziggy wrote:
> Could be nice if UUU was a microkernel OS. Just a general idea..
> And yes, you should start the device drivers from scratch.
Unununium can not be a microkernel because it does not have a
traditional kernel at all. There is no clean line where kernel code ends
and user code begins, because there is no address space separation.
> On Thu, 2005-03-10 at 11:40 -0500, Jacques Mony wrote:
>
> > That brings me to the "cut-and-paste" paradigm. Is that needed? We've
> > been discussing icons, but what about this cut-and-paste? What, exactly,
> > do we move around? Data, instances, objects? What's with file
> > hierarchy? Do we really need so many levels of classification? Look at
> > *nix: /bin, /sbin, /usr/bin, etc. Why not "Applications" and rights
> > associated to them. (Same thing with Windows and its executables in both
> > \Widnows and sub \Program Files directories). In fact, we want to
> > abolish applications,
>
> you will probably accomplish that by changing the definition of the word
> application. There will still be 'executables' and 'Programs'. I think
> you've got high-hopes about this one.
Definately not. I think I've corrected you on this in the past. One can
not have 'executables' if there are no files. I imagine the term
'program' will continue to be used, but it's somewhat inaccurate because
again there is no clean line between one program and another because
there is no address space separation. The distinction is one of only
packaging.
I'll say it again, a different way. "To run a program" on a traditional
OS means to locate an executable file, create an address space, load the
executable file in to the address space, then call a function in that
space. This function isn't just any function; it's a function that must
return an integer and takes only strings as parameters. When the
function returns the address space and associated file descriptors are
destroyed.
It's not like this in Unununium. "To run a program" means exactly "to
call a function". There is no executable file, address space, loading
(only potentially filling a cache, which is orthogonal to, not part of,
calling the function), or restrictions on what it must return or what
types of parameters it must take. It can create objects that are
referenced by other things and as such are not destroyed when the
function returns.
|
