KOSH [Kommunity Orientated Software Hardware] Summary Inclusive of Dates: May 20th 2000 to July 28th 2000 Number: 033 Mailing List: kosh@chaossolutions.org Comments on this summary should be emailed to summaries@kosh.convergence.org or kosh@mythicz.u-net.com . If you think I've missed out (or mis-quoted) anything please contact me. -Bridge Deady *New Scribe needed* I will only be doing one more summary after this due to other commitments taking up my time from now on. If you are interested in taking over my duties please email me. In the mailing list these last weeks, the following items were discussed. a) Subject: Single mouse, dual window/screen activity Summary of debate: Suggested that the ability to have two windows or screens active at the same time, with the mouse clicks registering on both should be implemented. This would be in addition to the normal single-window/screen mouse activity mode. This feature could be used in a "trace" mode. Currently if one brings a window to the front and starts clicking, the results of the input are applied to the window at the front. With this system, the results would be applied to the window behind. However it was pointed out that using markers and copy and paste functions (much as in current systems) would most likely more than suffice. Even so, the attempt here is to provide a more fluid natural way of working. This is particularly apparent in art where in the real world. John provided the following: "I had an example of a paint package that attempted to emulate the way I use a real brush and palette using two mice and hence two 'pointers'. Left mouse controls my palette, which is essentially a window that follows the mouse but can be 'locked' into place by a click and then doubles up to control the load on the brush - i.e. how much pigment I have. So a swift upright movement gives me thick paint, and a drop full down gives me dry-brushing so I'm just picking up the texture faintly from an alpha channel. Meanwhile the right mouse is controlling where the paint is actually being applied, and I can move it over to the palette to select and mix colours." b) Subject: Command line interfaces in KOSH Summary of debate: KOSH will of course have some form of CLI, but it is unlikely that our CLI concept will be anywhere close to existing ones. c) Subject: KOSH Booklist update Summary of debate: The KOSH Booklist has been updated. In case you have lost the address: http://www.snowcrash.u-net.com/kosh/booklist.html d) Subject: KOSH Legal structuring Summary of debate: Many thanks to Bernard Giltrap for agreeing to assist with legal structuring and business items. e) Subject: Abstract data searching Summary of debate: A very powerful search system allowing more complex queries than those available with the Windows "Find Files" ability. Using multiple phrases, wildcards, boolean operators and the like would clearly be useful. The very interesting bit is that we are talking about being able to find anything - not just "files" and text within. The ability to search for images, sounds and any other form of data is envisaged. Greg takes it further: "More powerfully, let's imagine we give it a digital whiteboard. I sketch out a rough drawing because I can remember an image (or section of it) but do not know where it is. It then scans through - presumably using colour matching and edge detection - and ranks results by similarity. Or, let's say I've got a tune running round in my head. So, I hum it into the microphone and it returns a list of likely candidates. Now, this is all complicated, processor-intensive and would require a lot of R&D. But I can also really see the use for this one day, along with the marketing potential of yet another cool technology." Something along these lines can be seen at: http://www2.cs.cornell.edu/zeno/Papers/humming/humming.html Called "Query by Humming" it is a piece of research by Cornell f) Subject: Background task scheduling Summary of debate: To quote Greg: "What we essentially need is a form of soft-RT scheduling. Games need to be able to say 'help, I need all the CPU power I can get for the next few seconds!' on the understanding that that requirement will level out again a few seconds later, while the utilities need to get used to the idea of running when the system allows them to, rather than grabbing time when they want it. Again, on the understanding that they will get it, even if we're only talking 5% time over a longer period." This raises a problem when the key background task is something like a virus checker or firewall. We need some way to maintain essential background tasks while at the same time ensuring that CPU intensive processes get the clock cycles they need. To quote Ignaz: "Background tasks should have a low task priority all the time, including the firewall, the virus detector and the disk optimiser. The game should keep a slightly raised priority, and whenever it needs most of the CPU power, it can raise its own priority and lower it again after that. You can do that under AmigaOS; Unix does have some problems (you can raise a task priority only while being root) [Where possible] functionality [should rarely be] dependent on processing power availability. A firewall puts itself in between two OS layers, and after that there will be no chance to circumvene the firewall. Lower the priority of the firewall, and it will be slower, but you cannot circumvene it. I don't know any reason why a firewall, or a virus detector should have attached any process to itself. They can provide the whole security by being a library that integrates itself into the OS layer hierarchy. g) Subject: Moving KOSH forward Summary of debate: Bernard Giltrap produced a document derived from the KOSH ML Summaries detailing several points that ought to be forwarded. In brief: 1) Ownership of KOSH - looking at ESOP (Employee Ownership). 2) Object Distribution - slim binary/ANDF, security, licencing, anti-piracy, etc. 3) Object Model - develop an organic modem of what an object needs to encompass, emphasis on container objects for data import from other platforms. 4) Marketing - KOSH production and sales 5) Informational/Educational Resources - track expertise of KOSHans, identify deficits in the community as a whole, maintain resource references, etc. 6) Host Hardware Resources - would determine level of hardware support available within and outside KOSH. 7) Industry Standards - identify and assess various standards and their impact on KOSH. 8) KOSH UK - there are a number of people in the UK involved with KOSH; informal and formal meetings (perhaps in relation to publicity of KOSH at WOA) to formalise "KOSH UK" considered. Leading on from this, official establishment of KOSH in the UK required. 9) Promoting cooperation and communication - John Chandler's editorial discussing promotion of cooperation between the various projects such as AROS, Phoenix, AmigaOS for PPC etc. When KOSH has a legal structure in place, formal cooperation can be made (scribe's note: "unofficial" cooperation is taking place at the moment in various ways between KOSH and other projects). Follow-up emails discussed how a lot of the above is being progressed. h) Subject: Version control on autosaving Summary of debate: If two applications have the same document open concurrently version control needs to be in place to prevent one of the apps from autosaving an older version of the document over a more recently saved version being edited in the other app. The final form of version control in this context would be fully concurrent with branching. i) Subject: KOSH sign-up Summary of debate: If you have not completed a KOSH sign-up form we invite you to do so, to show your interest in the project: http://kosh.convergence.org/workinggroups/individu.txt For the completest, developers should register as "Red", and others expressing an interest "Blue" at the moment. j) Subject: Amie & KOSH & QNX Summary of debate: A query was raised as to whether the new Amiga Software Developer Kit and the Linux system it resides on could be used as the basis for a KOSH hosted development system. Obviously there are a number of functional and legal issues here we would need to examine. To quote John: The ideal thing for us would be to ensure KOSH has this same degree of portability, with the added advantage of something like Tao Elate's hardware-independent binaries. Total portability and independence from the ground up - from kernel to applications. Greenboy suggested that we familiarise ourselves with QNX's offering (particularly due to the free software release). See: http://get.qnx.com/ k) Subject: Kommunity Desktop Summary of debate: Marcus Petersson has created a new KOSH desktop at: http://www.desktop.com Username and password available on request (scribe's note: this summary can be edited to include them once I know it is ok to do so). There is also a KOSH account at: http://www.hyperoffice.com l) Subject: Linux & QNX Summary of debate: See: http://www.ann.lu/detail.cgi?category=unmoderated&file=963674816.msg To quote: "OSOpinion features a nice editorial stating that Linux is rather bloated and that X Windows is largely responsible. It further presents QNX's floppy demo as an example that such bloat does not have to be. How does this affect Amiga Inc and QNX chances?..." m) Subject: Rebol & KOSH Summary of debate: Chaz came up with an extremely good idea: "I believe what they need is a demonstration of the power of community. What I'm suggesting is that a number of you pick a REBOL project, KOSHify it and show them what can be done. [Some interesting Rebol links:] People have already written bots in Rebol, http://www.searchlores.org/sono_bot.htm Rebol programs can understand messages in dialects of your creation http://www.rediff.com/computer/1999/sep/29carl.htm Rebol processes can be servers and they can communicate to each other via internet ports. http://www.rebol.com/docs/network.html This guy is yearning for a Kosh-like use of Rebol http://www.rebol.org/userlist/archive/253/596.html The Object Sea is the killer framework that will revolutionize the way humanity interacts with computers." ------------------------ To unsubscribe - post to mdaemon@Chaossolutions.org with Unsubscribe kosh as the only line in the body. Problems, complaints - List-Admin@chaossolutions.org Web site - http://kosh.convergence.org