Portada
mis comunidades
otras secciones
#13:
Se le suele echar la culpa al último mono siempre: piloto de Spanair, conductor del Alvia, operador de red, etc. pero cuando se produce un desastre no es culpa de una persona, detrás hay presiones, recortes, malas arquitecturas.
En este caso parece que un crecimiento demasiado acelerado ha creado una arquitectura poco resistente a fallos. Y eso no es problema del operador, administrador, etc. porque las artquitecturas tienen que diseñarse para que sean resistentes al fallo humano que, inevitablemente, va a ocurrir.
En este caso parece que un crecimiento demasiado acelerado ha creado una arquitectura poco resistente a fallos. Y eso no es problema del operador, administrador, etc. porque las artquitecturas tienen que diseñarse para que sean resistentes al fallo humano que, inevitablemente, va a ocurrir.
#1:
Un simple typo.
Dios mío, llévame pronto.
Dios mío, llévame pronto.
#7:
Desafortunadamente, una de las entradas del comando se ingresó incorrectamente y eliminó un conjunto de servidores más grande que el previsto.
Está claro, olvidó el where en el delete from .
Está claro, olvidó el where en el delete from .
#45:
#6 Si, una dejadez tremenda. Mantengamos la salida del producto congelada hasta que no hayamos testeado bien. Pero no mal, ¡bien!
- Hacer la batería de test habituales
- Luego pasaremos los test buenos (no los habituales) los test buenos buenos.
- Más tarde haremos los test de esos fallos que sólo se producen cuando un equipo está en producción: Traigan a un millardo de usuarios repartidos por 4 regiones mundiales y póngalos a tocar las teclas como los monos en noche de luna llena mientras suena de fondo Kandinsky. ¿Pero Kandinsky es un pintor? Eso, eso no se lo esperarán.
- Una vez pasado esos test, haremos las pruebas de fallos que pueden surgir pero que no estaban dentro del protocolo, para ello preguntale a Paco. ¿A Paco? Si, a Paco. Que te haga una lista.
- Llama a Google, Microsoft, Oracle y que te den los fuentes de esas librerías que linkamos, estudialas y prueba cualquier posible error de aquí a los próximo 15 años.
- Hacer la batería de test habituales
- Luego pasaremos los test buenos (no los habituales) los test buenos buenos.
- Más tarde haremos los test de esos fallos que sólo se producen cuando un equipo está en producción: Traigan a un millardo de usuarios repartidos por 4 regiones mundiales y póngalos a tocar las teclas como los monos en noche de luna llena mientras suena de fondo Kandinsky. ¿Pero Kandinsky es un pintor? Eso, eso no se lo esperarán.
- Una vez pasado esos test, haremos las pruebas de fallos que pueden surgir pero que no estaban dentro del protocolo, para ello preguntale a Paco. ¿A Paco? Si, a Paco. Que te haga una lista.
- Llama a Google, Microsoft, Oracle y que te den los fuentes de esas librerías que linkamos, estudialas y prueba cualquier posible error de aquí a los próximo 15 años.
#26:
#13 totalmente de acuerdo. El recurso fácil siempre es culpar al soldado raso. Que una multinacional como Amazon, dando servicios críticos a miles de clientes, facturando cientos de millones de euros, no disponga de una infraestructura sujeta a unos protocolos básicos de calidad y seguridad no debe tener nada que ver. Que alguien pueda ejecutar un comando que fulmine el sistema sin que salte ninguna alarma es una fatalidad del destino. En fin, el pobre ingeniero que metió la pata se ira al paro, mientras los responsables que cobran millones por gestionar una infraestructura de la que no tienen ni idea dan una rueda de prensa para comunicar que la culpa no fue de Amazon. Ya nos sabemos el rollo: "Ese ingeniero del que usted me habla ya no está en nuestra empresa y no tenemos nada que decir sobre sus actos"
#15:
#2 Tenemos la culpa de TODO porque no nos dejais terminar las cosas.
Y recuerda... https://m.youtube.com/watch?v=udhd9fmOdCs
Y recuerda... https://m.youtube.com/watch?v=udhd9fmOdCs
#10:
rm -rf /
- mierda! Le dado al entre antes de tiempo...
- Ya da igual, déjalo que terminé
Si no que le pregunten al de gitlab, que le paso eso hace unas semanas.
- mierda! Le dado al entre antes de tiempo...
- Ya da igual, déjalo que terminé
Si no que le pregunten al de gitlab, que le paso eso hace unas semanas.
Comentarios
Un simple typo.
Dios mío, llévame pronto.
#1 Just one errata.
#16 De hecho no sé cómo no se ha generalizado la errata, que en el fondo es como un "bug" que se te ha colado al escribir con el teclado... una e-rata.
#16 realmente "error tipográfico"
#1 Un tipo sencillo... ea
#1 Era un tipo el que se equivocó al escribirlo, si hubiera sido una mujer sería una "persona".
#1 Me quedo con las ganas de saber si se trataba de un simple tipo, o un simple topo.
#1 ya tío, lo llaman typo debe tener relación con que los "informáticos" nunca ponen tíldes
Desafortunadamente, una de las entradas del comando se ingresó incorrectamente y eliminó un conjunto de servidores más grande que el previsto.
Está claro, olvidó el where en el delete from .
#7
#7 DELETE FROM users WHERE true; -- ejem... >;)
#7 se le olvidó el where 1=1
#7
:(); :
Se le suele echar la culpa al último mono siempre: piloto de Spanair, conductor del Alvia, operador de red, etc. pero cuando se produce un desastre no es culpa de una persona, detrás hay presiones, recortes, malas arquitecturas.
En este caso parece que un crecimiento demasiado acelerado ha creado una arquitectura poco resistente a fallos. Y eso no es problema del operador, administrador, etc. porque las artquitecturas tienen que diseñarse para que sean resistentes al fallo humano que, inevitablemente, va a ocurrir.
#13 totalmente de acuerdo. El recurso fácil siempre es culpar al soldado raso. Que una multinacional como Amazon, dando servicios críticos a miles de clientes, facturando cientos de millones de euros, no disponga de una infraestructura sujeta a unos protocolos básicos de calidad y seguridad no debe tener nada que ver. Que alguien pueda ejecutar un comando que fulmine el sistema sin que salte ninguna alarma es una fatalidad del destino. En fin, el pobre ingeniero que metió la pata se ira al paro, mientras los responsables que cobran millones por gestionar una infraestructura de la que no tienen ni idea dan una rueda de prensa para comunicar que la culpa no fue de Amazon. Ya nos sabemos el rollo: "Ese ingeniero del que usted me habla ya no está en nuestra empresa y no tenemos nada que decir sobre sus actos"
#13 Si. No deja de ser curioso que una empresa tan opaca como Amazon, que nunca facilita datos sobre sus negocios, en este caso facilite tantos para echarle la culpa al informático.
#13 Ya te digo. Y no sabemos si el tipo o la tipa en question habia trabajado más de la cuenta esa semana, o estaba enfermo porque en USA las bajas por enfermedad no existen o vete a saber.
#13 Dudo que nada de eso se aplique a Amazon Engineering (a otras brancas de la empresa sí y mucho, pero en Eng todo el mundo dice que se curra muy bien). Pero bueno, comentario populista y a disfrutar del karma!
#65 Nunca he tenido claro para que sirve tener más o menos karma. ¿Cómo puedo disfrutar de él, lo puedo cambiar por euros para irme de cena?
#78 Imagínate que mirando la cola de envíos ves algo que no te gusta. Quien lo ha enviado tiene 7 de karma y, como tienes 18, le mandas a -11 de un click.
Ahora solo te queda mirar cómo el resto de la gente le vota negativo con la esperanza de que la descarte y ganar un poco de karma.
Ahí tienes un ejemplo de para qué sirve el karma.
#85 jajajajaa me lo creo, la gente hace unas cosas increibles para incrementar su contador de lo que sea. Supongo que somos esencialmente competitivos, aunque no sirva para nada real.
Yo voto noticias en karma negativo si me interesan. De lo que sí me di cuenta hace años es que si se vota indiscriminadamente se acaba el karma (menos de 6 creo que fué) y no deja votar. Y como le he cogido vicio a eso de votar lo que me gusta me cuido un poco más.
Votar negativa una noticia creo que lo he hecho un par de veces. Algún caso muy insultante, no recuerdo. No le veo mucho sentido a eso en general.
#6 Si, una dejadez tremenda. Mantengamos la salida del producto congelada hasta que no hayamos testeado bien. Pero no mal, ¡bien!
- Hacer la batería de test habituales
- Luego pasaremos los test buenos (no los habituales) los test buenos buenos.
- Más tarde haremos los test de esos fallos que sólo se producen cuando un equipo está en producción: Traigan a un millardo de usuarios repartidos por 4 regiones mundiales y póngalos a tocar las teclas como los monos en noche de luna llena mientras suena de fondo Kandinsky. ¿Pero Kandinsky es un pintor? Eso, eso no se lo esperarán.
- Una vez pasado esos test, haremos las pruebas de fallos que pueden surgir pero que no estaban dentro del protocolo, para ello preguntale a Paco. ¿A Paco? Si, a Paco. Que te haga una lista.
- Llama a Google, Microsoft, Oracle y que te den los fuentes de esas librerías que linkamos, estudialas y prueba cualquier posible error de aquí a los próximo 15 años.
#45 Oye, si les compensa tirar media red por subir rápido a producción ¿quien soy yo para cuestionarlo? para ti la perra gorda,
#46 No, me refiero a que tildas muy rápidamente de dejadez un fallo en producción dando por sentado que no hacen suficientes test en el proceso de calidad. Cuando esto siempre va a ocurrir en cualquier sistema ya que no se pueden controlar todas la variables de un entorno. Si no los aviones no caerían jamás.
#57 Se pueden colar fallos de todo tipo por muy bien que pruebes, ¿pero de este calibre?
#46 Deberías leerte la noticia porque el problema no ha sido que hayan subido rápido a producción sin testear.
#62 Si tienes razón. Con instrucción había entendido instrucción dentro del código. Se cepilló los servidores, entendido.
#82 No has testeado tus comentarios antes de darle a enviar
#45 pues lo que hace Google precisamente es tener una batería de tests automáticos inmensa. Antes de mover a producción hay que pasar todos los tests.
Escribir tests no es complicado pero hay que tener el hábito
#49 Si, y al final siempre habrá un problema en producción o habrá que tratar una optimización del sistema en producción. No hay nada 100% fiable. Y no por eso ha tenido que haber dejadez. Vaya que dudo mucho que la gente de Amazon no tenga los mismos sistemas de testeo que los de Google.
#55 claro, pero entonces hay un test más que tienes que escribir
#5 No seas así y le subestimes. Todos podemos cagarla así ¡y mejor!
#9 "la estupidez real siempre ganará a la inteligencia artificial."
- Terry P
rm -rf /
- mierda! Le dado al entre antes de tiempo...
- Ya da igual, déjalo que terminé
Si no que le pregunten al de gitlab, que le paso eso hace unas semanas.
#10 como si en un entorno de discos virtuales en cabinas SAN de alto rendimiento eso tardase mas que un parpadeo
#12 Si hablamos de la cantidad de datos de Amazon, posiblemente eso si que tarde más de un parpadeo.
#28 realmente no, en cabinas EMC puedes tardar menos de un segundo en cepillarte todas las lun's
#10 Pero no tienes sudo
#23 Incluso con sudo, no funciona sin la opción que le indiqué en #25 como puedes ver en #95.
Ahí no use "sudo" porque directamente pasé a root con "su"(ademas de que nunca tengo "sudo" instalado).
#10 para que eso funcione te falta la opcion "--no-preserve-root", ya que "--preserve-root" está por defecto desde hace bastante tiempo.
https://ss64.com/bash/rm.html
#25 Prueba prueba, ya verás que gracioso. De todas formas, dudo que tengan los datos restrigidos solo a root y los servicios que ejecutan lo hagan con permisos de root.
#27 el root de --no-preserve-root se refiere a /, no al usuario root
#63 Vale, quien pone / , pone /data o /srv o /mnt o /donde/quiera/que/tengas/los/datos/
#c-27" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2742293/order/27">#27
"# rm -fr /
rm: es peligroso operar recursivamente sobre '/'
rm: utilice --no-preserve-root para saltarse esta medida de seguridad"
Como puedes ver, estaba como root al intentar el borrado recursivo del raíz del sistema. En la imagen adjunta puedes ver el comando y lo que responde rm.
Como te indica #63, el preserve-root no es para el directorio personal del usuario root, se refiere al raíz del sistema de ficheros("/").
#95 Viviendo al límite
#27: Me recuerda al "fork bomb", también conocidas como "bomba bifurcación" o "bomba tenedor" que ejecuté en GNU/Linux, el administrador casi me pwnea porque encima se corrompió el sistema de archivos al tener que reiniciar de forma brusca. Bendito sistema RAID 1 con redundancia, me salvo de un pwneamiento seguro.
Yo creía que el sistema estaba preparado para absorber ese tipo de ataque... se conoce que no.
Un consejo: es mejor prevenir que pwnear, en este caso al $luser que haga experimentos.
#100 El sistema tiene ulimit y sysctl, con el cual puedes limitar la cantidad de procesos que ejecuta un usuario, o la ram que puede utilizar(ademas de otros límites).
http://www.linuxhowtos.org/tips%20and%20tricks/ulimit.htm
Tampoco hace falta reiniciar el sistema, solo hacerle un "killall -STOP" y cuando están todos bien dormidos un "killall -9". Aunque esto seguramente solo podrás hacerlo si ya tienes una consola abierta.
Otra opción es utilizar las "magic keys" si están activas te permitirán matar todos los procesos(todos es todos que quede claro), sincronizara los discos, remontar en solo lectura los discos y reiniciar el sistema.
https://en.wikipedia.org/wiki/Magic_SysRq_key
REISUB
R-Teclado en raw
E-Terminar procesos
I-Matar procesos
S-Sincronizar discos
U-Montar en solo lectura
B-Reiniciar
Por otra parte, si es por un proceso que consume mucha ram y te está hiperpaginado hay una tecla que elige uno al alzar entre los que mas ram estén ocupando y lo mata(creo que es f).
Malditos informáticos tenéis la culpa de todo. (Ironía)
#2 Informático aquí: no tienes ni idea
#2 Tenemos la culpa de TODO porque no nos dejais terminar las cosas.
Y recuerda...
#2 Y cada vez más. El caso es cuando vidas dependan de un error informatico...va a ser entretenido.
#21 si por que a los coches toyota no les ha pasado nunca nada en en acelerador relacionaldo con algo informatico
#37 Si no lo retwittea D. Trump no existe!
#38 tengo un gato en la cabeza y me he pasado una bolsa de chetos por la cara JAQUE MATE
#21 ¿Como por ejemplo esa batería antimisiles patriot que tenía error acumulativo en el contador de tiempo que hizo que fallara al detener un ataque y murieran varios soldados?
http://embeddedgurus.com/barr-code/2014/03/lethal-software-defects-patriot-missile-failure/
¿O ese que hacía a los f35 los mas pacifistas del mundo hasta el 2019? https://tabloidenoticias.wordpress.com/2015/01/04/fallo-en-el-software-de-la-computadora-de-armamento-de-los-f-35-impide-que-puedan-disparar-sus-ametralladoras/
Aunque siempre les quedarían el resto de armas del avión.
¿O el que dejo un barco de la marina estadounidense a la deriva porque alguien puso un 0 en un campo de la base de datos MS-SQL causando una división por cero?
https://en.wikipedia.org/wiki/USS_Yorktown_(CG-48)#Smart_ship_testbed
#21 Como cada vez que sales a la calle, te refieres? Semáforos, trenes, metro, aviones... Que crees, que hay un tío detrás de cada semáforo diciendo "ahora rojo, ahora amarillo, ahora verde"?
#31 Aunque si viene un tio con un comando militar también te revienta el chiringuito...
#6 no has tenido que mantener algo en producción en tu vida?
#18 ¿Teniendo miles de usuarios por debajo? Jamás. Hablamos de un ERP.
Lo que me fascina y aterroriza a partes iguales es la evidencia de lo frágil que es este tipo de plataformas, de las que cada vez dependemos más.
#3 es el problema de ejecutar mierda en producción.
#4 Es que cuando se dan problemas en producción se tienen que resolver en producción.
#36 Testeando primero en un entorno de pruebas... si eso.
#66 No siempre es posible. Y menos cuando hablamos de optimización ya que en el entorno de pruebas no se reproduce el problema.
#72 Si tienes un problema en producción, pero en tu entorno de pruebas no se reproduce, tu entorno de pruebas es una mierda y no te sirve para testear cosas antes de pasarlas a prod.
#99 Totalmente deacuerdo. Sin embargo, no todas las empresas se pueden permitir tener un entorno de verificacion exactamente igual que produccion. Hay que tener eso en cuenta tambien.
#66 No es lo mismo un bug que un crash. El entorno de pruebas está antes de llegar a producción, cuando se produce un crash en produccion se tienen que resolver en producción.
#3 bueno...
Si tu tuvieras esos servidores la podrias cagar igual....
#3 Más bien no la dejadez de no testear bien en calidad antes de subir a productivo,
#3 Eso no debería pasar nunca si se hacen las cosas bien. Y aunque todos tenemos un poco romantizadas a las empresas grandes, en todos sitios cuecen habas y se hacen cosas a lo loco, puedes tener tu mercurial, tus entornos currados, CI, pruebas de unidad a muerte y validaciones complejas y al final viene un tio con un comando (una instrucción, no un grupo especial de militares) y te revienta el chiringuito.
#3 La fragilidad de los sistemas siempre ha estado ahí.
Recuerda la leyenda del primer bug https://es.wikipedia.org/wiki/Error_de_software#/media/File:H96566k.jpg
#3 no existe nada 100% infalible. Hay formas de testar automáticamente la plataforma como la que usa Netflix https://github.com/Netflix/SimianArmy pero contra el factor humano no hay nada que hacer.
#73 En cierto sentido Chaos Monkey es una forma de testar contra el factor humano: lo peor que puede pasar es que una parte del sistema deje de funcionar, como le ha pasado a Amazon, y si el resto del sistema es capaz de aislarse de la parte caída y recuperarse sin problemas, entonces por mucho que el factor humano la cague, el sistema en su conjunto seguirá funcionando.
Los mismos de Amazon dicen que los sistemas caídos tardaron "más de lo esperado" en reiniciarse... o sea que no los reiniciaban de forma rutinaria, que es lo que les habría dado un Chaos Monkey, y no se enteraron del problema hasta que fue demasiado tarde.
#84 chaos monkey tambien esta hecho por humanos jaajjaa asi que no tiene porque probar "todo" y los detalles más nimios pueden provocar un desastre...
La he liao parda. Version digital.
Y todos los listillos de meneame intentando dar clases de administración de servidores
#47 Claro, porque tu usas "buena parte de Internet". La caida de S3 us-west se ha notado bastante en el Internet de EEUU, que me atrevería a definir "buena parte de Internet"
#69 Claro, y si se colapsa la m30, se ha colapsado buena parte de las carreteras españolas, porque hay muchos que la usan, pero a mi me que vivo en alicante, plim
A ver, si con analogias lo pillas mejor.
Aparte, es que ¿internet son solo las webs? Joder, pues se ve que si se caen las webs, yo no puedo hacer nada....
#71 Te estás contradiciendo sólo. Si dejara de funcionar la M30 no sería nada sensacionalista (sin ironía) decir que ha dejado de funcionar buena parte/una parte importante de la infraestructura viaria española.
#74 Claro, la m30, que pueden ser ¿100km? tirando a lo alto ¿200km?. Los otros 15000km que hay en españa no cuentan, y que se colapsen 200km (como mucho) es una parte importante de la infraestructura viaria española.
Sabes que eso es la definicion de sensacionalismo ¿verdad?
En todo caso no sería sensacionalista si pusiesen "parte importante de la infraestructura viaria madrileña."
Y no, no me contradigo. Que deje de funcionar unas cuantas webs, no es "buena parte de internet", igual que que deje de funcionar una via, no es una buena parte de la infraestructura viaria española.
#81 La importancia de una infraestructura (y de los servicios de Internet) no es sólo en los kilómetros sino sobre todo en el número de usuarios afectados. Está claro que no ha caído toda Internet por los problemas de una zona de S3, pero ha sido una caída importante, que se ha notado y de la que vale la pena discutir.
#89 ¿No entiendes, que hay una diferencia entre global y local? Para la zona sera grave, para el resto de españa, pues mira, se han colapsado los "centralistas".
Que no todo el mundo gira en torno a "Madrid" (pongasé ahí lo que se quiera, como si quieres poner ombligo).
Falta esto: https://aws.amazon.com/es/message/41926/
"The Amazon Simple Storage Service (S3) team was debugging an issue causing the S3 billing system to progress more slowly than expected."
"At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. "
"Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended."
"The servers that were inadvertently removed supported two other S3 subsystems. One of these subsystems, the index subsystem, manages the metadata and location information of all S3 objects in the region."
"Removing a significant portion of the capacity caused each of these systems to require a full restart. While these subsystems were being restarted, S3 was unable to service requests. "
" While this is an operation that we have relied on to maintain our systems since the launch of S3, we have not completely restarted the index subsystem or the placement subsystem in our larger regions for many years"
"S3 has experienced massive growth over the last several years and the process of restarting these services and running the necessary safety checks to validate the integrity of the metadata took longer than expected"
"The placement subsystem began recovery when the index subsystem was functional and finished recovery at 1:54PM PST."
"We are making several changes as a result of this operational event."
Decir que el desastre fue causado por un typo, es como decir que el accidente de Spanair fue por culpa del piloto. Jamás de los jamases la causa es única.
Menos mal que Amazon tiene claro que tiene que hacer varios cambios en la operativa.
Comunicado oficial de Amazon: https://aws.amazon.com/message/41926/
#68 Hombre, causado fue causado por un typo. Que no hubieran sistemas para paliar/bloquear este error, o que no hubiesen hecho pruebas de reinicio controlado en años es otro tema. Nadie (ni el articulista) está echándole la culpa al sysop/sysadmin/SRE/llamale_como_quieras que le ha dado "enter" al comando equivocado
#90 Sí, el error es de un typo. El impacto viene derivado de lo mucho que han escalado y que los checks de consistencia se fueron muchísimo respecto a los tiempos esperados. Y hasta no completar los checks, no pudieron levantar los servicios dependientes.
No sólo es el typo, derivado de una intervención manual según un procedimiento establecido ejecutado por una persona autorizada. Es el impacto que causó el typo.
Una intervención manual va a tener errores. No sabes cuando ni con qué frecuencia, pero cualquier intervención manual algún día tendrá un error. Lo que Amazon va hacer es limitar su impacto y minimizar los procedimientos manuales.
Lo de buena parte de internet me hace gracia. Es cuando menos alucinante que empresas como airbnb o bussines insider no tengan planes de backup por si su proveedor principal cae.
#34 Claro, solo tienes que pagar y mantener dos infraestructuras.
Btw, se suponte que esto es algo excepcional y que no debería pasar en una empresa como Amazon
#53 Cuando precisamente a Amazon se les paga una pasta para que estas cosas excepcionales no pasen
"buena parte de internet"
como le gusta a los medios dramatizar todo.. nada, otra que voto sensacionalista, por las formas
#22 Lo mismo digo, estos titulares clickbait...
#22 O sea, se caen unas cuantas páginas, de las cuales yo NO USO NINGUNA, y para ellos se ha caído, "buena parte de internet". Si, Objetivos e imparciales, y sobretodo NADA sensacionalistas.
En castellano, gazapo.
Resumiendo
Que ganas que tengo de ver una huelga en Informática.
Os lo traigo en exclusiva:
10 print "Manuela t kiero muxo"
20 GO TO 10.
#14 SYNTAX ERROR
#14
ManuelaCarmenaToda mi vida me acordare de mis 3 días de trabajo perdidos buscando por que un programa no funcionaba como debía.
Y tras días de búsqueda descubrí que había una línea en la que había escrito un "0" en lugar de una "o" mira, para volverse loco.
¿Pero qué clase de typo es este ingeniero?
Little Bobby Tables
https://xkcd.com/327/
https://www.explainxkcd.com/wiki/index.php/Little_Bobby_Tables
Query
https://xkcd.com/1409/
#79 Nunca entendí como el inyection hace tanto daño al php.
Claro que en catalan se usan muchos apostrofes y claro yo siempre guardé en la base de dados con urlencode y al mostrar hacia urldecode.
"Internet se diseñó para aguantar una guerra"
pero no una tecla.
Al final volverá el "Está seguro?" que tanto se ha criticado de windows
Noob.
Es lo que pasa cuando se permiten teclear comandos básicos desde consola para ciertas tareas.
¡Por dios! Para eso se hacen interfaces de usuario para controlar lo que se puede hacer, cuándo, se den advertencias, incluso se requieran acciones y se envíen alertas a un superior o supervisor, etc, etc.
Lo de los comandos está bien para trastear, pero para ciertas cosas..., buff
#56 con los comandos puedes hacer lo mismo loco
#61 Con los comandos no, con los scripts en todo caso. Y un script no deja de ser una interfaz en este supuesto caso.
#64 rm passwords.txt
rm - ¿Borrar el fichero regular "passwords.txt"? (s/n)
#80 Qué simple, una pregunta de sí o no. Das a S y estamos en las mismas, como control es el más básico de todos.
Te pregunta si quieres hacer lo que le has dicho que haga.
El ejemplo sería si en vez de preguntarme eso me dijera que si borro ese fichero va a repercutir en A, B y C. Y si ya nos ponemos más exquisitos que se necesita que esa operación tendrá que ser validada por tal operador para hacerla efectiva.
Pero tú mismo, don erre que erre.
#56 Totalmente de acuerdo. Aunque no se puede descartar que error tipografico haya sido una forma de llamar a un error de procedimiento u otro tipo menos "fortuito". Es como cuando en otras empresas uno toca lo que no debe y luego dicen que "ha habido un error informatico". AWS no puede permitirse el lujo de usar esa excusa
No probaron a reiniciar el sistema?......o internet?
Ahora venid a defenderme mierdas como Javascript, Ruby, Python y demás lenguajes sin tipado.
Malditos ;;;;;;;;;;;;;;;;;
Me parece que tienen lustre como sistema de ficheros, por lo que sé el proceso de arranque es bastante lento.