I recently had the opportunity to install Debian on my system. I had long heard about this distribution, but never had the chance to use and install it personally. My roommate Gad had
been plugging Debian for a year and so when the time came to install a new Linux distribution I gave Debian a shot. Eight hours later and two re-installs I had successfully installed Debian onto my machine. If it wasn't for apt-get though I would have another Red Hat machine and not Debian. The Debian installer was inconsistent and in a number of places needed drastic improvement. Over the next few weeks I began to think of how an installer works and how so many components are similar between distributions, which resulted in my hunt for the Linux Installer.
Research - What is really going on here...
There is much debate in the Linux world for what should be the correct application installer. Whether you prefer to have rpm's or debs or just tars I will not try to answer that question, but you don't hear much debate around the Linux OS installer. One of the things that you always hear from someone is that Linux is hard to install. It may because people generally need to dual boot, but work needs to be done on the system installers non-less.
I made a quick trip over to Red Hat and Mandrake's websites. Mandrake had some information on their installer, but it seemed to be for there installer only. I couldn't find any information on Red Hat's installer (or the website is just so confusing). Spending an hour I couldn't find an open source Linux OS installer project, anywhere. It seemed like every distribution was coming up with there own Linux installer, making it GPL and that is all. Maybe they copied parts from another installer, but I couldn't tell or find any docs to that.
Reasoning - Why we need a common Linux installer
When I use my Red Hat 6.2 boot floppy it can't see my cdrom, but Mandrake's boot floppy does. This is just one small bug of many that I have had over the years. The bug list for an installer should be as near to zero as it can reach. Especially for an operating system that is trying to sell itself to a new market. As more and more people try Linux for the first time they shouldn't be frustrated even before they get the OS installed. Why should there be twenty different Linux installers with their own quirks and bugs? If more people used one particular installer it would have many more eyes reviewing it. As the quote goes, with many eyes, all bugs are shallow.
I remember way back all the way to 1997 (seems like so long ago...) when I installed Red Hat 5.2. It was my very first Linux installation on my own. I spent quite a bit of time reading over every word and figuring out what it all meant before hitting the ok button. Over the past few years I have edged more to using Red Hat and Mandrake based distributions. I found the installers to be similar from one release to the next. Even when they added GUI installers I was able to figure it out with little trouble. I think of myself as a pretty good Linux developer. I thought I knew the system quite well that is until I installed Debian. The installer was so confusing that I felt like I was back with Red Hat 5.2 learning every little thing over again. The troubling thing was that it was doing the exact same thing that my other installer had been. Asking for my root password, repartioning the hard drive etc. For something that it so fundamental to Linux the installer should be more consistent across distributions.
But why stop there? Just about every installer has there own little "perk", but for the most part they all do the same thing. Set up some hard drive, copy files, and set up the base config. Why can't these things be the same from distribution to distribution? Why must developers reinvent it over and over?
In the dot com crazy I often thought about bisiness opportunities I could look into. One such crazy idea was to start a distribution. But if I wanted to create a good distribution I had to make a good installer to go with it. Everyone knows that this is not where the money is and creating an installer for Linux is not something that you want to spend resources on. If there was a common installer that was advertised as such I could simply pick it up, write the plugin for the "Speedy backup connection 2005" that I was bundling with my distribution and be good to go. I would get the consistency of a common installer, the stability of an installer used by many, and it would allow me to spend my resources on other better areas. But best of all, the users who used my distribution would not have to worry about learning the install process all over again.
Proposal - The Common Linux Installer
I propose that a Common Linux Installer Group (referred to as CLIG from now on) be created. It will consist of people who are working on Linux installers. It will not have a distribution itself, but be used in every distribution out there that wants to use it. This does not mean that a distribution has to use this, but the option will be there. I presume that there will be a sample "distribution" that will come with the package, but hardly what I would call a distribution.
Upon start of the install a data selection method will be chosen. This will be ftp, nfs, cdrom, floppy, hard drive or anything else that is wanted. The data retriever will be a separate library so that anyone can write a new library to allow the installer to use the new fangled file retriever. For example you could write a module that would use apt-get to get files for the install application if you so desired or pull the files off of a tape.
Each step in the install process would be a module. Each module will have three components. A text front-end and a graphical front-end and an action backend. The two front-ends would call upon the action backend to execute the requested action such as adding a newUser. This also allows for the installs that have a script that don't pull up the text or graphical, but simply the action with no user input. (i.e. plop in a disk for you install and come back 30 minutes later when it is done.) Internationalization will of course be tightly bound to this step so that the components can be used all over the world in different languages. Finally for the developer there will be a test function to simply simulate that action, but not to actually do it.
The final step is the install. This will also be a module. There can be an rpm installer, apt-get, tar source or anything that the distribution wishes to use. This component will be modular of course to allow for the latest and greatest packaging system to be used.
More important then anything else the installer will be clean. It will follow proper user interface design rules and not include pointless extra features such as themes or Tetris. Each page will be thought about and the interface will be consistent across the installer. There will be documentation and the entire project will be clean so that any distribution can grab the components they need and toss them together with minimal effort.
Conclusion - The Common Linux Installer Group.
The current state of Linux installers is not what it could be. There are many different variations and many different problems that they each have. A common Linux installer could be able to create a base for anyone that desired to use it. It would provide not only a standard install interface, but also one that is tested and working. Using a common installer the distributions could spend more time on the more important issues and not on such things as getting nfs working on and alpha boot dist. If someone wanted to make a distribution for their own personal setup they could do that with this package.
I am already involved with a part time project (Kaim), going to school, and working so I can not head up this project, but I wanted to get this off my chest for it has been going around me head for a long time. If some company is interested in sponsoring me to work on this project I might talk with them about it.
This document is just preliminary findings from the past few weeks. There may be a secrete developer group that shares all of the work already and I just totally missed it. Perhaps every installer is already modularized like this. But I don't think that is true. Even if the code was being shared in the background it wasn't showing up in the user interface, which is the only thing that the user sees.