-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-22 a las 00:35 +0100, Camaleón escribió:
El 21/03/08, Carlos E. R. escribió:
Sí había limitación de hardware. Unos cuanto kb era lo máximo que podían poner, y tenías que ser de la CIA o la NASA para conseguirlos.
Tú no has visto las placas de memoria de ferrita, tamaño A3 para un cuarto de kilobyte.
Hay que aprovechar al máximo los recursos disponibles. La memoria era escasa pero no inexistente. Y hay, lo que llama, "prioridades".
Ese error fue, claramente, un error "humano", falta de visión o "mente de programador" (centrada en un objetivo) que les llevó a valorar de una forma errónea el significado real de lo que estaban haciendo.
Mira, la wiki lo explica perfectamente en el artículo del Y2K:
*** http://en.wikipedia.org/wiki/Y2k
"(...) the first person known to publicly address the problem was Bob Bemer who had noticed it in 1958, as a result of work on genealogical software. He spent the next twenty years trying to make programmers, IBM, the US government and the ISO aware of the problem, with little result. This included the recommendation that the COBOL PICTURE clause should be used to specify four digit years for dates. This could have been done by programmers at any time from the initial release of the first COBOL compiler in 1961 onwards. However, lack of foresight, the desire to save storage space, and overall complacency prevented this advice from being followed." ***
Pobre Bob... intentando explicar a los programadores ¡que estaban equivocados! :-)
"Falta de visión, deseo de ahorrar espacio..." Hum, qué raro, no dice nada de "memoria físicamente no disponible" >:-)
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. 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__.
Al contrario, era una decisión lógica de uso eficiente de los materiales existentes.
Una decisión lógica, no, yo diría más bien "arbitraria", donde no se valoró más que una variable: la memoria. Ese fue el gran error.
Una variable _fija_, que no estaba en su mano aumentar. No fué un error.
Pues eso, se quita del siglo, que este ordenador no va a durar tanto.
Premisas, todas ellas, que el tiempo ha demostrado que eran incorrectas. Hay que ser (o intentar ser) "globales" -y no sólo en informática-, hay que prever no el "hoy" ni el "ahora", sino ir más allá del momento actual porque no sabes qué puede pasar ni cómo se van a desarrollar las cosas: esa es la belleza del orden... y del caos.
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.
"El aleteo de una mariposa en Hong Kong puede desatar una tormenta en Nueva York..."
Eso es una tergiversación de la teoría del caos, a la que se agarran los periodistas.
Creo que la informática en general debería desarrollar un pensamiento más científico para poder interactuar de una forma más precisa con el entorno que la rodea... sería más efectiva... sería casi, perfecta.
Sí. Ahora. No los pioneros.
No, la gestión original era correcta para los recursos que tenían.
Según esa teoría, nunca existiría el error :-): siempre se trabaja en base a lo que se conoce, eso es obvio, pero disponer de datos "limitados" no te exime -ni justifica- el fracaso. Hay que "saber (o aprender a) prever".
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. 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.
En el caso de los discos duros el fallo de los sectores está previsto. Hay por ahí una probabilidad estadística que te da la tasa de sectores fallados por cuestiones como simple ruido estadístico.
¿Y no hay por ahí alguna directriz que indique qué hacer en caso de fallo? >:-)
Claro que las hay. Pero no toda la documentación es abierta y conocida.
No se ignora.
No, bueno... lo parcheas :-) Pero ¿cómo evaluas la efectividad del parche?
¿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 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.
No, no es suerte. Sólo se cuelga cuando el sector en cuestión contiene un fichero imprescindible. Tiene que darse una serie de circunstancias para producir el cuelgue, no basta con tener un error de lectura.
Todo eso que acabas de decir, es, precisamente, lo que se considera como "suerte":
suerte. (Del lat. sors, sortis). Encadenamiento de los sucesos, considerado como fortuito o casual
:-P
Pos llámalo como quieras... los puentes no se caen por suerte. No se, yo no me acerco a los rascacielos. Puede caerse una piedrecita o un tornillo de los cristales por mala suerte y romperme la crisma.
Porque en cada prueba aumenta >:-)
Un error fortuito es una cosa. Un error que va aumentando es otra muy distinta.
También aumenta de 1 a 2, o de 2 a 5... ¿En qué dato científico, lógico, comparable y reproducible basas, pues, tu decisión de que el 6 es "la hora de cambiar de disco"? >:-)
No me decide el 2 ni el 6 ni el 10 ni el 50. Me decide el hecho de que aumenta en cada prueba. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH5XIxtTMYHG2NR9URAg5iAJ4zoxLTJn7/lg0Yg84mougRkxU9uwCggqq7 oSlRK0Tudzw7V6UQ+WUYFbo= =EA9P -----END PGP SIGNATURE-----