EDICIóN GENERAL

Huawei lanza ordenador sin AMD, Intel ni Microsoft

#59 "Linux para ARM está verde en comparación con x86."

NO

Ahí están los Chrome OS, sin ir más lejos.

El problema de ARM en linux es que cada fabricante que licencia ARM tiene permiso para añadir sus propias modificaciones, y se hacen sin ton ni son (y aquí sólo estoy hablando del procesador). En general, el soporte ARM en linux es un caos, hay SOCs muy bien soportados, hay SOCs que tienen la mitad de sus componentes bien soportados y la otra mitad sin soporte, SOCs que ni arrancan y así.

RISCv por lo que tengo entendido tiene un sistema de extensiones que permite que se comparta el código base entre todas las implementaciones (y luego cada extensión tenga que soportarse aparte), lo que facilita muchísimo el mantenimiento y la integración en kernel.

Y si, aquellos SOCs que tienen componentes sin drivers abiertos son un dolor, sean de la arquitectura que sean (por eso, hasta nvidia tiene soporte completamente libre de sus SOCs arm, y precisamente son los que han conseguido extenderse más y en más ámbitos).

Pero como tal, los SOCs ARM que tienen buen soporte detrás funcionan perfectamente en linux. No es algo inherente a ARM sino al fabricante.
#109 Tienes razón. Antes me expresé mal: El soporte ARM no está "verde", sino que es muy irregular.

#59 entonces no deberia haber problema con los drivers gráficos.

#122 Raspberry no es el mejor ejemplo. Tiene una gran comunidad y mejora constantemente, pero en sus inicios los drivers estaban verdes.

Ejemplos: La Raspberry pi, que durante los primeros años de RP1-3 los drivers de la GPU no soportaron aceleracion grafica del escritorio, penalizando el rendimiento. Y luego está sus blobs no libres y el driver grafico semicerrado de esas versiones de Pi.

Y varias distros importantes tardaron en ser porteadas a la PI4... la version estable de la distro oficial de la fundacion, Raspbian, está compilada para ARM de 32bits en lugar de 64bits (pese a que ARM8 aporta un aumento de rendimiento). La GPU es capaz de usar Vulkan y GLES3.2, pero sus drivers solo soportaban ES3.0 de salida, recientemente subieron a la GL ES3.1 y los drivers Vulkan aun van a tardar en estar listos.

La decodificacion por hardware de videos y otras cosillas no funciona o lo hace mal en Raspbian.
#220 la decodificación hardware funcionó siempre decentemente. Ahí tienes las primeras versiones con XBMC y posteriormente con Kodi.

Me hablas de drivers de la gráfica. Son los mismos problemas que vas a tener con una tarjeta gráfica Nvidia. Driver propietario o el libre con muchas carencias. Y la implementación de OpenGL/Vulkan cuando el fabricante quiera.

Quitando el soporte 64 bits, que tampoco creo que le compense concretamente a las PI (una compilación en 64 bits dejaría fuera a las primeras versiones del SoC), Linux ha funcionado más que decentemente en este SoC.
#222 "la decodificación hardware funcionó siempre decentemente. Ahí tienes las primeras versiones con XBMC y posteriormente con Kodi"

Pero yo estoy hablando de Raspbian: INstala ese SO y VLC y trata de ejecutar un video 4K. En el navegador no va nada bien, a menos que instales versiones alteradas de Chromium basadas en el navegador de ChromeOS. Kodi lo arregla (en su XBMC o OpenELEC, pero no son distros oficiales de la fundación RP y tardaron varios meses o años en tener una versión realmente estable para RP4.

Lo cual nos lleva de vuelta a mi razonamiento: Como muchas distros no estaban disponibles o no eran estables durante el primer año del Soc, el soporte Linux que tenía el dispositivo era imperfecto e inestable. O, al menos, menos estable que el tipico PC al que instalases Linux o Windows.

" Quitando el soporte 64 bits, que tampoco creo que le compense concretamente a las PI (una compilación en 64 bits dejaría fuera a las primeras versiones del SoC), Linux ha funcionado más que decentemente en este SoC. "

A) Pueden compilar dos versiones, o lentamente dejar de dar soporte oficial a anteriores Pi (la Pi4 1GB cuesta lo mismo que una Pi3, nadie va a comprar la ultima)

B) Es la cambio de arquitectura da algo más que gestionar más RAM. La arquitectura ARMv8 trae bastantes mejoras de rendimiento respecto a su predecesor, y un SoC de escasa potencia como la Pi4 necesita toda la potencia que pueda sacar, aunque sea rompiendo la compatibilidad con placas antiguas.

Ah, y no te creas que la version de 64bits es estable. He leido que hay muchos problemas de tearing en la version de 64bits (algo de los drivers Mesa y el compositor) y durante un tiempo la fundación realizó quimeras inestable como lanzar un kernel de 64bits dentro de un raspbian de 32bits...

Que estuviese disponible no quiere decir que obtuvieses una experiencia digna de un Linux estable de escritorio.
#225 Yo tambien hablo de Raspbian. XBMC funcionó desde el principio, si bien creo que los paquetes no eran los oficiales de rapsbian. Pero tenías en reproductor oficial (omxplayer) que siempre estuvo desde el principio. Coño, es que mi primer HTPC fue un RPi 1 modelo B, y me tiró mucho tiempo.

"Lo cual nos lleva de vuelta a mi razonamiento: Como muchas distros no estaban disponibles o no eran estables durante el primer año del Soc, el soporte Linux que tenía el dispositivo era imperfecto e inestable. O, al menos, menos estable que el tipico PC al que instalases Linux o Windows.
"
El soporte que tenia el dispositivo desde el principio siempre ha sido bueno, y el video en 4K lo podías ver usando las herramientas del fabricante. Que no puedas ejecutar el VLC no significa que el soporte Linux sea inestable ni imperfecto, puedes decir que carece de compatibilidad con algunas tecnologías, pero no inestable e imperfecto.

"A) Pueden compilar dos versiones, o lentamente dejar de dar soporte oficial a anteriores Pi (la Pi4 1GB cuesta lo mismo que una Pi3, nadie va a comprar la ultima)"

Por poder pueden, pero hay que valorar más aspectos aparte del técnico.

"B) Es la cambio de arquitectura da algo más que gestionar más RAM. La arquitectura ARMv8 trae bastantes mejoras de rendimiento respecto a su predecesor, y un SoC de escasa potencia como la Pi4 necesita toda la potencia que pueda sacar, aunque sea rompiendo la compatibilidad con placas antiguas"

Y cada procesador nuevo trae nuevas instrucciones, y no por ello se compila una versión optimizada para cada procesador. (Bueno, se hacía en tiempos de la gentoo, ¿donde esta gentoo ahora?). Es una cuestión de tiempo de todas maneras.
#226 "Y cada procesador nuevo trae nuevas instrucciones, y no por ello se compila una versión optimizada para cada procesador. "

Ya, pero aquí estamos hablando de una arquitectura analoga a x86_64 que además trae un incremento de rendimiento considerable (mayor que el cambio de x86-> x86_64). Todas las distros y SO vienen en 32 y 64 bits y pronto solo 64bits. Lanzar 2 versiones es perfectamente posible.

Además, con el paso de los años los SOs y software (ej: Firefox) piden instrucciones adicionales como SSE2 para ir mas rapidos. ¿Por qué no pedir ARMv8?

En otras palabras, lo que pido yo (usar versiones de instrucciones superiores) es algo que ya se hace en PC de escritorio, y que beneficiaría mucho a RPi4. Los problemas de compatibilidad no pueden ser tan grandes, ya que casi todo su software es de codigo abierto y puede compilarse a la nueva arquitectura.

Sinceramente, tener esa potencia ahí, sin aprovecharse, es como tener 8GB de RAM con un SO de 32bits. Es un desperdicio logistico.

menéame