DragonFly BSD
DragonFly kernel List (threaded) for 2003-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: new sysinstall


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 31 Aug 2003 09:28:28 -0700 (PDT)

:
:With all the messages in this wandering thread, I've gotten lost.  Matt, 
:can you explain what you have in mind again, please?
:
:Richard Coleman
:richardcoleman@xxxxxxxxxxxxxx

    Summary so far of "How to rewrite sysinstall".

    * Make CDRom #1 a fully live image, allowing the system to boot into a
      complete environment.  Include various additional tools on the CDRom,
      including X.

    * Split a normal installation into two stages.  Stage 1 is responsible 
      for FDISK and basic partitioning (/, swap, and /usr), and simply copies
      the CDRom to the hard drive and reboots.  Stage 2 is responsible for
      the more sophisticated aspects of the installation.  Both stages
      will use the same scripts, languages, & utilities and such to do
      their work since both the CDRom boot and the HD boot will have a full
      environment to play in.

    * Choose a set of tools to build the installation GUI.  Desired features
      are to be able to run the installation from a character terminal, from
      a graphical environment, from a serial port, from a remote
      character terminal or graphical environment via the network, or
      totally automated.

    What I am currently proposing:

    * Place Apache, PHP4, lynx, and some sort of browser (if we can get it to
      fit) on the live CD.

    * Use Apache and PHP4 as the backend to the installer, lynx as the 
      character terminal frontend, or a browser as the graphical frontend.
      The installation code would be written primarily in PHP4.

    * The PHP4 code could make use of a simple database and the existing
      RCNG scripts to hold onto persistent data and execute its various
      functions.

    Problems with using high level languages like Ruby, Python, etc...

    * They have big library dependancy sets, which makes them somewhat fragile
      in regards to us being able to generate a release environment (everything
      is a moving target).

    * They have a big CD footprint.

    * There are issues with having multiple versions installed... a
      'system' version installed by the CD which is often older then
      the current release version that you might need in production.

						-Matt




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]