On 06/03/10 01:32, Pat Villani wrote:
> What I have in mind is a design in which all questions are asked up
> front and responses are tested for validity, e.g., do you have enough
> disk space for all the selected software, do you have the right hardware
> for a selected option, etc., and then the install happens. In my
> previous experience, we had a GUI that wrote a file to a RAM disk, and
> then invoked a process we called playback to to the physical install.
> We also wrote this file out to the installed disk so that an installation
> could be easily cloned.
I am very keen on installers that allow human interaction to be all over and
done with
early on, and then you can leave the computer to get on with the copying and so
on.
I produced a system years ago that did a lot of this, including a system
replication
facility to format and install DOS plus other partitions (including PS/2, so
you can
guess how long ago it was!). I also am thinking of writing a new FDISK program
(some may
recall my Turbo Pascal FDISK from times long ago, that had quite a few command
line
options and disk tests, and a nice blue interface).
The situations I would like to see handled are:
1. simple diskette (or USB or CD or net-boot) of DOS that comes up quickly
with a menu
to allow the current system to be tested, a new system to be installed, or
the option
of dropping down to a command prompt.
2. A net-installer for PCs that have odd things happen to them (e.g. used for
testing
dubious hardware, checking for virus activity, used by students) so
everything that
was there can be wiped and the disk restored afresh quickly.
3. Easy installation of FreeDOS onto a virtual PC (especially for dosemu
within linux,
but as general as possible), so a user's partition is mapped and
everything is set up
idiot-proof and neat from the start.
4. Installation and replication of DOS (and other systems) quickly on a new
computer,
such as for vendors selling systems without Windows to install at least
something
that proves the computer works. Especially should consider the case of
selling
or installing reconditioned PCs where the previous owners' files are sure
to be
wiped and a simple working system and memory/disk/etc test programs are
installed.
DOS can still be a good first step in an install process (as an
alternative to grub,
for instance, yet with the ability to do lots of other things). System
cloning tools
need not care about what operating systems are being installed, and the
code has a
large overlap with what FDISK should do anyway, so I am keen to make an
FDISK with
replication abilities (that might make some of the FreeDOS install tasks
easier?).
> Additionally, we need to improve software packaging so that any
> dependencies are checked prior to attempting installs and packages have
> an opportunity to run run pre- and post-install processes or scripts.
> It should be a single file, ala rpm, although there are strong arguments
> as to why it should be something akin to the windows installer.
I like the idea of self-executable zip archives for distributing packages, and
some
standards for naming documentation (that might make OpenOffice interchange
easy) and
a policy of a compressed source tree archive within the archive, again: with a
standard
for naming files to avoid clashes when upgrading, avoid duplication, and make
it clear
to people looking at the files what they are. Ideally, there should be a
ready-to-use
executable in the distribution that will work on the lowest common denominator
computer,
plus it should be possible to take the source tree and produce a new executable
optimised
for the local hardware automatically by an installer program... which I really
would like
to see named "Packman" (for package manager). As with rpm and deb packages,
there
should be a searchable record of files involved with each package, packages
installed,
and packages available for installation. It should be possible to set policies
to only
ever use packages from selected sources (already on local disk, from CD/DVD, or
selected
websites), and another security-conscious requirement: to easily compare the
contents
of all files with the distribution package (or just a selected file on the PC)
and say
whether the file has not been changed/corrupted/infected/updated, or (for
config files)
what changes have been made.
Mark Aitchison,
Christchurch, New Zealand.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
