by Bernardo Innocenti (email@example.com) - taken from Amiga Life
Translation by Joachim Thomas (firstname.lastname@example.org)
The first attempts in doing this missed the mark before even really starting. Amiga developers, certainly numerous, always totally lacked in coordination. The mailing list of the first projects, among them one called AOS, where only flooded by vain flame-wars about technical details like memory protection and symmetric multi-processing, without writing one line of code.
In the UNIX developers community it's practice to publish immediately program's sources, driving others to correct bugs or improving functionality. Using special tools it's possible to coordinate hundreds of freelance developers in very huge projects.
AROS uses a similar development system. Sources are mantained on a CVS server (Concurrent Version System) in the Internet. CVS keeps track of synchronisation in all developer's modifications and stores logs about authors and purposes of all changes.
Developers can update their source versions logging to the server and upload their own changes for all other developers. Discussions about new features are possible trought the aros-dev mailing-list before starting to work on them.
Every developer is free to offer his contribution in working on a part of the operating system. The job assignment is mantained by a special Job Server that keeps track of the progressions in all single jobs.
By now the only modules offering enough binary compatibility with OS3.1 are exec.strap, alert.hook, utility.library, keymap.library and commodities.library. All other libraries are still not usable on native Amiga, because the most developers are using the Linux flavour and are aimed in implementing lacking features of AmigaOS, letting the native environment testing and debugging phase as the last job to do.
AROS has been created to be easily ported to a variety of different environments and existing flavours are only a start. The only real limit in porting AROS to other sistems in native or emulated modes is given by the short number of developers doing the job. Some months ago on the mailing list there was a discussion about the porting to PowerPC.
Przemyslaw Szczygielski is working on an AROS version that will run in the same way on Linux APUS, Linux PPC and MkLinux. Claus Herrmann is working on a native Amiga PowerPC version. This is not the usual new PPC kernel, like Phase 5's and Haage & Partner's own: AROS will be a completely native PowerPC system on which old 68000 applications will not work without software emulation. An emulated flavour, like under UNIX, could be also done, running AROS for PowerPC on an own screen, with the original AmigaOS still running on 68000.
At the end of 1998, after endless technical discussions, the project restarted very quickly. A task-force built by Nils Henrik Lorentzen, Stefan Berger, Henning Kiel and Bernhard Fastenrath ported in a few months Intuition, Graphics and Layers to a maturity sufficient to go on with the whole project developing GadTools, Asl and Boopsi.
Johan Alfredsson, after the completion of commodities.library and datatypes.library, is now working on realtime.library and on the missing parts of console.device, allowing soon to open the shell within a CON: window, as on Amiga. As soon as Michael Schultz completes the needed drivers, it will be possible to create FastFileSystem partitions on PC HardDisks and boot the ibmpc-native version. In the meantime Branko Collins offered his help updating and correcting the documentation for AROS and reworking the website look, more accessible for non-developers starting in september.
While the single modules near completion, it will be possible to port on AROS existing software for Amiga. With the aim to not waste human resources, the AROS team decided, not to start in rewriting system utilities for which are already existent replacements in the public domain. Infatc there are plenty of software that, in the last years, replaced and improved the AmigaOS 3.1 equivalents. Workbench, for instance, could be replaced by Scalos or Directory Opus.
Every real Amiga user installed plenty of these programs together with many patches improving the system's look and functionality. The latter would be supefluous in AROS: having the source code of the entire operating system it would be far easier include this features directly into the system rather than using patches.
A driver for a new graphic board can be written in a few hours, implementing just the code that initializes the graphic frame buffer and a function allowing to draw single pixels. All other methods of the HIDD driver can be inherited from the generic ''graphic device'' class, which is able to emulate any drawing function calling only the WritePixel method. Obviously, later the driver can be optimized implementing directly other methods, using graphic acceleration. In this way in AROS the graphics.library is reduced to an high level interface accessing the underlying HIDDs.
By now a HIDD is available allowing to use an X11 window as an output device and others getting input from it through the mouse and the keyboard. The IBM-PC flavour has equivalent HIDDs accessing directly PC hardware. Nobody started writing HIDDs for Amiga hardware, but it should be easy.
It's possible, but not sure, that the distribution of an operating system, functionally the same as AmigaOS, would be an infringement of some patents registered by Commodore, now owned by Gateway 2000. In the eventuality of a legal action by Amiga Inc., the AROS team wouldn't have the economical power to manage his defense.
During the last two years Aaron Digulla and the other developers tried to contact Petro TyschTschenko, Jeff Schindler and Bill McEwen. The personal views of Amiga Inc's staff have always been positive, but by now there hasn't yet been a definitive official answer. Lacking a real legal information about the status of AROS, only the involved developers had access to the sources.
After this disclosure, it has been possible to start a discussion about releasing AROS to the public domain. The focal point of the discussion has been the distribution license. Although all developers agreed about a non commercial Open Source License, the discussion was about GPL or BSD Licensing. A lot of alternatives have been proposed, including writing a custom license. The final decision was MPL. MPL is very similar to GPL, but gives the team the possibility to offer the Source code to third party companies in form of other licensing types, allowing companies like Amiga Inc, Phase5 and Haage & Partner to use AROS as a part or as a whole for the development of commercial products, without the need to publish their sources.
Later, Aaron Digulla set a deadline for the first public release of AROS, asking all developers to send him all the work still to be released. The first Aminet upload has been in concomitance with the World Of Amiga. The distribution is divided in 4 archives for sources, documentation, executables for Amiga and executables for Linux.
By now AROS is surely the most mature AmigaOS rewriting project, and the day users will directly benefit is very near. The sources uploaded to th CVS server are by now more than 31MB and the 65% of all system functions have already been written. AROS involves nearly 90 developers and, thanks to the sprogressive system's trengthening, work is going on faster and faster.
In the future AROS' succes will depend in large way to Amiga developer's ability to conform their work to an Open Source OS model. Instead of wasting energies working individually at small programs, developers should contribute to the improvement of the whole system. By now there are lot of examples of successful projects to take as a model. It's enough mentioning Linux or FreeBSD to undestand that. also talking about software, union is strength.
For this article: email@example.com
General info: firstname.lastname@example.org