Jon «maddog» Hall: Entrevista exclusiva para AT

Esta es otra de las entrevistas más esperadas y que tenía muchas ganas de hacer, ya que es con el gran Jon «maddog» Hall. Alguien que no necesita presentaciones y que es una de las figuras más conocidas dentro del mundo del software libre.

Si quieres conocer un poco más de Jon Hall, y también algunas primicias sobre BSD, cosas interesantes sobre seguridad, RISC-V, LSB, LPI, y mucho más, te invito a leer la entrevista completa…

Architecnología: Siempre comienzo con esta pregunta: ¿Quién es Jon Hall? (Descríbete, por favor)

Jon «maddog» Hall: Blanco, hombre, barbudo (desde 1969), gordo, viejo, técnico, amigable (la mayoría del tiempo), tranquilo (excepto cuando no estoy tranquilo), casero (excepto cuando viajo el 50% del tiempo).

AT: ¿Cuándo y cómo te empezó a interesar la tecnología?

J.H.: Cuando era muy joven tenía un vecino de al lado jubilado que reparaba todo tipo de cosas como gramolas, relojes, radios, grabadoras de hilo (predecesoras de las grabadoras). Su colección me asombraba.

Empecé a leer revistas como Popular Science, Popular Mechanics y, finalmente, Popular Electronics. Ayudé a mi padre a montar juguetes complejos (odiaba leer las instrucciones) en una juguetería.

Más tarde, cursé tres años de taller de electrónica en el instituto. Diseñamos y construimos receptores y transmisores de radio (electrónica analógica) y me fui al Instituto Tecnológico Drexel a estudiar Ingeniería Eléctrica.

Mientras estaba en Drexel (ahora Universidad de Drexel) empecé a programar, sobre todo leyendo libros y practicando por mi cuenta. Con el tiempo hice más y más programación y se me daba bien. Por otro lado, mi ingeniería eléctrica no iba muy bien, así que cambié de carrera (y mis notas mejoraron drásticamente).

Otra cosa que ocurrió en esta época… me familiaricé con el grupo de usuarios de DEC, DECUS, y cómo los usuarios de DEC escribían programas y los publicaban por el coste de una copia (a menudo en cinta de papel). Escribían libremente su código, lo discutían libremente y compartían libremente sus fuentes. Conocí el «Software Libre» mucho antes que el proyecto GNU y la FSF, y a lo largo de mi vida profesional siempre tuve acceso al código fuente de los sistemas que utilizaba.

Al igual que Richard Stallman, me gustaba mirar el código fuente para ver cómo funcionaba, y a menudo corregía errores en el código que recibía de otras personas.

Todavía colecciono y reparo relojes mecánicos, así como instrumentos musicales automatizados. Sí, me gusta la tecnología de todo tipo.

AT: ¿Has tenido algún referente? ¿Alguien que te inspire?

J.H.: Tengo muchos «héroes personales». Alan Turing encabeza actualmente la lista junto con la contralmirante Grace Murray Hopper. Mi madre y mi padre (Mom&Pop™) también me inspiraron, aunque ninguno de los dos era muy técnico.

AT: Y ¿por qué «maddog»? Es broma jajaja, ¡No suspires! No te forzare a decirlo 1001 veces. La pregunta real es: ¿Cuándo/Cómo tuviste tu primer contacto con Linux?

J.H.: Mi primer contacto con Linux fue a través de una revista de informática llamada «Dr. Dobb’s Journal of Computer Calisthenics and Orthodontia»: Running lite without over-byte» (sí, ese era el nombre). Era alrededor de noviembre de 1993, y en la parte de atrás había un anuncio de «un sistema Unix completo con todo el código fuente» por 99 dólares.

Yo llevaba trece años en la comunidad Unix y sabía que AT&T se querellaría si vendía el código fuente de Unix por esa pequeña cantidad de dinero, pero…. envié mi dinero y recibí un CD-ROM con un pequeño manual que me decía cómo instalarlo en mi PC Intel.

El único problema era que no tenía ningún PC Intel. Tenía sistemas DEC VAX, sistemas DEC MIPS, sistemas DEC Alpha….pero ningún PC (aunque DEC fabricaba PCs).

Sin embargo, monté el CD-ROM en mi sistema DEC Alpha y miré las páginas man(1). Me impresionó, pero simplemente guardé el libro y el CD-ROM en mi archivador.

En mayo de 1994 cuando conocí a Linus Torvalds en DECUS en Nueva Orleans me di cuenta de que la cosa en mi archivador era realmente Linux, y cuando volví lo saqué de nuevo y miré.

Era la distribución Yggdrasil.

AT: Eres presidente de la junta directiva de LPI, ¿cómo convencería a los lectores de la importancia de las certificaciones de código abierto en la actualidad?

J.H.: Hay un par de maneras diferentes de responder a esta pregunta:

¿Son importantes las certificaciones? Yo creo que sí. Cuando vas a la escuela, los profesores determinan lo que debes aprender (el plan de estudios), luego te presentan la información, te examinan y finalmente acabas con un diploma o certificado. Ese trozo de papel le dice al mundo que has aprendido un tema concreto y que te han examinado de él. Lo sabías «lo suficientemente bien».

Tanto si haces un curso como si estudias por tu cuenta, un certificado le dice al mundo que al menos conoces la información lo suficientemente bien como para pasar el examen. Por supuesto, también puedes conseguir cartas de recomendación de tu empleador o cliente.

En segundo lugar, aunque no hagas el examen ni obtengas la certificación, el hecho de que los objetivos del examen estén disponibles en línea te permite estudiar por tu cuenta. Si lees todos los objetivos y dices «Sí, me los sé todos», probablemente estés bien. Si lees un objetivo y no tienes ni idea de lo que están hablando, tal vez deberías estudiar ese objetivo un poco más.

En tercer lugar, hemos visto que, en igualdad de condiciones, las personas que tienen una certificación respetada pueden ganar mucho más dinero que alguien que no está certificado.

AT: La Linux Foundation tiene sus propias certificaciones de administración de sistemas. ¿Tiene sentido mantener las certificaciones LF y LPI separadas? ¿Una fusión podría ser beneficiosa?

J.H.: Creo que tener diferentes certificaciones para elegir es algo bueno. LPI también separa nuestras certificaciones de la formación. Esto permite que la gente se forme de la manera que quiera, incluyendo el autoestudio. Tenemos socios que se encargan de la formación de nuestras certificaciones si la gente quiere seguir la formación, pero no están obligados a seguirla.

AT: ¿Cuándo será posible usar una distro Linux para hacer los exámenes LPI? Puesto que ahora solo está disponible para Windows y macOS…

J.H.: Actualmente, el principal sistema de entrega de exámenes de LPI en todo el mundo es VUE. También ofrecemos exámenes en papel en grandes eventos. Somos conscientes de que es deseable tener otras formas de realizar los exámenes.

AT: En 2013 estuvieste envuelto en el proyecto de portado a ARMv8. ¿Qué piensas ahora sobre RISC-V? ¿Piensas que este se transformará en una nueva «Arm» y lo veremos en todo tipo de máquinas (PC, embebidos, dispositivos móviles, HPC,…)?

J.H.: Me gusta más el modelo de negocio de ARM que el de Intel, y me gusta más el concepto de RISC-V que el modelo de negocio de ARM, simplemente por su «apertura». También me gustan los esfuerzos de colaboración en torno a RISC-V, y cómo están intentando aprender de los últimos sesenta años de magia negra informática y hacer un sistema más limpio y agradable.

Sí, creo que veremos chips RISC-V en todos los lugares que has mencionado, e incluso más. La «cuota de iniciación» para entrar en el desarrollo y el uso de RISC-V es mucho menor que la de ARM, así que creo que veremos a muchos más «fabricantes» e investigadores utilizando RISC-V como punto central.

AT: Para LSB, los paquetes deberían distribuirse en formato RPM, sin embargo, los paquetes DEB son los más populares debido al éxito de las distros basadas en ese paquete. ¿Debería introducirse un cambio teniendo en cuenta lo ocurrido? Quiero decir que las normas también deben ser flexibles para adaptarse a las necesidades actuales.

J.H.: Me gustaría que LSB tuviera estándares para los paquetes DEB, pero también creo que la parte más difícil de crear un estándar para GNU/Linux no es el gestor de paquetes. En el momento en que el desarrollador consigue las bibliotecas, compiladores y otras cosas correctas, la gestión de paquetes es mucho más fácil, EMHO.

Sin embargo, el LSB está ahora bajo el control de la Fundación Linux, así que deberías preguntarles a ellos.

AT: Temas candentes: medio ambiente y seguridad. Linux domina el sector de la supercomputación, y los centros de datos consumen enormes cantidades de energía. ¿Crees que se está haciendo lo suficiente en el ámbito del software para optimizar y crear código que ayude a gestionar los recursos de forma más eficiente?

J.H.: Le pido que separe el concepto de superordenadores (High Performance Computing) de las granjas de servidores. Son dos tipos diferentes de computación y tienen necesidades diferentes.

Creo que la gente debería aprender cómo funciona la máquina hasta el flip-flop, si no el transistor. Deberían aprender algún tipo de lenguaje ensamblador (RISC-V podría ser una buena opción en este momento), no para programar en él, sino para ver, de vez en cuando, lo que genera el compilador. Si codificas tus fuentes de una manera, y produce 50 instrucciones RISC-V, y luego cambias tu código ligeramente y produce 5000 instrucciones RISC-V, quizás necesites prestar más atención a lo que estás haciendo.

No se trata sólo de si Google está utilizando 10 GW de energía y al optimizar tu código para que sea un 10% más eficiente puedes permitir que Google utilice 9 GW de electricidad, sino también de si tu smartphone dura diez horas con una carga o sólo 9 horas. Ambos son ejemplos de cómo hacer tu código más eficiente.

También hay código que utiliza demasiada RAM, provocando paginación e intercambio que puede hacer que otros programas que se ejecutan en el mismo sistema sean menos eficientes. Hay muchos problemas de eficiencia.

En 1977 tomé un programa que se ejecutaba en 10,5 horas en un PDP-11/70 y lo hice funcionar en sólo tres minutos. La persona que escribió el programa original no sabía nada de cómo funcionaba el ordenador. Cambié el programa para aprovechar la arquitectura.

AT: Y, ¿se está haciendo lo suficiente en materia de seguridad para las nuevas amenazas actuales?

J.H.: Nunca se hace lo suficiente en materia de seguridad, pero también está el equilibrio entre hacer un sistema seguro y hacerlo fácil de usar. Mientras que ciertas cosas pueden ser buenas para una instalación comercial que cuenta con administradores profesionales de redes y sistemas, «Mom&Pop™» puede no tener las habilidades técnicas ni para entender el problema ni los conocimientos para mantener la seguridad.

También sé más que la persona promedio sobre los agujeros de seguridad en los sistemas, y cómo pueden ser explotados, no sólo por los «malos» sino por los gobiernos. Todavía consigo dormir por la noche, pero a duras penas…

AT: Y se ha comentado el uso de Rust en el kernel por cuestiones de seguridad. ¿Qué opinas al respecto?

J. H.: Dejaré que los ingenieros del kernel decidan qué es lo mejor para ellos. Estoy pensando en aprender Rust pero también me gustaría aprender Go.

AT: ¿Cuáles cree que serán los próximos retos a los que se enfrentará Linux?

J.H.: Creo que el verdadero desafío es para el Software Libre, no sólo para Linux. Demasiadas empresas crean productos que son de «Código Abierto», lo que significa que utilizan el Código Abierto en sus productos, pero no transmiten los cambios que realizan ni a los clientes/usuarios finales ni a los desarrolladores de las versiones anteriores. La gente oye que una empresa utiliza «Código Abierto» y en su mente piensa en «Software Libre», pero hay una diferencia.

Las empresas que utilizan el «código abierto» pueden crear un producto tan cerrado como las que son «directas» al crear un código cerrado. Pero las empresas utilizan el término «Código Abierto» porque hoy en día se ve como algo «bueno».

Yo solía decir «Si eres sólo parcialmente abierto, a veces es peor que ser completamente cerrado«. Eso sigue siendo cierto.

Tenemos que luchar para apoyar a las empresas que usan Software Libre. Tenemos que comprar software y servicios de empresas que apoyan y distribuyen Software Libre.

AT: Se ha comentado mucho sobre «el año de Linux en el escritorio». Pero lo cierto es que Linux parece estar dominando todo menos ese sector. No te voy a hacer la típica pregunta sobre esto, pero me gustaría saber tu opinión sobre los problemas que implicaría que GNU/Linux fuera el sistema operativo dominante en el escritorio: ¿Crees que podría llegar una oleada de malware como ocurre en Windows o Android?

J.H.: Solía ser mucho más fácil entrar en Microsoft Windows que en los sistemas Unix o GNU/Linux, simplemente porque estos dos últimos fueron construidos para ser sistemas multiusuario en Internet. Unix y Linux tenían que tener una seguridad más fuerte que un sistema monopuesto, lo que no sólo los hacía más seguros, sino más estables. Esto ha cambiado a lo largo de los años y creo que se podría argumentar que un sistema Microsoft actual tiene un nivel de sofisticación en la seguridad que rivaliza con el de los sistemas Unix y GNU/Linux.

También están los argumentos de «seguridad a través de la oscuridad» y «muchos ojos ven los errores«, ambos bastante (casi completamente) falsos.

El verdadero argumento sobre la seguridad es triple:

• ¿Qué gana el explotador al aprovechar un fallo?
• ¿Cuántos niveles de sistemas tiene que atravesar el explotador? ¿Cuál es el nivel de dificultad?
• ¿Cuánto tiempo se tarda en parchear un fallo una vez que se conoce?

En cuanto a la primera, si se trata de un banco, una institución gubernamental o un gran cuerpo de código similar (por ejemplo, Microsoft Windows), se trata de un gran cuerpo de usuarios a los que un exploit les da mucha rentabilidad. A medida que GNU/Linux se utiliza más y más, el atractivo del objetivo GNU/Linux se hace más fuerte.

En cuanto a la segunda, la diversidad de GNU/Linux puede ayudar a protegerlo. Mi cortafuegos es un chip ARM, no un chip Intel. Quizás pronto sea RISC-V. No uso una distribución «estándar» de GNU/Linux para mi cortafuegos. Todas estas cosas hacen que mi sistema sea más difícil de encontrar y de entrar. Si un sistema GNU/Linux usa systemd y otro usa sysvinit puede ser más difícil que un mismo exploit funcione en ambos.

En el tercer punto, el Mean Time To Fix (MTTF) es (para mí) la diferencia más importante, cuando se encuentra un bug, qué tan rápido se puede aplicar y a cuántos sistemas.

Por ejemplo, si se encuentra un fallo en Microsoft hay que esperar hasta que un ingeniero determine una solución. Entonces tienen que crear un parche de código objeto para cada versión del sistema operativo que soportan. Luego tienen que probarlo. Luego tienen que distribuirlo. Después, hay que aplicarlo. Mientras tanto, sus sistemas están expuestos al problema.

Tal vez todavía esté utilizando una versión antigua del sistema operativo, como Windows XP. En la actualidad (octubre de 2021) me han dicho que el 0,6% de los usuarios de Microsoft siguen utilizando Windows XP. Eso no parece mucho, pero si hay 2.000 millones de usuarios de PCs de escritorio y el 90% de ellos son de Microsoft, eso supone unos 10.800.000 equipos de escritorio que pueden verse afectados por ese fallo, sin que les llegue ningún parche. También me han dicho que hay un país en el que cerca del 60% de los ordenadores de sobremesa siguen siendo Windows XP.

Es posible que estos sistemas antiguos estén detrás de un firewall, y por lo tanto tengan algún tipo de protección contra los ataques. Sin embargo, no es bueno. Y sé por un amigo mío que trabaja para el ejército de los Estados Unidos que algunas agencias gubernamentales en los Estados Unidos también siguen usando Windows XP…

Compara esto con lo que ocurre con GNU/Linux. Se encuentra un error y se pone a disposición el parche del código fuente. La gente puede esperar a que se haga el binario y se distribuya, lo que suele ocurrir en un día o dos. Puedo aplicar el parche del código fuente a mis sistemas Intel, ARM o cualquier otra arquitectura. Si tengo algunos sistemas más antiguos, puedo reelaborar el parche para que encaje en el código fuente de los sistemas más antiguos (si es necesario), incluso si esos sistemas están oficialmente obsoletos.

Esto no lo digo sólo yo. Hace unos años, una revista de PC dio el premio al «mejor soporte» a la Comunidad de Software Libre durante tres años consecutivos. Entonces la revista dejó de hacerlo, porque sabían que siempre ganaría la Comunidad del Software Libre. Qué vergüenza para algunos de sus anunciantes…

AT: A veces he preguntado a ciertas empresas o desarrolladores: «¿Por qué no hay soporte para Linux?«. Y su respuesta siempre se refiere a la variedad de paquetes y distribuciones existentes. ¿Cree que los paquetes universales no han sido capaces de resolver este problema? ¿O crees que el problema es que no les compensa el esfuerzo por la pequeña cuota que tiene Linux en el escritorio?

J.H.: Cuando trabajaba para DEC, siempre escuchaba a los desarrolladores preguntar por qué no soportaban nuestras nuevas combinaciones de sistema operativo y hardware. Los desarrolladores se quejaban de que no teníamos las herramientas adecuadas, o que las cosas eran «diferentes» o cualquier otra razón. Todo esto era una desviación.

La verdadera razón es el volumen, tanto la base instalada como el ritmo de ventas de nuevos sistemas. Si tienes un gran número de sistemas existentes o (mejor aún) la venta rápida de nuevos sistemas (los nuevos sistemas quieren nuevas aplicaciones), te adaptarán y apoyarán.

La otra cuestión es el «índice de ventas de aplicaciones frente a la base instalada». Si la empresa piensa que la mitad de los clientes del sistema comprarán su aplicación, entonces harán el port. Si sólo el 1% de los clientes de la plataforma comprarán su aplicación, no estarán tan ansiosos por hacer la adaptación.

Desafortunadamente, la gente de GNU/Linux no es la mejor fuente de ingresos para las aplicaciones. No les gusta pagar mucho dinero por las aplicaciones, y esto también se ve afectado por la tasa de piratería de software en todo el mundo.

La última vez que miré, Vietnam tenía una tasa de piratería de software para aplicaciones de escritorio del 96%. China solía tener un 92%, pero lo han reducido al 84%. Brasil tenía una tasa de piratería de software del 84%, e incluso Estados Unidos (uno de los países más ricos del mundo) tenía una tasa de piratería del 34%. Obtuve estas cifras de la Business Software Alliance (BSA), que cuenta con el apoyo de empresas como Microsoft, Oracle y Adobe, entre otras.

La verdad es que odio la piratería de software. Compro todo mi software comercial, obedezco a las licencias, compro toda mi música (tengo miles de CDs).

Cuando fui por primera vez a Brasil dije «Deberías usar Software Libre», a lo que mis amigos brasileños dijeron «¡Oh, maddog! Todo nuestro software es libre!» Así, como ellos pirateaban el software comercial, el Software Libre tenía menos «valor» para ellos.

Por supuesto, las empresas comerciales y los gobiernos no pueden correr el riesgo de piratear el software, por lo que incluso con una gran cantidad de software de escritorio que se piratea, miles de millones de dólares salen de su país para pagar por el software donde existe una buena solución de Software Libre alternativa.

Además, los jugadores (por desgracia) tienen un índice bastante alto de «piratería», aunque los ingresos de los juegos están cambiando del juego en sí a los servicios proporcionados por un servidor de juegos.

Así que si se pone todo esto junto (base instalada de escritorio alrededor del 7%, una tasa de instalación de escritorio del 10%, y una base de usuarios que no compra muchos productos comerciales de escritorio) se puede ver por qué los proveedores de aplicaciones no hacen muchos ports.

Los servidores son algo diferentes. La gente está acostumbrada a comprar un servidor para ejecutar alguna aplicación grande.

Los ordenadores de alto rendimiento (antes conocidos como «sistemas Beowulf») tienden a escribir su propio software de propósito especial.

Los sistemas integrados buscan una solución portátil, segura, preparada para Internet, eficiente y de bajo coste (gratuita).

Android necesitaba un kernel que fuera portable, seguro, eficiente y abierto. Lo necesitaban a toda prisa, ya que Apple se les había adelantado.

AT: Los videojuegos han sido otro de los problemas que han alejado a muchos usuarios de la plataforma Linux. Hoy en día esto ha cambiado radicalmente, hay miles de títulos disponibles. ¿Qué opinas del panorama de los videojuegos en Linux?

J.H.: No soy un jugador. El último juego de ordenador al que jugué fue «Adventure» en 1973 en un PDP-8.

Me alegra ver que los juegos mejoran en GNU/Linux porque sé que mucha gente es jugadora y da la «falta de juegos» como la razón por la que se molestan en usar Windows.

Las consolas de juegos también afectan a esto. Un amigo mío tiene muchas consolas de juegos, por lo que no se molesta en jugar en sus sistemas de escritorio o portátiles.

AT: Si me permites un poco de humor en la entrevista, creo que han intentado tentarte para que te pongas del lado de FreeBSD en alguna conferencia, ¿Es así? Por qué sigues siendo fiel a Linux (aparte de perder el título de ‘padrino de las hijas de Torvalds’ jajaja). Es decir, ¿por qué Linux y no algún *BSD?

J.H.: Utilicé por primera vez el System III Unix de AT&T en 1980. Aprendí Unix con él en los Laboratorios Bell. Me quedé en los laboratorios hasta 1983 y usé System IV y System 5.0

Cuando fui a DEC basamos nuestros sistemas en la Versión 7 (modificada) para el PDP-11, pero fuimos con BSD 4.1c para nuestra versión VAX de 32 bits. Permanecimos en esa base BSD hasta que fuimos con OSF/1 para el Alpha. Así que estoy bastante familiarizado con BSD, y conozco a muchos de los buenos desarrolladores que trabajaron (y continúan trabajando) en él.

Sin embargo, en 1994, cuando conocí a Linus Torvalds, el pleito entre USL y BSDi no había finalizado. BSD Lite no había sido creado, y yo necesitaba un sistema operativo libre y abierto para ser portado al DEC Alpha de 64 bits. Uno con código fuente desinhibido por las licencias. ¿Por qué necesitaba esto? Tenía VMS. Tenía DEC OSF/1.

Lo necesitaba para la investigación en ciencias de la computación en grandes espacios de direcciones.

La mayoría de la gente no se da cuenta de lo grande que es 2 a la 64ª potencia. Con un ordenador de 32 bits puedes asignar cuatro mil millones de bytes de datos en la memoria virtual. Con 64 bits se pueden asignar cuatro mil millones VECES cuatro mil millones de bytes de datos. Eso equivale a llenar un disco de un gigabyte cada segundo del día, cada día del año, durante los próximos 584 años.

Y si estás trabajando en una película, o en el clima, o en las corrientes oceánicas, puedes encontrar que 32 bits es demasiado pequeño, pero 64 bits es suficiente.

Si utilizas una tabla hash, y tus datos son grandes pero tu memoria es pequeña, puedes tener muchas colisiones, que tardan en «arreglarse». Con 64 bits de espacio de direcciones la probabilidad de una colisión es pequeña.

Sí, los investigadores podrían hacer este tipo de investigación con un acceso restringido y con licencia al código fuente de un sistema de código cerrado, pero si el investigador quería colaborar, y si quería publicar su investigación con el código fuente para demostrarlo, necesitaba un núcleo, bibliotecas y utilidades de Software Libre. Esto es lo que yo buscaba.

Así que en mayo de 1994 encontré a este agradable joven, con pelo castaño arenoso que hablaba un inglés perfecto con un suave acento europeo frente a mí, el líder del proyecto, y que aceptó hacer un port para DEC Alpha.

Cuando volví a mi oficina descubrí que había un grupo de ingenieros en Digital Semiconductor (donde se diseñó, fabricó y vendió el Alpha) que (independientemente de mí) había hecho una evaluación de los sistemas operativos que no eran de DEC tratando de encontrar otro sistema operativo para portar al Alpha. Habían estudiado BSD, y lo rechazaron por la misma razón que yo… el problema de la licencia. Incluso habían considerado SCO (el «buen SCO» original) y lo rechazaron por las mismas razones.

Finalmente eligieron Linux, e incluso habían empezado a hacer un port, pero con un espacio de direcciones de sólo 32 bits. Les dije que eso era una locura, que uno de los principales puntos fuertes de Alpha era su espacio de direcciones de 64 bits, y que debían unirse a la comunidad para hacer esa tarea más grande. Los ingenieros pensaron que sería demasiado trabajo, ya que no sólo había que portar el kernel, sino todas las bibliotecas, compiladores, utilidades, etc., al espacio de 64 bits. Les dije que el trabajo ya estaba hecho, porque todo GNU, el sistema X Window y muchas otras utilidades ya habían sido portadas a DEC OSF/1, y ya estaba en 64 bits.

Comprobaron mi afirmación y descubrieron que tenía razón. Así que terminaron su port de 32 bits y se unieron al proyecto Alpha/Linux. Nos hicimos buenos amigos y uno de ellos, David Rusling, escribió el cargador de arranque de software libre «milo», que era como «lilo», sólo que para el Alpha. David pasó a ser un Fellow en ARM, y el CTO de Linaro, y sigue siendo un buen amigo hasta el día de hoy.

Pude ver mucho entusiasmo en torno a la creación de distribuciones (SLS, Slackware, Yggdrasil, Red Hat, Debian y más), así como grupos de usuarios de «Linux» (LUGs) surgiendo en todo el mundo. Pude ver múltiples revistas (Linux Journal, Linux Magazine, Linux Pro Magazine) en los quioscos. Y mucho interés en Linux.

Al final tuvimos un simpático pingüino como símbolo. BSD tenía un diablo. Sí, sé que es un «demonio», pero trata de decírselo a la gente de Texas.

En las ferias comerciales se me acercaban mujeres hermosas diciendo «POR FAVOR, dame uno de esos lindos Tuxes de felpa». Nunca tuve a nadie que me pidiera un diablo BSD.

Así que cuando la gente de BSD (finalmente) vino a mí y me preguntó por qué no les daba tanta ayuda como a «Linux», mi respuesta fue simple:

«Muéstrame tres revistas. Muéstrame cinco LUGS. Muéstrame otra distribución que no sea las tres principales (NetBSD, FreeBSD, OpenBSD) que no se peleen entre sí, y le daría a «BSD» tanto apoyo como el que le di a Linux«.

Para que quede claro, no considero que BSD sea «el enemigo». El código cerrado es el enemigo. El cliente que no tiene el control de su software es el enemigo. El cliente al que se le dice cuando actualizar, cuantos usuarios poner en su sistema, que procesador usar es el enemigo. La libertad del software es la respuesta. Y este es el problema con las licencias «permisivas» como BSD y MIT. No garantizan la libertad del software al usuario final.

Sé que muchas personas dicen que necesitan una licencia «permisiva» para hacer su producto y, por lo tanto, necesitan una licencia de «código abierto» además de la GPL. Simplemente están equivocados.

Hablamos mucho de Software Freedom. Para una persona de negocios, la “libertad” a veces da miedo, así que no le hablo de “libertad”. Para una persona de negocios, Software Freedom significa «control de su software». Cualquier otra cosa es la tiranía del software. Y ahora empezamos a verlo en Hardware (Open Hardware) y Cultura (Creative Commons).

Control. Control de su software, control de su negocio, control de su vida.

Y fue muy parecido a mi discusión sobre aplicaciones. Estuve en DEC tratando de producir y vender un sistema operativo (Unix) y un estilo de vida informático (Open Source) de 1983 a 1994 en una empresa que solo quería vender VMS y productos de código cerrado. Tenía marcas de látigo arriba y abajo de mi espalda. Estaba cansado de correr el guante.

Solo por una vez … solo por una vez … quería nadar agua abajo en la cascada, y no agua arriba en la cascada.

AT: Gracias Jon por esta entrevista y por la ayuda que me prestaste hace unos años para motivar a mis alumnos de mi curso de administración de sistemas Linux… See you later!