Rotundamente NO.

Si todos los medicamentos hasta ahora han tardado años en aprobarse por las duras pruebas de testeo (y eso que muchas solo afectarían a una pequeña minoría y no trataban de curar nada mortal), no entiendo por qué esto ha de ser distinto y no seguir el MISMO proceso.
Es más dado el cariz de que afecta a todo el planeta y que es mortal, se le debería exigir con razón aún más pruebas respecto de efectos secundarios ...especialmente los que puedan a aparecer a largo plazo, que es el más grave a contener.

No me parece mal, que quien quiera ponérsela se la ponga, pero CREO que deberá ser totalmente voluntario y por tanto ser tratados como las cobayas del laboratorio, luego los efectos secundarios que tuvieren no deberían ser distintos (respecto de quejas y reclamos), a los mismos voluntarios que se presentan cuando la 'están probando' (que es lo que estará sucediendo en la situación actual).

Por último, considero muy importante que todos los defensores a ultranza de las vacunas sean (caso de ser obligatorio en algún país), los primeros en ponérsela, empezando por políticos, luego sus simpatizantes (todos estos que salen en foros y rede ssociales defendiendo el asunto de las vacunas), luego por médicos y (resto de centifiquillos del ramo)... y en último lugar (repita, en caso de ser obligatorio en algún lugar), a aquellos que no quieren ser vacunados...

Otra pregunta (quizás más) interesante sería la dual: el que se vacuna porqué quiere vacunarse y el que no, porqué no quiere vacunarse.

Es trivial.

Creo que es el caso de la inmensa masa que apenas sabe lo justo de informática, usa los recursos de la red, pero no sabe nada subyacente sobre la tecnología, son puramente consumidores... En realidad no es culpa de ellos, a menudo en ejemplos de manuales aparecen contraseñas como 'admin', '1234' (parta ejemplo tenemos los fabricantes de router, que las suelen usar por defecto), luego ellos acaban por considerar que 'si lo usan los fabricantes, será que eso es seguro, entonces ''pluto1234'' tiene que serlo mucho más'.

Sin ir más lejos, cuando lees manuales de programación ves cosas igualmente ridículas como: 'Ahora vas a crear tu primer programa en el lenguaje 'x'... escribe:
print "Hola mundo"
y se quedan tan panchos... Al igual que los lenguajes de 'Hola mundo' crean programadores mediocres, los manuales de programas que señalan 'crea tu contraseña' y exponen como ejemplo una casilla de texto con '1234' han acabado creando usuarios confiados (no retrasados, retrasado lo sería si después de birlarle una cuenta, siguiera usando esas contraseñas). Para ellos es muy fácil pensar en algo como: 'con toda la gente que hay en el mundo, con dinero y otras coas de valor, para qué me van a atacar a mi con mi modesta contraseña???'...

Las tarjetas de crédito sin ir más lejos se han manejado con 4 digítos... claro que al  tercer intento fallido la tarjeta quedaba bloqueada en el cajero.

Tampoco podremos cambiar la creencia de los fabricantes de imaginar que los sitemas biométricos son infalibles, no solo antes el robo si no ya incluso para uno mismo.
Yo mismo si uso mi huella dactilar para el tf. móvil, solo me vale para el propio día, al día siguiente ya no me la reconoce... las yemas de mis dedos no mantienen largo tiempo su aspecto, las líneas no cambian básicamente en la vida, pero sí se pueden deformar fácilmente por la erosión. Si eres dado a las manualidades, te podrá suceder a menudo.

Es que ahí es donde tenemos cierto deber nosotros. Si cada uno enseñamos a nuestos amigos y conocidos a usar contraseñas fuertes y muy fáciles de recordar, no tendrían problema en mantener contraseñas seguras... y con el tiempo, cada uno de ellos, se lo enseñaría a otros...

A menudo cuando descubro esas contraseñas ridículas en mis amistades, les pregunto: "tienes en tu cabeza alguna estrofa de una canción o una frase, que sabes que jamás se te olvidará?. La respuesta siempre es sí.. les pido que la reciten  y les muestro como usar (por ejemplo, en el modo más sencillo), la primera letra de cada palabra... así si la estrofa tiene 20 palabras es de 20 caracteres de largo, guau, escrito no la podrías recordar, pero resulta que la frase YA ESTÁ memorizada en tu cerebro... luego les digo, bueno no lo dejes tan simple, después de todo hay letras que son las más comunes para empezar palabras, podrías por ejemplo descartar palabras de menos de 3-5 letras, o usa la letra inicial, luego la segunda en la siguiente palabra, luego la primera, etc... alternas una mayúscula otra minúscula, si son dos o más vocales seguidas omite excepto la primera o la última. etc... usa tu imaginación, y mete en algún punto algún número aunque no tenga número, por ejemplo cuenta las letras de una o dos palabras y ahí en medio de ellas lo pones, etc... después de una breve charla con diversos ejemplo escritos, captan la idea y con el tiempo notan la diferencia.

Yo que lo más odio, es que el usuario que aparece en un sitio, sea justamente la mitad de tu login en ese sitio...
Si aquí tu alias es 'TickTack', cualquiera tiene ya la mitad de tu login, solo precisa encontrar la contraseña... Además si algien quiere entrar en tu cuenta ya sabe que tiene que usar 'TickTack'... si consigo dar con la contraseña tengo acceso a tu cuenta, que es la que uno en un momento dado quería atacar...
Yo prefiriría que el login exigiera un alias que para nada sea el alias usado en el foro, supongamos que en tu login usaras 'perico1234' (ahí que no te gusta eso del 1234  ), solo con ver tu alias de 'TickTack', yo no podría decir... "voy a ver si consigo entrar en tu cuenta..." porque no sé cual sería tu alias de login, un login cualquiera usado podría corresponder a cualquier usuario desconocido, luego no podría siquiera 'fijar un objetivo concreto'...
...pero 'Donald Trump' sabemos que es la cuenta de 'Donald Trump', pero si Donald Trump, hiciera su login con "Pato Donald", la gente tendría que adivinar no solo una contraseña facilona (que seguro que la tiene facilona), si no además el alias... las combinaciones se elevan al cuadrado.

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...'