Hi, First excuse, I'm not a native and good English writer and speaker, and writing such long texts is something i normally do not day-by-day. Could we discuss about a suggestion: What if we drop the interactive procedure on installation process and offers only the automatic way, controlled by a plain text file? Huh? What he is talking about? =============================== AIF could use a control file in plain text to do the installation; also complex installations (ex: LVM and dmcrypt). For examples take a look at [1] and [2]. The install process then is running automatically without need of user invention. Installer paradigms ==================== Today installers (either if graphically or text based) are mostly interactive tools. They ask the user for information and the user is giving data to the installer. Also the user must make decisions in some steps, say Yes or No. Also in current AIF in interactive mode. Usual a installation is a top-down and sequent work-flow. But this don't prevent that user do "silly" things. So installers (also AIF) must do many things "behind the view" to intercept mistakes. Or need user invention/decision based on information from a procedure before current step... As a example the way grub install is handled by old arch-installer (AIF does this a little other): We have to ask about root/boot devices to generate a matching menu.lst file. This file is presented to the user again to have a look or change something. From the point that the user may have changed something some/most informations must be asked again (or be parsed from the changed menu.lst file). Main problem IMHO is: a today installer doesn't know at the beginning with what information it will conclude at the end. So each needed information for a step has to be asked/determined before this step. K.I.S.S me... ================= A today installer is hand-holding the user. It must be. From the user side the installer is the first tool he normally see from a distribution. How good he/she "feels" during this process, this often make a pro or contra later. The user - as a !Master! - means: I could work well with this installer, it does all what i want. First mistake! It's always the user that makes what the installer wants. That's the nature of this special piece oft software: It has a very restricted environment and its only goal is: install a working system. From a installer view the user is the obstructive part - only needed to give some information. To get those the installer feeds the user: give him nice varicoloured output, some play music or nice balls are wandering from the left to the right in progress bars... Meanwhile the installer must take care that the user make only one step left or one step right - but not two steps... In the "older days" installers - from users side - tend to be complex software; these days the trend is to keep the user off from the technical base behind the process of setup a base system. "5 clicks to get xyz ready to run..", "Full featured linux in 15 minutes - only 3 questions"... and so on. The result - we know this - are the full-bloated systems where in fact the distributions determine most of the users system. ... we are frogs! ================= During last images build and bugfixing i thought a lot about this. I know that our "old Devs" always prefer quickinst from old arch-installer package. Now coming familar with AIF, myself look most times and primary on the interactive part; but doing some work with automatic install scripts IMHO there is more potential than with quickinst. So my question: Am i totally wrong with my thoughts and - if not - have we the pluck to confront the user with... an text editor? Take a breath before hit Reply key... ;-) First: The above mentioned aif scripts are not the answer - syntax, presentation and documentation are more the "proof-concept" to look for answers. Pros & Contras ================== 1. Making the settings for installation in a control file gives not that pressure to the user what a User-Interface(UI) based installer has. Working with this file ("editing") does not any bad things. Look for ex. on the grub part currently in interactive AIF: The user is confronted in this step with questions in a very isolated manner. This step is very interdependent from the previous blockdevice setup - but these information's were entered before 10 minutes and out-of-users-sight in this step. In a editor all information is easy browseable and corrections could make at any point. IMHO a pro. 2. Install information could be saved at any time to external place by the user - or come complete from external medium. Currently our install procedure has to be restarted every time if the user got "stucked" in one step, or canceled the process, or when the installer has a bug. Most (and so in fact all) informations have to be re-entered... Think further about the capabilities: We (and the community) could offer templates for nearly each installation setup - without the need to bring this in a UI... If one has the idea to write a web-based interface to generate such installation control file - why not? IMHO a pro. 3. On the road to 2009.08 (and AIF) many of reported problems were UI related problems. Such things like "Cursor not automatically placed in Menu xyz". But also during the grub refactoring we have seen: to get feature or procedure X to work we must have here a new dialog, and there we have to change a other dialog... and so on. I guess on most interactive programs the UI-based part is the biggest part. And often the part with the most possible bugs. Current interactive AIF hast 2 UIs: the ncurses dialog based and a pure read/print based one. Ok, we will never ever have a graphical installer, but we hear often: why do you use such a "antique" UI? And in fact: Most today machines/environments could handle a graphically installer and also modern frameworks give even better widgets to interact with the user... But: Another UI gives potential more bugs and needs more manpower which could be better used to make the "base" more stable. If we use the control file based install we get rid off from such discussions of the "neatest" installer... And IMHO the step away from "how the others do it" could make us very modern... IMHO a pro. 4. Yes, i have a contra... Control files/variables tend to be not very self-explanation. For example take the current syntax for blockdevice setup: -------------- GRUB_DEVICE=/dev/sda PARTITIONS='/dev/sda 100:ext2:+ 512:swap *:ext4' BLOCKDATA='/dev/sda1 raw no_label ext2;yes;/boot;target;no_opts;no_label;no_params /dev/sda2 raw no_label swap;yes;no_mountpoint;target;no_opts;no_label;no_params /dev/sda3 raw no_label ext4;yes;/;target;no_opts;no_label;no_params' ------------- Here we have to invest a lot of work to bring such a syntax to the user in a better way. But on such complex steps i could imagine on "helper applications". Maybe a similar dialog-based we currently use in interactive AIF. But instead to "feed" a installer with this informations this helper produces for ex. the BLOCKDATA string for above control file. The user then import this generated piece into the editor. Similar helper could be one for timezone strings; all information a user normally not know by rote and so must be "picked" from a list. IMHO: if we make this good, the contra could went to a pro - cause at the end the user has still a (correctly) control file to start installation. Read until here....? ======================= Wow. Yes, I'm really thinking (and like to discuss) about a work-flow: a) User boots the image, login. b) Select/start a text editor with a base control file or select one of the other pre-defined control files. c) Edit his settings in this control file d) Uses the other tty's for getting infos, start helpers. Helper output he could load into the current control file editor. e) After "editing the setup" he could save it extern and come back later or f) start the installation. No interaction is needed after this (Ok, before fdisk'ing and formatting we should make a "break and review"). g) Base system is installed - user is happy... Cookies and taccos... What do you think? Of course, this is nothing for the next images... It's a massive U-turn against the main stream, but at the end IMHO the benefits could be great - KISS like... These are only my personal thoughts as a releng member, no position of "official politic". And now: Fire at will! ;-) Regards Gerhard [1] http://github.com/Dieterbe/aif/blob/2ef92eaa5f1106d8f1b379a8a94a477a0877bb1f... [2] http://github.com/Dieterbe/aif/blob/2ef92eaa5f1106d8f1b379a8a94a477a0877bb1f...