Priorities

[Anders Petersson]

>On Sat, 26 Dec 1998, Anders Petersson wrote (in unios@onelist.com):
>
>> I was also thinking of "user" as the *final users* of the system, not
>> developers. I think these two groups are so different in their needs that
>> they should be separated from each other. The users could retain their
>> place, while developers get a higher rank.
>
>Here is my philosophy.  Final users are the most important.  They are the
>people who the system should be most convenient for.  The needs of users
>are so diverse that pre-packaged applications (written by someone else)
>can't always work.  The best solution in every case is to get a program
>written specifically for that user, for the problem they have right then.
>It only makes sense, then, to have the system assist users in creating
>programs to solve their problems.

It turns out that users are developers too.
I have a somewhat differing view of how this will be made possible. Instead
of compact application packages, programs are divided into smaller
components, each one independent. The application has one way it uses the
components by default, but anyone can use the components as building blocks
or tools to accomplish whatever he wants. This can be seen as some sort of
very high level programming, like all UNIX commands, but with a finer level
of control and more possibilities than in UNIX.

>> >> [Tril:]
>> >> That means no C-like inability to check array boundaries (for example).
>> >> You CAN focus on stability in the initial design: use strong type
>> >> checking, throughout the system.  This just means that operations are
not
>> >> allowed to operate on values that don't make sense.  I am currently
>> >> developing a strong, integrated type system for TUNES, because I believe
>> >> it is the center of the system.  There will be no kernel, just this type
>> >> system.  All objects will take part in the type system (or they won't
>> >> exist).
>> 
>> Is the quality of the programmers' code really something system developers
>> can do anything about? How could it be?
>
>Language designers can do something about it.  At least, they can design
>languages that allow maximum expressibility, so the developer doesn't have
>to obfuscate the code to adapt it to the language.  This happens a lot in
>C because programmers have to completely reorganize their program for
>optimization.  That should be the job of the compiler.  Of course, I go
>much farther and say that the choice of "data structures", which are
>usually chosen for speed (linked list vs. arrays vs. trees etc), should be
>abstracted so the programmer doesn't need to decide, but the system can
>pick which structure to use for data.

You're speaking about _language designers_. I'm not that. mOS limits itself
to the "public" design of the system - the language used is not dealt with.

>> Sounds like this type system provides the security, is that so? But what if
>> the binary code is altered - by mistake or on purpose? And can all
>> programming languages be used, or just one?
>
>Yes, the type system is what provides the security.  Altering binary
>code.. is interesting.  Since the system knows the binary code depends on
>the source, changing the binary code will give you several options:
>
>* Try to figure out what to change in the source code to correspond with
>the binary change you made. (you and the system would work together on
>this, i.e. the system would try to figure it out but you would help if it
>failed)  It may not be possible to express the change in the language used
>in the source, if so, then one of the below options would have to be used. 

This is just too *unrealistic* to be commented.

>* Add a low-level "note" that the change you made should be used
>instead of the regular binary code , next time that same code is generated
>from the source.

The problem is that you can rely on that no sane person would edit binary
code with a honest purpose.

>* The change causes a "copy on write", or a duplicate of the binary that
>no longer depends directly on the source. (it would still have a history
>that it originally came from that source, but it would not be dependent in
>the sense that it could be automatically invalidated and changed when the
>source changes.  That is to preserve your change.)

Same here.

>* Or something else you can think of can happen.

My version is: shit happens. No system (at least not ours) can to 100%
assure that code is valid. It could be hardware failures or hackers. If
someone alters the code so the program doesn't care for security, well,
then you've got no security any more.
I don't believe in compile-time security.

>> >> In TUNES we say stability and reliability are just by-products of
security
>> >> (strong typechecking).  So when we say security we mean all three.
>> 
>> They are very much interrelated. But this strong typechecking idea is not
>> clear for me.
>
>Everything you do involves a typecheck.  Moving the mouse, typing text,
>running a program, deleting an object, etc.  Nothing will happen unless
>the operation to be done and the object it is operating on match their
>types.  If they don't match, that is a type error.  All errors are type
>errors.  There is a flexible system to describe what to do on type errors
>(each type error can have its own behavior, the user can customize, there
>can be defaults, etc).  Everything in the system has a type.  All types
>are explicitly defined...  much of what you do in programming languages
>today is just creating new types in my model.

There must certainly be other errors than type errors. How about
communication failure, division by zero or missing hardware?

>> >Stability - The need for the components that the system is composed of, to
>> not
>> >(be able) scrutinize the flow of run time code.  This does allow for
>> incorrect
>> >object usage (if binary is corrupted), as that is a logic bug, which
should
>> >not take down the system.  As you say, this will probably involve a
typecheck
>> >system.
>> 
>> _Compile-time_ typecheck?
>
>Good question.  Typechecks are done as soon as possible, but sometimes it
>can't be until runtime.  However there is a major difference in my system
>regarding the relationship between compiled and interpreted.  Everything
>is partially evaluated, and "compiled" is just one form an expression can
>be in.  "interpreted" means compiling each sub-expression, then running
>its code, before compiling the next sub-expression.  If some
>sub-expressions have been compiled before the "compile" function can have
>its results (for that sub-expression) memoized (cached) so it looks like
>the expression was compiled again but it really just read the saved result
>of the last time it was compiled.  (done when storage is cheaper than
>the computation of recompiling that expression)
>Note that everything is an expression and the compiler is just a function.

Umm... I think you will have to elaborate if you want me to understand. Or
maybe this is as clear as it can get. I hope not, for all of us.

>Back to type checking, it can occur anytime before an expression is
>evaluated, but it MUST occur or the expression can't be evaluated.  Type
>checking ensures that the meaning of the expression doesn't break the
>consistency of the system.

Is this something like Java? Interpreted programs? Sounds even slower than
my old 386...

binEng