KOSH [Kommunity Orientated Software Hardware] Weekly Summary Week Commencing: 27th February 1999 Number: 010 Mailing List: kosh-general 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: KOSHan Privacy Summary of debate: A user of KOSH should be able to set their system so that it is totally private from any snooping from outside (such as by the KOSH website). However, increasing levels of abstraction could make this difficult. b) Subject: Games for KOSH Summary of debate: Many Amigans got their machines because of the excellent games available and this happened with the PC (eg: Doom). As a result it makes sense to say that KOSH is going to need decent games. Has anyone looked at DirectX style games APIs yet? c) Subject: Objects for different character set implementation Summary of debate: Perhaps instead of choosing whether to use Unicode, UTF-8 or ASCII the philosophy of KOSH of having a large sea of interrelated objects that make up the system could be utilised to allow for all three. This would be possible by just updating the relevant object(s) rather than the whole system. d) Subject: Disk ejection (continued) Summary of debate: On drives such as conventional floppy drives with a mechanical eject button KOSH could keep a buffer file of what is being copied to the disk. Then, if the disk is ejected during a crucial write operation the data does not get corrupted. e) Subject: Another plug for John's KOSH Booksite URL Summary of debate: Cos it's so good and cos he put a lot of work into it John gets a second mention (in case you didn't see it the first time). See: http://www.snowcrash.u-net.com/kosh/booklist.html for a very comprehensive list of books (many with further information) relative to KOSH. f) Subject: Windows rebate scheme Summary of debate: Giorgio Gomelsky passed on an email written by Jean-Louis Gassée which goes into great detail about how the Windows rebate scheme encourages retailers and OEMs to only sell Windows machines, without BeOS, Linux or any other system in sight. There are exceptions such as when a machine is shipped with Windows loading with BeOS nowhere to be seen and requires the user to finish off the installation of BeOS to reveal that it is there at all. The following URLs were mentioned: This is an interesting email that could have great significance to KOSH. Interested readers can read the full email posted by Giorgio Gomelsky on 27th February, entitled "[Fwd: Jean-Louis Gassée on why PC manufacturers don't sell non MS products". g) Subject: KOSH "datatypes" Summary of debate: KOSH should support some implementation of "datatypes" as seen in Workbench 3+, only more advanced. h) Subject: Sorting Summary of debate: A wide-ranging discussion on the benefits and disadvantages of various search algorithms took place. Algorithms mentioned included Quicksort, Mergesort, Bubblesort, insertion sort, Combsort and Shell sort. Anyone interested in sort algorithms should see http://wannabe.guru.org/alg/ i) Subject: Disk handling Summary of debate: On the Amiga both volume and device exist and may be addressed. On NIX everything is one whole big happy family. Perhaps KOSH could combine the two approaches, allowing you to set up drives like on the Amiga but also have the ability to merge multiple physical drives into one logical directory tree if the user desires it so. The flexibility of the KOSH Object Sea allows any type of disk handling method to be implemented, ie: "the user chooses", not "we who make KOSH choose for the user". To go one step further how about a virtual file system? The idea is that we take the notion of "URL" to the heart of the OS. This means that the physical location of a CD, HDD, etc would become less important. For example: you would decide where you want an application installed and mount the CD, or a portion of it, there. That mount actually exists as the union of the CD and a hard disc-based subdirectory -- this is probably done using a special kind of directory object. OS2 shows how this works. j) Subject: Emails Summary of debate: Could we set up a mail client that allows secure, reliable, backed up storage of mails that allows you to assign multiple keywords to mails then view and search by them? Or perhaps just search by keywords in the mail body, or both? All email could be stored in a database separate from the actual mail viewer program. This could incorporate all search and sort functions that one could desire and many more data fields than the mail came with (eg: a comments box for comments on the mail. Perhaps procmail is what is needed? Perhaps this could all be an extension of the "standard" email container. We would define an email message, and each message is an instatiation of that class. Then the class itself can be extensible to add attributes that are useful. Alternatively a universal database browser object could be used that would recognise "email" databases, "address books", "lists of pictures", etc. The object would then open as an appropriate viewer (and editor etc). k) Subject: Greg Webb, Clash Bowley and task migration Summary of debate: Greg Webb has volunteered to produce a paper on the subject of task migration after a plea from your humble scribe (who as he sits here summarising this is very very grateful to Greg for volunteering). Clash Bowley has also offered to help with this. l) Subject: Sales slogans Summary of debate: When we come to selling KOSH a nice simple slogan like Apple's "Think different" could be used. Suggested is "Just better". m) Subject: Protected systems Summary of debate: Perhaps any are a of the system could be specified as "protected" - this means that it cannot be accessed by the "unprotected" area, but instead only the protected area can access the unprotected. The aim of this would be to limit threats of viruses. hacking, etc on important "protected" areas. Included with this would be a "bio-filter" that would remove impurities (such as viruses) from files if the protected system tried to copy such a file from the unprotected areas into itself. Simple "public" (accessible to the outside world) and "private" (not accessible from elsewhere) systems could be used to include things like the kernel and object sea interface as private that can not be changed externally. Using assorted methods to allow read-only/write-only access allows us to change the internal implementation at a later stage should we need to. Suggested that we need more levels of protection than simply "public" and "private". Each task could be forced to ask the OS for read or write access to an object or memory area. The OS then decides if the task should be permitted access based on security levels etc. Could per-byte protection of memory areas be implemented? Perl's data tainting that "taints" data collected from an external source until checked for viruses (and any other nasties) is similar in concept to the bio-filter proposal. n) Subject: Setting up Working Groups Summary of debate: If you would like to set up a KOSH Working Group based on anything discussed on the General Mailing List then please contact Jason Radford, jradford@zellerzone.com or Ben Rothwell, ben@kosh.net o) Subject: miggyBID Summary of debate: Ben has set up a new Amiga online auction at http://www.amozilla.force9.co.uk/miggyBID (Scribe's note: mentioned here as I'm sure KOSH will make use of it or "koshBID" in the nearish future). p) Subject: Possible source of funding for KOSH Summary of debate: To quote: "Creating and Information Society for Europe The Information Society Technologies (IST) Programme support collaborative projects involving organisations of every kind, in industry, academia, public sector bodies and research institutions and a first call for proposals will be issued on 17 March. The Programme has a budget of 3.6 billion Euro for 1998-2002. This makes it the largest component of the European Commission's Fifth Framework Programme for Research and Technological Development. Its size and scope reflect the pervasiveness of Information and Communication Technologies in our society, and the rapidity of developments in the technologies and infrastructures themselves. This means that continuous efforts are required in research, technological development, demonstration and in the support of technology up-take." Could KOSH make use of this? To read more see the email posted by Giorgio Gomelsky, gio1@interport.net, entitled "Fwd: ISPO newsletter - Issue 28], dated 4th March 1999. Note that ideally you need either an html capable email program or a web browser to view the message.