RE: Installer project

["yiyus" <jg_yiyus@jet.es>]

>I'm afraid I won't be terribly helpful here, because
>a) I'm doing way too many things this week
>b) I don't know anything about installers in the first place. :)

>In message <001c01bde32b$73db6960$bda237c3@ypc>, jg_yiyus@jet.es
writes:
>>Hi again,
>>I go on with my installer project, but there could be some changes,
I
>>would like to know your opinion first. These are the options I have,
I
>>would like to know which one you think is the best and if you know
>>about other one:
>>
>>1- Use libgwin (a libggi toolkit) to make a front end for an
existing
>>program (Debian, or RedHat) and run it on a ggi kernel. Good:
>>everything could be in a floppy disk and we would have a really nice
>>gui, I started to code this thing, so some work has alredy been
done.
>>Bad: GGI needs more development, at least two or three months for a
>>middle usable relase; no supported cards (they could use a patched
>>ncurses installer... ).
>
>Is GGI still regarded well by the rest of the graphics community? I
>remember there were some times in the past where people started to
>think maybe GGI wasn't worth continuing...
>

I am subscribed to the ML and things are going really well. Perhaps,
even GGI starts to be part of the oficial kernel in 2.2 (though
probably not). They have very good programmers, and lots of ideas, but
three problems: 1- they are always changing their APIs, so they can't
become a standar; 2- They need better advocacy, everybody think the
project is dead (they don't change their web page in months, for
example), but when I discovered it I thought it was a great project,
as it is; 3- Linus and kernel hq don't like very much to charge the
kernel with graphics, but things are being resolved now.

>>2- The gfdisk author think we could run X if we use a compressed
>>ext2fs (he found a tool to do it), so we would use Gtk to make the
>>program. Good: we can use lots of code; a nice gui; it should be
easy
>>to make a demo-distribution with our base; the user will install in
>>the GUI which he will use later if he use Gnome; we could obtain
help
>>from Gnome. Bad: I think it is really difficult; no supported cards;
>>it needs lots of MBs.
>
>This would be really neat. But I have no inkling of its technical
>feasibility; I haven't been following gnome/gtk, much less compressed
>ext2 issues. What do you mean 'no supported cards' if you're using X?
>Doesn't the vga or svga server support a lot of cards?
>

A lot, but not all them. This isn't a big problem, but I take it
seriously since I have a non suported card :-(

>>3- Patch a ncurses installer. Good: well, few things. Bad: it won't
be
>>very pretty.
>
>Pretty isn't everything. How flexible can you get, in terms of
supporting
>the widest variety of configurations? I suspect you can get
comparable
>flexibility with a choice that looks prettier though, it's true.
>
>>4- Write a libgwin based LinuxConf frontend and write the installer
as
>>LinuxConf modules. Good: we would have GGI, Gtk, Qt, ncurses and
even
>>http frontends, and the user would use the better he can; I suppose
>>LinuxConf people would help us with this; the modules could be run
>>later to configure the system; consistency; .... Bad: I don't like
the
>>atmosphere in LinuxConf, slow development, few people interested,
C++
>>(I don't know it very well, I would prefer C); very much work.
>>5- The same than up, but with COAS. Good: the same, though it
doesn't
>>have all that modules and frontends. Bad: close development; I don't
>>know how advanced it is and how it works.
>
>agreed that linuxconf and coas are kind of bloated these days. It
>may not be a good plan to base your installer off either of them.
>
>>6- Rewrite something similar to LinuxConf or COAS, but for us. Or
talk
>>to LinuxConf people to redirect it (more advocacy is needed). Good:
we
>>would have just what we need in a perfect way; a configurator tool
is
>>needed the same than an installer. Bad: lots of work and time, and
>>lots of help needed.
>
>Do you have any contacts in linuxconf? If not, that's probably not a
>feasible thing to do in the short or midterm.
>

No, I don't.

>Alternatively, nickm@seul.org is working on a configurator that will
>eventually be more flexible and better than linuxconf/coas. It will
>be a while until it's useful, though. But even so, I'm sure there are
>other groups out there saying "linuxconf is bloated and evil. let's
make
>a better one."
>

I would like to know more about these projects. Does anybody know
about them???

>How did configurators come into the picture? Why do you want to write
your
>installer as a configuration module for some other program?
>

The thing is that it could be done easier so. If I want a installer to
be used in any distribution it won't always do the same. If I use
modules, people will change some modules, will keep some of them as
they are, but it will require less work. And we would have two good
things :-)

>>As you can see, more I like the idea, more work it needs. I would
like
>>to hear your commentaries to start to work on this now I have time.
>>And don't think this is a dictatorial thing, we could start it in a
>>way (a temporary thing) and change it later. If I see this discuss
>>take too much time, I will try to improve  the RedHat installer to
>>have some ALPHA version. It won't be a good advance, but it would
help
>>us to look for help if we have some code.
>
>having code is often a good way to start, if you're trying to get
more
>programmers to join you.
>

If I don't find any useful code I will start to code the utility to
read modules. Something which reads a text file and make a GUI to
change configuration files, or something so.

>>Thanks for your interest,
>>- yiyus
>
>--Roger
>


- yiyus