pinit is a sysvinit alternative. It's a different way of booting linux. Keywords are: xml configuration, fast and parallel booting of services, modular design, dependecy based booting of services. It's intented to be more robust and faster than sysvinit. Please read the design document for more details.

A pinit system will boot faster than a script based sysvinit solution. On my system, for example, it will boot in about 1/3 of the time of a script based init. And shutdown is even faster. But speed was not the main concern for writing pinit. Rather fully featured, easy configuration, and a "clean" solution was more my concern. It was not intented to be "small". LibXML and Glib are used because they are fast and mature libraries. I can asure that I can write a single linked list myself. But Glib also has an implementation of a single linked list, so why not use that one ? Same goes for libxml: i know how to write a parser. But i don't want anyone to learn yet another syntax to use this program. And i don't want to write yet another parser for a config file. LibXML is fast and tested, so use it. If you want to make your system more lightweight: rewrite some utilities that use their own parsers, because it's redundancy (for most apps).


At this moment pinit is NOT ready for production use. Use only for testing. It can boot system, but it still has flaws. Don't run it on your server it might crash.



Why modules

A frequently asked question is: why use module, why not use scripts. I believe that scripts as they exist are very sensitive to faults the way they are used no in most linux distributions. For example: reading from proc which filesystems are mounted. This should not be done from a script. If the syntax of /proc/mounts is just a little bit different than expected. It will break.

What I rather would see is that someone write a generic interface to for all mounting needs. This can be done by extending the mount command. As a matter of fact, mount contains commmand to automaticly mount all filesystems from /etc/fstab. In my believe it is a better solution to fix mount, if it does not do what you want it to do, than to write ugly shell scripts to work around odd behaviour.

One can also expect a generic interface from a library (compiled elf-library). That is why modules are added. If for example a libnetwork would exist, one can easily write a module that reads an xml config file, and calls the routines in the libnetwork. It seems to me this is much less sensitive for error, than runnng some text file through awk en sed, and using it as a command line, and launching all kinds of processes all over the place.

Scripts can still be used through the program-service. This can even be used to convert your old script to this system. But I advise against it. One should rather think about a more maintainable solution, than just slapping some commands together, and just hope some syntax won't change. If a certain program needs alot of "magic" to get running, please consider fixing the program, instead of writting a "hack" to fix the problem.