KOSH [Kommunity Orientated Software Hardware] Weekly Summary Week Commencing: 26th December 1998 Number: 001 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 summaries@kosh.convergence.org, stating the Summary Number, and Mailing List Name, and he will try to answer your queries. a) Subject: KOSH configuration Summary of Debate: Being able to change the configuration of everything in the UI should be possible, but this could create problems for applications and for technical help. Interactive real-time configuration and reshaping of GUI elements suggested and further that electronic manuals could possibly automatically update when GUI changed. XML suggested instead of this. Caution re configuration and flexibility expressed by one subscriber as extremes of either could make KOSH impossible to configure and slow to use. Perhaps therefore a middle ground should be looked at. A solution to this is proposed in that each task is constructed by a number of small and fast specialised objects, however this could in fact increase system overheads. b) Subject: KOSH screens and windows Summary of debate: Suggested that KOSH interface should retain a version of the screens system (each with independent resolution and colour depth) as used in AmigaOS. An abstract window concept could be implemented where-in each user can choose how they would like their UI "windows" (perhaps "working-environment" is better) to appear and work. c) Subject: Application requirements Summary of debate: Although KOSH should be able to run on any configuration it was noted that certain applications would have minimum requirements (such as an art package being able to output to a graphical display); noted exception is POV-Ray which can render without a graphical display. The OS could be made to render to different mediums, such as graphical display to a text output, Braille output or even Quake rendered in Audio. Programs could notify the user that a certain configuration or above (eg: screen resolution) is required for optimum use of the program, but if the user does not have this they should be able to use it anyway, admittedly not at its best. d) Subject: Logging user actions Summary of debate: If there is a danger the user might mess things up, why not put a log file somewhere that records all the changes to all settings, then after a bad reconfiguration you can "undo" back to pre-the-mess by reading the log file. e) Subject: KOSH compared to other OSs Summary of debate: The consensus appears to be that the majority of modern OSs are bloated and prevent the user from reaching their full potential (although nice things have been said of AmigaOS and Linux despite their flaws). KOSH should be easy to use and aid creativity, not hinder it. f) Subject: Widening the Kommunity Summary of debate: As early as possible we need to get strong software developer support. We could get "KOSH specialists" to write to all informatic publications to get more people involved with KOSH. g) Subject: Audio WG Summary of Debate: An Audio WG promoted, to see what the interest would be in this. h) Subject: KOSH Merchandising Summary of Debate: The idea for an individual character for KOSH (along the lines of the penguin for Linux) was previously suggested. Further, maybe Eric Schwartz (creator of Sabrina for the Amiga) could be asked to design a new character. Perhaps it could be something connected with the object "sea" such as an orca, dolphin or yaught. Lava lamps for KOSH also suggested. i) Subject: Versions of KOSH Summary of Debate: Further to the suggestion that there could be "lite", "extended" and "heavy" versions of KOSH, perhaps the number of objects in the OS could be greater in the complex versions but with the possibility of upgrading the "lite" and "extended". To accommodate people's different needs, could have separate KOSH CDs: 1 each for graphic objects, audio objects, programming objects and network objects etc. It is further suggested that a minimal demo version of KOSH be available that would boot from one floppy to allow people to try out KOSH. Such a floppy demo could be made to work on "graveyard" machines - those that are abandoned in offices but looted for parts. Network them together and you could have a KOSH render farm for eg. j) Subject: Implementation of KOSH Summary of debate: An underlying system based on existing procedural systems like Linux with an Object layer on top in the form of a desktop is suggested. The OS should provide a simple, powerful and efficient foundation for any software. The consensus is that KOSH is not going to be -just- an OS but a whole environment including the OS, control medium (keyboard/audio/etc), display medium (Braille/monitor/audio/etc) all based around the object sea. From this KOSH looks (at the moment) to become an organic environment, to quote one mail: "a complex social ecology" KOSH 1 will probably sit on top of a Linux kernel if we adopt a phased development approach. k) Subject: Code in the object sea Summary of debate: Coding for the object sea has 2 features: the ability to reuse and build upon old code and that each unit of code is simpler, as it needs to account for only one static case (with allowance for dynamic changes during the lifetime of an object. The definition of the properties of an object needs to be agreed upon. Objects define the core OS operations. A class object could function something like a shared library, but in charge of only one object's management. All "objects" - perhaps entities is a better word - in the object sea must have a type, as with all things in the real world. l) Subject: Viruses and KOSH Summary of debate: Virus prevention should be considered right from the start. Maybe an internal kosh "hacker" group could help on this. m) Subject: The term "object" Summary of debate: Concern expressed at the use of the term "object" as could be confused with "object-oriented programming" and may imply something passive like a potato (although perhaps it refers to something discrete, separate and self-contained). Alternatives suggested include "organism", "creature" and "critter". A further suggestion is to retain the term "objects" for a set but use more unique terms for specialized objects. Perhaps an ecological model for KOSH based on GAIA could be used. n) Subject: KOSH on the internet Summary of debate: The web site could become a souped up Aminet with shareware and pd objects to be used in the object sea. A central archive (kosh object bank) could be set up for their distribution, with online registration. This could also be a source of documentation relating to kosh. o) Subject: Ben Rothwell's weekly update Summary of debate: Robert Wise is now the official scribe of hardware-o, Bridge Deady is now the official scribe of general and Kristan Slack is now working on a layered plan regarding KOSH scripting language. Reminders re applications for positions have been sent to those who have not returned their application forms. A database containing information re the people in the working groups and the scribes has been created. A complete set of application documents, Codes of Practice and Template relating to new Working Group applications and Scribes has been produced. p) Subject: Expert systems Summary of debate: Suggested that KOSH could -perhaps- be built upon an expert system in that the system would "learn" what the user needs. q) Subject: KOSH summaries Summary of debate: A kosh-summary ML could be started containing just the weekly summaries. r) Subject: Shutting down a KOSH system Summary of debate: Upon shutdown of a KOSH system, important applications running could automatically be paused and recommence when the system is next booted. Alternatively after selecting "shutdown" the OS tells the user what is being saved and after all drive activity has ceased, the OS turns off the power. But this could result in a lock-out situation if the OS hung. However perhaps people would not want the OS to automatically continue what it was doing, therefore such a shutdown feature should be optional.