El 22/03/08, Carlos E. R. escribió:
Yo he tenido que regatear byte a byte el código de programas para que cupieran en la memoria que tenía disponible. No sólo quitas el siglo de los años, quitas los decenios y lo que haga falta. Si tienes que medir alturas de 100 metros, pones un shortint cuyo máximo es 127. Es una labor de encaje de bolillos, de Ingeniería con mayúsculas, de aplicar el ingenio para conseguir resultados con los míseros medios disponibles.
Pero no se puede extrapolar a todas las situaciones a un caso particular, eso no es ser objetivo :-). Nadie dice que la gestión eficiente de la memoria sea una tarea sencilla (ni antes ni ahora), pero tampoco imposible. Y si tienes que "ahorrar" memoria o espacio, ¿no hubiera sido mejor sacarla de otro sitio? Hasta hoy día la fecha nos trae de cabeza en los equipos modernos: el ordenador necesita saber en qué tiempo vive (lamentablemente aún hoy no lo puede calcular de forma automática, todo llegará... :-P) pero es una de las primeras cosas que tienes que configurar cuando instalas un sistema operativo, fecha y hora... ... y es una de las pocas cosas de las que tienes que preocuparte que esté correctamente configurada... o se te puede ir todo al garete (servidores web, programas, cálculos...). La fecha, en un sistema informático, es casi tan importante como la memoria o el disco duro: entrada de datos incorrectos --> procesamiento erróneo --> resultado de salida falso No es una variable "susceptible de recorte" para ahorrar.
Los programadores iniciales no erraron en absoluto. La metedura de pata fué de los que vinieron después, que no se molestaron en rehacer los códigos que estaban diseñados para una época de escasez de recursos.
Oye, que hasta los impresos te ponían el 19__.
La metedura de pata fue de todos ellos; unos por no valorar correctamente de dónde sacar más espacio o más memoria y los otros por infravalorarlo (o ignorarlo) cuando ya no suponía un problema físico...
Una variable _fija_, que no estaba en su mano aumentar. No fué un error.
Oh, claro que estaba en su mano: era su elección, podían haber ahorrado de cualquier otra forma, siempre hay alternativas. Y obviamente, esa elección fue un error.
Eso lo tenían que hacer los que decidieron reusar código antiguo. Los que ahorraron tiempo y sueldo de programadores en no modernizar las cosas.
"Tiempo y sueldo" no deben interferir en la calidad de un programa. Ahora, año 2008, sí. Antes, años 1960, no. La informática estaba sólo al alcance de unos pocos, grandes empresas o gobiernos y los programas cumplían funciones específicas: desde el control de centrales eléctricas hasta el cálculos de estructuras. Mientras que los los programadores actuales suelen tener menos de 25 años, los de antes no tenían menos de 40... quiero decir con ésto que el "lo quiero para mañana y si no está documentado, mejor" dudo que se diera en aquélla época (y dudo que se también ahora en sectores industriales críticos que dependen casi por completo de los ordenadores).
Eso es una tergiversación de la teoría del caos, a la que se agarran los periodistas.
¿"Tergiversación"? Ninguna. No es más que un ejemplo gráfico que intenta resumir una teoría compleja. Que la relación "causa-efecto" es difícil de calcular y que no siempre el derrotero de las cosas sigue el cauce establecido...
Sí. Ahora. No los pioneros.
No, antes y ahora. Es más, antes "era más científica". La mayoría de los programadores tenían conocimientos sólidos de matemáticas, biología o física. Eran matemáticos, biólogos o físicos :-). La informática no era más que un medio para demostrar una teoría o para agilizar los procesos manuales. Ahora, esa esencia original se ha perdido, la informática es el "fin", no el "medio". Los informáticos (y todas las disciplinas, en general) se han especializado tanto que nos hemos vuelto "uni-disciplinares" y sólo unos pocos individuos (muy pocos) son capaces de desarrollar una visión "multi-disciplinar", casi "renacentista" de las cosas, es decir, ser capaces de una abstracción tal que les permita saber (prever) la mayor parte de las situaciones y procesos.
Mira, eso es como diseñar un puente para 20 toneladas y 15 años de uso, y luego pretender seguir usandolo 5 años más y con trailers de veinte ruedas. Las cosas se diseñan con unas premisas, unos materiales, unos costos, unas limitaciones, y unos resultados. El ingeniero trabaja con lo que le dan. Quejarse de que lo que hace no es eterno es absurdo. No se diseñó para eso.
Me quejo, me quejo... y me quejo porque el puente tiene fecha de caducidad, lo pone en el contrato, firmado por el ingeniero y el arquitecto: "este puente de características x tiene una esperanza de vida de n años". ¿Y qué sucede con el programa? ¿Dónde pone la fecha de caducidad? No la tiene y por lo tanto, queda al azar si su funcionamiento se convierte en errático cuando pasen "x" años... y queda al azar proque nadie se ha responsabilizado de ello.
El error es o de los politicos que inicialmente no presupuestaron un puente más capaz, o de los políticos posteriores que no presupuestaron su substituto a tiempo. Pero no del ingeniero, que cumplió perfectamente con lo que le pideron.
Como excusa está bien :-). Pero eso no es así. Está claro que quien construye el puente (peones de obra) no tienen culpa de nada, no es su trabajo ni su responsabilidad. Para eso está en "autor conceptual" del trabajo: el arquitecto (o ingeniero). Este no "pica", piensa, desarrolla y planifica. No "pica", pero se responsabiliza de su obra al 100%.
Claro que las hay.
Pero no toda la documentación es abierta y conocida.
No la hay, no se puede predecir con exactitud el fallo de un componente, por eso precisamente están los pre-avisos y las alertas.
¿Y como evaluas la efectividad de los sectores que un disco que no ha fallado nunca? No puedes. Simplemente ese disco ha caido del lado afortunaco de la estadística.
Los campos magnéticos que se graban en los discos modernos son ridículamente debiles. Están en el margen de lo indetectable: que se puedan leer es casi un milagro. Hay una tasa de error estadístico que te dice que las lecturas del disco van a fallar varios miles o millones de veces, y lo puedes medir:
9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 5136 195 Hardware_ECC_Recovered 0x001a 060 047 000 Old_age Always - 188948838
De esas dos variables no hemos estado hablando en este hilo. Las horas de funcionamiento no es un valor que se pueda "reparar" como un sector defectuoso. El otro valor indica las recuperaciones automáticas que ha llevado a cabo el disco de forma transparente ¿no? pues es lo que debe hacer... cuando no puede hacerlo el disco, aparece el otro error, que requiere la intervención del usuario.
Ese disco (320.0 GB) ha tenido 188.948.838 fallos. ¡Unos 188 millones de fallos! Pero son errores que el hardware ha conseguido recuperar, es decir, corregir el fallo a base de bytes redundantes del propio sector. Es normal que en todos esos millones de fallos de vez en cuando se produzca uno algo mayor que afecte a demasiados bytes, de tal forma que la redundancia prevista sea incapaz de corregirlo: ya tienes un error "incorregible" de manera automática. El disco reporta un error y deja al sistema operativo o al usuario que decida como corregirlo.
Otro disco más antiguo (40.0 GB):
9 Power_On_Hours 0x0032 076 076 000 Old_age Always - 21285 195 Hardware_ECC_Recovered 0x001a 100 253 000 Old_age Always - 0
no ha tenido ni un solo error de esos, porque usaba una tecnología menos compacta y más fiable.
La antigüedad no es un factor "per se" de fallo. En este caso, creo que es más importante el hecho de que sea un disco duro que está en un equipo portátil (susceptible a golpes o a un calentamiento elevado) que las horas de uso.
Pos llámalo como quieras... los puentes no se caen por suerte.
Huy, sí... el "factor azar" también hay que tenerlo en cuenta. Suele ser además, "factor determinante"... ¿es que no conoces las leyes de murphy? ;-)
No me decide el 2 ni el 6 ni el 10 ni el 50. Me decide el hecho de que aumenta en cada prueba.
Pero no es un valor fijo... es una apreciación tuya, personal, que puede ser correcta, o no. A eso voy. Ya tenemos bastante "indeterminación" en esta vida como para tener que estar adivinando si el aumento "de 1 a 5" o de "5 a 7" supone un factor o no de riesgo :-P. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org