Re: [mingp@COREL.CA: How we can with your Setup Engine?]
Adam Di Carlo wrote:
> Excellent. If you don't mind, we should probably correspond by way of
> the <email@example.com> mailing list. I am on that list,
> also this way we can make sure that we don't lose a week because
> someone (me) somehow (?) lost an email. This way, I can be the main
> liase, but if for some reason I don't respond, someone else can pick
> it up.
Sure, we can start to subscribe to the debian-boot list server. Hopefully,
we can become more active very soon in the discussions. I am just waiting
for my team members to come back from vacation/for some new members to start
> Actually, we already have this, but rather than making it X based,
> we're using the FrameBuffer devices from the 2.2 kernels. This
> actually *can* fit on a 1440KB floppy.
We would like to break up the setup into engine components and UI components
and the two should be independent of each other as much as possible. This
way, people can use the power of the setup engine to create whatever UI they
prefer to drive the setup engine to suit their needs. In my mind, the FB
code is still very important for the 1st stage install before the VGA16 X
Server is installed and loaded for the 2nd stage, more user-friendly setup
> |> 3. Complete hardware
> |> detection (video, network, sound, SCSI, ... etc.). We will start
> |> off by supporting PCI devices and the few well known Plug&Play ISA
> |> devices only. More hardware detection will be added as time goes
> |> on.
> Now, we are talking about the ARM hardware right? Auto detection for
> x86 is desirable -- complete detection is not possible.
No. PC for now but we still will do something for the NetWinder as HCC's
NetWinder division is still our technology partner.
> I think, anyhow, that if we could formulate a simple system like the
> * insert a module
> * run a script which tests whether the module was "sucessful"
> (i.e., the blogic card modules when successfully installed will
> add new devices to /proc/BusLogic/<number>
> * based on that, either leave the module loaded and mark the module
> as to be loaded, or unload it
Sure. We can even narrow the search down in some cases by looking for
strings and some special signatures in memory. One of my new guys has quite
a bit of experience in this area. I guess I will have him to start studying
the current Debian install process to get a better understanding of
everything. We will then try to merge his knowledge, your team's knowledge,
and Gary's knowledge on the Red Hat install to create a really powerful
setup engine with as much hardware detection as possible. With the current
Debian 2.1 install, out of the 20 people who tried it here, only 3 was
successful in the past week.
> The other reason why an X11 dbootstrap would be hard is that we
> *assume* that the rescue disk and drivers disk are 1440KB. I think
> it's a problem that the system isn't more flexible about the rescue
> disk image size (i.e., possibly making CD or OS booting easier).
> Anyhow, I guess you guys are basically tossing floppy installation?
We still would like to support the floppy+CD combination installation
option. Our goals are to try to bring Linux forward to the mass users and to
create an easy-to-use, level playing platform so all competitions are done
in a fair manner (unlike MS today). I don't think a plain floppy
installation is that much suitable these days. (Remember, how painful it was
to install OS/2 with floppies?). Please see my previous points on FB too.
I think once we have a chance to study your setup source code, things will
become much clearer for us. We can then suggest to you which area we can
contribute to the most. We would still welcome a To-Do list from you so we
can pick out the things we are good at for the moment or try to hunt for
potential candidates who are good at those areas. Thanks.
org:Corel Corporation;Emerging Technologies
adr:;;1600 Carling Avenue;Ottawa;Ontario;K1Z-8R7;Canada