Nuevo análisis, cambio de aires. Literalmente, además, ya que en esta ocasión el protagonista del artículo no es otro que el Slimbook Kymera, un PC de altos vuelos que destaca por su diseño y capacidad, incluyendo una ventilación que está a otro nivel. Pero antes de entrar en materia, hay unas cuantas cosas que vale la pena aclarar.

La primera es la de siempre: el análisis se enfoca en la experiencia de usuario, no en hasta dónde llega el hardware. Sin embargo, dado el equipo y la configuración con la que lo he pedido, sería un desperdicio no aprovechar para someterlo a presión, aunque nada de ello se refleje en el texto (más datos sobre este asunto, al final).

La segunda es que, a diferencia de un portátil, el tipo de dispositivo que más hemos analizado por estos lares, un PC al uso, una torre, puede resultar un contenido más anodino, al montar componentes estándar y prescindir de características cuya compatibilidad es clave para valorar la experiencia. Y algo de eso hay, pero un ordenador clásico también presenta sus retos.

Ese motivo —la potencial dificultad que puede presentar un portátil frente a un sobremesa para ejecutar Linux con todas las garantías—, unido a que en Linux somos muy del do it yourself, es lo que nos ha llevado a ignorar por norma estos equipos, aun cuando muchos preferimos el sobremesa al portátil. Pues bien, he aquí el primer análisis de un equipo de sobremesa en toda su plenitud.

Nota sobre las imágenes: como de costumbre, las imágenes que ilustran este artículo son las oficiales e incluyen tanto renders, como fotografías de estudio. Es así porque muestran con mayor fidelidad el equipo y porque Tux no me otorgó ni el talento, ni la paciencia como para hacerlo por mí mismo. E incluyo una foto propia para demostrarlo.

Slimbook Kymera

Comencemos por los antecedentes: Slimbook Kymera fue el primer PC tradicional que lanzó la marca española hace ya unos cuantos años, y aunque desde entonces su catálogo se ha ampliado y el producto se ha convertido en serie, y esta se ha ido renovando progresivamente, hay algo que no ha cambiado: Kymera es la torre de Slimbook, su gran referente para la sobremesa.

De todas las renovaciones de las que ha sido objeto el equipo, la última fue la más notable. Slimbook presentó la nueva Kymera Collection a finales del año pasado, con hasta seis modelos de caja predefinidos y más posibilidades si cabe en cuanto a personalización, aunque lo más interesante, como siempre, va por dentro. Pero a nadie amarga un dulce y poder elegir un estilo acorde con el propio es de agradecer.

De hecho, desde que sacaron la nueva colección han pasado varios meses y ya hay cambios, incluyendo una versión Compact mATX y nuevas configuraciones ETX, es decir, más opciones de tamaño a ambos extremos, si bien las estrellas de la serie se mantienen en formato ATX con los diseños ya conocidos. ¿Cuál es el que me ha llegado a mí? He dado una pista, así que te doy la oportunidad de adivinarlo, antes de que lo desvele.

Veamos ahora la configuración interna que permite el equipo, porque es ahí donde reside su valor intrínseco: si apuntas hacia un dispositivo de estas dimensiones, es porque lo necesitas, ya sea por potencia de procesamiento, gráfica o incluso por almacenamiento, aunque tanto portátiles como mini PC han avanzado tanto en este sentido que, seamos honestos, en la CPU y la GPU está su principal atractivo.

Otro aspecto relevante para muchos de los usuarios que siguen anteponiendo el factor forma de la torre a otros más acomodables, es la capacidad de personalización a nivel de componentes, así como la accesibilidad para su ampliación a futuro. En ambos casos, el Kymera no decepciona. Y como muestra, todas las opciones que permite la configuración de procesador y gráfica.

CPU Intel:

• Intel i5 14600K
• Intel i7 14700K
• Intel i9 14900K
• Intel Core Ultra 5 245K
• Intel Core Ultra 7 265K
• Intel Core Ultra 9 285K

CPU AMD:

• Ryzen 5 7600X
• Ryzen 7 7700X
• Ryzen 9 7950X
• Ryzen 9 7950X3D
• Ryzen 5 9600X
• Ryzen 7 9700X
• Ryzen 9 9900X
• Ryzen 9 9950X
• Ryzen 7 9800X3D
• Ryzen 9 9900X3D
• Ryzen 9 9950X3D

GPU AMD:

• AMD Radeon RX 6400 4 GB
• AMD Radeon RX 7600 8 GB
• AMD Radeon RX 9060 XT 16 GB
• AMD Radeon RX 9070 16 GB
• AMD Radeon RX 9070 XT 16 GB

GPU NVIDIA:

• NVIDIA 5050 RTX 8 GB
• NVIDIA 5060 TI RTX 16 GB
• NVIDIA 5070 RTX 12 GB
• NVIDIA 5070 TI RTX 16 GB
• NVIDIA 5080 RTX 16 GB
• NVIDIA 5090 RTX 32 GB

GPU Intel:

• Intel Arc A750 8 GB
• Intel Arc B580 12 GB
• Intel Arc A770 16 GB

La memoria y el almacenamiento ofrecen un margen de configuración igualmente generoso: entre 16 GB y 192 GB de RAM DDR5, y entre 500 GB y 4TB de SSD NVMe tanto para la unidad principal como para la secundaria, con un tope combinado de 8TB. Claro que gracias al formato del equipo, hay hueco también para unidades SSD de 2,5″ y discos duros convencionales de 3,5″.

Los nuevos Kymera ATX aceptan fuentes de alimentación desde los 500W hasta los 1.500W, y la refrigeración puede elegirse entre varias gamas, incluyendo soluciones líquidas AIO con ventiladores adicionales y, como ya advertimos en el anuncio de lanzamiento, con un perfil discreto o con la iluminación LED —tanto para los ventiladores como para los módulos de RAM— al máximo, según el gusto de cada uno.

La configuración del equipo concluye con el chipset —o más exactamente con la plataforma de placa base que figura en el configurador—, además de periféricos opcionales como aún más ventiladores, tarjeta de red Ethernet PCIe de 10Gb y, dependiendo del modelo de caja, vinilo personalizado. Y la distribución Linux con la que deseas recibir el equipo, a elegir entre un montón de alternativas: de Slimbook OS a opciones basadas en Ubuntu como Kubuntu, Xubuntu, Linux Mint o KDE neon, pasando por Fedora, CachyOS, openSUSE… O Windows. O nada, y te instalas tú lo que quieras.

Toda esta configuración se refiere al Slimbook Kymera ATX, sin importar el diseño. Los modelos mATX y ETX ofrecen configuraciones base adaptadas a su formato y, por lo tanto, menos y más potentes, respectivamente, por lo que el precio de arranque varía de uno a otro. Aunque lo cierto es que el precio de arranque varía también en relación a la caja y CPU elegidas. Concretemos, pues.

Pero antes, una pregunta: ¿has adivinado el modelo?

Slimbook Kymera Cristal Black

Fue el modelo que me sugirieron desde Slimbook y por mí, tanto monta, aunque observando con atención el resto de la colección… No lo tengo tan claro. Como sabe todo lector habitual de MuyLinux, porque siempre lo repito, suelo pedir lo que me compraría, lo que por lo general no se sitúa en los extremos, sino en la perspectiva que me ofrece cada equipo para mi uso en el día a día.

Sin embargo, este procedimiento lo aplico a la configuración interna. En este caso, el exterior también cuenta, y hay modelos que me atraen más que otros. Por ejemplo, el Kymera mATX es una opción muy interesante por tamaño y precio de salida; el Kymera Woodline me resulta muy discreto y elegante a la vista; y el Kymera Retro tiene un puntazo innegable.

Pero tengo que reconocer que el Kymera Cristal Black luce espectacular, en imagen y en vivo, y a falta de ver el resto in situ, creo que es una apuesta segura: el apartado estético es apreciable a simple vista, pero también la calidad de construcción —los materiales exteriores son aluminio y cristal templado— transmite una excelente sensación desde el primer momento. Y amplitud. Mucha amplitud. Por dentro, me refiero.

No hago unboxings y esta no va a ser la excepción, pero cuando te llega la gigantesca caja de transporte, el tamaño del bicho se empieza a perfilar en tu mente. Luego hay mucho de envoltorio, por fuera, pero sobre todo por dentro, protegiendo los componentes, y el efecto es doble: la torre es grande, pero no tanto; y el empaquetado es realmente impresionante, casi parece que pudieras dejarlo caer desde las alturas y no la pasaría nada. Por lo que sea, no lo hice (!).

En el empaquetado y desempaquetado se aúnan dos detalles de los que disfruto, vaya el mérito para Slimbook: la forma en que te llega el equipo denota extremo cuidado en el envío y lo mismo sucede con el montaje interno. Es una de las razones por las que prefiero que me lleguen las cosas montadas: soy perfectamente capaz de hacerlo por mí mismo, pero nunca me queda tan bien.

Las medidas concretas del Kymera Cristal Black son: 28,5 cm de ancho, 40 cm de alto y 42 cm de largo, esto es, un tamaño apto para torre ATX estándar, algo más pequeña y compacta que la caja típica, pero con el espacio interior muy bien aprovechado, gracias a una buena gestión de cables. A nivel visual, es muy parecida a la Pulsar ARGB de Nfortec, pero de ángulos rectos.

Como se puede ver en las imágenes, el Kymera Cristal viene en colores blanco y negro, y para gustos, colores. Y nunca mejor dicho. Para mi gusto, el negro es más bonito… y un poco más económico, lo que tampoco está mal.

En ambos casos tiene que ser una locura para los amantes del RGB, algo que no soy y, en consecuencia, uno de mis requisitos fue el prescindir de todo elemento de este tipo. El ahorro no es solo en ruido visual: el coste para tenerlo todo iluminado es de 80 euros: 30€ los ventiladores y 50€ la RAM, todo ello opcional.

No quise luces, pero sí la mejor ventilación, que para eso el Kymera Cristal Black se presenta bajo el enunciado «estilo y color, en un interior a la vista y un flujo de aire brutal», lo cual se traduce en una configuración con diez ventiladores… y porque no caben más (no me quiero ni imaginar todo eso iluminado). Pero que nadie se asuste: no tiene por qué ser así.

Como todo, dependerá de la configuración de hardware si necesitas más o menos ventilación, y es posible usar disipación por aire o líquida todo en uno. Cada método tiene sus ventajas: la líquida puede enfriar mejor y reducir algo el ruido percibido, pero también es más costosa y añade un punto adicional de complejidad frente a la simplicidad de la refrigeración por aire.

La imagen no engaña: diez ventiladores

Lo que ya no depende tanto de gustos —o tal vez sí— es la elección del modelo por procesador, aunque este aspecto también lo tenía claro: esta vez, AMD, lo cual también supone un ligero ahorro… en su configuración base. Así, el precio del Kymera Cristal Black comienza en 990 € con CPU AMD Ryzen 5 7600X, 16 GB de RAM DDR5, SSD NVMe de 500 GB y fuente de alimentación de 500W 80 Bronze.

¿Y la gráfica? Habiendo probado las últimas veces NVIDIA, la idea de tener un combo de AMD se me antojaba ideal, por lo que Ryzen y Radeon harían pareja. Sin embargo, y entramos ya en el meollo de la cuestión, en esta ocasión me abstraje de mi proceder habitual y me fui a por todas, con tan mala suerte de que no pude montar los componentes exactos que había planeado en el tiempo preciso…

Y me tuve que conformar con AMD Ryzen 9 9950X y AMD Radeon RX 9070 XT, dicho sea con ironía. Lo cierto es que ninguno de mis equipos actuales —y no tengo poca cosa— se aproximaba a la potencia que estos dos bichos ofrecen, ni por separado, ni mucho menos juntos. A ello le aderecé la nada despreciable cantidad de 128 GB de RAM DDR5 a 5600 MHz (en el configurador la memoria figura ahora en el rango de 5200-6000 MHz) y para el almacenamiento, 1 TB SSD NVMe Samsung 990 PRO.

El porqué de esta configuración, más adelante. Pero convengamos en que es muy potente, que es lo que me interesaba. No la más potente, porque esperar por el Ryzen 9 9950X3D se me hacía muy largo, y la opción de NVIDIA ni me lo planteba. Pero que nadie se lleve a engaño: NVIDIA GeForce RTX 5090 no tiene rival ahora mismo, y a saber cuándo vuelve a tenerlo.

La configuración del Slimbook Kymera Cristal Black la completa, según se puede comprobar en la página de compra del equipo, refrigeración de gama alta —para la CPU— y una fuente de alimentación 1000W 80 Plus Gold modular. Contando con CPU, GPU, RAM y SSD, el precio del equipo es, en estos momentos, algo más de 3.500 € (es complicado determinarlo con exactitud, al no figurar en el configurador la placa base concreta que monta esta unidad).

¿Para qué tanto equipo? He dicho que luego.

Antes, me gustaría señalar un componente capital al que pocas veces se presta la debida atención: la placa base. De hecho, es común que las ensambladoras de ordenadores de sobremesa no especifiquen el modelo, porque no usan siempre el mismo. Lo que sí suelen hacer, es —en particular, las compañías especializadas en Linux— usar primeras marcas, de probada compatibilidad.

En mi caso, se trata de la MSI MAG X670E TOMAHAWK WIFI, una placa bastante potente y equilibrada para el resto del hardware, aunque después de trastear un poco y de investigar otro poco, he llegado a la conclusión de que Slimbook hiló fino con su elección, porque los nuevos modelos de gama media y alta son un tema delicado… en Linux, pero también en Windows.

Sea como fuere, tras el ajuste inicial, todo fue bien: LAN 2.5G, Wi-Fi 6E (no alcanzó el nuevo Wi-Fi 7, pero como funciono por cable no me importa mucho), Bluetooth 5.3, etc. Incluye un puerto USB 3.2 Gen 2×2 (20 Gbps) Tipo-C, además de múltiples puertos USB 3.2 Gen 2 (10 Gbps) y Gen 1 (5 Gbps); y dos adicionales que lleva la caja.

Llegados a este punto querría señalar algo en relación a montarse un equipo así, por piezas, aunque no sea a la antigua usanza, esto es, recibiendo el puzle en casa y poniéndose manos a la obra uno mismo: incluso aunque lo tengas todo muy claro, no digamos ya si no es el caso, preguntar es gratis. Ante la duda, pregunta.

Hoy hablo de Slimbook, pero vale para cualquier otra de las marcas especializadas en Linux: os van a atender muy bien y, además, conocen el terreno mejor que nadie. Ergo, si vas a comprarte un equipo nuevo y no las tienes todas contigo, sobre todo si la inversión es importante, contacta primero con ellos y exponles tus dudas. Te ayudarán. Por supuesto, puedes buscar información, preguntar en foros, preguntarle a la IA… Pero pregúntale también a ellos.

Slimbook OS

Se me olvidaba mencionar otro elemento destacado de la experiencia predeterminada: Slimbook OS, la distribución propia de Slimbook, especialmente pensada para sus equipos. Como he dicho, es posible adquirir cualquier Slimbook con o sin sistema, con Windows o con una variedad ciertamente apabullante de distribuciones Linux, Slimbook OS me pareció lo más apropiado.

Es la misma recomendación que hago cuando pruebo un equipo de Tuxedo: mejor con Tuxedo OS, aunque sea para probarlo, y luego ya lo que quieras. Con Slimbook sería lo mismo, pero tengo dudas —quizás similares en su mismo contexto— de que sea igual de fundamental hacerlo con un sobremesa que con un portátil. Ahora bien, es lo que hice y me encontré con… Es algo confuso.

Cuando Slimbook OS lanzó su primera versión en abierto, en septiembre de 2024, lo describimos como una derivada de Ubuntu LTS con diferentes novedades en su haber. Tiene sentido, habida cuenta de que hay sabor GNOME y KDE Plasma. Sin embargo, yo solo probé la segunda y me encontré con un KDE neon retocado… y no siempre para bien, aunque hay detalles que entran en el ámbito de los gustos personales.

A mí no me gustó mucho, la verdad. Los retoques visuales, la preinstalación de aplicaciones de terceros y determinadas decisiones que para mí demuestran un criterio con el que no puedo coincidir, hicieron que tardara muy poco en dar el salto a algo más de mi estilo, como el propio KDE neon primero, para comprobar algunas cosas; y openSUSE Tumbleweed después, ya para echar millas.

No es el objeto de este análisis juzgar a Slimbook OS, pero como formó parte de mis primeras impresiones, qué menos que dedicarle unas líneas.

La buena noticia es que la experiencia con Tumbleweed ha sido excelente, y lo único que podría haber echado de menos de Slimbook OS, está mantenido por la compañía para distribuciones como Ubuntu y derivados, Debian, Manjaro, Fedora y openSUSE. Me refiero a Slimbook Service, un pequeño componente que reside en la bandeja de sistema y que facilita el acceso a funciones en portátiles o recibir «notificaciones importantes para tu modelo de Slimbook, como una actualización de la BIOS». Más información.

Lo tengo instalado y funcionando, pero tampoco es imprescindible, al menos en un sobremesa compatible como es el Kymera.

La experiencia Kymera

Toca hablar de la experiencia, aunque creo que a estas alturas del texto ya está todo dicho, o se puede dar por sentado: empaquetado impecable, montaje impecable, configuración brutal y componentes de primer nivel… La única crítica que he podido hacer hasta este punto se debe al sistema, y es opinable. What else? O, mejor aún: ¿qué se puede esperar que achaque a semejante bicho?

Voy a exponerlo de otra manera: conservo todavía un sobremesa de 2016 cuya configuración palice en comparación con el Kymera: i5 de cuarta generación —con sus gráficos integrados—, 16 GB de RAM, SSD SATA… Y Linux, cualquier distribución y escritorio, funciona estupendamente. Solo usando el navegador se nota renquear al equipo, cuyo límite, eso sí, se encuentra rápido en la multitarea con aplicaciones algo exigentes. También con juegos, claro.

A lo que voy es a que disfrutar de una experiencia decente con Linux requiere de los recursos justos: ni los requisitos mínimos que suelen recomendar algunas distros, ni tampoco mucho más. El cuello de botella viene dado por el navegador en las configuraciones más humildes, o por las aplicaciones —juegos incluidos— y procesos en las más altas. En resumen: nadie necesita un Kymera para hacer muchas, muchas cosas con Linux.

A modo de ejemplo, Slimbook tiene equipos como el Zero (Intel N150, 8 GB de RAM) que arrancan en los 300 y pico euros, y que para un uso corriente es más que suficiente. El Kymera mATX sale por 600 € en su configuración base (AMD Ryzen 5 5600G, 16 GB de RAM), y aunque los componentes son bastante modestos, su rendimiento es obviamente superior. No hace falta gastarse más para tener una muy buena experiencia en casos de uso doméstico o de oficina.

Si me preguntas, mi preferido del catálogo de Slimbook, hablando siempre de sobremesa, es el One, que ahora se sirve con dos configuraciones: AMD Ryzen 7 H 255 y AMD Ryzen AI9 HX 370. La primera cuesta de inicio 762 € y la segunda 300 € más, justificados por una APU superior con NPU para tareas de IA, así como por una gráfica más potente. Con algo más de memoria y almacenamiento, ese equipo da para muchísimo, y no precisamente por la IA.

Kymera vs One: cuestión de tamaño

Es momento, pues, de abordar una cuestión que quizás alguien se esté haciendo: si para lo que sea que vayas a utilizar el equipo, un mini PC cumple, no lo dudes, es la mejor elección a día de hoy. De hecho, he aquí otra crítica, esta intrínseca al hardware del Kymera: acostumbrado en los últimos tiempos a usar portátiles o mini PCs para todo, fue encenderlo y notarlo.

En otras palabras, de estar usando dispositivos a los que apenas se oye cuando los estás sometiendo a determinado estrés, a que el sonido de los ventiladores te golpee desde el arranque. Poca cosa, siendo sincero, pero lo suficiente como para percibirlo y no con agrado. Pero es que ese zumbido remanente es una brisa, comparado con el ruido que alcanza el equipo con juegos o tareas exigentes, de las que lo ponen a trabajar de verdad.

Todo es relativo, cabe matizar: no es lo mismo estar acostumbrado a usar torres con gráficas dedicadas que venir de ultraportátiles y mini PC; no es lo mismo usar el ordenador en un ambiente diurno, que en la quietud de la noche; no es lo mismo hacer unas tareas que otras… Pero, en mi experiencia, me resulta complicado jugar por las noches a títulos exigentes sin los cascos puestos. Es solo un ejemplo.

Las cosas como son: esto lo digo como usuario irredento de teclados mecánicos, a quien no es raro encontrar tecleando con furia en plena madrugada, con algún pódcast o música de fondo. Y vive Tux que mi teclado es más ruidoso que el Kymera en modo reactor nuclear, aunque son ruidos diferentes. En todo caso, es el aspecto negativo que más me ha impactado y tenía que mencionarlo.

¿Minimizaría el ruido la refrigeración líquida? Podría ayudar. Pero en esto coincido con Linus Torvalds y por muchos PCs que haya montado —muchos más que él, me temo— hay cosas que no controlo, ni tengo interés de hacerlo. También podría usar teclado de membrana, periféricos inalámbricos… Pero va a ser que no.

¿Y entonces?

Entiendo que haya a quien choque mi forma de ver las cosas, pero soy bastante pragmático, siempre que la economía acompañe: si solo tienes para un equipo y no te sueles mover, un mini PC es lo suyo. Si solo tienes para un equipo y te sueles mover, solo un portátil puede cubrir de manera eficiente tus necesidades. ¿Y si ambos dispositivos se quedan cortos? Esta es la respuesta. Al menos, en la sobremesa.

Por más que mini PCs y portátiles hayan avanzado enormemente en los últimos años en cuanto a capacidades de memoria y almacenamiento, no alcanzan las prestaciones de una torre, cuya potencia de procesamiento y gráficos sigue sin tener parangón en el ámbito doméstico. Es tan sencillo como eso.

Pongámoslo así: ejecutar sistemas de IA, juegos triple A, editar y procesar vídeo, virtualizar… Todo puedes hacerlo con un alto grado de dignidad con una variedad de hardware. No obstante, si el objetivo es hacerlo todo con holgura o llegar a límites de otra manera inalcanzables, las concesiones son parte del trato: tamaño, consumo, ruido… Y precio, claro. Un trato que estoy dispuesto a asumir porque sí, quiero hacer todo eso.

¿Y entonces…? ¿Por qué no una 5090, 192 GB de RAM…? Por varios motivos: el coste es de absoluta locura, 128 GB de RAM ya me parecen todo un exceso —cosas de la IA, amigos—… Y algo más importante en el caso que nos ocupa: la compatibilidad del combo AMD con Linux. O lo que es lo mismo, la tranquilidad de poder probar muchas cosas —léase distribuciones, pero no solo— sin complicarse más de lo estrictamente imprescindible.

Mi foto

Por ejemplo, llevo probando estos últimos meses CUDA para cargas de trabajo en local y quería hacer lo propio con ROCm, aunque sé que no está a su nivel. Sin embargo, su enfoque en ecosistema de código abierto me atrae mucho más. También el hecho de ser la alternativa al referente. Lo mismo me sucede con el tema juegos: según los benchmarks, la Radeon RX 9070 está ligeramente por encima de la GeForce RTX 5070, por lo que la distancia con respecto a una 5080 o 5090 es patente, pero… ¿lo compensa la relación calidad-precio?

No voy a ponerme a divagar ahora, pero tampoco voy a entrar en los entresijos técnicos de procesador o gráfica, ni hacer menciones de Perogrullo, más allá de lo ya expuesto: rendimiento brutal… y tal y tal. Ni siquiera voy a recomendar este equipo con la configuración que me ha llegado, porque pocos usuarios, incluso entre los más exigentes, necesitan algo así.

Lo que voy a hacer es remitir al lector a un futuro cercano, pues al contrario que la temible quimera, el monstruo mitológico de tres cabezas que vomitaba llamas, el Kymera tiene que ser puesto a prueba. En más de un sentido.

Conclusiones

En pocas palabras, el Kymera Cristal Black es un equipazo, con un mérito relativo, porque irse a por lo mejor, o casi lo mejor que existe en el mercado, es mera cuestión económica. Lo que aporta Slimbook, por su parte, es digno de consideración, así que permíteme que vuelva a hacer hincapié en ello: diseño —entendiendo esto como la confección del producto en su conjunto—, montaje, servicio y, por qué no decirlo, un precio ajustado, dadas las circunstancias.

Acerca del precio, vale la pena recordar que atravesamos una época realmente convulsa, cuyo desenlace parece más lejano de lo deseable; pero de los 990 € del precio de salida a lo que cuesta mi Kymera, hay un trecho en el que caben decenas de configuraciones muy potentes y mucho más asequibles. ¿Un término medio? Ryzen 7 9700X, Radeon RX 9060 XT, 32 GB de RAM… No llega a los 2.000 € y es otro equipazo que puede casi con todo.

Lo mejor:

• El diseño de la caja, muy elegante y no tan grande como otros modelos de su mismo formato.
• El «toque Slimbook» se nota en muchos detalles.
• El flujo de aire es realmente brutal, pero…

Lo peor:

• El ruido que alcanza el equipo puede llegar a ser molesto si no estás acostumbrado.
• Slimbook OS no es la mejor carta de presentación.

La entrada Slimbook Kymera, análisis: diseño, potencia y concesiones en una torre Linux de altos vuelos es original de MuyLinux

FSR 4, la cuarta iteración de la tecnología de reescalado de AMD, ha generado bastante controversia, porque si bien representó en términos cualitativos una mejora frente a las versiones anteriores, lo hizo a costa de traicionar las tres grandes virtudes que tenía frente al DLSS de NVIDIA: código abierto, soporte multiplataforma con respecto a la GPU y retrocompatibilidad.

Al contrario de lo que ocurrió con las versiones anteriores, el código fuente de FSR 4 no está disponible oficialmente. Además, hasta ahora solo ha soportado oficialmente las gráficas de arquitectura RDNA 4, dejando fuera tanto a generaciones anteriores de gráficas Radeon como a NVIDIA. Con FSR 4, que es un producto derivado de un esfuerzo conjunto entre Sony y AMD, parece que la corporación dirigida por Lisa Su lo tuvo claro en aquel momento: si se quería competir con el DLSS de NVIDIA, había que hacer lo mismo que el DLSS de NVIDIA.

El convertir a FSR 4 en poco más que una copia de su gran rival trajo mejoras en la calidad visual que se obtenía, siendo este posiblemente el frente en el que más languidecía frente a DLSS, pero lo hizo a costa de destruir todas las virtudes que tuvo en iteraciones anteriores. Un año después de que se conociera la exclusividad para RDNA 4, los consumidores han dictaminado una sentencia muy contundente: ante la copia (FSR 4) y el original (DLSS), se quedan con el original, y esta afirmación no es baladí.

Según Jon Peddie Research, NVIDIA acaparó en el segundo trimestre de 2025 el 94% de los envíos de gráficas dedicadas frente al solo 6% de cuota de AMD Radeon. A eso hay que sumar que desarrolladoras como Capcom decidieron quitarle el protagonismo exclusivo a las tecnologías del gigante rojo, que fueron implementadas en el remake de Resident Evil 4, para centrarse en las del gigante verde con Resident Evil Requiem y Pragmata. Dicho de otra manera, Radeon está, literalmente, en el peor momento comercial de su historia contando solo sus gráficas dedicadas, y no son pocos lo que perciben que estos productos en la actualidad tienen muy difícil justificación más allá del escritorio Linux.

Volviendo a FSR 4, desde hace tiempo hay vías para hacerlo funcionar sobre las gráficas RDNA 3 (RX 7000) y RDNA 2 (RX 6000), pero estas no son oficiales. El error de no hacer la última versión de la tecnología de reescalado compatible con al menos las dos generaciones anteriores de gráficas, aunque fuese con limitaciones, terminó provocando reacciones pidiendo a AMD que rectificara el rumbo. Por suerte y según han recogido en GamingOnLinux, parece que así será con FSR 4.1.

Sí, ahora sí es oficial: AMD ha anunciado que FSR 4.1 será compatible con RDNA 2 y RDNA 3, lo que no solo va a beneficiar a los usuarios que poseemos una o varias gráficas basadas en alguna de las dos arquitecturas mencionadas, sino que esto, haciendo uso de un poco de lógica, podría derivar después de que Valve haya mantenido conversaciones con el fabricante de gráficas.

La posible llegada de FSR 4.1 a RDNA 3 es algo de lo que publicamos en una ocasión anterior, y, viendo las características de la Steam Deck y la Steam Machine 2, es obvio que la exclusividad para RDNA 4 ha perjudicado a Valve. Recordamos que la Steam Deck emplea una APU de AMD con una gráfica integrada basada en RDNA 2, mientras que la Steam Machine 2 utilizará una RX 7600 ligeramente recortada como gráfica dedicada. Esto hacía que los dos dispositivos quedaran, al menos en términos oficiales, fuera de poder soportar FSR 4.

En lo que respecta al funcionamiento de FSR 4.1 sobre RDNA 3, AMD ha comentado que proporcionará a los usuarios una mejora en la fluidez de los videojuegos, imágenes más nítidas y que “estará listo out of the box para los jugadores de la Serie Radeon 7000 en más de 300 juegos compatibles en el lanzamiento”. Sobre RDNA 2, desde Radeon se han limitado a decir que proporcionará más fluidez e imágenes más nítidas.

En resumidas cuentas, estamos ante una rectificación de AMD para recuperar, aunque sea de manera muy parcial, el espíritu original de FSR. Como ya hemos comentado, posiblemente Valve haya tenido que ver en todo esto viendo que la falta de soporte de FSR 4 perjudicaba a sus dispositivos, y, por supuesto, esta es una buena noticia para todos los poseedores de una gráfica basada RDNA 2 o RNDA 3, aunque para AMD posiblemente ya sea demasiado tarde ante aquellos que ya han decidido sustituir su RX 6900 XT o RX 7900 XT por un modelo de NVIDIA.

La entrada AMD hace oficial la llegada de FSR 4.1 a RDNA 2 y RDNA 3, beneficiando a la Steam Deck y la Steam Machine es original de MuyLinux

KDE acaba de anunciar una importante inyección económica por parte del Sovereign Tech Fund: más de un millón de euros destinados al desarrollo de software e infraestructura crítica del proyecto.

La inversión llega a través de la Sovereign Tech Agency alemana, se enfocará en reforzar la fiabilidad estructural y la seguridad de componentes esenciales del ecosistema KDE, incluyendo Plasma, KDE Linux y los frameworks que sustentan sus servicios de comunicación.

El anuncio se da asimismo en un momento especialmente sensible para todo lo relacionado con la soberanía tecnológica europea, la privacidad y la dependencia de grandes proveedores tecnológicos y, de hecho, el propio comunicado incide en ello ,cargando contra el modelo de negocio de compañías como Microsoft, Google, Meta o Apple, a las que acusa de imponer software caro, inseguro y plagado de espionaje.

En este contexto, KDE reivindica su papel como alternativa abierta para infraestructuras personales, empresariales y públicas, al tiempo que recuerda que el proyecto recuerda que lleva tres décadas desarrollando software libre y de código abierto para todo tipo de usos: desde sistemas operativos y entornos de escritorio, hasta visores de documentos, herramientas multimedia y bibliotecas de desarrollo.

Según explica Fiona Krakenbürger, directora técnica de Sovereign Tech Agency, la apuesta por KDE tiene una razón clara, y es que el escritorio sigue siendo una pieza crítica de la infraestructura digital moderna. “Estamos invirtiendo en KDE porque es uno de los dos grandes entornos de escritorio utilizados en Linux y desempeña un papel clave en cómo millones de personas experimentan la tecnología abierta”, señala la responsable.

Krakenbürger añade además que reforzar la infraestructura de pruebas, la arquitectura de seguridad y los frameworks de comunicación de KDE supone “invertir en la resiliencia y fiabilidad de la infraestructura digital central de la que depende la sociedad moderna”.

Por su parte, Aleix Pol, presidente de KDE e.V., ha celebrado la iniciativa destacando la oportunidad de fortalecer los cimientos del proyecto “para servir mejor a una sociedad que cada vez valora más sus derechos digitales”.

El Sovereign Tech Fund forma parte de la Sovereign Tech Agency, una organización pública impulsada por el Gobierno alemán con el objetivo de reforzar componentes críticos de software libre considerados estratégicos para la competitividad e innovación europeas.

La entrada KDE recibe más de un millón de euros del Sovereign Tech Fund es original de MuyLinux

Fedora tiene nuevo experimento entre manos y, a decir verdad, apunta maneras. El proyecto se llama Fedora Hummingbird y acaba de ser presentado en el Red Hat Summit 2026 como una nueva distribución rolling release basada en contenedores e imágenes, orientada a ofrecer software siempre actualizado, pero con un enfoque muy concreto: reducir al máximo la superficie de ataque y la gestión manual de vulnerabilidades.

Fedora Hummingbird nace como una extensión natural de Project Hummingbird, una iniciativa centrada en la creación de «imágenes de contenedores endurecidas, minimalistas y distroless«, esto es, sin gestor de paquetes, sin shell y solo con los componentes estrictamente necesarios para ejecutar una aplicación. El objetivo del proyecto es acercarse todo lo posible a cero informes CVE en las imágenes que distribuye, automatizando buena parte del proceso de detección, reconstrucción y despliegue de parches.

Según explican en Fedora Magazine, el proyecto lleva ya meses construyendo un catálogo de imágenes de este tipo para diferentes lenguajes y servicios, incluyendo Python, Go, Node.js, Rust, PostgreSQL, nginx o .NET, entre muchos otros. Todo ello sustentado sobre una infraestructura basada en Konflux, compilaciones reproducibles y herramientas propias como chunkah, diseñada para descargar únicamente las partes modificadas de una imagen durante las actualizaciones.

La novedad ahora es trasladar toda esa filosofía al propio sistema operativo. Así, Fedora Hummingbird se distribuye como una imagen OCI completa, construida y actualizada igual que cualquier contenedor, utilizando actualizaciones atómicas y rollback integrado. El sistema mantiene la raíz en modo de solo lectura, separando el contenido del sistema de los datos modificables alojados en /var y /etc.

Por debajo, Fedora Hummingbird utilizará el kernel ARK (Always Ready Kernel) del proyecto CKI, siguiendo muy de cerca el desarrollo principal del kernel Linux. La idea aquí es combinar una base extremadamente actualizada con un flujo de validación y pruebas continuas.

El proyecto se apoya además en buena parte del trabajo previo realizado alrededor de Fedora CoreOS y de la iniciativa de contenedores arrancables de Fedora, aunque con un enfoque distinto: mientras CoreOS se orienta a cargas orquestadas y entornos minimalistas, Hummingbird pretende facilitar a desarrolladores y administradores el despliegue simultáneo de diferentes versiones de runtimes y servicios.

Aunque Fedora Hummingbird ya arranca y puede probarse desde hoy mismo, sus responsables reconocen que todavía queda trabajo de integración por delante, especialmente en la convivencia entre paquetes construidos directamente por Hummingbird y los paquetes tradicionales de Fedora. Aun así, el proyecto ya se presenta abiertamente como un futuro candidato a integrarse de forma oficial dentro del ecosistema de la distribución comunitaria de Red Hat.

Para quienes quieran probarlo, la publicación original incluye instrucciones básicas para comenzar a utilizar Fedora Hummingbird en máquinas virtuales y otros datos de interés.

En otro orden de cosas, hace apenas un par de semanas que llegó Fedora 44, un lanzamiento repleto de noveades.

La entrada Fedora Hummingbird quiere llevar el modelo «distroless» al propio sistema operativo es original de MuyLinux

La Steam Machine 2 va a acarrear en su lanzamiento una importante limitación: el hecho de que el driver AMDGPU no puede soportar HDMI 2.1. Desde el punto de visto técnico esto afecta a todas las distribuciones Linux, pero es importante tener en cuenta que el dispositivo de Valve va orientado principalmente a ser conectado a televisores, donde HDMI es prácticamente un monopolio, mientras que en PC la interfaz recomendada suele ser DisplayPort, la cual es desarrollada por VESA y tecnológicamente va por delante de HDMI.

La razón de por qué AMDGPU no puede soportar HDMI 2.1 es el veto que le puso HDMI Forum, el consorcio japonés encargado de la especificación, a la implementación de dicha versión de su interfaz como código abierto. Esta limitación, curiosamente, no afecta a Nova, ya que el firmware GSP de NVIDIA es capaz de realizar funciones que por lo general realizan los drivers y además es privativo. El firmware utilizado para las gráficas de AMD no es capaz de realizar al menos en un principio funciones de un driver, a pesar de ser también privativo.

El veto de HDMI Forum se lo ha puesto difícil a AMD e Intel, así que ambas empresas están intentando incorporar características de HDMI 2.1 sin implementar la especificación per se. Esto es todo un desafío al consorcio japonés, pero hasta ahora parece que ambos gigantes del chip estadounidenses están dispuestos a seguir adelante. Sin embargo, aquí nos centraremos únicamente en lo que respecta a Radeon por la mencionada Steam Machine 2.

La primera característica de HDMI 2.1 que fue incluida en AMDGPU es Fixed Rate Link (FRL), una tecnología que permite alcanzar mayores velocidades de transmisión de datos. Esto es necesario para soportar correctamente resoluciones más altas, como por ejemplo 4K a 120 Hz, 8K a 60 Hz e incluso 10K. Además, es capaz de alcanzar anchos de banda de hasta 48 Gbps.

La otra característica implementada más recientemente es Display Stream Compression (DSC), que fue desarrollada por VESA e introducida oficialmente en HDMI 2.1. El propósito con DSC es transmitir a resoluciones ultra altas como 8K y 10K a tasas de refresco elevadas, de 120Hz o más, sin que en teoría haya una pérdida en la calidad de imagen perceptible por el ojo humano.

Un viejo televisor Samsung que funciona a resolución HD

En resumidas cuentas, los desarrolladores de AMDGPU están intentando que el driver sea capaz de soportar correctamente pantallas, más concretamente televisores si reducimos el tema a la Steam Machine 2, que manejan altas resoluciones y elevadas tasas de refresco mediante HDMI. La incorporación de estas características o equivalentes en DisplayPort no son un inconveniente, ya que VESA permite realizar reimplementaciones sin royalties ni exigencias de sus interfaces, a pesar de no ser realmente abiertas o de código abierto.

Veremos cómo acaba la implementación de las características de HDMI 2.1 en AMDGPU, sobre todo por el veto de HDMI Forum. Estas incorporaciones pueden terminar siendo muy importantes para la Steam Machine 2, si bien es necesario que el dispositivo que emite los gráficos, la gráfica Radeon RX 7600 en el caso del mini-PC de Valve, y el televisor o monitor soporten HDMI 2.1. Como curiosidad y siendo este otro detalle importante para los videojuegos, HDMI 2.1 es la primera versión de la interfaz que incorpora oficialmente la tasa de refresco variable (VRR).

Viendo que la Steam Machine 2 es más consola de videojuegos que PC, aunque técnicamente es puramente lo segundo, su principal desventaja en la no implementación de HDMI 2.1 no es frente a NVIDIA, sino a las consolas de videojuegos, sobre todo las futuras de sobremesa de décima generación. El hecho de que el software de PlayStation y Xbox sea privativo hace que lo tengan fácil para esquivar el veto de HDMI Forum y es más, hasta es posible que el consorcio japonés se implique en el desarrollo de esas futuras consolas de sobremesa.

El otro punto de vista en este asunto es que no todo el mundo tiene un televisor que soporta HDMI 2.1 y es más, este servidor usa en pleno 2026 un viejo televisor Samsung de los años 2006-2008 cuya resolución nativa es HD, 1.360×768 píxeles para ser exactos, así que en teoría no todo el mundo debería verse perjudicado por el veto a la implementación de HDMI 2.1 en AMDGPU.

Además de todo lo mencionado, un aspecto adicional a tener en cuenta es que el funcionamiento de HDMI a través de AMDGPU no va del todo fino, por lo que el usuario puede encontrarse con que el monitor no entra en suspensión tras apagar el ordenador, mostrando la pantalla un aviso de que no hay señal. El hecho de que HDMI no vaya del todo fino en AMDGPU hace que el uso de DisplayPort sea extremadamente recomendable, pero como ya hemos dicho, HDMI es un monopolio en los televisores, y se supone que la Steam Machine 2 irá conectada principalmente en televisores.

La entrada AMDGPU incorpora características de HDMI 2.1 de cara a la Steam Machine 2 es original de MuyLinux

Hace más de una década que Debian persigue este objetivo, pero los desarrolladores de la distribución lo han fijado para el lanzamiento de la próxima versión estable: a partir de Debian 14 «Forky», la reproducibilidad dejará de ser un objetivo para convertirse en un requisito.

El equipo de lanzamiento ha comunicado en la lista de correo que Debian debe —no que quieran hacerlo, sino que deben hacerlo— distribuir paquetes reproducibles, es decir, compilables a partir del mismo código fuente para obtener binarios idénticos, bit a bit, con independencia del momento o la máquina en que se realice el proceso.

Ciertamente, no es una declaración de intenciones: el software de migración de Debian ya bloquea, desde el pasado 9 de mayo, el paso a los paquetes nuevos que no sean reproducibles, así como a los existentes que empeoren en este aspecto. Debian 14 «Forky» será, por lo tanto, la primera versión mayor en exigirlo de forma vinculante.

El camino ha sido largo, pero a todo se llega. Desde 2015 existe la propuesta explícita de conseguir el pleno reproducible, lo que entonces se describía con aquello de «malo para la CIA, bueno para nosotros». La idea era —y sigue siendo— garantizar que cualquiera pueda verificar que un binario es exactamente lo que dice ser, que no ha sido alterado en el proceso de compilación.

Desde entonces, el avance ha sido gradual y constante: el hito más reciente que recogimos fue el de las imágenes en vivo de Debian Bookworm alcanzando la reproducibilidad total, hace apenas unos meses. Ahora el proyecto da el siguiente paso lógico, aunque seguramente el más difícil, como es extenderlo a todos sus paquetes.

En todo caso, «Forky» se encuentra a mitad de ciclo de desarrollo y no se espera que llegue a estable antes del verano de 2027, así que queda tiempo para que los mantenedores adapten los paquetes que todavía no cumplan con el requisito de marras.

En otro orden de cosas, los desarrolladores de Debian han aprovechado el comunicado para anunciar otra novedad: hace un par de semanas que LoongArch64 se incorporó oficialmente al archivo de Debian como nueva arquitectura soportada, uniéndose a las ya habituales: amd64, arm64, armhf, riscv64, ppc64el y s390x.

El soporte de LoongArch —la ISA de 64 bits desarrollada por Loongson, de origen chino— en el kernel de Linux lleva ya un tiempo madurando, por lo que no es una sorpresa, aunque sí una confirmación de que la arquitectura tiene recorrido suficiente como para ganarse un hueco en Debian.

La entrada Debian 14 «Forky» exigirá paquetes reproducibles y añade soporte de LoongArch64 es original de MuyLinux

Cuando Valve anunció la publicación oficial de Proton en el año 2018 a través de la característica Steam Play de Steam, sentó las bases de una revolución que se ha transformado en la que hoy es la vía más común para jugar desde Linux. Además, y gracias a que la capa de compatibilidad se basa en Wine, su código fuente acabó publicado, permitiendo así la existencia de bifurcaciones que en no pocos casos han resultado o son más recomendables que las compilaciones de Valve.

Aunque hay diversas bifurcaciones de Proton, hay dos que han sobresalido por encima del resto. La primera fue la más conocida de todas, Glorious Eggroll, que en tiempos pasados demostró ser más competente para la ejecución de muchos videojuegos triple A de última generación que las compilaciones de Valve. De entre los títulos que sobrevivieron en Linux principalmente gracias a Gloirous Eggroll, se puede destacar al remake de Resident Evil 2, que si bien fue lanzado en el año 2019, en 2021 todavía dependía de la mencionada bifurcación de Proton para poder funcionar a la perfección.

Tras unos años en los que las distintas ramas oficiales de Valve y la bifurcación Glorious Eggroll básicamente constituyeron la base para jugar en Linux, con permiso de los videojuegos que están compilados de manera nativa para el sistema, empezó a emerger otra bifurcación de Proton procedente de una de las derivadas de Arch Linux más populares: CachyOS. La bifurcación de CachyOS, que en realidad funciona sobre cualquier distribución, destacó frente a Glorious Eggroll principalmente por su mejor soporte para la ejecución nativa sobre Wayland, en lugar de apoyarse en XWayland.

El soporte nativo para Wayland del Proton de CachyOS no es algo propio del proyecto, sino que es básicamente una reimplementación del soporte para Wayland de Wine tomada de Proton-EM, otra bifurcación del Proton de Valve que se centra en lo que ya hemos comentado. Sin embargo, el hecho de que CachyOS sea una marca asentada y conocida entre los usuarios de Linux ha facilitado la difusión de su bifurcación de Proton frente a las procedentes de otros proyectos.

Otro detalle a tener en cuenta es que la bifurcación de Proton de CachyOS ha ido madurando con el paso del tiempo para ofrecer una mejor compatibilidad, reduciendo así en el frente en el que Glorious Eggroll le saca mayor ventaja. Esto y el soporte de Wayland han sido los dos principales motivos que han llevado al Proton de CachyOS a ser adoptado y usado de manera predeterminada por más de uno, aunque lo recomendable es tener distintas compiladores de diferentes proyectos que estén realmente vivos para así tener balas en la recámara. De hecho, y como caso personal, Deus Ex: Human Revolution me funciona mejor con Glorious Eggroll debido a que este Proton me presenta menos problemas de stuttering.

Pese a todo, la popularidad del Proton de CachyOS ha ido a más, así que vamos a aprovechar la ocasión para publicar un tutorial que permite obtener dicha capa de compatibilidad a través de un marco que requiera de poco mantenimiento por parte del usuario.

Cómo obtener el Proton de CachyOS para Steam y Heroic Games Launcher

Lo primero que hay que hacer es instalar la aplicación ProtonPlus, la cual está disponible en Flathub a través de un paquete verificado. Frente a ProtonUp-Qt, una herramienta similar al que se le ha dado más difusión en los medios, ProtonPlus destaca por facilitar la obtención de versiones latest de los Proton de Glorious Eggroll, CachyOS y EM, por lo que solo hay que abrir la propia aplicación para iniciar las actualizaciones de las capas de compatibilidad. Este proceder reduce y facilita el mantenimiento gracias a que lo automatiza al menos parcialmente, y en caso de que la última versión dé problemas con un juego específico, siempre se puede obtener la penúltima versión de manera específica y configurar el juego problemático para que la utilice.

ProtonPlus es una aplicación construida con GTK4 y con una interfaz bastante sencilla. Tras iniciar la herramienta, solo hay que seleccionar el cliente en la esquina superior izquierda, pulsar sobre la pestaña Tools y luego hacer clic sobre el botón correspondiente para iniciar la instalación de la versión latest del Proton de CachyOS u otra bifurcación. Aquí aparece la compilación dirigida a la versión 3 de x86 de 64-bit debido a que uso un Intel Core i5-12600K como procesador, pero sobre modelos más antiguos debería aparecer la compilación para la versión 1 de la arquitectura.

Pasos a seguir para instalar una versión Latest de Proton, Proton-ME en este caso, si bien los pasos son los mismos para la compilación de CachyOS.

Después, en el cliente de Steam y como de costumbre, hay que hacer el siguiente recorrido partiendo del menú principal: Steam > Parámetros > sección “Compatibilidad” > seleccionar “Proton-CachyOS Latest” en el desplegable de “Herramienta de compatibilidad predeterminada”. Tras realizar los pasos, la aplicación pedirá reiniciarse, cosa que hay que conceder para aplicar la configuración establecida.

Luego hay que hacer clic con el botón secundario del ratón sobre las “Propiedades” de un juego que está instalado y poner lo siguiente en “Parámetros de inicio” para forzar el uso de Wayland de manera nativa:

PROTON_ENABLE_WAYLAND=1 %command%

Mediante la sección “Compatibilidad” de las propiedades de un juego se puede seleccionar una compilación alternativa de Proton, aunque las ramas de Valve no proporcionan soporte nativo para Wayland o al menos las ramas estables no lo hacen.

En Heroic Games Launcher hay que dirigirse a Ajustes > Valores predeterminados del juego > Wine y seleccionar la “Versión de Wine” que será empleada de manera predeterminada por los juegos, donde hay que seleccionar “Proton-CachyOS Latest” en el desplegable. Luego, para tener el soporte nativo de Wayland, hay que marcar la opción “Activar Wine-Wayland (Experimental) (La versión de Wine debe ser compatible)”.

Otra opción es hacer el mismo proceso desde las propias preferencias de los juegos, si bien esta última vía sería mejor emplearla cuando se necesita emplear otra compilación de Proton, ya sea una concreta de la misma bifurcación o la latest de otra, como Glorious Eggroll.

Como ya hemos dicho, el usar la versión latest mediante ProtonPlus hace que, cada vez que se abra la aplicación, las compilaciones de Proton que haya instaladas se actualicen de manera automática, evitándose así el tener que poner esto al día cliente por cliente o, todavía peor, juego por juego.

Aunque el soporte nativo para Wayland de Wine está en fase experimental, al menos con gráficas Radeon está lo suficientemente maduro como para soportar videojuegos que funcionan a pantalla completa con una experiencia totalmente estable. De hecho, este servidor ha jugado ya cientos de horas de esta manera, habiéndose pasado títulos como el DmC de Ninja Theory, Art of Rally, Trepang2, Deus Ex: Human Revolution (de manera nativa en Wayland, pero con Glorious Eggroll), Weird West, Prey 2017, Cronos: The New Dawn y jugado durante más de cuarenta horas a Fallout: New Vegas, si bien perdí las partidas por un error mío.

Para terminar, lo bueno de jugar de manera nativa sobre Wayland es que se puede obtener una experiencia más fluida, se facilita el uso del HDR y abre la puerta a quitarse de un plumazo los inconvenientes de arrastrar XWayland. Otro detalle a tener en cuenta es, según se puede concluir de la comparativa más reciente entre GNOME y KDE Plasma realizada por Phoronix, que el primero parece estar centrándose en la ejecución de las aplicaciones de manera nativa en Wayland, mientras que el segundo está cuidando mejor su soporte de XWayland. Esto da como resultado que sería conveniente forzar el uso nativo de Wayland mediante Proton en caso de usar GNOME como escritorio.

La entrada Cómo configurar el Proton de CachyOS para jugar de manera nativa en Wayland es original de MuyLinux

ONLYOFFICE Docs es la pieza que permite llevar los editores en línea de ONLYOFFICE a un servidor propio e integrarlos con plataformas como Nextcloud, ownCloud, Moodle, Odoo, Seafile y otros servicios de almacenamiento o colaboración. En otras palabras, no hablamos de la suite ofimática en la nube, sino de desplegar el servidor de documentos con el que editar textos, hojas de cálculo, presentaciones, PDF y formularios PDF desde el navegador, a través de uno de estos medios.

En este tutorial vamos a instalar ONLYOFFICE Docs Community Edition mediante Docker, ya que es el método más práctico cuando se busca un despliegue reproducible, fácil de actualizar y válido para cualquier distribución Linux capaz de ejecutar Docker. El ejemplo concreto, no obstante, lo haremos sobre Ubuntu 26.04 LTS, de reciente lanzamiento y una base muy habitual en servidores, que además Docker contempla oficialmente entre las versiones soportadas.

Antes de seguir, un matiz importante: este tutorial cubre la instalación de ONLYOFFICE Docs como servicio independiente. La integración posterior con Nextcloud, ownCloud u otra plataforma dependerá del conector correspondiente, pero la base será siempre la misma: tener un servidor de ONLYOFFICE Docs accesible por HTTP o, mucho mejor, por HTTPS.

Dicho lo cual, ONLYOFFICE dispone también de una plataforma propia llamada ONLYOFFICE DocSpace, pensada para quienes buscan directamente una suite colaborativa online completa, con gestión de usuarios, salas, almacenamiento y los editores ya integrados, sin necesidad de recurrir a servicios externos. DocSpace se puede desplegar igualmente con Docker, pero requiere un enfoque diferente y merece su propio tutorial.

Requisitos previos

Aunque la documentación oficial de ONLYOFFICE está un poco desactualizada, fija unos requisitos razonables para la edición Docker que se mantienen: procesador de doble núcleo a 2 GHz o superior, 4 GB de RAM como mínimo, 40 GB de espacio libre, al menos 4 GB de swap y una distribución Linux amd64 con kernel 3.10 o superior. A eso hay que añadir una versión de Docker todavía soportada por el propio proyecto.

En la práctica, conviene preparar lo siguiente:

• Un servidor Linux actualizado, físico, virtual o VPS.
• Acceso con privilegios de administrador.
• Un dominio o subdominio apuntando al servidor si se va a usar HTTPS con Let’s Encrypt.
• Los puertos 80 y 443 libres, o bien un puerto alternativo si el servidor ya tiene un proxy inverso o una web en funcionamiento.
• Una plataforma con la que integrar ONLYOFFICE Docs, salvo que solo se quiera dejar el servicio preparado.

El método es válido para cualquier distribución con Docker, pero la instalación de Docker cambia según el sistema. En Debian, Fedora, RHEL, openSUSE, Arch y compañía habrá que seguir las instrucciones oficiales correspondientes. Lo que cambia es esa parte; el contenedor de ONLYOFFICE Docs se ejecuta igual.

1. Actualizar Ubuntu 26.04 LTS

Comenzamos con lo básico. En Ubuntu 26.04 LTS, actualiza el sistema antes de instalar Docker:

sudo apt update
sudo apt upgrade

Si el sistema recibe una actualización de kernel, reinicia antes de continuar:

sudo reboot

2. Instalar Docker en Ubuntu 26.04 LTS

Docker recomienda instalar Docker Engine desde su repositorio oficial. Antes, elimina posibles paquetes conflictivos que pueda proporcionar la distribución:

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc | cut -f1)

No pasa nada si apt indica que no hay nada que eliminar. Después, añade la clave y el repositorio oficial de Docker:

sudo apt update
sudo apt install ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

Instala ahora Docker Engine y sus componentes principales, incluyendo el plugin de Docker Compose:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Comprueba que el servicio está activo:

sudo systemctl status docker --no-pager

Y verifica la instalación con la imagen de prueba:

sudo docker run hello-world

A partir de aquí usaremos sudo para ejecutar Docker, que es la opción más directa en un servidor. Se puede configurar Docker para ejecutarlo sin sudo, pero conviene recordar que el grupo docker concede privilegios equivalentes a root, así que no es una decisión menor.

3. Crear un secreto JWT

ONLYOFFICE Docs utiliza JWT para validar las solicitudes que recibe. Desde la versión 7.2, si no se define un secreto propio, este se regenera en cada reinicio de la máquina o del servidor físico, lo que puede romper integraciones. Por eso hay que fijarlo desde el primer momento.

Genera un secreto aleatorio y guárdalo en un archivo de entorno:

JWT_SECRET=$(cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)

sudo install -m 600 /dev/null /etc/onlyoffice-docs.env

echo "JWT_SECRET=${JWT_SECRET}" | sudo tee /etc/onlyoffice-docs.env > /dev/null

Guarda ese valor también en tu gestor de contraseñas o en la documentación privada del servidor. Lo necesitarás al conectar ONLYOFFICE Docs con la plataforma que vayas a usar.

4. Lanzar ONLYOFFICE Docs con Docker

La instalación básica se puede hacer con un solo comando, pero es recomendable montar los directorios persistentes en el servidor. Así se conservan datos, configuración, logs y base de datos interna cuando actualices el contenedor.

Ejecuta:

sudo docker run -i -t -d \
  --name onlyoffice-docs \
  --restart=always \
  --env-file /etc/onlyoffice-docs.env \
  -p 80:80 \
  -v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice \
  -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data \
  -v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice \
  -v /app/onlyoffice/DocumentServer/db:/var/lib/postgresql \
  onlyoffice/documentserver:latest

Con esto, Docker descargará la imagen onlyoffice/documentserver:latest y arrancará el servicio en el puerto 80 del servidor. La opción --restart=always hace que el contenedor vuelva a levantarse automáticamente tras un reinicio, mientras que --name onlyoffice-docs facilita su administración posterior.

Si el puerto 80 ya está ocupado, puedes publicar ONLYOFFICE Docs en otro puerto. Por ejemplo:

sudo docker run -i -t -d \
  --name onlyoffice-docs \
  --restart=always \
  --env-file /etc/onlyoffice-docs.env \
  -p 8080:80 \
  -v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice \
  -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data \
  -v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice \
  -v /app/onlyoffice/DocumentServer/db:/var/lib/postgresql \
  onlyoffice/documentserver:latest

En ese caso, el servicio quedará accesible mediante http://IP_DEL_SERVIDOR:8080 o a través del proxy inverso que configures delante.

5. Abrir los puertos necesarios

Si usas UFW en Ubuntu y quieres exponer el servicio directamente, abre HTTP:

sudo ufw allow 80/tcp

Si vas a activar HTTPS, abre también 443:

sudo ufw allow 443/tcp

Comprueba el estado del cortafuegos:

sudo ufw status

Este paso depende de la configuración de cada servidor. En un VPS, además del firewall local, puede haber reglas de red en el panel del proveedor.

6. Comprobar que ONLYOFFICE Docs funciona

Lista los contenedores activos:

sudo docker ps

Consulta los últimos mensajes del contenedor:

sudo docker logs --tail=50 onlyoffice-docs

Y prueba el acceso desde el propio servidor:

curl -I http://localhost

Después abre en el navegador la dirección del servidor. Si estás usando el puerto predeterminado:

http://IP_DEL_SERVIDOR

Si has usado un puerto alternativo:

http://IP_DEL_SERVIDOR:8080

La página inicial de ONLYOFFICE Docs no sustituye a una plataforma de almacenamiento o colaboración. Sirve para comprobar que el servicio responde. Para trabajar con documentos tendrás que conectarlo con Nextcloud, ownCloud, Moodle, Odoo, Seafile u otra solución compatible, indicando la URL del servidor de documentos y el secreto JWT que has creado.

7. Activar HTTPS con Let’s Encrypt

Para un despliegue real, HTTPS no es opcional. ONLYOFFICE Docs se puede ejecutar directamente en HTTPS y la documentación contempla el uso de Let’s Encrypt mediante variables de entorno.

Si ya has creado el contenedor anterior, deténlo y elimínalo antes de recrearlo con HTTPS. No perderás los datos si mantienes los mismos volúmenes:

sudo docker stop onlyoffice-docs
sudo docker rm onlyoffice-docs

Ahora lanza de nuevo el contenedor, sustituyendo docs.tudominio.com y admin@tudominio.com por tus datos reales:

sudo docker run -i -t -d \
  --name onlyoffice-docs \
  --restart=always \
  --env-file /etc/onlyoffice-docs.env \
  -p 80:80 \
  -p 443:443 \
  -e LETS_ENCRYPT_DOMAIN=docs.tudominio.com \
  -e LETS_ENCRYPT_MAIL=admin@tudominio.com \
  -v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice \
  -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data \
  -v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice \
  -v /app/onlyoffice/DocumentServer/db:/var/lib/postgresql \
  onlyoffice/documentserver:latest

El dominio debe apuntar correctamente al servidor y los puertos 80 y 443 tienen que estar accesibles desde Internet. Si tienes un proxy inverso delante, lo más limpio suele ser terminar TLS en el proxy y publicar el contenedor en un puerto interno, pero esa configuración ya depende de Nginx, Apache, Traefik, Caddy o la solución que utilices.

8. Conectar ONLYOFFICE Docs con tu plataforma

El último paso no se hace en Docker, sino en la aplicación con la que vayas a usar ONLYOFFICE Docs. Por ejemplo, en Nextcloud u ownCloud tendrás que instalar el conector correspondiente, indicar la dirección pública del servidor de documentos y añadir el secreto JWT.

La URL será algo como:

https://docs.tudominio.com

En el caso de ONLYOFFICE DocSpace, la integración con ONLYOFFICE Docs ya viene preparada de serie, por lo que no hace falta configurar conectores externos como sucede con Nextcloud u ownCloud. Aun así, el servidor de documentos sigue siendo la base tecnológica sobre la que se apoyan los editores online.

Si no has configurado HTTPS y estás haciendo solo una prueba local, podría ser:

http://IP_DEL_SERVIDOR

Pero para producción, insistimos: usa HTTPS, dominio propio y un secreto JWT fijo.

9. Actualizar ONLYOFFICE Docs

La ventaja de Docker es que actualizar resulta relativamente sencillo, pero no conviene hacerlo de cualquier manera. La documentación oficial recomienda crear una copia de seguridad de los volúmenes antes de actualizar y preparar el apagado del servicio para evitar pérdida de datos, ya que ONLYOFFICE Docs guarda los documentos cuando todos los usuarios que los estaban editando los han cerrado.

Crea una copia de seguridad:

sudo tar -czf onlyoffice-docs-backup-$(date +%Y%m%d).tar.gz \
  /app/onlyoffice/DocumentServer/data \
  /app/onlyoffice/DocumentServer/lib \
  /app/onlyoffice/DocumentServer/db

Prepara el apagado:

sudo docker exec onlyoffice-docs documentserver-prepare4shutdown.sh

Detén el contenedor y conserva el antiguo hasta comprobar que todo funciona:

sudo docker stop onlyoffice-docs
sudo docker rename onlyoffice-docs onlyoffice-docs-old-$(date +%Y%m%d)

Descarga la imagen nueva:

sudo docker pull onlyoffice/documentserver:latest

Y vuelve a lanzar el contenedor con los mismos volúmenes, puertos y secreto JWT. Cuando compruebes que todo funciona, podrás eliminar el contenedor antiguo.

10. Alternativa: Docker Compose

ONLYOFFICE mantiene también una vía de instalación con Docker Compose basada en el repositorio Docker-DocumentServer. Es útil si prefieres gestionar el despliegue con un archivo de composición en lugar de un comando largo.

En Ubuntu 26.04 LTS, si has seguido los pasos anteriores, ya tienes instalado el plugin moderno de Docker Compose. Clona el repositorio oficial:

git clone https://github.com/ONLYOFFICE/Docker-DocumentServer
cd Docker-DocumentServer

Arranca el servicio:

sudo docker compose up -d

Y para detenerlo:

sudo docker compose down

La documentación de ONLYOFFICE todavía muestra el comando clásico docker-compose. En instalaciones actuales de Docker, lo habitual es usar docker compose, sin guion, porque Compose se instala como plugin de Docker. Si tu distribución mantiene el binario antiguo, el comando heredado seguirá funcionando.

Conclusión

Instalar ONLYOFFICE Docs con Docker no tiene demasiado misterio, y esa es precisamente una de sus ventajas: una vez Docker está funcionando, el despliegue es prácticamente el mismo en cualquier distribución Linux. Ubuntu 26.04 LTS aporta aquí una base cómoda y oficialmente soportada por Docker, pero no es un requisito imprescindible.

Lo importante es cuidar tres puntos: usar una versión soportada de Docker, fijar desde el principio el secreto JWT y montar los volúmenes persistentes para poder actualizar sin sobresaltos. A partir de ahí, queda lo más interesante: integrar ONLYOFFICE Docs con la plataforma que ya uses y llevar la edición colaborativa de documentos a tu propio servidor.

La entrada ONLYOFFICE Docs en tu propio servidor: instalación con Docker paso a paso es original de MuyLinux

Mesa 26.1 ha sido lanzada como la nueva versión de la pila gráfica encargada de proporcionar los controladores que operan en el espacio del usuario. Dicho de manera más llana, básicamente proporciona los soportes de OpenGL, Vulkan y OpenCL, si bien hay controladores más exóticos como Zink que se encargan de renderizar (traducir) OpenGL sobre Vulkan. Sin más dilación, vamos a mencionar los aspectos más importantes.

Intel es, aparentemente, la marca de hardware que mejor parada ha salido del lanzamiento de Mesa 26.1, ya que todos sus drivers actuales: Iris, Crocus y ANV, han incorporado soporte para el controlador de contexto nativo de VirtIO-GPU, lo que permite una paravirtualización de las GPU Intel más ligera y rápida en una máquina virtual. Para los que anden perdidos, ANV es el controlador de Vulkan para el hardware de la marca mencionada, Iris es el driver moderno de OpenGL que funciona en los modelos de GPU más recientes y Crocus es un desarrollo relativamente joven que pretende mejorar el soporte de OpenGL en las generaciones 4, 5, 6 y 7 de Intel Core.

Continuando con cosas relacionadas con la virtualización, el controlador VirGL, que se encarga de suministrar soporte de aceleración 3D por GPU virtual para los invitados de QEMU, ha dejado de estar considerado como mantenido. Los responsables de Mesa explican que, “a menos que alguien se haga cargo de su mantenimiento a largo plazo, es probable que el código se deteriore y termine siendo eliminado”, así que recomiendan migrar a otras soluciones cuanto antes.

Otra novedad destacada es el hecho de que la biblioteca estática de C++ stdlib es a partir de Mesa 26.1 requerida por Rusticl, el controlador de OpenCL basado en Rust, como solución para las aplicaciones que utilizan su propia implementación de stdlib. Por otro lado, OpenGL ES 2.0 es desde este lanzamiento compatible con las gráficas PowerVR a través del Zink, un driver que actúa como un renderizador o traductor de OpenGL sobre Vulkan.

De entre las muchas extensiones de Vulkan incluidas en Mesa 26.1, sobresale VK_EXT_present_timing, que está presente en RADV (AMD Radeon), NVK (NVIDIA a través de Nouveau y Nova), Turnip (Vulkan para Adreno), ANV, Honeykrisp (Vulkan para Apple Silicon) y panvk (Vulkan para Mali en las microarquitecturas Midgard y Bifrost). VK_EXT_present_timing proporciona en teoría una reducción de las latencias y una mayor consistencia en la sincronización de fotogramas (frame timing), por lo que la experiencia con ciertos videojuegos que presentan problemas con la sucesión de fotogramas debería verse mejorada.

Además de todo lo mencionado, en Mesa 26.1 se han corregido, entre otros, los siguientes problemas: una de gestión de la memoria con AMDGPU que fue detectada en Mesa 25.3, la corrupción de la iluminación en Shekiro cuando se usa una gráfica RX 7900 XT, una violación de acceso (segfault) en gm200_validate_sample_locations cuando se usa Firefox sobre una GTX 1070 Ti y Nouveau, la ausencia de iluminación en la fase The Hollow en el videojuego The End is Nigh ejecutado sobre Wine, parpadeos de la hierba y sombras erróneas cuando se ejecuta Genshin Impact sobre ANV, el cuelgue de Left 4 Dead 2 cuando el usuario inicia o intenta unirse a una supervivencia en servidores “Official Dedicated” y fallos con el trazado de rayos en Elden Ring.

Como aspectos superficiales, los responsables han destacado que Mesa “incluye implementaciones de Vulkan 1.4, OpenGL 4.6, OpenGL ES 3.2, OpenCL 3.0 y más API”, por lo que en este frente se puede decir que es una pila que está bastante actualizada. Pero más allá de las características técnicas específicas que están escritas, lo más importante es la enorme evolución que ha experimentado desde la aparición de AMDGPU, controlador del kernel Linux que ha motivado el llevar la pila gráfica estándar del sistema mucho más allá, permitiendo la ejecución de videojuegos triple A compilados para Windows con unos resultados muy buenos, incluso superando al sistema de Microsoft en no pocas ocasiones.

Y estos son los aspectos más destacados de Mesa 26.1, del que se pueden conocer todos sus detalles a través de las notas de lanzamiento. Si se quiere obtener la pila sin tener que pasar por el tortuoso proceso de compilación, lo suyo es esperar a que llegue a modo de actualización a través de Flathub o los repositorios de una distribución bleeding edge, mientras que los usuarios de Ubuntu y derivadas tienen a su disposición los PPA fresh y stable de Kisak.

La entrada Mesa 26.1 mejora la experiencia con la virtualización en Intel y los videojuegos en general es original de MuyLinux

La Open Source Initiative (OSI) y OpenLogic han publicado la edición de 2026 de su informe sobre el estado del código abierto, el cual se basa en más de 700 respuestas obtenidas de una encuesta realizada a líderes de tecnologías de la información (TI) que trabajan para organizaciones de todo tipo a nivel global. Adelantamos que la mayoría de los principales hallazgos que derivan del informe suenan a estas alturas a perogrullada, ya que a grandes rasgos se repiten cosas que se han dicho muchas veces.

El primer hallazgo clave es la adopción de software de código abierto para evitar los bloqueos de los vendedores, siendo esto una respuesta dada por el 55% de los participantes de la encuesta. Este porcentaje supone un aumento del 68% en comparación con el año anterior, pero posiblemente lo más interesante es que el 63% de los participantes de la Unión Europea y el Reino Unido dijeron esta respuesta frente al 51% de los norteamericanos. Esta disparidad puede derivarse de la convulsa situación política que vive el mundo y el hecho de que la mayoría de las grandes corporaciones que dominan el mercado de la computación en occidente son estadounidenses, lo que ha motivado a ciertos países europeos a poner cierta distancia de estas.

El segundo hallazgo más relevante que se desprende del informe es el hecho de que, entre las empresas que tienen 5.000 empleados o más, el 60% de los encuestados han respondido que invierten como mínimo la mitad del tiempo en mantenimiento, problemas de producción y corrección de errores en lugar del desarrollo de características. Esta situación es más pronunciada en tecnologías como Java, de la que el 31% de los equipos TI solo emplean entre el 10 y 25 por ciento del tiempo al desarrollo de nuevas características. Esto, según explica el informe, “afecta directamente a los plazos de entrega, la moral de los desarrolladores y la capacidad de innovación a largo plazo”.

Tiempo dedicado al mantenimiento y al desarrollo de nuevas características

Otro detalle destacado del segundo hallazgo es que “la falta de experiencia interna en software de código abierto es un problema común que puede llevar a que las empresas tengan problemas de implementación y/o aplicaciones” que el personal empleado no es capaz de solucionar. Aquí se menciona como ejemplo la acelerada cadencia de lanzamientos de JDK, que exige llevar a cabo procesos de actualización más frecuentes. Como consecuencia, los equipos tienden a quedarse en rutinas de actualización que les deja poco tiempo para el desarrollo de nuevas características.

El tercer gran hallazgo es que las actualizaciones de seguridad y los procesos de parcheo siguen siendo un reto persistente a pesar de la madurez que ha alcanzado la adopción del software de código abierto. Además, esto afecta a organizaciones de todos los tamaños, con un 20% de estas que informan no tener un proceso específico para responder ante los CVE, un 39% de las grandes empresas que reconocen tener dificultades para cumplir sus acuerdos de nivel de servicio (SLA o ANS) internos para la corrección de vulnerabilidades, además de que el 55% de las organizaciones que no aprobaron el año pasado una auditoría de cumplimento emplea software de código abierto que ha llegado a su fin de ciclo, lo que supone no recibir actualizaciones de seguridad.

El informe sugiere que el éxito de la adopción del código abierto a escala depende más de cómo se gobierna y sostiene este que las propias tecnologías que se adoptan. Por otro lado, para los líderes TI surgen diversas preguntas en torno a los procesos para mantener el software de código abierto en producción en el largo plazo, si sus flujos de trabajo en torno a la seguridad y las vulnerabilidades están alineados con la escala de su huella con el código abierto, si es más conveniente mejorar las habilidades del personal propio o contratar a un tercero para el mantenimiento y la operatividad del código abierto, además del cómo encaja el código abierto en una estrategia más amplia en torno al riesgo de los proveedores, el cumplimiento y la autonomía digital.

Principales desafíos que acarrea el software de código abierto

Otro dato importante es que menos del 2% de las organizaciones reportaron una disminución en el uso de software de código abierto en comparación con el año pasado, frente al 98% que mantuvo su nivel o lo incrementó. Los principales desafíos son descubrir mejores maneras de respaldarlo, asegurarlo y sostenerlo a nivel empresarial sin sacrificar la innovación, la resiliencia y el control, siendo lo primero algo que aparentemente se está sacrificando en favor reforzar el mantenimiento, posiblemente debido a un desarrollo acelerado que dificulta a los equipos de TI mantener el ritmo.

El informe de la OSI y OpenLogic, a grandes rasgos, no señala cosas novedosas viendo la trayectoria del software de código abierto en la última década y media, con la salvedad de unos equipos de TI a los que parece les está costando seguir el ritmo de desarrollo de ciertos componentes, lo que les obliga a invertir más tiempo en el mantenimiento a costa del desarrollo de características.

Veremos qué ocurre en el futuro, sobre todo por el hecho de que la inteligencia artificial nos ha llevado a un escenario convulso que promete la consolidación de grandes cambios en el sector del software a todos los niveles. El informe completo puede ser obtenido en la página web que le ha dedicado OpenLogic, mientras que la OSI ha publicado un resumen de este.

La entrada La OSI y OpenLogic publican su informe sobre el código abierto para 2026 es original de MuyLinux