KOSH [Kommunity Orientated Software Hardware] Summary Inclusive of Dates: 21st February 2000 to 22nd March 2000 /Between mid January and 21/02/2000 the server was down/ Number: 030 Mailing List: kosh-general@iconimaging.net now kosh@chaossolutions.com *Please note the new KOSH mailing list:* * kosh@chaossolutions.com * Comments on this summary should be emailed to kosh@mythicz.u-net.com for the time being. If you think I've missed out (or mis-quoted) anything please contact me. -Bridge Deady In the mailing list these last weeks, the following items were discussed. a) Subject: Welcome to the new KOSH mailing list Summary of debate: On 21/02/2000 Martin Randall started the new KOSH Mailing List at kosh@chaossolutions.com - thanks Martin. b) Subject: Updating free subscriptions to the KOSH ML. Summary of debate: If you were on the KOSH Mailing List before the switch detailed above and have seen this summary but don't appear to be on the new mailing list please make yourself known to KOSH and subscribe to kosh@chaossolutions.com c) Subject: KOSH and World of Amiga 2000 Summary of debate: It was discussed that KOSH should have a presence at WOA2000. This is still in the early discussion stage. More details to follow as they come to light. d) Subject: Temporary settings in KOSH. Summary of debate: It was discussed and agreed that user changes to KOSH settings should employ some form of the Amiga "Use" and "Test" modes as well as "Save". Therefore if one accidentally changed a setting and was unable to change it back, a reboot (or a timeout: "press OK to accept changes within x seconds") would restore everything to normal if "Use" or "Test" was selected. However it was also suggested that perhaps an alternative solution to this is required. Perhaps a way to temporarily block access to a certain resource for all other processes than the one which really needs it (ScanDisk or whatever). Ideally you would have a backup option for the other processes to use (either a second disk or RAM disk, used as a mirror or cache). When you initiate the action, before the blocking takes effect, the modified bits in the cache are written to disk. Optionally every process could request their needed data to be added to the cache, so that they could continue to run as normal. This scheme may only be useful for slow resources like disks, modems, and some other devices like cameras, scanners and printers. Usage of such devices are rarely automated anyway, it makes sense to use the same system and interface for blocking all kinds of resources. e) Subject: Where to now with KOSH Summary of debate: Now that Fleecy Moss is busy with Amiga questions were raised as to where KOSH goes from here. Suggested was to move KOSH development over to an existing Amiga project, but it was justly pointed out that KOSH while "Amiga-like" in many respects is not Amiga. Further discussions will no doubt be formalised into a development strategy for KOSH in the near future. f) Subject: KOSH and Tao/Elate Summary of debate: Discussion was held over the merits of the Tao/Elate kernel being used as the basis for KOSH, particularly as it has the ability to be hosted on another OS. Again, "watch this space" for developments on this. g) Subject: Running Linux on an IBM S/390 Summary of debate: For those interested in the above see: http://www.linuxplanet.com/linuxplanet/reports/1532/1/ h) Subject: Representatives of KOSH Summary of debate: It was discussed that KOSH needs representatives to handle various areas. If you are interested in ay of the following please make yourself known to the ML: Press, Promotion, Public Liaison, Recruitment, anything else on a related theme. Also anyone who has skills in PR, marketing, writing, website development etc. who feels they can make a contribution (even if they probably don't have anything specific to say/do at the moment) please make themselves known here right now. No commitment, just an expression of interest. Also a "figurehead" in Fleecy Moss' absence, will also be needed - not just for internal leadership (if such a thing is required at the moment), but also to project an image of coordination and control to the outside world. Preferably this person would be high-profile within KOSH and other areas of computing as a whole. i) Subject: KOSH Announce List Summary of debate: It was discussed that KOSH needs an announce only mailing list to provide information directly relevant to the press and those with a passing interest who do not want to wade through the existing ML or summaries. j) Subject: Disabled access to KOSH Summary of debate: Over the next couple of weeks I (Bridge Deady) will be contacting various organisations and individuals working with disabled people to introduce KOSH and form links which can be used at a later stage to ensure that KOSH is completely accessible to all. A paper on this will be written. If you know of any individual or organisation that would be interested in the work that KOSH is undertaking please pass their contact details directly to me at csbdeady@mythicz.u-net.com An interesting web site containing many relevant documents is at: http://phoenix.herts.ac.uk/SDRU/hmpage.html k) Subject: KOSH PAD Summary of debate: The KOSH Pass Around Document describing a method for cooperation on writing documents for KOSH will soon be available in a draft form. l) Subject: Device Independence Summary of debate: It was described how there are often problems configuring some existing devices (eg: complex joysticks) to work generically with certain hardware and software combinations. As a result it was mentioned that we may be entering an era where true device independence will be vital to the survival of any computing environment. KOSH should have this concept at its heart. The following quote from Dave Haynie of Met@box illustrates this point nicely: "We need to distance ourselves from any entrenched paradigm of... 'programs' as they exist now. What is an 'email application' likely to consist of under KOSH?... an object that presents an interface for finding and interacting with local 'email objects', an object that sends and/or receives such objects to/from remote seas (or imports/exports from/to 'traditional' systems), an 'editor object' (or several, for various media types) for the creation of email objects, and the email object itself, encapsulating the actual data sent/received. Only one of these, the email object, is limited to use strictly for this purpose - all the others can function in other capacities. Also, each of these would in fact consist of a working aggregate of many objects (or classes?) themselves. Given such a definition, WHY would the 'email application' give a damn whether the 'message' composed by the user becomes an email object through a handwriting interface, a video camera, a speech->text conversion, or whatever? Why would it give a damn HOW the user instructs it to present a given email object, or even how that presentation occurs? That is all user interface, not email. As I understand the object sea proposal, and KOSH's intentions toward realizing that proposal as a functional ecology, it is VITAL that - from the start - we thoroughly divorce ourselves from such concepts of programs." Dave stated that this is not intended as a final description, just a first approximation. A quote from Greg Webb supports this but shows some caution in the short-term: "There's a very real appeal in being able to mix and match. In the long term, there is for plenty of people. But in the short term, or for people who find AOL or Macs complicated, we need to remember that the application as a monolithic concept is useful. Even if it's fundamentally a set of utilities and some UI glue, it needs to be able to appear as a standard application or we'll confuse users and scare away developers. Neither of which are exactly a good idea." There were many other comments and this debate seems set to continue. m) Subject: Advances in interface design Summary of debate: See the following for some independent suggestions on the above: http://www.quailwood.com/limit.html http://www.arstechnica.com/reviews/1q00/macos-x-dp3/macos-x-dp3-1.html n) Subject: Signup forms on Web Site Summary of debate: If you want to sign up to helping with KOSH in a specific or general area or just as a supporter and have not done so already, there is an extra file on the web site http://kosh.convergence.org which may fit the bill. Please show your support to the project. o) Subject: Usability Interview Summary of debate: Slashdot held an interview with Jakob Nielsen convering usability in which he describes something not too disimilar from the object sea: http://slashdot.org/article.pl?sid=00/03/03/096223&mode=nested p) Subject: E-Speak Summary of debate: Suggested reading time again on e-speak: http://www.e-speak.net "A Tutorial in Developing E-Speak Services"