El efecto 2038 y como probarlo desde C

Ya se habló de sobra del efecto 2000 hace tiempo: los programas que empleasen dos cifras para las fechas podrían considerar que el año 00 no era el 2000, sino el 1900, y calcular incorrectamente cualquier diferencia entre tiempos, con los problemas que podría conllevar.

Pero también existe el efecto 2038: muchos sistemas actuales están programados en lenguaje C (o alguno de sus "derivados") y en estos sistemas la forma "habitual" de contar fechas es como segundos transcurridos desde el 1 de enero de 1970.

¿El problema? En un sistema de 32 bits, como son la mayoría de los actuales, el tipo de datos "time_t" usado para guardar fechas equivale a un "long", un entero largo... y el número de segundos que se puede contar acaba en 2038, en la madrugada del 19 de enero. Un ejemplo para probarlo desde C sería éste

#include 
#include 

int main ()
{
 time_t momento;
 int i;

 momento = 2147483641;
 for (i = 0; i < 10; i++) {
   momento ++;
   printf ( "El instante %ld se convierte en %s\n",
     momento, ctime ( &momento ) );
 }

 return 0;
}

Se supone que es C estándar, debería funcionar tanto desde Windows como desde Linux, y su resultado debería ser algo como:

El instante 2147483642 se convierte en Tue Jan 19 04:14:02 2038
El instante 2147483643 se convierte en Tue Jan 19 04:14:03 2038
El instante 2147483644 se convierte en Tue Jan 19 04:14:04 2038
El instante 2147483645 se convierte en Tue Jan 19 04:14:05 2038
El instante 2147483646 se convierte en Tue Jan 19 04:14:06 2038
El instante 2147483647 se convierte en Tue Jan 19 04:14:07 2038
El instante -2147483648 se convierte en (null)
El instante -2147483647 se convierte en (null)
El instante -2147483646 se convierte en (null)
El instante -2147483645 se convierte en (null)


¿La solución? Debería venir "sóla". En sistemas de 64 bits, y si se usa realmente el tipo "time_t", esto debería ocultar los detalles del hardware, y debería bastar con recompilar el fuente para tener una vida muuuucho más larga. Esperemos que en el 2038 no queden muchos equipos con software de 32 bits y/o que no lo hayan previsto...

Más detalles en la Wikipedia: Efecto 2038
Y en algún que otro sitio más, como El módem

Redescubriendo el Amstrad CPC

Yo me introduje en el mundo de la programación a mediados de los 80, hace ya unos 23 años, con un Amstrad CPC 664. Existen varios foros en español en los que usuarios o aficionados a estos sistemas comentan, todavía hoy en día, formas de crear y optimizar programas para estos equipos, de ampliar su hardware, de conectarlos a un PC...

En parte por nostalgia y en parte por desenterrar conocimientos ya casi olvidados, voy escribiendo a ratos libres una introducción a la programación de Basic para estos ordenadores.

Si te pica la curiosidad...

www.nachocabanes.com/amstrad/curso

Un coche arrastrando un avión

El anuncio del Volkswagen Touareg arrastrando un avión Boeing 747 impresiona. Si no lo has visto, lo tienes (por ejemplo) aquí:

http://www.youtube.com/watch?v=kPC8-7l9Esg

¿Puede realmente un coche "de serie" mover un avión? He estado buscando información y parece ser que sí (con algún "pero"). En un artículo de Serious Wheels detallan (en inglés) los preparativos y el proceso.

Pero claro, se trata de un coche "casi de serie"... con 310 caballos de potencia, con un precio cercano a los 60.000 dólares (*), no es "un coche normal". Es el modelo equipado con motor V10 TDI, al que se hicieron apenas unas mínimas modificaciones. Además, se cargó con 4.345 kg extra para asegurar una mejor tracción en el momento de la arrancada (una vez que se ha comenzado a andar, mantener el movimiento no es problema).

En cuanto al "objeto a mover", es un avión de 155 toneladas de peso, 4 motores, un fuselaje del tamaño de un bloque de pisos, 450 asientos, una superficie alada de 511 m2...

Si quieres ver un video un poco más detallado (5 minutos, en inglés), aunque también algo propagandístico:

http://www.youtube.com/watch?v=9sO_xmXiQqM

(*) En cuanto al precio en España, en una primera búsqueda no he encontrado precio oficial para el V10 TDI, pero el FSI de 280 caballos anda entre 52.000 y 56.000 euros, según versiones, y el 4.2 V8 salta de los 70.000 euros. Como siempre, los coches nos resultan más caros en Europa que en Estados Unidos... incluso los de origen europeo.

Portátiles por menos de 100 dólares

El proyecto OLPC (One Laptop Per Child) pretendía crear portátiles de bajo coste, que pudieran llegar a cualquier lugar desfavorecido del mundo. Según las directrices del visionario Negroponte, debían tener un precio cercano a 100 dólares, para que fuera cada gobierno el que los comprara y los distribuyera en sus escuelas.

Debían ser, además, equipos capaces de funcionar en sitios en los que no existiera electricidad, por lo que el primer prototipo tenía una manivela para cargar la batería. El fabricante, el taiwanés Quanta (que parece ser el mayor fabricante del mundo, que crea portátiles para casas como HP, Dell y Acer) optó también por una pantalla dual, capaz de trabajar en color y en blanco y negro, incluso sin iluminación posterior, para reducir el consumo, y con detalles como la posibilidad de seguir leyendo la pantalla mientras el procesador está suspendido, para actuar como si fuera un libro. El sistema operativo sería de código abierto, basado en Linux, y los equipos contarían con 256 Mb de memoria RAM y 1 Gb de memoria flash en lugar de disco duro (puedes ver más detalles -en inglés- en la información publicada por Quanta y la presentación -en español- del proyecto en su página oficial, laptop.org).



Pero resulta que los costes de fabricación están ahora mismo en el entorno de los 175 dólares (puedes ver artículo original en 20 minutos) y se habla de que sería necesario una demanda de al menos 3 millones de equipos para rebajar esos costes hasta el valor esperado. En mi opinión, aunque haya claramente más de 3 millones de personas en situación de subdesarrollo, no es tan fácil que los países en vías de desarrollo vayan a hacer una inversión tan grande...



Además, se ha hablado que hay conversaciones con Microsoft para que este equipo pueda trabajar con Windows, lo que ha parecido mal a muchos de los defensores del proyecto. A mí también me sentaría mal después de que el señor Gates hubiera despreciado con anterioridad el proyecto con frases como "ten un ordenador decente donde puedas realmente leer el texto y no te sientes allí dándole cuerda mientras intentas teclear" (nota original en 20 minutos, de marzo de 2006). A lo mejor no se da cuenta de que no todos tienen su holgura económica. Un año después parece haber rectificado su postura y habla de un paquete de software que contiene (nota original en PcWorld, en inglés) Windows XP Starter Edition, Office Home and Student 2007, Windows Live Mail, y alguna otra aplicación por un precio de 3 dólares (sí, tres) para estos países desfavorecidos (¿será ese el software que pretende incluir en la máquina de OLPC?).

Pero el caso es que hay otros países con capacidad de producción y que han tomado ideas. En un artículo de 20 minutos (descubierto gracias a barrapunto) se habla de que India pretende llegar a fabricar portátiles a 10 dólares (el desarrollo tardará cerca de dos años) y que de momento ya tiene un modelo por 47 dólares.

A ver si alguna de estas iniciativas termina de cuajar y la "aldea global" se hace realmente global, no sólo una "aldea de países desarrollados"...

Crackeando ficheros ZIP

A raíz del último post, me he preguntado cuanto tiempo se tardaría en descubrir claves usando "fuerza bruta" en el caso de que hubiera además que acceder a un fichero que contenga la información encriptada. Un caso típico sería el de intentar descubrir la contraseña de un fichero Zip.

Como era de esperar, los resultados en un caso "normal" no son tan favorecedores para el "atacante" como los que aparecían en el Blog original. En mi caso, un Zip con una contraseña de 3 letras ha tardado más de 10 minutos en encontrarla.

Ha sido un ataque "poco eficiente". En concreto, he usado un programa muy simple y que accedía continuamente a un descompresor externo. En estas circunstancias, ha tardado 11 minutos y 42 segundos en probar 10.159 contraseñas de tres letras. Eso quiere decir que era capaz de probar "sólo" 14,5 contraseñas por segundo (como curiosidad, esos son tiempos medidos en Windows; este mismo fuente compilado bajo Linux, y funcionando en circunstancias similares era capaz de probar 125,3 contraseñas por segundo, casi 9 veces más rápido).

Entonces, saquemos cuentas para claves formadas sólo por letras minúsculas (26) o por cualquier carácter ASCII imprimible de 7 bits (95 símbolos, aunque muchos compresores permiten también usar contraseñas con caracteres extendidos).

Longitud de la contraseña	Cualquier ASCII imprimible	Sólo minúsculas
1 carácter 2 caracteres 3 caracteres 4 caracteres 5 caracteres	6,55 segundos 10,37 minutos 16,42 horas 65,01 días 16,92 años	1,79 segundos 46,62 segundos 20,20 minutos 8,75 horas 9,48 días

Como se ve, en ataques tan simples, una contraseña de 5 símbolos no alfabéticos para un fichero ZIP ya daría una seguridad razonable. Pero sólo contra ataques así de simples.

¿Mejoras posibles? Innumerables, claro. Pero se puede hacer que sea MUCHO más rápido apenas con tres cambios:

• No usar un descompresor externo, sino una rutina de descompresión que sea parte de nuestro fuente, con lo que se evita la carga debida a la llamada a un programa externo.
• Si tenemos los datos en memoria, en vez de leer el fichero para cada prueba, también se ganaría mucha velocidad.
  
• No escribir en pantalla cada clave que se prueba, y menos todavía usando el modo de consola de Windows.
  

Queda como reto para quien se atreva con ello... ;-)


Por cierto, el fuente de prueba, para los curiosos, era simplemente así (C estándar, usando un descompresor que usa el parámetro -s para indicar la contraseña y -o para sobreescribir resultados en vez de pedir confirmación si el fichero ya existe):

#include <stdio.h>
#include <stdlib.h>

int main() {
  int resultado;
  long contador = 0;
  char clave[4]="aaa";
  char orden[200];
  char a,b,c;

  for (a='a'; a<='z'; a++)
    for (b='a'; b<='z'; b++)
      for (c='a'; c<='z'; c++) {
           clave[0] = a;
           clave[1] = b;
           clave[2] = c;
           printf("Probando: %s...\n", clave);
           sprintf(orden, "unzip -s%s -o 1.zip", clave);
           resultado=system(orden);
           contador++;
           if (resultado == 0) {
             printf("\n\nEncontrada. Es: %s\n", clave);
             printf("Claves intentadas: %ld\n", contador);
             return 0;
           }
         }
  printf("Clave no encontrada!");
  return 1;
}

Es fácil tu contraseña?

¿Es tu contraseña fácil de adivinar? En One Man's Blog se hace un estudio (en inglés) del tiempo que tardaría en encontrarse una contraseña por "fuerza bruta" (probando todas las posibles combinaciones), según la cantidad de letras que la forman, y según si emplea todos los caracteres posibles o sólo letras en minúscula. Las cifras asustarían a la mayoría de gente:

Longitud de la contraseña	Cualquier letra	Sólo minúsculas
3 caracteres 4 caracteres 5 caracteres 6 caracteres 7 caracteres 8 caracteres 9 caracteres 10 caracteres 11 caracteres 12 caracteres 13 caracteres 14 caracteres	0.86 segundos 1.36 minutos 2.15 horas 8.51 días 2.21 años 2.10 siglos 20 milenios 1,899 milenios 180,365 milenios 17,184,705 milenios 1,627,797,068 milenios 154,640,721,434 milenios	0.02 segundos 0.46 segundos 11.9 segundos 5.15 minutos 2.23 horas 2.42 días 2.07 meses 4.48 años 1.16 siglos 3.03 milenios 78.7 milenios 2,046 milenios

Vemos que una contraseña de 5 caracteres que estuviera formada sólo por letras minúsculas (ej: nacho) se podría descubrir en 11.9 segundos... o menos. Si al menos tuviera alguna cifra numérica, algún signo de puntuación y/o alguna mayúscula, se necesitaría (como mucho) unas dos horas.

Lo razonable es no bajar de las 7 letras, y que incluyan algún carácter que no sea letras en minúscula, porque si un atacante necesita 2 años para encontrar nuestra contraseña, generalmente no se molestará en intentarlo.

Pero la cosa puede ser peor:

• Son tiempos estimados para un "ordenador medio". Si se usa un ordenador de gran potencia, se podría tardar todavía menos (y los ordenadores tienen cada vez más potencia, lo que quiere decir que cada vez será necesario menos tiempo).
• Hay ataques todavía más rápidos: si usamos como contraseña una palabra que pueda aparecer en diccionarios, los tiempos de búsqueda pueden ser muchísimo menores.
• También se puede acortar si el "atacante" conoce a su "víctima", porque mucha gente usa contraseñas como el nombre de su mascota, o de su pareja, su número de teléfono o de DNI...
• Y también está la opción de atacar a través de otras páginas que "la víctima" frecuente, como foros de internet, porque mucha gente usa la misma contraseña (o un número muy reducido de contraseñas), de modo que se puede descubrir en un sitio "débil" y ya tenemos el acceso a todos los demás sitios.
  
• Si se tiene acceso al ordenador del "atacado", la situación puede ser enormemente fácil, simplemente mirando las cookies de su navegador, porque la mayoría de gente no se molesta en borrar la información privada al terminar la sesión (a pesar de que en Firefox se puede hacer de forma automática).
  

Así que ahora te toca meditar... ¿es fácil descubrir tu contraseña?

Recuerda: tienes el artículo original (en inglés) en One Man's Blog.

Calidad en programas pequeños

Cuando uno empieza a programar, muchas veces confunde un programa de calidad con un programa "vistoso". Por eso, voy a repasar algunos de los factores de calidad más frecuentes, y lo apoyaré con algún ejemplo aplicado a programas de pequeño tamaño (menos de 300 líneas de código, por ejemplo). Estos ejemplos en la mayoría de los casos los acercaré a lenguajes como C y C++.

Corrección
El programa es correcto si hace lo que el usuario quería que hiciera.
Un ejemplo: Tengo que calcular las soluciones de una ecuación de segundo grado. Aplico la fórmula x1 = (- b + sqrt(b*b - 4*a*c) ) / 2 * a ... Pero debería dividir entre (2*a), he olvidado un paréntesis, así que la solución es incorrecta. Si no hago suficientes pruebas (por ejemplo, sólo miro la ecuación x2 - 4 = 0), es fácil que se me escape.

Fiabilidad
El programa es fiable si se comporta correctamente, incluso en situaciones inesperadas. Esto incluye los casos en que los datos que recibimos no sean los correctos.
Ejemplo: ¿Qué hace mi programa si no existe el fichero de datos? ¿Y si el usuario teclea una texto en vez de un número?

Eficiencia
Un programa es eficiente si la cantidad de recursos y de código que necesita para realizar una función son razonables.
Ejemplo: voy a abrir un fichero de configuración, pero no sé manejar memoria dinámica, así que reservo espacio para 10.000 líneas... por si acaso.

Seguridad
Es el grado en el que se controla el acceso al programa o los datos por usuarios no autorizados.
Ejemplo: Mi programa tiene un interfaz web. ¿Puede un usuario entrar directamente a la pantalla de visualización de datos, sabiendo su URL, sin haber pasado antes por la pantalla de validación?

Facilidad de uso
Indica el esfuerzo necesario para aprender, manejar, preparar entradas e interpretar la salida de un programa.
Ejemplo: ¿Tiene el usuario información en pantalla sobre las teclas que debe usar? ¿Hay ayuda disponible? ¿Se puede salir pulsando ESC o hay que pulsar Ctrl+Alt+Mays+S?

Mantenibilidad
Es el esfuerzo requerido para localizar y corregir un error en un programa en funcionamiento (el programa debería ser fácil de leer, fácil de modificar)
Ejemplo: ¿Uso siempre variables de una sola letra, o nombres más significativos? ¿Pongo comentarios en lo que no es evidente? ¿Tengo funciones de 300 líneas o de 20 líneas? ¿Están disponibles los diagramas de diseño?

Facilidad de prueba
Es el esfuerzo necesario para probar un programa (cuando se quiere garantizar que realiza la función deseada).
Ejemplo: ¿He creado una función que recibe parámetros y devuelve resultados, de forma que pueda hacer pruebas repetitivas, contrastando los resultados obtenidos con resultados conocidos? ¿O está todo dentro de "main" y sólo puedo hacer pruebas tecleando valores?

Flexibilidad
Indica si es fácil modificar un programa que ya está en funcionamiento.
Ejemplo: si decido que la variable "contador" no debería ser un "int", sino un "long", ¿tendré que modificar muchas partes de mi programa?

Portabilidad
Es el esfuerzo requerido para trasferir un programa de una configuración hardware o entorno software a otro.
Ejemplo: He creado mi programa de prueba con Windows, que es lo que tengo en casa. ¿Funcionará en el Linux que hay instalado en mi centro de estudios, o he usado funciones exclusivas de Dos/Windows, como getch o clrscr?
Y otro caso "más profesional": voy a crear pequeño programa con interfaz gráfico. ¿Todos los usuarios lo manejarán siempre desde Windows? ¿O me puede interesar usar una biblioteca multiplataforma como Qt o Gtk, por si algún usuario prefiere (o necesita) usar Linux o MacOs X?

Reusabilidad
Es el grado en que lo que se ha desarrollado para un programa se puede utilizar en otras aplicaciones.
Ejemplo: Voy a hacer un programa parecido, pero con ciertas posibilidades nuevas. ¿Podré aplicar lo que he hecho o tendré que volver a crear muchas cosas que ya hice?

Interoperatividad
Es una medida del esfuerzo necesario para acoplar un sistema con otro.
Ejemplo: ¿Podré hacer que mi utilidad lea los ficheros de datos que manejaban las demás aplicaciones del sistema? ¿Y los ficheros de datos que genere se podrán manipular directamente desde aquellas? ¿Podré incluso pasar datos "al vuelo", sin necesidad de usar ficheros intermedios?


Como se puede ver, todo son "puntos a tener en cuenta", pero en la mayoría de los casos no existe una forma clara de "medir" hasta qué punto se ha conseguido aplicar un cierto criterio. Aun así, aunque no se pueda decir "ahora mi programa es el doble de portable que antes", deberíamos considerar estos puntos cuando programamos, para acercarnos a ese "programa de calidad" que pretendemos hacer.

Referencias (hay muchas fuentes de información en Internet; éstas son sólo por citar unas cuantas):

Breves notas sobre la Medición de los Atributos Externos del Software
http://www.sc.ehu.es/jiwdocoj/mmis/externas.htm

La importancia de las buenas prácticas en el desarrollo de aplicaciones Java
http://www.als-es.com/home.php?location=recursos/articulos/buenas-practicas-java

Aspectos de Calidad en el Desarrollo de Software Basado en Componentes
http://www.lcc.uma.es/~av/Publicaciones/02/CalidadDSBC.pdf

A Pattern Framework for Software Quality Assessment And Tradeoff
www.eelke.com/research/literature/SQTRF.pdf

Food for Thought: How Do You Define Software Quality?
www.swqual.com/newsletter/vol1/no4/vol1no4.html

Vuelve el Google Summer of Code

¿Te apetece trabajar durante el verano en un proyecto Open Source, ganando 4.500 dólares, y teniendo a Google como mentor?

Pues el tiempo se acaba. Hasta el 26 de marzo está abierto el plazo de solicitudes para el Google Summer of Code 2007. Este es el tercer año. En 2005 se admitieron cerca de 400 estudiantes, que aumentaron hasta unos 600 en 2006, y esa es la previsión de admisiones para este año.

No es una oferta de trabajo, pero a nadie se le escapa que si el estudiante resulta bueno en su trabajo, tiene posibilidad de incorporarse en la empresa con la que haya colaborado. Y es que hay que recordar que el hecho de que un proyecto sea Open Source no quiere decir que no genere dinero. Muchas empresas generan una buena cantidad de dinero a partir de la consultoría sobre productos Open Source, o en algunos casos con versiones "profesionales", que ofrecen más prestaciones.

Puedes colaborar en proyectos como Gnome, KDE, OpenOffice.org, Apache, Mono, FreeBSD, OpenSolaris, Ubuntu, Gentoo, MySQL, PostgreSQL, Firefox, Wine, WxWidgets, WordPress, Moodle, ... Si te animas, la lista completa la tienes disponible (en inglés, "por supuesto") en:

http://code.google.com/soc/

Y recuerda: las solicitudes sólo se admiten durante 10 días... y ya han pasado 5...

Un PC de 26.000 dolares

Los de PC-Welt deben aburrirse.

El caso es que se les ha ocurrido montar un "Super-PC". Y les ha salido una maquinita de unos 26.000 dólares.



Su nombre es Höllenmaschine II (algo así como "máquina del infierno 2"). Incluye "detallitos" como:

• Dos procesadores Xeon DP 5355 de cuádruple núcleo a 2,67 Ghz.
• Nueve discos duros SAS (Serial Attached SCSI) con un total de 4,3 Terabytes (incluyendo un extraible de 750 GB).
  
• 4 módulos de memoria dual channel Corsair CM73DD1024R-667, de 1 Gb cada uno.
• Dos tarjetas gráficas basadas en Nvidia Geforce 8800 GTX, con soporte para DirectX 10.
• Una unidad de Blu-Ray 2x (capaz de grabar un disco 25 Gb en 45 minutos, además de leer y grabar CD y DVD).
• Una fuente de alimentación de 1.000 W (qué menos, con tanta maquinaria dentro).
• Una pantalla Benq de 24" que soporta hasta 1920 x 1200 puntos... acompañada por una pantalla táctil de 8".
• Una tarjeta de sonido Sound Blaster X-Fi Fatality FPS acompañada de un conjunto de altavoces inalámbricos envolventes.
• Una caja echa a medida por uno de los modders más prestigiosos, y acabada con pintura de coche Porsche. Sólo la pintura cuesta cerca de 1000 dólares.
  

¿Quien se atreve a hacerse uno similar para casa...? ;-)

El artículo completo (en inglés) en www.pcwelt.de/news/englishnews/Hardware/74058/index.html

Wikia: la búsqueda se hace Wiki

Hay quien considera que los algoritmos de búsqueda de Google, aunque en general son muy buenos, más de una vez colocan en posiciones altas una información que no es realmente relevante, lo que hace perder tiempo a los usuarios.

Por eso, existe gente que propone una "alternativa humana". Esto ya ocurrió con la "wikipedia", una enciclopedia "abierta", en la que cualquiera puede editar un artículo, y que cada vez gana más adeptos, lo que a su vez está permitiendo que cada vez sea una fuente de información más grande y más fiable (a fecha de escribir este texto: 1.605.383 artículos en la versión inglesa y 193.217 artículos en la versión en español, que todavía tiene mucho camino por recorrer)

Jimmy Wales, creador de la Wikipedia, sugiere crear un buscador (Wikia) en el que puedan ser los propios usuarios los que den más peso a la información que consideren más relevante. El proyecto ya está en marcha, pero todavía en pañales. Las comparaciones duelen: buscar la palabra Pascal da mas de 70 millones de resultados en Google... y 0 resultados en Wikia (!). Esperemos que los usuarios lo acojan con la misma ilusión que a la Wikipedia y se convierta pronto en una herramienta realmente útil.

Más detalles, en

http://search.wikia.com/wiki/Search_Wikia

y si lo que quieres es saber más sobre Jimmy Wales, deberías acudir a la Wikipedia (ya sabes... preferiblemente en inglés):

http://en.wikipedia.org/wiki/Jimbo_Wales

El formato "Big Endian" y el "Little Endian"

Estas palabras se usan para referirse a las dos formas en que se pueden guardar los números que ocupan más de un byte.

Vamos a verlo usando como ejemplo el número 5. Si lo expresamos en binario con 4 bits, su equivalencia es 0101. Si lo hacemos con 8 bits, sería 00000101. Pero si usamos más de un byte para representarlo, por ejemplo porque se tratara de un número "entero corto", usando la nomenclatura del lenguaje C, tenemos que el número 5 equivaldría a 16 dígitos binarios: 00000000 00000101.

Por tanto, ahora este número 5 queda representado como 2 bytes. El de la izquierda es el byte más significativo (MSB) y el de la derecha es el bit menos significativo (LSB). Estos nombres vienen de que un cambio en el byte de la derecha hace que el número cambie poco (por ejemplo, 00000000 00000100 = 4 en decimal), mientras que un cambio en el byte de la izquierda provoca cambios mucho más grandes (00000001 00000101 = 261 en decimal).

Pues bien, según la arquitectura del ordenador puede ocurrir que esos dos bytes se guarden en el orden que hemos visto: 00000000 00000101 (primero el MSB y luego el LSB) o al contrario (00000101 00000000). Lo primero, que a priori es lo que podría parecer más natural, es lo que se hace en procesadores como los de la familia PowerPc (usados en muchos ordenadores Apple, por ejemplo). Lo segundo, aunque parezca más enrevesado, es lo que se hace en la mayoría de procesadores de Intel, como los usados en los ordenadores PC.

El primer formato (MSB LSB) es lo que se conoce como Big Endian, porque eso de que el extremo más grande aparece en primer lugar. El segundo formato (LSB MSB) es lo que se conoce como Little Endian, porque se almacena primero el dato más pequeño.

¿Y eso en qué afecta a un programador? En que muchas veces deberemos saber con qué plataforma se ha creado un fichero de datos, para poderlo interpretar correctamente.

Por ejemplo, si leemos un fichero que contiene un dato "entero corto", de 2 bytes, formado por la secuencia 00000101 00000000, y ese fichero se ha creado con un ordenador basado en un Pentium u otro procesador de Intel (Little Endian), podemos suponer que ese número es un 5. Por el contrario, si el dato se ha creado desde un equipo Apple clásico, la secuencia 00000101 00000000 estaría en formato Big Endian, luego equivaldría al número 1280.

En general, en caso de que un fichero contenga datos numéricos de más de un byte, deberíamos saber si están almacenados en formato Little Endian o Big Endian, e intercambiar el orden de los bytes después de leer, si fuera necesario.

Como primera curiosidad, existen arquitecturas que permiten escoger la "endianness" que se prefiere usar (como IA64, MIPS y ARM) y que reciben el nombre de "bi-endian". En estos sistemas, normalmente este cambio se puede hacer por software (al arrancar el equipo,por ejemplo), pero en algún caso se ha de realizar por hardware (como podría ser cambiando un jumper en la placa base).

Como segunda curiosidad, el nombre de "Big Endian" y de "Little Endian" se tomó irónicamente de "Los viajes de Gulliver", en que aparece una discusión sobre si un huevo hervido debería empezar a comerse abriéndolo por su extremo pequeño o por su extremo grande.