We're certainly getting there! I haven't yet given up hope of doing this with a shell script (evidentiary question again). The benefit of a shell script is that it leaves open the possibility of packaging a "lite" version of the program as a single architecture-neutral file, so that we can support users of other unixoid systems that can download a script.
The reason I went for numbered rankings was that it makes it easy to compare two modules that don't know anything about each other. If every module needs a greater than/less than function that knows about every other module, that makes O(n^2) work for us every time we want to add a new module. Or more precisely, O(n^2) work for some poor expert we'll never meet that happens to need a particular module for his special case. On the other hand, if you have a non-numeric solution with linear complexity, I always like being proved wrong about these things :) The choice of interface module needs to be made before the choice of lower-level module, because not all interfaces have the same requirements. For example, VNC needs a TCP socket, which has to be passed in the parameters to SSH. Finally, I agree that a GUI would be a good default choice here, although it needs to be written in such a way that the ncurses/plaintext fallback looks quite natural to the user when everything goes wrong. However, I don't really do GUI programming, so it's not something I would be able to do myself. I'm now going to download dash and see whether I can fight my way out of that little box. If not, C it is. - Andrew Justin M. Wray wrote: > I agree with your generalization, and ordering. It provides fault tolerance, > security, and usability. Making the entire process esasier (the main goal of > this project). > > I am unsure if I feel adding a numeric value to each option is needed, when > simple programming conditions can handle the tasks. I think the numbers > (bids) adds some uneeded complexity/confusion. > > The robustness and power of the solution we are now talking about exceeds the > power of simple shell scripts and code hacks, thus needing a higher level > language. But I personally see this as a good thing (speed, security, etc). > > I think it would be best to go through each option as you have them listed, > and try them, once. If it works use it, if not move on. Only prompt the > user if we get to an insecure option. But at the same time I think the > "helpless user" should have the ability to over-ride the option, or the > "helper" over-ride the option (with approval from the helpless) at start. > > A GUI front-end would le such choices be easily made. And an expert can > easily tell the "helpless" to type --telnet at the end of the command. > > One more note, if we do use something like 'c' we could easily add a socket > into the app itself. So we would have the following options, in said order: > > 1) SSH > 2) bash->socat->cryptcat > 3) bash->socat->netcat > 4) bash->socat > 5) telnet > 6) bash->socket > > (I've changed the order around a bit, to what I think would more secure and > sound.) > > And after connection, having the following recovery options: > > 1) A VNC-based GUI > 2) An X-based GUI (for e.g. broken video cards) > 3) A screen-based TUI (for those of us that love screen) > 4) A pty-based TUI (so that editors like vi work) > 5) A pipe-based TUI (for dire emergencies) > 6) A non-interactive mechanism for swapping keys > 7) Custom command > > (Which should have been selected when the recovery-command was first run.) > > It seems like we are on track, what do you think? > > Thanks, > Justin M. Wray > > Sent via BlackBerry by AT&T -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss