EDICIóN GENERAL

Huawei lanza ordenador sin AMD, Intel ni Microsoft

Parece que les queda trabajo con los drivers
#1 Pues tendría delito. Los drivers son los mismos que para Android. ¬¬
#2 Android para componentes de PC poco drivers tiene.

Aparte usa una versión de Linux no de Android
#19 Los drivers van en el Kernel
El Kernel de Android y Linux es el mismo.

Creo que sí tiene. Me da a mí. xD
#20 No, el kernel de Android esta basado en el de Linux, pero no es el mismo. De hecho Google esta en un proyecto para usar realmente el kernel original de Linux

arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-lin

#36 #30 Creo que el que no sabe de que habla no soy yo
#20 si el problema es más bien de que los drivers los hace cada compañía para sus dispositivos y son privativos... ¿No? Pero si es ARM ya tendrían que tener alguno previo.
#61 son cosas diferentes. Que les quede trabajo con los drivers pera un ordenador no significa que en el común de los ordenadores tengas problemas con drivers y sí hay problemas en algunos (también en Windows por cierto).
Sé de un ordenador Acer al que le puse xubuntu o lubuntu que no tiene sonido. El soporte viene en el kernel 5.7o 5.8 así que toca esperar un poco. Pero llevan con ello varios años aunque tuvieran el parche también hace 2 años...
#108 #67 y #20 tienen razón.
#19 Ofú, a mí mis padres me enseñaron a no opinar de lo que no entiendo, es mejor escuchar y aprender
#30 Con esa actitud nunca llegarás a nada en Meneame! :-D
#19 creo que no tienes mucha idea de lo que hablas xD
#2 ahí pone Linux (y otras cosas —> “ Según cuentan en el vídeo, el ordenador tiene problemas de rendimiento y compatibilidad. No soporta aplicaciones de 32 bits, y otras como las de Adobe, dan muchos problemas. Incluso le cuesta reproducir vídeo a resolución 4K. Recomiendan usarlo solo para aplicaciones de ofimática no muy exigentes.”)
#29 #89 Yo que curro con mucho con excel llenos de formulas me cag** en los que dicen "ofimatica no muy exigente" :-) tengo un pc con 4 años y ahora con un disco duro solido nuevo va bien, pero si no... tela.
#126 los excels cargados exigen más de lo que la gente piensa
#29 Teniendo en cuenta que es ARM y ningún programa de PC convencional funcionaría en esa arquitectura, que no soporte ARM 32 bits no es muy relevante y seguramente sea hasta intencional.

Y dudo que la versión ARM de Adobe funcione bien en ARM en general.. no creo que sea culpa de este equipo ni de los drivers. Lo de que le cueste reproducir video a 4K ya es otra historia, pero en el video dicen que puede reproducir 4K a 60 fps asique no tengo claro quien tiene razón o que es lo que quiere decir con "le cuesta", sin referencias podría ser mil motivos que no necesariamente tengan que ver con los drivers, podría hasta ser haber usado un video con un encoding no soportado, no el hecho de que sea 4K el video.
#164 Ayer me pasaron un vídeo del pi Phone F2 en 8k (160 megas, 10 segundos) y mi iPhone 11 no era capaz de Reproducirlo xD
Tengo que meterme en Linux a ver (lo pasaré por Telegram)
#2 Los fabricantes de chips gráficos hacen drivers cerrados para hardware moderno en android. Drivers específicos para modelos concretos, que se abandonan rápido, muchas veces llenos de bugs que dificultan desarrollar juegos y aplicaciones -están llenas de excepciones para modelos concretos- y portarlos de un hardware a otro. Esta es la principal razón de que cueste bastante hacer imágenes basadas en android libres y plenamente funcionales, como AOSP, porque drivers y SO no están tan integrados como los que suelta el fabricante del móvil -que conoce los bugs concretos y ha parcheado adecuadamente su android para evitarlos, que no corregirlos, porque esa es labor del fabricante del chip gráfico y ya sabemos que da un soporte bastante limitado-). También es la razón por la que muchos fabricantes no se pillan los dedos ofreciendo actualizaciones del SO en sus móviles (con cada versión, portar sin que los drivers te jueguen malas pasadas es cada vez más difícil), o se retractan o tardan muchísimo en salir.

Los drivers libres que existen, son a base de ingeniería inversa de manera desinteresada por gente a la que le gusta jugar con estas cosas y están hechos para kernels modernos (android usa kernels bastante antiguos) y hardware viejo (porque nadie da especificaciones del hard, se van descubriendo con el tiempo y la perseverancia de la gente.

Estas son las principales causas por lo que no van en los android (y por las que los intentos de telefonos con SO 100% libre como librem5 o pinephone usan SOCs desfasados, porque si no, no tendrían soporte, aparte de por precios).
#108 en #99 lo explica bastante bien.
#2 No necesariamente. Hasta donde se, en Android no se utiliza DRM para la parte gráfica (Ojo, que no hablo de gestión de derechos - en.wikipedia.org/wiki/Digital_rights_management -, sino de acceso a la tarjeta gráfica - en.wikipedia.org/wiki/Direct_Rendering_Manager -). Sólo por eso, ya no es lo mismo.
#2 y para que necesita drivers de Android? Linux lleva años funcionando en ARM, de hecho la Raspberry Pi usa linux y arm.
#1 Sí, segun tengo entendido, Linux para ARM está verde en comparación con x86.
No ayuda que esos dispositivos ARM suelan llevar chips graficos cutres con drivers cerrados y malos.

Si Huawei intenta de verdad meterse en el sector de PC y no lo abandonan tras hacerse la foto inaugural, las mejoras que vayan haciendo a su distro Linux podrán ser llevadas al resto de distros.
#59 No está verde, lo que ocurre es que son arquitecturas muy diferentes. ARM está concebido para ser de reducido tamaño y de bajo consumo, por eso se le denomina "embebido". Otras arquitecturas similares pueden cumplir la función como MIPS.

Una instalación en ARM ahora mismo puede ser más complicada porque no hay apenas interés en que cambie, pero lo está haciendo por ejemplo con sistemas como la Raspberry (y aún queda), y si Huawei pasa por aquí es que quiere adelantarse a que los RISC-V (muy probablemente el verdadero futuro, que este sí está verde) se los coman a ellos. Todo es adelantarse.
#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.
#59 Mal entendido. Ejemplo evidente, Raspberry Pi.
#59 Técnicamente, este lleva una AMD RX550 ensamblada por una compañía china
#59 no creo que este verde, al menos para según que tareas: en.wikipedia.org/wiki/Annapurna_Labs
#1 Bastante tiempo hace que usas linux me parece a mi, yo instalo ubuntu y tengo que instalar 0 drivers.
#61 que no los tengas que instalar manualmente simplemente quiere decir que la distribución lo ha hecho por ti.
Pero si el driver existente no está a la altura, hay que mejorarlo. A eso se refiere #1
#139 Muchas gracias, menos mal que alguien me entiende
#61 es exactamente lo que te ha dicho #139, que los drivers no son buenos, que les queda por mejorar, no que no haya.
#1 Pues eso es un problemón.
#1 Eso de por si no demuestra que se pudiera tratar de un Linux mainline sin ninguna clase de parches con optimizaciones o drivers específicos para Android. Parchear el kernel es muy común, sobretodo en sistemas empotrados.

En teoría puedes tener perfectamente un driver personalizado que soporte KMS y que se haya desarrollado sin ser aceptado en upstream y que no lo hayan querido integrar en la rama oficial de Linux.

menéame