relationship with our tools? NO.

[Tril]

On Mon, 7 Dec 1998, Matt Miller wrote:

> 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?

Yes, being in C is part of the problem.  It's not just C, though, it's the
form the source code comes in, ASCII text.  The need for source code to be
processed all at once by a huge compiler is, IMHO a relic from the days of
punch cards.  

Somehow, people decided efficient binaries were more important than saving
programmer time.  Now, it is true, some effort is required to make a
program optimized for a platform.  But spending time optimizing an
algorithm for a specific platform and a specific data set is DIFFERENT
from what we have today.  What we have is languages which force
programmers to think in terms of the low level machine.  All programmers,
not just kernel ones. 

The idea of a kernel itself is based on low level design, that of making
the OS efficient.  Well, instead of the system programmers choosing what
will be efficient, the user needs to do that.  Any design configuration
has limitations and tradeoffs in efficiency in some cases, and benefits in
other cases. 

So in TUNES we allow the user to make requests that have effects
throughout the entire system, reconfiguring the organization of the
various modules.  I am writing a specification for TUNES now that explains
how all this works. 

Low level languages not only make it more time-consuming to program,
but time-consuming to understand the code by reading it.

> 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?

Yes.  We want to eliminate the ease of use problem, the development time
problem, the automation problem (where not everything in the system is
automatable), and the end user control problem all at once.  To do this we
unify UI and API.  (Going backwards in the above list) The user can access
any part of the system, and write a macro to do something in it; and the
basic unit of the system is simple to use and understand (and is suitable
for users and programmers). 

> [large data sets]
agree

> > 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.

It is not the job of TUNES to convince people one way or the other.  It is
simply to provide a working system that allows those who wish to design
software the "correct" way (according to the above postulate) to do so,
and have optimal machine aid along the way.

> [emacs]
agree

I don't know much about Emacs, except that it is a huge editor that runs
lisp.  Is there something more?  Has lispos list discussed extending emacs
to encompass an OS, Fare?  

[screwdrivers]
I don't know that this analogy holds with software.  People ought to know
that there will be pressure to add features to their software.  Because
it's easy.  You can't exactly modify a screwdriver fundamentally anytime
you have an idea.  That's just because you can't change the laws of
physics that the screwdriver is bound by.  But software can define an
environment for other software, so in effect you can define the laws
within a computer.

> > 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?

No.  GNU/Linux' Bazaar is good.  We just want to make it faster, easier,
and more automatic.  To compare TUNES with GNU/Linux, however: TUNES is a
completely redesigned system, whereas GNU/Linux is built on proven
formulas.  We don't have that many new ideas, either, but the combination
of so many of the old, infrequently-seen ideas in one place, is what
counts.

David Manifold <dem@tunes.org>
This message is placed in the public domain.