ORG,KER+ far12

[Francois-Rene Rideau]

>> Hello everybody.
>> 
>> Don't like the idea of a superuser, a chain is never stronger than its weakest
>> link. It's better if we could make the OS replace the superusers most powerful
>> rights.
>> As I see it, we have a dictionary with a list of possible device drivers,
>> as harddisk, soundcard etc. If a program has its own device driver it first
>> looks into the dictionary, is there any device drivers that can fulfill what
>> I want to do? If, add myself to the dictionary as a passive device, else
>> add myself as an active device.
>> The dictionary must have dictionary entries for a huge set of possible
>> device drivers. If we want, we can tag our own device drivers as
>> non-changeable to make the os more secure. Then only a superuser could change
>> the entries.
>> Now I see one problem that can/will arise, a device not mentioned in the
>> dictionary, but then the superuser could add it into the dictionary.
>> This might look like a cumbersome way of doing things, but that is the way
>> I'd like it. It is flexible and requires very little human involvment.
>> The OS could support calls like CheckForDictionaryEntry (xxx),
>> AddToDictionaryEntry (xxx, yyyy).
I think we can solve ths problem by each object having its own local 'virtual'
dictionary. Then the 'superuser' (not inevitably a system special object)
will only be a console (program somehow inteacting with the user to have
anything he wants done - an intepreted language is compulsory here for the
shell, so why not the same as the LLL, with special libraries added ?) with
EVERYTHING in its dictionnay. From there, the 'supeuser' can (manually or
automatically) export non dangerous names to more public parts of the
dictionary.

>> > I prefer the more general 'you know its ID, you can use it' phylosophy. Then
>> > you can have a 'user' object with the list of its known objects being limited
>> > to some objects, and some aspects only of objects not entirely owned.
>> 
>> See my part over.
>> 
We seem to agree !
What of the other moose-programmers ? or won't they also be moose-specifiers ?


>> > >> > [...] That's why the system should offer many different
>> > >> > capabilities of allocating memory, from raw reservation of
>> > >> > contiguous physical memory (to device drives) to garbage
>> > >> > collecting-aware [...]
>> >
>> > >> NO! The kernel should offer a single simple and (hopefully)
>> > >> sufficiently general method that is used by all.
>> >
>> > Hey ! who told you the Kernel should do that ? Of course the
>> > Kernel won't provide /* added: itself */ any memory allocation
>> > routine; it will only branch you to the memory device you need
>> > (only a basic device being available on a basic system).
>> 
>> As long as the kernel can give amounts of code to the system, we don't
>> actually care what happens to that memory amount, does we. I vote for
>> Fare's(with appostrof over the 'e' :-) way of doing it concerning this
>> issue.
(actually, that's not an apostrophe but a french acute accent, which doesn't
exist within the 0-127 ASCII character set ;-( )


>> > >> > There we come to an important point: error handling. Of course, old OSes
>> > >> > (stands for Old Shit ?), being based upon C, couldn't integrate this concept,
>> > >> > neither could they understand anything sensible about HL programming (nor
>> > >> > LL programming with respect (?) to DOS - Double Old Shit (OS/2 being half-old
>> > >> > shit). Recent language like ADA, later version of (true) C++ and CAML do
>> > >> > include exception handling, and many HLL I don't know certainly do. I like
>> > >> > very much that of CAML (not knowing the others - tell me - 't'should be
>> > >> > mostly taken from the same language as for C++, but CAML should be better
>> > >> > because of automatic genericity as opposed to C++'s template hack). The
>> > >> > Kernel should include exception handling as a standard, so that objects
>> > >> > can exchange not only usual data, but also exceptional data (notice that
>> > >> > these language do not allow embedding exception in data itself by declaration
>> > >> > of exceptional format as should accept the language I vouch for (of course,
>> > >> > their are ways to obtain equivalent results, but then why not repeat we all
>> > >> > use Turing Machine equivalent languages ?)
>>
>> Let's design a critical event device, of the style I've already proposed.
>> A tree-structured function list (? :-). When a critical event appers it
>> just calls the function linked, belonging to the app, or just a standard
>> function, if the app hasn't added one to the device.
That's it ! But/and each thread can add a leaf/branch to the tree, so that
what I have proposed is having the tree-structure be a sub-structure of the
threading structure.

>> > >> Were designing an OS - not a langueg.
>> True enough, but what is an OS without any accesible functions from the
>> outside world. An OS and nothing more. A vast screen with no apps :-)
>> 
>> > >> I'll come back to this point again, I think you're trying to throw a lot
>> > >> of what properly belongs in a language into the kernel -- thereby imposing
>> > >> a uniform object oriented view on all users of the OS.
>> > >>
>> > >> Personally I will disassociate myself from MOOSE if we decide to enforce
>> > >> OO programming on everything ... I feel that OO is overhyped.
>> It depends on the way we implement to objects...
(I don't like people like MS and the such, who talk a lot about OO, but
don't ever implement it a correct way for the common of us to use, so that
their OOing is only an added limitations in lieu of an added freedom.
Apart from that, I see nothing bad at OOing, if properly implemented for
optimizing a compile-time)

>> > >> Personally I'd much rather use a Very-High-Level-Language like Haskell --
>> > >> OOPLs are based around imperative languages and are lower level as a result.
>> No language discussion please, as you said, we are not designing a language,
>> but an OS.

>> > >> Objects:
>> > >> > >> > I like the approach of simply defining a standard format.
>> > >> > Well, if not, this would no more really be OO'ed, and be another DOS, waiting
>> > >> > to be (VERY quickly) obsolete !
>> > >> > OO standardness is compulsory. To be in advance with other existing OS
>> > >> > projects, we must also include NOW genericity (for the which C++ templates
>> > >> > are only a hack) and logical programming (the most common use is find how
>> > >> > to find the "best" path to transform a virtual object into another, knowing
>> > >> > the elementary virtual transformations available and their physical cost).
>> > >>
>> > >> Yet another OO fanatic ... :-)
>> > >> I repeat -- objects are not magic ...
>> But they can be very helpful from time to time...
and as I repeat, they are the only known means to
correctly communicate code together with data. And
without code, data is useless.

>> > >> > How complicated !
>> > >> > Again, let's program it by layer. The lowest (kernel) layer does a Andreas
>> > >> > says. Then, you can have a filter monopolize the lower-level resource to emit
>> > >> > events on a queue, then if you want, mix that queue into a general event queue
>> > >> > for stubborn processes to un-multiplex the global queue, as stupid current
>> > >> > systems do. YES, you CAN do it ! But once you see there are simpler, easier
>> > >> > means to handle data, by piping data just where you want, you WON'T use the
>> > >> > centralizing algorithm. Everything is easier, neater, quicker, better, when
>> > >> > objects just fit one into the other.
>> I liked that part "does an Andreas say".
of course it was a mistype: we should all have read 'AS Andreas says'.
>> Have to go now. I'll continue in another mail. Have a nice weekend.
>> 
>> 
>> Arff
>> 
>> sig.'s in for 1000 miles service
>>         --Andreas Arff          andreasa@dhhalden.no--
   ,
Fare
-- Franc,ois-Rene' Ba^n Rideau D+a(.ng Vu~ --
(Following the Vietnamese convention for placing accents/modifiers
after the letter, as ASCII is only 127 characters, including
forbidden control characters and line limitation, so 95 (32-126)
useable codes only. Down with stubborn ASCII !)