KOSH [Kommunity Orientated Software Hardware] Summary Inclusive of Dates: 23rd March 2000 to 30th April 2000 Number: 031 Mailing List: kosh@chaossolutions.org (formerly kosh@chaossolutions.com) *Please note the new KOSH mailing list:* * kosh@chaossolutions.org * Comments on this summary should be emailed to summaries@kosh.convergence.org or 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...again Summary of debate: Due to problems that Chaossolutions were experiencing there has been a shift from the .com suffix to .org. From now on the KOSH Mailing List is located at kosh@chaossolutions.org b) Subject: KOSH, TAO, QNX and virtual machines Summary of debate: With QNX Neutrino and Phoenix having a good thing going with development taking place and with Amiga's decision to use the TAO Elate/Intent system it looks likely from the discussions on the ML that KOSH may join in - with versions of KOSH being hosted on both as well as Linux. Note that we have not forgotten about the possibilities of hosting on other systems. The virtual machine properties of TAO's offering sparked great interest and debate. It was felt that this particularly offers the opportunity to port KOSH to many platforms with a minimum of delay. It was felt that writing a VM for KOSH should proceed soon. c) Subject: Potential virtual machines Summary of debate: As writing a new VM from scratch could take up a lot of programming time it was suggested that we utilise an existing one, at least to begin with. Two suggestions were made: MIPS and DLX. To quote Timo Suoranta from the ML: "Mips has several simulators, at least: http://www.cs.wisc.edu/~larus/larus.html http://www.ccs.neu.edu/home/swong/CompSim/ The DLX processor is a RISC machine described by John Hennessy and David Patterson in their book Computer Architecture: A Quantitative Approach. Simulator and other support software is linked at http://www.cs.adelaide.edu.au/users/petera/designers-guide/DG-DLX-material.html Good-looking Computer Architecture course notes online at, well worth browsing through for anyone on this mailing list: http://www.comp.nus.edu.sg/~johnm/cs3220/schedule.htm There is gcc crosscompiler at least for MIPS, because it is a real processor, and I think it can be used with a simulator. This would greatly help OS development, as we could write in C and not have to use asm for everything." Timo has put a document on his web site which details his investigations into the VM idea. It is located at: http://www.helsinki.fi/~tksuoran/sVM.html d) Subject: Open documents and XML Summary of debates: It was discussed and generally agreed that all "documents" and interfaces in a KOSH computer system should be open. With this we mean that any object should be able to access any other object and where possible any one object should not have exclusive control over another object. In relation to this XML was discussed again, although a common consensus has yet to be reached. For those interested in XML see: http://www.xml.com http://xml.apache.org http://alphaworks.ibm.com e) Subject: KOSH Kernel Summary of debate: It was suggested that C++ is used to program the Kernel as it is object orientated and we have many people with experience of this. Added to this should be assembler when we need to generate special inline functions. Objects will be programmable in any language. However it was stated that C++ is a tool with very sharp edges able to do good work but it can get messy if mistakes are made. Further, KOSH will be offering it's own object oriented mechanisms. It may not work well from C++, which uses it's own mechanisms. It was further stated that C/C++ is excellently supported throughout the industry with good and reliable compilers. With the choice of implementation language leading to a trade-off between various factors, C/C++ may be the best compromise. There is however a major problem with C++ for OS and other low-level applications, in that the memory allocations resulting from implicit object creations are very difficult to keep track of. In an application with a short lifetime, it isn't much of a problem, as the memory can be recovered at the end of execution. For an OS which will run for months at a time, memory management is a major problem. f) Subject: Phoenix and KOSH Summary of debate: John Chandler, also involved with Phoenix posted the following to the ML: "For those not subscribed to the Phoenix Platform Consortium mailing list, Phoenix has acknowledged KOSH as a valuable 'think tank' and to this end extended an informal invitation for KOSH to enter a partnership with Phoenix. This relationship would not involve KOSH losing its independence, nor would it involve taking us away from the current objectives of KOSH - both technological and philosophical. Just as companies such as Amiga Inc., QNX, Met@Box, and the many others involved in Phoenix haven't lost their own independence or individual goals. What it could provide us with is access to both the Amie (Amiga's Elate/Intent system) and QNX Neutrino, two excellent OS architectures with which to host at least an initial version of KOSH. Phoenix also lists hardware people who may pick up on the potential of KOSH, not to mention application developers. In return, KOSH could opt to release particular technology and information - the exact nature of this exchange is open to discussion. Of course, this relationship would not be entered into without the support and blessing of everyone here. KOSH is a community effort, after all. We would all need to discuss the finer points of the relationship, which will obviously involve a bit of give and take, but should ultimately prove to be a richly rewarding partnership for both KOSH and Phoenix." Greenboy of Phoenix replied to John, offering his support and reassurance to the above. Mario Saitti of Phoenix stated "To Phoenix, KOSH represents one of the most innovative technical development bodies in existence". He did have one provisor though, in that KOSH will need to be registered in some way; if not then work with Phoenix will have to be on an individual basis. Registration of KOSH is being considered, see the ML for more information. g) Subject: Modifications to the KOSH web site Summary of debate: Timo has put online his suggestion to fix the colours and structure of the KOSH web site. He stresses (as of 19/04) that it is only a partial conversion at the moment, see: http://www.cs.helsinki.fi/~tksuoran/kosh/ Timo then went on to look at http://www.lifl.fr/~beaufils/gtml/gtml.html and proceeded to produce a KOSH web site in gtml. h) Subject: KOSH Working Group Proposition Summary of debate: Timo has uploaded the working group proposition mailed by John Chandler: http://www.cs.helsinki.fi/~tksuoran/kosh/proposition.html If you have any comments please post them to the ML. i) Subject: Contrast and monochrome weighting issues for web pages Summary of debate: A web site with information and links to other sites concerning the above is at: http://www.toledo-bend.com/colorblind/ Andy also suggested the following@ http://www.textmatters.com/guides/visually_impaired.html j) Subject: KOSH Council Elections Summary of debate: A preliminary proposal based upon the existing KOSH Law Document was prepared and posted to the ML concerning the upcoming KOSH council elections. A copy is available on the web site if you missed it. If you have any comments that you would like seen, please post to the ML. One thing that this has shown up is that as KOSHans are from many different countries with different election systems and business structures, etc there is a need for a consensus to be reached. The discussions on the ML are rapidly moving in this direction. k) Subject: Get QNX Summary of debate: QNX is available for free. See http://get.qnx.com for more details. l) Subject: User interface interaction Summary of debate: Greg provided two example of what we could do to allow interaction with various entities as a whole: "Example 1: An address entry form. You've got multiple fields: Address, Town, County,... you get the idea. Now, we've all filled in this sort of thing what feels like a million times, and the format of them isn't always very consistent. But we tend to fill them in on autopilot. Type, jump to next field, type.... And, a couple of weeks ago, I got one wrong. The details were fine, but I'd not read the field headings correctly so I'd filled in a field that should have been blank with what should have been in the next field and so on down. Rendering the data gibberish. Instinct then tries to shunt the data with cut & paste - except the clipboard doesn't work when you have to work across fields, unless you want to manually shunt it around. Which isn't so clever. Now, I was only two fields into the data entry so it's a trivial job to manually re-enter, but it shouldn't be necessary. I'm not quite sure how to do it or even how many people would discover it, but the idea of somehow either being able to shunt data through the form or use the same clipboard entry across multiple components strikes me as powerful and the sort of toy that people like most of us would forever be taking pleasure in showing off to our friends. Example 2: ...a vector drawing program is where [the following] came up and it's probably the easiest place to spot the mechanics. Let's say we're playing with our vector drawing package - something like CorelDRAW! or ProVector, in case that helps people. Now, let's imagine we've got this effect we want, and we have to build it up across multiple components. Now, stand back and look at it again. For whatever reason, it isn't right. Maybe the colour gradient is wrong. Maybe it's a text effect and you've noticed you misspelt the title... Anyway, you need to make a modification to this set of components you've created. If it's one, it's easy. But, because it's multiple objects, it's a pain. One possibility for solving this... is in Windows. Pull up the Properties dialog on a set of files, and look at their attributes. If they're all set one way, then they're shown as that. If there's a mix, it's given ghosted. But there's no way of setting the new options as anything other than a broad set. You can't ask to invert everything, or to set flag X wherever flag Y is already set. Or, to take our drawing example, you couldn't map a curve showing your colour gradient, redefine aspect(s) of the curve and then have it change the colours for you. None essentially very difficult, all quite useful." This prompted much discussion, and created many other questions of the "how to" nature. Joel came up with the following: "Sounds like it might functionally tie in to the history/undo/'scripting' concepts discussed a while back. If each object maintains a finite history of its own changes then it would be possible to simply tell many objects "rewind and do that with THIS". The user dialog for such system control might still be tough though, as above." To which Timo presented this pearl: "Excellent hit to the right spot. Long ago I suggested (concurrent) version management interface for all kosh objects. That would help to correct any changes done earlier, completely remove need of saving versions to different files etc." Dr Peter Kittel pointed out that localisation of an address form for each country is needed. Postcodes, zip codes and street names are all used differently across the globe. m) Subject: WAP Summary of debate: If anyone wants information on WAP, see: http://www.wapforum.org/ n) Subject: Internet Resources Working Group (formerly Web Development) Summary of debate: Volunteers are needed to help Greg on this Working Group. We are in the transition stages of creating a new and greater web presence for KOSH. If you are interested please contact Greg Webb directly, greg@kosh.convergence.org . o) Subject: Cooperatives Summary of debate: It has been discussed how KOSH could borrow from the many successful cooperatives out in the world at large. For more information on cooperatives, see: http://www.coop.org/menu/informationsite.html