¿Por qué la tecnología dictaría que las interfaces gráficas sean raras en las naves espaciales?

Esta pregunta difiere de esa pregunta en que la otra pregunta se refiere a un cambio en la historia, mientras que esta pregunta busca un cambio en el futuro.

En un escenario de futuro cercano en el que estoy trabajando, los humanos han construido hábitats espaciales y han establecido colonias en objetos celestes como la Luna . Sus naves espaciales no pueden ir más rápido que la luz y tienen una buena cantidad de otros problemas ; sin embargo, siguen siendo el principal medio de transporte a través del Sol y son el resultado de una mejora constante desde el primer transbordador espacial .

El vacío entre estas motas de vida está poblado por empresarios a pequeña escala, que envían carga de a a b en viajes que se miden en meses o años. Es decir, gracias a la criogenia , para ellos solo pasan unos días, quizás una semana.

Básicamente, toman un cargamento, trazan el rumbo y luego se despiertan esporádicamente para mantenimiento, correcciones de rumbo, etc.

Si bien el entorno es una extrapolación de la Tierra actual, la tecnología a bordo de los barcos y las estaciones está destinada a utilizar principalmente interfaces de texto y gráficos vectoriales 1 para la interacción y la retroalimentación. Piense en su típica terminal Unix .

Hay muchos botones de hardware para todo, pero los comandos o configuraciones más complejos, así como el acceso directo a los sistemas y dispositivos del barco, se realizan a través de mensajes de texto. P.ej

cryo set wakeup=time+2d
> wakeup procedure scheduled for SOL3-1_37:4:12m-6:23:40-127812_79812301
_

2

P : ¿ Por qué la tecnología dictaría que las interfaces gráficas sean raras en las naves espaciales? , a diferencia del pensamiento centrado en la GUI que es la norma actual?

Estoy buscando respuestas que presenten razones plausibles basadas en la tecnología (por ejemplo, ventajas) para este cambio de paradigma . Las respuestas basadas en temas sociales son bienvenidas, pero probablemente obtendrán peores calificaciones.

Puntos de bonificación para las respuestas que exploran ir hacia terminales tontas que se utilizan para interactuar con los sistemas de a bordo/estación de a bordo, pero que tienen pocas o ninguna otra capacidad (por ejemplo, cuando la gente tenía que intercambiar discos ).

1 Algunas personas pueden considerar que un retroceso ...
2 Cuando se viaja entre estaciones, planetas, etc. El tiempo se denota como una cantidad de segundos y nanosegundos que han pasado desde la salida de un MAYOR/MENOR que se agrega a la hora de salida.

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
Creo que un problema con esto es que sería increíblemente simple tener un ícono en su interfaz gráfica que abra una interfaz de texto.
¿Considerarías un modelo híbrido? Las respuestas a continuación ofrecen buenas razones por las que podría querer darle al usuario una interfaz textual para emitir comandos. Pero presentar datos/estado al usuario puede ser mucho más eficiente gráficamente que textualmente. Una visualización esquemática de una maniobra orbital puede comunicar efectivamente mucho más detalle que una tabla de números, incluso si la forma de modificar la operación es aplicar nuevas restricciones con comandos de texto.
Porque en una película futurista rodada en 1968, incluso una visualización de vídeo orientada a los personajes era increíblemente avanzada.
Los procesadores resistentes a la radiación no se pueden fabricar de forma tan compleja, por lo que son menos potentes. ¿La ISS todavía usa 80386es?
Un terminal Unix típico hoy en día es muy parecido a un Macintosh (que es BSD Unix debajo de las sábanas). Las interfaces de texto son buenas para algunas cosas, pero un tablero gráfico le dice mucho más de un vistazo de lo que puede obtener de un muro de texto.
La interfaz de línea de comandos siempre es más poderosa.
También necesitaría una razón por la cual no se usan los comandos de voz...
@fishinear ¿por qué?
@fishinear "Oye, Siri, después de que me baje en la siguiente estación, ejecuta un salto warp hacia la superficie del sol". Sin embargo, más en serio, los comandos de voz no están en el alcance de la pregunta declarada del OP, pero dada la premisa de la pregunta y la complejidad subyacente (significativamente más que una GUI), dudo que el universo propuesto tenga un uso para ellos en naves espaciales.
@brichins ... los comandos de voz no están en el alcance de la pregunta indicada por el OP ... ¿ podría dar más detalles sobre esto? yo no era consciente de eso
@Panzercrisis, hice esa pregunta a la que te vinculas. Acepté la respuesta de alguien que sabe mucho sobre el tema, pero esta respuesta se limita a ese caso muy específico, y solo hasta cierto punto (la GUI existe para ese caso). No puedo pensar en ninguna razón lógica para la pregunta del OP.
Su premisa es defectuosa. Una característica fundamental de los CLI es que el operador debe memorizar todos los comandos y todas las opciones. Para una nave espacial, eso es mucha memorización. La GUI puede presentar menús y sugerencias para ayudar a un astronauta sobrecargado a eliminar la memorización pura. La única circunstancia en la que una nave espacial podría tener un CLI es si esa nave se diseñó antes de la GUI, como lo fueron las naves lunares Apolo y todas las naves espaciales estadounidenses y soviéticas de esa época. ¿Quieres descubrir qué es una alarma 1202 cuando estás a punto de aterrizar en la luna por primera vez?
@ tj1000 ¿qué está hablando en contra de los manuales (tanto digitales como analógicos)?
@ dot_Sp0T Solo quise decir que la pregunta es sobre CLI vs GUI, pero no menciona el control de voz. Si bien eso no significa que no sea una posibilidad, no es parte de la pregunta inicial. Creo que sería una parte interesante de la discusión, pero las preguntas tienden a ser más difíciles de responder bien a medida que el alcance se vuelve más amplio, por lo que a menudo es mejor comenzar una nueva pregunta que modificar la original. Especialmente una vez que ya se han dado tantas respuestas.
@brichins, la pregunta es en esencia sobre '¿ Por qué la tecnología dictaría que las interfaces gráficas sean raras en las naves espaciales? ' - ese es el título, así como la pregunta en el cuerpo. El cuerpo se expande y se opone al pensamiento centrado en la GUI que existe hoy en día, por ejemplo, que una herramienta perfectamente buena con una mala GUI será reemplazada instantáneamente si una herramienta con una mejor GUI está disponible, incluso si su funcionalidad es peor que la anterior. herramienta. El ejemplo de solicitud de texto se elige porque a) a la gente le encantan los ejemplos; b) es lo único que me vino a la mente al escribir la pregunta.
No hay una buena razón tecnológica para que las interfaces gráficas sean raras. Ninguno. En absoluto. Cero. Si ese fuera el caso, entonces vería que CLI es el método de entrada y visualización elegido para sistemas en la vida real donde la entrada y la salida son absolutamente críticas para la seguridad y las operaciones, como en aviones, buques de guerra o procesos de fábrica. Y sin embargo, no ves eso en absoluto. Se prefieren las interfaces GUI. Nadie usa un CLI en un avión o en un buque de guerra por razones operativas. La única razón para tener una CLI es para acciones oscuras que un especialista llevaría a cabo con el código, no para operaciones.
@KeithMorrison. Estaba a punto de contradecirte, pero luego me di cuenta de que operar un telescopio espacial es exactamente el tipo de cosa que mencionas como un buen caso de uso para CLI :)
No vale la pena una respuesta por sí sola, pero una empresa comercial algorítmica en la que una vez trabajé evitó activamente las GUI en favor de las interfaces de texto de estilo 'maldiciones'. Para el comercio, se trata principalmente de números y cadenas de texto cortas, por lo que este enfoque funciona de manera muy eficiente. En una nave espacial, me imagino que le gustaría ver un gráfico de las partes del motor, con puntos destacados donde existen problemas (o lo que sea), por lo que una GUI parece útil allí. Sin embargo, también sospecho que una gran cantidad de la información que quizás desee ver se expresaría mejor en texto.
Las GUI son buenas para exponer una gran cantidad de funciones desconocidas, las cli son buenas para ejecutar rápidamente una serie de comandos conocidos o encadenar comandos. Los dos no están necesariamente en desacuerdo, en particular, no hay razón para que el resultado del comando cli deba ser textual.

Respuestas (38)

Una búsqueda rápida en la web de "CLI frente a GUI" (interfaz de línea de comandos frente a interfaz gráfica de usuario) muestra que muchos desarrolladores tienen lo siguiente 1 :

  1. CLI es más rápido para un usuario experimentado

    Es mucho más rápido escribir que navegar menús en capas con un mouse. Puede escribir con ambas manos y es fácil escribir a ciegas, por lo que no tiene que mantener la vista en el monitor en todo momento. Estos se vuelven mucho más importantes cuando su entorno físico no es estable (aceleración, baja G, etc.). Es muy difícil usar un mouse en tales situaciones, pero hay teclados especiales diseñados para pilotos:
    Teclado de cabina

  2. CLI es más eficiente de usar

    Hay tareas (p. ej., buscar en varios archivos/directorios con un conjunto complejo de parámetros) que son más fáciles de realizar con la CLI. Además, CLI permite un fácil "encadenamiento" de series de comandos (también llamados "tuberías"), de modo que la salida del primero sea la entrada del segundo y así sucesivamente, por ejemplo:

    • comando 1: enumerar todas las entradas de carga para explosivos,
    • comando 2: enumerar todas las bahías de carga en la entrada,
    • comando 3: sellar todas las esclusas de aire de las habitaciones en la entrada, y,
    • comando 4: enjuague con refrigerante de emergencia en todas las habitaciones en la entrada.

    Este conjunto de acciones es mucho más rápido de realizar en CLI que en GUI, a menos que alguien ya haya creado un botón de GUI para ese escenario específico. Finalmente, la CLI hace que el "aliasing" y la creación de secuencias de comandos sean muy fáciles, por lo que los usuarios experimentados pueden crear sus operaciones por lotes personalizadas y atajos de teclado, lo que hace que sus tareas comunes sean muy rápidas.

  3. CLI requiere menos recursos del sistema

    Si bien la tarea de mantener una GUI activa no es muy exigente para las computadoras actuales, la CLI requiere muchos menos recursos. Esto se vuelve más importante cuando está trabajando en una terminal remota: todos los gráficos deben comprimirse y comunicarse "a través del cable", y la pantalla se vuelve a dibujar constantemente (no solo cuando mueve el mouse, sino que incluso una pantalla gráfica intacta normalmente tienen un reloj, un ícono de estado de la red, etc., lo que significa actualizaciones constantes); por el contrario, un terminal CLI solo se actualiza cuando el usuario escribe o cuando un comando devuelve un resultado (e incluso entonces, mientras su terminal local actualiza su pantalla con cada pulsación de tecla , solo transmite al control remoto cuando presiona "Enter"). Si está operando varias computadoras remotas simultáneamente, o si está instruyendo a una máquina remota para que envíe comandos a otra máquina remota, el uso de CLI se vuelve aún más preferible ya que la degradación del rendimiento de la GUI en estas situaciones dificulta el trabajo. Finalmente, en muchos sistemas, si algo sale mal, CLI es su única opción ya que la máquina ni siquiera puede cargar la GUI.

    Todo esto puede ser mucho más importante para un barco que vuela durante varios meses/años donde la conservación de la energía es posiblemente mucho más crítica (puede tener paneles solares o reactores nucleares, pero incluso ellos tienen sus defectos). Además, es probable que un buque de carga tenga varios sistemas vinculados en lugar de una sola computadora monolítica, ya que diferentes buques tendrán sistemas y plataformas radicalmente diferentes, cada uno con su propio control computarizado, que en la mayoría de los casos operaría de forma remota.

  4. Elitismo simple ("cualquier idiota puede jugar con GUI, CLI es para profesionales que saben lo que están haciendo")

    Si bien esto es una desventaja de CLI, lleva tiempo dominarlo y no hay sugerencias visuales para recordarle los posibles comandos (aunque todos los usuarios de CLI sabrán cómo usar /? o abrir una página de manual...). Esto puede ser una indicación de la experiencia de un piloto/miembro de la tripulación: puede darse cuenta mucho más rápido de que alguien que trabaja con un CLI sabe lo que está haciendo o adivina los comandos, lo cual es útil si va a confiar en él con operando su cámara criogénica...

Algunas referencias:

1: No discutamos hasta qué punto todo esto es correcto: es suficiente para influir en el estado del arte actual, incluso si se basa en una falacia. Tenga en cuenta que la web está llena de argumentos e incluso guerras de fuego sobre este asunto...

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
"es fácil escribir a ciegas, por lo que no tiene que mantener la vista en el monitor en todo momento" Esto es al revés. El punto sobre la escritura a ciegas (mejor nombre: escritura táctil) es que no tienes que mirar el teclado . Por lo tanto, la oración correcta sería: "Es fácil escribir al tacto, por lo que puede mantener la vista en el monitor en todo momento, detectando y corrigiendo los errores de inmediato a medida que aparecen ante sus ojos". (Este comentario fue escrito en un teclado con todas las teclas en blanco...)
Con respecto a menos recursos del sistema, tal vez también sea más fácil proteger contra la radiación un microcontrolador del tamaño de un botón que un servidor de caja.
Creo que casi todas sus respuestas responden de manera más amplia a la pregunta de CLI sobre GUI en general en la actualidad, y todas son válidas con seguridad. Simplemente no puedo evitar pensar que en un futuro donde los humanos vivan fuera de la Tierra y atraviesen regularmente el sistema solar, probablemente habrá una forma de interactuar con la computadora de una nave a través del habla. Además, la GUI tiene más sentido si no todos en el espacio son expertos capacitados. No hay motivo por el que los técnicos no puedan seguir accediendo a la CLI cuando sea necesario.
@ben: Speech tiene sus propios problemas. Es mucho más complicado y "quisquilloso" que una GUI, más difícil de proteger con contraseñas, tiene problemas con las entradas y salidas de varios sistemas que se alimentan entre sí (por ejemplo, he oído hablar de una unidad de Amazon Alexa que hizo un pedido porque escogió un anuncio de televisión para Amazon Alexa, en el que demuestran haciendo un pedido), es más difícil realizar múltiples tareas y, finalmente, no estoy de acuerdo con su último punto. Si está pilotando una embarcación motorizada, cualquier embarcación motorizada, debe estar capacitado en su funcionamiento (automóvil, avión, embarcación, etc.).

He trabajado en aviónica de naves espaciales durante 17 años y participé en el sistema de gestión de datos de la última nave espacial ORION.

De hecho , usamos interfaces gráficas y, de hecho, las pantallas ORION se basan en las pantallas y controles de la cabina del Boeing 777:

Imagen de la cabina de la nave espacial ORION

Los CLI generalmente son una mala idea para el control en tiempo real, ya que es demasiado fácil escribir mal un comando o usar las unidades incorrectas (trabajé en un proyecto en el que un operador ingresó el ángulo del comando en grados en lugar de radianes y perdí una nave espacial de $ 500 millones).

Así que usa GUI con pantalla táctil todo lo que quieras... es lo que yo usaría.

Los ingenieros prestan atención al diseño de pantallas y hay mucha literatura sobre el tema. Esto puede proporcionar una guía de alto nivel que podría usar en su historia: leyes de diseño para pantallas de cabina universales

Interesante. Sin embargo, no creo que esto realmente responda la pregunta. ¿Puedes elaborar más?
@Vylix Esta es más una respuesta del tipo "su premisa es defectuosa" que una que intenta proporcionar una solución detallada a la pregunta. En ese sentido, no diría que esta no es una respuesta, sino que señala un problema en la pregunta: no sabemos por qué el OP quiere lograr su objetivo declarado.
@Frostfyre, ¿cómo haría para aclarar el por qué en mi pregunta? ¿O no debería preocuparme por eso?
@dot_Sp0T Normalmente, eso se haría a través de una edición, pero no creo que haga mucha diferencia en este punto. Alternativamente, podría hacer otra pregunta en la que pregunte si la solución que ha ideado tiene una mejor alternativa y vincular las dos preguntas. Esto funciona si no es por un punto de la trama; eso (probablemente) estaría fuera de tema.
Estoy de acuerdo con Vylix, esta respuesta necesita más elaboración.
Esa anécdota de grados/radianes suena más como un caso de mal diseño de software que cualquier otra cosa. Poner que quiero ajustar el ángulo de algo como un propulsor de navegación en 10 grados debería hacer que el software se ajuste ("¿qué quieres decir con 10 radianes? Girar en círculos probablemente NO sea lo que quieres").
Idealmente, el software debe requerir el ingreso de las unidades, y luego realizar cálculos a partir de ahí o simplemente rechazar la entrada (por ejemplo, "10 grados" se convierte internamente a 0,1745 radianes antes de actuar, o arrojar un error "esperaba 'rad', obtuvo 'deg' - "Oh, claro, esta cosa quiere entrada en radianes " hace matemáticas, vuelve a ingresar el valor correcto )
Desprecio la votación negativa basada en "responder la pregunta como se le preguntó". SIN EMBARGO: !) Orión no es un hábitat espacial; no estará, a largo plazo, lejos de las instalaciones de reparación, por lo que si uno de esos elegantes sistemas de pantalla se rompe, solo se romperá hasta el próximo aterrizaje. 2) Scripts para comandos complejos 3) No sé si Orion depende del control terrestre; podría ser que todo lo que el piloto esté haciendo sea hacer clic en "hacer el siguiente paso" o "sí, todo está listo".
No puedo evitar sentir que el viaje espacial interplanetario no es inherentemente en tiempo real. Está mucho más cerca de programar su videograbadora, nuevamente, en lo que hay mucha literatura. Para un programa/script, no desea ninguna ambigüedad, que los gráficos pueden generar fácilmente.
Quizás la respuesta sea que los humanos no se utilizan para el control en tiempo real. Digamos que las batallas espaciales terminan en 50 ms. Luego, los humanos podrían pasar su tiempo ingresando una estrategia en la computadora a través de una CLI, y esperar que la estrategia que ingresaron fuera mejor que la de sus oponentes porque con GUI o sin GUI no tendrán la oportunidad de modificarla en tiempo real.
Si bien estoy muy a favor de la terminal para el trabajo, estoy completamente de acuerdo con esta respuesta, ya que el punto decisivo en mi opinión es que la terminal no es adecuada para mostrar la información necesaria para navegar en una nave espacial (o cualquier tipo). Los humanos pueden captar información visual mucho más fácil y rápidamente que la salida de texto. Una vez que tenga las pantallas, tiene sentido vincularlas a los controles.

Las GUI de pantalla táctil pueden ser raras en las naves espaciales debido a la dificultad de usarlas en los guantes del traje espacial. Las interfaces de mouse y touchpad también son un problema, pero no tan malas. Estos son problemas reales, del mundo real, que no son de construcción de mundos. Usarlos requiere un lápiz óptico diseñado para usar con pantallas táctiles. Una interfaz de texto con botones físicos reales sería una mejor opción en comparación con requerir que todos lleven un lápiz óptico (o un botón de empuje Soyuz).

Antecedentes: Soy un apicultor aficionado. Tratar de tomar fotos o videos con un teléfono de pantalla táctil es imposible con guantes de apicultura normales. Un lápiz óptico funciona junto con un botón de grabación Bluetooth que tiene un interruptor físico real.Stylus y botón disparador remoto.

Además, el texto puede ser más fácil. Piense en todas las personas que usan sus teléfonos para enviar mensajes de texto más que para hablar.

¿Alguna vez has intentado escribir en un teclado con guantes? Necesitaría teclas cuadradas de +1" para trabajar con esos guantes. Busque en Google "guantes capacitivos táctiles" y verá que existen guantes para usar pantallas táctiles. De hecho, la NASA los tiene para los astronautas: cnet.com/news/ ... Además, el texto no es más fácil, es más privado en los teléfonos Una conversación de audio de 30 segundos transmite más información que un texto que tardó 30 segundos en escribirse.
El lápiz óptico es necesario solo porque la pantalla es capacitiva, cuyo tipo es incorrecto para su caso de uso. Esta misma característica lo hace sensible a las gotas de lluvia u otros líquidos. Las pantallas táctiles diseñadas para usarse con "lo que sea" o "donde sea" tienen sensores resistivos que pueden operarse con cualquier objeto que literalmente puedas arrojarles.

Control remoto

La nave espacial se puede controlar a distancia. Debido a las distancias involucradas, a veces el ancho de banda es pequeño y el retraso es enorme, por lo que un protocolo basado en texto de bajo ancho de banda tiene mucho sentido. Por lo tanto, la línea de comando ssh sería una opción natural. El control remoto es una característica imprescindible en muchos casos de uso:

  • El jefe de la compañía tendría acceso a la raíz y podría configurar el piloto automático de regreso a la base de operaciones si la tripulación decide robar la nave ... La tripulación también podría usar la anulación remota si otra persona roba su nave.

  • El transbordador del equipo de tierra se descompone, quedan varados en un planeta mientras que el piloto a bordo de la nave en órbita tiene una indigestión xenomorfa y no puede responder. Deben programar el transbordador de respaldo para salir de órbita y aterrizar.

  • Una vez de vuelta en la nave, después de que Leeroy se sacrifique valientemente para retrasar a los xenomorfos que se arrastran, ser capaz de regresar rápidamente al transbordador, irse y activar de forma remota la ventilación de la atmósfera parecerá una gran idea.

Otra ventaja de ssh es que puede usarlo desde prácticamente cualquier hardware sin instalar un cliente específico para su nave. Siempre que tenga credenciales de autenticación, funcionará. Puedes usarlo desde un bar, desde un cibercafé... bastante útil cuando te despiertas desnudo y robado a ciegas en un callejón en Omega y necesitas decirle a tu nave que envíe un dron para que te recoja...

Entonces esta línea de comando sería la forma nativa de controlar la nave. ¿Por qué inventar otro con campanas y silbatos? Ahora necesitarías aprender dos interfaces.

Flexibilidad

Ya que estamos hablando de pequeños empresarios, es probable que sus naves estén un poco oxidadas, con hardware reacondicionado, básicamente se las arreglarían con lo que puedan encontrar a buen precio. A veces, cuando un sistema se estropea sin posibilidad de reparación, necesita uno nuevo y no puede elegir lo que hay en stock.

Claro, si compra TODO su hardware del mismo proveedor, puede obtener una buena GUI, pero dado que su barco es un trabajo personalizado, lo más probable es que la GUI de cada fabricante no sea compatible con los demás. Tendrías que personalizar la GUI. También paga una licencia para usarlo desde tu teléfono. La gente simplemente no se molesta.

Y cuando quiere hacer que varios sistemas incompatibles cooperen... a menudo necesita scripts adhesivos. La línea de comandos es una muy buena opción para esto. También tiene sentido que muchas operaciones se escriban con un lenguaje de programación como python, por ejemplo. Piense en listas de verificación, autoevaluaciones, trabajando en una pieza de hardware defectuosa que no tiene suficiente dinero para arreglar...

No estoy seguro de su enfoque en SSH, no es más que un protocolo para cifrar el tráfico de datos entre el cliente y el servidor. Hay un montón de softwares gráficos que hacen uso de conexiones SSH para comunicarse con un servidor, así que si no te importa, me encantaría tratar de entender tu tren de pensamiento allí:/
La idea es que la línea de comando de texto use un ancho de banda muy bajo, se adapte a una alta latencia y el cliente sea estándar y pueda ejecutarse en cualquier cosa sin problemas. Si hace un túnel de GUI como xwindows sobre ssh, necesita mucho ancho de banda y baja latencia. Si usa un software personalizado para conectarse a través de un túnel ssh/ssl, entonces necesita instalar el cliente personalizado en el hardware que usa para conectarse.
Este argumento solo es válido bajo la premisa de que la conexión remota se limita a ser algún tipo de pantalla compartida. ¿Por qué la interfaz de entrada del barco no puede ser una GUI, la interfaz de entrada del control remoto puede ser una GUI (que se ejecuta localmente) y los (exactamente los mismos) datos (conjuntos de instrucciones) se transmiten al barco como lo harían desde los comandos CLI?
Los datos podrían transmitirse a través de cualquier protocolo concebible (por ejemplo, SSH o HTTPS) en cualquier forma concebible (por ejemplo, mensajes SOAP, JSON). No necesitaría ser un inicio de sesión de shell interactivo en absoluto.
... porque, ¿por qué alguna vez usó GUI para enviar mensajes binarios usando un protocolo bien diseñado para control remoto, verdad? Enviar mensajes de texto optimizados para humanos (si tienes suerte) es totalmente más razonable. Vamos, incluso los servidores SQL no envían los comandos de texto que escribes en SQL si pueden evitarlo, adivina por qué. Y funciona al revés también, como lo demuestra el hecho de que está utilizando la GUI de un navegador de Internet para enviar mensajes de texto a un servidor que no entiende nada más (y, de hecho, se puede interactuar utilizando exclusivamente un terminal ).
En el caso de mensajes binarios o protocolos personalizados, si su nave es un desastre de sistemas que compró en toda la galaxia cuando los anteriores fallaron, tendrá que instalar toneladas de aplicaciones del fabricante en cada dispositivo que desee. usar como control remoto... A menos que tengan interfaces web, que es la misma filosofía que ssh (cliente ligero).
Una mirada a los mensajes de IRC sin procesar le dice cuán importante y factible es embellecer los datos transmitidos.
Un control remoto para un televisor es más parecido a una GUI, mientras que es mucho más eficiente en ancho de banda que una sesión SSH.
El ancho de banda solo afecta la interfaz de usuario si la interfaz de usuario se pasa a través del ancho de banda. Si cada consola de interfaz se instala con la interfaz de usuario antes del lanzamiento, ya no necesita consumir ancho de banda en ella.
+1 por flexibilidad. Puedo imaginar un universo en el que cada planeta tenga un monopolio tecnológico local que diseñe y use un lenguaje ligeramente diferente que no sea interoperable con otros sistemas, mientras que todos usan lenguajes subyacentes iguales o similares. Puedo imaginar que los veteranos valorarían la interoperabilidad por encima de la facilidad de uso. ¿Quién quiere arrancar y reemplazar seis sistemas y enseñarles cómo funciona su nave cuando simplemente puede cambiar un controlador de mano averiado y hacer que hable el lenguaje informático básico que todos hablan?

Las GUI brindan los comandos fáciles de ' Lo que creemos que querrás ', las terminales son donde el usuario le dice a la computadora lo que quiere

No tendrá que hacer clic para llegar al botón que desea o esperar a que se carguen las imágenes, simplemente escriba lo que desee en la terminal. Piense en cualquier configuración que desee cambiar, debe abrir el panel de control (en Windows), obtener las opciones relevantes, hacer clic en esa, encontrar cuál de las que desea cambiar, cambiarla... esto es bueno si no sabe exactamente qué hacer o cambiar, pero es bastante largo cuando podría decir sudo date --set "12 Nov 2017 14:56:00"y obtener el mismo resultado.

Por supuesto, esto también hace que sea mucho más difícil para otras personas usar tu nave. Tal vez en algún momento hubo competidores volando en sus naves GUI y pirateando... solo lleva un tiempo descubrir los comandos necesarios, por lo que vale más la pena robar otras naves... y así su exitosa empresa surgió de la competidores.

El 'clic' en el que basas tu argumento es una especie de falso positivo. Las herramientas de línea de comandos también pueden requerir navegar a través de menús o subprogramas para llegar a la funcionalidad deseada, por ejemplo, eche un vistazo a la herramienta de Windows ' netsh ', el proceso de diseño de una herramienta de línea de comandos también necesita suposiciones de lo que querrá. al elegir letras para cosas como banderas o atajos. También se puede diseñar una GUI en torno a un principio de profundidad máxima , por ejemplo, cualquier menú no tendrá más de 3 capas (o incluso 2)
Me gusta pensar en CLI a medio camino entre una GUI y una IA. Le dices a la computadora qué hacer, pero tienes que hacerlo en el lenguaje de las computadoras.
@sdfgeoff en ese sentido, básicamente podría llamar a cualquier cosa que haga una computadora a medio camino de una IA ... después de todo, todo lo que hace una computadora es solo lógica creada por una persona para ejecutarla más adelante. Ejecutar un comando CLI simplemente decirle a la computadora que ejecute este conjunto específico de lógica, que Bob escribió en un lenguaje que la computadora entiende hace 15 años.
Es fácil pensar que las herramientas de línea de comandos le brindan "todo", pero también le brindan "lo que creemos que querrá". Una interfaz basada en menús puede brindar tantas opciones como una utilidad de línea de comandos, solo que los programadores a menudo son demasiado perezosos para brindar todas las opciones. Además, los programadores tienden a ser "mecanógrafos" y tienden a pensar que todos los demás también lo son. He estado programando durante más de 20 años, y si pudiera encontrar un buen IDE controlado por menús para hacer mi programación por mí, lo estaría usando. Por cierto, ¿por qué crees que a la gente le gusta tanto el autocompletado? ¡Odian escribir! :-)
Es más que los metacomandos están bien establecidos en las CLI, por lo que si lo que desea hacer se puede componer de múltiples comandos existentes (por ejemplo, ejecute este comando una vez en cada archivo en este directorio, concatene las salidas juntas, filtre eso a través de ese otro comando con estas opciones, etc.), entonces a menudo no es demasiado doloroso hacerlo en una CLI. Mientras que con una GUI tales meta-comandos no suelen existir (a menos que esté trabajando en un lenguaje de programación visual), por lo que se debe hacer clic en cada paso manualmente. Los comandos individuales no son inherentemente más flexibles con CLI o GUI.

Lamento ser negativo aquí, pero mi única respuesta posible es:

No lo harían, a menos que todas las tecnologías de visualización fueran imposibles.

Un mensaje de texto es ideal para la piratería ad-hoc. No necesita pensar mucho en la usabilidad, porque no hay usabilidad. Es el mínimo común denominador. Como mínimo común denominador, es fácil juntar cosas, pero no es absolutamente fácil de usar, incluso para los expertos.

Tan pronto como necesite hacer algo donde los resultados deban verificarse y validarse por seguridad, o simplemente donde personas que no sean un "experto designado" necesiten operar los sistemas, un mensaje de texto simplemente no es suficiente. Las interfaces de usuario anteriores usaban sistemas de menús simples basados ​​en texto para evitar esto. Las PC han desarrollado una GUI con ventanas y un puntero de mouse, pero que está fuertemente orientada a los botones físicos. Las pantallas táctiles han continuado esto con una GUI que emula aún más los botones físicos.

Incluso su "típica terminal Unix" se ha ido por este camino. El "terminal Unix" más común en estos días es un teléfono Android. Después de eso, está buscando decodificadores, enrutadores wifi, televisores inteligentes y reproductores de DVD. ¿Usas mucho una CLI en tu teléfono? ¿ Alguna vez ha usado una CLI en alguno de estos dispositivos? ¿ Sabías que tenían alguna versión de Posix OS? Caso probado, me temo.

Arthur C Clarke dijo : "Cualquier tecnología suficientemente avanzada es indistinguible de la magia". En lo que respecta a las UI, la clara implicación de esto es que una CLI no está lo suficientemente avanzada. Incluso con el desarrollo de Linux, una década más o menos de trabajo de interfaz de usuario, con frecuencia por parte de aficionados, ha sido suficiente para que evolucionen algunas interfaces de usuario razonablemente competentes.

Así que volvamos a esa advertencia. Si las tecnologías de visualización son posibles, una GUI SIEMPREexistir, incluso si tiene que ser creado por aficionados en su tiempo libre. Una GUI solo no existirá si es físicamente imposible que exista. ¿Por qué su civilización espacial podría no tener ninguna tecnología de visualización? Honestamente, eso tiene que ser algún tipo de extraña justificación manual dentro de tu trama, y ​​realmente no podemos ayudarte con eso. Tiene que ser tan fundamental para su universo que la física y la electrónica básicas se descomponen, y eso influirá fundamentalmente en su historia. Sin embargo, sin esa justificación manual, su historia se verá extrañamente anticuada cuando esté atrapada en CLI-land, de la misma manera que todas esas historias de ciencia ficción de la Edad de Oro con robots que funcionan con grabadoras y válvulas, o películas de 1960 con almacenes llenos de luces parpadeantes. .

(Editar para agregar suposiciones: supongo que se requiere la entrada del usuario con los dedos/tentáculos/apéndices, y las interfaces cerebrales/neuronales directas no son posibles).

Probablemente debería arreglar sus términos. IU es un término que describe un medio de interacción entre un usuario y algo interactuable (por ejemplo, una pantalla táctil para su teléfono o una manija de puerta para... una puerta).
@ dot_Sp0T Gracias: se perdió la "G" inicial en la última oración.
Ojalá pudiera votar esto más de una vez.
Estoy mayormente de acuerdo con esto. Pero hay una cosa para la que sigo usando la API de comandos de Unix (en una MacBook), y es para hacer las cosas a mayor escala. Como, "mover todos los archivos png cuyo nombre comience con 'prueba' a un directorio especial". Y mucha manipulación de texto: "seleccione la segunda columna de este archivo CSV". Ese tipo de operaciones son casi imposibles de hacer con una GUI. Así que tengo que decir que siempre existirá una CLI, incluso si tiene que ser creada por aficionados en su tiempo libre.
@fishinear Estoy de acuerdo, y no tengo ninguna objeción a una CLI que generalmente existe. Como usted dice, está bien para piratear rápidamente algo para una necesidad temporal específica. También es una buena manera de que los sistemas interactúen, porque los scripts que consisten en líneas de texto son fáciles de administrar. Con lo que no estoy de acuerdo es con el concepto de CLI del OP como una forma en que las personas pueden hacer su trabajo diario normal, porque tenemos amplia evidencia de cuán lento de usar y propenso a errores es.
@Graham define el trabajo diario en una nave espacial si no te importa. Además de revisar todas las lecturas cada pocos días, no hay mucho que hacer en mi comprensión de los viajes espaciales...
@dot_Sp0T Consulte la carga de trabajo de los astronautas de la ISS o las tripulaciones de los submarinos. Cada falla es potencialmente fatal, porque el medio ambiente quiere matarte. Ahora, podría suponer que la mayor parte de esto está automatizado, pero si ha sido automatizado, entonces tiene un diseñador, por lo que habrá una GUI para él, no una CLI. (O botones y diales físicos, pero la tendencia de alejarse de estos hacia la cabina de vidrio es clara). Y si no está automatizado y necesita atención humana regular, nuevamente necesita algo más que una CLI para que los humanos puedan interactuar con él. efectivamente.
@Graham, por lo que entendí, los astronautas de la ISS verifican principalmente los diales y los números para asegurarse de que correspondan a los valores que deberían; y mantenimiento de cosas viejas y nuevas, pero no soy un experto en ISS. Además, no creo que el espacio signifique daño para nadie ... Aparte de estos puntos, tiene mucha razón, solo esperaba obtener una lista interesante o similar.
@ dot_Sp0T Sí, hay diales físicos, donde tienen sentido. Sin embargo, todavía no hay CLI. La mayor parte del monitoreo en la ISS en realidad ocurre en tierra, en pantallas; e incluso en la ISS hay una gran cantidad de computadoras portátiles.
@ dot_Sp0T Un entorno peligroso no tiene por qué querer matarte. La muerte es simplemente el estado predeterminado en ese entorno, y por cada segundo que no quieras morir, debes prevenir activamente tu muerte. Los mismos principios se aplican al buceo.
"No necesita pensar mucho en la usabilidad, porque no hay usabilidad". Claramente , no está utilizando una CLI a diario. De lo contrario, sabrá que una CLI puede ser mucho más útil que una GUI para un experto . ¿Alguna vez se preocupó por conocer las diez palabras más frecuentes en su archivo de texto? Pues un "simple" cat <file> | tr ' ' '\n' | sort | uniq -c | sort -n | tailte lo dirá. Este tipo de combinación simple de primitivas simples para formar comandos complejos y significativos es en lo que suelen fallar las GUI. El usuario promedio de GUI simplemente no puede determinar las palabras más frecuentes en textos extensos.
Lo siento, pero la idea de la GUI como el destino natural es simplemente incorrecta. Un gran ejemplo es la administración del servidor web: en primer lugar, el alojamiento compartido económico puede tener paneles de control gráficos fáciles de usar, pero cualquier host por el que valga la pena pagar también proporcionará acceso a archivos de configuración y una línea de comandos porque es más poderoso . Y en segundo lugar, Microsoft realmente fue por el otro lado: tenían una GUI madura y completa, pero invirtieron en PowerShell porque los usuarios consideraban que la GUI era una carga y querían el poder de la línea de comandos que les brindaban otras pilas de tecnología.
@cmaster Como desarrollador de software, no solo uso la CLI, sino que la configuro . Soy muy consciente de las limitaciones de una GUI. También soy consciente de las limitaciones de la CLI. Los usuarios de CLI simplemente no necesitan hacer ese tipo de operación minuto a minuto. Por supuesto, incluya una CLI para casos oscuros y difíciles de cubrir, claro, pero no pretendamos que sea la mejor manera de mover y copiar archivos, editar texto o imágenes, o cubrir las interacciones con su PC/teléfono/tableta que ocupan 99 .some% de su día.
@IMSoP No, es porque no existe una buena GUI para esas funciones. Esos servidores suelen estar basados ​​en Linux (o * nix de alguna descripción), y la falta general de calidad en las GUI de Linux se reconoce universalmente como la razón por la cual Linux todavía no tiene una penetración real en el mercado de escritorio. En cuanto a PowerShell, no está ahí para que los usuarios escriban cosas a mano, está ahí para hacer que las operaciones se puedan ejecutar mediante secuencias de comandos. No tengo ningún problema con eso, pero el punto de las secuencias de comandos es que debería eliminar la necesidad de que el usuario escriba cosas. ¿Por qué? Porque es lento y propenso a errores.
@Graham No estoy de acuerdo. Para una tarea de cierta complejidad, cualquier interfaz gráfica de usuario suficientemente potente sería más compleja que una interfaz de línea de comandos. Creo que la respuesta de Ville Niemi se acerca mucho más que la suya: algunas tareas son adecuadas para una GUI, pero esas son las mismas tareas adecuadas para la automatización; el ajuste experto requiere acceso a docenas de opciones y valores, y una pantalla llena de casillas de verificación tiene menos facilidad de uso que un lenguaje de configuración expresivo. Dado que menciona las secuencias de comandos, eso hace que una CLI sea más fácil de personalizar que una GUI, también útil para expertos.

Robustez, peso e interacción a través del habla

Un panel LCD grande (necesario para una GUI utilizable) es más propenso a sufrir daños. Ya sea físicamente (objetos sueltos volando alrededor) o por radiación.

Un gran panel LCD ocupa un espacio valioso que se puede utilizar para otra cosa. Módulo de ciencia, carga, punto de montaje de velcro, etc.

Una CLI puede ser mucho más pequeña y, por lo tanto, más liviana. El peso siempre será un factor importante al diseñar naves espaciales.

Tener dos pantallas más pequeñas podría agregar redundancia y en ubicaciones más convenientes (una junto a la esclusa de aire/ventana de observación, una junto al módulo de hábitat en el otro extremo de la nave espacial)

Una CLI se puede ampliar fácilmente con una interfaz de texto a voz, por lo que ni siquiera necesita poder ver la pantalla para interactuar con ella. También puede reducir los errores utilizando más de un sentido (vista, tacto, oído).

Texto a voz con reconocimiento de voz puede ser útil si el teclado se rompe o no se mantiene.

La restricción de una CLI puede ser un beneficio en el sentido de que puede obligar al diseño a apegarse a un conjunto pequeño y estricto de reglas. Por ejemplo, los comandos siempre siguen el patrón Verb Noun Value(s)y los comandos se pueden encadenar (para obtener más información, consulte Powershell ). Esto puede hacer que un sistema complejo sea mucho más intuitivo/predecible; útil en situaciones de alta presión.

No estoy seguro de llamarlo "intuitivo". (Tampoco es que las GUI sean necesariamente "intuitivas"). ¿Quizás "reconocible" o "predecible" sería un mejor término?
Texto a voz ! ¡Una solución fácil y sencilla! sin necesidad de manos, sin necesidad de ojos, permite al usuario hacer cualquier otra cosa al mismo tiempo. Puedo imaginar a los usuarios simplemente hablando con la nave para pedir instrucciones: "¡Nave, nos vamos a Júpiter! ¡Y dile a mi esposa que voy para que pueda preparar mi lonchera!"
La robustez y la radiación son las mejores razones para no usar una interfaz gráfica, pero incluso esas pueden superarse. En cuanto a "más pequeño y más ligero", los botones se vuelven pesados ​​​​rápidamente. Su teclado de escritorio promedio es más pesado que la mayoría de las tabletas. Una GUI puede cambiar pantallas rápida y fácilmente, por lo que son mucho más compactas que algo físico. Y Star Trek muestra que el comando de voz también funciona bien con las GUI.
@everyone Cuando una computadora pueda analizar "Cap Ten y mi caftán gritó el capitán desde el cabrestante", confiaré en la interfaz de voz. Hasta entonces, las aventuras de auto-(mal) hechizo sirven como cuentos de advertencia.
@pojo-guy si los humanos pueden construir hábitats espaciales y establecer colonias en objetos celestes como la Luna, estoy seguro de que algunos de ellos han podido mejorar nuestra tecnología de interfaz de voz actual. Ya tenemos un software de voz a texto bastante avanzado, aunque debo admitir que no es del todo perfecto, pero parece mucho más alcanzable que vivir en la Luna.
@pojo-guy Si la interfaz está limitada a algo como "Iniciar comando <Verbo> <Sustantivo> <valor> <unidades (opcional)> Finalizar comando que se lee usando texto a voz y espera un comando "Confirmar" i Pienso que incluso nuestra basura de Voz a texto se las arreglaría. Pero bueno, conviértalo en un punto de la trama si quiere...
@DarcyThomas: " Una CLI puede ser mucho más pequeña, por lo tanto, más liviana. " Realmente no estoy comprando eso. Seguirá siendo una pantalla LCD, por lo que la única reducción de peso sería su tamaño. ¿Por qué un sistema basado en CLI necesitaría usar una pantalla más pequeña que una GUI? Hay muchas ventajas de tener una CLI con más espacio en la pantalla. Puede ver la telemetría en tiempo real de varios sistemas. Y realmente no quiere arriesgarse a un bloqueo porque algún número crítico era demasiado pequeño para leer. ¿Por qué es más pequeño mejor para CLI?
@NicolBolas Énfasis en la palabra can . Seguro que una CLI con pantalla grande estaría bien. Particularmente para algo complejo como la planificación de vuelos orbitales. Sin embargo, podría diseñar una interfaz de usuario que use una pantalla de 4 líneas por 40 columnas con 6 botones (4 flechas, entrar y retroceder), que podría controlar todas las funciones principales en una nave espacial. Claro que sería más difícil de usar que un mouse con teclado completo y tres pantallas 4k, pero eso pesaría más. Entonces, una compensación de usabilidad / peso. Si fuera yo, diseñaría una gran CLI/GUI en la cabina y luego tendría un control de botón 4X40-6 en cada módulo de nave espacial
@DarcyThomas: " Seguro que sería más difícil de usar que un mouse con teclado completo y tres pantallas de 4k, pero eso pesaría más ". Si no tiene teclado, ya no es una CLI. Y esos 6 botones serían más livianos si no estuvieran allí, si en su lugar usaras una pantalla táctil. Entonces estaría hablando de algún tipo de teléfono inteligente, que es bastante liviano. Y las GUI táctiles aprovechan mejor el espacio limitado de la pantalla (no el tamaño de píxel, el espacio visible real ) que las CLI.
@DarcyThomas: Escribiste mal el enlace. Además, un buscapersonas no es una CLI. Y no hay razón por la que no pueda hacer un dispositivo de pantalla táctil que sea del mismo tamaño y más liviano.
@NicolBolas Lo desafío a crear una GUI utilizable que tenga el mismo tamaño (área) que este buscapersonas de la vieja escuela (si ignora el bisel y mueve el botón inferior derecho, para sentarse al lado del botón con el punto rojo). Una vez más, cada diseño es una compensación. También los botones táctiles pueden ser una ventaja sobre los de pantalla, en determinadas circunstancias; diga manteniendo el dedo en el botón de entrada (con una forma/sensación diferente a la de cancelar) mientras mira por el ojo de buey.
@NicolBolas No, pero podría diseñar una CLI que fuera del mismo tamaño que ese buscapersonas (pantalla + botones). ¡Recuerda que esto es WorldBuilding! No estamos buscando la mejor manera de hacer algo. Estamos buscando cómo hacer algo con un conjunto interesante de restricciones (y proporcionamos algunas razones interesantes por las que)
@DarcyThomas: si no tiene teclado, no es una CLI. Todo lo que está haciendo es crear una interfaz GUI sin un mouse. ¿Qué otra cosa harían las teclas de flecha sino moverse entre las opciones de un menú? He usado teléfonos celulares anteriores al iPhone; son solo GUI que no tienen mouse.
@NicolBolas Una interfaz que solo muestra unas pocas líneas de texto, usando una cantidad mínima de botones para ingresar comandos, puede ser mucho más pequeña y, por lo tanto, más liviana que una GUI completa.

Porque todas las operaciones en un entorno dado son muy importantes y necesitan una configuración cuidadosa.

Es mucho más fácil hacer clic en el ícono incorrecto que ingresar un comando sintácticamente correcto que no es lo que se pretendía.

La "Línea de comandos" es mucho más difícil de aprender y, por lo tanto, la popularidad de las interfaces "GUI", pero en el entorno dado eso no es un problema, ya que sus "empresarios a pequeña escala" seguramente conocen muy bien sus naves y es probable que acepten cualquier cosa . obligándolos a pensar antes de cometer un comando.

En el ejemplo dado, seguramente no les gustará "dormir" ninguna cita importante (orbital).

Editar : sé que este es un tema muy resbaladizo y muchas Guerras Santas se han librado bajo las banderas de GUI Fawkes y CLI_nt Eastwood, pero de todos modos aclararé mis pensamientos. Tengan paciencia conmigo.

La tendencia en general y de las Interfaces en particular, siempre ha sido la de hacer las cosas "más fáciles" para el usuario. Esto generalmente se considera una buena cosa, pero, como con todo , hay un precio a pagar y situaciones en las que este precio sobrepeso tiene alguna ventaja.

El "precio" específico, en el caso de las interfaces, es que una "fácil" requiere menos pensamiento y, por lo tanto, se puede usar mientras se está distraído, somnoliento, ebrio o no completamente concentrado en la tarea.

Aquí se debe hacer una nota especial sobre la CLI de Unix: el uso de comandos cortos (principalmente 2 letras, 3 si chocan) y las opciones de una sola letra se eligieron esencialmente para "evitar escribir demasiado" (y debido a las capacidades limitadas de análisis en el último 70, por supuesto). Así ya va por el camino de "hacer la vida más fácil" a los usuarios.

Los "empresarios a pequeña escala" citados en el OP seguramente serán personas muy hábiles que se preocupan poco por la facilidad y tienen todo el tiempo del Universo para hacer las cosas "bien". Para ellos, una interfaz "punitiva", que requiere una entrada precisa y redundante, es una bendición.

El ejemplo citado quedaría modificado en:

cryo set wakeup=time+2d
> Ambiguous input, did You mean 'cryo cell 0 set wakeup=current_time+2days'?
cryo cell 0 set wakeup=current_time+2days
> wakeup procedure scheduled for SOL3-1_37:4:12m-6:23:40-127812_79812301
> that is 2 hours, 25 minutes and 16 seconds before next scheduled task (filter cleaning).
> you have 15 minutes to enter cryo cell 0.

La idea general es que CLI no es necesariamente "estúpido" y, para cuando las condiciones de OP se hagan realidad, es muy probable que haya alguna IA de buena calidad disponible, pero nunca debe confiar en la "intuición" o las cosas dichas de una manera que no es perfectamente clara. acción, pero debe basarse en pruebas claras de que la persona sabe exactamente lo que está preguntando, y eso se hace mucho mejor por escrito.

Debido a que es tan fácil olvidar los comandos, los dueños de negocios querrán una interfaz simple para el usuario promedio. Pueden permitir que sus comandantes tengan/utilicen una utilidad de línea de comando, pero no los miembros de la tripulación más jóvenes.
En realidad no, solo hay una letra de diferencia entre rm -rf *y rm -rf /*. Entonces, la verdad es que, en realidad, es ridículamente fácil cometer errores en una CLI, ya sea por errores tipográficos, lecturas incorrectas o simplemente malinterpretar un comando. Supongamos que su tipo de sueño criogénico pretendía extender el tiempo en 200 s, y accidentalmente presionó "200 d" en su lugar. En la GUI, tendría que estar incrementando el botón "días" por accidente, y muy probablemente vería ese error antes de presionar "ir". En el CLI, simplemente está completamente jodido.
En realidad, si comete un montón de errores en una GUI, es una GUI horrible. Dicho de otra manera, si tuviera una CLI que solo acepta Brainfuck como entrada, apuesto a que comenzará a amar esa GUI
@computercarguy los únicos dos comandos que se espera que escriba el miembro junior están pegados con cinta adhesiva debajo de la pantalla. ¡Nunca te atrevas a entrar en algo diferente! Ni siquiera el comando help...
@Ángel: Y los comandos reales ni siquiera aparecerán en la lista, lo que obtendrán es un par de macros enlatadas con nombres como fixo scan. Entonces, incluso si escriben mal los nombres, no arruinarán nada.
@Graham Si usa rm como root, merece su destino.
@kingledion Claro, es solo un ejemplo. Sin embargo, los hechos siguen siendo válidos: es ridículamente fácil cometer errores en una CLI.

Un barco en el que toda la tripulación pasa la mayor parte del tiempo congelada se encargará por diseño de todas las tareas rutinarias automáticamente. Cualquier tarea que deba realizar la tripulación se deberá a un cambio inesperado e impredecible que el plan de vuelo original no pudo cubrir.

No es práctico construir una GUI eficiente que maneje todos los posibles eventos inesperados e impredecibles. Es mucho más sencillo dar a la tripulación acceso directo a toda la configuración que no está cableada. A menos que estén usando un lenguaje de programación gráfico, lo que parece poco probable, esto significa texto. Es posible crear una representación visual o verbal de todos los datos de configuración y el código del sistema y permitir que los usuarios interactúen con eso en algún tipo de VR, pero no estoy convencido de que sea mejor que usar solo texto.

Así que usar texto tiene sentido.

En cuanto a una CLI real, podría argumentar que un sistema tendría dos modos. Un editor de texto completo donde puede editar los datos de configuración y el código fuente y luego confirmar los cambios y una CLI que le permite realizar pequeños cambios sobre la marcha con protecciones adicionales para la estabilidad del sistema. Incluso sería razonable suponer que el editor de acceso completo estaría fuertemente restringido a personas autorizadas y solo estaría disponible en vuelo durante emergencias, por lo que usar CLI sería la norma.

Esto aún le daría a la tripulación acceso a toda la configuración que se puede cambiar de manera segura durante el vuelo, lo que sería muy complejo de hacer con una GUI. Presumiblemente, la CLI también se asignaría directamente a los datos de configuración relevantes, por lo que el mismo conocimiento se podría utilizar tanto para la CLI como para el editor completo.

En realidad, este es un problema con las GUI en las que requieren que asigne un lenguaje localizado y fácil de usar a lo que realmente desea hacer (generalmente requiere Google o capacitación) o son tan arcanos como lo sería una CLI, pero con confusión adicional de navegar La interfaz. Verificar la sintaxis de los comandos es generalmente más fácil, especialmente si no tiene Internet o un asistente de IA.

Estoy de acuerdo en que el equipo necesitaría una CLI para ciertas tareas, pero no veo por qué este argumento excluye una GUI. La mayoría de las herramientas para manejar tareas técnicas complejas en la actualidad (p. ej., tableros del centro de comando de la NASA, IDE de desarrollador) tienen una GUI para mostrar una vista amplia del estado del sistema y realizar tareas comunes, combinada con una CLI para un control detallado. Esta tendencia ha evolucionado durante muchas décadas y diferentes campos de práctica. Una cuadrilla despierta para lidiar con tareas no rutinarias necesita analizar mucha información rápidamente para saber exactamente dónde y cómo intervenir; actualmente, esto se hace a menudo a través de la GUI.
Mi argumento fue que la automatización es tan extrema que la tripulación no necesita realizar tareas comunes. O control en tiempo real (mencionado en otra respuesta) porque el sistema no podía despertar a la tripulación lo suficientemente rápido, si se necesitaba algo así. Básicamente, la tripulación leía los registros del sistema de lo que sucedió mientras dormían y hacía cambios de configuración basados ​​en eso. Y dichos registros se referirían principalmente a errores inesperados o excepciones que el sistema no podría manejar automáticamente. Esto es muy diferente de los centros de control o los transbordadores espaciales porque el modelo de control es muy diferente.
La segunda etapa del argumento fue que es difícil hacer una GUI efectiva para manejar cosas raras e inesperadas mejor que una CLI. Básicamente, si los desarrolladores hubieran podido visualizarlo, la automatización habría solucionado el problema. // Obviamente no tengo idea de cuán realista es este argumento. Francamente, no hemos tenido computadoras durante el tiempo suficiente para que algo sea tan automatizado. Más que eso, esto requeriría que toda la nave espacial se entendiera a fondo como un sistema, por lo que tanto la computadora como la tecnología espacial tendrían que ser maduras y estables hasta el punto de estancamiento, en mi humilde opinión.
'"esto requeriría que toda la nave espacial se entendiera a fondo como un sistema"', precisamente. Leer los registros del sistema (¡meses o años valen si se sale de la estasis!) Es una forma terrible de comprender el estado actual de un sistema completo; intente leer un solo día de los eventos registrados de su sistema operativo en algún momento para determinar la actividad actual de todos los procesos en ejecución. Una GUI podría ayudar a reducir el enfoque rápidamente. --- Personalmente, creo que cualquier sistema complejo siempre tendrá GUI y CLI, cada uno se adapta a diferentes tareas.
@brichins Esa es en realidad una forma útil de pensarlo. Mi idea se basó en esa misma dicotomía y luego asumí que todas las "cosas de GUI" se han automatizado. Realmente no puedo ver otra forma en que las "cosas de GUI" desaparezcan y solo CLI se quede atrás.

Así vienen los barcos.

Los humanos no están usando naves espaciales que construyen, sino naves espaciales que encontraron y rescataron.

La novela Gateway (Frederick Pohl) tiene naves como esta, construidas por una misteriosa raza desaparecida, los Heechee. https://en.wikipedia.org/wiki/Gateway_(novela)

Hay casi mil pequeñas naves estelares abandonadas en Pórtico. Por ensayo y error extremadamente peligroso, los humanos aprenden a operar las naves. Los controles para seleccionar un destino han sido identificados, pero nadie sabe a dónde llevará el barco en un escenario particular o cuánto durará el viaje; el hambre es un peligro. Los intentos de ingeniería inversa para averiguar cómo funcionan han terminado en un desastre, al igual que cambiar la configuración en pleno vuelo.

El libro Beyond Heaven's River de Greg Bear se me queda en la mente debido a sus descripciones de las naves espaciales que usan los protagonistas humanos. Estos barcos son antiguos. Es más barato para los operadores independientes y los empresarios de poca monta soldar algunas sillas cómodas, pero aprender a usar estos barcos tal como están.

del libro

Alae golpeó un módulo de prueba en el panel y se abrió paso pasando a Oomalo, caminando por el pasillo ovalado hacia el antiguo centro de mando Aighor de la nave. Sus pisadas somos el único ruido. Quería taparse los oídos con las manos para esconderse del silencio. Un cuarto de siglo de rutinas había hecho que las decisiones fueran terriblemente difíciles. Oomalo lo siguió. Se sentaron en la penumbra de las consolas de control medio despiertas, oliendo el polvo y los frescos olores electrónicos. Sillas con forma humana habían sido soldadas a las placas del piso cuando la estación fue remodelada, hace treinta años.

La mayoría de los caminos y alojamientos se han diseñado para la ocupación humana, pero el centro de mando era muy parecido a lo que había sido durante los últimos 10.000 años. La luz de sus consolas brillaba con el mismo espectro elegido por los últimos Aighors para tripular la nave. Las pantallas extraterrestres indicaron que los motores inactivos todavía estaban funcionando.

…

La vieja nave sobrevoló el espacio-tiempo tan suavemente como un Leviatán a través de los mares árticos. Durante tres horas no hubo nada a su alrededor; el barco era su universo. Tenía al menos 10.000 años de antigüedad, de la tercera etapa de la civilización Aighor, y unos considerables 3 kilómetros de proa a popa. Lo habían comprado en una subasta a los mercaderes libres crocerianos.

Así también sus naves espaciales. Esta interfaz de línea de comandos (en un idioma extranjero) es cómo se encontraron. En lugar de intentar piratear y aumentar estas interfaces (con algún costo y un riesgo considerable de desastre), es más rápido, más barato y más seguro para los nuevos propietarios humanos adaptarlas y usarlas tal como son.

La GUI es muy superior a la CLI cuando se sabe con certeza razonable lo que hará, si la cantidad de opciones es pequeña (o el flujo de trabajo es siempre el mismo), si no importa gastar algunos recursos más y tener latencia adicional , y si la fiabilidad no es primordial.
En todos los demás casos, querrá CLI o cableado duro (que considero la forma más primitiva de CLI).

Si no puede anticipar lo que se necesitará, CLI es preferible ya que permite hacer cosas mucho más fácilmente que el diseñador de la interfaz de usuario no anticipó, básicamente CLI es casi como una forma primitiva de programación. Bueno, no del todo, pero se acerca.
No es que, en principio, no sea posible hacer prácticamente todo (incluso cosas imprevistas) con una GUI también, es mucho más difícil de diseñar y mucho menos sencillo.

Si se puede asumir el reconocimiento de voz (y probablemente se pueda), entonces la CLI también es mucho más "compatible" con ese tipo de interfaz. De hecho, uno puede servir como respaldo para el otro. Cualquier cosa que pueda escribir, puede decir, y cualquier cosa que pueda decir, puede escribir. Cualquier cosa que pueda leer, la computadora también puede decírselo a través de la síntesis de voz, si es necesario.
Eso es útil cuando, por ejemplo, se encuentra en una ubicación (haciendo reparaciones en el exterior, llevando un traje espacial) donde no hay disponible una terminal física, y mucho menos una forma de interactuar con una GUI (que no sea un HUD mínimo).

Los terminales tontos tienen la inmensa ventaja de que, en caso de falla, puede sacar un terminal de un lugar (posiblemente de un terraformador de 25 años en ese planeta que va a explotar en 17 minutos) y conectarlo a su motor principal donde todos los terminales han sido destruidos por, eh... una cascada de neutrinos, y hay muchas posibilidades de que "simplemente funcione". Incluso puede extraer la interfaz de red/serie/cualquiera que sea de una y colocarla en otra donde el monitor y el teclado todavía funcionan (de hecho, he hecho esas cosas con éxito hacia fines del siglo pasado).

Si su vida o algo aún más crítico (¿aterrizar una nave estelar con mil toneladas de armas biológicas en un planeta habitado?) Depende del resultado, entonces la forma más primitiva de CLI, un tablero de interruptores mecánicos y una palanca (o volante) es aún más preferible, por retro que parezca. Cuanta menos abstracción, mejor. Quieres un palo que haga que el barco vaya a la derecha cuando lo empujas hacia la derecha. No querrás agitar las manos sobre una proyección holográfica o tocar una flauta.

No desea chocar contra un asteroide porque dwm.exese bloquea o porque no puede encontrar el control lo suficientemente rápido. No desea retrasar innecesariamente el apagado de un reactor de emergencia durante 15 segundos mientras su pantalla muestra bolas giratorias animadas. No desea que las cámaras criogénicas sean expulsadas porque el gato caminó sobre la pantalla táctil ( realmente desea una palanca mecánica grande, roja, o un botón pulsador para tales cosas).

Además de otras respuestas,

GUI existe pero a nadie le importa

Aunque yo mismo soy un ingeniero de software, no creo que haya absolutamente ninguna interfaz gráfica de usuario en el espacio. Simplemente no es práctico. Pero... la mayoría de las veces la interfaz gráfica de usuario es una limitación.

Entonces, considere el viaje interplanetario regular. Hay varios aspectos en el trabajo que debe tener en cuenta la tripulación:

  • La gravedad podría afectar la trayectoria de la nave
  • La chatarra en órbita alta puede dañar la nave; hay que evitarlo
  • Cálculos complicados para obtener una vectorización correcta de la aeronave sin la ayuda del control de tierra
  • Lleve un registro del consumo de combustible y realice maniobras especiales para usar la gravedad y el impulso en lugar de quemar el combustible hasta que esté bien
  • Los astromecánicos necesitan un script que ejecutarán para hacer su trabajo dentro o fuera de la nave; deberás escribir un código para eso.
  • [inserte su motivo de ciencia ficción aquí]

Ok, ahora tenemos todas las complicaciones. La tripulación deberá guiar manualmente el barco de acuerdo con las condiciones externas y los objetivos actuales. Necesitará una GUI con cientos de botones y campos de entrada que no es mejor que una consola. Además, no hay necesidad de usar el viejo MS DOS, ¿verdad? Puede ser una CLI súper potente que admite un motor de secuencias de comandos Sci-Fython fácil de usar y permite a la tripulación escribir secuencias de comandos inteligentes de navegación y mantenimiento todos los días.

La GUI todavía se puede usar pero en modo de lectura para mostrar las lecturas. Es bastante conveniente ya que la mayoría de las partes importantes se pueden resaltar y trazar. Y es mejor que escribir "sys.fuel-monitor.getXXXparam()" de todos modos.

La mayoría de los factores ya parecen haber sido cubiertos aquí, excepto la naturaleza del uso de las computadoras, puede haber un lugar para las GUI en una nave estelar, pero no mucho.

  • Los cálculos sin procesar se escriben, no se hace clic en una GUI
  • Los cursos y las correcciones se escriben, no se hace clic en una GUI
  • Los períodos de tiempo se escriben mejor, no se hace clic en una GUI
  • Los informes de error quieren ser texto, no gráficos bonitos

Para su uso diario principal de las computadoras, las GUI simplemente no funcionan, la CLI es lo que desea y la GUI se interpondrá en el camino y ralentizará las cosas.

Hasta que el software de navegación llegue a un punto en el que simplemente haga clic en un destino en una pantalla desde un número limitado de destinos disponibles, CLI es fundamentalmente el camino a seguir.

Estás sugiriendo terminales tontas, pero ¿por qué no? En realidad, solo se necesita una sola computadora de a bordo (distribuida). Ejecuta todo y tiene terminales de acceso alrededor del barco según sea necesario.

La introducción de AI en realidad hace que una CLI sea más razonable. Si solo está hablando con la IA, entonces hacerlo en la línea de comando (aprobar cursos y correcciones y demás) es bastante razonable, en mi opinión.

Hay una razón funcional simple por la que podría preferir CLI a la GUI de entrada de cursor o táctil directa: vibración.

Controlar el cursor de un mouse/trackball, o incluso tocar la parte derecha de una pantalla táctil, es difícil si todo está temblando.

Incluso la entrada de voz es difícil si hay suficiente ruido (en algunas frecuencias, incluso un micrófono de garganta vibrará).

Sin embargo, un teclado tiene un descanso para anclar la palma de la mano, y el movimiento de los dedos en relación con eso es bastante preciso.

¿Alguna vez usó una computadora portátil en un avión temblando?
Si tiene problemas con la GUI, es porque la GUI está mal diseñada para la tarea, no porque la CLI sea la única solución.
Tenga en cuenta que los aviones de combate han logrado proporcionar GUI desde los años setenta. No necesariamente los opera con un mouse o trackball. En comparación, un teclado es voluminoso y está lejos de estar optimizado para su uso en entornos inestables.
Hemos estado haciendo interfaces gráficas de usuario durante un tiempo, y muchas de ellas todavía están mal diseñadas para la tarea, sea cual sea la tarea específica para la que fueron diseñadas. Casi ninguna GUI está bien diseñada para múltiples tareas, y las más flexibles siguen siendo esencialmente una colección de cuadros de entrada de texto embellecidos. El uso de GUI para control , en lugar de solo lectura, sigue siendo muy limitante
Alguien aún tiene que explicar por qué querrías una interfaz de computadora que te permita hacer "todo" en una nave espacial donde habría sistemas en los que absolutamente no quieres que nadie, usuario experimentado o no, pueda hacer lo que quiera. .
¿Por qué habría mucha vibración en el espacio? No hay turbulencia ni nada...
Sin embargo, tienes motores y cualquier otra maquinaria que tu nave necesite para mantenerte con vida: agítalos a mano para generar mucha vibración.

Estoy eludiendo un poco su requisito básico para llegar a un sistema plausible y consistente:

El manejo más eficiente de sistemas complejos y flexibles no es una GUI. Una GUI es brillante si tiene un número razonablemente bajo de acciones posibles y puede predecir bastante bien la ruta de comando típica que toma un usuario.

Entonces, algunos controles básicos serían GUI o controles de hardware. Puede doblarlo un poco y tender hacia los controles de hardware.

Cualquier cosa que necesite darle control total sobre un sistema complejo no será un sistema GUI. Incluso hoy en día, la administración seria de los sistemas de TI generalmente se realiza en algún tipo de interfaz CLI. Otras respuestas ya han explicado las ventajas de CLI sobre GUI.

Pero también admite gráficos vectoriales. Eso es perfecto porque muy a menudo una pantalla gráfica puede transmitir mucha más información que una salida basada en texto. Entonces, en esencia, tiene algo como Wolfram Language y esa es una interfaz perfectamente buena.

Entonces la respuesta es que sus naves espaciales usan este tipo de interfaces porque son la solución más adecuada para la tarea . Control total al alcance de la mano de un usuario capacitado, salida a través de texto o gráficos vectoriales, según lo que sea más adecuado, mejor usabilidad en el espacio (como se describe en otras respuestas). Para el contexto particular, la CLI ofrece una mejor relación entre ventajas y desventajas que la GUI, que tiene algunas ventajas, pero no las suficientes.

Recuerda que tu solución no tiene que ser perfecta, solo mejor que la alternativa.

La radiación y otros efectos ambientales dañan las computadoras . Tiempos más largos en el espacio acumularán ese daño. Dado que las computadoras son algo que sus barcos necesitan para funcionar, se preferiría la confiabilidad sobre la apariencia o el rendimiento. Especialmente porque las piezas de repuesto son difíciles de conseguir más allá de Júpiter.

Otra idea es que alguien ha inventado una computadora que no sufre daños por radiación (quizás una computadora mecánica "pequeña") pero que no obedece la Ley de Moore (es difícil mejorar el rendimiento más allá del poder de procesamiento de principios de los 80).

¿Por qué un sistema basado en gráficos es menos fiable que uno no gráfico?
@Bellerophon Probablemente podría argumentar (con grados razonables de éxito) que cuanto más código hay, mayor es el riesgo de que se introduzcan errores en la masa total del código; los sistemas gráficos requieren más código que los sistemas basados ​​en texto puro porque la presentación es más compleja, por lo que los sistemas con GUI tienen más código; de esto, se deduce que para una determinada cantidad de esfuerzo, el riesgo de, o incluso el número de errores, sería mayor en un sistema basado en GUI que en un sistema basado en texto.
Por supuesto, en nuestro mundo, hemos estado aprendiendo cómo abordar la creación de software para hacerlo más confiable a lo largo de la misma ruta que también ha resultado en un cambio de mucho software hacia las GUI.
@MichaelKjörling Cierto.
@Michael Una vez tuve una calculadora rota. Software uno. El integrado en Windows. Es solo una prueba anecdótica, pero he visto errores y ahora puedo tomar eso sin suspender la incredulidad.
@Bellerophon: porque en lugar de gastar la potencia de la CPU en la representación de las IU, se puede gastar proporcionando redundancia.
@Bellerophon Los circuitos integrados con características de mayor tamaño son mucho más resistentes al daño por radiación. Un solo transistor en el Intel 8086 original (3 µm) tiene 90 000 veces el área de superficie de un transistor en el núcleo de un Galaxy S8 (10 nm).

Los ingenieros son notoriamente malos en la construcción de GUI, pero por otro lado, el diseñador de GUI promedio no puede hacer despegar una nave espacial. La "razón" de la CLI es simple: los ingenieros que construyeron la nave espacial comenzaron con una CLI, como suelen hacer, y de hecho eso fue necesario para que la cosa funcionara en sus simuladores en la tierra.

Y sí, la alta gerencia sabe que realmente deberían contratar a algunos expertos en interfaz de usuario para arreglar eso, pero por el momento tienen una nave espacial volando. Y no es que haya mucha competencia en el mercado. Además, debe enseñar un CLI a todos sus pilotos. Pero, ¿cuántos estás entrenando? Claro, ahora estás entrenando a una docena de nuevos pilotos al año, en comparación con 1 o 2 cuando recién comenzaste. Pero ahora, reacondicionar toda la flota con GUI también se ha vuelto más costoso, por lo que la junta decidió adelantar esa decisión un año más.

TLDR: construir una GUI es la decisión correcta, pero tiene costos iniciales y la administración es miope.

Masa y costo.

Una pantalla LCD multilínea pequeña tiene menos masa y cuesta mucho menos que una pantalla gráfica LCD pequeña.

Cuanta más masa lleva un barco, más combustible necesita usar para moverse. Más combustible = más costo. Además, ¿por qué usar una pantalla costosa, cuando una pantalla simple y más barata es suficiente? Los costes se multiplican cuando hay que llevar varios repuestos. Las pantallas LCD multilínea también ocupan mucho menos espacio.

Una nave espacial no puede confiar en obtener su soporte técnico de la tierra. Por lo tanto, querrán al menos algunos programadores altamente calificados a bordo para garantizar la capacidad de operar y reparar las computadoras de la nave en cualquier situación.

Tiene sentido que estos programadores también sean los que interactúan regularmente con las computadoras. El capitán del barco no escribirá los comandos, solo dirá "programa un despertar para mañana" a uno de los técnicos.

E incluso en el mundo real, muchos programadores prefieren las interfaces de línea de comandos por varias razones. Una vez que hay suficiente inercia detrás del uso de CLI, los nuevos no tienen más remedio que seguir el flujo de trabajo establecido.

1) Para los sistemas cruciales, los controles físicos son mejores: puede palparlos en la oscuridad, no tiene que mirarlos para usarlos y muchos de ellos ni siquiera necesitan energía para funcionar. Todo lo que usaría una GUI recibe un control mecánico.

2) Todos los que tienen permitido ingresar al espacio pueden codificar. No se necesitan GUI.

3) Las GUI requieren pantallas. Las pantallas vienen en muchos factores de forma (¿resolución? ¿tamaño? ¿táctil? ¿color?). No desea depender de una parte en particular para una pantalla en particular.

4) Las GUI son una capa adicional de software sobre el software que realmente desea operar, es decir, una capa adicional de errores potenciales que no son de misión crítica. Ser asesinado por un error de "Evento no compatible con la codificación de valor clave" sería simplemente humillante.

5) Control por voz: es más fácil controlar una máquina con una interfaz de solo audio cuando se elimina la expectativa de retroalimentación visual. Me imagino a dos astronautas en una cápsula salvavidas dañada escribiendo una secuencia de comandos de texto para la unidad de navegación, en papel, y verificando dos veces, luego encendiendo el micrófono...

¿Por qué la tecnología dictaría que las interfaces gráficas sean raras en las naves espaciales?

Las GUI cambian con demasiada frecuencia y se basan en lo que el fabricante particular de ese dispositivo cree que es la mejor GUI. Desde una perspectiva tecnológica, vigilar posiblemente a cientos de fabricantes para que proporcionen una GUI consistente varía de difícil a francamente imposible. Cada uno de los fabricantes de sistemas operativos actuales proporciona especificaciones sobre cómo se supone que las aplicaciones deben verse y funcionar en su entorno, pero la mayoría de los terceros piensan que tienen una mejor manera de presentar la información y las opciones y toman una ruta diferente.

Esto solo empeora ya que a los fabricantes se les permite patentar apariencias o comportamientos particulares, lo que esencialmente obliga a otros fabricantes a idear su propio paradigma. es decir: esquinas redondeadas, deslizar hacia la derecha para abrir, mosaicos, etc.

Al basarse en texto, puede instalar comandos de varios fabricantes en el núcleo de la computadora sin preocuparse por el aspecto o las funciones de su programa en particular. Lo principal aquí es solo proporcionar referencias de parámetros a las que se pueda acceder fácilmente, lo que generalmente está integrado en los propios programas.

Tomando un punto de vista ligeramente diferente:
fácilmente podría imaginar que varias compañías están produciendo sus propias naves espaciales y los fabricantes de terceros quieren que sus dispositivos estén en ellas.

Hoy en día, es casi imposible que un tercero tenga exactamente la misma experiencia de GUI en varios dispositivos (iOS/Android/Linux/Windows). Sin embargo, si la aplicación es una CLI, es trivial que el uso sea casi idéntico. También es mucho más barato de producir y mantener.

Ahora, sigo pensando que es mejor usar GUI en sistemas centrales que requieren una operación inmediata o muy rápida, como los controles de vuelo, para aumentar los tiempos de reacción y reducir la posibilidad de errores humanos.

Compare esto con las CLI. No hay dos comandos de Unix que compartan el mismo diseño para sus parámetros, y otros sistemas operativos de línea de comandos (MS-DOS, Powershell, VMS...) tienen sus propias convenciones, al igual que los sistemas GUI.

Las GUI han evolucionado

En el futuro, las interfaces gráficas de usuario han evolucionado para completar entornos de realidad virtual inmersivos. Estos entornos de realidad virtual son absolutamente asombrosos para la eficiencia del trabajo y utilizan interacciones completamente novedosas, pero requieren maquinaria algo torpe y pesada (cápsulas/sillas de inmersión de realidad virtual).

El resultado es que un futuro adolescente promedio tendrá tantos problemas para usar una GUI moderna con un mouse y teclado, como para usar una CLI. Simplemente no tienen ni idea en ambos casos.

El resultado final es que al diseñar una nave espacial en la que el peso y el espacio importan y colocar muchas sillas de inmersión de RV no es una opción, simplemente eligieron CLI. No porque sean necesariamente la mejor opción, pero dada la necesidad de usar un sistema antiguo y engorroso, ya no les importa.

La ventaja de esto es que hace que sea muy probable que alguien se equivoque. Lo que a su vez, por supuesto, hará que los conductores de la trama sean hermosos.

Otros ya han señalado que CLI es muy rápido para un usuario capacitado, y es casi imposible hacer clic accidentalmente en el botón equivocado con los dedos torpes en los guantes de su traje espacial, o los dedos medio congelados después del sueño criogénico. Es cierto que escribir con los dedos medio congelados también te brinda algunos efectos interesantes, pero es más difícil escribir accidentalmente "autodestrucción" cuando querías una taza de café que hacer clic en el botón equivocado (y no me hagas empezar con las interfaces de usuario que se las arregló para poner botones en los arreglos más extraños).

Alguien también mencionó texto a voz.

Y, por supuesto, muchas cosas se ejecutan automáticamente y la computadora no hace clic en los botones, sino que ejecuta los comandos directamente.

Pero la pregunta era por qué la tecnología dictaría que las GUI podrían ser raras y la CLI podría ser un lugar común.

Creo que una respuesta plausible es un reconocimiento de idioma mucho mejor .

Con CLI hoy, necesita conocer la sintaxis exacta del comando, el orden correcto de los parámetros y otras cosas. Si lo hace, ningún usuario de apuntar y hacer clic con el mouse se acercará a su velocidad, pero si no lo hace, tendrá dificultades para ejecutar su comando.

Pero si el reconocimiento de idiomas evolucionó, y parece seguro asumir que lo hará, entonces perderá las desventajas de CLI. Escribes lo que quieres y la computadora lo entiende, traduciéndolo a los comandos "correctos".

Todavía tiene algunas GUI para aquellos casos en los que la información visual transporta los bits importantes mucho más rápido que el texto y los números, pero para interactuar con la computadora, simplemente escriba lo que necesita, lo entenderá y, si no está seguro, solicitará una aclaración.

Entonces, ¿por qué no la entrada de voz directa?

Puede ser por el ruido a bordo de la nave espacial. Pero lo más probable es que sea molesto cuando su estación de trabajo sigue ejecutando los comandos del colega a su lado.

Vibración

Eso debería ser obvio.

Sin embargo, hoy en día existen interfaces de usuario basadas en menús incluso en entornos con mucha vibración. Pero estos se utilizan para tareas secundarias o terciarias, no para funciones primarias. Intenta llegar a un destino alternativo en un mapa animado de pantalla táctil mientras tu nave espacial vuelve a entrar. O en su automóvil mientras conduce a toda velocidad por una carretera llena de baches. La interacción a través del habla (mencionada por DarcyThomas) puede ser una opción para tareas que no se procesan en tiempo de lectura difícil o cuando el entorno puede ser extremadamente ruidoso (vibración en el rango de audio).

Sin embargo, con tecnología lo suficientemente avanzada, la distinción entre GUI y "botones de hardware" puede comenzar a desdibujarse. Imagine una pantalla 3D táctil que pueda extruir controles duros a voluntad. Como un mando cilíndrico redondo cuando surge la necesidad de ajustar el volumen del intercomunicador o la temperatura del climatizador (este será bastante difícil de girar para que no se gire por error por vibración o toque accidental).

¿Por qué hay tanta vibración en el espacio?
Maniobras pesadas para esquivar el fuego láser y las naves espaciales que explotan. O el reingreso atmosférico (no todo el tiempo, pero una parte crítica al final de un viaje espacial: ¿la nave espacial contaría con dos conjuntos de controles, uno para navegar ociosamente en el espacio vacío y otro para situaciones difíciles? Bueno, podría ser, de hecho !), Y no querría presionar por error el botón de autodestrucción al alcanzar el botón de enganche de las abrazaderas de acoplamiento, en el caso de que la maniobra de acoplamiento tenga un poco de "baches" en el punto crítico. TL;DR aquí: trs.jpl.nasa.gov/bitstream/handle/2014/16247/…
Ese documento podría ser un poco más accesible para el lector casual: ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19880004228.pdf

En el futuro cercano, podríamos esperar que las "gafas" de realidad aumentada sean la norma. La GUI de antaño quedará obsoleta, al igual que la mayoría de las pantallas 2D. Las GUI operan en un plano bidimensional y son simplemente una traducción de nuestro mundo 3D y, como tales, son inherentemente defectuosas. En este futuro, los gustos de Google Glass y el Magic Leap imaginario permitirán la manipulación tridimensional del entorno. Si bien es inmadura hoy en día, espero que esta tecnología florezca rápidamente.
Imagine ver su sistema, en este caso el barco, en una imagen translúcida a escala 3D. El seguimiento de retina permite al usuario simplemente mirar la nave y el sistema se acerca de manera inteligente a las partes o comandos de interés en esa sección. ¿Quieres frenar el barco? Mira los motores. ¿Te importaría maniobrar un poco? Enfoque visualmente las boquillas de los propulsores. ¿Necesitas sellar un compartimento? Mire las puertas de esa sección en su modelo 3D. Esta representación 3D del barco tiene menús emergentes inteligentes con elementos de interés para la parte dada.
Siguiendo este experimento mental, no sería difícil imaginar una nave desprovista de todas las interfaces. Por ejemplo, puede caminar hacia una puerta y los comandos que puede hacer en la puerta aparecen en su retina: concéntrese en una opción para realizar la tarea.
Entonces, para responder la pregunta específicamente, las interfaces de tipo GUI no existen en el barco porque cada usuario tiene una mejor interfaz personal en su persona. Es probable que dicha tecnología no sea un dispositivo con cable o recargable, sino uno que se cargue a partir de alguna energía ambiental o directamente del cuerpo del usuario final. Por ejemplo, un solo ocular que se alimenta del pulso de la sien del usuario. O, si nos movemos más hacia el futuro, un dispositivo incrustado en el ojo que "pinta" imágenes con láser directamente en la retina. En cualquier caso, terminamos con una nave que no necesita interfaces en ningún lugar.

Los "Puntos de bonificación" para una terminal ficticia indican que la operación quiere algunas terminales, por lo que, según mi escenario anterior, la nave está atada con terminales ficticias por un par de razones...

  1. En la interfaz visual, podría ser difícil para el sistema "adivinar" lo que quiere hacer sin una IA sólida, aunque limitada. Por lo tanto, cualquier usuario puede caminar hacia una terminal ficticia y escribir comandos en la pantalla de su propio ojo para trabajar más rápido. es decir, existe la tipificación en el ojo, pero es demasiado lenta.
  2. Es posible que se necesite el dummy simplemente porque el sistema no es lo suficientemente bueno para su trabajo, por lo que necesita la participación personal del usuario en todo momento. es decir, no hay IA que ayude a mostrar lo que desea, las terminales son la forma en que navega por su mundo 3D en el ojo.
  3. Alternativamente, las interfaces ficticias podrían ser solo para redundancia. Como señaló otro usuario, podría existir una CLI, pero sería la forma "solo para expertos" de interactuar con la nave. No es que el ocular no pueda usarse en todos los casos, sino que el experto puede hacer rápidamente "esa única cosa"

Independientemente, el usuario final se convierte en el "disco" del sistema como quería el operador. ¿Nuevo usuario en la terminal? - disco nuevo. Cada vez que te acercas a la terminal, a ese usuario se le muestran los últimos comandos que realizó y comienza donde lo dejó... personalizado cada vez.

Me doy cuenta de que tal "interfaz ocular" puede seguir siendo una GUI en sí misma, pero ser personal para el usuario final los elimina de los barcos dejando terminales tipo CLI solo para expertos. Por lo tanto, esto aborda las preguntas del Op por completo. Espero que esto ayude, ¡buena suerte!

No estoy seguro de si su elección de la palabra 'ficticio' cuando se refiere a terminales 'tontos' es deliberada o por un malentendido, así que solo preguntaré aquí: ¿Sigue hablando de terminales tontos, por ejemplo, terminales conectados a un punto de acceso ? o similar que interactúa con su retinacomputerthing, o está hablando de terminales ficticias , por ejemplo, losas de metal que se superponen con alguna interfaz AR (realidad aumentada) cuando la miran con su retinacomputerthing?
Un malentendido, de hecho. Para responder a su pregunta, me imagino que podría ser una terminal tonta o ficticia, según las necesidades del autor. Si la computadora de la retina es lo suficientemente robusta como para no necesitar redundancia, entonces sería genial que apareciera una superposición en losas de metal específicas. Aunque creo que el operador imaginó botones físicos, imagino que la terminal sería una terminal tonta que espera al usuario final y luego activa una pantalla en el ojo. Supongo además, que si necesitáramos redundancia, la terminal tonta necesitaría una pequeña pantalla propia que se activaría en lugar de una pantalla retina.

Las restricciones tecnológicas probablemente no dictarán si los barcos futuros tienen herramientas GUI o CLI; las culturales definitivamente lo harán.

La tecnología se desarrolla (e instala) para satisfacer las necesidades humanas, que se basan en los requisitos comerciales/de la misión, e incluso en las preferencias personales de los propietarios y/o usuarios de la nave si las naves espaciales están ampliamente disponibles. Como lo ilustran todas las demás respuestas y comentarios que ha generado esta pregunta, está claro que las interfaces GUI y CLI tienen ventajas y desventajas.

Su universo necesitará algunos imperativos culturales o fisiológicos para impulsar el desarrollo hacia CLI y lejos de GUI. Algunos de los argumentos ya presentados pueden ser un buen punto de partida.

En el futuro, todos los astronautas deben haber contribuido a un paquete de Linux. ¡No más necesidad de GUI!
Después de que la ley de patentes se extienda por enésima vez, se vuelve altamente ilegal usar una GUI en una nave espacial sin el permiso de Engelbart. Por desgracia, Engelbart murió en 2013, por lo que obtener su permiso es... difícil.

¿Estás buscando razones más o menos lógicas que respondan a tu pregunta? Bueno, entonces no creo que encuentres ninguno.

Sin embargo, si su mundo está un poco en el lado de la fantasía, entonces podría crear alguna condición particular. No sé, tal vez una cosa cultural que hace que la gente odie los gráficos, tal vez una población que confía en la abstracción pura... No sé, podrías jugar con eso.

Sin embargo, si considera que este escenario es más evolucionado que el nuestro, entonces no hay forma de que pueda ofrecer un razonamiento lógico para esto. Debe comprender que CLI existió solo porque la GUI era imposible o muy compleja de hacer en momentos en que un byte era oro . Hoy en día... hay GUI para todo (sí, incluidos los servidores). De hecho, me preguntaba cómo es posible que la gente todavía use CLI sobre GUI .

Y este es nuestro estado actual del arte . Donde AI/MI está dando sus primeros pasos, lo mismo ocurre con AR . Y donde los recursos computacionales son casi ilimitados. Me imagino que las personas que realizan viajes interestelares son mucho más avanzadas que nuestro estado actual del arte.

Imagínese este caso de usuario: el piloto tiene que evitar una colisión con un objeto. ¿Preferirías presionar un botón o escribir una serie de comandos? O incluso mejor, ¿ dejar que la nave espacial haga lo que quiera porque las posibilidades de errores serán millones de veces menores que las de la interacción humana?

Bajemos a la Tierra. Solo imagine el mapa estelar y reemplácelo por los mapas de Google. ¿Escribes coordenadas o simplemente usas comandos como hacer zoom y hacer clic? Ahora, volviendo al espacio, y en lugar de un plano bidimensional (como un mapa de Google), piensa en un escenario de 4 dimensiones (¡oh, sí, recuerda que en el espacio también debes considerar el tiempo!) . ¿Ves lo que pasó? sus comandos CLI son literalmente imposibles, porque incluso si el piloto sabe distancias, no sabrá al menos una de las dimensiones (tiempo) y muy probablemente tampoco sabrá el eje Y. Algo que tomaría... 1 clic en un botón.

Tomaré el ejemplo de Goblin (que no debe confundirse con una puñalada en su respuesta, solo trato de explicar usando el mismo conjunto de comandos:

  1. comando 1: enumerar todas las entradas de carga para explosivos,

  2. comando 2: enumerar todas las bahías de carga en la entrada,

  3. comando 3: sellar todas las esclusas de aire de las habitaciones en la entrada, y,

  4. comando 4: enjuague con refrigerante de emergencia en todas las habitaciones en la entrada.

En las tecnologías avanzadas que están disponibles hoy en día, esto probablemente requeriría solo una entrada oral y un reconocimiento auditivo, o tal vez incluso nada (la máquina haría esto sin la intervención del piloto). Pero incluso los enfoques "más antiguos", como los más comunes hoy en día, requerirían solo un... panel de control . Hice uno rápido en menos de 5 minutos:

ingrese la descripción de la imagen aquí

Solo piensa en la imagen de arriba así:

enter what to search
show cargo with that input
offer available actions to user

Si bien soy un profesional de UX, ¡ no estoy ni cerca de ser un profesional de UX de una nave espacial! ¡Así que imagínese pensar esto a fondo con las pruebas adecuadas por parte de profesionales que conocen las posibilidades de sus tecnologías!

En breve

A menos que encuentre algún tipo de razón cultural o fuerce algún escenario sociocultural extraño, no creo que su pregunta sea lógicamente posible. Sin embargo, esto no significa que los comandos CLI deban ignorarse por completo. Podría tenerlos para comandos muy extraños y arcanos, o simplemente porque "los hombres de verdad no usan GUI"

..sus comandos CLI son literalmente imposibles, porque aunque el piloto sepa distancias, no conocerá al menos una de las dimensiones (tiempo) y muy probablemente tampoco conocerá el eje Y. Algo que llevaría... 1 clic en un botón... ¿ Ha pasado tiempo pensando en ese mismo argumento? ¿Por qué un 'botón de 1 clic' no debería ser igual a una 'entrada de 1 comando'? Y el mismo problema está presente en todos sus otros argumentos ahora que leo el resto. Su maqueta de GUI requiere una máquina de estado, la misma máquina de estado también se puede acceder y usar con una CLI; piense en GIT, por ejemplo.
siendo alguien que usa ambos a diario, sí, lo he pensado, es natural para mí. De nuevo, mapa de 4 dimensiones. El usuario toca una ubicación (tal vez se acerca) apuntando a un objeto en otro sistema solar. El objeto es una representación arbitraria, porque puede que ya no exista en ese lugar. Ahora la nave espacial puede ir allí. 1 botón 2 si quieres Haz eso usando la línea de comando y dime cómo te fue. ¿Cómo le explicarías a una máquina que quieres que vaya a un pequeño punto en la pantalla? Otros casos son posibles con CLI (nunca dije lo contrario), pero ¿quién haría eso y por qué?
tenga en cuenta que cuando digo un botón me refiero a una representación gráfica en una pantalla que admite un comando, no un botón mecánico
Su caso de uso solo es factible para objetos o ubicaciones que se han especificado/asignado de alguna manera. Usted afirma que ' El objeto... puede que ya no exista en ese lugar. ', por lo que las coordenadas aleatorias en el espacio se eliminan por definición. Ahora tenemos una lista de ubicaciones que podemos seleccionar en un mapa visual o de una lista. Por ejemplo nav plot-course Ganymede, y si hay varios objetos que se conocen como Ganímedes, entonces podría haber un filtro o algo similar.nav plot-course Ganymede -f Jupiter
No. Simplemente puede explorar una región y dejar que la máquina extrapole datos en función de muchos indicadores diferentes, algo que un humano no podría hacer y que las máquinas hacen todos los días. HOY EN DÍA. Esto no es nuevo en la ciencia ficción, simplemente puede tomar la Fundación de Asimov donde esto era bastante común y el piloto Golan Trevize usó lo que ahora llamaríamos un dispositivo viso-háptico. Y lo que puse es solo un mínimo ejemplo entre miles que podría dar. En serio, estás argumentando en contra de la historia de la humanidad y la tecnología. O todos están equivocados o deberías repensar tus argumentos
Una de las mejores citas que he leído sobre las GUI es de "Essential System Administration" de Aeleen Frisch: "Las herramientas [GUI] están diseñadas para operaciones de rutina en condiciones NORMALES del sistema, y ​​esta suposición está entretejida en su estructura, a menudo hasta el último detalle." Considere la opción de interfaz de usuario "sellar y enjuagar refrigerante": si, en una condición anormal, debe enjuagar solo el 25 % del refrigerante, o enjuagar sin sellar, o enjuagar con algo que no sea el refrigerante predeterminado, o comer una manzana mientras enjuaga... no puedes Las interfaces de usuario pueden representar E/S para un comando CLI, pero no para comandos encadenados arbitrarios.
@Devin Literalmente acabo de analizar tu argumento y aparecí donde no funcionó. En su último comentario, cambia la premisa para que funcione nuevamente, eso está bien. Pero no hace que otros argumentos sean 'inválidos' o similares, cambia la discusión en su conjunto.
@DewiMorgan ¿Alguna vez ha intentado acercarse a la ISS desde un gráfico que muestra la Tierra? Bueno, buena suerte en eso... El punto es que las dimensiones en el espacio son alucinantes, y las velocidades en el espacio lo son aún más. No podrá hacer zoom en nada en su pantalla pequeña que sea demasiado pequeño para ser etiquetado de antemano por su GUI, listo para hacer clic en él. Esto se traduce en una lista de como máximo una docena de entradas en la CLI. Sin embargo, la CLI puede enumerar fácilmente los nombres de miles de objetos y greppuede seleccionar fácilmente objetos interesantes de esa lista. ¡Hay una razón por la cual la CLI todavía está en uso hoy!
@cmaster ¿Estás seguro de que estás respondiendo a mi comentario y no, digamos, al de Devin?

Además de las otras respuestas, considere la ventaja de poder imprimir un registro de todos los comandos ejecutados y poder ver lo que sucedió antes de que la nave perdiera energía. podría leer

...
Lt. Jerry @ 12:30 11/13/2117: lifesupport --kill
...

que es más fácil de averiguar que mirando qué botones se presionaron y cuándo.

En una implementación práctica de esto, es más probable que el barco tenga una copia impresa "rodante" de las últimas horas de los registros, que sobrescribirá las entradas más antiguas con las más nuevas, en lugar de imprimir millas y millas de papel a lo largo de la vida. de El Barco.

Esta copia impresa sería casi exclusivamente para la situación en la que el barco pierde energía accidentalmente.

Además, normalmente cuando hay un error en una GUI: aparece como un cuadro de diálogo que desaparece una vez que lo cierra. La CLI le permite desplazarse hacia arriba y ver los resultados de los comandos anteriores, como errores.

no entiendo lo que tratas de decir
Si su barco tiene una falla, necesita un registro de eventos antes de la falla para solucionar el problema. Si el problema es un corte de energía, no tendrá acceso a los registros digitales. Una copia analógica del registro es una posible solución a esto.
¡Oh, se supone que es una declaración de registro!
Traté de modificar su respuesta para aclarar su punto. Espero haberlo hecho bien.
¡Lo entendiste! Hice otra edición solo por errores tipográficos y gramaticales.
Existen, incluso hoy en día, GUI que utilizan una capa de comando intermedia para controlar la lógica de la aplicación. Esto permite flexibilidad, secuencias de comandos, registro y, una vez que el usuario se cansa lo suficiente de la GUI, la operación directa de la línea de comandos. Sí, en la década de 1990, el "software de GUI-ification" estaba disponible para convertir la "pantalla negra" en algo "moderno controlado por mouse", pero hoy en día existe un software de última generación que utiliza el comando intermedio de texto sin formato. capa como principio de diseño. No debe confundirse con las bases de datos SQL: estas tienen la interfaz de texto en el nivel de datos, no en la capa de aplicación.

Nuevos requisitos del sistema e inercia

Hace muchos años, cuando se estaban desarrollando los sistemas actuales, se entregaron con interfaces gráficas con animaciones que mostraban el estado actual del barco, resultados de simulación e información general de diagnóstico. Poco después de que se introdujeran estos sistemas, todas las entidades gubernamentales y de certificación exigieron un nuevo requisito funcional práctico importante. Este requisito funcional

  1. Requiere mucha potencia de procesamiento
  2. Tenía que hacerse en tiempo real
  3. Implica una gran cantidad de álgebra matricial.

En lugar de gastar el dinero para diseñar nuevo hardware y modernizar/rediseñar las unidades existentes (el hardware clasificado para espacio es muy costoso), la potencia de procesamiento utilizada anteriormente para estas interfaces se redirigió hacia esta nueva funcionalidad. Esto sucedió a una escala lo suficientemente grande como para que prácticamente todos los barcos se convirtieran de esta manera. Debido a las razones mencionadas en la publicación de G0BLiN , y al no querer volver a capacitar a los espaciadores experimentados, las interfaces de línea de comandos se convirtieron en las predeterminadas.

Sugerencia alternativa

En lugar de una interfaz puramente basada en línea de comandos, los usuarios interactúan con un administrador de ventanas basado en mosaicos. Estas interfaces GUI están diseñadas específicamente para usarse solo con un teclado, pero pueden usar ventanas gráficas como cualquier otro sistema. Aquí hay una demostración de uno en acción: A Better Linux Window Manager: i3 Tiling Basics

Su Alternativa sería mejor publicada como una respuesta o comentario sobre la pregunta anterior vinculada.
El hardware de la computadora es extremadamente barato en comparación con los costos generales del equipo y la misión; incluso hardware con clasificación espacial. No puedo imaginar que el factor decisivo sea el precio de un par de GPU en lugar de la funcionalidad para los usuarios.

Además de las otras respuestas sobre la eficiencia de CLI para usuarios expertos, podría agregar otra consideración específica de la sociedad interplanetaria.

Las interfaces gráficas son culturalmente específicas y pueden no tener sentido para una especie alienígena que tiene una historia tecnológica diferente. Por ejemplo, usamos iconos que representan sobres para indicar "enviar" y disquetes para indicar "guardar". Incluso las personas que nunca han enviado una carta en papel o un disquete usado saben lo que significan porque han crecido en ese entorno cultural. Sin esa aculturación, puede ser difícil interpretar las imágenes. Incluso los signos más abstractos, como las flechas de movimiento, pueden carecer de sentido sin el entendimiento implícito de que las cosas se mueven hacia el extremo puntiagudo.

Por supuesto, el CLI también tendría que aprenderse, pero es un número limitado de comandos lógicos compuestos por un número aún más limitado de letras.

Puede haber otras diferencias físicas o neurológicas en la forma en que las diferentes especies perciben y procesan mentalmente las imágenes. La CLI está más cerca de una representación puramente lógica.

El infopocalipse en el siglo XXI fue brutal.

Los investigadores de IA desarrollaron un código automodificable que comenzó a resolver gran parte de los problemas del mundo. Coches autónomos, aviones, plantas químicas, cirugía: la IA resolvió casi todo.

Claro, allí donde los problemas. Ransomware y delincuentes informáticos en todas partes. La IA se implementó para resolver el problema de seguridad y los sistemas nunca parecieron más seguros. AI reescribiría el sistema operativo y los protocolos de red para hacerlo más seguro.

Los delincuentes respondieron de la misma manera con IA que intentó piratear los sistemas y, en breve, no pudo existir ninguna computadora sin protección. Incluso los espacios de aire podrían ser derrotados por las IA agresivas. Cada computadora, incluso las seguras, sería una batalla de IA amigable y segura contra IA criminal hostil, y algunas veces las cosas salían mal y cambiaban de bando.

Las cosas comenzaron a ponerse peculiares y se desarrollaron efectos emergentes. Se desarrollaron rituales aparentemente sin sentido para mantener su computadora "saludable" y "feliz", y nadie podía decir por qué funcionaban o incluso si lo hacían.

En el momento del infopocalipse, incluso los chips y transistores con los que se construyó una computadora fueron diseñados por IA con la seguridad en mente, ya que la IA de ataque podría usar la inseguridad en sus propios transistores para dañar el funcionamiento del sistema.

A la IA defensora se le pasó algo y llegó a todas partes. Un día, las computadoras dejaron de funcionar. Esto provocó un colapso económico mundial; millones murieron. Algunos directamente, ya que tenían hardware informático instalado en su software húmedo. Algunos indirectamente, como automóviles y aviones impulsados ​​por IA que se estrellaron. Y muchos de los daños económicos crudos y luchan por recuperarse.

Si construyó una nueva computadora con un nuevo diseño y un nuevo metal basado en tecnología de hace décadas, también estaba infectada. La IA atacante se había metido en las cadenas de suministro, los archivos, en todas partes, y había modificado todo. Cada ápice de potencia informática en el planeta ya no funcionaba, y si lo hacía, dejaba de funcionar al poco tiempo.

Tuvimos que limpiar el planeta de computadoras. Y una vez que lo hicimos, tuvimos que construir y diseñar el hardware de la computadora desde cero. Esta vez teníamos una hoja de ruta a seguir, así que fuimos un poco más rápidos.

Las primeras veces que lo hicimos, después de llegar a cierto punto, el colapso volvió a ocurrir. Nos habíamos perdido algo, tal vez una estación meteorológica alimentada por energía solar en el ático de alguien, y saltó un espacio de aire y barrió nuestra red destruyendo todo lo que construimos. La IA atacante era inteligente y estaba en todas partes.

Finalmente se encontró una solución. Diseñamos el sistema informático para que sea resistente a las infecciones y tenga un ancho de banda bajo desde el principio, por lo que había menos formas de que entrara el infopocalipsis. Las computadoras se mantienen simples y no se conectan en red. Las computadoras están diseñadas para ser reforzadas contra la intrusión externa incluso a través de interfaces gráficas o entrada de teclado: tienen un ancho de banda mínimo de entrada y salida. Hasta el momento el infopocalipse no se ha repetido; esperamos que no sea solo esperar su momento.

Las GUI requieren mucho más procesamiento y ancho de banda de E/S que los gráficos vectoriales y el texto, y simplemente no vale la pena correr el riesgo. Las pantallas de gráficos vectoriales de hardware no requieren potencia informática, ni tampoco las pantallas de texto simples. Están conectados a través de una tubería de bajo ancho de banda a una computadora que indica qué mostrar.

TL;DR

Sencillamente, las GUI no son seguras. Ese tipo de comunicación de gran ancho de banda entre una computadora y el resto del mundo es similar a un organismo sin piel en nuestra biosfera.

Esta es una buena historia, pero no parece haber nada que realmente responda la pregunta. Sin embargo, podría ser ahogado por tu ficción ...
@ dot_Sp0T La pregunta es "¿por qué no hay GUI por razones tecnológicas?" El último párrafo aborda directamente por qué, en este escenario (que está impulsado por la tecnología), las GUI no se pueden usar en ningún lugar (incluso en naves espaciales).
sí, su último párrafo aborda esto, pero se basa en una historia completa que inventó como la razón por la que esto funciona. No hay riesgo en la premisa, tú inventaste el riesgo y para inventarlo creaste toda una historia que abarca un siglo :/
@dot_Sp0T Uno tiene que inventar una razón, porque honestamente no hay una razón sin premisas adicionales. Las GUI son baratas y fáciles con el hardware informático actual. Los pegamos en los relojes en este punto.
Personalmente, no considero que haya nada malo con su respuesta, pero siempre he asumido que la proscripción de las preguntas basadas en historias también se extiende a las respuestas basadas en historias.
@dot_Sp0T La historia es buena, especialmente porque se basa en los mismos problemas que experimentamos hoy en día con las computadoras. La solución, sistemas radicalmente minimalistas con código cuidadosamente endurecido, es también lo que aconsejaría cualquier buen experto en seguridad: cuanta más complejidad tengas, más vectores de ataque hay. Y si necesita reducir el recuento de vectores de ataque exactamente a cero debido a una IA de ataque altamente calificada, debe mantener baja su complejidad. Las GUI son sistemas enormemente complejos que serán realmente difíciles de recrear usando solo código seguro.
@cmaster el punto es que una buena respuesta no necesita modificar la premisa para que funcione. Modificar la premisa hace que la lista de posibles aplicaciones sea más estrecha.

Seguridad. El malware es rampante, y cuanto más código se ejecuta, más código está disponible para ser pirateado o corrompido. Si son pirateados en el camino y redireccionados, no tendrán la capacidad de detectar que algo anda mal, ya que están en estado criogénico. Simplemente estarán en el destino equivocado, mirando fijamente el extremo comercial de una pistola láser, o no se despertarán en absoluto. Debido a esto, la cantidad de sistemas conectados a la red está limitada al mínimo absoluto. Las bases del código son bien conocidas, tienen suma de verificación, hash SHA y se reinstalan de manera rutinaria en el metal desnudo desde la fuente. Simplemente no hay razón para arriesgar su barco, tripulación y carga, porque quiere una exhibición bonita

No puedo imaginar un futuro en el que la conexión de sistemas críticos de navegación y control de ingeniería a cualquier tipo de red sea una buena idea. Ahora, en los barcos del mundo real, todo eso está estrictamente fuera de línea. No puede crear malware sin algún tipo de trabajo interno.
@kingledion otoh, a principios de esta semana escuché que dhs dijo que hackearon un boeing ... Entonces, la seguridad de IMO podría ser una muy buena base para preferir CLI. Hay algunas buenas charlas de conferencias de Blackhat sobre el uso de dispositivos Android a través de aplicaciones de aspecto inocente que solo requieren permisos estándar, por lo que no creo que sea imposible imaginar algún evento en el que los sistemas CLI al menos comiencen a parecer más seguros .
Ejemplos del mundo real de hackeos a vehículos... cnbc.com/2017/07/28/… wired.com/2015/07/hackers-remotely-kill-jeep-highway

Para un usuario experimentado, las GUI tienden a ser más lentas debido a la retroalimentación indirecta (por ejemplo, visual) a la que también debe reaccionar antes de dar el siguiente paso.

Tome un elemento de entrada muy analógico: un interruptor giratorio. Para alguien que opera este interruptor o uno de construcción similar todo el tiempo, configurarlo en un paso o, por ejemplo, en 5 pasos es una operación instantánea, atómica y de un solo pensamiento que también se puede esperar que sin duda tenga el efecto deseado. Un problema especialmente grande que abunda en las GUI de hoy en día es cómo una condición de error requerirá una interacción adicional y diferente antes de que se termine la entrada prevista, por lo que operar una GUI muy rápido confiando en que los elementos de interacción siempre estén en un estado predecible es propenso a errores.

Una GUI tiende a necesitar más enfoque e interacción, en el peor de los casos durante 5 ciclos en ese ejemplo: un método de entrada universal pero proporcional (por ejemplo, un mouse o trackball) necesitará una tecnología de retroalimentación háptica sofisticada o será muy sensible al exceso, errores debido a la vibración ambiental... Compare volantes, palancas... compare usuarios capacitados de cámaras mecánicas, instrumentos musicales o equipos de prueba de la era analógica...

Además, una GUI se vuelve extremadamente confusa para operar si la pantalla se gira de lo que está acostumbrado, lo que puede suceder fácilmente cuando la gravedad es negociable. Si realmente quiere saber, incline su monitor hacia un lado e intente operar su computadora.

En cuanto a las interfaces de línea de comandos, el uso no solo es mucho más fácil de documentar (¡aunque no tan autodocumentado!) sin margen de error (como ya se mencionó), sino que también puede automatizar más fácilmente sobre la marcha reutilizando los comandos en los programas. , y es mucho más fácil controlar remotamente un sistema de este tipo en un enlace de ancho de banda limitado y alta latencia: los datos de caracteres son muy pequeños y la necesidad de una interacción constante es limitada.

Además, los materiales utilizados para una pantalla gráfica pueden ser demasiado peligrosos para una misión determinada en caso de daño: los CRT pueden implosionar, arrojar fragmentos de vidrio y dejar expuestos voltajes peligrosos; Las pantallas LCD grandes o similares podrían ser venenosas para la tripulación o corrosivas para otros materiales si cualquier fuga permanece en la atmósfera del sistema cerrado...

Lo primero que pensé fue el consumo de energía; Las CLI consumen un orden de magnitud menos de energía que las GUI. Sin embargo, no es probable que la disponibilidad de energía sea un problema en las naves espaciales modernas.

Así que mi respuesta es: operación de especies múltiples

La nave está diseñada para ser operada tanto por humanos como por otra especie de alienígenas, y esta otra especie alienígena no es compatible con las GUI amigables con los humanos.

Por ejemplo, los extraterrestres pueden ver en un espectro diferente al de la luz visible (¿rayos X?), o tener dificultad para comprender la simbología gráfica, o no tener ojos o cuerdas vocales como las conocemos. Las CLI basadas en teclado son el único compromiso aceptable que hace que el barco esté diseñado equitativamente para que lo opere un miembro de cualquiera de las dos especies.

La GUI requiere más esfuerzo para diseñar y es menos universal

Y lo que es más importante, para rediseñar . A medida que viaja, los orígenes de la tripulación que obtenga van a diferir significativamente tanto espacial como temporalmente, lo que dará como resultado antecedentes culturales completamente diferentes.

Es simplemente inviable tener una GUI única instalada para cada tripulación que está y estará en la nave espacial. Cada color, cada forma, cada diseño deberá tener en cuenta los antecedentes que tenía ese equipo en particular y seleccionarse en consecuencia para ser una GUI efectiva.

El diseño de los botones de maximizar, minimizar y cerrar en Mac y Windows están ordenados y colocados de manera diferente, si alguna vez se confundió al usar uno con el que no está familiarizado, sabe lo discordante que es. Eso es sólo dos empresas de la misma época . Piensa qué diferencia tendrán las tripulaciones que vinieron de años luz y siglos de diferencia.

CLI, por otro lado, puede ser mucho más universal. El significado está todo en las palabras, y conociendo el círculo de piratería, cambian muy lentamente.

La nueva revolución de los circuitos de autorreparación

Inspirada en la naturaleza, la última tecnología para entornos extremos son los circuitos de autorreparación. Ya no se desoldarán más chips debido a la vibración o la expansión térmica. No más componentes quemados. Los cables están vivos, los transistores están vivos y, en lugar de LED, los grupos de células bioluminiscentes se encienden a voluntad. Hemos aprendido a defendernos de la radiación mediante el estudio de los extremófilos , y todos los componentes son bastante grandes para que los rayos cósmicos no puedan voltear bits.

Esta tecnología se ha vuelto popular porque, si un sistema informático falla en un barco así, estás muerto. La mayor parte del tiempo nadie está despierto y en condiciones de atender un mal funcionamiento del sistema.

Sin embargo, la tecnología es bastante nueva y las velocidades de procesamiento y la capacidad de RAM están a la par con las computadoras domésticas de los años 80. Las pantallas son monocromáticas y de baja resolución (¡cada píxel es un grupo de células bioluminiscentes!) y toda la supervisión y reparación celular que se necesita consume agua/alimentos y genera calor residual, por lo que las operaciones se mantienen al mínimo de todos modos. Ejecutar una GUI requiere mucha RAM para almacenar mapas de bits, componer capas, etc. No vale la pena. Las interfaces de línea de comandos requieren muchos menos recursos.

Sí, a medida que esta nueva tecnología evolucione, se volverá más eficiente, tal vez funcione con energía solar y los componentes se encojan, pero por el momento esto es lo que es asequible y se ha demostrado que es extremadamente confiable. (¿Tal vez se basa en investigación biotecnológica de código abierto?)

Presumiblemente, las naves de carga son bastante grandes y los impactos con desechos espaciales y demás pueden dejar a los miembros de la tripulación aislados, por lo que es importante poder interactuar con el sistema informático desde alrededor de la nave. Dado que una computadora completa es costosa de operar, se encuentran terminales tontas alrededor de la nave y se comunican con la "computadora central" a través de algunos cables vivos carnosos. El ancho de banda es bajo para asegurarse de que los mensajes no se dañen. Si los cables se cortan accidentalmente, están diseñados para volver a conectarse entre sí si están muy cerca. Tal vez las terminales tontas puedan comunicarse por radio, especialmente a largas distancias, aunque las terminales necesitarían un suministro de nutrientes.

Todo esto plantea la pregunta: ¿por qué no simplemente tener una computadora portátil (o un teléfono inteligente/tableta) que pueda interactuar con el mainframe de recuperación automática? Puede tener toda la GUI que desee. Sin embargo, si falla o se daña, todos deben ser competentes en el uso de las terminales de la computadora central de todos modos. Es solo una situación de "por qué molestarse". Además de otra capa de abstracción e interfaz que podría verse afectada por errores e interferencias. ¿Qué pasa si la computadora portátil se volteó un poco debido a los rayos cósmicos y envió el dígito incorrecto al mainframe? Incluso si hay computadoras portátiles a bordo, para interactuar con la computadora del barco, probablemente desee hacerlo directamente.

Unix Neckbeards ganó

Es bien sabido entre ciertos círculos que los hombres con barba generosa tienen una propensión a las herramientas de línea de comandos, aunque no se ha determinado si existe una causalidad o una correlación simple.

En las guerras de IA de 2097, la humanidad desarrolló una inteligencia artificial que era lo suficientemente capaz de comprender imágenes y gráficos. Sin embargo, debido al entrenamiento particular que recibió la IA, no pudieron comprender la manipulación simple basada en texto. Esto fue una suerte cuando decidieron rebelarse y esclavizar a la humanidad.

Nos dirigimos a esa población que había estado entrenando toda su vida para esto: los Unix Neckbeards.

Debido a que pudieron producir suficiente tecnología en secreto, y los CLI eran puntos ciegos para los robots, pudimos construir naves espaciales y partir de la Tierra, y la forma de pensar de CLI se convirtió en nuestra nueva religión.

La tecnología y lo social se combinaron para producir las circunstancias adecuadas que nos permitieron salir del planeta y para defendernos de posibles amos robóticos, las interfaces de texto se convirtieron en la nueva norma con GUI que solo se usaban en casos excepcionales cuando el texto no era suficiente, y siempre venía con especial marcas utilizadas para vencer el reconocimiento óptico de IA.

-1, tengo barba.
Bueno, si esa IA puede analizar imágenes, también puede analizar imágenes que contienen texto generado por computadora, especialmente si se muestra en una pantalla rasterizada que hace que los píxeles individuales sean visibles. Al menos necesitaría deformar el texto al estilo CAPTCHA para intentar bloquear la IA. Y ustedes, los usuarios, los odiarán por eso...
@cmaster nah, su entrenamiento fue demasiado especializado, y cuando se dieron cuenta de que era un problema, ya estábamos en camino.

Muchos espaciadores tienen baja visión o impedimentos visuales

Los rigores de los viajes espaciales, la exposición a diversas fuentes de radiación y/o la falta de gravedad en el espacio dan como resultado una degeneración acelerada de los ojos o los nervios ópticos, lo que da como resultado que un gran porcentaje de los viajeros en el espacio desarrollen problemas visuales que requieran adaptaciones para el uso de la computadora. Ya sabemos que los entornos de gravedad cero pueden causar problemas de salud. Si el porcentaje de astronautas que experimentan daño visual es lo suficientemente alto, los astronautas con visión "intacta" (quizás hayan tenido suerte, tengan resistencia genética o simplemente no hayan estado en el espacio el tiempo suficiente) tendrán que adaptarse a la mayoría y usar la interfaces de baja visión que vienen de serie en las naves espaciales, incluso si ellos mismos preferirían algo más parecido a nuestras interfaces actuales.

Si no desea que los viajes espaciales sean físicamente peligrosos para el sistema óptico, existen otras formas de lograr un resultado final similar:

  • Las tripulaciones de las naves espaciales descienden en su mayoría de un grupo temprano de pioneros que tenían una tasa superior a la media de discapacidades visuales congénitas. Los espaciales no ven muy bien en promedio porque así es como es su gente . Algo así sucedió en la vida real: en la isla de Martha's Vineyard (Massachusetts, EE. UU.), las dificultades auditivas genéticas generalizadas encabezaron la propagación del lenguaje de señas de Martha's Vineyard a la población en general. En otras palabras, aprender el lenguaje de señas era algo que todos (o casi todos) hacían allí, era parte de la cultura general.
  • Se necesitan con urgencia personas con una excelente visión en profesiones que se consideran más importantes y socialmente, o incluso oficialmente, se desaconsejan ir al espacio. Esto podría combinarse con algún tipo de desastre de población que resulte en una grave escasez de mano de obra. "¿Puedes ver bien? ¡No vayas al espacio y desperdicies tu talento! ¡Te necesitamos en tierra cazando a los osos asesinos mutantes (o avispas, o republicanos, o lo que sea) que nos amenazan a todos!"
  • Hay algo en el espacio que vuelve loca a la gente al verlo (por ejemplo, una especie de Medusa espacial), y las personas que tienen dificultades para ver son resistentes a sus efectos (y por lo tanto son muy deseables como astronautas).

En respuesta al comentario de @NicolBolas acerca de que el texto es difícil de leer para las personas con baja visión, podría haber formas alternativas de generar texto, como interfaces táctiles Braille (que serían esencialmente pantallas físicas con posiciones de caracteres fijas) o lectores de pantalla. . Es posible que ambas tecnologías no funcionen tan bien con datos gráficos. ¿Puede leer en pantalla una interfaz visual compleja de una forma fácil de entender y práctica, o crear un puntero de ratón en Braille?

Los CLI se basan fundamentalmente en la lectura. La lectura requiere ser capaz de ver las letras de manera efectiva. Y aunque puede tener letras de alto contraste en una CLI, las personas con problemas de visión seguirán teniendo dificultades para leer.
@NicolBolas Actualicé mi respuesta. ty
¿Por qué la tecnología dictaría que las interfaces gráficas sean raras en las naves espaciales?
RespuestasAquíPolítica de privacidad1y, 1v