KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 13th March 1999

Number: 012

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: Alternative filesystem mechanics

Summary of debate: Part of the feature set for the filesystem "SFS" is that it
                   supports a "run-time defragmenter" that defragments the
                   drive when the user isn't accessing it. Still in development
                   but take a look at the following if interested:
                   http://www.xs4all.nl/~hjohn/SFS/features.htm

                   There is a similar tool under development for PFS2


b)

Subject: File locations

Summary of debate: If the end user wants to be able to keep their files in
                   locations not originally designed for, eg: applications in
                   the applications area then they should be able to do so.


c)

Subject: Sets

Summary of debate: A collection of files/objects could be termed a set. Sets
                   can contain subsets. Two sets can also contain common
                   objects without one being a subset of another. Folders and
                   drawers as terms lack this ability of multiplicity.

                   Soft sets would contain only references to objects. Hard
                   sets would contain the objects themselves.


d)

Subject: Moving around a GUI

Summary of debate: At the moment most GUI's are designed so that you move
                   around them vertically and then horizontally (or vice
                   versa). As a result moving windows, text, pictures etc. in a
                   fluid and accurate diagonal manner can be haphazard at best.
                   For example: resizing windows in 2 plains at once is OK, but
                   after that you are left with a vertical and a horizontal
                   scroll bar and nothing that combines both (except the new
                   track wheel mice - but these have their problems).

                   Therefore it would be nice if KOSH could have diagonal
                   movement built in as standard in an intuitive way.


e)

Subject: New keys on keyboards

Summary of debate: It would be nice if KOSHkeyboards had cut, copy and paste
                   keys in intuitive positions. However you should be able to
                   define your own clipboard keys so adding these three may not
                   be necessary. If we did add these keys they would need to be
                   placed in the main area of the keyboard and not off to one
                   side (eg: near the keypad) as accessing them becomes slower.

f)

Subject: Abstraction and Backing up data

Summary of debate: Scribe's note: this is a subject that I have summarised in
                   depth as it is central to a number of concerns that people
                   have expressed about the object sea.

                   KOSH will fully abstract physical and logical devices in a
                   comprehensive and easy-to-live-with manner. Therefore it
                   will be possible to locate all animations, text objects,
                   application objects, etc individually (eg: .jpg) or by
                   group (eg: all picture types etc) that are present on the
                   system irrespective of where they are located.

                   There is no relationship between the layout of the
                   filesystem as presented to the user and the physical
                   location of the files on a disk.

                   However there should still be a way to find all data
                   relating to a particular object or objects. This could be
                   one of the many entries in the object "database". Therefore
                   an option to display the system as per the conventional
                   currently used directory tree system should also be included
                   as this could be of use when wanting to do things like data
                   backups.

                   However the user should not need to see this. The backup
                   tool perhaps does but it can present the information to you
                   in whatever way you like.

                   Backup tools would probably take a frozen object and
                   compress it (if not already) and store it on the chosen
                   backup media, and note the pertinent information in some
                   index object it maintains of the backup.

                   Backup tools don't need to work directly with the storage
                   system on the drive, just with the objects themselves. It is
                   unlikely that people would often want to perform a
                   block-by-block backup of their files.

                   With an object sea, you throw your work into the sea. To
                   enable you to find it again, it has one or several strings
                   attached to it. When you need it you can just pull in the
                   right string until your creation comes up to the surface. A
                   natural worry that this creates is that the descriptive
                   strings could get broken and objects could therefore be
                   theoretically lost in the sea.

                   Therefore objects in the object sea will not float in an
                   arbitrary way. The objects will be ordered, even if they can
                   have links all over the place.

                   When sending an object to another KOSH machine the class
                   object and associated binding would be understood. however
                   when passing this same object (eg: a JPEG file) to a Linux
                   or Windows machine, they don't know KOSH object structures or
                   class bindings. Further, "JPEG" has a fairly precise
                   definition as a byte-stream. When sending this out to other
                   systems, just that JPEG stream would be wanted. Likewise
                   when importing: a JPEG (again as an example) from another
                   system should be inserted into a JPEG object.

                   Having the ability to add compression, cryptification or other
                   services to the objectsystem is a very good idea.

g)

Subject: Java Serialization

Summary of debate: See: http://www.javasoft.com - In Java there is something
                   called serialization which provides an easy way to implement
                   loads and saves of data in an ArrayList (from the Java API).
                   This could be the same with the Object Sea except that load
                   and save are replaced with freeze/unfreeze.


h)

Subject: Engineering Jobs at Amiga (in San Jose)

Summary of debate: See: http://www.amiga.de or the post forwarded to the ML by
                   Paul May dated 13/03/99, title as per the above subject
                   for information about positions with Amiga.


i)

Subject: Status of AROS

Summary of debate: Paul May has also forwarded a statement on AROS and where it
                   is currently at to the ML, dated 13/03/99, title: [TA] AROS
                   Statement (fwd).


j)

Subject: Icons (continued)

Summary of debate: Do we want fixed size icons which must occupy a specific
                   square or do we go for the Amiga approach which is more
                   flexible but potentially untidier and harder to handle?


k)

Subject: Force feedback input devices

Summary of debate: The idea to have force feedback devices such as a mouse was
                   suggested. This could (for example) let the user feel
                   scrollbars as channels, resizing windows as pulling elastic
                   and selecting icons becoming heavier the more you picked up.


l)

Subject: Mouse-Responsive Speech in a GUI

Summary of debate: As the mouse (or other control device) moves around the
                   desktop a voice could quietly tell the user the name
                   associated with each icon that is passed over, or some other
                   sound, word, or phrase specific to it. This then provides
                   aural confirmation of selection for those who may benefit
                   from such a feature. The same type of aural presentation
                   could equally as an option be implemented for menus and
                   controls within an application. The same applies to context
                   menus in web browsers.


m)

Subject: Heat dissipation in KOSHboxes (continuing "Waterproofing KOSH")

Summary of debate: Two links recommended regarding cooling chips are:
                   http://www.kryotech.com/ and
                   http://www.totalpc.net/hardware/renegade/
                   Kryotech manufactures cooling cases for PCs that use a
                   refrigerating base that runs through a heatsink that you can
                   then affix to your CPU in place of a standard heatsink.

                   The best solution to overheating would be to use low power
                   components and some sensible power management system that
                   can power down unused parts of the system.

                   As for radio interference as previously mentioned, the way
                   to solve this is with shielding which converts radiation
                   back into heat which can then be dissipated via some inbuilt
                   system.

                   The orientation of cards to allow for unfanned convective
                   currents to be optimised could be important. Orientating
                   cards on a vertical plane would not hinder heat
                   dissipation.

                   We must ensure that any KOSHbox that is produced can compete
                   in the general marketplace and therefore special cases and
                   heat dissipation units may increase the cost and reduce
                   sales potential when put next to an average PC. Therefore
                   apart from passive design points (eg: orientating cards
                   vertically) there may be little we can do initially to
                   improve designs.



n)

Subject: Virtual memory in newer NetBSD systems

Summary of debate: See: http://www.ccrc.wustl.edu/pub/chuck/tech/uvm/ for some
                   technical documents on the above.


o)

Subject: Compiling for the Object Sea

Summary of debate: How far would existing compilers need to be rewritten to
                   take account of the new object system when taking into
                   account the fact that programs tend to save data as
                   separate files?

                   A set of functions in the OO filesystem would allow existing
                   applications to be directed to use the new system and not
                   rely on traditional methods of saving. A method would be
                   needed to map the old style files onto the OO filespace.

                   It was stated that this would have nothing to do with
                   compilers as most languages have I/O as some kind of library
                   routine. Allowing for some functions being rewritten there
                   should be no problem.


p)

Subject: RAM disks

Summary of debate: Implementing a RAM: disk aka Amiga-style but designed to
                   work with virtual memory so that the data would be held on
                   disk but not placed in memory. This could be a better way to
                   handle things than temporary files in Windows.

                   Perhaps if everything is conceptually in RAM (including
                   contents of physical disks). Some systems use this and it
                   would building an OO system with persistent objects.

                   There could actually be a (small?) application which does
                   about the same thing as a RAM: disk.


q)

Subject: Task masking

Summary of debate: Could we set up a system where, via a quick option, certain
                   running tasks are suspended and hidden according to user
                   settings and (optionally) another one that's been frozen in
                   the background gets re-activated and set as the current
                   running application?

                   Hotkeys could accommodate this.


r)

Subject: Use of computers by those with disabilities

Summary of debate: See:
     http://www.newsunlimited.co.uk/The_Paper/Weekly/Story/0,3605,30692,00.html
                   which is relevant to the above subject particularly as KOSH
                   aims to enable accessibility for all.


s)

Subject: Speed and thousands of files

Summary of debate: In a traditional filesystem organising several thousand
                   files into several directories with several subdirectories
                   allows for a relatively fast search and locate for an
                   individual file. With the Object Sea references to objects
                   will similarly allow fast access - most likely faster
                   if a directory class optimised for large numbers of files
                   was created.


t)

Subject: Printing of objects

Summary of debate: Objects could be made to include the details to be able to
                   print themselves if text (or show themselves if pictures -
                   or both if either etc). This would remove concerns about
                   having the correct viewer/whatever to be able to use the
                   object. Could Amiga-style datatypes be used for this?


u)

Subject: Computer knit-wear

Summary of debate: See: http://wearables.stanford.edu/ for (what one scribe-e
                   describes as) a "combined pocket computer and hand warmer".


v)

Subject: Userinterface Working Group

Summary of debate: Timo Suoranta wants to work on user interfaces. For this he
                   would like a mailing list and a working group set up. Timo
                   details that this would be started by making one version of
                   the user interface with a limited C++ object model. Then when
                   the KOSH object model is available this can be rewritten or
                   translated. The first version would run on top of X.

                   Timo will look at some existing user interfaces which have
                   free source code and see if this can be utilised. See:
                   http://www.fsai.fh-trier.de/~schmitzj/Xclasses/ which could
                   be relevant.

                   It turns out that Xclasses had some building trouble, but
                   another promising toolkit could be: http://fltk.easysw.com
                   which Timo built on his NetBSD system.


w)

Subject: Disadvantages of the Windows interface (again)

Summary of debate: Greg says the URL quoted last time should have been:
                   http://www.iarchitect.com/msoft.htm - that little "l" makes
                   all the difference:)

Cyberstorm G3/G4 Zusatzinfos
Author: Wolf Dietrich
Date: 1999/03/21
Forum: de.comp.sys.amiga.misc

In den ersten zwei Tagen nach der Ankündigung unseres Cyberstorm
G3/G4-Projekts haben wir bereits eine recht positive Resonanz erhalten.
Allen denen, die bereits jetzt dieses Projekt durch ein Vorbestellung
unterstützen, möchte ich daher schon einmal herzlich danken. Da
allerdings auch einige Fragen gestellt wurden, und in ersten Kommentaren
in dieser Newsgroup einige Dinge gesagt wurde, die m.E. der Ergänzung
bedürfen, möchte ich diese hier kurz ansprechen.

1. Leistungsdaten
Das Cyberstorm G3/G4 ist eine reine PowerPC-Lösung, die als erste
PPC-Karte für Amiga keinen 68k-Prozessor benötigt. Sie wird mit
G3-Prozessoren mit mindestens 400MHz oder G4/Altivec-CPUs geliefert
werden (auf  Interposer ZIF- Prozessormodulen). Es wird immer mindestens
1 MB Cache vorhanden sein. Über das PCI-Interface lassen sich beliebige
PCI-Karten betreiben (wir werden uns über mechanischen Anforderungen mit
den Tower-Herstellern unterhalten); hier bietet sich für alle Entwickler
die Möglichkeit, Karten mit PCI-Chips zu bauen oder z.B. PC-Karten mit
Amiga-Treibern zu versehen und anzubieten. Erweiterungen von unserer
Seite sind derzeit nicht vorgesehen; wir werden aufgrund von Nachfragen
allerdings prüfen, ob wir einen Slot für vorhandene
CyberVisionPPC-Karten vorsehen kann.

Zusätzliche on-board Features sind auch nicht vorgesehen; ggfs. könnte
allerdings noch ein FireWire-IF integriert werden, das werden wir in den
nächsten Wochen prüfen. Theoretisch (und praktisch) könnten wir auch
zwei Prozessorsockel (und die dazugehörige MP-Logik) auf dem Board
unterbringen, allerdings wäre für MP-Betrieb die Softwareunterstützung
völlig offen; hier sind andere als wir gefragt...


2. Preis
Die Prozessormodule für Apple PowerMacs mit 400MHz/1MB Backside-Cache
kosten derzeit rund DM 1.700 inkl. MwSt. auf dem deutschen Markt. Wer
also zum aktuellen Vorbestellungspreis von DM 2.030,-- eine Cyberstorm
G3/G4 mit 400MHz G3 ordert, auf der genau ein solches G3 ZIF-Modul wie
in den PowerMacs eingesetzt wird, kauft, erhält das "Cyberstorm
Baseboard" mit dem A4000-Interface, dem SDRAM-Memory Controller bis zu
1GB, sowie dem PCI 2.1 Interface für DM 330,-- Mehrpreis. Dies ist wohl
alles andere als teuer.

Außerdem sollte man berücksichtigen, daß man ggfs. durch den Verkauf
einer vorhandenen Prozessorkarte die Kosten noch etwas reduzieren kann -
und wenn es nur ein paar hundert Mark sind. Bei einem anderen Ansatz ,
z.B. einer Z3-Karte, ist dies eher problematisch, da ein G3 im
Zorro-III-Slot weiterhin den 68k benötigt - zumindest als
Interrupt-Server (was eigentlich auch keinen "100% native PPC kernel"
erlauben dürfte).


3. Vorkasse
Wie (ab Montag abend auch in Deutsch) aus unserer Ankündigung
hervorgeht, verlangen wir - sobald nach Eingang von 1000 Bestellungen
das Projekt gestartet wird - eine Vorkasse von DM 250. Diese wird auf
ein notarielles Anderkonto geleistet, und uns nur dann zur Verfügung
gestellt, wenn wir  innerhalb einer festgelegten Frist die Boards an die
Kunden liefern (Einzelheiten hierzu werden den Vorbestellern zusammen
mit einer Proforma-Rechnung bei Projektstart zugehen). Erfüllen wir die
zugesagte Leistung nicht, erhalten die Kunden ihr Geld zurück. Bei einer
Storno seitens des Kunden besteht allerdings kein Erstattungsanspruch.

Da wir heute nicht einschätzen können, ob sich die sechsstelligen
Investitionen, die für Entwicklung, Prototypisierung, Test und
Produktionsstart notwendig sind, rechnen werden, sehen wir diesen
Mechanismus als einzig sinnvolle Möglichkeit an, das Projekt zu
realisieren. Wir denken, daß man dies als eine Art Partnerschaft
zwischen den Kunden, die Interesse am Erscheinen und Kauf dieses
Produkts haben, und uns, die wir das Produkt bei ausreichender und
gesicherter Nachfrage gerne realisieren möchten, sehen kann. Nebenbei
kann eine über diesen Vorbestellungs-Mechanismus abgesicherte
Entwicklung auch zeitlich gestrafft durchgeführt werden, da eine
gesonderte Finanzierung möglich ist.


4. Lohnt sich ein Upgrade überhaupt noch oder Warum baut man nicht
gleich einen neuen Rechner?

Dies muß natürlich jeder für sich selbst entscheiden. Wer z.B. sieht,
daß ein neuer 300 MHz PC im April 98 DM 2.800 kostet und das gleiche
Produkt im November des gleichen Jahres für DM 1.350 erhältlich ist, muß
sich die Frage stellen, ob er sich überhaupt einen Computer oder
irgendein Zubehör kaufen sollte...

Man muß daher wohl eher den Wert und Nutzen der Leistung, die man zu
einem bestimmten Zeitpunkt einkauft, absolut bewerten. Hier steht eine
400MHz G3-Karte (mit Speichererweiterung und PCI-Interface) für rund
2000 Mark sicherlich recht gut da. Da man über PCI beliebige aktuelle
Hardwareprodukte anschließen kann, wird für eine Erweiterung mit
günstigem Zubehör nur noch die Treiberentwicklung benötigt - und
zumindest für SCSI, Grafik und einiges andere besteht hierfür immer noch
ausreichend Entwicklerpotential. Daran, daß man als Gehäuse und für's
I/O noch die alte A4000-Hardware weiterverwendet (um's mal so überspitzt
zu sagen), gibt es ja eigentlich auch nichts einzuwenden. Wenn man dabei
Erweiterungen, die man schon hat, weiterbenutzen kann, umso besser.

Ein neuer Rechner für AmigaOS wäre natürlich noch besser, aber dies läßt
sich nur dann realisieren, wenn es dazu ein klares (unterstützendes)
Statement und entsprechende Aktivitäten von AI gibt. Die G3/G4
Generation wäre nach unserer Meinung weiterhin der sinnvolle Weg in die
Zukunft, auch mit neuen OS-Versionen. Aber leider beteiligen wir uns
derzeit nicht an Visionen, sondern bauen eben ganz bodenständig nur ein
Stück Hardware...


Wir werden in der Zukunft weitere Infos zu diesem Projekt
veröffentlichen, und auch auf typische Fragen eingehen. Ich bitte, von
Fragen direkt an mich per email abzusehen, ich werde sie (aus zeitlichen
Gründen) mit an Sicherheit grenzender Wahrscheinlichkeit nicht
beantworten können

Ich hoffe, daß wir dieses neue Projekt erfolgreich durchführen können,
und daß es weiterhin genug Unterstützung der Anwender für den Amiga
gibt, und auch das Interesse, mit diesem System ins neue Jahrtausend zu
gehen.

---------------------------------------------------------
Wolf Dietrich, GM phase 5 digital products
wd@gf.phase5.de   http://www.phase5.de


In the first two days after the announcement of our Cyberstorm G3/G4-Projekts we already
received a quite positive resonance. Those, which support this project already now by
vorbestellung, I would like to thank all already once cordially therefore. Since however also some
questions were asked, and in first comments into this newsgroup was said some things, which
require m.E. the supplement, would like I these briefly here to address.

1. Performance data the Cyberstorm G3/G4 is a pure power PC solution, which does not need
68k-Prozessor as the first PPC card for Amiga. It will be supplied with G3-Prozessoren with at
least 400MHz or G4/Altivec-CPUs (on Interposer ZIF processor modules). It will be available
always at least 1 MB Cache. Over the PCI INTERFACE any PCI cards can be operated (we will
us over mechanical request maintained with the Tower manufacturers); here is offered the
possibility, cards with for all developers PCI chip

Additional on board feature are not intended also; if necessary however still another FireWire IF
could be integrated, which we become in the next weeks to check. Theoretically (and practically)
we could accommodate also two processor bases (and the pertinent MP logic) on the board,
however the software support would be completely open for MP operation; here others than we in
demand are...

2. DM 1,700 cost price the processor modules for Apple PowerMacs with 400MHz/1MB Backside
Cache at present approximately inclusive MwSt. on the German market. Who thus at the current
priceprice price of DM 2,030, - - a Cyberstorm G3/G4 with 400MHz G3 orders, on which exactly
such G3 ZIF module is inserted as into the PowerMacs, buys, receives the " Cyberstorm cousin
board " with the A4000-Interface, the SDRAM MEMORY CONTROLLER up to 1GB, as well as the
PCI 2,1 INTERFACES for DM 330, - - additional price. This is probably everything else as
expensive.

Additionally one should consider that one can if necessary reduce the costs by the sales of an
available processor card still somewhat - and if there only a few hundred Marks is. With another
beginning, e.g. a Z3-Karte, this is rather problematic, since a G3 in the Zorro III Slot needs further
the 68k - at least as INTERRUPT server (which actually also no " 100% native PPC might permit
kernel ").

3. Vorkasse as (starting from Monday evening also into German) from our announcement follows,
requires we - as soon as after receipt by 1000 orders the project is started - a vorkasse of DM
250. This is carried out on a notarial Anderkonto one, and made available us only if we supply the
boards within a determined period to the customers (details for this will happen to the
Vorbestellern as well as a pro forma calculation with project start). If we do not fulfill the assured
performance, the customers receive their cash back. With cancellation on the part of the
customer however no claim to reimbursement exists.

Since we cannot estimate today whether the six-digit investments, which are necessary for
development, Prototypisierung, test and production start will count themselves, regard we this
mechanism as only meaningful possibility of implementing the project. We think that one can see
this as a type partnership between the customers, who have interest in the appearance and
purchase of this product and us, whom we would like to implement the product with sufficient and
secured demand gladly. Besides a development secured by this mechanism can be executed also
temporally tightened, since a separate financing is possible.

4. Is a Upgrade worthwhile itself at all still or why builds one not directly a new computer?
This must naturally decide everyone for itself. Who sees e.g. that new 300 mc/s PC in April it
costs 98 DM 2,800 and the same product in the November of the same yearly for DM 1,350 is
available, the question to place itself whether he should buy at all a computer or any
accessories...

One must evaluate therefore probably rather the value and use of the performance, which one
buys at a certain point in time, absolutely. Here is a 400MHz G3-Karte (with memory expansion
and PCI INTERFACE) for approximately 2000 Marks surely quite well there. Since one can attach
any current hardware products over PCI, for an extension with favorable accessories the driver
development is only needed - and at least for SCSI, diagram and some different one for this still
sufficiently developer potential exists. To the fact that one gives I/O still the old A4000-Hardware
as housing and fuer's re-used (um's exaggerates times in such a way to say), it also nothing to
actually object. If one can retain thereby extensions, which one has already, the better.

A new computer for Amiga OS would be naturally still better, but this can be implemented only if
there are in addition a clear (supporting) statement and appropriate activities of AI. The G3/G4
generation would be according to our opinion further the meaningful way into the future, also with
new OS versions. But we unfortunately take part at present not in visions, but build ourselves
evenly quite natively only one piece hardware...

We will publish further information in the future to this project, and will deal also with typical
questions. I please to refrain I her (for temporal reasons) also at security of bordering probability
to answer will not be able from questions directly to me by email

I hope that we can successfully execute this new project, and that there is further enough support
of the users for the Amiga, and also the interest to go with this system in the new millenium.

---------------------------------------------------------
Wolf Dietrich, GM phase 5 digital products
wd@gf.phase5.de   http://www.phase5.de