¿Cuánto ocupa el código fuente del Chrome?

Lo elija o no como navegador predeterminado en su PC (yo sigo por ahora con el Firefox ), el Chrome ofrece una nueva mirada al sancta sanctorum de la informática: el código fuente. Es muy cierto que tenemos toneladas (literalmente) de líneas de código en Internet, y que el Firefox es open source desde su nacimiento.

Quizá no me expliqué bien.

Google ya ha hecho público bastante código y Linux ( www.linux.org ), Apache ( www.apache.org ), MySQL ( www.mysql.com ), PHP ( www.php.net ), Python (www.python.org) y miles de otros proyectos son de código fuente abierto, incluso algunos son GPL, es decir, software libre ( www.gnu.org ). Es más, en enero de 1998 Netscape fundó el proyecto Mozilla y abrió sus fuentes. Pero ésta es la primera vez que podemos mirar tan de cerca un emprendimiento de la que hoy es la mayor compañía de Internet, cuya acción en Nasdaq supera los 400 dólares y que ha enfrentado sin hesitar al más poderoso de los gigantes de la era informática, Microsoft.

Aunque el Chrome era una intriga y, como narré en mi última columna, lo instalé tan pronto estuvo en línea, lo que realmente me interesaba era ver las dimensiones y la organización de su receta. La versión 2.04 del Firefox tiene un código fuente de 318 megabytes (MB) en casi 38.000 archivos. Sí, todo eso hace falta para que uno se baje un instalador, le dé doble clic y a los 30 segundos esté navegando por la Web. Sin entrar en detalles de estilo de programación, ni mucho menos de las soluciones dadas a cada problema, lo que en general me excede ampliamente, ¿qué tanto código hace falta para hacer algo minimalista? La respuesta sería realmente sorprendente.

Hablamos idiomas diferentes

Para que nadie se quede afuera, aquí van los básicos del tema. Advertencia para expertos: lo que sigue contiene, por razones obvias de espacio, una cantidad de simplificaciones y reduccionismos. Su lectura puede causar temblores y mareos, sobre todo en personalidades sabelotodo. Si en lugar de seguir mi consejo y saltarse hasta el próximo subtítulo, el lector entendido insiste en proseguir, los síntomas pueden calmarse rápidamente recitando stdio.h de atrás para delante. De memoria, claro.

Las computadoras, más precisamente sus microprocesadores, no entienden los lenguajes humanos. Los humanos, opuestamente, son capaces de entender el lenguaje de las máquinas; es más, han diseñado ese lenguaje. El problema es que escribir código en lenguaje de máquina es como vaciar una pileta olímpica con un cuentagotas usando para presionar la perilla una pinza de depilar controlada por medio de unas tenazas de doce metros de largo. Es posible hacerlo; de hecho, vi a mi padre programar así, hace unos 40 años. Como él siempre dice, todavía recuerda la instrucción para sumar: "Era 7070, o tres llavecitas para abajo". Porque aquella máquina, además, no tenía teclado. Ni pantalla. Se usaba una cinta perforada por toda interfaz.

Con la complejidad del software actual, programar en lenguaje de máquina resultaría completamente impracticable. Por eso usamos lenguajes de alto nivel, como C, C++, Eclipse, Java, Basic, Pascal y muchos otros. Son de alto nivel porque están cerca de nuestra forma humana de pensar, no porque sean más chic.

Estos lenguajes dejan mucho que desear en términos de expresar cosas humanas, pero mediante un conjunto de palabras reservadas, una sintaxis inflexible y procedimientos claros y previsibles pueden usarse para decirle a la computadora lo que queremos que haga.

Esas líneas escritas por personas en un lenguaje como C o Pascal, que contienen las instrucciones y los datos que constituyen un programa de computadora, se llaman en conjunto código fuente .

Por supuesto, los microprocesadores no entienden ni C, ni Pascal ni nada de eso, así que una vez que el código fuente está terminado hay que dar un paso más: traducirlo al lenguaje de máquina , un proceso denominado compilación. Técnicamente es más complejo y tiene más pasos (creación de código objeto, creación del ejecutable o linking, y por otro lado existen lenguajes de nivel más bajo, como Assembler (Ensamblador, en español), que no son tan arduos como el lenguaje de máquina ni tan confortables como los de alto nivel, pero permiten manipular con más detalle el hardware y producen programas más rápidos. Hoy sólo se los usa para algunas rutinas especiales).

La compilación del código fuente produce el software que ejecutamos en Windows, Mac, Linux o cualquier otra plataforma. Se los llama binarios , aunque en rigor también las imágenes y los sonidos son archivos binarios .

De los binarios ejecutables no se puede obtener exactamente el código fuente, así que los programas son el pastel y el código fuente, la receta. Usando herramientas especiales puede examinarse la receta y sacar algunas conclusiones, incluso alterar el programa, lo que en general está prohibido por la licencia de los autores, pero nunca obtendremos exactamente la fórmula exacta con que se lo fabricó. Entre otras cosas porque diferentes compiladores producirán diferentes binarios a partir del mismo código fuente.

De la misma forma, podemos saber que el pastel tiene vainilla, un toque de naranja y tal vez jengibre, pero no tendremos ni la menor idea de exactamente cuánto y cómo hay que poner de cada ingrediente.

Las compañías comerciales de software, como Adobe, Autodesk y Microsoft, han guardado bajo siete llaves el código fuente de sus programas. Si vendés pasteles no tenés ni la menor intención de hacer pública la receta de tu éxito.

Lo que el open source vino a demostrar es bastante obvio: que el software no es igual a los pasteles. Aunque hay muchas variantes de licencias para distribuir el código fuente, lo cierto es que la movida alimentó los negocios de Google, Thawte, Nokia (en la Ayuda de sus teléfonos puede verse la dirección de donde bajar partes del código que hay en sus dispositivos) y cientos de otras compañías, además de incentivar la liberación de código por parte de gigantes como IBM e impulsar los progresos de Internet, cuyos protocolos y aplicaciones se originaron en una época en la que el código fluía mucho más libremente, mucho antes de la PC; la Red mayormente ha mantenido esa política.

Pero tras más de 25 años de aplicaciones de código cerrado, el open source supone una revolución copernicana, donde el código fuente ya no es el centro del universo. El soporte y los servicios lo son.

Y esto vino a ajustar como anillo al dedo con la lógica Internet, donde todo parece ser gratis pero se sostiene sobre un conjunto de servicios, como el de la conexión, que pagamos regularmente.

Así que el código fuente, que suena como algo que sólo les compete a los expertos, se encuentra en el centro de un cambio que involucra a toda la industria y, por lo tanto, afecta nuestras vidas. Además, sí que nos importa a los que no somos programadores. ¿Por qué? Porque si el código fuente es público, entonces es mucho más difícil que alguien inserte funciones indeseables en un programa (puertas traseras, espías).

Por ejemplo, ¿tiene sentido usar software para encriptar sin tener el código fuente? ¿O acaso hay ahí escondida una puerta trasera que las agencias de seguridad del país de origen podrían usar, llegado el caso?

Una anécdota que me cuenta un amigo, para ilustrar este punto: cuando Unix era muy nuevo, Ken Thompson, uno de sus autores, insertó un bug en el código fuente para que el sistema aceptara una contraseña maestra, en manos de Thompson, evitándole así pedirla a los usuarios cada vez que tenía que reparar una estación de trabajo. Ese bug se arrastró luego durante años, hasta que fue descubierto. Así que incluso con las fuentes a la vista es posible insertar esta clase de "puertas ocultas", aunque con la cantidad suficiente de ojos que escrutan el código al final se las descubre.

La moraleja de Thompson, en este extenso y muy técnico artículo ( http://cm.bell-labs.com/who/ken/trust.html ), es muy dura: "Uno sólo puede confiar en el código que uno mismo crea". Desde luego, esto ya no es posible en un mundo con 2500 millones de personas que usan computadoras e Internet.

Entienda uno o no el código, y el 99,99% de nosotros no lo entiende, lo que importa es que el open source combinado con la comunidad de programadores e Internet prácticamente no puede esconder nada. Mucho menos Google, por el nivel de atención que acapara.

La compañía ha apoyado y liberado mucho de su código en su primera década de vida, aunque sigue manteniendo en secreto la fórmula de su éxito, es decir, los algoritmos de su buscador. Chrome parece reafirmar que seguirá apostando a esa forma de hacer software, una forma que le resulta estratégicamente útil.

Ahora era tiempo de ver cómo hace una de estas corporaciones tan mediáticas y poderosas para escribir un programa.

Gigante, pero bien organizado

Obtener el código fuente de los programas, cuando está disponible, es para el usuario no técnico entre muy sencillo (caso de Firefox ) y bastante complicado (caso de Chrome ). Las complicaciones no son porque sí, sino para garantizarles a los desarrolladores y revisores que tengan la versión más reciente, y además los programadores están más que habituados a sincronizar su almacén de código con un servidor remoto. En el caso del Chrome hay que bajarse un software llamado depot_tools y seguir las instrucciones que figuran en esta página: http://dev.chromium.org/developers/how-tos/build-instructions-windows

La cosa se puso interesante al ejecutar el comando de sincronización. Veía el disco duro muy activo y bajaban muchos datos desde Internet. Esperé un rato largo. Hasta que me di cuenta de que no iba a detenerse en 300 MB, ni en 500, ni en un GB. Me fui y lo dejé descargando código.

Al día siguiente me costaba creer las dimensiones del proyecto: 207.282 archivos en 23.948 carpetas. En total, 2,5 gigabytes. Esto, para un simple navegador Web. Es más, para un navegador minimalista .

Cierto es que dentro de esa suma está todo el V8 (el motor de JavaScript que usa Chrome), la extensión para crear aplicaciones Web de Google, llamada Gears , y una cantidad de cosas más. Pero allí estaba. Había ido por lana y salí trasquilado. Esperaba unos 500 MB de código. Me encontré con dos gigabytes y medio. Sólo en el subdirectorio browser hay casi 660 MB.

No obstante, esta inmensa cantidad de código estaba obsesivamente organizada en módulos y carpetas; internamente, el estilo es prolijo y bien documentado. Como debe ser, por otro lado. Me hubiera gustado compilarlo, pero no tenía ni el tiempo ni las herramientas. Se necesita el Visual Studio 2005 , así que lo dejaré para más adelante.

Al cierre de esta edición, encontré una buena nota (en inglés) sobre la experiencia de compilar el código de Chrome en InfoWorld, escrita por Neil McAllister http://weblog.infoworld.com/fatalexception/archives/2008/09/building_google.html .

Le pregunté a la compañía cuánta gente trabajó para producir esa enormidad de código; aunque es cierto que hay muchas líneas tomadas de fuentes externas, el sólo hecho de organizarlas y adaptarlas ya es una tarea colosal. Google me respondió que trabajaron 40 ingenieros y 60.000 testeadores internos. No se me ocurre cómo hicieron para que ninguno de esos 60.000 individuos soltara ni una palabra sobre el tema.

La mayor deuda que le encontré a esta experiencia, en general positiva, es que, como afirma de forma tajante Google en su sitio para programadores, "No hay una versión de Chrome funcional para Linux todavía" ( http://dev.chromium.org/developers/how-tos/build-instructions-linux ). Una pena.

Por ahora, me suscribí http://dev.chromium.org para recibir las actualizaciones. Habrá que esperar.

Por Ariel Torres

---

Conforme a