As said above, I think people from the different worlds (to name them: different Linux distributions, the BSDs (Free/Net/Open/...)) should work close together. I think we all have the more or less the same ideas, we want to create high quality, usable, free and open source software.

I think one possibilty to work together would be to write a modular installer, that is generated before you put it onto the installation media.

This way you can create a highly modular installer that is still small on the installation system.

I would recommened using a modular shell-script (using source to source functions and libraries) combined with a modular dialog variant (in my applications I use an ailas 'dialog" that either points to dialog or Xdialog, if DISPLAY is set). This way one has very less dependencies almost all Unices have a Posix compliant /bin/sh. Dialog also runs fine on serial lines, so the only situation dialog could be a problem would be when using non-redrawable screens (like terminals is connected to a printer).

After that I would begin to implement all parts of the installer for my system. That means I would create modules that are for instance SuSE-Linux specific, but also modules that work on any Unix. The important thing is that all modules work with a know interface, so one can plug in and use them.
It could look like this:

A sample prototype

• installer_greeting.sh
• choose_language.sh
• could be used by `uname -s` specific tools then
• Some people may say "But I want a region selector to be used there to select the default language"
• No problem, simply code it and let that tool call choose_language.sh
• select_destination.sh: Where to write data
• You could call create_slices.sh or create_partitions.sh before, depending on the OS you are installing.
• select_source.sh
• Where to install from:
• Network
• HTTP(S)/FTP(S)
• NFS
• Samba
• Local
• DVD / CDROM
• Harddisk
• Tape
• ...
• select_packages.sh
• What packages/ports/programs to install. May also be prefixed by a meta-package:
• "Install a desktop-PC"
• May be prefixed by detection of the computer
• Is it server hardware? Install remote access (sshd)?
• Is it a laptop? Include power management, pcmcia-support, other multimedia-support?
• May be prefixed by specific hardware detection
• Install video-player, if a dvb-t card is detected?
• DVD-recorder?
• Vendor specific laptop extensions?
• Non-standard hardware support (for drivers not in mainline kernels)
• ...
• install_now.sh
• Could just display all settings to be verified by the user
• Could lunch a game or a web-browers (if network is available)
• add_people.sh
• add groups and users
• also set the password of the superuser
• finish.sh
• Tell the user that the system is ready to be used
• Give her some hints to documentation or other ressources.
  

Interfaces

The really important point is to specify interfaces. Tell the world, what parameters your module expects and how it outputs information.
If you add features, create a new module that calls your first module.
Stick to the Unix-way of coding: Code small modules, that simply solve one problem.
Always write your module that it can be run without any specific order.

Communication

One of the easiest ways to communicate between programs are pipes. If your information is more complex, you could use cconfig and output the path of the cconfig-directory to standard-out (stdout). There are also many others ways, like sockets or very limited communication over exit-codes.

Cross developing

As this project is aimed to bundle the availbale FOSS-ressources do yourself a favour and use a decentralized version control system (dvcs) from the beginning. It does not care which one you use, as long as they are FOSS, so everybody can join you. Every developer has her own preference, but in todays times, where are more than twenty competing vcs out there, one is used to use also a different one.

What to do with this article?

If you are developing some kind of Unix think about this idea and think about implementing it. if you are wondering why your operating system of choice does not implement a modular installer, simply ask the responsable persons. If you would like to give some feedback either use the comment function or send an e-mail to nico-unix-installer <at> schottelius.org. Or just pass along this article, I would be very happy if someone would implement such a system.

Why don't you implement it?

To speak truth, there are parts of such a system on my harddisk. But as I am normally working my time for FOSS developing is very limited.
If you give me the time, I'll do it.