From: "Derek J. Belrose" <derek@omegabyte.com>
To: Jeff Rose <rosejn@Colorado.EDU>
Cc: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] GUI installer
Date: Sun, 13 Apr 2003 05:14:40 -0400 [thread overview]
Message-ID: <3E992A80.60508@omegabyte.com> (raw)
In-Reply-To: <Pine.GSO.4.40.0304130220080.7841-100000@ucsub.colorado.edu>
I think we should take a look at RedHat's installer to see what goes on
underneath. For what I have used, it's hardware detection worked
perfectly...i believe it's kudzu that drives it.
In my opinion, the installer should just do a stage install, and
everything that the install doc describes...then on reboot maybe dump to
X or a ncurses interface giving the user options on what to do next. I
like how Debian does it, basic install, then allow dpkg to be configured.
Opinions?
Jeff Rose wrote:
>Well, I'm glad to see that people are interested. After doing some
>initial research I have some thoughts. First, we should decide on whether
>we want to have a terminal or X based installer. Does anyone know how
>well the generic vesa driver works for X? I personally have battled with
>X so many times that I'm not sure I think its worth it for an installer.
>(Although we could just use the RedHat stuff for autodetection etc. if we
>want to go that direction.) Besides X we could use ncurses dialog
>widgets or another terminal gui package. I was thinking it would be cool
>to use somethine lighter than X like svgalib. I have no experience with
>it and don't know how cross platform (or cross video card) it is, but it
>could be a cool solution if a decent widget set is put on top of it. I'm
>not sure if this would lead to more or less work than using X.
> As for choosing stages, that should be a decision made by the user
>at install time. We can very briefly explain how the system works and let
>them do what they please. For the complete novice we can basically have
>the "do everything for me" button. For the supreme hacker we can let them
>have it all while still taking care of mundane details. (For example,
>they could choose what file systems they want to use on what partitions,
>but that would just be a selection dialog rather than having to type the
>commands etc...) It might be nice if the installer can be exited at any
>point so people have the ability to get things rolling quickly but then
>tweak things out to their hearts content once its where they want it.
> One of the major pains in the redhat like installers deals with
>package selection. I think it is ridiculous to give people a list of a
>thousand packages and tell them to pick. Especially since the package
>documentation is horrible. Most people probably wouldn't know that its
>important for them to have the e2fsprogs installed, for example. So, this
>is the portion of the installer where I see the most room for innovation.
>Especially since gentoo has such a unique package system, we should really
>try to enable the user as much as possible, rather than just hucking a
>bunch of packages into the mix. I'm still working on ideas, but we should
>experiment with all kinds of stuff to get this stage really smoothed out.
> This idea of processor detection makes me think that a whole lot
>of detection could go on if we wanted it to. The thing is detection is
>useless unless you can act on what you have detected. Changing some CPU
>related compiler flags is one thing, but what about detecting network,
>sound, video, raid, scsi, firewire, printers etc. This could all get very
>tricky real fast. What about using RedHats kudzu?
>
>Peace,
>Jeff
>
>
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-04-13 9:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-11 23:04 [gentoo-dev] GUI installer Jeff Rose
2003-04-11 23:25 ` Riyad Kalla
2003-04-12 0:05 ` Alec Berryman
2003-04-12 2:19 ` Brian Harring
2003-04-12 3:52 ` George Shapovalov
2003-04-13 5:05 ` Justin Whitney
2003-04-13 5:38 ` Derek J. Belrose
2003-04-13 6:50 ` Cliff Free
2003-04-13 7:08 ` Derek J. Belrose
2003-04-13 8:49 ` Jeff Rose
2003-04-13 9:14 ` Derek J. Belrose [this message]
2003-04-13 9:23 ` Cedric Veilleux
2003-04-13 9:30 ` Derek J. Belrose
2003-04-13 9:34 ` Brian Harring
2003-04-13 9:47 ` Derek J. Belrose
2003-04-13 13:55 ` Cliff Free
2003-04-18 9:35 ` Mark Bainter
2003-04-18 14:54 ` Jeff Rose
2003-04-19 3:45 ` Abhishek Amit
2003-04-20 2:50 ` Evan Powers
2003-04-20 3:05 ` C. Brewer
2003-04-13 16:33 ` Alain Penders
2003-04-13 20:04 ` Jeff Rose
2003-04-13 20:09 ` Graham Forest
2003-04-13 20:36 ` Derek J. Belrose
2003-04-13 22:26 ` Cliff Free
2003-04-13 22:33 ` Derek J. Belrose
2003-04-13 23:13 ` Alec Berryman
2003-04-15 14:26 ` DJ Cozatt
-- strict thread matches above, loose matches on Subject: below --
2003-04-14 10:18 Stroller
2003-04-14 13:17 ` William Hubbs
2003-04-15 4:06 ` John Nilsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E992A80.60508@omegabyte.com \
--to=derek@omegabyte.com \
--cc=gentoo-dev@gentoo.org \
--cc=rosejn@Colorado.EDU \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox