KOSH [Kommunity Orientated Software Hardware] Weekly Summary Week Commencing: 20th February 1999 Number: 009 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: Character codes, sets and formats (continued) Summary of debate: Suggested that we do not need backwards compatibility with ASCII directly within KOSH - which as previously mentioned could use UTF-8 or Unicode. ASCII<->unicode conversion could be the job of a data container object. However it was commented that this could result in an increase in storage space needed (presumably for unconverted+converted code) as well as doubling the data to be transferred. A good description of UTF-8 and Unicode in BeOS can be read in an email to this ML by Flemming Søndergaard (cupid@plastique.dk), subject: "RE: Character codes", 23/-2/99 (too long and complex to summarise here). See: "Unicode, UTF-8 and ASCII (dissertation of sorts)" by Joel Newkirk, posted to this list on the 25th of February which goes into a great deal of detail on this subject matter (too long and complex to summarise here). This led to a long discussion about the merits and disadvantages of various text formats - interested parties would do well to read the individual emails following on from the above one as several complex threads were developed that need reading in full to gain their correct context. The current status of this is that no clear decision has yet been made, except that possibly the development of a fully UTF-8 or Unicode aware environment would greatly increase the timescale for the release of KOSH 1 - perhaps implementing GCC would be better in the interim? Transparent import and export of all text formats should be part of KOSH. b) Subject: Types of seas Summary of debate: To describe other types of object sea, why not just add a qualifier to the term Object Sea such as "Local", "Regional", "Universal", "Primordial", etc. It emerged that there are a whole host of descriptions revolving around the term "Object Sea" that could be used to describe KOSH, all maintaining the "organic" nature of KOSH as a whole. c) Subject: Integral UPS Summary of debate: KOSH boxes could include a small (eg: 10 second) Uninterruptable Power Supply to safeguard against power glitches, or brief power loss however it occurs. However it should be possible to quickly disable the UPS if needed. d) Subject: Disk ejection Summary of debate: KOSH boxes should include the feature to have the ejection system for any disk-ejectable drives (floppy, zip, CD etc) configured by the user to manual or software eject only or both. e) Subject: Task migration (continued) Summary of debate: Could a migrated task be made to run in an encrypted or an obscured form so that even physical access to the guts of the target machine would make it impossible to steal data? f) Subject: Wireless communication Summary of debate: To reduce bandwidth requirements for sharing programs between computers how about using radio signals, eg: cordless phones working at 900MHz are now common. Perhaps in the not too distant future we could demonstrate "KOSHWireless" at various computer shows to generate even more interest in the project. g) Subject: House-wide systems Summary of debate: It was originally suggested that a central system (computer based central controller with CDROM and a large HDD) could distribute sound to audio "terminals" throughout a household, possibly using Audiophile (although this would be expensive). This would all be instead of having to have several CD players across a house as separate systems which is the easiest way to have house-wide high quality sound at the moment). This idea was developed by the fact that it is similar to a mainframe concept: one central large unit with a number of terminals - only in this case the terminals could be anything including televisions, sound systems, graphics workstations, telephones, door locks, etc. Communication lines to the house (eg: telephone line) would also be terminals and are all parts in one system. The central software would allow any terminal to gain access to any other on the system (eg: your TV could notify you when your coffee is ready). By using KOSH in all of the above, it could be at the heart of future homes and businesses. It was suggested that using KOSH in such a centralised manner could actually be rather clumsy as modern consumer electronics tends towards decentralisation with more power, intelligence and storage capacity being available at each node. A further problem with centralisation could be the increased bandwidths required to cope with data transfer between a large number of devices. However, hubs are designed to centralise the flow of information. See: http://www.siamese.co.uk re: TVNC which is apparently an implementation of the centralised home entertainment system (and contains the term "Digital Convergence" several times). It was suggested that to give KOSH the benefits of mainframe-ish system, more than one "terminal" must be supported. To this end the OS should not write directly to video memory, it must be able to accommodate more than one user at once, input and output devices should be assignable to one or more users and the system must be able to boot even with no active terminals. h) Subject: Removing computer illiteracy Summary of debate: If computers were more accessible, more logical in operation and with sufficient (and consistent) abstraction, computer illiteracy wouldn't exist. i) Subject: KOSH Booklist online Summary of debate: See: http://www.snowcrash.u-net.com/kosh/booklist.html which John Chandler has made available as an online list of book references to do with KOSH. j) Subject: Credibility of KOSH to developers Summary of debate: The credibility of KOSH to developers could be established and achieved by developing a target for GCC and company that would produce the appropriate format for KOSH. A good HTML viewer could be used for this - properly objectified and freely available to developers. k) Subject: Wizards Summary of debate: KOSH should have the option of implementing decently designed "wizards" that work well with and compliment both the user and the computer, but at the same time they should not cause confusion or be too simplistic. Perhaps by using wizards an application could be glued together from a number of contributing objects, thus presenting an easy way for developers (expert or otherwise) to create applications. l) Subject: CPU support Summary of debate: Suggested that KOSH should not be made with support for 68k and x86 processors as these are slow and would impose limits on what we are trying to do with KOSH. This was countered by saying that just if it is still usable, used and works well then KOSH should support it as long as someone is prepared to write the appropriate code. m) Subject: KOSH encryption Summary of debate: A question around the following was presented: Should we move away from public key encryption for the KOSH security model as SSL and RSA have been broken? n) Subject: TCP/IP communication Summary of debate: If there are requirements on the protocol that can't be met by TCP/IP then perhaps KOSH-KOSH communications could be met by a different protocol on top of this. o) Subject: KOSH Website Summary of debate: Greg is in the process of updating the site, if you have any important requests please pass them on to him: greg@kosh.net p) Subject: Open source and Software testing Summary of debate: http://www.zdnet.co.uk/news/kw/kewney61.html contains an article relevant to KOSH. It describes how "open source" may become the only way to develop software. It goes on to say that "nobody can test an OS under all conditions and... court(s would be unlikely to find an organisation) guilty of deliberately supplying insufficiently tested software (as) there is no definition of "sufficiently tested"". The above quote Copyright ©1998 ZDNet UK q) Subject: Proposal for a WG on Task Migration in the KOSH environment. Summary of debate: Greg Webb proposed the above on the 25th of February. Volunteer(s) to lead this please? r) Subject: WG definitions Summary of debate: Perhaps we need three different types of WG: Research groups - for looking into new ideas, Production groups - looking at developing an idea that we know is OK into a specific function, and Resource groups - to cover ongoing needs but not directly addressing KOSH features.