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
