Antonio Larrosa: entrevista exclusiva para AT

Antonio Larrosa es un malagueño al que he tenido el honor de poder entrevistar para que nos comente algo sobre su trabajo como desarrollador del proyecto KDE y también sobre su actividad actual dentro de la gran SUSE, además de como miembro de openSUSE. Así que si quieres conocer un poco más sobre él y su trabajo, te invito a seguir leyendo esta entrevista…

Architecnología: Siempre suelo preguntar la misma pregunta inicial ¿Quién es Antonio Larrosa? ¿Cómo te definirías?

Antonio Larrosa: Empezamos con una pregunta difícil… Supongo que podría decir que soy un defensor permanente del software libre, de la privacidad y del conocimiento libre en general. Soy licenciado en matemáticas aunque siempre me he dedicado al mundo de la informática. Llevo desde 1995 usando Linux, desde 1997 siendo desarrollador de KDE y colaborando de distintas formas (traduciendo, ayudando a organizar conferencias…) . Desde 2013 trabajando en SUSE tanto en la distribución de Linux para empresas, SUSE Linux Enterprise Server como en las distribuciones comunitarias openSUSE Leap y openSUSE Tumbleweed así como colaborando con multitud de proyectos de software libre.

AT: ¿Cuándo te comenzó a interesar el mundo de la tecnología?

AL: Pues a eso de los 7 u 8 años tenía un Dragon64 pero no tenía prácticamente acceso a juegos para esa plataforma ya que no fue nunca muy común en España, así que tuve que aprender a «programar» para hacer mis propios juegos. Pero es cuando salió Windows95 con unos 16 años que me di cuenta de la ventaja del software libre cuando mi teclado (piano electrónico) que podía conectar a mi PC con Windows 3.1 dejó de funcionar con Windows 95 simplemente porque requería una funcionalidad que «ya no estaba soportada». Coincidió que en aquella época conocí Linux, donde tenía acceso a todo el código fuente y por lo tanto me permitía programar por mí mismo esa funcionalidad que necesitaba, mejorar la aplicación que se usaba para reproducir música por el teclado y cualquier persona del mundo podía beneficiarse de esa mejora.

AT: ¿Algún referente de este sector que te haya servido de inspiración?

AL: Por supuesto. Hay muchas personas a las que admirar en la comunidad por sus desarrollos o por su visión, personas como Matthias Ettrich (fundador de KDE y LyX) o Kalle Dalheimer (colaborador de KDE casi desde el principio y fundador de KDAB). También, Takashi Iwai (que escribió el primer driver de Linux para la SoundBlaster AWE32) creo que es alguien a quien habría que agradecerle mucho todo lo que hace por el software libre como mantenedor de ALSA entre otras muchas cosas.

AT: ¿Cuál ha sido el reto más complejo al que te has enfrentado en tu trayectoria como desarrollador? ¿Y el más gratificante?

AL: No sé si el más complejo, pero quizás uno de los retos más complejos ocurrió hace unos 5 años. Para ponernos en contexto, KDE estaba completamente centrado en el desarrollo de KDE Plasma 5 pero en SUSE todavía teníamos que mantener paquetes de SLES 11 (que al haber salido unos años antes usaba KDE 4). Había un problema con el NetworkManager que hacía que al conectarse a redes WPA2 Enterprise, no comprobara el certificado del servidor al que se estaba conectando, con lo que un usuario podía conectarse sin darse cuenta a una red maliciosa creada para hacerse pasar por la red wifi a la que el usuario realmente quería conectarse. Este problema se arregló en el applet de NetworkManager de KDE, pero el applet se había reescrito para Plasma 5 con lo que no se podía portar de vuelta a KDE4 y tuve que implementar el soporte para comprobar certificados de redes WPA2 Enterprise en el applet de NetworkManager de KDE 4 cuando KDE 4 estaba ya obsoleto oficialmente por parte de KDE.

Otro reto complejo en el que estoy involucrado últimamente está relacionado con los tipos de letra en Linux. Recientemente pango 1.44 (en realidad, harfbuzz) ha dejado de soportar tipos de letra en formato bitmap. Esto ha molestado a muchos usuarios que quieren seguir usando los mismos tipos de letra que estaban usando hasta ahora. Una primera solución, basada en convertir los tipos de letra de formato bitmap a un formato OpenType ya ha sido incluida en SLE 15.3, openSUSE Leap 15.3 y openSUSE Tumbleweed, pero todavía no está totalmente solucionado ya que el problema es bastante más complejo de lo que puede parecer inicialmente.

Sobre el reto más gratificante, creo que valen las mismas respuestas. Generalmente cuanto más cuesta encontrar una solución, más gratificante es encontrarla.

AT: ¿Cómo es la simbiosis (en cuanto a desarrollo) que hay actualmente entre openSUSE y SUSE? ¿Es bidireccional o solo en un sentido?

AL: Me alegra que me hagas esa pregunta justo ahora porque si antes ya era bidireccional, desde hace unas semanas hay un proyecto en marcha llamado openSUSE Jump que busca que la simbiosis sea incluso mayor.

Hay que tener en cuenta que en SUSE se desarrollan varias distribuciones (SUSE Linux Enterprise Server, SUSE Linux Enterprise Desktop, SUSE Linux Enterprise for SAP Applications, etc.) y todas usan una misma base que llamamos «SUSE Linux Enterprise» (o SLE para abreviar).

Por otra parte, openSUSE desarrolla también varias distribuciones, de las que las principales son openSUSE Leap, openSUSE Tumbleweed y openSUSE Kubic.

Tumbleweed siempre tiene las últimas versiones de todos los paquetes y en SUSE tenemos una máxima que dice «Factory first» (Factory es el nombre interno de Tumbleweed en los servidores de openSUSE) lo que significa que siempre que se modifique un paquete (por ejemplo para actualizarlo o para arreglar algún problema) siempre hay que hacer el cambio primero en Tumbleweed. Así nos aseguramos que Tumbleweed incluye siempre todos los arreglos introducidos en SLE. Además, siempre que se va a actualizar un paquete en SLE, éste paquete se toma desde Tumbleweed, con lo que aquí se empieza a ver esa bidirección de la que hablaba antes.

Por otra parte, Leap es una distribución basada en SLE mantenida por la comunidad de openSUSE. Lo que se venía haciendo hasta ahora es que se usaba el código fuente de los paquetes en SLE como origen de los paquetes para construir Leap. Pero con el proyecto Jump lo que está haciendo es tomar directamente los mismos paquetes ya compilados en SLE para usarlos en Leap (y sobre esta base, añadir paquetes y configuración propia de Leap). Una de las ventajas de esto, es que nos aseguramos de que los paquetes base del sistema son exactamente iguales, con lo que por ejemplo, cuando SLE se certifica para cierto hardware o se certifica que un software de terceros funciona en SLE, automaticamente sabemos que también va a estar soportado en Leap.

AT: ¿Por qué crees que GNOME se ha impuesto frente a KDE Plasma como el escritorio por defecto de algunas importantes distros como Ubuntu, RHEL, etc.?

AL: Es una buena pregunta. Supongo que buena parte de los motivos estarán relacionados con la inercia por parte de los programadores, equipos de trabajo y personal responsable de tomar las decisiones en cada distribución. Quizás el problema principal haya sido de comunicación de las ventajas de KDE que no hemos sabido transmitir. Aun así, la mayoría de distribuciones siguen ofreciendo la posibilidad de instalar un escritorio KDE Plasma ya que muchos usuarios lo solicitan.

AT: KDE Plasma ha sufrido un cambio extremo en cuanto a consumo de recursos. Ha pasado de ser un escritorio pesado a ser bastante liviano en cuanto a consumo de RAM últimamente. ¿Dónde ha estado la clave? Porque el cambio ha sido realmente impresionante (aunque algunos no se lo creen aún)…

AL: Pues en mi opinión no hay una cosa concreta. Principalmente ha sido un proceso iterativo de optimizar el uso de recursos en cada versión tanto de Plasma como de KDE Frameworks a la vez que se ha ido haciendo lo mismo desde Qt.

AT: Sigo de cerca el proyecto EPI y GAIA-X, para el desarrollo de un procesador y la nube europea, y la no dependencia tecnológica del Viejo Continente (las luchas entre EE.UU. y China quizás han hecho que algunos aquí comiencen a abrir los ojos). Afortunadamente, podemos presumir un poco más desde el lado de software, con grandes como SUSE ;), SAP, etc. ¿Cómo ves este problema?

AL: La verdad es que no conocía EPI ni GAIA-X. Creo que efectivamente tenemos un problema de dependencia en varios gigantes tecnológicos y que la solución pasa no por tener un gigante tecnológico europeo, sino por el desarrollo de hardware y software libre y que desde Europa se le dé prioridad al uso de estas tecnologías libres. También pienso que el esfuerzo que se va a hacer con GAIA-X se debería emplear de forma más productiva en mejorar Nextcloud, que ya es una nube desarrollada principalmente en Europa de software libre.

AT: Volviendo EPI, como sabes, estará basado en ARM con acelerador RISC-V. ¿Como desarrollador de SUSE, una distro que está presente en el sector HPC, cómo ves el futuro de estas dos ISAs para centros de datos? SUSE está disponible para ARM, y creo que openSUSE está trabajando también en un port para RISC-V. ¿Es así?

AL: Creo que ARM y RISC-V se están usando cada vez más en centros de datos por su menor consumo y cada vez mejor rendimiento, el que EPI esté basado en ambos me parece una buena noticia. Como decía no lo conozco mucho, pero si EPI también es hardware libre sólo puedo decir… «bienvenido sea».

Sobre el port para RISC-V, sí, es correcto. Tenemos actualmente un proyecto en marcha en y ya hay unos 13000 paquetes en Tumbleweed compilados para la arquitectura riscv64. Está totalmente en desarrollo, pero en la página del proyecto se pueden descargar imágenes para ejecutar de forma virtualizada para quien quiera colaborar en el desarrollo :).

AT: Hay dos cosas que me preocupan especialmente en el mundo de la computación: eficiencia energética (especialmente cuando se trata de HPC) y seguridad. ¿Crees que se destinan suficientes recursos en el desarrollo de software para mejorar esos aspectos?

AL: Creo que se destinan algunos recursos, pero no los suficientes. El que haya software que haga un mal uso energético es realmente preocupante, especialmente si es software que usan muchos millones de personas en todo el mundo. Tenemos ejemplos de este tipo de software cada vez que vemos aplicaciones de escritorio desarrolladas en javascript que es uno de los lenguajes menos eficientes energéticamente hablando. Personalmente, creo los usuarios deberíamos rechazar las aplicaciones que usan tecnologías poco eficientes, como forma de hacer activismo por el medio ambiente. Creo que si para reducir la contaminación y el calentamiento global se fomenta el uso de transporte público, el consumo local, el uso de energías renovables… también debería fomentarse el uso de software que haga un uso eficiente de la energía.

AT: Han emergido muchas tecnologías como la nube, realidad virtual/aumentada/mixta, virtualización y contenedores, IA,… ¿Cuál creéis que será el próximo reto para SUSE? ¿Tenéis las miras puestas en alguna tecnología floreciente que os llame especialmente la atención de cara a un futuro próximo?

AL: Toda la entrevista la he contestado a título personal, pero para contestar a esta pregunta me temo que tendrías que hablar con alguien habilitado para hablar por SUSE.

AT: Ok! Se la haré a Gerald Pfeifer (CTO) próximamente…

Y la última es obligada y tal vez la más difícil…¿tú cómo pronuncias SUSE? ¿”susa”? ¿”suse?Jajaja 😉

AL: Jeje, yo suelo pronunciarlo «SUSE» tal cual se escribe en español, pero la pregunta como bien dices es difícil y bastante común así que el año pasado se publicó un vídeo para resolver la duda oficialmente.

Muchas gracias por la entrevista.

AT: Gracias a ti!!!