Con motivo de la celebración de SUSECON 24 entrevistamos a Gerald Pfeifer, CTO de SUSE, responsable del área de estrategia, seguridad y código abierto para EMEA y actual presidente de la junta de openSUSE.
Como sucedió con la entrevista a Pilar Santamaría, vicepresidente de IA de SUSE que realicé en el mismo evento, esta tendría que haber salido publicada en esas fechas, pero por distintos motivos que no vienen al caso, no pudo ser.
La sacamos ahora porque todo lo que se trata sigue vigente y, mucho más importante, aunque esta sea una apreciación personal, porque quedó una entrevista larga, pero muy interesante, que toca muchos de los temas que nos han dejado grandes titulares en los últimos tiempos, que deja claras algunas cosas que no lo estaban y que darán mucho de que hablar y que, en definitiva, discurre por diferentes derroteros que, considero, serán del interés de nuestra audiencia.
* * *
Como de costumbre, aprovechasteis el marco de SUSECON para anunciar el lanzamiento de SUSE Linux Enterprise Server 15 Service Pack 6. Una nueva versión del sistema que ya cubrimos, pero sobre la que me gustaría preguntarte: aparte de las actualizaciones menores ¿cuáles serían los aspectos destacados de esta versión?
Diría que lo interesante de la versión 15 es que lleva mucho tiempo en funcionamiento. La lanzamos en 2018, así que ahora ya son seis años. Y hemos anunciado que el ciclo de vida regular irá hasta 2031, lo cual es bastante…
Y luego, si la gente realmente quiere, podemos llegar hasta 2037. Porque tenemos clientes con casos de uso muy críticos que nos dicen: «Esto está funcionando, no queremos cambiarlo». No es para un usuario de escritorio, pero sí para casos de uso muy críticos, como producción en fábricas. Algunos dicen que no quieren cambios. Al mismo tiempo, lanzaremos una nueva versión importante el próximo año.
Creo que eso es algo de lo que estamos empezando a hablar ahora, será SUSE Linux Enterprise 16 y para SAP. Para algunas personas ha sido una sorpresa que todavía exista un Linux clásico. Obviamente, hay mucho movimiento hacia Kubernetes. Como plataforma de Kubernetes en el lado de Linux, tenemos a MicroOS, un sistema muy orientado a su tarea.
Lo que estamos descubriendo es que no se trata de «esto o aquello». Hay bastantes personas que todavía quieren usar una distribución de Linux muy clásica, como SUSE Linux Enterprise Server. Y, de igual manera, hay mucha gente que sigue creciendo a medida que Kubernetes se extiende, y quiere usar algo como MicroOS. Así que creo que el Linux clásico con soporte extendido sigue siendo una sorpresa para muchos.
SUSE Linux Enterprise Server 15 tendrá soporte hasta 2037. ¿Será esta la última versión de SUSE 15 o, en su caso, la última versión de SUSE Linux Enterprise tal como lo conocemos? Es decir, antes de que Adaptable Linux Platform ocupe su lugar.
Por lo que sé hoy, habrá un próximo service pack, el Service Pack 7, el próximo año, porque sí, es una buena observación: entre los service packs hay un intervalo de aproximadamente un año, cada doce meses más o menos. Así que probablemente llegará en la primera mitad del año, y luego, en la segunda mitad, espero que la siguiente generación.
Poco antes del lanzamiento de SUSE Linux Enterprise Server 15 SP6 se anunció SUSE Linux Enterprise Micro 6. El enfoque de este sistema inmutable es realmente interesante y está ganando tracción más allá de contenedores, máquinas virtuales y demás. ¿Qué hay de la versión inmutable de SUSE Linux Enterprise? Escritorio?
Buena pregunta. Por ahora, no estamos planeando eso en el lado de SUSE Linux Enterprise. Hay algo que tenemos en el lado de openSUSE. Se llama openSUSE Aeon.
Sí, la conozco. Hemos hablado de ella en MuyLinux.
Creo que incluso tienes un stand aquí en la exposición, lo lleva…
Richard Brown.
Sí. Richard Brown es el principal desarrollador y el impulsor de eso. Y la razón por la que no estamos pensando en hacer esto en el lado empresarial es simplemente porque nuestro enfoque está en los servicios, la nube y el edge computing.
Así que no es una declaración sobre la viabilidad o si tiene sentido. Creo que es un enfoque muy interesante, o uno que tiene mucho sentido para muchos casos de uso. Simplemente no lo vemos como nuestro foco de negocio.
¿Es Richard es el único mantenedor de openSUSE Aeon?
Hay otros contribuyentes, pero él es realmente la figura principal, por así decirlo.
El problema de Aeon es que al ser un proyecto tan pequeño, deja mucha cosa fuera. Por ejemplo, solo soporta GNOME como entorno de escritorio.
Esto es lo que pasa cuando tienes una comunidad: las elecciones las hacen aquellos que están dispuestos a hacer el trabajo, y Richard elige GNOME. Hay otro desarrollador, Sean, que está trabajando en una versión con KDE, llamada KALPa.
Pero está mucho más verde, en una fase muy inicial.
Aeon está mucho más avanzado, sí; es el líder, por decirlo de alguna manera.
Para aquellos a los que les gustan los sistemas inmutables para trabajar, hay un debate, porque Fedora está muy avanzada en ese camino con Silverblue. Pero creo que hay una gran opinión sobre Aeon por este enfoque de contenedores, con la aplicación y el soporte de otras distribuciones a través de Flatpak.
Es como con la moda, la gente tiene preferencias y dice: «Vale, estas son las mejores zapatillas de correr, «solo compro Adidas» o «compro Puma» o «compro Nike». Creo que hay algunas preferencias personales.
En mi caso, en mi portátil, estoy ejecutando Tumbleweed. Este es mi sistema de producción. No es lo que recomendaría a la gente normal, la verdad. Pero para mí funciona muy bien. Y, bueno, no soy ni siquiera aventurero, porque ahora, con el OpenBuild Service por un lado y luego OpenQA, incluso algo como Tumbleweed, que es rolling-release, se ha vuelto muy estable.
Ahora bien, no recomendaría a mi pareja que use Tumbleweed en casa. Simplemente porque hay demasiadas actualizaciones. Por eso le puse openSUSE Leap.
Ciertamente, la cantidad de actualizaciones de Tumbleweed abruma, incluso en comparación con otras distribuciones rolling-release
Algunas semanas, no todas, pero algunas semanas tenemos seis actualizaciones o al menos cinco, a veces tres, a veces dos, pero entonces tienes, como, un gigabyte de actualizaciones.
Así que, para alguien que no está en TI y no quiere jugar con la tecnología, no es necesariamente ideal. Por eso le puse a mi pareja Leap, que está alineada con SUSE Linux Enterprise. Aunque tiene componentes más nuevos que vienen de openSUSE, por lo que en cierto modo es lo mejor de ambos mundos.
Tal vez si instalo un nuevo sistema el próximo año para alguien de mi familia, tal vez considere Aeon.
Entonces,¿nada de Windows o Mac en casa?
Literalmente, no uso Windows ni Mac. Mi pareja tiene un iPad, pero eso es todo.
Hablando del futuro del sistema. ¿Qué hay de Adaptable Linux Platform (ALP), la «nueva generación de SUSE Linux»? Sabemos algunas cosas: será modular, una especie de base común sobre la que construir un sistema dedicado completo con un enfoque en casos de uso específicos, ya sea en escritorio, nube, etc; se apoyará en contenedores y automatización… Suena bastante a un MicroOS evolucionado, un sistema inmutable más maduro. ¿Cuáles son las principales diferencias entre SUSE Micro y la propuesta de ALP?
ALP fue un proyecto, una plataforma que comenzamos a desarrollar donde hicimos cambios significativos en la base. Y, por así decirlo, el SUSE Linux Enterprise 16 del que hablábamos hereda mucho de ALP.
Ha habido trabajo en el lado de la seguridad. Ha habido mucho trabajo en el «motor», si lo quieres llamar así, algo que no es súper visible, pero que está ahí abajo para hacer la distribución más ligera y moderna. Todo ese trabajo ha estado ocurriendo en openSUSE, en openSUSE Tumbleweed.
Otros miembros de la familia, por así decirlo, que salen de ALP y que se visten más clásicamente son SUSE Linux Enterprise 16 y la versión para SAP. Luego hay otros que se visten de manera más «moderna», como MicroOS, y las versiones futuras de este.
ALP era más un nombre en clave, y ahora el nombre de la familia es SUSE Linux Enterprise o SUSE Linux.
¿La versión principal de SUSE Linux Enterprise 16 será MicroOS?
Existirán en paralelo, así que no lo llamaría la versión principal. Son versiones equivalentes.
Será como ahora, entonces.
¿Como ahora? Sí, más o menos. Donde tenemos, para diferentes casos de uso, una versión clásica para SAP, como SAP NetWeaver, SAP HANA, tenemos ese sabor. Luego tenemos el clásico SLES (SUSE Linux Enterprise Server), porque hay bastantes clientes que quieren, al menos por algún tiempo más, seguir por esa ruta.
Y luego está MicroOS. Así que, al menos por ahora, tenemos tres miembros de la familia que están relacionados, comparten mucho, pero son bastante diferentes en el sentido de que MicroOS, en muchos aspectos, se siente y se comporta de manera muy diferente a un sistema operativo Linux clásico, aunque comparten mucho: el kernel, muchos otros componentes que tiene sentido compartir.
Creo que se presentó de una manera diferente, como una especia de reinicio total de la base del sistema.
La presentación ha cambiado o la manera de verlo ha cambiado un poco desde ese proyecto.
La propuesta original apuntaba a un nuevo concepto de un sistema empresarial.
Sí, lo sé, porque tuve conversaciones con el equipo en aquel entonces y les dije: «mirad, parece que se trata de un único sistema». Pero la idea realmente nunca fue tener un solo sistema base. Quizás se entendió así. La planificación desde el principio era tener múltiples miembros de la familia. O eso creo, basado en el feedback que les di, porque hicimos snapshots públicos…
¿Hay espacio para una versión rolling release empresarial?
No sé qué decirte. Desde luego, no vamos al lanzar nada parecido próximamente, pero nunca digas nunca. Lo que sí veo es un interés por parte de la industria por desacoplar la base del sistema, la parte que gestiona el hardware y la infraestructura, de la parte que interactúa con la aplicación.
Y para la parte de las aplicaciones, a menudo quieres mantenerlas funcionando sin tener que cambiarlas. Así que creo que se espera más estabilidad de nuestra parte allí, por lo que un movimiento rolling-release puede darse más por la base que por encima. De hecho, si miras SLES 15, el Service Pack 6 viene con un nuevo kernel de Linux.
Aunque tampoco lo llamaría una rolling-release, si actualizas algo cada dos años. No es nuestra definición de rolling release.
En este aspecto sí se ha visto evolución. SLES 15 SP6 viene con Linux 6.4, una versión muy actual del kernel.
Sí, las cosas están cambiando. Incluso la muy clásica y conservadora distribución empresarial de Linux se ha vuelto más rolling o menos estática, si lo prefieres. Siempre es un equilibrio; no quieres arriesgarte a nada, porque si hemos aprendido algo es que a veces los clientes dependen de algo que no está garantizado que siga funcionando si lo tocas, y no porque introduzcas un error, simplemente porque el código es diferente.
Algo puede ser más rápido y eso puede causar un problema porque el código del cliente no esperaba eso. O, si tienes múltiples hilos de ejecución, no esperas que uno de ellos termine antes que el otro, cuando siempre ha sido al revés, pero ahora el sistema es más rápido y lo cambia. Entonces hay código por ahí que es susceptible al cambio, y ese tipo de clientes realmente tienden a querer estabilidad, sobre todo.
Nosotros nos adaptamos, tú triunfas [We Adapt, You Succeed, un viejo lema de SUSE]
Esa era la antigua frase publicitaria. Y sí, en realidad, se trata de aprender. No hay dos clientes iguales, pero hay similitudes. Intentamos… tratamos de crear soluciones que aborden ciertos casos de uso.
Uno de ellos es MicroOS, para una clase de clientes que obviamente está creciendo bastante porque las nuevas aplicaciones, si te fijas, más del 90% de las nuevas aplicaciones hoy en día se desarrollan en Kubernetes o de una manera nativa en la nube. Así que, obviamente, ahí es donde tenemos que poner mucho enfoque.
Hablemos entonces de SUSE Liberty Linux, porque no parece haber mayor ejercicio de adaptación que ese, pese a que han habido algunas confusiones al respecto. ¿Qué es exactamente SUSE Liberty Linux? Algunos lo describen como un clon de CentOS o RHEL. Otros como un servicio de soporte exclusivo.
Estamos haciendo dos cosas. Algo similar a SUSE Manager. ¿Conoces SUSE Manager? Tenemos Uyuni, que es un proyecto upstream de código abierto; y tenemos SUSE Manager, que es un producto de SUSE. Y, de manera similar, creamos y cocreamos con socios como CIQ y Oracle, OpenELA, que proporciona el código fuente para una distribución compatible con Red Hat Enterprise Linux.
Así que, para responder a tu pregunta, eso es algo como un clon de CentOS. Estamos tomando la base de código y manteniéndola. Proporcionamos actualizaciones en formato de código fuente. Entonces, OpenELA es un proyecto que todavía está en una etapas inicial, pero que es accesible, que puedes descargar. Y luego está SUSE Liberty, que es una oferta comercial de SUSE, basada en OpenELA, donde ofrecemos mantenimiento con una cadena de suministro.
Con SUSE Liberty tienes un centro de clientes, puedes descargar cosas firmadas criptográficamente, etcétera, y obtienes soporte. Dependiendo del paquete que elijas, también obtienes un componente de gestión porque SUSE Manager es parte del paquete. Así que existe la oferta comercial, que es SUSE Liberty, y luego está el proyecto comunitario, producto versus proyecto, que es OpenELA. Y la idea de OpenELA es que se pueda descargar libremente.
¿Cómo va SUSE Liberty?
¿Hay demanda? Sí, estamos viendo buenas oportunidades y ya hemos cerrado algunos acuerdos importantes. Como siempre, no todos nuestros clientes quieren ser casos de referencia, pero estamos intentando obtener algunas historias de referencia.
Según tengo entendido, tenéis ya una gran cliente de SUSE Liberty con más de 26.000 migraciones en marcha…
Sí, pero no es público todavía. Ya sabes cómo va. Pero es realmente significativo en términos comerciales, en cuanto a servidores. Esa es la elección que algunos están haciendo.
¿El proyecto OpenELA fue desarrollado bajo el paraguas de SUSE?
Sí.
El anuncio de OpenELA junto a CIQ y Oracle se dio poco después del de SUSE Liberty…
Correcto.
Con una notable inversión de 10 millones de dólares.
Para OpenELA.
No se mencionó eso en la nota que tengo aquí.
Tendremos que revisar los detalles.
Si SUSE pone 10 millones de dólares ¿cuál es el nivel de participación de los otros dos socios clave, CIQ y Oracle?
No sé exactamente cuánto están contribuyendo o en qué están contribuyendo. Todavía está en una fase de formación. Puedes contribuir de muchas maneras: código, esfuerzo, escribir…
Para nosotros, es importante distinguir entre OpenELA, que como has mencionado es el código fuente, y luego SUSE Liberty, que es un producto, con binarios que se construyen a la manera segura de SUSE, con soporte de un equipo de seguridad, pasando por mantenimiento, pruebas de calidad, y luego lanzado como una oferta comercial.
¿Por qué regalarle a Red Hat el término «Enterprise Linux» (Linux empresarial? ¿No es esta una exaltación innecesaria o una devaluación de vuestro propio producto?
Nosotros inventamos el Linux empresarial. La primera distribución de Linux empresarial fue SUSE Linux Enterprise, pero nombramos nuestros productos y otros nombran sus productos. No entiendo exactamente a qué te refieres.
A eso me refiero: en OpenELA utilizáis el término «Enterprise Linux» para referiros al código de Red Hat Enterprise Linux como el Linux empresarial de referencia. ¿Acaso no es SUSE también un Linux empresarial?
Sí, ahora entiendo a lo que te refieres. Pero deberías preguntarle a la gente de marketing. Yo, para ser sincero, no estuve involucrado en la creación de ese nombre. No sé cómo surgió. Quiero decir, hay una conexión: utiliza algunas de las letras que tienes en RHEL, ¿sabes? Pero tienes razón, tenemos que recuperar el crédito y recordar que nosotros inventamos el Enterprise Linux.
La decisión de Red Hat de prohibir el uso de su código bajo ciertas circunstancias parece entrar en conflicto con la licencia GPL. ¿Es legal?
Hmm, no soy abogado…
Quiero decir, si lo es, entonces ¿cuál es el punto de la licencia? Y si no lo es ¿por qué todos los que están en contra están usando el código de CentOS Stream para construir la distribución?
Esa es una muy buena pregunta.
¿Es legal?
No soy abogado.
Pero eres un experto en código abierto.
Creo que es legal, o no lo harían, porque IBM tiene más abogados que la mayoría de las empresas ¿verdad?
Me refiero a que la licencia de Red Hat no permite hacer cosas que la GPL sí permite
Sí, entiendo a lo que te refieres. Veo el conflicto que señalas y mi entendimiento (sin ser abogado) es que el EULA (acuerdo de licencia de usuario final) no prohíbe lo que la licencia dice. Todavía puedes hacer lo que la licencia permite, la GPL, solo que hay consecuencias, como que pierdes algo, pero no impide que uses la GPL.
¿Está SUSE preparada para una batalla legal?
No lo sé. No estoy involucrado en los aspectos legales de eso.
Muchos dábamos el choque legal por inevitable, habida cuenta del cambio implementado por Red Hat en relación a la prohibición de redistribución del código. Oracle dio a entender que no cambiaría nada, CIQ (Rocky Linux) también. Solo AlmaLinux aceptó el nuevo marco desde el principio, tomando como nueva base para su sistema a CentOS Stream. Pero CentOS Stream no es cien por cien compatible a nivel binario con RHEL.
Sí, por eso creamos OpenELA, y esa es la belleza de todo esto. Por eso hicimos que OpenELA estuviera disponible, para que cualquiera lo pueda usar, sin temor a ser demandado.
¿El código fuente de OpenELA proviene de CentOS Stream?
Literalmente no sé de dónde proviene el original, porque no estoy involucrado en la parte de ingeniería de eso.
Vuestra competencia con Red Hat es un hecho. Sin embargo, hace muchos años que tenéis una gran relación con IBM. ¿Los caminos del negocio son inescrutables?
Sí, sí, sí, competencia, absolutamente. OpenELA es un mensaje fuerte hacia Red Hat y al mundo, diciendo que no estamos de acuerdo con lo que hacen. Y ahora les damos una pequeña patada en la espinilla ¿vale? Lanzamos el mensaje.
Espero que todos los vendedores de SUSE compitan fuertemente contra Red Hat. Quiero que mis colegas de ventas en SUSE compitan fuertemente contra Red Hat. Ese es su trabajo. Y que también compitan contra Oracle y contra cualquier otro.
Al mismo tiempo, es un mundo colaborativo, porque conozco a bastantes personas de Red Hat en el lado de ingeniería, en mi rol dentro de la comunidad de código abierto. Nos mandamos correos, ellos aprueban mis parches, yo apruebo los suyos, ellos me ayudan, yo les ayudo…
Un ejemplo es el proyecto GCC (GNU Compiler Collection), en el que estoy personalmente involucrado. Y colaboramos de manera confiable, sin guerra, sin competencia. Existe colaboración en el mundo del código abierto.
Para mí, esa es la diferencia. En código abierto, colaboramos. Tal vez nuestras ideas compitan: «No me gusta esto, creo que esto es mejor», «esto es más rápido, esto es más fácil». Luego lo resolvemos y seguimos adelante. Puedo darte nombres de colegas en SUSE que trabajan muy de cerca con gente de Red Hat, y también con muchas otras compañías.
Pero en el ámbito comercial, sí, competimos. Piensa en esto: Linux más o menos eliminó todos los sistemas Unix, ¿verdad? HP-UX ya casi no existe, Solaris está muy, muy limitado. Incluso AIX está disminuyendo. Y luego tenemos IRIX y muchos otros.
Y todos esos son socios ahora, porque HP con HP-UX es un socio clave para SUSE. Y hemos estado trabajando a lo largo de los años en Linux en mainframes con IBM, al mismo tiempo que trabajábamos en Linux en Power y HANA en Power. Así que hay mucha colaboración. También tenemos clientes que migramos de AIX a Linux en servidores Intel o AMD. Entonces, es muy dinámico.
En código abierto, es principalmente colaboración. Entre empresas, hay mucha colaboración en el ecosistema. Pero en el lado de los negocios, a menudo, la competencia es feroz. Y creo que eso está bien.
La línea que separa la colaboración de la competencia es muy fina. Ls dos usáis el mismo Linux, Kubernetes… Pero uno desarrolla OpenShift y el otro Rancher Prime…
Esa es la diferencia clave entre Unix y el mundo del código abierto. Con Unix, teníamos todos esos vendedores, y sí, había estándares, existía el estándar Unix, pero todos los vendedores competían: «Mi Unix», «mi Unix», y solo funcionaba en cierto hardware.
Ahora decimos: «No, trabajamos juntos». Usamos el mismo proyecto Kubernetes, usamos el mismo kernel de Linux, usamos los mismos compiladores, usamos el mismo GNOME, usamos los mismos montones de herramientas. Y luego, donde competimos es en cómo los construimos, cómo los integramos. Ahí es donde se da la competencia.
En el pasado, hablando solo de Unix, cada uno hacía sus propios procesadores, construía sus propios servidores, hacía su propio sistema operativo, y luego tal vez incluso algún software. Entonces teníamos a Sun, que tenía Spark, construía los servidores Spark, tenían Sunway y Solaris, y HP hizo lo mismo, IBM también lo hizo, SGI lo hizo… todos.
Con Linux, compartimos… o debería decir, con el código abierto.
Linux, Kubernetes…
Exacto, la gran familia de Linux y cloud native, si lo prefieres. Hay una mezcla de compartir y competencia, y a veces tus mejores amigos en el desarrollo son tus competidores. Pero está bien. Hay vida.
¿Hay vida más allá de Linux?
He pensado en ello, porque cometí un error hace algunos años y dije que «Kubernetes es el nuevo Linux».
Red Hat hizo exactamente lo mismo.
Hay algo de verdad en ello, en cuanto a la adopción. Es algo que se está convirtiendo en un estándar de facto. Pero, como dice un colega mío «nada se ejecuta en Kubernetes».
Kubernetes es el sistema de gestión, pero aún necesitas un sistema operativo, ¿verdad? Así que eso significa que Kubernetes no está reemplazando a Linux, está complementándolo. Cada tendencia tecnológica que hemos visto, o una implementación específica, ha sido reemplazada en el pasado.
Siempre hay algo nuevo por aparecer ¿sabes?
Bueno, está BSD. Google está trabajando en un nuevo kernel…
Soy un colaborador de ports de FreeBSD, así que conozco BSD. No lo veo como una competencia para Linux. Si miras los números, el número de usuarios y las capacidades, los BSD son buenos para ciertos casos de uso. Pero si lo pones en tu portátil… buena suerte con eso. ¿Ahorro de energía? ¿Suspensión? Linux es mucho más rico y amplio. No creo que BSD vaya a reemplazar a Linux.
Pero he estado pensando en eso, porque te garantizo que dentro de 50 años no será el kernel de Linux el que esté ejecutándose en la mayoría de los servidores. Estoy bastante seguro de eso, pero no tengo idea de qué será lo que lo reemplace.
O quizás me equivoque, y será el kernel de Linux 50.3 o lo que sea. Algunas personas dicen…
… Que Linux se ha convertido en un monstruo enorme, que su código es tan extenso que en un futuro no se podrá mantener.
Sí, me gustaría tener una bola de cristal, porque realmente me causa curiosidad.
Bueno, en 2050 no, pero sabemos seguro que en 2037 aún habrá un Linux por ahí…
Sí, en 2037 habrá mucho Linux. No sé cómo será, o qué lo sustituirá. Sabes, el tema de las disrupciones es que son difíciles de predecir. Cuando empecé a estudiar en 1990, nadie sabía que Linux iba a llegar, ¿verdad?
Ni siquiera Linus Torvalds, supongo. No estoy seguro, pero entiendo que si las cosas van a cambiar significativamente, tal vez sea algo diferente. Pero Linux sigue evolucionando. Ahora tienes partes de Linux que están comenzando a implementarse en Rust.
Así que quizás Linux se esté auto-disrumpiendo, o tal vez sea otra cosa. Nos deberíamos encontrar en el SUSECON de 2037 y ver qué ha pasado. ¿Estás planeando retirarte para entonces?
(Risas) No sabría que decirte ahora mismo.
Si me preguntas por mi mejor suposición, diría que creo que Linux permanecerá mucho tiempo más en la infraestructura de servidores. Tal vez algo nuevo llegue para los dispositivos móviles. Pero Android utiliza el kernel de Linux. Y me gusta decir que la mayoría ya está usando software libre porque hay mucho software libre en los iPhones también. Pero mi teléfono Android está utilizando el kernel de Linux.
Así que quizás… Sé que Google está desarrollando algo llamado Fuchsia. Tal vez eso acabe en los teléfonos Android, tal vez eso tenga futuro.
Veremos en unos cinco años. Amazon también está trabajando en su propio sistema operativo para sus dispositivos, abandonando Android, pero no Linux.
Será interesante verlo. Sabes, Linux sigue evolucionando. Siempre hay nuevas cosas.
El software de código abierto puede ser un arma de doble filo para las empresas. Por un lado, puede fomentar la innovación, la colaboración… Por otro lado, también puede generar preocupaciones sobre los ingresos y la apropiación de proyectos. Sabes de lo que hablo, porque últimamente algunas empresas que crecieron en el ámbito del código abierto se están cerrando debido al «free riding» (aprovechamiento gratuito). Gigantes como Amazon y otros en bases de datos…
Sí, sí, sí, lo veo, es…
¿Cuál es tu opinión al respecto?
En mi opinión, si consumes código abierto, a veces veo que no es una obligación legal, pero personalmente siento que existe una obligación moral de devolver algo. Así que si consumes, si usas código abierto, creo que debemos esforzarnos por devolver algo en forma de contribuciones de código, y no solo hacer de esto una calle de un solo sentido.
Hay licencias que permiten más esa dinámica de calle de un solo sentido, pero personalmente no me gusta mucho eso. Si miras lo que hace SUSE, por ejemplo, tenemos una política de código abierto que es «upstream first», lo que significa que nuestros desarrolladores, cuando hacen cambios, deben hacerlos en el contexto de los proyectos upstream primero.
Así que no lo hacen a puertas cerradas, sino en el kernel de Linux, en Rancher, en los proyectos upstream que corresponden, y luego esos cambios se convierten en parte de nuestro producto. Pero sí, dependiendo de la licencia de código abierto no hay, necesariamente, un requisito legal de hacer que tus cambios estén disponibles. Pero yo, personalmente, lo haría siempre que consuma algo. Si hago un cambio, lo devuelvo.
¿SUSE seguirá siendo una empresa abierta?
Sí. Lo hemos dejado claro, incluso en las tarjetas de las habitaciones del hotel, ¿no?
«Choice happens» (la elección ocurre) [El lema de SUSECON 24].
Sí, «choice happens» (la elección ocurre). Aunque la versión completa es un poco más larga y en realidad dice «hacemos que la elección ocurra», porque «choice happens» es correcto, pero también da la impresión de que ocurre mágicamente o automáticamente.
No es que tú y yo nos sentemos a meditar y, de repente, la elección ocurra. Es SUSE quien toma medidas activas. OpenELA es un ejemplo. Decimos: «Bien, ahora hacemos que la elección ocurra», y luego tú puedes elegir. Pero nosotros tenemos que trabajar, tenemos que invertir o tener una política de código abierto que diga que contribuimos a los proyectos upstream, no nos quedamos nada para nosotros.
Así que hay mucho compromiso y participación explícita de SUSE a favor de la elección.
¿Qué es lo mejor de SUSECON 2024?
Un colega tuyo me hizo una pregunta similar, y le dije: «¿Puedo elegir tres cosas?». Estrategicamente, creo que el anuncio sobre IA es clave.
Aunque la IA ya se ha vuelto un poco cansina, porque parece que todo ahora tiene IA, incluso el helado. Está en todas partes, pero la gente tiene necesidades y no quiere poner todo en la nube pública. Muchos quieren mantener sus propios datos, pero no hacer todo por sí mismos. Así que ayudar a la gente a hacer cosas bajo su control, ese es el aspecto estratégico que realmente me gusta.
El geek de la tecnología en mí es un fan de NeuVector, y la defensa contra ataques DDoS (ataques de denegación de servicio distribuidos) es algo que me gusta mucho. Porque NeuVector es muy bueno para observar lo que está pasando en el tráfico de red dentro del clúster de Kubernetes.
No sé qué cuánto sabes de NeuVector, pero realmente examina el tráfico de red capa a capa, incluso sin cifrar, y aprende de ello.
En realidad, necesito profundizar en eso, porque no sé mucho sobre NeuVector.
Es un paso muy natural, y es una pieza que faltaba de alguna manera. Así que ese es el geek de la tecnología en mí. Y luego, el geek del cliente en mí se entusiasma con el futuro de Linux, el ciclo de vida, el nuevo lanzamiento del próximo año, etc.
Porque sé, habiendo hablado con clientes, colegas, analistas, que la adquisición de StackState realmente nos lleva… Ya estábamos en una buena posición, pero con StackState, nos lleva al ático, por decirlo de alguna manera. Esa es mi parte favorita orientada al cliente.
Mencioné antes una segunda parte de la entrevista sobre openSUSE, pero no sé…
¿Quieres que lo hagamos? Tenemos la conferencia de openSUSE la próxima semana. Vente.
¿Es en…?
En Nuremberg.
Me pilla un poco lejos. Lo dejaremos para otra ocasión. Pero sí me hubiera gustado hablar contigo de openSUSE. Tengo preguntas, quejas…
¿Quejas? ¿Sobre qué? ¿Usas openSUSE?
No, porque…
Entonces, yo sí tengo una queja (risas).
[Dejamos la conversación sobre openSUSE para otro día]
La entrada Gerald Pfeifer, CTO de SUSE: «Nosotros inventamos el Linux empresarial» es original de MuyLinux
