ERROR... lo deciden todos.

Es como si algunos deciden que quieren una jornada laboral a la semana de 20 horas, pero solo pudieran votar aquellos que están a favor.  Es ridículo, deben votar todos los afectados, esto es, todo el país.

Imagina que tu vecino decide que no quiere pagar la comunidad y para hacerse fuerte decide independizarse del 'edificio', como eél es el máximo interesado, solo podría votar él, según tú y no todos los vecinos del edificio que son todos los afectados... escaleras, luces, ascensor, tejado sótano y facada... todos son elementos dle edificio, afecta a todos.

Una votación donde solo voten los propios interesados (a favor de su contienda), resulta absurda. Vamos jamás existirá una votación donde haya 20 tipos decididos por una cosa, voten y salga que los 20 voten 'no'... y si la hubiera cabría añadir que son tontos del KU10...

En efecto, para manejar más de 255 caracteres, debes prescindir de los 'ReadLINE y WriteLINE, que como su nombre sugiere refieren a una sola línea.

Puedes crear arrays donde cada ítem del array fuere una línea. Usar directamente un array de bytes es igualmente válido, cuando se escribe al detectar los caracteres de salto de línea, los interpreta y sigue escribiendo...

Nota que algo WriteLine y ReadLine, suelen usarse para la interacción con el usuario, normalmente si se le pide algo al usuario suele bastar una línea (o en varias writeLine-s), pero la respuesta dle usuario suele limitarse a una sola línea, luego ReadLine es más que suficiente al caso.

Ahora la cuestión es... porqué perder tiempo con la consola para intentar sortear los límites prácticos de la consola cuando hay controles para hacer interfaces de usuario sin las limitaciones de la consola????????. Un chat acaso no será más cómodo en una ventana (form) con alguna caja de texto multilínea... pero en fin, cada uno pierde el tiempo como quiere.

Considera que igual que tú has hallado vulnerabilidades, puede suceder que al mismo tiempo alguien también las haya encontrado y a diferencia de tí, esté utilizándolas para su provecho o simplemente digamos que ilegalmente. En tal situación reportar dichas vulnerabilidades les lleva inmediatamente a sospechar que eres tú el que les está asaltando y que no logran evitar.

Es una lástima que los gobiernos no incluyan (provean ni prevean), un sistema donde poder reportar estos datos (por ejemplo) a la policía pescializada en delitos telemáticos, como un apartado precisamente para recibir estas notificaciones y que luego ya la policía pudiera trasladar a las empresas y sobretodo verificar la validez de las vulnerabilidades y dando por positivo los resultados, exigir un plazo (razonable) a las empresas para enmendar dichos fallos (cuando lógicamente dependa de ellos).

Así que sí, lo mejor es enviar una notificación anónima donde expliques todo el caso bien desarrollado. No olvides incluir fechas y horarios (si los recuerdas), pués de algún modo esto podría ayudarles a distinguir esas otras posibles o supuestas intrusiones que tuvieren. Por supuesto si no señalas como destinatario "departamente de seguridad informática" (o similar), tiene muchas posibilidades de que acabe en la basura sin siquiera alguien que lo lea. Y aún con eso, puede que no sea atendido.

Más interesante si además de enviarlo a la propia empresa, se lo envías también a un juez, y aclaras en ambos escritos algo como: "este documento se envía por duplicado a la empresa 'x' y al juez, para que en futurible caso de violación de seguridad de la empresa, pueda un juez desestimar las posibles denuncias alegando omisión del deber en la seguridad..."
Es decir es una aclaración a la empresa de que en caso de que no resulevan los problemas, si en un futuro a causa de dichos fallos les expolian, el seguro (por ejemplo) podría denegarles el derecho a la cobertura alegando que fueron halladas vulnerabilidadas en el pasado, que no han sido corregidas y que son la causa del expolio. En fin, supone una invitación clara a corregir sus fallos o que se atengan a las consecuencias.

Nota que un diagrama de flujo es sustancialmente distinto a una máquina de estados, aunque ambos tienen un carácter de desarrollo, un autómata suees ser específico a una tarea muy determinada. Si bien un autómata puede ser expresado también y fácilmente en un diagrama de flujo, lo opuesto puede llegar a ser inabordable ysi hay cierta complejidad.

En un diagrama de flujo, básicamente expresas todo o parte de lo que un programa hace, además se puede hacer a mayor o menor detalle... una caja puede contener todo un programa, o una simple línea de código... Una máquina de estados opera siempre al detalle mínimo, es decir aborda los detalles del problema en cuestión. ambos pueden ser abstraciones, por cuestiones de generalidad (múltipleas adaptaciones de uso, por pocos cambios para el caso de que se trate).

Los diagramas de flujo centran su interés casi exclusivamente al hehco de tener que mostrar el comportamiento (más exactamente la forma en que se desenvuelve), a terceras personas... sea para enseñanza, sea para que lo programe un tercero, etc...

El autómata centra su interés en 'vehicular' el código necesario cumpliendo todos los condicionantes exigidos. Es decir la idea de crear el autómata es escribir luego el cóodigo libre de errores a sabiendas de que cumple su funcionalidad. Con el diagram de flujo, esto solo es posible cuando el diagrama expresa los detalles más ínfimos, si no es de 'libre implementación' esas partes no detalladas.

Es decir si es para ti mismo un diagrama de flujo, solo pueden llegar a ser necesarios cuando la complejidad o envergadura del sistema exige, dicho tratamiento para abordarlo e ir definiendo partes completas y partes sin terminar o mejorar, o probar... es decir como un planificador de trabajo.
En cambio un autómata se hacen necesarios cuando hay muchas condiciones y son complejas y se requiere una alta eficiencia. Además una vez completado un autómata, siempre puede ser optimizado so pena de dejar el código más oscuro.

Como te decía al comienzo, un diagrama de flujo es sustancialmente distinto a una máquina de estados aunque hay puntos en determinadas situaciones donde el diagrama de flujo y la tabla de estados son sinónimo lo uno de lo otro, es decir partiendo de ellos se puede escribir el código subyacente.

...por lo demás, en el enlace los pasos están meridianamente explicados, siguiéndolos al pie de la letra, no te pierdes. La importancia para tal ejercicio, recáe únicamente en que te sirvan de base para poder desarrollar otros diagramas por tu cuenta.

No me gusta (de dicho artículo), el grafismo usado en el desarrollo. Me quedo con la descripción del viejo libro (1970) de Mario Farina (Flowcharting), que pese a su edad sigue vigente, no se han realizado aportes significativos desde entonces.

Particularmente considero que mediante UML, se consiguen desarrollos más sencillos y explícitos de seguir (creo recordar que VS-2008 permitía generar el UML correspondiente a tu código, y no recuerdo si luego en las siguientes versiones lo disgregaron de ciertas versiones).
Pero igualmente si no es para que entregar o exhibir a terceros, no suelen tener una utilidad propia, más allá de la comentada cuando la complejidad exige una planificación que facilite su suguimiento y abordaje. Por supuesto tampoco estorba, cuando como el caso comentado, el diagrama era generado a partir del código, algo muy útil para repasar un proyecto de cierta complejidad que hiciste tiempo atrás y del que ya olvidaste detalles...

Ufff, ese 'tutorial', es francamente malo... Me recuerda ciertos libros y artículos de revistas, en esa misma línea. Ese tipo de tutorial donde te explican como si fueras idiota, "pulsa aquí, escribe esto, haz lo otro...", no enseñan absolutamente nada.

Un autómata o máquina de estados, es un modelo matemático que se compone de un alfabeto, una serie de estados, una función de transición, un conjunto de reglas, un estado inicial y un estado final.
- El alfabeto determina los elementos que puede contener.
- El estado inicial, es el modo exacto en que está el autómata al comienzo. Por lo general queda definido por un valor a la entrada.
- El estado final, es el modo exacto en que está el autómata al final. Por lo general sólo es de interés el valor de salida. O dicho de otra forma, cada valor de interés a la salida es devuelto. Es común que sea un único valor.
- Los estados, son los valores entre los que puede evolucionar internamente el autómata.
- La función de transición, determina que valor de estado se toma internamente ante las eventualidades presentes. Esta función generalmente describe en código o se compone de condiciones que examinan el estado actual y la situación en un momento concreto, para decidir el siguiente estado. Suele resumirse en una tabla de estados, que refleja fielmente qué sucede en cada caso.
- El conjunto de reglas es lo que diferencia una función de transición respecto de otra. Las reglas se pueden reflejar en un esquema o bien en una tabla.

Como podrás ver, en el 'tutorial' aludido, no se menciona prácticamente nada de todo esto, ni mucho menos aclara qué sucede y por qué...

Existen los autómatas finitos e infinitos, pero en la práctica, sólo podemos operar y llevar a término, los finitos (los infinitos pueden requerir memoria infinita o tiempo de cálculo infinito y no disponemos ni de uno ni de lo otro...).

Los finitos tienen básicamente dos aplicaciones: autómatas reconocedores, aceptadores (comúnmente llamados scanners), o traductores. Estos últimos transforman un valor de entrada en uno de salida, los otros suelen limitarse a 'decir', ok, está bien, o no, está mal... Pero no es infrecuente utilizar un rango mayor de posibilidades que sólo 2.
- Un ejemplo de los reconocedores, es por ejemplo la fase de análisis del código fuente de un lenguaje de programación para determinar si el texto recibido pertenece o no a dicho lenguaje... en realidad, ahí hay más de 1 autómata, por ejemplo uno determina si una secuencia de caracteres es o no un número.
- Un ejemplo de los traductores, ahondando en el mismo caso, es utilizado cuando por ejemplo el texto del código se pasa desde el lenguaje en que se programó a ensamblador o a código máquina, o a código intermedio durante el proceso de compilación...

En mi opinión harías más avances si usarás de ejemplo el reconocimiento de un token numérico. Más útil y más didáctico, además es un ejemplo donde puedes usar tu mente (pensar, no meramente leer y escribir).

 Ejemplo
--—------—---—------—----—-----
digito = 0|1|2|3|4|5|6|7|8|9
sepDecimal = '
digitos = digito [digitos]
numero = digitos [sepDecimal digitos]

Así el alfabeto lo componen cada digito (0 a 9) y el separador decimal  '
Las reglas se condensan en las 4 líneas que describen digito, digitos, sepDecimal y numero.
El estado inicial es 0. digito tiene estado 1, cuando se transita de un digito a otro, el estado cambia a 1, es decir no cambia. Si aparece un separador decimal tras un digito transita al estado 2, si tras el separador aparece un digito transita al estado 3. Pero si aparece otro separador tras el separador , transita al estado 4. Y si aparece un carácter que no pertenece al alfabeto transita al estado 5.
Si alcanza un estado 3, si aparece otro digito transita a estado 3, es decir no cambia. Y si aparece un nuevo separador transita al estado 4.
En resumen, empieza en estado 0, la función continua analizando mientras queden caracteres y el estado sea menor o igual a 3. La aparición de un carácter no definido en el alfabeto transita al estado 5.
Los estados finales, pueden ser 0, 1,2,3,4 o 5. Pero los estados de aceptación sólo son 1 y 3. Es decir la función reconocerá el token 'numero', si se devuelve el estado 1, o 3... O directamente resumido un valor TRUE (if estado =1) or (estado=3) devolver TRUE.

Si decides abordarlo, y muestras algún progreso (escribir por escribir, si no hay interés, paso) podría mostrarte el esquema, la tabla de estados y el flujo de la función... Que te servirían de excelente ejemplo para aprender...

Tú crees que alguien aprendería matemáticas simplemente participando en retos matemáticos?...

Primero se necesita una base mínima lo más amplia posible sobre informática (amplia en el sentido de abarcar diferentes áreas: hardwre, sistemas operativos, drivers, redes, programación, etc...).

Resiste como puedas 1, 2 o 3 años más... mientras termines tus estudios, luego busca un trabajo lo más estable posible, ahorra 6 meses y vuela fuera...

p.d.:
No te compliques la vida con vengatas, que nunca satisfacen. Simplemente acabas siendo al final el 'malo de la película', eso te apega miserablemente más tiempo del que quieres a dicha persona. Y lo que necesitas es alejarte, cuantos menos vínculos mejor... incluído la memoria.
Tampoco merece la pena ir a la policia y denunciar si no hay maltrato físico, el psicológico tendría que ser demostrable, primero que lo padeces y en segundo lugar que la causa es él y no otra. Y esto en el seno familiar, es muy complicado. Considera que el mundo a su manera acaba dando a cada cual 'su merecido'...

Supongo que por lo mismo que otros comparten su pareja: 'les excita...' 

Esto no es correcto...

Estas cerraduras, existían desde poco antes de mediados de los 60, osea alrededor de 20 años antes.

Se usaban en los PDP de DEC, además desde los 70 (PDP-11), tenían 3 posiciones que eran mucho más útiles. La llave entraba en la posición que estaba y se podía girar y sacar en cualquiera de las otras 2 posiciones a las que podía moverse (más contando la actual), es decir si estaba en la posición 'off', no se podía encender el equipo. Si estaba en la posición 'power' no podía apagarse el equipo y si estaba en 'lock' (que era una extensión de power), es cuando actuaba como indica el artículo.
Los PDP-8, y PDP-5 (de 1963 y 1965 aprox.) en cambio solo tenían 2 posiciones como los mencionados en el artículo.

Adjunto una imagen del panel delantero del pdp-11/20 (la cerradura está abajo a la izquierda)


[MOD] Imagen redimensionada según Normas del Foro.

 mmmm... Porqué respondes a un tema de hace 8 años... De verdad crees que alguien esperará durante 8 años una respuesta ¿¿¿