KOSH [Kommunity Orientated Software Hardware] Summary Inclusive of Dates: 21st November 1999 to mid January 2000 Number: 029 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. Additional Credit to Greg Webb for his contributions and to John Chandler for reading over what we wrote. -Bridge Deady 24/02/2000 In the mailing list these last weeks, the following items were discussed. a) Subject: KOSH and POP Summary of debate: The release of the POP specification for PowerPC chip based systems raised some interest. It was suggested that this adds yet one more viable option for a port of KOSH. b) Subject: KOSH & Amiga & Others Summary of debate: There has been quite a bit of talk both on and off list concerning the perceived links between KOSH and Amiga, ie: that KOSHans are all Amigans. Just for clarity, KOSHANS use everything from Linux to BeOS, from Win32 to AmigaOS with MacOS and also making themselves known. c) Subject: "KOSH UK" continued Summary of debate: Continuing on the theme of a meeting for people interested in KOSH in the UK Reading appears to be the best bet as many of us are within sprinting/jobbing/driving distance. d) Subject: "The LART" Summary of debate: Apparently people can be inspired to produce great things with the aid of a LART. This amazing device appears in many forms, but 2x4 seems to be the most common with a triangular cross-section. Apparently we should all read: http://www.tuxedo.org/~esr/jargon/html/entry/LART.html or http://www.phil.uni-erlangen.de/tree/jargon/html/L/LART.html for further information. e) Subject: Introduction to KOSH website Summary of debate: Andy Wanless is coding the above including news and FAQ questions. The last I heard was that he is after encouragement (hence the talk about the LART...) Thanks Andy. f) Subject: Flying Mice Summary of debate: Clash Bowley suggests saying hi to: http://www.flyingmice.com and http://www.flyingmice.com/squid/moobunny/amiga sounds good to me. Clash also suggested a KOSH message board could be added to the MooBunny which sounds like a jolly spiffing idea. g) Subject: KOSH, x86 hardware, IDE, USB and SCSI Summary of debate: There is a potential problem with the current x86 hardware in that there are only 16 IRQs (partially overcome with PCI and DMA). After some have been reserved for the system timer, math co-processor etc this does not leave many for expansion. It was therefore suggested that a "KOSH Box" should not use IDE. While it is cheaper, and with UDMA-66 it's very competitive performance wise - it only contributes to the IRQ problem. Ideally though the final KOSH hardware solution won't be based on x86 architecture. Instead of IDE it was suggested that USB and SCSI be used as both manage good performance at the cost of only a single IRQ. If standardization of a physical form-factor for a USB based expansion cartridge could be developed this would be ideal and allow "hot swap" bays. It was also suggested that the NIC could be USB based - 10/100 port backed up by USB. However the potential problem with 16 IRQ's was countered by some by stating that there could be one IRQ hardwired per slot and then these could all be connected to an external interrupt controller. That one then uses only one "real" IRQ to wake up the CPU, which then polls which IRQ happened from this interrupt controller. Others also disagreed with the idea not to use IDE, partially due to the current overinflated prices for SCSI controllers and the high costs of SCSI drives when compared to IDE. It was suggested that for IDE a RAID controller (eg from: http://promise.com for about $150) could be used. USB drives were also discounted - the current transfer rate was quoted at under 600kb/s, however if USB2.x can deliver near 48mb/s as quoted on the Mailing List then perhaps this would be viable. However it was suggested that by having separate "cards" (CPU, graphics etc) and "drives" (HDD and others) boxes connected to each other via some form of USB, the form factor of the "cards" box could be significantly reduced while allowing easy access (with no risk of damaging the cards) to the drives. Overall it was felt by all that KOSH needs to go beyond current existence of some bad hardware - perhaps by defining a completely new standard? h) Subject: Iwin Summary of debate: The interesting goings-on at Iwin Corp. can be seen at: http://www.iwin-corp.de and by selecting "products" and then "Xetos" one can have a look at their OS plans. (NB: KOSH is neither advocating nor condoning the goings on at Iwin - well not until we have something concrete to look at anyway). i) Subject: KOSH Reading site Summary of debate: The KOSH URL at Reading University has been removed but the other two sites are open for "business as usual". j) Subject: Mice Summary of debate: On Slashdot someone mentioned someone who uses his mouse with his foot to keep his hands free for the keyboard. It was suggested a custom mouse could work through shoes, something similar to a foot massager perhaps? This could work with a big version of a laptop joystick for the ball of one foot, with the mouse buttons handled with the other or alternatively more of a trackball afair. The ability to use this as a "second" mouse received a favourable response, allowing more freedom in CAD, artwork and working with a true multi-tasking system in general. Part of the reason for this is that if one lacks a true 3D input device then one mouse could be used for XY and the other for Z with one "spare" axis (rotation?). It was pointed out that it should not be difficult to integrate such devices into KOSH, perhaps naming it a "Fouse" (Foot/Mouse). Alternative mice with lots of buttons can apparently be found at http://saitek.com The point that as mice get more ergonomic keyboards are tending to go the other way was raised. We -definitely- need to consider the control of a KOSH system with care! k) Subject: Musical PDA Summary of debate: The potential workings of a musical PDA with a good CPU, microphone and a headphone jack with a touchscreen was described. It included two touchscreen areas, one for "bar start" and one for "new beat" to allow music to be "drawn" on screen. The microphone would be able to calculate pitch from a noise that one makes into it. It would then work calculate a thythm in conjunction with the beat tapping on the screen. Both aspects would be smoothed by an algorithm. See http://www.akoff.com for relevant software along these lines for the PC. l) Subject: Promoting Cooperation and Communication Summary of debate: John Chandler has written an editorial on the trying to promote cooperation and communication between the various projects out there striving to make the next logical step after the Amiga: KOSH (Amiga replacement in part only), AROS, Phoenix, AmigaOS 3.6/4.0 for PowerPC. It can be found at: http://www.suite101.com/welcome.cfm/amiga To quote from John's post to the ML: "The idea is that each project is currently trying to forge their own post-Amiga vision. Some are a direct evolution of the Amiga with useful backwards compatibility, others (like KOSH) are a ground-up reassessment with no real interest in offering out-of-the-box Amiga compatibility. Each project is relatively small in the big scheme of things - a limited number of developers and infrastructure, but big ideas. There are some overlaps of resources... yet no real exploitation of these overlaps. We discussed a while back about opening up channels of communication and cooperation between the differing projects, pooling development time and resources for mutual benefit but never really made a start on building those links properly. Well, Greenboy (one of the main voices of Phoenix) has expressed an interest in forming links with KOSH, partly fuelled by the recent IRC conferences which KOSH undertook just before Phoenix. By cooperating and communicating we can hopefully: - Break down the petty squabbles and backstabbing that seems to exist... - Pool valuable resources: ideas, time, developers, maybe even money or hardware and software... - Open up links to users, developers, retailers who either haven't heard of us, or maybe can't afford to support multiple projects without very good reasons... - Facilitate efforts to have consistent software available for all the different projects... allow software to be ported easily between the different systems opening up a broader spread of application support for each OS." To this Greg Webb added: "Steve from COSA approached me about us cross-promoting each other right after the IRC conference." It would therefore seem that there are definite links already in existence that need to be developed. However it was felt that we should not merge with any other development group as our aims are rather different but supporting each other would be good. As KOSH is not about developing an "NG" Amiga we need to maintain our view that KOSH is trying to design the right platform for the world as a whole. Perhaps we can parcel out some of the KOSH development time to other projects? Perhaps extend the KOSH idea of credits to all the projects, allowing us to build up some credits owed by other projects which we can cash in later when we need it? It may be possible to get the other projects to contribute to a recently suggested idea, that of a repository of KOSH code. Probably some code would be designated "for all", some for "just KOSH" or "just Phoenix" or maybe "non-Commercial use only". m) Subject: Scripting and possible integration with the OS. Summary of debate: It was suggested that the directory object, rather than just being a container, could have a script attached to be run on file updates within that directory. It was pointed out that this could cause undesirable results should files be inadvertently saved to an affected directory. It was noted that this should not ideally operate on the original file as to do so would increase the chance of accidental file damage and provide a very powerful mechanism for virus writers. It was noted that there's no fundamental reason why the scripting has to be producing a derivative of the file and that this could be sued to update a document management system. It was suggested that this could provide a mechanism for automated digital watermarking and document tracking. Do NIST (http://ww.nist.gov) have an official standard for this? It was suggested that this could usefully be extended to allow scripts to be chained to arbitrary system operations rather than just file updates. To quote Andy Wanless (23/11/99): "Maybe instead of just a menu option saying "Open", you get "Open" and "Open with filters" ? Then of course, do any of these filters in the parent directory apply? Or you could define big complicated chains of filters and use them if you want to. Take an XML file, send it off to Babelfish for translating, then apply the XSL stylesheet, all from within your ftp client when you try and upload a file." This was noticed to be close to the Unix pipe in functionality, so providing us with a potential example to work from. It was also observed that, by attaching methods to e-mail a reasonably powerful base for groupware is provided. Alternatively, it could be used to provide differing levels of service for different classes of user. To quote Paula Lieberman (29/11/99): "There could very easily be situations where different users have authorization for different products from the same query - someone paying large amounts extra might get image files in lossless form, while a random surfer could get 640 X 480 jpegs of the same set of images, which would not allow the level of fidelity the e.g. stock image commercial account customer would get - the stock image high priced account customer might be using the images as high resolutions graphics images in magazines, and paying substantially for the privilege of using the highest resolution of image fidelity available. The web surfer isn't paying that kind of money and is not getting the high priced level of resolution and implicit service." Scripting in general came back into discussion and it was suggested that scripts could perhaps be written graphically as flowcharts. In addition, would it be worthwhile to allow them to interact with each other across distributed systems? It was noted that this should ideally be usable as a batch processing mode where appropriate. It was suggested that this could act as a powerful abstract data passer - for example, providing a printing mechanism. n) Subject: File saving (it's more interesting than it sounds, OK?) Summary of debate: It was suggested that Autosave facilities could usefully be provided automatically by the freeze and unfreeze methods rather than relying on the program to implement such a feature themselves. It was suggested that this could be expanded so the methods were effectively providing a dynamic undo system, but noted that this would definitely have to be optional and configureable to avoid creating vast quantites of unnecessary data - though it was suggested that delta files could usefully be used where appropriate to reduce resource usage. It was suggested that saves could be made only when specific conditions had been made, per-paragraph in a Word processor, for example. It was suggested that perhaps this should not necessarily be a linear operation and branching should be allowed where appropriate. To quote John Chandler (23/11/99): "However, a really good Undo is what I need. I mean *really* good. Not the last action, or a couple of actions... I mean paths of actions, trees of actions that I can traverse backwards and forwards... Say I'm writing a novel and I've completed 3 chapters. Chapter 2 and Chapter 3 would make more sense the other way around so I drag Chapter 2 to the end of the document. Original --> Change 1 Now I rewrite the new Chapter 3 a bit and add Chapter 4... Original --> Change 1 --> Change 2 Oops, decided Chapter 4 would be better between Chapter 2 and 3... Original --> Change 1 --> Change 2 --> Change 3 Hmmm... now it looks stupid, so I go back to the first change and create a new Chapter 4 followed bye Chapter 5... Original --> Change 1 --> (Change 2) --> (Change 3) \ +-> Change 4 --> Change 5 Creative troubles again! Maybe I want Chapter 5 added to the state of the novel I had with Change 2... I copy Chapter 5, move back to Change 2 and paste it in..." Cross platform compatibility was noted as a potential problem. The merits of explicity requiring a save request were debated. Some felt it outdated, others felt it useful, most felt it useful only in some situations. It was suggested that these could be combined so the system performed automatic saves but to a spare, temporary file in a dedicated location. When a save is requested the system merely has to copy the temporary file over the standard file, while in the event of a system failure the user can retrieve the working copy and combine the two as they please. It was suggested that the OS itself could record a history of user input actions, but noted that this could make a mockery of password security. It was pointed out that many objects will be persistent so this may well be automatic anyway... o) Subject: Data formats Summary of debate: It was suggested that HT/X/SGML could be used as a universal object container, especially for plain ASCII text files. p) Subject: File addressing Summary of debate: It was asked whether it would be practical to use n-bit addressing for files rather than fixed size. It was noted that this could potentially have a large performance hit and so may be better served by setting a range that was merely improbably large. q) Subject: Layered files Summary of debate: It was suggested that we could usefully allow a facility for abstract document types to be overlayed on one another for easier annotation of documents. r) Subject: Time stamping Summary of debate: It was suggested that a unique time model - for example, timestamping with GMT and an offset - would be preferable to merely using the current system time to prevent potentially ambiguous times due to daylight saving time or moving between timezones. s) Subject: File names Summary of debate: It was observed that, with conventional system, different files may sometimes require the same name - perhaps with a version number, perhaps in a different place in the directory tree. This can potentially be confusing or awkward to use, so could the system default to containing one file per ID but potentially handle several as records in a database? t) Subject: Surveys Summary of debate: Greg posted the next draft of the proposed KOSH survey (presumably updated again by now) in early December. More info here on it in the next summary (this one's long enough!) u) Subject: Promoting KOSH in the media Summary of debate: KOSH has had a few mentions in the press recently and it was felt that we should step up our "press campaign". v) Subject: KOSH Booklist Summary of debate: Continuing with my theme of plugging this at every opportunity, just a reminder that the latest version is at http://www.snowcrash.u-net.com/kosh/booklist.html w) Subject: Blind computer use Summary of debate: Slashdot ran an article on this. Not sure if it is still accessible, but just in case try http://slashdot.org/article.pl?sid=99/12/09/1342224&mode=nested ------------------------ To unsubscribe - post to mdaemon@Chaossolutions.com with Unsubscribe kosh as the only line in the body. Problems, complaints - List-Admin@chaossolutions.com Web site - http://kosh.convergence.org