1 |
I'm going to throw in here. I've been using GLIS here to try and get up |
2 |
a custom installer and it's a good first pass but it has severe |
3 |
limitations. While just about everything in the install process can boil |
4 |
down to a command on the shell command line, that does not make bash a |
5 |
natural choice for an install script. Take for example, there is no easy |
6 |
way to do multi-dimensional arrays in bash and doing something as |
7 |
seemingly simple as define 2 raid arrays with different numbers of |
8 |
partitions, becomes increasingly hard to do in bash. |
9 |
|
10 |
Also, I've had to make some significant changes to GLIS to get it to do |
11 |
what I'd like it to. Namely, my plan is to be able to install gentoo on |
12 |
clusters of machines that need to be exact, and the build process needs |
13 |
to be fast. I will *not* stand for having to compile a kernel on every |
14 |
install. GLIS got the ball rolling and got people thinking about what's |
15 |
good and bad, but I agree that a new method, that's engineered from the |
16 |
ground up to handle all of these things is "a good thing"(tm). |
17 |
|
18 |
Just my piece. |
19 |
|
20 |
On Thu, 2004-03-18 at 00:17, Scott Hadfield wrote: |
21 |
> Eric Sammer wrote: |
22 |
> |
23 |
> > Short answer is that it doesn't cover all the features users want. |
24 |
> > (Remember we're talking about users, not just ourselves, etc.) |
25 |
> |
26 |
> It doesn't cover ALL of the features, but it does cover a lot of them. |
27 |
> Just briefly reviewing over the initial specifications: |
28 |
> * Multiple front ends - Definately |
29 |
> * Reusible back end framework - Sort of, but arguably not. |
30 |
> * Automated deployement - Definately |
31 |
> * Dry run profile generation - Yes |
32 |
> * Full support for all Gentoo architectures - I doubt it. And it |
33 |
> definately hasn't been tested on much more than x86 |
34 |
> * Specialized profiles - Possible, but no one's done any work to create any. |
35 |
> * Open policies and standards use - No, not really. |
36 |
> * Integration with future configuration projects - No. |
37 |
> |
38 |
> As far as design goes, GLIS is fairly similar to what is specified (at |
39 |
> least as far as my untrained eyes can tell). |
40 |
> |
41 |
> >> It even seems to me that an initial goal of GLI is to get to the |
42 |
> >> point where GLIS is at right now, i.e. working, based on a |
43 |
> >> configuration file, and highly flexible. |
44 |
> > |
45 |
> > It's coincidence. The reason it's being rebuilt is because the |
46 |
> > architecture had to change to accommodate the required features. |
47 |
> |
48 |
> Probably not coincidence, probably just good practice if you want to |
49 |
> write a serious installer. :-) |
50 |
> |
51 |
> >> GLIS is written in bash and made up of about 8 small bash scripts |
52 |
> >> (except for the partition code, which is way too big for bash), and |
53 |
> >> in my opinion this is really all you need for a gentoo installer |
54 |
> >> since all it takes to install gentoo is a few bash commands. |
55 |
> > |
56 |
> > And while it's good that something such as that works for you, there's |
57 |
> > somewhere around 250,000 - 500,000 gentoo users out there (last I |
58 |
> > heard) that this doesn't work for. If it did, they wouldn't be asking |
59 |
> > for something else. |
60 |
> |
61 |
> While, a few bash commands do work for me, but in my next sentence I |
62 |
> said that "GLIS simply takes those commands and puts them into scripts." |
63 |
> Maybe I'm wrong, but I think most of the 250-500 thousand potential |
64 |
> gentoo user's would be willing to type in ./glis to get gentoo |
65 |
> installed, and the rest would be willing to wait for a GUI. Of course |
66 |
> most of those people wouldn't be willing to sit down and take two hours |
67 |
> or so editing the glis config file the first time they do it. And a good |
68 |
> interface to the config file would be a must if glis was going to be |
69 |
> taken seriously. |
70 |
> |
71 |
> >> I've followed this installer project from its beginning in January, |
72 |
> > |
73 |
> > This may come off wrong, but if you've been following it since its |
74 |
> > beginning, the differences in goals between GLIS and the GLI should be |
75 |
> > clear, as should the need for the GLI. |
76 |
> |
77 |
> This is partially the main reason I wrote this email now, and not in |
78 |
> January. Perhaps I just need it spelled out for me. As I said |
79 |
> previously, to install gentoo takes a few bash commands, these commands |
80 |
> would fit ideally into a bash script. There's a few areas that this idea |
81 |
> fails though, as can be proven just by reading over the partitioning |
82 |
> code in glis. Bash is not an ideal language to write a partitioner, 400 |
83 |
> lines of bash code full of nested loops is just too much for any normal |
84 |
> person to handle. Another area where this fails is in editing system |
85 |
> config files, the way glis does this, in my opinion, is not pretty and |
86 |
> full of potential bugs. I think it would be very difficult to write a |
87 |
> good, stable config parser/editor in bash. |
88 |
> |
89 |
> So, I do understand a few of the reason's for GLI, but after two months |
90 |
> the difference is still not fully clear to me. |
91 |
> |
92 |
> >> but it seems like most of core developer's don't have as much spare |
93 |
> >> time to devote to the project as they may have initially thought. |
94 |
> > |
95 |
> > Not entirely true... just because cvs activity isn't streaming, |
96 |
> > doesn't mean it's not being worked on. |
97 |
> |
98 |
> I didn't mean to imply that no work had been done or that the work that |
99 |
> has been done is not significant. I believe quite the opposite, all I |
100 |
> was trying to imply was that the project may take a bit longer than |
101 |
> previously thought. (I'm aware that no one has really even given a |
102 |
> ballpark estimate of the eta for gli, but I think it's hard to argue |
103 |
> that it's progressing as fast as it seemed it would at the end of January). |
104 |
> |
105 |
> >> If you adopted GLIS as gentoo's installer right now then at least |
106 |
> >> gentoo would have something, and in 6-12 months when GLI is done you |
107 |
> >> could switch over it. |
108 |
> > |
109 |
> > Unfortunately, that would cause even further upset. See, if you |
110 |
> > introduce something new, get them to learn it, and then replace it |
111 |
> > with something with a very different feature set and design, well, |
112 |
> > you'll piss people off. |
113 |
> |
114 |
> This is something I definately overlooked. But how different will the |
115 |
> feature set actually be? The way I see it GLI will have (pretty much) |
116 |
> everything GLIS had but way more, and be way cooler. Of course the |
117 |
> configuration file will be completely different and somebody who's use |
118 |
> to the GLIS config file would likely be pissed at having to switch. |
119 |
> However, I'm not convinced that this is a real issue. If people are |
120 |
> upset that gentoo switched "official" installers then so-be-it, it's not |
121 |
> like they won't be able to use the old way anymore and it's not like |
122 |
> they chose gentoo because of it's cool assed installer. I'm just trying |
123 |
> to say, if GLI was lacking in features compared to GLIS, I'd sympathize |
124 |
> with the pissed-off, otherwise, as long as they were given sufficient |
125 |
> warning, I wouldn't be too worried about them. |
126 |
> |
127 |
> > It's a bit more complicated than that. There's more to application |
128 |
> > design than drawing two boxes on a white board and labeling one |
129 |
> > "Backend" and one "GUI" no matter what people say. |
130 |
> |
131 |
> For a lot of applications I would agree, but not for this one. If a gui |
132 |
> was developed for glis and then we wanted to switch it to gli, with the |
133 |
> foresight that it would be switched, it could easily be made up of three |
134 |
> main parts. 1) reading in the config 2) asking the user questions 3) |
135 |
> writing the config. 1 and 3 would need to be completely rewritten for a |
136 |
> different installer, 2 (which is the essence of the GUI and most |
137 |
> difficult) could remain largely the same, except for maybe a few more |
138 |
> features that would need to be added to it. |
139 |
> |
140 |
> > there have probably been few bugs in GLIS because it doesn't meet the |
141 |
> > needs of the majority of users. |
142 |
> |
143 |
> You're probably right. Small user base generally equals small number of |
144 |
> bugs found. But I think glis doesn't meet the needs of the majority for |
145 |
> two main reasons, 1) no interface to the config file 2) no one really |
146 |
> knows about it. |
147 |
> |
148 |
> > As a (rather contrived) for-instance... |
149 |
> > |
150 |
> > We build an installer like GLI with multiple front ends, |
151 |
> > auto-deployment for large networks, reusable... [SNIP] The world is a |
152 |
> > better place. Gentoo is a better distro. Linux gains more acceptance. |
153 |
> > |
154 |
> It's a nice story, but I'm not really sure I see it's relevance to not |
155 |
> using GLIS. In fact I see exactly the opposite, why hold an installer |
156 |
> back only to delay the world being a better place ;-). |
157 |
> |
158 |
> Basically, I was just seeing if anyone thought it would be a worthwhile |
159 |
> idea to adopt glis as an "unofficial-official" installer until gli is |
160 |
> ready, develop a working UI that could be easily interchanged between |
161 |
> both, and give the user's a little something right now. There's a lot of |
162 |
> issues involved in doing this and perhaps for now it's best to just |
163 |
> remain focussed on one installer instead of having the worry of two. |
164 |
> |
165 |
> Thanks for your reply though, it definately cleared a few things up for me. |
166 |
> |
167 |
> Scott |
168 |
> |
169 |
> -- |
170 |
> gentoo-installer@g.o mailing list |
171 |
> |
172 |
|
173 |
|
174 |
-- |
175 |
gentoo-installer@g.o mailing list |