Francois-Rene Rideau wrote:
>
...
> I'm wondering if you know the TUNES project, and have any comments on it:
Wow! Encyclopedic! I very much like people who learn from history. [So much bad reinvention takes place!]. Some very cool ideas.
[I have not had much chance to do more than a quick scan, but..]
My major concerns about such a project are:
* Funding (How to eat while doing this).
* Target/Vision/Coherence issues (How to narrow goals and strategies to what can be accomplished with resources at hand).
* Technology reuse/leverage (Not being able to do everything from fundamentals, how to converge on and leverage what is there and how to energize/grow/leverage existing communities; where to contribute, how to grow).
* I know how hard the goalset is to achieve [It is a lot of work by many people over years/decades => requires organizational persistence and learning].
> (note that the archives for the LispOS list are also around there:
> http://lists.tunes.org/cgi-bin/wilma/lispos
> ). The project needs some core code and a manager.
> I've proved unable to fulfill that task up to now.
> If you feel like it, I'd happily offer the task to you...
I have the background but at this point I would have to be paid to do the work. [You can scan my general background included as HTML, below]. [I'll review the archive soon].
> I invite you to include tunes@tunes.org in your replies...
>
> > SYSTEM PRINCIPLES FOR RELIABLE, USEFUL, PERSONAL COMPUTER SYSTEMS
> >
> > [...] radical rethinking [...]
> Been doing that a lot.
> Unhappily, not been doing much anything else
> (e.g. coding, writing PhD thesis, etc).
>
> > - SELF CENTERING (homeostatic)
> > - SELF DESCRIBING
> I call tend to put all that under the concept "reflection".
My concept of 'reflection' does not quite cover this. I tend to think of reflection as a low-level implementation substrate/strategy.
By SELF CENTERING I mean self 'healing'. I.e. tendency toward stability and usability in the presence of an uncertain world and unexpected circumstances. I.e. as system I find that some of my code/hw does not verify (e.g. checksum) and I take action to [1] repair, [2] work around, [3] communicate the problem(s) as a typical part of system behavior.
By SELF DESCRIBING I mean that the user can always ask "what is going on?", "what components are present?", "why am I getting no response here?", and so forth. I.e. the UI supports explinations.
> > - Backup is continuous
> Unhappily, in absence of battery backed-up TRAM,
> this is either very expensive,
> or subject to some delay (which is completely uncontrollable with IDE,
> somewhat controllable with SCSI).
There is 'ephemeral state' and there is 'transacted state'. When significant state transitions take place they are always transacted and have been logged to stable media. If the power fails and is restored, the system should not only be able to recover data but also to recover system state, which may include "replaying conversations/interactions" from logfiles (e.g. to reestablish 'live' distributed connections). Ephemeral state is lost. This ephemeral and transacted distinction must be managed explicitly.
>
> > - UI RELIABLE AND CONSISTENT [Visibility & Control]
> Good.
>
> > QUESTIONS:
> >
> > - What are the rules/rubrics for developers? How checked?
> > - What HW & SW Technologies support the above?
> > - What Baseline Components are Required?
>
> I think your problematic is correct.
> My general opinion is that reflection dynamically allows
> for new static invariants to be enforced and taken advantage of.
Good substrate mechanism, but it must be reflected/abstracted/filtered/presented to the user in comprehensable ways.
> Would sending the full description of a man, destroying the original in the
> process, so he be reconstituted back light-years further be a valid means of
> transportation? Or would it be killing him and making a different man?
Yes. [Do you walk to school, or take a lunch? 8^]
Cheers,
-KenD
============= Original Scribblings
=============>
File: "System Principles"
Implements: Notes on System Principles for reliable, useful, personal
computing devices
Author: Ken Dickey
Date: 2000 March 20
Updated: 2000 March 21
SYSTEM PRINCIPLES FOR RELIABLE, USEFUL, PERSONAL COMPUTER SYSTEMS
Over time I have come to the conclusion that there needs to be a radical rethinking of 'consumer
computing'. I had thought that the rise of the comsumer and networking would increase reliability and
usability because of consumer demand. Instead it appears that 'consumers' now put up with crashing cell
phones.
It is time to rethink the fundamental strategies we use to build computing systems implementing tools
and devices for ordinary people.
In accord with modern thinking on health, one should think of 'self healing' systems.
- SELF CENTERING (homeostatic)
- Model of Self (endomorphic)
- Consistency monitoring; self check
- State & feedback driven centering procedures
- Both HW & SW components can be 'hot swaped'
- STATE CONSISTENCY
- Component & Data self check (incl checksums) at all levels
- State is Transacted
- Schema Evolution
- Component Update w Compatability (incl version) Constraints
[legal component set -> transcient -> legal component set]
- Backup is continuous (logfile) with transaction completions noted
- can always delete transcient state, replay inputs from a checkpoint
- if transactions are local, can undo system state to previous
[=> special markers for distributed transaction undo]
- Backup/undo a normal part of system behavior
- can decide to uninstall a newer version of a component and then
replay transactions with old component
- SELF DESCRIBING
- Can always answer the questions:
- What can I do here?
- What is going on? [Activities]
- What is there? (what hw & sw subsystems/components are installed?)
- What is this component doing?
- Why the delay? Is it sane? What can I do about it?
- Can I install/uninstall/update this component?
-> What is affected? What required? What provided?
- UI RELIABLE AND CONSISTENT [Visibility & Control]
- UI never 'blocks'; User always feels system is immediately responsive
- All user interface actions are visible
- Either immediate (visual) response or visual indicator of an
action (e.g. mouse click) queued on a specific component.
- Clean separation between UI layer (always responsive) and underlying
components/applications (may be waiting, or compute bound)
- UI able to move, resize, scale, display menu/click/mouse
events/actions w/o blocking on component/application response
- Universal undo/redo (modulo non-local transacted commits)
- Including component install/uninstall/update
- Component/App can always indicate what is it doing (continuously or
by request) even when it is compute bound or blocked.
==============================================================
QUESTIONS:
- What are the rules/rubrics for developers? How checked?
- Design for self-test, fault diagnosis & fault repair
- Break compute bound computations into chunks [Agenda control structure]
- Provide explanations of actions: Explanatory Model
- Undo/Redo & Transactions
- Compatibily Constraints
- Provides/Requires
- Save/restore
- What HW & SW Technologies support the above?
[E.g. (sw):
'Garbage Collection' (automatic storage reclamation)
is a powerful consistency checker;
Closures aid in undo/state consistency, agenda control structures;
Object System
Recoverable Exceptions
Lexical & Dynamic variables & Dynamic Wind
Full Programming Environment
et cetera.. ]
- Use partial evaluation and runtime code generation aid in reducing
system footprint in restricted resource environments (e.g. Embeded).
- What Baseline Components are Required?
- Ontology Database [Explanations; Provides/Requires] [XML]
- Language Runtime (sub)System(s)
- Constraint Checker
- Transaction System
- Component Manager; Data Manager
- Regulatory/Healing System
- Self Test System Manager/Scheduler
- Diagnostic System
- Repair System
- GUI [Manager]
- Event Manager
- IO Manager
- Time Manager
- Process Manager
- Device Manager
- Security Manager
- Per Task
- Storage Manager
Memory, Stable Storage
- Resource Custodians
- Threads
- Events [Eventspaces]
- IO
Files, Ports, Network Connections, Transactions
============= List Of Sins ...
<!-----CUT-HERE---PASTE-IN-TEXT-FILE---VIEW-WITH-WEB-BROWSER----->
Ken Dickey
Kenneth A Dickey
14565 SW McFarland, Tigard, OR 97224
kend0@earthlink.net
(503) 968-6798
Skills Synopsis
Base Technology Background
Software Architecture/Systems Engineering Experience
People & Management Skills
MicroTek {1990-1992}
Tektronix {1984-1990}
DiaLogic {1982-1984}
Purdue University {MS in Computer Science}
Humboldt State University {BS in Environmental Resources Engineering}