1 |
Why not simply use gentoo's livecd? |
2 |
|
3 |
The livecd can boot the user into a fully loaded console or X workstation, |
4 |
with all the tools needed. |
5 |
|
6 |
The installer could be an additional tool on the liveCD system.. Anybody knows |
7 |
a GUI abstration toolkit that can generate either terminal based or X based |
8 |
interface, depending on what's available at runtime? |
9 |
|
10 |
This way the same installer could be used if X is not working or can't be |
11 |
used. |
12 |
|
13 |
In both environment (terminal / X), multitasking would be possible so |
14 |
experienced users could perform manual tasks while the installer is waiting |
15 |
for input.. |
16 |
|
17 |
|
18 |
Just my 2 cents, |
19 |
|
20 |
Cedric |
21 |
|
22 |
|
23 |
|
24 |
|
25 |
|
26 |
Le 13 Avril 2003 04:49, Jeff Rose a écrit : |
27 |
> Well, I'm glad to see that people are interested. After doing some |
28 |
> initial research I have some thoughts. First, we should decide on whether |
29 |
> we want to have a terminal or X based installer. Does anyone know how |
30 |
> well the generic vesa driver works for X? I personally have battled with |
31 |
> X so many times that I'm not sure I think its worth it for an installer. |
32 |
> (Although we could just use the RedHat stuff for autodetection etc. if we |
33 |
> want to go that direction.) Besides X we could use ncurses dialog |
34 |
> widgets or another terminal gui package. I was thinking it would be cool |
35 |
> to use somethine lighter than X like svgalib. I have no experience with |
36 |
> it and don't know how cross platform (or cross video card) it is, but it |
37 |
> could be a cool solution if a decent widget set is put on top of it. I'm |
38 |
> not sure if this would lead to more or less work than using X. |
39 |
> As for choosing stages, that should be a decision made by the user |
40 |
> at install time. We can very briefly explain how the system works and let |
41 |
> them do what they please. For the complete novice we can basically have |
42 |
> the "do everything for me" button. For the supreme hacker we can let them |
43 |
> have it all while still taking care of mundane details. (For example, |
44 |
> they could choose what file systems they want to use on what partitions, |
45 |
> but that would just be a selection dialog rather than having to type the |
46 |
> commands etc...) It might be nice if the installer can be exited at any |
47 |
> point so people have the ability to get things rolling quickly but then |
48 |
> tweak things out to their hearts content once its where they want it. |
49 |
> One of the major pains in the redhat like installers deals with |
50 |
> package selection. I think it is ridiculous to give people a list of a |
51 |
> thousand packages and tell them to pick. Especially since the package |
52 |
> documentation is horrible. Most people probably wouldn't know that its |
53 |
> important for them to have the e2fsprogs installed, for example. So, this |
54 |
> is the portion of the installer where I see the most room for innovation. |
55 |
> Especially since gentoo has such a unique package system, we should really |
56 |
> try to enable the user as much as possible, rather than just hucking a |
57 |
> bunch of packages into the mix. I'm still working on ideas, but we should |
58 |
> experiment with all kinds of stuff to get this stage really smoothed out. |
59 |
> This idea of processor detection makes me think that a whole lot |
60 |
> of detection could go on if we wanted it to. The thing is detection is |
61 |
> useless unless you can act on what you have detected. Changing some CPU |
62 |
> related compiler flags is one thing, but what about detecting network, |
63 |
> sound, video, raid, scsi, firewire, printers etc. This could all get very |
64 |
> tricky real fast. What about using RedHats kudzu? |
65 |
> |
66 |
> Peace, |
67 |
> Jeff |
68 |
> |
69 |
> On Sun, 13 Apr 2003, Derek J. Belrose wrote: |
70 |
> > The only problem I see with doing this is how to represent it in a user |
71 |
> > friendly, yet power user accessible fashion. Maybe if you are using |
72 |
> > anaconda, you could have the power user abilities under "Amazing super |
73 |
> > power user" setting :) |
74 |
> > |
75 |
> > Grabbing the processor isn't difficult, build a small database of known |
76 |
> > processors and compare it to /proc/cpuinfo. |
77 |
> > |
78 |
> > At this point, what would you use for a install? Stage1, 2 or 3? Stage |
79 |
> > 3 would be the quickest in my opinion as well giving the user a really |
80 |
> > good launching pad for an optimized system. |
81 |
> > |
82 |
> > Cliff Free wrote: |
83 |
> > >I think a GUI installer would be great if done correctly. The |
84 |
> > >interface, obviously, should be easy to use, but in the spirit of |
85 |
> > >Gentoo, shouldn't limit the user with what he can do. On a side note, I |
86 |
> > >also think it would be cool to have the ability to detect the processor |
87 |
> > >type(s) and include some optimization flags for the detected |
88 |
> > >processor(s) (I also feel this feature should be able to be toggled so |
89 |
> > >hard-core power-users would still have the option to fine-tune to their |
90 |
> > >heart's content, and that by default the feature would be OFF. Maybee |
91 |
> > >the detection system would only augment CFLAGS and CXXFLAGS in |
92 |
> > >make.conf. and/or make.conf settings would override what's detected.) |
93 |
> > >Just my 2 cents worth. Doing this correctly could prove to be a |
94 |
> > >daunting task. |
95 |
> > > |
96 |
> > >On Sun, 2003-04-13 at 01:38, Derek J. Belrose wrote: |
97 |
> > >>Is the Mandrake install system based on RedHat's anaconda? If it is, |
98 |
> > >>it's nicely written python...but you'll have to seriously hack it to |
99 |
> > >> get rid of the neat little rpm stuff :) |
100 |
> > >> |
101 |
> > >>I'd be willing to help out a bit on this too...gotta get it going for |
102 |
> > >>Gentoo-Sparc :) |
103 |
> > >> |
104 |
> > >>Derek |
105 |
> > >> |
106 |
> > >>Justin Whitney wrote: |
107 |
> > >>>I think some or all of Mandrake's install system is under GPL as well, |
108 |
> > >>>so you might want to check that out. |
109 |
> > >>> |
110 |
> > >>>--Justin |
111 |
> > >>> |
112 |
> > >>>On Fri, 2003-04-11 at 19:04, Jeff Rose wrote: |
113 |
> > >>>>Hello, |
114 |
> > >>>> I'm pretty new to gentoo, but I am an instant convert. Just a |
115 |
> > >>>>few months of emerge bliss and now I'm an avid supporter. Anyway, |
116 |
> > >>>> I'm thinking about starting a summer project and I'm pondering the |
117 |
> > >>>> idea of a gui installer. I've been looking around a bit and it |
118 |
> > >>>> doesn't look like anyone is working on one. Is that true? If there |
119 |
> > >>>> isn't already a project then I think I'll give it a whirl. I know, |
120 |
> > >>>> I know, gentoo is so great because it allows you to customize and |
121 |
> > >>>> tweak the hell out of everything. That is completely true. So, an |
122 |
> > >>>> installer would have to allow just as much but it could take care of |
123 |
> > >>>> the mundane details for those who aren't interested or knowledgable |
124 |
> > >>>> enough. |
125 |
> > >>>> I haven't been around to see what people discuss in terms of the |
126 |
> > >>>>installer so I'm sorry if this is all stuff that you have gone over |
127 |
> > >>>>hundreds of times. Even more minimal than a gui installer, have you |
128 |
> > >>>>thought about adding more scripts to do the standard directory setup, |
129 |
> > >>>>download, chroot... type of stuff? |
130 |
> > >>>> What do you think? |
131 |
> > >>>> |
132 |
> > >>>>-Jeff |
133 |
> > >>>> |
134 |
> > >>>> |
135 |
> > >>>>-- |
136 |
> > >>>>gentoo-dev@g.o mailing list |
137 |
> > >>> |
138 |
> > >>>-- |
139 |
> > >>>gentoo-dev@g.o mailing list |
140 |
> > >> |
141 |
> > >>-- |
142 |
> > >>gentoo-dev@g.o mailing list |
143 |
> > |
144 |
> > -- |
145 |
> > gentoo-dev@g.o mailing list |
146 |
> |
147 |
> -- |
148 |
> gentoo-dev@g.o mailing list |
149 |
|
150 |
|
151 |
-- |
152 |
gentoo-dev@g.o mailing list |