Mailinglist Archive: opensuse-es (1145 mails)

[Camaleón <noelamac@xxxxxxxxx>]

El 2009-03-17 a las 13:13 +0100, Rafa Grimán escribió:

> > > El Tuesday 17 March 2009, Camaleón escribió:

> > Por eso mismo. Que el sistema se cuelgue, es normal.
>
>
> Pero _NO_ debería serlo.

No, claro, pero sucede.

> > Que haya apagones, también. Que no haya un SAI, también.
>
>
> No debería ser normal no tener un SAI.

Hombre, no todos tienen los recursos necesarios para tenerlo y no por 
ello tienen que arriesgar sus datos cada vez que encienden el equipo O:-)

> > Componentes en mal estado, pues también.
>
>
> No debería ser normal tener componentes en mal estado.
>
> ¿Por qué estos ejemplos que pones se consideran "normal" o aceptables? En un 
> coche _NO_ son aceptables. Por lo menos nadie en su sano juicio conduce un 
> coche cuyas ruedas están lisas sin dibujo o cuyos frenos no funcionen o 
> se "cuelguen". Nadie compra pantalones rotos (bueno, a menos que sea la 
> última moda y quieras ser la super-estrella ... nunca he entendido las 
> modas). Nadie compra comida caducada. Nadie va a un dentista cuyas manos 
> huelen a pie.
>
> Esto es lo mismo. ¿Por qué en la informática es normal? ¿Por qué se acepta 
> como normal que no haya SAI, que no haya backup, que las cosas se cuelgan? 
> _NO_ señor.
>
> Sí, son inventos hechos por Humanos y, por tanto, imperfectos por lo que 
> tienden a fallar (de ahí los MTBF). Se acepta que haya un % de error. Pero es 
> que en la informática se acepta un % de error enorme: es "normal" Y ESO QUE 
> _TODO_ DEPENDE DE LA INFORMÁTICA (banca, sanidad, ...).

A ver. Te pongo el ejemplo del sector que conozco. Ingeniería y 
construcción. ¿Las casas se caen? Hombre, pues no es lo normal. 
¿Pero _no_se caen? pues sí, pero se contruye con teniendo en cuenta 
(ni te imagians) una cantidad de variables no "precedibles" (no sabes 
cuándo) pero si esperables (vientos, tipo de sulo, tipo de construcción, 
zona sísmica, etc...).

Nadie espera un terremoto en Valencia, pero hace poco hubo temblores de 
escala 4. No pasó nada porque la normativa actual es bastante clara, 
cocisa y segura.

Yo espero lo mismo en informática, espero la misma fiabilidad y que que el 
hecho de apagar el sistema a lo bruto no termine en una pérdida de datos.

La parte por el todo no puede ser, no es de rigor. Los problemas hay 
que aislarlos y no pueden afectar a todo el conjunto, sólo, claro está, 
en casos extremos. Por ejemplo, si quito el pilar central de un 
edificio, con el tiempo y factores externos se acabará por derrumbar. 
Pero no compares quitar un pilar base con apagar el sistema de forma 
abrupta :-)

Uno sucede (o puede suceder) a diario y el otro no, es un caso aislado 
y extremo.

> > ¿Y cómo debe actuar el sistema en esos casos? Fácil: problemas de
> > hardware, debe registrar errores de acceso (lectura y escritura).
> > Problemas más serios, pues también debería regsitrarlos.
>
>
> 1º Ver rollo que he escrito más arriba ;)
>
> 2º Se podrán registrar los errores que no bloqueen el sistema, que 
> sean "normales", que sean previsibles ... pero los que no entran en esas 
> categorías ... va a ser difícil.

Bueno, me refería a los errores de hardware más que de software. 
Obviamente, si el sistema deja de responder, también deja de responder 
la gestión de ¿casi todo? :-) No sé qué nivel o rango de acción tienen 
los desarrolladores del kernel en ésto, es decir, qué es registrable y 
qué no :-?

> > Si el usuario no tiene datos, no puede saber que hay un problema y no
> > puede solucionarlo.
>
>
> Pero si compras hardware (memoria RAM, por poner un ejemplo) malo y te falla 
> (lo normal) ... ¿qué datos guardas si están todos corruptos o bien se han 
> esfumado? Si la placa base es mala ... los datos que se transmiten pueden 
> corromperse o bien un problema de tensión te puede dañar el disco de forma 
> que NO puedes acceder al disco: ¿dónde guardo qué datos?

Ya, pero te das cuenta en el momento, lo cambias y listo. En cambio, un 
fallo del sistema de archivos que no escribe los datos porque se piensa 
que están escritos pero realmente no lo están (eso es lo que comentabas 
hace poco) pues te deja a dos velas: ademaś de perder datos, no sabes 
el alcance de esa pérdida, que puede hacerte que tengas que volver a 
instalar de nuevo porque el equipo se cuelga de manera inesperada (por 
ejemplo) cuando antes no lo hacía y no sabés el motivo (¿será por el 
problema que tuve al apagarlo a lo bruto aquél día o fallará la fuente, 
o quizá el disco duro tenga algún problema...?)

¡No sabes nada! Si al menos registrara los datos que elimina :-P

> > Si el sistema se cuelga, el sistema de archivos debería poder
> > gestionarlo. Es un evento esperable, y tendrían que estar preparados
> > para ese tipo de errores.
>
>
> Si el cuelgue es por un módulo de RAM o controladora de disco defectuoso, 
> ¿qué 
> datos y dónde se guardan? Si el sistema de refirgeración del procesador es 
> defectuoso y hace que el procesador realice cálculos erróneos, ¿me puedo fiar 
> de ellos aunque los guarde?

Pero si los hoy en día los componentes funcionan sin electricidad :-P. Está 
la hibernación, la suspensión y seguro que habrá algún otro estado más 
de ahorro. El disco duro debería tener incorprado algún sistema de seguridad 
adicional. A ver, no te digo que haga milagros, pero si todos los 
componentes del equipo están en buen estado ¿por qué un simple apagón 
hace que pierdas datos? No sólo le puedes echar la culpa al hardware 
sino también a la gestión que hace el sistema con los archivos.

¿Qué tenemos, memoria ram? Pues que la usen, que el disco vuelque los 
datos a la ram (a modo de buffer) y que pueda recuperarlos y volver a 
escribirlos en disco antes de desecharlos y dejar el archivo a 0 bytes.

> > No te digo hace 30 años, pero hoy en día, pues sí.
>
>
> No digo que estés equivocada. Lo que digo es que no es tan fácil como te 
> imaginas/piensas.

No, supongo que no lo es, pero merece la pena mejorar la seguridad de 
los datos.  

> > Se avanza mucho en hardware pero poco en software :-(
>
>
> IMHO, se avanza demasiado y se asienta (aka depura y profile) poco :( Es 
> decir, se introducen demasiadas novedades (¿features?) sin asentar y depurar 
> las que ya existen.

Sí, cierto. Hay mucha cantidad y poca calidad. Y lo que es peor, en 
algunos casos se pierden funcionalidades.

> > Las cosas que no se pueden precedir, también se gestionan. Y eliminar
> > datos del disco no es precisamente lo más deseable.
>
>
> Pero es que a lo mejor esos datos nunca llegaron a disco, luego no estás 
> eliminando los datos ... simplemente nunca existieron ;)

Pues que los pases a algún sistema secundario de almacenamiento :-P

> > ¿Qué datos se eliminan y en base a qué? ¿Archivos de configuración de
> > programas, archivos necesarios para el inicio del sistema? ¿Se
> > elimina al azar, no hay prioridades? Una cosa así no puede quedar al
> > libre albedrío :-/
>
>
> En el caso que nos atañe (KDE pierde ficheros de configuración). No es que se 
> produzca al azar, es que KDE lo ha hecho mal. Es decir, no crea un fichero 
> temporal en el que guarda los datos y luego renombra. Si hiciera esto (crear 
> un fichero temporal, borrar el original y luego renombrar), la probabilidad 
> de pérdida de datos sería mucho menor. En este enlace lo explican mejor:
>
> http://mjg59.livejournal.com/108257.html

Los archivos de configuración de kde es lo que ha visto, sencillamente 
porque lo ha ido a utilizar y le había desaparecido ¿pero... qué más se 
ha perdido? :-?

> > Si se puede apagar, se apagará. Hay que programar con esa premisa,
> > pensando siempre en sucesos probables. Hardware en mal estado,
> > apagones, bloqueos o cuelgues son variables "posibles".
>
>
> Sí, son predecibles, lo malo es ¿cuándo se van a dar? Si se sabe el cuándo, 
> se 
> puede programar al sistema de ficheros o al kernel o al driver o a quien sea 
> para que guarde los datos al disco o a dónde sea.
>
> Por cierto, estoy de acuerdo contigo en que hay que mejorar el software.

:-)

> > Y de una buena programación. Ya te digo que de nada sirve prever y
> > tener toda la seguridad si el sistema está mal diseñado porque no se
> > ha previsto que el equipo se puede quedar colgado en cualquier momento.
> > Y eso es algo que sucede a diario. No sabe "cuándo", pero se sabe "qué" y
> > "cómo". Algo se podrá hacer para evitar esa pérdida de datos.
>
>
> Para empezar, se puede intentar dirigir las medidas (inversión en desarrollo) 
> a intentar evitar cuelgues porque el sw esté mal desarrollado. Pero esto no 
> interesa: mola más añadir una nueva feature que depurar un driver (o una 
> aplicación cualquiera). En cuanto a las empresas: tres cuartos de lo mismo, 
> da más prestigio añadir una nueva funcionalidad que corregir cuelgues.

Como pasa con los controladores de las tarjetas gráficas, no importa 
que se cuelguen o rendericen el 2D a paso de tortuga con tal de que 
el juego de última hornada les dé un benchmark bueno para las revistas :-( 
 
> > Puedo esperar perder datos si lanzo el equipo por la ventana, o si se
> > quema en un incendio. Pero no espero perder datos si se va la luz :-)
>
>
> Si se va la luz, hay que tener en cuenta una serie de cosas:
>
>       - es un evento impredecible en cuanto a cuándo se va a producir.
>         Que se va aproducir: sí, alguna vez se tiene que dar, pero
>         cuándo ... es difícil predecir
>
>       - la razón por la que se produce es impredecible también:
>         ¿fenómeno atmosférico? ¿La señora de la limpieza ha
>         desenchufado el servidor y ha enchufado la aspiradora?
>         ¿El usuario ha pulsado el botón "sin querer"?
>
>       - el material informático es 100% DEPENDIENTE de la electricidad
>         por lo que a nivel sw no hay nada que se pueda hacer, la
>         solución TIENE que ser por hardware: baterías, por ejemplo.
>         Por sw NO se puede solucionar ya que si falla la luz -> falla
>         el hw -> falla el sw ya que el sw DEPENDE del hw que a su vez
>         depende de la luz.*
>
>
>
> * Por poner un ejemplo sencillo: una bombilla. Ya puedes tener el mejor de 
> los 
> filamentos o gas o lo que sea la bombilla que tienes que si se va la 
> corriente ... adiós luz aka veo menos que un plátano liado en un trapo aka 
> oscuridad. Es inmediato. Ahora diréis: "Ya, pero hay gases que permiten 
> mantener una combustión durante X tiempo por lo que la luz (incandescencia) 
> no desaparece de golpe y bla, bla, bla, ..." Esto es una solución hardware y 
> sería similar a usar un SAI o una batería o un condensador o lo que sea, NO 
> es una solución sw.

Es que en una bombilla predomina hardware, o la cambias o la cambias. 
Además, las de bajo consumo o las led duran más >:-)
 
> Otro ejemplo: un coche. El conductor sería el sw, el coche el hardware y la 
> gasolina la electricidad. Por muy buen conductor que seas, por muy previsor 
> que seas, ... si pillas un bache y se te arranca el depósito de pronto 
> (equivalente a se va la luz de pronto) o el motor se para. Sí, ya si vas 
> cuesta abajo o vas a 270 KM/h no paras en seco, pero eso sería una solución 
> HW (física, inercia) y no de sw (tu, conductor).

Pero si el coche hubiera tenido algún sensor inteligente que detecte el 
firme, el bache lo hubiera evitado o le hubiera avisado al conductor 
("oye, que tienes un desnivel a tantos metros, activa los 
amortiguadores o reduce la velocidad...") >:-)

> > Las SSD basadas en DRAM tienen algunas ventajas.
>
>
> Pero siguen DEPENDIENDO de la electricidad. Si falla la luz, es inmediato el 
> fallo a menos que haya un HW por en medio que garantice cierta corriente 
> (batería, por ejemplo). El sw no puede hacer nada porque es una capa superior 
> que DEPENDE de las que hay abajo, por lo que si las de abajo fallan ... lo de 
> arriba falla. Y si lo de abajo falla impredeciblemente ... lo de arriba no 
> puede hacer nada.

Suspendes a ram o suspendes a 
"poner-aquí-X-componente-que-permita-almacenar-datos-para-luego-recueprar
los" :-P

> > Este problema afecta a la mayoría de sistemas de archivo, así que nadie
> > se libra, con empresa gorda detrás o sin ella.
>
>
> Incluso afecta a sw que no es sistema de ficheros ;)

También :-)

> > No se puede precedir el factor tiempo (cuándo) pero sí qué es lo puede
> > hacer (subir o bajar las acciones, si hará lluvia, sol o viento). Pero
> > hay variables con las que sí se puede jugar. Sabes qué le puede afectar
> > al sistema de archivos (apagón, bloqueo, hardarwe, componente lógico...)
> > pues solucionemos las variables de las que sí tenemos información.
>
>
> Pero es que lo que precisamente te interesa saber es cuándo para poder estar 
> preparado en ese momento. Por ejemplo el tiempo, sé que va a llover (o al 
> menos eso creo y espero ;), pero lo que me interesa saber es cuándo para 
> saber si salir con paraguas o sembrar o ponerme chanclas o quedarme en casa y 
> comprar un SAI por si cae un rayo y me estropea el ordenador ;)

Pues llevas siempre el paraguas encima :-P
 
> En cuanto al ordenador, también: me interesa saber cuándo va a fallar el 
> componente (sea hw o sw) porque ya sé que va a fallar, lo que no sé es 
> cuándo. De ahí que haya cosas como SMART, redundancia, alta disponibilidad, 
> disaster recovery, business continuance, ... De lo contrario (si supiéramos 
> cuándo va a fallar), no nos haría falta todo eso, lo haríamos por sw ;)
>
> Por cierto, sé que va a tocar la lotería, pero quiero saber cuándo y dónde 
> ... 
> para ir y comprarla !!!!
>
> Como decía Niels Bohr: "Es difícl hacer predicciones, especialmente si son en 
> el futuro" ;)

Si no compras lotería seguro que nunca te toca ;-)

Saludos,

-- 
Camaleón 
-- 
Para dar de baja la suscripción, mande un mensaje a:
   opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
   opensuse-es+help@xxxxxxxxxxxx