Hello, I would suggest to have a configurator option for SIS : Do you use network boot (yes/no radio button, default yes).
This value will be set during the configure package step. Once this is set, the GUI can then be automatically configured to adress those two situations. At some point, the scenario are a bit different but I guess that the same GUI pannel can fit both... Ben * Jeremy Enos <[EMAIL PROTECTED]> [04-02-05 17:05]: > That would be better than the current scenario of course... again tho- Why > not just do it automatically ALL the time? > Rationale: > * Most users will be doing it anyway (this is a guess, but based on > experience) > * Another daemon running a "bad thing"? N/A... this daemon isn't running- > it's spawned from inetd. > * It's "do no harm". No need to complicate the interface (or > documentation) any more than it is already. > > Jeremy > > At 03:48 PM 2/5/2004, Jeff Squyres wrote: > >Sure. Just make it more obviosu in the GUI. Like, do it unless users say > >*not* to. > > > >Or pop up another window saying "Do you need to network boot?" and require > >a yes/no click to dismiss the window, etc. Terry would probably have some > >good ideas on how to make this silly UI issue better. > > > > > >On Thu, 5 Feb 2004, Jeremy Enos wrote: > > > >> Folks- > >> It came up once in the past- I'll bring it up again. The question of > >> whether or not to "setup network boot" automatically w/o forcing the user > >> to explicitly hit a button. Documentation can take us so far, but not as > >> far as simply guaranteeing it. > >> > >> I just dealt with [another] frustrated user who was following > >> documentation, started reading a paragraph that started out talking about > >> making a boot floppy... skipped it and went on. Unfortunately, this > >> paragraph ended by talking about the setup network boot step, and was > >> missed. This left the user with a tftp hang on the nodes, and spending > >> hours trying to debug *the other* 50 reasons that symptom may > >> occur. Granted, they could have read the documentation more closely, but > >> nonetheless, it was an AVOIDABLE problem... that's what burns me. (and > >> that I wanted to just do it a long time ago) ;-) Anyway... there's the > >> whole premise that you can't protect the user from the user. Well in > >this > >> case, it's certainly possible. > >> Can we finally plan on just doing this in the future? It's an > >opportunity > >> to remove a choice from the user that's not necessary for them to even > >have > >> to think about. > >> > >> Jeremy > >> > >> > >> > >> ------------------------------------------------------- > >> The SF.Net email is sponsored by EclipseCon 2004 > >> Premiere Conference on Open Tools Development and Integration > >> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > >> http://www.eclipsecon.org/osdn > >> _______________________________________________ > >> Oscar-devel mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/oscar-devel > >> > > > >-- > >{+} Jeff Squyres > >{+} [EMAIL PROTECTED] > >{+} http://www.lam-mpi.org/ > > > > > >------------------------------------------------------- > >The SF.Net email is sponsored by EclipseCon 2004 > >Premiere Conference on Open Tools Development and Integration > >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > >http://www.eclipsecon.org/osdn > >_______________________________________________ > >Oscar-devel mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/oscar-devel > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Oscar-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/oscar-devel -- Benoit des Ligneris Ph. D. <|> http://benoit.des.ligneris.net/ Centre de Calcul Scientifique <|> http://ccs.USherbrooke.ca/ OSCAR Developpe(u)r <|> http://oscar.sourceforge.net/ �duLinux <|> http://www.edulinux.org/ R�volution Linux <|> http://www.revolutionlinux.com/ ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
