KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 6th March 1999

Number: 011

Mailing List: kosh-general

In the mailing list this week, the following items were discussed. Please do
not email the scribe regarding any of these topics, it is not his job to answer
these questions but merely to report  the topics of conversation. If you have
any queries about this summary, please email ben@kosh.net, stating the Summary
Number, and Mailing List Name, and he will try to answer your queries.

a)

Subject: Virtual Memory

Summary of debate: For decent virtual memory support in KOSH processors will
                   probably need some form of Memory Management Unit. This
                   could cause problems if running KOSH on EC versions of 68k
                   chips. VM could still be implemented without an MMU but
                   would be unable to trap page faults which could cause
                   problems. Amiga programs such as Photogenics often have
                   their own VM implementation that may not require an MMU -
                   raw images are stored on disk and only the bits that are
                   being processed are loaded into physical memory.

                   A good scheduler could allow certain idle processes to be
                   swapped to disk until needed.

                   An alternative would be to run a machine directly from the
                   HDD but via a big memory cache so you would not have to wait
                   for it to catch up all of the time.


b)

Subject: Memory protection

Summary of debate: Memory protection is essential in full-blown KOSH - however
                   some hosted versions may not be able to support this.


c)

Subject: Database systems

Summary of debate: KOSH should feature a good base services for database
                   systems. This could include both RPG and OOP.


d)

Subject: Icons

Summary of debate: A number of people like the idea of having the icon
                   information for a particular file in a separate .info file
                   (aka Amiga-style) as previously mentioned. However when
                   copying or moving a file the appropriate icon file should
                   automatically be copied/moved as well (unless OFC the user
                   selects otherwise).

                   However it was suggested that to the end-user icons should
                   exist as a representation of the file and not be a separate
                   object themselves. It should still be easy to manipulate the
                   icons if the user desires to do so.

                   Perhaps animated or active icons could be used. When you
                   move the cursor over them the icon animates, or it plays a
                   tune or gives a brief snippet of its contents, etc. If you
                   don't like this feature you could just turn it off of limit
                   its effects (eg: audio limited to 5 seconds of play).

                   Icons could be set to "pointer mode". This would allow it to
                   be set up so that one user saw one set of icons but another
                   user could see a completely different set.

                   The image pointer for each file could instead of pointing to
                   an individual icon point instead to a big database which
                   contains all of the possible icons.


e)

Subject: Group locating objects

Summary of debate: Should we have all related objects in the same place, eg:
                   all applications in applications/ etc?



f)

Subject: Object Synchronisation

Summary of debate: By being able to synchronize two or more duplicates of the
                   same object at different locations this would allow
                   trans-internet games (and presumably any other type of
                   application) to handle everything in-system (not at a server)
                   and simply synchronize a world object between each player.


g)

Subject: Application-Objects as drawers

Summary of debate: If we setup application-objects to be a form of drawer,
                   executing it would run the application, but right-click (or
                   alternate key press) on the app-object would actually open
                   it up so that the component objects were visible.

                   On the subject of drawers how about defining a drawer as a
                   physical directory with a folder being a grouping of
                   files/documents (eg: files composing a project) treated as
                   one discrete entity? Or just stick with Objects and object
                   groups.



h)

Subject: Cloning output

Summary of debate: If a window's output could be shown on another user's
                   machine by using a form of object cloning there could be
                   immediate benefits for training and network management by
                   allowing you to use the tools of your choice on network
                   whiteboards.

                   QNX Photon GUI has a concept doing this.
                   The KOSH booklist (scribe's note: thanks again John and yes
                   you can have another free plug) at:
                   http://www.snowcrash.u-net.com/kosh/booklist.html contains
                   references to the QNX system book which covers the above.

                   Perhaps synchronisation (as mentioned above) would be more
                   use as this would allow constant communication from source
                   to destination as opposed to cloning which is more to do
                   with a one-shot duplication of an object, its state and
                   data.


i)

Subject: Settings Working Group

Summary of debate: Marcus Peterson has suggested that it may be time to form a
                   Settings WG to define such things as visual design,
                   functional design, bindings between objects, containers and
                   settings, and hot to deal with import/export and multi-user.


j)

Subject: Accessing the OS

Summary of debate: As individual people each have individual preferences as to
                   how to access and use the OS (eg: desktop workspace, file
                   manager, DOS, etc) we should have an object manager and an
                   application manager as a minimum. We could then begin to
                   allow for any desired way of accessing and controlling the
                   OS.


k)

Subject: Studying systems as a whole

Summary of debate: See: http://pespmc1.vub.ac.be/ASC/Cybernetics.html re
                   studying systems as a whole in relation to cybernetics.


l)

Subject: ANDF Url

Summary of debate: A company that makes ANDF stuff can be found at:
                   http://www.ddci.dk/news/brief_andf.html
                   and at:
                   http://www.npac.syr.edu/projects/hpsin/hpandf.html


m)

Subject: Supporting formats
Summary of debate: With an object based system supporting any particular type
                   of format (image, sound, text, etc) could be achieved by
                   coding the relevant object for it and inserting this into
                   the relevant part of the Object Sea.

                   The OS could provide a configuration utility for this that
                   allows programs and classes to only have a "form" for the
                   utility to fill out which could include things like image
                   and sound formats.


n)

Subject: Root object & filesystems

Summary of debate: A "root" object in the file system would be the thing that
                   exports methods for allocating and freeing data blocks and
                   perhaps dealing on a very basic level with navigation. A few
                   basic classes (such as "entity" (eg: a disk), "name", "date)
                   would be manipulated by the roots file system.

                   A "foreign" file system could be supported by creating a
                   filesystem object to represent and interact with it.

o)

Subject: Avatars and KOSH

Summary of debate: An Avatar/personality system was suggested and debated that
                   would represent the defaults setup in a system. A hierarchy
                   could serve well here.

                   A media preferences editor would set these things up as a
                   standard chart object. A program wishing to ask you would
                   query the object sea for a list of media types of the
                   specified class, but one wishing to simply write the default
                   would query the media defaults chart for this. Chart objects
                   are nothing more than a standardized way to create class
                   interections with caching (eg, you ask the chart for a
                   specific class pointer by token, not by fully specified path
                   name/URL).

p)

Subject: Novice users and system settings

Summary of debate: For the system to "know" you're a novice, would imply some
                   some intelligence in the recognition. This could break down.

                   Could a series of sets of settings starting at basic and
                   expanding up to advanced with progressively more detail where
                   you could explicitly request that the next time the settings
                   opens it does so at the level previously selected.

                   However KOSH needs to go beyond improving the range of
                   features or grouping them into fixed expertise levels to
                   allow a greater and more accurate degree of response to user
                   ability and desires.

                   The worst case would be what is generally apparent in systems
                   at the moment with every user being presented with the same
                   identical set of options to deal with, and the path that the
                   person must traverse to use these options is rigidly fixed at
                   the software factory

                   KOSH needs to be able to learn to present the user at the
                   very first request those options which the user is most
                   likely to need. This is really the only question the user
                   ever has. "How do I get the machine to do what I want it to
                   do?" A good set of defaults and thoughtful design is helpful,
                   but only as a starting point.

                   Directory requesters usually come up with the system default
                   path or an app-specific pre-configured path, but a few
                   programs are intelligent enough to remember what path the
                   user picked when performing a save (for example), and give
                   that as the first option the next time that function is
                   requested

                   We might want to consider an AI lister that, by use of some
                   artificial neural network for instance, tries to predict what
                   path the user's trying to reach. Eh, well, that would be nice
                   anyway.

                   Inherent within decent file requestors we should have an
                   intelligent form of word completion. As with all such things
                   it should aid usage of the computer and not hinder the user
                   by making unfounded assumptions.

                   User-defined menu structures are something else we should
                   implement.

                   The little personal AI that each Koshan will be growing,
                   training and nurturing (or leaving dormant) should be able to
                   recognise potentially interesting objects and organisms that
                   exist in the wider sea and bring them to the attention of
                   their owner.


q)

Subject: Standardised configuration

Summary of debate: The OS could provide a global configuration utility. With this
                   programs or classes shouldn't have to bother with their own
                   configuration, but just provide a "form" for a standard
                   configuration utility to fill out.


r)

Subject: More on KOSH helpers

Summary of debate: A KOSH helper will have to remember a number of things to be
                   successful in KOSH: Smart Dirs requestors, Version tracking,
                   smart menus, macro building and semi-automated software
                   updates,  Data-KnowledgeBase updates, an option to revert to
                   previous Configuration settings, tracking of software
                   failures and semi-auto bug reporting etc.

                   By standardizing formats (instead of the current system with
                   each application type having its own formats), the helper
                   could then use the prefs and habits of any application the
                   user uses to form its own particular knowledge-base.

                   Even without AI this sort of standardisation would simplify
                   user control over the whole range of options involved.

                   However helpers/AIs/etc have -always- in the past ended up
                   annoying people because they "learn" and make assumptions
                   about what we want to do.


s)

Subject: KOSH hotkeys

Summary of debate: When you have set a hotkey locally lots of times in different
                   applications there could be an option to make it apply
                   globally. At this point a settings editor could pop up and
                   ask you which applications should explicitly keep the chosen
                   hotkey and which should make it the same as the global one
                   which presumably would update automatically.


t)

Subject: Waterproof KOSH boxes

Summary of debate: Suggested that we make KOSH boxes waterproof to avoid damage
                   from spills of coffee that are unfortunately all too common.

                   However a waterproof box may have problems with a fan based
                   cooling system. Solutions could be to pass the internal air
                   current to the edge of the case away from the hot chips, or
                   better still make a fanless system that uses good case
                   design and materials to dissipate heat as it is generated.
                   This could be coupled with using chips that naturally do not
                   get too hot.

                   Heat dissipation to the case would have to be spread out
                   evenly and the temperature regulated to prevent the case
                   from becoming too hot.

                   Could Peltier elements be used to directly transfer heat
                   from one area to another with no moving parts? However they
                   use power and therefore generate heat themselves. An
                   alternative would be heat pipes. They are just a normal hose
                   with a cooling medium and fluff on the inside. It carries
                   heat better than for example a metal bar but can still be
                   bent and curved.

                   How would all this affect radio interference?


u)

Subject: 1999 USENIX Annual Technical Conference

Summary of debate: To be held on June 6th to 11th 1999 at Monterey Convention
                   Center & DoubleTree Hotel, Monterey California. Registration
                   by May 3rd. See the program at:
                   http://www.usenix.org/events/


v)

Subject: Paper on Task Migration

Summary of debate: Greg Webb and Clash Bowley (and possibly others by the time
                   you read this) have volunteered to produce the paper on Task
                   Migration that your humble scribe asked for.
                   (Scribe's note: Thankyou!!)


w)

Subject: disk space and scheduling

Summary of debate: With KOSH we presumably will release some form of disk
                   tools. With a defragmenter could a small area of disk space
                   be kept free so that scheduled tasks (eg: RC5 clients) could
                   run unimpeded. Could it be dynamic as the task was being
                   performed? Could the system tools pause such scheduled tasks
                   if needed and let them continue when possible?

                   With a filesystem that is well constructed to minimise the
                   need to defragment and have the ability to defragment
                   automatically as and when needed with little/no interrupts
                   (configurable by the user as usual) this problem would be
                   minimised.

                   In the object-based file system idea for KOSH, the
                   root object for any file system includes methods for
                   allocating and freeing blocks, which can be optimised
                   independently of the higher level file system objects. This
                   should make it fairly simple to incrementally de-frag.


x)

Subject: Accessing the system

Summary of debate: Rather than the standard downwards (or sideways) accessing
                   of menus we could use a pie system moving out from a central
                   point. As the pointer moves away from the center, the
                   "target" to select increases. In essence you are allowing
                   the user control over the size of the pop-up menu at each
                   instance.

                   Other alternatives could include using a hexagonal system
                   either emanating from a central point or providing a more
                   fluent way to pick sub-menus with more choice available at
                   each step. However this may not be easily accepted by people
                   who have been trained to expect 2D groupings in a
                   rectangular grid of some sort. Therefore for unfamiliar
                   users how intuitive would this system be?

                   A graffiti painting mode could provide an interesting option
                   for those that would like this. However painting can often
                   be frustrating to replicate with a mouse so this would have
                   to be kept simple.

                   If we implemented pressure sensitivity in the input device
                   we could perhaps remove the need for mouse buttons when
                   accessing the system in this GUI based manner (unless
                   someone preferred mouse buttons or keyboard shortcuts of
                   course).

                   A further suggestion is that the pointer could appear
                   somewhere other than at the top of a menu, perhaps
                   determined by the last or most frequent selection.


y)

Subject: Disadvantages of the Windows interface.

Summary of debate: See: http://www.iarchitect.com/msoft.html (NB: this was from
                   Greg's memory so it may not be quite this URL - ask him if
                   you get stuck) for a detailed analysis of the problems with
                   the Windows 95+ interface.