Hace 4 años | Por Sinfonico a muylinux.com
Publicado hace 4 años por Sinfonico a muylinux.com

Se acabó el culebrón: Canonical cede a la presión de la comunidad y se compromete a mantener la arquitectura de 32-bit al menos hasta el lanzamiento de Ubuntu 20.04 LTS el próximo año, según informan en un comunicado publicado ahora mismo en el blog de Ubuntu.

Comentarios

s

#1 No sé, yo creo que sus desarrolladores poco pueden hacer. Entiendo que el problema son los juegos antiguos, que dejarían de funcionar si no hay soporte para 32 bits. Y dudo mucho que se puedan hacer ports a 64 bits en muchos de ellos.

eltoloco

#2 claro que pueden hacer, la solución bestia sería encargarse ellos mismos de mantener y distribuir las librerías necesarias, hasta aquí estamos de acuerdo en que es mucho trabajo al menos para Wine, que ya tienen bastante, pero Valve se lo podría permitir.

Y seguro que hay más opciones, por ejemplo una capa intermedia de compatibilidad entre las llamadas a las librerías de 32 bits y las librerías de 64 bits. De la misma forma que se puede ejecutar software antiguo en Windows (p.e. juegos de 16 e incluso 8 bits) sin necesidad de mantener todas las librerías originales, sino con una capa de compatibilidad incluida junto con los juegos.

Lo que está claro es que los 32 bits son cosa del pasado, y tarde o temprano se van a eliminar las librerías de los repositorios. Hay que empezar a buscar alternativas ya mismo.

s

#3 La cosa es que eso ya existe. Por lo que yo entiendo, el problema viene de la adecuación de las librerías de las tarjetas gráficas que aún no han salido. Y ese trabajo no tengo claro que sea Valve quien lo tenga que hacer, en todo caso debería ser Nvidia o ATI quién se pusieran a ello.

Y, desde luego, si todas las distros de Linux soportan 32 bits y lo siguen haciendo, estoy bastante seguro que el problema lo tiene Ubuntu y no Valve. No tienen una posición de poder como podría ser la de Microsoft.

eltoloco

#5 Si ya existiese no habría problema en eliminar las librerías de 32 bits. Si se depende de ellas es porque no hay otra opción. Y no entiendo cual es la relación entre las librerías de 32 bits y las tarjetas gráficas “que aún no han salido”, ni que pintan Nvidia y AMD en esto, nadie está hablando de drivers en ningún momento.

Y Ubuntu será pionera en eliminar el soporte a 32 bits, pero no será la única ni mucho menos. Tarde o temprano todas irán dejando de lado el soporte a 32 bits, hasta que llegue el día que incluso el kernel elimine el soporte, como ya se ha hecho con otras arquitecturas obsoletas.

s

#6 Las librerías llaman a las intrucciones, tanto de la tarjeta gráfica como del procesador. Y esos drivers, como bien dices, se actualizan, cambian nombres, estructuras, etc. Cada vez que Nvidia saca un CUDA nuevo, por poner un ejemplo alejado de los juegos, tanto Tensorflow como PyTorch tiene que actualizarse para dar cabida a nuevas funciones que puedan aparecer, e incluso para que algunas de las funciones ya existentes sigan funcionando. Si ahora Tensorflow dejara de dar soporte, tarde o temprano la librería dejaría de funcionar en modelos nuevos, por este motivo (y supongo que algún que otro problema que pudiera aparecer). Esto llevaría a que modelos que funcionan correctamente usando unas GPU, dejen de funcionar en otras.

Entiendo que el soporte a 32 se acabará eliminando en algún momento. Pero dado que, a efectos de juegos, Ubuntu es residual, es una jugada bastante arriesgada, si tú eres el único que lo hace. Puede provocar migraciones a otros sistemas.

eltoloco

#7 repito, no entiendo que tienen que ver Nvidia y AMD. Cuda en los pocos juegos que lo aprovechan es opcional, nunca es obligatorio. Ademas Cuda es software privativo que viene incluido en el driver de Nvidia, no tiene nada que ver con las librerías de 32 bits que mantiene Ubuntu.

s

#9 Pues te lo paso a software libre. Cada vez que nvidia saca un nuevo driver, las librerías de mesa tienen que actualizarse. Si dejas de dar soporte...el rollo que puse antes con CUDA otra vez

eltoloco

#10 no seas terco, ni Cuda ni Mesa tienen nada que ver en esto. Son librerías de 32 bits con funciones que se ejecutan en la CPU, no tiene nada que ver con tarjetas gráficas ni viejas ni nuevas.

s

#11 Ah, no sabía que los juegos no hacían uso de tarjetas gráficas. No entiendo mucho del tema, perdón.

eltoloco

#12 se nota que no entiendes del tema..

Los juegos, como cualquier software, hacen uso de todo el hardware principal de un PC, además de las tarjetas gráficas, pero no por ello el problema que trata esta noticia afecta a todos los componentes que usan. Que digas que como los juegos usan tarjetas gráficas el problema afecta a Cuda y Mesa es tan absurdo como decir que como usan los discos duros el problema afecta al sistema de ficheros ext4.

Para empezar tienes una pista muy importante que estás ignorando; el problema trata sobre arquitecturas obsoletas de CPU, en concreto de x86. Pero si te quieres emperrar en decir que es problema de gráficas y afecta a software como Cuda, Mesa o Vulkan, no dejes que nadie te lo impida.

s

#14 No soy un experto en juegos, no te lo niego. No tengo mucha idea de todas las cosas que utilizan. Pero de CPUs y GPUs sí sé más, ya que me va en el trabajo. Deja de insistir con CUDA, era un ejemplo que te quería poner fuera del tema de juegos (como bien expliqué cuando lo puse), pero con respecto al resto...las librerías gráficas (como OpenGL, por ejemplo), tienen versiones en 32 y en 64 bits. Obviamente, necesitan hacer uso del procesador en ciertos momentos. Y si no mantienes esas librerías, no van a funcionar cuando salgan nuevos modelos, y cambien algo en los drivers.

Lo mismo pasa con las CPU, obviamente. No quiero decir que el problema de las librerías gráficas sea el más grave que tienen (francamente, no lo sé), pero sí es el que más evoluciona en sus librerías. Y la retrocompatibilidad no es algo que les importe mucho.

a

#1 No se puede, Wine abastrae a muchas apps que solo funcionan en 32 bits, como versiones antiguas de Photoshop y Office.

D

Yo creo que ya habría que ir pasando página, así mejoraría la eficiencia de los Sistemas Operativos, procesadores, etc.

D

#4 En estas cosas hay que aprender de Apple, creo que es la única grande que sabe gestionar la compatibilidad hacia atrás de la forma correcta.