Google Summer of Code

[Adam Gołębiowski]

On Sat, Mar 03, 2007 at 08:56:26PM +0100, Daniel Mróz wrote:
> On Saturday 03 of March 2007 20:03:41 Adam Gołębiowski wrote:
> > > > areq's rescuecd is the best one, but I realize it may be the best one
> > > > for me, not necessary for everyone. Having a modern, gui installer
> > > > wouldn't hurt.
> > > Wouldn't, but I think we should fix existing text mode installer and add
> > > some new features to it (like multimachine, fully automated network
> > > installation).
> > And end up with an installer that almost noone would use - experienced
> > users will prefer rescuecd, while less experienced would rather choose
> > another distro, which has a better installer. I know of a few people
> > whose choice was based on how easy is to install given distro.
> Small steps would be better I think. We must have text mode installer, that's 
> for sure. When this will be accomplished, then we can think about GUI 
> installer, which can be even build on top of existing one or use 
> it's... "modules".

If there is to be a text mode installer, I would rather fix it to be
able to install Ac from current (final) package set and try to avoid
adding any new features to it. It's just waste of time.

> But let's get back to that new feature above for a moment. What would you say 
> about that for a project? I mean, if we have a few raw machines with the same 
> or similar hardware configuration (like a cluster) and we want to install PLD 
> on all of them. They're booted from TFTP with our new installer that opens 
> some TCP port. On a single, already running machine we define all the 
> parameters of the installation (disk partitioning, RAIDs, packages to 
> install, initial system configuration; we could do this even on per machine 
> basis), connect to "slaves" and monitor the entire process done in parallel 
> on all of those machines. Thanks to this we could manage that multimachine 
> installation from a single "master" application (i.e. GUI), without 
> connecting keyboards and displays to the "slaves". In one window we could 
> have informations like what each of the "slaves" is doing now, are there any 
> errors, how much time (not exact of course) is left to finish and so on.

Great. I see this as a great and useful addon, but still - an addon.
What I would love to see from an (GUI) installer is to install PLD on a
single machine. Once that is completed, I am all for developing any
additional modules, but let's have a base first.

 > > Then you won't install it. Others will. Sure it's not going to give us
> > correct numbers, but at least we could have rough statistics about
> > packages' popularity (like whether gnome or desktop is preferred).
> >
> > Debian has popcon [1], and they don't complain about their statistics
> > being inadequate. I know we are not as big as Debian is, but still, such
> > data could be useful and for sure, it won't hurt to have them.
> OK, but there's one more thing that bothers me. Is it not too simple? Such 
> application can be done in less than 100 lines of code in Python, including 
> error handling. That's about two hours of coding without final tests. How 
> long this Summer of Code will take?

I don't know. I think it will be up to Google to choose which projects
can be done within SoC. Maybe a client can be quite simple to code, but
to design various graphs, stats, or comparisions from gathered data can
take a while.

-- 
 http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
   PLD Linux developer    | Everybody needs some solid rock, I know I do.