relationship with our tools? NO.

[Matt Miller]

On Mon, 7 Dec 1998, Tril wrote:

> The system IS to be completely controllable, even at the expense of
> allowing users (well, at least the administrator of that system) to
> "compromise" the system.  There is no reason why a user should not be able
> to make their own system insecure, or unstable.  In fact, if we don't
> allow them to, the system will be useless and someone will make another
> one.  More likely, they will make a work-around for TUNES' limitation.
> It's better for us to include the ability to turn off security, as a
> *feature*, so at least it's done right.

I guess I am confused about the -level- at which you propose this
controlability.  All of the above can be accomplished with a GNU/Linux
system today.  By the nature of the GPL, the source is there.  You can
hack around with it and make it as insecure and unstable as you like.  Is
the major difference for you the fact that these things must be done in C?

Is your complaint with current systems that there exists a dichotomy
between "end user" and "programmer"?  Should every (current paradigm) end
user be permitted to interact with his system at the deep levels which is
the province of the programmer today?

> Let me rephrase.  HAL malfunctioned, that is, performed some action that
> was not intended by the designers.  The reason HAL malfunctioned is that
> he came into contact with data that the designers did not anticipate.

And there will always be such data sets, no matter how far you abstract
and include larger and larger "meta-data" sets.  I think Godel applies
here. 

> To work on fixing this situation...
> First, designers should not believe they know everything, and they should
> not build software that is inherently suited for only one specific task.

That involves changing the midset of people which is far beyond the
purview of this project, I should think.


> That is, people should design software with the intent that the software
> will be used for other things than it was intended for.  This includes the
> possibility that some user will find it useful to modify the software for
> a novel use.  

Emacs springs to mind as an excellent example of something which has
expanded far beyond the scope of the original intentional construction.
It seems to have a lot of the elemnts which you are lobbying for.
(Including a LISP-based structure)


> Why should an author "intend" anything for the program.

Because if he has no intention for the program it will never get built.
Remember software as tool.  Why should the "inventor" of the screwdriver
have an "intention" for how it should be used?  Doesn't it make a fine
lever/prying tool?  How could he be so short sighted as to think it was
good for screwing in screws?  

Why didn't he just create something that had the beautiful "screwdriver
form"?  Because form follows function.

> Second, language designers, operating system designers, etc. should
> redesign these systems to support a model of software evolving.  New
> systems should be invented (like TUNES) which make it easy for programs to
> be extended, replaced, or reoptimized for different uses.

Again, show me on what level this is different from the Gnu/Linux
paradigm?  All aspects of the system are open to review/modification by
the programmer/user?  Is it that this is too difficult?


Matt