public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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


  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