23.Feb.1999
Colin-Stewart Bridge Deady via KOSH-ML
|
KOSH Summary Nr. 8
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..."
(ps)
[Meldung: 23. Feb. 1999, 08:00] [Kommentare: 0]
[Per E-Mail versenden] [Druck-Version] [ASCII-Version]
|