| 1 |
On Wed, 2004-01-14 at 22:09, Brian Dwornick wrote: |
| 2 |
> There are two very different reasons that I can see for making an installer. |
| 3 |
> One is to make it easier to install gentoo for people that are not |
| 4 |
> comfortable with linux. This in my opinion would be a bad move as gentoo |
| 5 |
> isn't aimed to be the first linux distribution someone uses. |
| 6 |
I disagree. Teaching people something because it might be easier in the |
| 7 |
beginning is not always the best strategy. |
| 8 |
<flame> |
| 9 |
Just look at all the people that need a mouse and a pretty icon to click |
| 10 |
at. How did they work with text-based editors a few years ago? |
| 11 |
Why can't the secretary that used DOS 3.3 to copy files use the Dos-box |
| 12 |
in Windows? |
| 13 |
</flame> |
| 14 |
I've observed that those people that are interested in learning (as |
| 15 |
opposed to those that want to get their work done) can benefit a lot |
| 16 |
from gentoo, and the others don't care (if there is a problem, _you_ |
| 17 |
better fix it), so you can't loose (I hope) |
| 18 |
|
| 19 |
So, from my point of view, Gentoo is good since it teaches those that |
| 20 |
want to learn and makes life easier for me if I have to "repair" a |
| 21 |
broken system. |
| 22 |
|
| 23 |
> The seconds |
| 24 |
> reason would be to make it easier to install in a corporate enviroment |
| 25 |
> (server farms, multiple offices, etc.) With this in mind, I believe an |
| 26 |
> "installer" should be implemented as a text based script, not a pretty GUI. |
| 27 |
I'm more for a config-file driven thingy with different frontends (nice |
| 28 |
GUI with text fallback or something like that), but someone has to |
| 29 |
implement it ... |
| 30 |
|
| 31 |
> It should read a config file made by whoever is doing the install that has |
| 32 |
> many default configs in it and maybe prompt for the uses of the machine. |
| 33 |
> IE: |
| 34 |
If you could save / restore a config file you could easily clone a setup |
| 35 |
onto different hardware, and if you had automatic processor detection you |
| 36 |
could clone the setup _and_ optimise at the same time! :-) |
| 37 |
|
| 38 |
> The following configs have been detected please choose one: |
| 39 |
> [0] Prompt for config |
| 40 |
> [1] Desktop (KDE) |
| 41 |
> [2] Laptop (KDE) |
| 42 |
> [3] Email/Web/DNS Server (No X) |
| 43 |
> [4] Rendering Farm |
| 44 |
> ? 2 |
| 45 |
Yes, that should be nice. Maybe a two- or three-layer menu, but |
| 46 |
nothing as horrible as dselect, please. |
| 47 |
|
| 48 |
> What stage would you like to start from? |
| 49 |
> [1] |
| 50 |
> [2] |
| 51 |
> [3] |
| 52 |
> ... |
| 53 |
> At this point the installer could make choices that would produce the |
| 54 |
> optimal system but without the system admin having to sit and type the same |
| 55 |
> things over and over. The make.conf could be generated by using /proc and |
| 56 |
> the settings from the loaded config. |
| 57 |
You expect a lot of magic. I tend to dislike automatic detection of hardware |
| 58 |
since it can never work on all available systems. But if it worked very |
| 59 |
well (99,999% ;-) ) it'd be really nice to have. |
| 60 |
Still, I'd like to have full manual control, e.g. disable automagic |
| 61 |
detection, force-load this module, ... |
| 62 |
|
| 63 |
> Basically, distributions like Redhat make many decisions for you. I would |
| 64 |
> hate to see an installer that took choices from the users hands, as, gentoo |
| 65 |
> seems to be about choice. |
| 66 |
I agree. |
| 67 |
|
| 68 |
> My two cents, |
| 69 |
Euro or dollar? |
| 70 |
|
| 71 |
Patrick |
| 72 |
|
| 73 |
|
| 74 |
-- |
| 75 |
gentoo-dev@g.o mailing list |
Archives