Recientemente estuvo circulando por foros underground la noticia de como Wine 11 había llevado el rendimiento del juego Dirt 3, de 110,6 FPS a 860,7 FPS, aunque el dato en realidad es de 2023, y proviene de una serie de benchmarks del trabajo experimental sobre NTSYNC presentado por Elizabeth Figura, desarrolladora de CodeWeavers.
A comienzos de 2026, cuando Wine 11.0 incorporó oficialmente NTSYNC, aquellos números volvieron a circular y adquirieron una interpretación irresistible: Linux acababa de multiplicar por casi ocho el rendimiento de un juego de Windows.
Con el creciente interés por linux dentro del público general y aficionados a los juegos de video, esta semana vamos a hablar de Wine.
Primero hay que entender que Windows utiliza objetos de sincronización —mutexes, eventos, semáforos— para coordinar los distintos hilos de ejecución de un programa. Durante años, Wine tuvo que reproducir parte de ese comportamiento mediante mecanismos que podían terminar generando demasiada comunicación con wineserver. En determinados programas intensamente multihilo, particularmente algunos videojuegos, esa coordinación podía convertirse en un cuello de botella considerable.
NTSYNC lleva al kernel Linux primitivas diseñadas específicamente para reproducir esas semánticas de Windows NT con mayor eficiencia. La propia documentación del kernel explica que existe porque las implementaciones anteriores en espacio de usuario no podían combinar simultáneamente el rendimiento de Windows con una reproducción suficientemente precisa de su comportamiento.
No es una nueva GPU. No es otro motor gráfico. Es algo probablemente más interesante: la consecuencia de haber comprendido cada vez mejor un sistema que Wine lleva más de treinta años intentando comprender. Ahí los 860 FPS comienzan a contar otra historia.
Treinta y tres años aprendiendo a hablar con Windows
Wine comenzó en 1993, originalmente como una forma de ejecutar programas de Windows 3.1 sobre Linux. Su primera versión estable 1.0 no llegó hasta 2008, después de quince años de desarrollo.
La escala temporal importa.
En informática estamos acostumbrados a pensar el progreso mediante generaciones: Windows 10 sucede a Windows 8; un procesador reemplaza al anterior; una API sustituye otra; una aplicación cambia de versión y eventualmente deja de soportar aquello que vino antes. La presentación comercial de la tecnología necesita que imaginemos una flecha que siempre apunta hacia delante.
Wine se parece menos a una flecha y más a una biblioteca.
Cada vez que algún desarrollador descubre cómo espera Windows que se comporte una función, corrige una incompatibilidad, implementa una API, reproduce una peculiaridad no documentada o consigue que una aplicación que fallaba pueda ejecutarse, una pequeña porción de conocimiento queda incorporada al proyecto.
Wine 11.0 representa aproximadamente 6.300 cambios individuales y más de 600 correcciones de errores en apenas un año de desarrollo. NTSYNC y la finalización de la nueva arquitectura WoW64 fueron los dos grandes hitos que WineHQ eligió destacar en su lanzamiento de enero de 2026.
Pero la cifra verdaderamente difícil de medir son los treinta y tres años anteriores.
Pruebas que fallaron. Soluciones sustituidas. Documentación. Decisiones de arquitectura. Bugs que alguien encontró en un programa oscuro hace quince años. Comportamientos de Windows que otro desarrollador tuvo que estudiar. Código escrito por personas que posiblemente hace mucho dejaron el proyecto y que continúa haciendo algo útil cada vez que alguien ejecuta hoy una aplicación.
Eso es conocimiento acumulativo y el software posee una propiedad extraordinaria: puede copiarse y reproducirse sin que se consuma.
Una cosa extraña sucede cuando compartimos código
Gran parte de nuestras intuiciones sobre el valor provienen de un mundo material.
Si tengo una manzana y te la doy, tú ganas una manzana y yo pierdo una.
Si poseo un terreno y permito que otra persona lo ocupe, ya no puedo utilizar simultáneamente exactamente el mismo espacio.
Si utilizamos cobre para fabricar un cable, ese cobre no estará disponible para fabricar otra cosa.
La economía denomina a estos bienes rivales: mi consumo interfiere con el tuyo.
La información funciona de manera diferente.
Yochai Benkler parte precisamente de esta anomalía en The Wealth of Networks. Una vez producido cierto conocimiento, que otra persona lo utilice no reduce la cantidad disponible para los demás. La información es un bien no rival: una idea no tiene que volver a producirse desde cero para cada persona que la recibe.
El software hace esta diferencia extraordinariamente visible.
Si escribo un programa y te entrego una copia, sigo conservando el programa.
Si cien mil personas lo descargan, no termino poseyendo una cienmilésima parte.
Si una de esas personas descubre un error, lo corrige y devuelve la modificación al proyecto, puede ocurrir algo todavía más extraño desde nuestras intuiciones materiales:
todos terminamos teniendo más de lo que teníamos antes de compartirlo.
Esto no convierte al software en una sustancia mágica libre de escasez. El computador que lo ejecuta necesita silicio, minerales y electricidad. Los servidores cuestan dinero. Los desarrolladores necesitan vivir. Mantener código requiere tiempo. Documentar, auditar, probar y corregir software son trabajos perfectamente materiales.
La copia puede acercarse a un costo marginal insignificante. La creación no.
Esta diferencia resulta fundamental porque evita una conclusión demasiado fácil: que, dado que el código puede copiarse, todo software debería necesariamente ser gratuito.
El problema interesante es otro.
¿Por qué tendríamos que organizar un bien no rival exactamente como organizamos los bienes que sí se agotan cuando los compartimos?
La buena voluntad no significa trabajar gratis
Aquí Immanuel Kant puede ayudarnos, siempre que no intentemos convertirlo retrospectivamente en defensor del código abierto.
Al comienzo de la Fundamentación de la metafísica de las costumbres, Kant atribuye un lugar excepcional a la buena voluntad. No está hablando simplemente de alguien bienintencionado ni de una persona que hace favores. Lo que le interesa es una voluntad determinada por principios que reconoce moralmente, cuyo valor no depende exclusivamente del beneficio conseguido o del resultado producido.
Sería ingenuo concluir a partir de ahí que Wine existe porque miles de programadores kantianos decidieron regalar su trabajo al mundo.
La historia real es más compleja y, precisamente por ello, más fértil.
Wine contiene contribuciones voluntarias, pero una porción considerable de su desarrollo también procede de personas que cobran por programarlo. CodeWeavers construye desde hace años un negocio alrededor de CrossOver, una solución comercial basada en Wine. La compañía afirma que desarrolla directamente contra el proyecto upstream y que envía primero allí su trabajo; la mayor parte del desarrollo de CrossOver termina beneficiando al proyecto abierto.
En febrero de 2026, la propia empresa explicaba su modelo con una claridad difícil de ignorar: las licencias de CrossOver financian desarrollo, una parte importante de ese trabajo vuelve a Wine y la compañía no necesita sostenerse monetizando publicidad, atención o datos de sus usuarios.
Hay dinero, trabajadores, clientes y propiedad, pero una parte del conocimiento producido regresa al común. Por eso la pregunta kantiana que vale la pena hacer no es si alguien ganó dinero escribiendo ese código.
Es si podemos construir sistemas tecnológicos donde la creación humana no tenga que reducirse necesariamente a modelos de suscripción.
Windows comienza a quedar desnudo
Windows es una pieza extraordinaria de ingeniería. Buena parte de la historia de la computación personal sería incomprensible sin él, y la enorme compatibilidad acumulada que Microsoft mantiene hacia atrás es una de las razones por las que muchas organizaciones continúan dependiendo de la plataforma.
El problema no es que Windows sea propietario.
El contraste aparece cuando observamos qué significa que una sola compañía controle la evolución de una plataforma de la que dependen cientos de millones de personas.
La empresa puede decidir qué integra, qué deja de soportar, qué convierte en servicio, qué recomienda, qué enlaza con una cuenta y de qué manera amplía la relación económica con quien ya compró un computador.
Microsoft ni siquiera oculta muchas de estas capas. Su documentación de Windows 11 explica que el sistema dispone de un identificador publicitario que puede utilizarse para ofrecer anuncios personalizados; también contempla contenido sugerido dentro de Configuración y distintas formas de personalización basadas en la actividad del usuario.
Hay algo particularmente revelador en la configuración denominada Device usage. Microsoft explica que, si una persona declara utilizar su computador para jugar, puede recibir una prueba de Xbox Game Pass o recomendaciones relacionadas con gaming; si lo utiliza para negocios, puede recibir una oferta de Microsoft 365 Business. La compañía describe explícitamente estos resultados como consejos, anuncios y recomendaciones personalizados.
No hay nada clandestino aquí y precisamente por eso resulta interesante.
Durante años pensamos el sistema operativo como el suelo del computador: aquello sobre lo que colocábamos nuestras cosas. Poco a poco también puede convertirse en un espacio desde el que se mantiene una relación comercial permanente con nosotros.
Y eso afecta especialmente a algo que parecía estar fuera del trabajo: el ocio.
Jugamos dentro de tiendas. Vemos dentro de plataformas. Escuchamos dentro de suscripciones. Guardamos dentro de nubes. El acceso puede depender de cuentas, autenticaciones, servidores, licencias y condiciones que continúan existiendo mucho después de haber pagado por el dispositivo que tenemos delante.
No se trata de afirmar que cada suscripción sea abusiva o que todo servicio conectado sea innecesario. Algunos ofrecen un valor real y sostienen trabajo real.
Lo que ha cambiado es algo más sutil: una cantidad creciente de actividades humanas ha pasado a concebirse como una oportunidad para conservar abierta indefinidamente una relación de monetización. Incluso descansar o jugar.
Una herramienta que todavía podemos hacer nuestra
Ivan Illich utilizó en 1973 la palabra convivencialidad para pensar herramientas que ampliaran la capacidad autónoma y creativa de las personas, en contraste con sistemas que terminan obligando a sus usuarios a adaptarse a las necesidades de la propia estructura técnica. Para Illich, la cuestión no era rechazar las herramientas, sino preguntarse cuándo dejan de estar bajo nuestro control y comienzan a reorganizar nuestra vida alrededor de ellas.
Wine permite mirar el computador desde ese ángulo.
No exige que Microsoft abra Windows.
Tampoco reproduce una máquina Windows completa dentro de Linux. Wine se define como una capa de compatibilidad: traduce llamadas de la API de Windows para que puedan ejecutarse sobre otros sistemas.
Hay algo profundamente emancipador en esa idea, porque un archivo ejecutable deja de contener una orden implícita acerca del sistema operativo que debemos poseer.
El usuario recupera una parte de la decisión.
No siempre funciona. Hay incompatibilidades, regresiones, anticheats, DRM y aplicaciones que continúan dependiendo de comportamientos muy específicos. Wine no elimina mágicamente las estructuras propietarias.
Pero demuestra que al menos parte de aquello que considerábamos una dependencia inevitable era, en realidad, una dependencia técnicamente reconstruible.
Es ahí donde Windows comienza a quedar desnudo ante nuestra mirada, no porque esté desapareciendo, sino porque empezamos a distinguir qué parte de su poder procede de la excelencia técnica de su software y qué parte procede de haber controlado durante décadas las condiciones bajo las cuales ese software podía ejecutarse. Wine separa lentamente ambas cosas.
Preservar un programa también es preservar cultura
Wine 11 trae además una mejora menos espectacular que los 860 FPS.
La nueva arquitectura WoW64, introducida experimentalmente en Wine 9, pasa a considerarse plenamente soportada y añade compatibilidad con aplicaciones Windows de 16 bits.
En una nota de lanzamiento esto parece una especificación para aficionados a la informática retro.
Culturalmente significa algo diferente.
Un programa antiguo no pierde automáticamente su valor porque haya dejado de actualizarse.
Puede ser un videojuego, una herramienta científica, un software musical, un sistema de diseño, un programa educativo o alguna pequeña aplicación escrita por una persona que ya ni siquiera mantiene una página web.
También puede contener una interfaz, una manera de resolver un problema, un lenguaje gráfico o una concepción particular de lo que debía ser utilizar un computador.
El software forma parte de nuestra memoria.
La Library of Congress lleva años tratando precisamente esta dificultad. Preservar los bits no garantiza poder volver a utilizar una obra digital: el formato puede quedar obsoleto, el software original puede desaparecer, una licencia puede impedir ejecutarlo o el hardware necesario puede dejar de existir. Por eso la emulación y la preservación de entornos forman parte de las estrategias contemporáneas de conservación digital.
La propia Library of Congress incluye software y videojuegos en sus recomendaciones de preservación y contempla versiones virtualizadas o emuladas de plataformas propietarias cuando son necesarias para mantener las obras utilizables.
Wine pertenece, aunque su objetivo inmediato sea otro, a esa misma constelación cultural, y hace posible que algo sobreviva fuera de la casa donde nació. Eso cuestiona una de las ideas más arraigadas de nuestra relación con la tecnología.
Nuevo no significa mejor; viejo no significa inútil
Nos hemos acostumbrado a una secuencia demasiado cómoda:
nuevo, mejor, viejo, obsoleto, descartable.
En el mundo material ya es discutible. En software puede llegar a ser absurda.
Un editor de texto escrito hace quince años puede seguir editando texto.
Un sintetizador virtual antiguo puede continuar produciendo exactamente el sonido por el cual alguien lo eligió.
Un videojuego no pierde su valor cultural cuando aparece una GPU nueva.
Una herramienta creada para resolver un problema puede continuar resolviéndolo mucho después de que la empresa que la desarrolló haya decidido que necesita vender otra cosa.
Incluso las propias soluciones que terminan integradas en sistemas contemporáneos tienen historias más largas de lo que sugieren sus números de versión.
NTSYNC no nació el día que Wine 11 apareció en una página de descargas. Es el resultado de años de intentos por resolver las limitaciones de los mecanismos anteriores de sincronización. Y esos mecanismos anteriores, a su vez, existían porque durante décadas Wine había tenido que aprender cómo reproducir un comportamiento concebido originalmente para otro sistema.
Visto así, el progreso deja de parecer una sucesión de productos y comienza a parecer más a una conversación entre generaciones. Lo hermoso es que nadie necesita comenzar completamente desde cero.
El problema de llamar propiedad a todo lo que tiene valor
Durante buena parte de nuestra historia económica, escasez y valor caminaron juntas. Poseer significaba, en gran medida, poder excluir. Y de algún modo el fantasma de la exclusión vive en las redes sociales.
Este terreno vale porque no todos pueden tenerlo. Este mineral vale porque existe en cantidades limitadas. Este objeto es mío porque, mientras lo tengo yo, no puede estar simultáneamente en tu casa.
El mundo digital introdujo bienes que no obedecen completamente a esa lógica y, sin embargo, buena parte de nuestras instituciones económicas continúa intentando reconstruir alrededor de ellos las condiciones de exclusividad del mundo físico.
Licencias | DRM | Activaciones | Servidores de autenticación | Suscripciones | Cuentas
No todas estas tecnologías son injustificadas. Hay un problema económico verdadero detrás.
Si producir la primera copia de un programa cuesta millones y producir la segunda cuesta prácticamente nada, ¿cómo financiamos la primera?
Benkler reconoce precisamente esta tensión. Los derechos de propiedad intelectual pueden crear incentivos para financiar producción, pero lo hacen introduciendo exclusividad sobre algo cuyo uso por una persona no impide técnicamente el uso por otra.
El software libre tampoco ha resuelto completamente el problema.
Hay proyectos fundamentales mantenidos por pocas personas. Hay desarrolladores agotados. Hay infraestructura subfinanciada. Hay empresas multimillonarias construyendo negocios sobre componentes abiertos cuyo mantenimiento termina recayendo en comunidades diminutas.
Nada de eso desaparece diciendo que el conocimiento debería ser libre.
Pero Wine introduce una posibilidad mucho más interesante que esa consigna.
CodeWeavers puede vender CrossOver.
Valve puede construir Steam y Proton alrededor de Wine.
Los desarrolladores pueden recibir salarios.
Los usuarios pueden pagar por soporte, integración, comodidad y servicios.
Y el conocimiento fundamental puede seguir acumulándose en una base que otros pueden estudiar y utilizar.
Crear riqueza no obliga necesariamente a convertir cada fragmento de conocimiento en una propiedad exclusiva.
Quizá esa sea una de las ideas económicas más radicales que el software libre ha normalizado sin hacer demasiado ruido.
Los 860 FPS eran lo menos importante
Volvamos entonces a Dirt 3.
110,6 FPS.
860,7 FPS.
Al comienzo parecían una demostración de velocidad.
Después de recorrer la historia que existe detrás, quizá signifiquen otra cosa.
Ese segundo número no apareció porque alguien decidió borrar Wine y escribir una alternativa completamente nueva.
Apareció después de décadas intentando comprender Windows, años explorando distintas formas de sincronización, experimentos que funcionaron parcialmente, soluciones con limitaciones, discusiones técnicas, pruebas realizadas por personas diferentes y finalmente una implementación que pudo encontrar su lugar tanto en Linux como en Wine.
Wine 11 utiliza NTSYNC cuando el kernel apropiado está disponible. Proton, la capa que ha convertido gran parte del catálogo Windows de Steam en una posibilidad cotidiana para usuarios de Linux, ya se basa en Wine 11 en su rama actual.
E software libre sigue siendo difícil de interpretar utilizando únicamente las categorías con las que aprendimos a valorar objetos.
En el mundo material, compartir suele significar repartir. En el mundo del conocimiento, compartir puede significar multiplicar.
Y eso obliga a revisar también nuestra idea de progreso. Tal vez una sociedad tecnológicamente madura no sea aquella capaz de producir cada vez más cosas que sustituyan rápidamente a las anteriores. Quizá también deberíamos aprender a reconocer qué herramientas continúan siendo útiles, qué conocimiento merece conservarse y qué partes de nuestra cultura digital deberían poder sobrevivir a las empresas, sistemas operativos y modelos de negocio que las hicieron posibles.
Los 860 FPS terminarán siendo superados. Llegarán procesadores más rápidos, nuevas APIs, nuevos kernels y otras versiones de Wine. Pero existe una pregunta bastante más duradera detrás de ese benchmark.
Cuando casi todo lo digital puede copiarse, modificarse y transmitirse sin destruir el original, ¿Cómo debemos construir nuestra relación con la propiedad en el mundo digital?.
Tal vez el progreso digital no consista en reemplazar constantemente el mundo que tenemos, sino en aprender, por fin, a conservar todo lo que ya sabemos.
