[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Installer project
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>, firstname.lastname@example.org writes:
>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...
>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?
>3- Patch a ncurses installer. Good: well, few things. Bad: it won't be
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.
Alternatively, email@example.com 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."
How did configurators come into the picture? Why do you want to write your
installer as a configuration module for some other program?
>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.
>Thanks for your interest,