Summary: Getting more help
This is a summary of the "getting more help" discussion on the aros-dev
mailing list during January 2002. It covers some points and ideas of what
should be done next and how this should be done.
This summary contains comments from:
- People think that all areas are covered by someone.
- This gives them the impression that things are being handled fine and no
help is necessary.
- This is probably the reason why they do not offer their time for AROS.
- At the moment there isn't any information on the AROS website about what
YOU can do for AROS.
- List of free jobs is in CVS at docs/src/jobs.dat.
- Solution: create direct requests about things which could be
done for AROS and spread them.
I was just sitting at work today thinking about AROS and its current
Currently there are rather few active developers involved and I see people
wanting help with their part in AROS just about every time I visit #aros.
I came to wonder why there are so few helping out. In my opinion that's mainly
because most people that know of AROS thinks that things are going very
smoothly, with all areas covered by someone already involved and that things
are being handled just fine. At least that's the picture that most public
statements from us would (and do IMHO) give.
In such a light people might not think about offering their time. I
brought the matter up in #aros and people agreed with me, and we though that
something should be done. So my suggestion is that a more direct request for
help is made, describing in what areas we need help and what those areas are.
I would be happy to assemble such a request and then we (including myself :)
can post it on popular forums, like ann, comp.sys.amiga.*, moobunny, chech
Amiga News and whatnot.
I would basically write a message saying "Want to help? This is what we need:
1,2,3 and this is what would help is you were experienced in: a,b,c"
- In what areas is help needed?
- What experience might be needed?
- Description of what the different areas (meaning of areas).
To sum up, the request should include in what areas help is needed, what
experience might be needed and a description of what the different areas would
mean. Just stating "bus.hidd" would not interest anyone unless it is specified
what it means.
I made a quick list of the different areas that might come up. I don't have
the knowledge about what they would mean, or what experience would be needed,
but that's what I would want you guys on the list to help me with before I
send something out to the public.
I think it is important that such tasks (that we can get "outside" help with)
is quite small and independent. For instance, sending out a message asking for
- TCP/IP stack
- New workbench
Won't get anyone helping at all (my guess at least). These tasks are either
too big or you really need special expertise. Rather, I think it would be
better to focus on small things, although leaving in some bigger things
might be good as well. Examples:
- Preferences programs
- Icon.library enhancements
- BOOPSI itexticlass
Yes, its a good idea to start with smaller request. So the people could
estimate how much time they will need and the chance that they could finish
their work is bigger.
Its probably better to start with stuff known by Amiga developers than with
things which are special for AROS like the HIDD system.
If the first type of requests works (and AROS has better docs for building,
oop-lib, hidd, porting) then the requests could be become bigger and more
The message would go something like this:
"There's still a lot of work to do for AROS. So AROS can need your
[description of the AROS project and the goal]
At the moment you can i.e. write the missing preference applications:
These should be implemented using bgui and/or gadtools.library and
the iffparse.library in plain ANSI-C. All these libraries are working
on AROS. The development is done in ANSI-C (instead of C++)
to make it easier to port AROS to different systems (the AROS
project started 7 years ago).
So you need knowledge about the AmigaOS, the preference you want
to implement, the bgui- or gadtools- and iffparse-libraries and
about plain ANSI-C to write preference applications for AROS.
Some preference are implemented so you can use the existing sources
to start writing a missing prefs. You will also getting help from
the people of the aros-dev mailing list.
For developing it's recommended to use a Linux/x86 system. Because
AROS is portable its also possible to do development on ...
but at the moment the Linux branch is the easiest to handle.
You need on this system:
- GCC 2.9x+ (2.96 from Redhat does not work)
- make, autoconf, automake,...
In the FAQ on www.aros.org you can find a a bit of information about
the AROS project and the development for AROS.
Please write to ... if you are interested in doing some work
for AROS or if you have any questions and suggestions. You
could also join the aros user mailing list: see ...
[maybe its good to describe also the idea and the intention of this
Implementing missing library functions (see docs/src/jobs.dat)
HIDD's of different kinds, NET.HIDD, BUS.HIDD, PCI.HIDD, etc.
Specific drivers for gfx-cards, VESA support
translator.library (sources can be downloaded from Aminet)
A functional workbench
Coordinating GUI design for AROS programs, such as prefs program,
tools and utilities.
Text editors, vim, Emacs ..
Port of GCC and the whole development tool chain (gcc, make,
Improving the C link library (porting ixemul from geekgagdets.org)
Implementing missing ANSI (and some POSIX) functions in the clib, to make
it easier to port GNU software (e.g.. GCC, make and binutils).
The most biggest thing missing is support for POSIX style signalling,
but there probably are a lot of other functions missing as well.
Porting to more hardware platforms
A first step might be to make a hosted flavour for an OS on the intended
platform, of which some Unix flavor is probably easiest (since most Unix
code is the same for different operating systems).
Some ideas for possible ports which AFAIK haven't been started yet:
- Atari ;-)
- HP 300 series (m68k-based)
- SUN Sparc
Improving existing native ports
As always, more drivers. Just some examples that, AFAIK, nobody is working
- Input (touchscreen, buttons)
- Specific graphic card drivers (we only have general, not very well
accelerated ones). A short wishlist:
- nVidia TNT/TNT2/GeForce
- S3 Virge
- Matrox Millennium
- Specific IDE chipsets (e.g. Promise UltraATA)
- ...a lot more.
Problem MUI is closed source, commercial software
Convince Stefan Stuntz to release the source
Convince Stefan Stuntz to release a binary for AROS
Reimplement MUI starting with Zune (GPL-ed MUI clone for X11)