Jugar a EA Sports FC, Battlefield o Need for Speed está más cerca de Linux que nunca gracias a un cambio histórico en su kernel
Linux está más cerca de ser una plataforma gaming completa gracias a las múltiples mejoras en su kernel que amplían la compatibilidad con tecnologías de grandes compañías.
Durante años, jugar en Linux ha sido una de esas promesas que siempre parecía estar a punto de cumplirse, pero que seguía teniendo algunos obstáculos importantes.
El sistema operativo ofrecía muchas ventajas para los usuarios de PC, pero cuando llegaba el momento de ejecutar determinados juegos, especialmente aquellos vinculados a grandes compañías, aparecían problemas de compatibilidad difíciles de solucionar.
La situación ha cambiado mucho en los últimos años gracias a proyectos como Proton, la capa de compatibilidad desarrollada por Valve, que ha permitido que miles de juegos creados para Windows funcionen en Linux.
Sin embargo, todavía existían barreras técnicas en la base del sistema operativo que complicaban la portabilidad de las herramientas. Pero ahora, Linux está dando un paso importante con un cambio dentro de su propio kernel.
Pero la noticia no es que Electronic Arts haya añadido soporte para Linux ni que juegos como EA Sports FC, Battlefield o Need for Speed vayan a funcionar de repente en este sistema.
La realidad es más compleja, ya que la mejora afecta a la forma en la que Linux carga y gestiona determinados programas, beneficiando indirectamente a la infraestructura que hace posible jugar en la plataforma.
El verdadero cambio está en cómo Linux carga los programas
Para entender la importancia de esta modificación, hay que mirar una parte del sistema que normalmente pasa desapercibida, que es el cargador de programas. Cuando un usuario abre una app nativa en Linux, el kernel no ejecuta simplemente el archivo y ya está.
Antes necesita saber qué componentes debe utilizar para poner ese programa en funcionamiento, especialmente cuando hablamos de aplicaciones que dependen de librerías externas.
Para ello, los ejecutables de Linux utilizan un formato llamado ELF, que contiene información sobre cómo debe iniciarse el programa.
Dentro de ese sistema existe una sección conocida como PT_INTERP, donde se indica la ubicación del intérprete dinámico, una pieza fundamental que permite cargar las librerías necesarias para que una aplicación funcione.
El problema es que, tradicionalmente, esa ruta debe ser absoluta. Es decir, el sistema espera encontrar el intérprete en una ubicación exacta y rígida del disco. Aquí es donde entra en juego $ORIGIN.
Qué es $ORIGIN y por qué es importante
Cabe señalar que $ORIGIN es una referencia que permite decirle al sistema: “Busca este archivo tomando como punto de partida la ubicación del propio programa”. En lugar de depender de una ruta fija, un programa puede saber dónde está instalado y encontrar sus componentes desde ahí.
Esto parece un detalle pequeño, pero es una revolución para sistemas que buscan crear programas más fáciles de mover entre diferentes ubicaciones sin romper sus dependencias, como ocurre con NixOS, una distribución Linux conocida por su gestión avanzada e inmutable de paquetes.
Hasta ahora, el kernel de Linux no permitía utilizar esta idea relativa de forma nativa en puntos críticos como el intérprete (PT_INTERP). El nuevo trabajo en el kernel busca solucionar precisamente esa limitación histórica.
La solución propuesta por los desarrolladores no consiste simplemente en añadir una regla rígida dentro del código del kernel. En su lugar, abre la puerta a utilizar de forma combinada dos tecnologías potentísimas: eBPF y binfmt_misc.
binfmt_misc es el sistema clásico que permite a Linux reconocer formatos de archivos ajenos y decidir qué herramienta debe encargarse de ejecutarlos (como cuando ejecutas un archivo de Windows y el sistema sabe que debe llamar a Wine).
Por su parte, eBPF permite inyectar y ejecutar pequeños programas ultraseguros dentro del propio núcleo del sistema operativo en tiempo de ejecución.
Gracias a una nueva actualización en esta arquitectura (que introduce la bandera de ejecución L), un script de eBPF podrá interceptar el arranque de un binario y sustituir el intérprete dinámico de forma inteligente y transparente.
Al final, el kernel gana, por primera vez, una forma dinámica y flexible de decidir cómo arrancar ciertos programas sin alterar la identidad del proceso.
¿Qué tiene que ver esto con EA y sus videojuegos?
Aquí está la clave, ya que la relación con los juegos de Electronic Arts es indirecta, porque este cambio no modifica una sola línea de código de Battlefield o EA Sports FC y tampoco convierte sus versiones de Windows en juegos nativos para Linux.
Lo que ocurre es que, al mejorar la forma en la que Linux gestiona ejecutables, rutas y componentes externos, los desarrolladores de las capas de compatibilidad y los entornos de ejecución encapsulados (como Steam Runtime de Valve o los entornos de desarrollo planos) tienen herramientas mucho más limpias para mover, aislar y empaquetar software complejo.
Esto significa que cualquier mejora estructural en los cimientos del sistema elimina pequeños obstáculos y errores ocultos de memoria que antes entorpecían la experiencia general de juego.
Por eso se habla de que Linux está “más cerca” de una compatibilidad total, no porque EA haya dado un paso directo, sino porque el propio sistema operativo está madurando su arquitectura interna.
La importancia de esta modificación está en una parte del sistema que normalmente nadie ve. Linux lleva años conquistando el terreno gaming gracias al éxito de la Steam Deck, Proton y el trabajo incansable de la comunidad, pero detrás de esa evolución hay debates de ingeniería profunda en las listas de correo del kernel.
Cabe señalar que este cambio técnico es otro paso fundamental para que el sistema del pingüino sea arquitectónicamente superior, más flexible y libre de las cadenas de las rutas absolutas.