• Added sprite priorities (spr/spr and spr/bgr)
• Changed some things in the CPU-core (speed)
• Small fix to the triangle channel
• Added mapper#79 (Krazy Kreatures)
• Better support for the VS-system (still no dip-switches)
• Gzip support (need z.library)
• Fix to the Megadrive-pad reading

KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 6th March 1999

Number: 011

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: Virtual Memory

Summary of debate: For decent virtual memory support in KOSH processors will
                   probably need some form of Memory Management Unit. This
                   could cause problems if running KOSH on EC versions of 68k
                   chips. VM could still be implemented without an MMU but
                   would be unable to trap page faults which could cause
                   problems. Amiga programs such as Photogenics often have
                   their own VM implementation that may not require an MMU -
                   raw images are stored on disk and only the bits that are
                   being processed are loaded into physical memory.

                   A good scheduler could allow certain idle processes to be
                   swapped to disk until needed.

                   An alternative would be to run a machine directly from the
                   HDD but via a big memory cache so you would not have to wait
                   for it to catch up all of the time.


b)

Subject: Memory protection

Summary of debate: Memory protection is essential in full-blown KOSH - however
                   some hosted versions may not be able to support this.


c)

Subject: Database systems

Summary of debate: KOSH should feature a good base services for database
                   systems. This could include both RPG and OOP.


d)

Subject: Icons

Summary of debate: A number of people like the idea of having the icon
                   information for a particular file in a separate .info file
                   (aka Amiga-style) as previously mentioned. However when
                   copying or moving a file the appropriate icon file should
                   automatically be copied/moved as well (unless OFC the user
                   selects otherwise).

                   However it was suggested that to the end-user icons should
                   exist as a representation of the file and not be a separate
                   object themselves. It should still be easy to manipulate the
                   icons if the user desires to do so.

                   Perhaps animated or active icons could be used. When you
                   move the cursor over them the icon animates, or it plays a
                   tune or gives a brief snippet of its contents, etc. If you
                   don't like this feature you could just turn it off of limit
                   its effects (eg: audio limited to 5 seconds of play).

                   Icons could be set to "pointer mode". This would allow it to
                   be set up so that one user saw one set of icons but another
                   user could see a completely different set.

                   The image pointer for each file could instead of pointing to
                   an individual icon point instead to a big database which
                   contains all of the possible icons.


e)

Subject: Group locating objects

Summary of debate: Should we have all related objects in the same place, eg:
                   all applications in applications/ etc?



f)

Subject: Object Synchronisation

Summary of debate: By being able to synchronize two or more duplicates of the
                   same object at different locations this would allow
                   trans-internet games (and presumably any other type of
                   application) to handle everything in-system (not at a server)
                   and simply synchronize a world object between each player.


g)

Subject: Application-Objects as drawers

Summary of debate: If we setup application-objects to be a form of drawer,
                   executing it would run the application, but right-click (or
                   alternate key press) on the app-object would actually open
                   it up so that the component objects were visible.

                   On the subject of drawers how about defining a drawer as a
                   physical directory with a folder being a grouping of
                   files/documents (eg: files composing a project) treated as
                   one discrete entity? Or just stick with Objects and object
                   groups.



h)

Subject: Cloning output

Summary of debate: If a window's output could be shown on another user's
                   machine by using a form of object cloning there could be
                   immediate benefits for training and network management by
                   allowing you to use the tools of your choice on network
                   whiteboards.

                   QNX Photon GUI has a concept doing this.
                   The KOSH booklist (scribe's note: thanks again John and yes
                   you can have another free plug) at:
                   http://www.snowcrash.u-net.com/kosh/booklist.html contains
                   references to the QNX system book which covers the above.

                   Perhaps synchronisation (as mentioned above) would be more
                   use as this would allow constant communication from source
                   to destination as opposed to cloning which is more to do
                   with a one-shot duplication of an object, its state and
                   data.


i)

Subject: Settings Working Group

Summary of debate: Marcus Peterson has suggested that it may be time to form a
                   Settings WG to define such things as visual design,
                   functional design, bindings between objects, containers and
                   settings, and hot to deal with import/export and multi-user.


j)

Subject: Accessing the OS

Summary of debate: As individual people each have individual preferences as to
                   how to access and use the OS (eg: desktop workspace, file
                   manager, DOS, etc) we should have an object manager and an
                   application manager as a minimum. We could then begin to
                   allow for any desired way of accessing and controlling the
                   OS.


k)

Subject: Studying systems as a whole

Summary of debate: See: http://pespmc1.vub.ac.be/ASC/Cybernetics.html re
                   studying systems as a whole in relation to cybernetics.


l)

Subject: ANDF Url

Summary of debate: A company that makes ANDF stuff can be found at:
                   http://www.ddci.dk/news/brief_andf.html
                   and at:
                   http://www.npac.syr.edu/projects/hpsin/hpandf.html


m)

Subject: Supporting formats
Summary of debate: With an object based system supporting any particular type
                   of format (image, sound, text, etc) could be achieved by
                   coding the relevant object for it and inserting this into
                   the relevant part of the Object Sea.

                   The OS could provide a configuration utility for this that
                   allows programs and classes to only have a "form" for the
                   utility to fill out which could include things like image
                   and sound formats.


n)

Subject: Root object & filesystems

Summary of debate: A "root" object in the file system would be the thing that
                   exports methods for allocating and freeing data blocks and
                   perhaps dealing on a very basic level with navigation. A few
                   basic classes (such as "entity" (eg: a disk), "name", "date)
                   would be manipulated by the roots file system.

                   A "foreign" file system could be supported by creating a
                   filesystem object to represent and interact with it.

o)

Subject: Avatars and KOSH

Summary of debate: An Avatar/personality system was suggested and debated that
                   would represent the defaults setup in a system. A hierarchy
                   could serve well here.

                   A media preferences editor would set these things up as a
                   standard chart object. A program wishing to ask you would
                   query the object sea for a list of media types of the
                   specified class, but one wishing to simply write the default
                   would query the media defaults chart for this. Chart objects
                   are nothing more than a standardized way to create class
                   interections with caching (eg, you ask the chart for a
                   specific class pointer by token, not by fully specified path
                   name/URL).

p)

Subject: Novice users and system settings

Summary of debate: For the system to "know" you're a novice, would imply some
                   some intelligence in the recognition. This could break down.

                   Could a series of sets of settings starting at basic and
                   expanding up to advanced with progressively more detail where
                   you could explicitly request that the next time the settings
                   opens it does so at the level previously selected.

                   However KOSH needs to go beyond improving the range of
                   features or grouping them into fixed expertise levels to
                   allow a greater and more accurate degree of response to user
                   ability and desires.

                   The worst case would be what is generally apparent in systems
                   at the moment with every user being presented with the same
                   identical set of options to deal with, and the path that the
                   person must traverse to use these options is rigidly fixed at
                   the software factory

                   KOSH needs to be able to learn to present the user at the
                   very first request those options which the user is most
                   likely to need. This is really the only question the user
                   ever has. "How do I get the machine to do what I want it to
                   do?" A good set of defaults and thoughtful design is helpful,
                   but only as a starting point.

                   Directory requesters usually come up with the system default
                   path or an app-specific pre-configured path, but a few
                   programs are intelligent enough to remember what path the
                   user picked when performing a save (for example), and give
                   that as the first option the next time that function is
                   requested

                   We might want to consider an AI lister that, by use of some
                   artificial neural network for instance, tries to predict what
                   path the user's trying to reach. Eh, well, that would be nice
                   anyway.

                   Inherent within decent file requestors we should have an
                   intelligent form of word completion. As with all such things
                   it should aid usage of the computer and not hinder the user
                   by making unfounded assumptions.

                   User-defined menu structures are something else we should
                   implement.

                   The little personal AI that each Koshan will be growing,
                   training and nurturing (or leaving dormant) should be able to
                   recognise potentially interesting objects and organisms that
                   exist in the wider sea and bring them to the attention of
                   their owner.


q)

Subject: Standardised configuration

Summary of debate: The OS could provide a global configuration utility. With this
                   programs or classes shouldn't have to bother with their own
                   configuration, but just provide a "form" for a standard
                   configuration utility to fill out.


r)

Subject: More on KOSH helpers

Summary of debate: A KOSH helper will have to remember a number of things to be
                   successful in KOSH: Smart Dirs requestors, Version tracking,
                   smart menus, macro building and semi-automated software
                   updates,  Data-KnowledgeBase updates, an option to revert to
                   previous Configuration settings, tracking of software
                   failures and semi-auto bug reporting etc.

                   By standardizing formats (instead of the current system with
                   each application type having its own formats), the helper
                   could then use the prefs and habits of any application the
                   user uses to form its own particular knowledge-base.

                   Even without AI this sort of standardisation would simplify
                   user control over the whole range of options involved.

                   However helpers/AIs/etc have -always- in the past ended up
                   annoying people because they "learn" and make assumptions
                   about what we want to do.


s)

Subject: KOSH hotkeys

Summary of debate: When you have set a hotkey locally lots of times in different
                   applications there could be an option to make it apply
                   globally. At this point a settings editor could pop up and
                   ask you which applications should explicitly keep the chosen
                   hotkey and which should make it the same as the global one
                   which presumably would update automatically.


t)

Subject: Waterproof KOSH boxes

Summary of debate: Suggested that we make KOSH boxes waterproof to avoid damage
                   from spills of coffee that are unfortunately all too common.

                   However a waterproof box may have problems with a fan based
                   cooling system. Solutions could be to pass the internal air
                   current to the edge of the case away from the hot chips, or
                   better still make a fanless system that uses good case
                   design and materials to dissipate heat as it is generated.
                   This could be coupled with using chips that naturally do not
                   get too hot.

                   Heat dissipation to the case would have to be spread out
                   evenly and the temperature regulated to prevent the case
                   from becoming too hot.

                   Could Peltier elements be used to directly transfer heat
                   from one area to another with no moving parts? However they
                   use power and therefore generate heat themselves. An
                   alternative would be heat pipes. They are just a normal hose
                   with a cooling medium and fluff on the inside. It carries
                   heat better than for example a metal bar but can still be
                   bent and curved.

                   How would all this affect radio interference?


u)

Subject: 1999 USENIX Annual Technical Conference

Summary of debate: To be held on June 6th to 11th 1999 at Monterey Convention
                   Center & DoubleTree Hotel, Monterey California. Registration
                   by May 3rd. See the program at:
                   http://www.usenix.org/events/


v)

Subject: Paper on Task Migration

Summary of debate: Greg Webb and Clash Bowley (and possibly others by the time
                   you read this) have volunteered to produce the paper on Task
                   Migration that your humble scribe asked for.
                   (Scribe's note: Thankyou!!)


w)

Subject: disk space and scheduling

Summary of debate: With KOSH we presumably will release some form of disk
                   tools. With a defragmenter could a small area of disk space
                   be kept free so that scheduled tasks (eg: RC5 clients) could
                   run unimpeded. Could it be dynamic as the task was being
                   performed? Could the system tools pause such scheduled tasks
                   if needed and let them continue when possible?

                   With a filesystem that is well constructed to minimise the
                   need to defragment and have the ability to defragment
                   automatically as and when needed with little/no interrupts
                   (configurable by the user as usual) this problem would be
                   minimised.

                   In the object-based file system idea for KOSH, the
                   root object for any file system includes methods for
                   allocating and freeing blocks, which can be optimised
                   independently of the higher level file system objects. This
                   should make it fairly simple to incrementally de-frag.


x)

Subject: Accessing the system

Summary of debate: Rather than the standard downwards (or sideways) accessing
                   of menus we could use a pie system moving out from a central
                   point. As the pointer moves away from the center, the
                   "target" to select increases. In essence you are allowing
                   the user control over the size of the pop-up menu at each
                   instance.

                   Other alternatives could include using a hexagonal system
                   either emanating from a central point or providing a more
                   fluent way to pick sub-menus with more choice available at
                   each step. However this may not be easily accepted by people
                   who have been trained to expect 2D groupings in a
                   rectangular grid of some sort. Therefore for unfamiliar
                   users how intuitive would this system be?

                   A graffiti painting mode could provide an interesting option
                   for those that would like this. However painting can often
                   be frustrating to replicate with a mouse so this would have
                   to be kept simple.

                   If we implemented pressure sensitivity in the input device
                   we could perhaps remove the need for mouse buttons when
                   accessing the system in this GUI based manner (unless
                   someone preferred mouse buttons or keyboard shortcuts of
                   course).

                   A further suggestion is that the pointer could appear
                   somewhere other than at the top of a menu, perhaps
                   determined by the last or most frequent selection.


y)

Subject: Disadvantages of the Windows interface.

Summary of debate: See: http://www.iarchitect.com/msoft.html (NB: this was from
                   Greg's memory so it may not be quite this URL - ask him if
                   you get stuck) for a detailed analysis of the problems with
                   the Windows 95+ interface.

From:       "Allan Havemose" <havemose@ix.netcom.com>
Subject:    Engineering Jobs at Amiga (in San Jose)
Date:       13 Mar 1999 00:41:58 GMT
Newsgroups: comp.sys.amiga.misc

Below is our latest Engineering job openings in San Jose. If you're
interested and think you may be qualified, please follow the directions
at the end of the message.

Most of the formatting got lost when I pasted it into this news message.
Visit www.amiga.de, select the english language tab, and look for
engineering jobs on the left hand side. Should be easier to read this
way.

As you can see, we're redoing both our web sites. The job openings will
be on www.amiga.com as soon as we finish the work.

NOTE: We have a problem with our mail server. Do NOT send email to
hr@amiga.com for the next few days. Follow the directions as the end of
this message.

I'm looking forward to speaking to qualified candidates !

Allan

*****
ASCII version: Visit www.amiga.de for the HTML version
*****
Job Descriptions for Amiga Engineering in San Jose

General

Amiga is a highly entrepreneurial start-up company. We are headquartered
in San Diego and have our development group in San Jose. All of the
following openings are based in our San Jose offices. Our San Jose
offices are located on North First Street between Trimble and the
Airport.

At Amiga we are designing next generation Internet-ready,
consumer-oriented digital appliances. The Amiga name is associated the
world over with user-friendly, low cost, powerful computing. We are
taking this philosophy into the next generation, enabling products from
hand held Internet appliances to high-end graphics computers that help
the user rather than frustrate them. See www.amiga.com or www.amiga.de
for more details on Amiga, our history and the community.

The successful candidate will have a proven track record in the computer
industry. While each opening has special requirements the general
expectations are:
* Proven industry track record
* Demonstrable ability to deliver robust, top-quality software on time
* Committed to success and willing to "do what it takes" to deliver
industry leading product
* BS/MS/Ph.D. in computer science or electronic engineering
* Strong proven technical skills in C++

Job Descriptions

Principal Engineer/Manager Positions

User Interface Group:
* More than 10 years of commercial experience in generating compelling
user-interfaces
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with Client/Server graphical user interfaces
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Understanding of system architecture and design of operating systems
* Ability to lead, manage and mentor a group of software and
human-factors engineers


Networking and e-commerce Group:
* More than 10 years of commercial experience in networking, e-commerce
and transaction processing.
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with Client/Server transaction/e-commerce systems
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Understanding of system architecture and design of operating systems
* Ability to lead, manage and mentor a group of software engineers


 Sr. Software Engineer/Software Engineer Positions:

Graphics/Video/OpenGL/Audio/Gaming (multiple positions)
* More than 5 years of commercial experience in one or more of the
following
* 2D/3D graphics engines
* OpenGL application programming
* Applications using Digital video algorithms (MPEG, codec's)
* Applications using Digital audio algorithms (AC-3, positional audio,
mp3)
* Gaming technologies
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Experience with embedded programming.
* Ability to write specifications

User Interface (multiple positions)
* More than 5 years of commercial experience in one or more of the
following
* Consumer user interfaces
* Desktop user interfaces
* Use of multimedia (video, graphics, animation and audio) in user
interfaces
* Preferences and Configuration
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Experience with embedded programming.
* Ability to write specifications


Human Factors (multiple positions)
* More than 5 years of commercial experience in one or more of the
following
* Design of consumer user interfaces
* Design of desktop user interfaces
* Usability studies
* Proven creative background with a strong sense for good "user
experiences"
* Working knowledge of today's leading operating systems: Windows, Mac,
UNIX, QNX and AmigaOS
* Ability to clearly articulate user interface designs

Networking/e-commerce/transactions (multiple positions)
* More than 5 years of commercial experience in one or more of the
following
* Basic networking technologies (TCP/IP, SMTP, POP3 etc.)
* Browsers and their implementation
* E-commerce standards
* Encryption and Authentication
* Cable interfaces
* Billing & Logging
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Experience with embedded programming.
* Ability to write specifications

Build manager
* More than 3 years of experience managing the build process of a larger
software development group
* Revision control, release management, Documentation control
* Ability to write smaller tools and utilities to assist the development
process
* Good technical skills with an understanding of C++ and Java
technologies
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Ability to work well with engineering staff and management

Quality Assurance & Test
* More than 3 years of industry experience in the field of software test
and quality assurance:
* Write test-suites and run them
* Tenacity to identify and isolate bugs and inconsistent behavior
* Work as a member of a software development team.
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Experience with embedded programming.
* Ability to write test-plan


How to Apply

If you would like to apply for one of the openings please forward a copy
of your resume to one of the following addresses. Be sure to clearly
indicate the position you are applying for.

Email:
Email: andrew.mccartney@gateway.com
Make sure you to include the word Amiga in the subject line

Fax:
Fax:   (619) 799-3949
Attn: Andrew McCartney, Amiga Human Resources

Mail:
 4545 Towne Centre Crt
 San Diego, CA 92121
 Attn: Andrew McCartney, Amiga Human Resources



Amiga is an equal opportunity/affirmative action employer. Amiga does
not discriminate in employment on the basis of race, color, religion,
gender, national origin, age, disability, Vietnam Era veteran or special
disabled veteran status, sexual orientation, or any other protected
status as provided by law.





--
Allan Havemose, Ph.D.
Amiga Vice President, Engineering
email:havemose@amiga.com (W)
email:havemose@ix.netcom.com (H)

AMIGA-aktuell-Special +++ AMIGA-aktuell-Special +++ AMIGA-aktuell-Special

Neues von der Amiga 99 (13.03.99)
---------------------------------

Wie in AMIGA aktuell 3/99 berichtet, findet in diesen Tagen in den USA die
Messe Amiga 99 statt. An einer IRC-Konferenz, die kuerzlich abgehalten
wurde, nahmen auch Amiga-Praesident Jim Collas und der Leiter der
Amiga-Produktentwicklung Jeff Schindler teil. Nachfolgend die wichtigsten
Details zum Amiga der naechsten Generation, die genannt worden sind:

- Das erste AmigaNG-Produkt werde das Entwicklersystem sein.

- Amiga erwaege, fuer das Entwicklersystem optional eine Erweiterungskarte
anzubieten, die Multimedia-Features und -Leistung zur Verfuegung stellt,
die nicht jeder PC bieten koenne.

- Das zweite AmigaNG-Produkt werde ein Multimedia-Computer sein.

- Amiga will einen Computer zum Preis von etwa 500 US-Dollar mit der
Leistung eines 3000US-Dollar-PCs ermoeglichen.

- Amiga wolle selbst neue Hardware vorstellen, jedoch solle der AmigaNG
eine offene Architektur besitzen, so dass die Technologie in vielerlei
Produkten verwendbar sei.

- Letztendlich peile man eine Gesamtstueckzahl von 20-30 Millionen
Geraeten an.

- Das neue Amiga-Betriebssystem werde Multiprocessing unterstuetzen.

- Weitere Details zur Architektur sollen auf Entwicklerkonferenzen im
Sommer und Herbst bekanntgegeben werden. An anderer Stelle wurden die
Monate Juli/August (moeglicherweise frueher) genannt.

- Amiga verhandele mit verschiedenen grossen Softwareunternehmen ueber
AmigaNG-Unterstuetzung, von denen bislang keine ausdruecklich "nein"
gesagt habe.

- Der AmigaNG soll ueber das bestehende Haendlernetz verkauft werden.

- Amiga werde als weltweite Firma gefuehrt, der Schwerpunkt liege auf den
Laendern, in denen der Amiga am weitesten verbreitet ist, also
Deutschland,
UK und USA.

- Der erste grosse Auftritt von Amiga soll auf der Comdex im Herbst
stattfinden.

- Noch in diesem Jahr soll eine bedeutende Menge an Geld fuer
Marketingmassnahmen bereitgestellt werden.


In einer Rede gab Jim Collas weitere Details bekannt:

- Das neue Amiga-Betriebssystem werde den Namen "AmigaSoft" tragen. Die
erste Version, AmigaSoft 4.0 alpha (fuer Entwickler), werde im September
erscheinen, die endgueltige Version soll Ende des Jahres auf den Markt
kommen.

- Eine Betaversion von AmigaSoft 5.0 soll Ende des Jahres erscheinen, die
endgueltige Version soll im zweiten Quartal des Jahres 2000 fertig sein.

- AmigaSoft soll eine "revolutionaere" Software-Architektur und eine
vollstaendige Entwicklungsumgebung bereitstellen.

- Jim Collas versprach eine bessere Kommunikation zwischen Amiga und der
Amiga-Gemeinde.

- Amiga haette nun die volle Unterstuetzung durch den Mutterkonzern
Gateway.
How to Apply

Amiga sucht Entwickler (13.03.99)
---------------------------------

Parallel zur Amiga 99 startete Dr. Allan Havemose, der Leiter der
Amiga-Softwareentwicklung, eine Aktion, die die Einstellung von
Mitarbeitern zum Ziel hat:


»Below is our latest Engineering job openings in San Jose. If you're
interested and think you may be qualified, please follow the directions
at the end of the message.

Most of the formatting got lost when I pasted it into this news message.
Visit www.amiga.de, select the english language tab, and look for
engineering jobs on the left hand side. Should be easier to read this
way.

As you can see, we're redoing both our web sites. The job openings will
be on www.amiga.com as soon as we finish the work.

NOTE: We have a problem with our mail server. Do NOT send email to
hr@amiga.com for the next few days. Follow the directions as the end of
this message.

I'm looking forward to speaking to qualified candidates !

Allan

*****
ASCII version: Visit www.amiga.de for the HTML version
*****
Job Descriptions for Amiga Engineering in San Jose

General

Amiga is a highly entrepreneurial start-up company. We are headquartered
in San Diego and have our development group in San Jose. All of the
following openings are based in our San Jose offices. Our San Jose
offices are located on North First Street between Trimble and the
Airport.

At Amiga we are designing next generation Internet-ready,
consumer-oriented digital appliances. The Amiga name is associated the
world over with user-friendly, low cost, powerful computing. We are
taking this philosophy into the next generation, enabling products from
hand held Internet appliances to high-end graphics computers that help
the user rather than frustrate them. See www.amiga.com or www.amiga.de
for more details on Amiga, our history and the community.

The successful candidate will have a proven track record in the computer
industry. While each opening has special requirements the general
expectations are:
* Proven industry track record
* Demonstrable ability to deliver robust, top-quality software on time
* Committed to success and willing to  do what it takes  to deliver
industry leading product
* BS/MS/Ph.D. in computer science or electronic engineering
* Strong proven technical skills in C++

Job Descriptions

Principal Engineer/Manager Positions

User Interface Group:
* More than 10 years of commercial experience in generating compelling
user-interfaces
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with Client/Server graphical user interfaces
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Understanding of system architecture and design of operating systems
* Ability to lead, manage and mentor a group of software and
human-factors engineers


Networking and e-commerce Group:
* More than 10 years of commercial experience in networking, e-commerce
and transaction processing.
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with Client/Server transaction/e-commerce systems
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Understanding of system architecture and design of operating systems
* Ability to lead, manage and mentor a group of software engineers


 Sr. Software Engineer/Software Engineer Positions:

Graphics/Video/OpenGL/Audio/Gaming (multiple positions)
* More than 5 years of commercial experience in one or more of the
following
* 2D/3D graphics engines
* OpenGL application programming
* Applications using Digital video algorithms (MPEG, codec s)
* Applications using Digital audio algorithms (AC-3, positional audio,
mp3)
* Gaming technologies
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Experience with embedded programming.
* Ability to write specifications

User Interface (multiple positions)
* More than 5 years of commercial experience in one or more of the
following
* Consumer user interfaces
* Desktop user interfaces
* Use of multimedia (video, graphics, animation and audio) in user
interfaces
* Preferences and Configuration
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Experience with embedded programming.
* Ability to write specifications


Human Factors (multiple positions)
* More than 5 years of commercial experience in one or more of the
following
* Design of consumer user interfaces
* Design of desktop user interfaces
* Usability studies
* Proven creative background with a strong sense for good  user
experiences
* Working knowledge of today s leading operating systems: Windows, Mac,
UNIX, QNX and AmigaOS
* Ability to clearly articulate user interface designs

Networking/e-commerce/transactions (multiple positions)
* More than 5 years of commercial experience in one or more of the
following
* Basic networking technologies (TCP/IP, SMTP, POP3 etc.)
* Browsers and their implementation
* E-commerce standards
* Encryption and Authentication
* Cable interfaces
* Billing & Logging
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with real-time, multimedia operating systems
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Experience with embedded programming.
* Ability to write specifications




Build manager
* More than 3 years of experience managing the build process of a larger
software development group
* Revision control, release management, Documentation control
* Ability to write smaller tools and utilities to assist the development
process
* Good technical skills with an understanding of C++ and Java
technologies
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Ability to work well with engineering staff and management

Quality Assurance & Test
* More than 3 years of industry experience in the field of software test
and quality assurance:
* Write test-suites and run them
* Tenacity to identify and isolate bugs and inconsistent behavior
* Work as a member of a software development team.
* Strong technical skills with a good understanding of C++ and Java
technologies
* Experience with QNX, UNIX, Linux, WindowsNT, AmigaOS or similar modern
OS
* Experience with embedded programming.
* Ability to write test-plan




If you would like to apply for one of the openings please forward a copy
of your resume to one of the following addresses. Be sure to clearly
indicate the position you are applying for.

Email:
Email: andrew.mccartney@gateway.com
Make sure you to include the word Amiga in the subject line

Fax:
Fax:   (619) 799-3949
Attn: Andrew McCartney, Amiga Human Resources

Mail:
 4545 Towne Centre Crt
 San Diego, CA 92121
 Attn: Andrew McCartney, Amiga Human Resources



Amiga is an equal opportunity/affirmative action employer. Amiga does
not discriminate in employment on the basis of race, color, religion,
gender, national origin, age, disability, Vietnam Era veteran or special
disabled veteran status, sexual orientation, or any other protected
status as provided by law.


--
Allan Havemose, Ph.D.
Amiga Vice President, Engineering
email:havemose@amiga.com (W)
email:havemose@ix.netcom.com (H)«


--

Und noch zwei Kurzmeldungen:

* Bei dem Programm 'Daytona', das Nordic Global fuer den Sommer
angekuendigt hat, handelt es sich um eine Java Virtual Machine.

* YAM ist in der Version 2.0 Preview 7 erschienen und kann auf
http://www.yam.ch heruntergeladen werden.

--

E-Mail-Abos von AMIGA aktuell koennen unter Angabe der gewuenschten
Version (1. AMIGAGuide oder HTML; 2. mit oder ohne Grafiken) kostenlos auf
den WWW-Sites http://www.mediaspace.net/amigaaktuell und
http://www.vmc.de/aakt bzw. per E-Mail (aakt@gmx.de) eingerichtet werden.

© 1999 Carsten Schroeder - Der Inhalt dieser Mail darf nur vollstaendig
und ohne Aenderungen weiterverbreitet werden.

AMIGA-aktuell-Special +++ AMIGA-aktuell-Special +++ AMIGA-aktuell-Special

• "Drucker nicht bereit" Fehlermeldungen kommen zu früh
• Grafikpublisher: Inverser Text wird am Bildschirm falsch dargestellt

• HP DeskJet 8xx druckt Text bei FinalWriter oder Wordworth manchmal mit zuviel Farbe
• Canon BJ Treiber kann mit Fehler 80000005 abstürzen

• Epson Stylus Color 300 druckt im Farbmodus die Farben versetzt
• Bei Hardcopies von 16/24-Bit Bildschirmen wird schwarz durch weiß ersetzt
• Die druckerspezifischen Einstellungen werden zwar verwendet, aber nicht abgespeichert
• Epson StylusColor 600 und StylusPhoto 700 drucken im 1440dpi-Modus zu hell

Name : xvs.library v33.18
Archivname : xvs33_18.lha
Archivgröße : 49.953 bytes
Datum: 8 März 1999
Programmierer : Georg Hoermann
System : OS 2,0 oder höher
Nutzbar mit: VirusZ II & III, VirusChecker II,
     VirusExecutor, VirusSlayer, Fungiside.

Neu in v33.18:
 - Fixed bug in recognition code for Elbereth 1 - 4
   and Disnomia linkviruses. Some copies have not been
   detected correctly. Thanks to Dran/Chew-Z for the
   report and the testfiles.
 - Added additional verification code for  pseudo-
   executables like 'Scalos.key' starting with $3f3
   even if they are datafiles. Thanks to Ramon for
   the report.

• Virtual Grand Prix Demo Update
• Islona Secure hat Rechte zur Neuauflage von SuperFrog von TEAM17!

• Info: Softwareentwicklung kostet Zeit und damit auch leider einiges an Geld.
• Neue Software zu entwicklen und aktuelle Software zu verbessern setzt voraus,
• daß diese Software auch gekauft wird - dies gilt besonders für den Amiga.
• Es macht einfach keinen Sinn, viel Zeit und Geld in ein Produkt zu investieren,
• das wenig gekauft wird und auf irgendwelchen Servern zum Downloaden existiert.
• Wer Camouflage kauft, investiert auch gleichzeitig in die Weiterentwicklung.
• Das gilt natürlich auch für alle anderen Amiga-Softwareprodukte.
• Wer also Raubkopien benutzt, muß sich im Klaren sein, dass er damit Neu/Weiterentwicklungen verhindert (hat)...

02445/911571 - Analog
02445/911368 - ISDN
02445/911285 - Hotline
02445/911568 - FAX
0173/3078687 - Handy

• Mit GrafikpublisherBE und allen aktuellen Druckertreibern! Kompatibel zur gesamten Amiga-Software.
• Funktionsumfang wie Professional-Version, jedoch ohne Postscript, Turbospool und Grafik-Textmodus. GrafikpublisherBE ohne Textmodus, Zoomfunktion und Photo-Optimizer.
• Mit Upgrademöglichkeit auf Professional-Version
• Ausführliches deutsches Handbuch
• Nur DM 69,- (unverbindliche Preisempfehlung)

• "die Architektur und das Betriebsumfeld des neuen Amigas" wird Mitte November dieses Jahres vorgestellt;
• Erste Details werden in St. Louis, USA, am 12.-14. März vorgestellt;
• Bestätigung das die Realisierung von OS 3.5 "gemeinsam mit Haage & Partner" durchgeführt wird, und man hofft, "die ersten Betriebssystem-Pakete 3.5 im Sommer dieses Jahres ausliefern zu können".

• The Ripper 5 Ausgabe 5 des Diskettenmags von Raising Hell Productions
• Neue Version 3.7 des Treibers für den FAST ATA2-Kontroller von Elbox. Geändert wurde die Prozedur der Erkennung von Festplatten über 9 GB und hinzugefügt wurde eine schnelle Erkennung von schreibgeschützten LS-120 Disks.
• GoldED Studio 5 Update, registrierte User können sich das Update vom 5.0.x auf 5.1.2 hier downloaden.
• Alle Spieler mit ClickBooms BOOM-Nummer können die T-zer0 "Beta"-Seite im ClickBoom-Portal testen.

• Vorstellung strategischer Partner diesen Sommer
• NG-Amigas innerhalb dieses Jahres
• System für dieses Jahr: Development-System, ein Internet-System, und ein low-cost Home-Computer "in der Tradition des A500"
• PC-Level und High-End Workstations gehören auch zum Amiga-Plan, ebenso "Hand-Held Internet devices" - also ein Handy zum surfen.

TYPE (MIME TYPE): APPLICATION / X-SHOCKWAVE-FLASH
EXTENSION: SWF
ACTION: External Program
(VIEWER) NAME: SYS:C/swfplayer
ARGUMENTS: %f >NIL:

• Grafische Benutzerschnittstelle
• Kommt ohne MUI aus
• Bequeme Auswahl der seriellen Schnittstelle
• Gestattet die Programmierung von MSN-Liste, MSN-Zuweisungen, ISDN-Merkmale, interne Umleitungen, Kurzwahlnummern und Providerpräfix
• Kann alle fünf Gebührenzähler auslesen und einzeln löschen
• getrennte Vorgaben von Gebühren-Faktor und Währung (also für den Euro gerüstet :) )
• Provider-Liste mit Netzkennzahlen inklusive
• Ordnet Kurzwahlnummern auch Namen zu

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

Achtung - 19. Februar '99 - Kündigung - Achtung

 Verbraucherschutzverein verhindert 77 Mark-Pauschaltarif!

 MobilCom bietet ab sofort Internet FlatRate 6 Pf./Min rund um  die
 Uhr.

 Leider   müssen   wir   Ihnen   heute   mitteilen,   daß  wir  den
 Tomorrow-Tarif  nicht   länger   anbieten   dürfen.   Mit   dieser
 Veröffentlichung  kündigt die MobilCom Communications-dienste GmbH
 fristlos     den     mit     Ihnen     geschlossenen     Tomorrow-
 Tarif-Nutzungsvertrag   aus   wichtigem  Grund.  Entgegen  unserer
 eigenen  Überlegung,  das  Internet  in  Deutschland  billiger  zu
 machen, zwingt uns ein Angriff des Verbraucherschutz- vereins e.V.
 Berlin vom 2. Februar '99 dazu, die FlatRate vom Netz  zu  nehmen.
 In  dem  Schreiben  des  Verbraucherschutzverein  e.V.  Berlin vom
 9.Februar '99 wird der MobilCom GmbH vorgeworfen,  daß  einige  im
 Tomorrow-Tarif   gegenüber   dem   Kunden   genutzten  Allgemeinen
 Geschäftsbedingungen (AGB) gegen das geltende AGB-Gesetz verstoßen
 und  damit  wettbewerbswidrig sind. Bei der intensiven Prüfung der
 gerügten AGB's hat sich ergeben, daß die MobilCom GmbH nahezu alle
 Beanstandungen ausräumen könnte. Dies ist aber bei der nachfolgend
 genannten Geschäftsbedingung nicht möglich: In dem Schreiben heißt
 es: "Für diesen angebotenen Dienst steht nur eine begrenzte Anzahl
 von Zugängen zur Verfügung. Aus diesem Grund kann  die  permanente
 Einwahl  nicht  gewährleistet  werden."  Es  ist  uns aufgrund der
 gewaltigen Resonanz auf das Tomorrow-Tarif-Angebot nicht  möglich,
 jedem  einzelnen Interessenten jederzeit einen eigenen Einwahlport
 zur Verfügung zu stellen und  nur  dies  würde  einen  permanenten
 Zugang  ins  Netz  gewährleisten.  Da  eine  Weiterverwendung  der
 bestehenden AGB's  mit  einer  hohen  Vertragsstrafe  seitens  des
 Verbraucherschutzvereins   geahndet  werden  wird,  hat  sich  die
 MobilCom    Communicationsdienste    GmbH    entschlossen,     die
 Unterlassungs-  erklärung  zu  unterzeichnen  und  damit  auch den
 Tomorrow-Tarif mitsofortiger  Wirkung  vom  Netz  zu  nehmen.  Die
 Unterzeichnung     der     Unterlassungserklärung    hat    leider
 konsequenterweise  die   fristlose   Kündigung   des   mit   Ihnen
 geschlossenen Tomorrow-Tarif-Nutzungsvertrages zur Folge.

 Achtung:  Keinem  für  den  Tomorrow-Tarif freigeschalteten Nutzer
 wird die 77 Mark Pauschale berechnet. Sollte dies  jedoch  bereits
 geschehen  sein, wird der Betrag mit einer der nächsten Rechnungen
 gutgeschrieben. Für 6 Pfennig pro Minute  rund  um  die  Uhr  über
 01019 01929 im Internet surfen !!

 Unabhängig von dieser Entscheidung hält MobilCom an dem Plan fest,
 das  Internet  billiger  zu  machen.   Ab   sofort   können   alle
 Internet-Nutzer  im Internet by Call -Verfahren über 01019 FREENET
 für nur 6 Pfennig pro Minute rund um die Uhr im  Internet  surfen.
 "Mit  der  Tomorrow-Tarif  FlatRate haben wir Neuland betreten und
 aus Gründen, die in  keiner  Weise  vorhersehbar  waren,  negative
 Erfahrungen    sammeln    müssen",    sagt    Gerhard   Schmid   -
 Vorstandsvorsitzender der MobilCom AG, "mit unserem neuen  Angebot
 an  die  Internet-  Community bringen wir zwar kein Äquivalent auf
 den Markt, aber ermöglichen den Internet-Zugang zu einem ungeheuer
 günstigen Preis."

• 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.

Marc Albrecht
-----------------------------------------------------
//Hard- and Software Developer  //  A.C.T. Germany //
-----------------------------------------------------

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!