Eric Sammer wrote:
> Short answer is that it doesn't cover all the features users want.
> (Remember we're talking about users, not just ourselves, etc.)
It doesn't cover ALL of the features, but it does cover a lot of them.
Just briefly reviewing over the initial specifications:
* Multiple front ends - Definately
* Reusible back end framework - Sort of, but arguably not.
* Automated deployement - Definately
* Dry run profile generation - Yes
* Full support for all Gentoo architectures - I doubt it. And it
definately hasn't been tested on much more than x86
* Specialized profiles - Possible, but no one's done any work to create any.
* Open policies and standards use - No, not really.
* Integration with future configuration projects - No.
As far as design goes, GLIS is fairly similar to what is specified (at
least as far as my untrained eyes can tell).
>> It even seems to me that an initial goal of GLI is to get to the
>> point where GLIS is at right now, i.e. working, based on a
>> configuration file, and highly flexible.
> It's coincidence. The reason it's being rebuilt is because the
> architecture had to change to accommodate the required features.
Probably not coincidence, probably just good practice if you want to
write a serious installer. :-)
>> GLIS is written in bash and made up of about 8 small bash scripts
>> (except for the partition code, which is way too big for bash), and
>> in my opinion this is really all you need for a gentoo installer
>> since all it takes to install gentoo is a few bash commands.
> And while it's good that something such as that works for you, there's
> somewhere around 250,000 - 500,000 gentoo users out there (last I
> heard) that this doesn't work for. If it did, they wouldn't be asking
> for something else.
While, a few bash commands do work for me, but in my next sentence I
said that "GLIS simply takes those commands and puts them into scripts."
Maybe I'm wrong, but I think most of the 250-500 thousand potential
gentoo user's would be willing to type in ./glis to get gentoo
installed, and the rest would be willing to wait for a GUI. Of course
most of those people wouldn't be willing to sit down and take two hours
or so editing the glis config file the first time they do it. And a good
interface to the config file would be a must if glis was going to be
>> I've followed this installer project from its beginning in January,
> This may come off wrong, but if you've been following it since its
> beginning, the differences in goals between GLIS and the GLI should be
> clear, as should the need for the GLI.
This is partially the main reason I wrote this email now, and not in
January. Perhaps I just need it spelled out for me. As I said
previously, to install gentoo takes a few bash commands, these commands
would fit ideally into a bash script. There's a few areas that this idea
fails though, as can be proven just by reading over the partitioning
code in glis. Bash is not an ideal language to write a partitioner, 400
lines of bash code full of nested loops is just too much for any normal
person to handle. Another area where this fails is in editing system
config files, the way glis does this, in my opinion, is not pretty and
full of potential bugs. I think it would be very difficult to write a
good, stable config parser/editor in bash.
So, I do understand a few of the reason's for GLI, but after two months
the difference is still not fully clear to me.
>> but it seems like most of core developer's don't have as much spare
>> time to devote to the project as they may have initially thought.
> Not entirely true... just because cvs activity isn't streaming,
> doesn't mean it's not being worked on.
I didn't mean to imply that no work had been done or that the work that
has been done is not significant. I believe quite the opposite, all I
was trying to imply was that the project may take a bit longer than
previously thought. (I'm aware that no one has really even given a
ballpark estimate of the eta for gli, but I think it's hard to argue
that it's progressing as fast as it seemed it would at the end of January).
>> If you adopted GLIS as gentoo's installer right now then at least
>> gentoo would have something, and in 6-12 months when GLI is done you
>> could switch over it.
> Unfortunately, that would cause even further upset. See, if you
> introduce something new, get them to learn it, and then replace it
> with something with a very different feature set and design, well,
> you'll piss people off.
This is something I definately overlooked. But how different will the
feature set actually be? The way I see it GLI will have (pretty much)
everything GLIS had but way more, and be way cooler. Of course the
configuration file will be completely different and somebody who's use
to the GLIS config file would likely be pissed at having to switch.
However, I'm not convinced that this is a real issue. If people are
upset that gentoo switched "official" installers then so-be-it, it's not
like they won't be able to use the old way anymore and it's not like
they chose gentoo because of it's cool assed installer. I'm just trying
to say, if GLI was lacking in features compared to GLIS, I'd sympathize
with the pissed-off, otherwise, as long as they were given sufficient
warning, I wouldn't be too worried about them.
> It's a bit more complicated than that. There's more to application
> design than drawing two boxes on a white board and labeling one
> "Backend" and one "GUI" no matter what people say.
For a lot of applications I would agree, but not for this one. If a gui
was developed for glis and then we wanted to switch it to gli, with the
foresight that it would be switched, it could easily be made up of three
main parts. 1) reading in the config 2) asking the user questions 3)
writing the config. 1 and 3 would need to be completely rewritten for a
different installer, 2 (which is the essence of the GUI and most
difficult) could remain largely the same, except for maybe a few more
features that would need to be added to it.
> there have probably been few bugs in GLIS because it doesn't meet the
> needs of the majority of users.
You're probably right. Small user base generally equals small number of
bugs found. But I think glis doesn't meet the needs of the majority for
two main reasons, 1) no interface to the config file 2) no one really
knows about it.
> As a (rather contrived) for-instance...
> We build an installer like GLI with multiple front ends,
> auto-deployment for large networks, reusable... [SNIP] The world is a
> better place. Gentoo is a better distro. Linux gains more acceptance.
It's a nice story, but I'm not really sure I see it's relevance to not
using GLIS. In fact I see exactly the opposite, why hold an installer
back only to delay the world being a better place ;-).
Basically, I was just seeing if anyone thought it would be a worthwhile
idea to adopt glis as an "unofficial-official" installer until gli is
ready, develop a working UI that could be easily interchanged between
both, and give the user's a little something right now. There's a lot of
issues involved in doing this and perhaps for now it's best to just
remain focussed on one installer instead of having the worry of two.
Thanks for your reply though, it definately cleared a few things up for me.
email@example.com mailing list