KOSH [Kommunity Orientated Software Hardware] Summary Inclusive of Dates: May 1st to May 19th 2000 Number: 032 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: Help wanted Summary of debate: If anyone has an hour or two available every now and then to help with these summaries please email me at kosh@mythicz.u-net.com - any help appreciated b) Subject: Similarities between KOSH and Amie from Amiga Summary of debate: It was noted that there are several similarities between the design plans of Amie and KOSH. For example the "AmiVerse" is similar to the "Object Sea". This is a good thing. For more information about the AmiVerse see: http://www.amiga.com/press/zine c) Subject: Logical Architecture Working Group Summary of debate: The LA WG is kicking off again. It looks like there will be at least four participants, others welcome - send a message to the ML. Martin has kindly set up a list for the LA WG. d) Subject: Law and KOSH Summary of debate: If anyone would like to provide legal advice to a community project like KOSH, please can they make themselves known. Thanks. e) Subject: Pass Around Document Summary of debate: The Pass Around Document (the PAD) version 0.9 has been released. PAD representative: Greg Webb, additional members: Marcus Petersson and John Chandler. This prompted a large discussion about the form the PAD takes. As this is most likely to be of little interest to those outside of KOSH, I'm leaving it to the people named directly above to take notes as they see fit. See: http://kosh.convergence.org/announcements/news/index.html http://kosh.convergence.org/projects/pad/index.html f) Subject: Zope Summary of debate: John Chandler has been using Zope, http://www.zope.org which is the "Zope Object Publishing Environment" written in Python to provide web-publishing services to produce a "Zope Portal" This will be demonstrated to KOSH soon. To quote John: "As it stands, it could be a useful way of constructing a community-based site in which people can contribute stuff themselves. Someone (i.e. me) provides the basic shell, I allocate a few additional managers who moderate the content alongside myself, and basically anyone can join and contribute. At the very least it would be useful to decide if we want to use it, or write something ourselves which does similar things." g) Subject: Computer Supported Cooperative Work Summary of debate: As part of the PAD discussion the following list of web sites was mentioned concerned with CSCW CSCW main sites: http://www.acm.org/siggroup/ http://www.telekooperation.de/cscw/ A list of CSCW supporting editors: http://www.telekooperation.de/cscw/multiusered-name.html A list of FAQs concerning CSCW: comp.groupware http://www.faqs.org/faqs/comp-groupware-faq/ Some big link lists: http://www.telekooperation.de/cscw/cscw-links.html http://usabilityfirst.com/cscw.html http://dougal.derby.ac.uk/andree/links.html h) Subject: KOSH Licence Summary of debate: Ignaz Kellerer raises several important issues: "KOSH developers want to get paid (allowing full-time jobs), but users should know the internals of the KOSH system. If they do not, they would not really know if they can trust KOSH software. The advantages of source code availability are great, most of us know them, but what are the disadvantages? Copying: "Information is free". Information must be free since no one can forbid any other person to have ideas and work them out. But the work that is needed to create a good piece of information must be rewarded. The ideal would be that developers get as much money as they have earned; after that, the information may be distributed freely. But you cannot distribute the cost among all customers since you don't know in advance how many customers you get. A solution may be: The first customer has to pay most, the second one a bit less, the third one even less, and so on until all costs have been amortized. After that, the information is free to copy. But I don't know what is needed to make that system really work. Another, less ideal solution is the one KOSH presented in the past: Charge money for all copies, no one is allowed to copy the software. Any surplus made will be returned to the community by letting them choose what to do with it (e.g.: distributing the surplus among the customers). Sourcecode availability: Customers can really trust only that parts of software which sourcecode is available to the community since no-one except the developers can know what closed software is really doing. Besides, open software promotes more interest among the community; it makes bug tracking a LOT easier; we get more developers since they have learned the source code as long as they were freaks; people learn to love the system more when source code is available. Also, people do know more about the system. Really huge advantages. The only disadvantage I can think of is: We have to find a way to prevent ...any company from taking advantage of recently developed sourcecode. i) Subject: Other operating systems (ie: more links for you to peruse) Summary of debate: Attempting to keep with my philosophy of posting all URLs mentioned on the ML (ok I missed a couple a bit back by accident) here are some more you may want to look at: http://www.500mhz.net - click on "index of systems" to see a partial list of existing operating systems. http://www.atheos.cx/ http://www.v2os.cx/ http://www.osnews.com/ http://www.tunes.org/Review/OSes.html#Indices http://homepages.paradise.net.nz/~marksibl/blitzidx.html http://sites.netscape.net/happyfrappy/os/os.html http://www.phys.uu.nl/~mjanssen/ http://www.reactos.com/ http://www.gaztek.co.uk/index.html http://www-dsg.stanford.edu/papers/cachekernel/main.html http://www.acm.uiuc.edu/sigops/roll_your_own/ http://www.cs.utah.edu/flux/oskit/ http://www.sysinternals.com/ http://www.freeos.com/ j) Subject: Babelfish on the KOSH web site Summary of debate: In case you are not aware, all the pages of the KOSH web site contain a link to Alta Vista Babelfish to empower more to read them. As there are other translation tools out there, has anyone any views on whether we should look at another instead of Babelfish? It was noted that Babelfish only covers a limited set of languages. This raises another issue. If anyone would like to manually translate any of the pages to other languages this would be extremely useful. As translation tools occasionally generate text which while literally correct are often grammatically in error (sometimes to the point of having a completely different meaning) having manual translations would be excellent. k) Subject: Internet Engineering Task Force and workgroups Summary of debate: If anyone is interested in how IETF handles workgroups see: RFC 2418 - IETF Working Group Guidelines and Procedures http://www.faqs.org/rfcs/rfc2418.html l) Subject: Guidelines on writing research papers. Summary of debate: Ignaz Kellerer found an interesting text on writing research papers. They are from: almanac@usenix.org mail-body: send advice papers If you would like a copy to read please email the above. m) Subject: Programming languages Summary of debate: A discussion over the merits of C, E, PERL, REBOL, Pascal, BASIC, Modula-2, Python and others was held - mainly off topic. It was stated that a list of all platforms that REBOL supports is at: http://www.rebol.com/releases.html n) Subject: Automatic mouse centring Summary of debate: Greg Webb mentioned the following site: http://slashdot.org/article.pl?sid=00/04/26/1231212&mode=nested concerning interfaces for the disabled. It is something that is worth reading. One of the comments is worth a particular note in that it suggests a command to automatically centre the mouse. Click the hotkey or combination and the mouse pointer automatically centres either on the screen or in the active window. Obviously this assumes a keyboard and monitor, but it could be any method of input and display. It was stated that such a feature should of course be optional. For some this would be useful, but for others it would not. An example of this is that a lot of people find that if the pointer "jumps" from one place to another without the intermediary gap being traversed that they lose track of where it is and take a second or two to find it on-screen again.