KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 13th February 1999

Number: 008

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 ben@kosh.net, stating the Summary
Number, and Mailing List Name, and he will try to answer your queries.

a)

Subject Object Ocean

Summary of debate: An object ocean made up of many object seas plus network
                   objects which belong in no particular sea, but are
                   accessible from all was suggested.

                   An application server could send out precompiled binary
                   across just such a network. This may not be a "physical
                   server" but instead a function of the operation of the sea.
                   If a machine is isolated from the sea and then becomes a
                   part of the sea then all the common resources of the sea
                   should become available to it.


b)

Subject: Cloning

Summary of debate: A variation of migration is where a task is duplicated on
                   another machine but the original remains in place.


c)

Subject: More book text

Summary of debate: The Macmillan Personal Bookshelf has a "side service",
                   Betabooks which has current text of books-in-progress
                   available online.
                   The URL is http://www.mcp.com/betabooks


d)

Subject: Character sets (continued)

Summary of debate: Alternative character sets such as Japanese or Chinese
                   should not be treated separately, but instead we should use
                   UTF-8 or Unicode which could support such character sets.


e)

Subject: Slim binaries and anti-piracy

Summary of debate: Fixing slim binaries will also solve some serious problems
                   in anti piracy, it will enable a portable keyfile system to
                   be used across various platforms.


f)

Subject: UTF-8 or Unicode instead of ASCII?

Summary of debate: Would it be possible to use UTF-8 or Unicode instead of
                   where conventional systems use ASCII? The two main problems
                   with ASCII are that it is a vaguely defined standard and
                   only has 256 characters which is not enough. Unfortunately
                   most other systems use ASCII and programs would need
                   translators.

                   Alternatively make a new character code standard,
                   "KOSHKode". Each letter would be 32 bits. The low 16 bits
                   are standard Unicode but the upper 16 bits could be used for
                   font size and font selection. This could help make a
                   standard for wordprocessing. However only "KOSH-aware"
                   software would be able to read the new standard. The general
                   consensus seems to be that such a new standard would produce
                   a number of problems including compatibility, and over-large
                   files etc.

                   See http://unicode.org/ for further information on Unicode.

                   http://www.amazon.com/exec/obidos/ASIN/0201483459/joelnewkirk
                   (shameless plug for Joel's agent thing there) is a URL with
                   a book called "The Unicode Standard, Version 2.0",
                   ISBN 0201483459, cost $63.

                   See: http://www.cs.monash.edu.au/~jono/ISIS/Solo-bio.html
                   which is a URL detailing Ray Solomonoff and his invention of
                   Algorithmic Probability - and was involved with setting up
                   ASCII originally.

                   Scribe's note: Please see Paula Lieberman's (paal@gis.net)
                   post dated 16/02/99 "Re: Character Codes" which is 19k's
                   worth of excellent text relating to this thread and includes
                   numerous URL's like the one above - but which would double
                   the size of this summary if included here:P


g)

Subject: Distribution and precompilation

Summary of debate: Code that is generated and distributed could be either
                   precompiled on the host machine or compiled on-the-fly
                   depending on the CPU. Perhaps a basic form of this could be
                   built into KOSHv1 to see what the response to it is. This
                   would be tied into the ability of the software to be
                   migrated from one machine to another.

                   Such abilities would eventually allow a home network with
                   transparent resource sharing (including distributed
                   processing) and free and transparent migration across
                   machines.


h)

Subject: Uninterruptable Power Supply

Summary of debate: How about a 10 second UPS on KOSH machines - which should be
                   enough for at least a partial shutdown (including finishing
                   disk activity)?


i)

Subject: Software disk ejecting

Summary of debate: Suggested that software disk ejecting (a-la-Mac) could be
                   implemented to reduce the risk of disk corruption.
                   Alternatively make it so the manual disk eject button is
                   disabled until disk activity is finished. Both these ideas
                   could cause problems if the system crashed and locked out
                   the floppy drive (although a "paperclip" eject like Macs
                   could also be used).


j)

Subject: Delayed messaging

Summary of debate: Could include a delayed message send feature in KOSH so that
                   when a file/email/whatever is sent from one KOSH machine to
                   another on a LAN/WAN and the recipient machine is turned
                   off, it receives the "thing" the next time it is turned on.


k)

Subject: KOSH timekeeping

Summary of debate: Instead of an internal timeclock for KOSH machines on the
                   internet we could implement an online-timekeeping device
                   instead to maintain correct system time.


l)

Subject: Proposed Working Groups

Summary of debate: Joel Newkirk has proposed the following working groups:

                   Marketing - the what and how of KOSH production and sales.

                   Object Distribution - slim binary/ANDF, security, licencing,
                   anti-piracy, etc.

                   Nomenclature - document and as needed devise naming
                   conventions used within KOSH and to monitor usage of such
                   terms, etc.

                   Informational/Educational Resources - track expertise of
                   KOSHans, identify deficits in the community as a whole,
                   maintain resource references, etc.

                   Host OS Resources - subdivided into teams dealing
                   specifically with particular OSses to move towards being
                   able to host KOSH on such systems, etc.

                   Host Hardware Resources - would determine the level of
                   hardware support available within and outside of KOSH and
                   make attempts to increase this.

                   Industry Standards - Identify and assess various industry
                   standards available and their impact on KOSH.

                   Migration - research and propose a system of modems allowing
                   objects to be transferred from one KOSHer physical system to
                   another.

                   Object Model - (perhaps already covered in KOSH) to try to
                   develop an organic modem of /what/ an object needs to
                   encompass. Also emphasis on container objects for data
                   import from other platforms.

                   Scribe's note: Full details of the above that were proposed
                   can be found in an email by Joel Newkirk dated 21/02/99,
                   entitled "WorkingGroups..."

• Nach Aussage von Stefan Burstroem von Omnipresence Intl. wird IBrowse 2 ebenfalls das PlugIn Shockwave Flash beinhalten.
• Die neue Version der CyberGraphX V4 mit Rave3D.library wird bald veröffentlicht. Die erste Software, die Rave3D.lib benutzt, ist Tornado 2.1a. Mehr Infos finden Sie auf der Rave3D-Seite.
• Nicholai Benalal bietet Kaffe1.0b3.lha zum Download an, lesen Sie bitte auch diese Install-Hinweise.
• Amiga Flame Interview mit Sofia Tsiotsikas von ClickBoom.

           PPC-Lib    WarpOS

SViewII      Yes       (via ppc.library emulation)
akJFIF       Yes       Yes
akPNG        Yes       Yes
akTIFF       Yes       Yes

• Unoffizielle Napalm Support-Seite mit Web-Forum, Updates und Patches und Strategien.
• GoldED Studio 5 Update von 5.0.x nach 5.1.1. golded5.lha
• Genie 3.0 für DeliTracker Deli14BitGenie.lha mit Interpolation und DSP mit verschiedenen Effekten. Der Autor plant außerdem Real 3D Stereo Sound. Wenn Sie Vorschläge an den Autor haben, bitte eMail an platon@cu-muc.de.
• Operation: Counterstrike, es gibt neue Screenshots, Logos und andere kleinere Änderungen.

KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 6th February 1999

Number: 007

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 ben@kosh.net,
stating the Summary Number, and Mailing List Name, and he will try to answer your queries.

a)

Subject: Versioning

Summary of Debate: The author's name could be added to source code, with potentially lots of authors
                   marked against source code for an application/blueprint.


b)

Subject: HAVi

Summary of debate: Could KOSH incorporate the concept of HAVi - Home Audio Video interoperability, a
                   new plug and play standard for electronic appliances? The NG Amiga is going to use
                   this. The standard allows many ways to communicate with and control many
                   appliances, which is something that we have talked about in KOSH before.


c)

Subject: Wizards of OS

Summary of debate: http://www.heise.de/tp/english/inhalt/konf/3332/1.html is a site about a
                   conference called "Wizards of OS", dealing with the historic development of OSs


d)

Subject: Book list

Summary of debate: John Chandler has produced a preliminary list of books to be built on.
                   (Scribe's note: not repeated here as the email concerned was 11k in size, and I'm
                   trying to keep these summaries small. See email: Book List (draft), by John
                   Chandler <metaljoe@scnowcrash.u-net.com>, dated: 8th Feb)


e)

Subject: Task migration (continued)

Summary of debate: Peripheral sharing could be built into KOSH to allow any machine on a KOSH-network
                   to easily access any facilities on any of the other machines.


f)

Subject: Installation and application types

Summary of debate: The system could keep a central database of exactly what applications are
                   installed where.

                   If someone is viewing a picture it should go to a viewer. If it is being
                   edited it should go to a Paint program. The same is true of text that has
                   been created: HTML to either an editor or a browser as desired. As a result
                   perhaps a "finished" tag should be included in the information of a file so that
                   it goes to the correct application.

                   However a 'finished' flag may not be the answer as projects are rarely "finished"
                   and often need further editing. Perhaps left-click on a file to view it as though
                   it were finished and right-click to edit it.

                   It was then pointed out that clicking is only one example of control over files
                   as any control medium could be used (touchscreen, voice, on-button mouse +shift,
                   etc).

                   How about the Windows registry approach if better implemented? The registry would
                   have to be dynamic, intelligent and transparent.

                   Two older documents which are relevant are:
                   http://www.crusaders.no/members/donv/icoa/install-process.html
                   http://www.crusaders.no/Amiga/installer/

                   If a newly installed package requires a more up to date resource then that should
                   be located and handled by KOSH automatically - if this option is allowed by the
                   user.

                   Maybe every application could register all the data formats it can handle and
                   therefore if you access a file you could be presented with a choice of what to
                   load it into.


g)

Subject: Revenue from merchandising

Summary of debate: It was suggested that games for KOSH could be sold cheaply and the
                   majority of revenue made from merchandising around the game.


h)

Subject: Portfolio files

Summary of debate: A 'portfolio file' would be an attributes 'chunk' inside a package container
                   object. A central registry would then hold all references to applications.
                   Therefore when a package is moved elsewhere then the package manager is
                   automatically notified of changes. This information could then be used to keep a
                   track of what is where.


i)

Subject: KOSHan Web Sites

Summary of debate: A list of links from the KOSH url to KOSHan people's web sites could be added.


j)

Subject: ISO 9000
Summary of debate: Suggested that KOSH (presumably KOSHinc?) could get ISO9000 certification for
                   quality management standards if we follow the guidelines for such assessment.
                   But the future of ISO9000/9002 may be in doubt, and there may not be a clear
                   advantage for being so certified.


k)

Subject: Accessible programming

Summary of debate: If we made sure that KOSH came with a built-in not-too-complex programming
                   language that people could just dive into and learn to code with ease (such
                   as BBC Basic on the 8-bits). This could lead to a resurgence in the number of
                   "bedroom programmers" that once were commonplace and graced the world with their
                   existence.


l)

Subject: QNX literature

Summary of debate: Literature on QNX systems can be found at:
                   http://www.qnx.com/literature/index.html


m)

Subject: Macmillan Computer Publishing updated URL

Summary of debate: The new URL for the above is http://www.pbs.mcp.com


n)

Subject: Asian character sets

Summary of debate: G'o'tz Ohnesorge <gohnesorge@lh-computertechnik.de> would like help on how to
                   include support for Japanese and Chinese character sets as seen in website.


o)

Subject: Unhappiness with DVD URL

Summary of debate: URL for the above at: http://www.techweb.com


p)

Subject: Hosted-KOSH file export/import

Summary of debate: Hosted versions of KOSH should be able to import and export files transparently
                   with the hosted system and the applications there present.


q)

Subject: Linux on one 1.44mb floppy

Summary of debate: Apparently it can be done. Go to http://www.toms.net/rb/ to see how.


r)

Subject: ANDF

Summary of debate: It is suggested that for all machines out there to be potential KOSH boxes
                   with little barriers for entry, some form of ANDF is needed, but ANDF distribution
                   would require a separate code compilation on each platform. Perhaps therefore Slim
                   Binary distribution?


s)

Subject: Idle tasks (continued)

Summary of debate: Why not have a concept similar to WBStartup drawer on AmigaOS wherein programs in
                   the drawer do not run directly after a boot but when there is enough system idle
                   time?

• Neue Echtzeit-Effekte für die Prelude und die Prelude1200 in Vorbereitung.
• Neue Revision der Prelude 1200 benötigt die aktuelle prelude.library V4.2 [PrlLib420.lha]. Die Version ist abwärtskompatibel und kann auch mit älteren Revisionen oder mit der Prelude Z-II verwendet werden.
• Neue Version des AHI-Treibers V2.30 [PreludeAHI230.lha]
• Neue Version der Prelude Surround-Dekoders V1.2 [Surround12.lha] - benötigt die V4-library!

- STD-Crabs1-Install                    99-02-05
- STD-Vag1-Install                      99-02-08
- STD-Vag1-Trojan                       99-02-08
- STD-Vag2-Install                      99-02-09
- STD-Vag2-Trojan                       99-02-09
- STD-Vag3-Install                      99-02-10

Archive name.....: HF-CD417.LHA
Archive size.....: 306.382 bytes
Trojan File......: CygnusED/CED
Trojan Size......: 169.872 bytes
Virus infect.....: c/mount (new size 7388 bytes)
Virus size.......: 800 bytes

Archive name.....: mdlx09c.lha
Archive size.....: 882.398 bytes
Dropper File.....: MiamiDx_Install/MiamiDx.beta
Dropper Size.....: 439.724 bytes
Virus installed..: STD-Crap linkvirus