I'm going to throw in here. I've been using GLIS here to try and get up
a custom installer and it's a good first pass but it has severe
limitations. While just about everything in the install process can boil
down to a command on the shell command line, that does not make bash a
natural choice for an install script. Take for example, there is no easy
way to do multi-dimensional arrays in bash and doing something as
seemingly simple as define 2 raid arrays with different numbers of
partitions, becomes increasingly hard to do in bash.
Also, I've had to make some significant changes to GLIS to get it to do
what I'd like it to. Namely, my plan is to be able to install gentoo on
clusters of machines that need to be exact, and the build process needs
to be fast. I will *not* stand for having to compile a kernel on every
install. GLIS got the ball rolling and got people thinking about what's
good and bad, but I agree that a new method, that's engineered from the
ground up to handle all of these things is "a good thing"(tm).
Just my piece.
On Thu, 2004-03-18 at 00:17, Scott Hadfield wrote:
> 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
> taken seriously.
> >> 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
firstname.lastname@example.org mailing list