KOSH [Kommunity Orientated Software Hardware] Weekly Summary Week Commencing: 23rd January 1999 Number: 005 Mailing List: kosh-hardware-o 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: Java Virtual Machine Summary of Debate: Some versions of the JVM are now quite fast and would be suitable to host KOSH. b) Subject: OS as a compiler Summary of debate: The OS could also be a compiler to generate the final code. See: http://www.helsinki.fi/~tksuoran/kosh_aom.html c) Subject: Big Brother Summary of debate: We must be careful not to go too far with the idea of copy protection, registration, etc. as it could strangle the project. At the same time we must not be too relaxed, copyright is copyright, applications should not be pirated. We must define our position between the two extremes. As KOSH is a community based OS, KOSH enforces cooperation between us. The answer to the above will lie with a solution that is favourable to the users and developers and not to the software pirates. d) Subject: Amiga 1200 Hosted KOSH Summary of debate: Suggested that we skip a hosted version of KOSH for the Classic Amiga line and jump straight to PPC/AmigaNG. This was countered by statements that the A1200 with a 68030 accelerator outperforms some pentium systems, many people have the A1200, it is good for a lot of people's needs and that people may not be able to afford to buy a whole new system. e) Subject: ISA Summary of debate: Conflicting views as to whether KOSH should support the old ISA standard. Suggested it would be pointless to do so, as there is little new ISA hardware coming out. This was countered by the fact that a lot of people use ISA hardware and would not be willing to buy/re-engineer new hardware just for KOSH which is reasonable. As some want ISA support and some don't the solution would appear to be Modular I/O architecture, with easy expansion. With the large user-base of ISA based systems, it makes commercial sense to support it. It comes down to the fact that each user should be able to drop the object-drivers of their choice into their Object Sea to run the hardware that they want to, and also be able to freeze any hardware support on their own system that they will not need. Such drivers should be optional extras, but should still be available. Inclusion and not exclusion of users. f) Subject: UUIDs and Dolphin Summary of debate: UUIDs consists of a 64-bit timestamp Dolphin uses UUIDs to identify interfaces to the kernel, because using names would result in a much larger chance of clashes. Dolphin will also use UUIDs to uniquely identify classes in its object system. The only thing identified by name will be methods, and the process for doing this will match the process traditionally employed to ensure dynamic linking in shared object files. g) Subject: 2 more Q's for the questionnaire Summary of debate: Suggested we add the following 2 q's to the KOSHan survey: C - What platform or current platforms do you think KOSH should initially target? D - What kind of mascot character would you choose to be identified with KOSH? h) Subject: KOSH WWW site Summary of debate: Concern expressed over the lack of recent updates to the KOSH web site. Access to the summaries for kosh-general, as well as being available on the mailing list are also available at http://www.mythicz.u-net.com/kosh.htm, or by email to ksummary@mythicz.u-net.com As with all the other summaries of the other lists, they will also be available on the main kosh web site in the fullness of time. i) Subject: Terminology (continued) Summary of debate: Perhaps we could look at defining new terms as these bring new perspectives. Old terms have a lot of "baggage" attached, with assumptions made. j) Subject: Blueprint Summary of debate: A blueprint contains information, that describes a lot of different things, including versioning, documentation, dependencies and a blueprint will have what is necessary to produce a class. k) Subject: Glossary Summary of debate: Luke A. Guest has offered to collate all terms relating to KOSH, with definitions and to sort through them and produce a useful glossary to go on the kosh web site. Send all glossary terms to laguest@nebulas.demon.co.uk, subject: KOSH Glossary l) Subject: Distribution format and slim binaries Summary of debate: Objects not conforming to slim binaries could have problems executing. Therefore in the kernel there needs to be a way to identify other binaries. We need to maintain platform independence as an essential feature of KOSH. Java and other binaries should be supported to retain platform independence functioning of KOSH. m) Subject: GEOS Summary of debate: GEOS is close to the dynamic logical-physical split UI that has been discussed. It may be 16-bit but it comes recommended and for research for KOSH, GEOS Concepts Volume 1 and 2 are recommended. it also includes a rather nice way of handling persistent objects relatively cleanly. n) Subject: Update on work in progress: Layered Plan Summary of debate: Kristan Slack has said that his work on the preliminary plan is almost done.. o) Subject: Arguments Summary of debate: Objects on the same processor could use a none copying approach which would be a lot faster that if every message has it's arguments passed as a KOSH object. The object manager could make the decision whether to copy arguments or not. A standard message passing protocol could be considered. If in KOSH it is general enough to communicate transparently across networks, maybe MPI could be used? It is fairly high-level, but allows for very low-level implementations. p) Subject: Versioning Summary of debate: The versioning could be a part of the container object that contains the pure text file, which would only exist an object sea. That container would have to conditionally passed along with the text file if transported to another sea, The container may not be a part of the "file" itself, but in that case would not be capable of incorporating version information for the file itself, just for the container. The ASCII nature of Amiga-type version strings made it possible to use them also in pure ASCII files, this feature could in some way be retained. Unicode is suggested instead of ASCII. q) Subject: Offer of assistance Summary of debate: Michael Franz at franz@ics.uci.edu university (scribes note: apologies I don't know what university that is) has offered help with KOSH with some of their existing work, noting that as they have limited resources they probably won't be able to help with a project if it does not yield any new research insight. r) Subject: Linus of Linux Summary of debate: http://www.paulallen.com/ has a list of projects that Linus is invested in and those that he has funded. s) Subject: Abstract Sound Summary of debate: A user wants sound, not a particular card or chip. Therefore KOSH would be better designed to give the abstract "sound" regardless of actual board and chip. There are problems with this approach, namely getting the right level of abstraction. This approach could be used for other extensions such as graphics. t) Subject: Book List Summary of debate: (Re-)Suggested that a book list relevant to KOSH be created and updated regularly. An introductory OS book mentioned is "Operating Systems Design and Implementation" by Tanenbaum and Woodhull, (Prentice Hall). u) Subject: Providing the skeleton Summary of debate: Suggested that KOSH could use one configurable GUI per application "type" (such as wordprocessing, rendering etc). This would aid modularity by providing a "standard" that a programmer could use to produce an object, such as someone programming a dictionary without having to worry about the end wordprocessor knowing that it would follow a certain pattern.