#67 ¿Pero tú entiendes el significado de la palabra extensión? ¿una cosa que es aparte del estándar y que puedes implementar o no? ¿quieres ir por favor a la ilustración de la página numerada como 25? ¿no lo ves en el dibujito, o incluso con un diagrama te pierdes?
RISC-V KERNEL -> Baseline -> Full feature y luego, fuera de todo esto "codesense, stacksafe, powerbrake, dsp/fp extensions, security extensions, custom extensions, etc."
Incluso vienen así puestas en conjuntos, para que veas y diferencies que hay capas que son superconjuntos de otras capas, y luego cosas en conjuntos completamente separados...
No ya es que ni leas tus propios enlaces... es que te lo ponen de la manera más sencilla posible y lo ignoras...
Pero es más, en la 27 dice literalmente:
Adopting RISC-V as Natural ISA Evolution: V5m+ more Andes Ext.
O sea, la v5m + extensiones de Andes
#68 De tu propio enlace:
"The Andes PMU extension provides the same mechanism as Sscofpmf, allowing us to reuse the SBI PMU driver to support event sampling and mode filtering."
¿qué más da que hagan extensiones propias? son extensiones, tú añades lo que quieras mientras la base sea la misma para todos. ¿Por qué te iban a pedir que no añadieras cosas? lo importante es que seas compatible a nivel de base, si otros fabricantes no soportan tus extensiones o no son estándar da igual. No aprovechas esas funcionalidades, pero todo sigue funcionando... no rompen nada.
"To make use of this custom PMU extension, "xandespmu" needs to be appended to the riscv,isa-extensions for each cpu node in device-tree, and enable CONFIG_ANDES_CUSTOM_PMU."
¿Y si no quieres usar esa extensión? ¡pues no la usas! no es imprescindible para tener un riscV corriendo, del mismo modo que no es imprescindible tener una de las nuevas extensiones de intel AMX para poder usar un kernel x86 en un amd... ¿necesitas soporte de intel en caso de que sus extensiones rompan? pues igual que cuando sus instrucciones de división fallaban en los pentium... ¿eso en qué afecta al resto de procesadores intel que no tienen esas extensiones o las de otros fabricantes? ¿impiden que amd pueda implementar las extensiones cuando le interese? pues eso...
#65 ¿Entiendes lo que he dicho? da igual las extensiones que añadan los fabricantes, son extensiones opcionales u optativas, la base funciona igual y un kernel de linux para riscv arrancará en cualquiera, así que puedes usarlos aunque no explotes todas sus características, igual que se hace con un x86. ¿Que el fabricante de turno podrá hacer lo que le de la gana igualmente? por supuesto. Pero sería tirarse piedras contra su propio tejado y perder soporte oficial de linux. ¿Que x86 no es la mejor arquitectura con la que compararse, teniendo en cuenta que el código de arranque se sus procesadores tiene muchísima tela que cortar? también, aunque la cosa mejorará mucho cuando el soporte a 32 bits sea eliminado más pronto que tarde en software, y quién sabe cuándo y quién dará el primer paso, en hardware.
"Additionally, the RISC-V specification allows implementors to create their own custom extensions. These custom extensions aren’t required to go through any review or ratification process by the RISC-V Foundation. To avoid the maintenance complexity and potential performance impact of adding kernel code for implementor-specific RISC-V extensions, we’ll only to accept patches for extensions that have been officially frozen or ratified by the RISC-V Foundation. (Implementors, may, of course, maintain their own Linux kernel trees containing code for any custom extensions that they wish.)"
Poder usar un kernel genérico para usar placas RiscV es una ventaja que muy pocos fabricantes pueden ignorar, saber que en el kernel sólo va a acabar lo que haya sido ratificado por la fundación o extensiones de terceros estables y probadas (como las extensiones de vulkan u opengl) y que cualquier fabricante podrá implementarlas si son útiles y necesarias también es un plus. Mantener tu propia rama de linux, drivers, etc. es lo que hace que ARM sea un caos y sea imposible mantener teléfonos actualizados y con soporte, siempre hay alguna pieza de la cadena que empieza a tener incompatibilidades o problemas con lo demás más pronto que tarde.
#19 Pero un chip RiscV debe funcionar en todos lados, otra cosa es que uses esas mierdas o las ignores. RiscV no es ARM (que licencia y olvida), la filosofía es "comparte la base tal cual, estándar y sin tocar y funcionarás en todos lados; y las mierdas que quieras añadir por tu lado, irán por separado". ¿Recuerdas que habían ordenadores pentium soportando mmx y otros que no? pues el software o aprovechaba mmx o no, pero todo seguía funcionando (más o menos lento, pero funcionaba). Con ARM esto no es así, tienes que compilar con compiladores diferentes y generar código diferente, a veces tan sustancialmente diferente que no funciona en los dispositivos ARM de la competencia o en los tuyos propios de meses atrás, las diferencias llegan a esos extremos.
#20 ¿Y de qué van las mejores prestaciones? ¿de ocultarlas bajo las soluciones de siempre (añadir cosas que aceleren otras cosas por hardware y optimizar el software propio para exprimirlas, aunque el rendimiento con el software de terceros apeste hasta que les sueltes pasta o les convenzas de que optimicen específicamente para ti) y pagar más para tener mejores tecnologías de fabricación para poder luego decir que su solución es mejor que la de los demás? ¿como lo de presumir que las arquitecturas ARM son mejores y consumen menos cuando se fabrican en los mejores nodos de fabricación y con técnicas de fabricación específicas para lograr poco consumo porque su nicho de mercado es el móvil, servidores flojitos pero con "high core count" y como mucho portátiles pero que escalan horriblemente mal?
Te voy a poner un ejemplo: ¿Sabes quién fue la primera arquitectura que apostó por muchísimos cores ligeros y poco potentes para atacar el mercado de los servidores web y java? la sun SPARC (en particular, a partir del UltraSparc T2 -8 cores con 8 hilos cada uno, hasta 64 threads simultáneas- y T3 -16 cores con 16 hilos cada uno, 128 hilos, que se dice pronto-) . Y tuvo relativo éxito, pero al final el mercado buscaba cosas más generalistas y potentes y murió. ¿Sabes qué otra arquitectura intentó algo similar? bulldozer de amd. Y falló en parte por estar fabricados con tecnología que intel podía barrer tranquilamente (aunque con gran capacidad multitarea, poco potentes y consumiendo más que los procesadores de intel). Y ojo, que hablamos de la tecnología que movió la play4.
Justamente ahora AMD tiene soluciones que aunan todo y por eso están comiéndose ciertos mercados: tienen cpus con gran cantidad de capacidad multiproceso, con muchísima potencia cada núcleo individual y con un consumo contenidísimo y mucho menor que el de los productos de sus rivales en sus mismas gamas y tecnologías de fabricación equivalentes (si, incluso comparados con apple... sácalos de… » ver todo el comentario
#52 Son cosas diferentes y atacan ámbitos diferentes. MS y otras han tenido que asociarse para permitir usar patentes en desarrollos de software libre porque se dieron cuenta de que estaban pisándose su propia prosperidad con eso (dado que las compañías propietarias hacen mucho dinero con el software libre y demandarse unas a otras por cosas que usan todas al final era una tontería).
Cada dispositivo ARM es modificado por cada empresa para añadir sus mierd... cosas, tienen software de arranque distinto, etc. Hacer un kernel ARM universal (como podría ser un x86 o un riscv) es imposible ahora mismo.
RISC-V ha tomado un camino diferente: extensiones (estándares y no estándares). RISC-V base es soportado por todos y luego cada uno soportará las extensiones que necesite. Si por lo que sea, añade extensiones no estándares, no afectaría a un kernel que soporte la base de RISC-V, simplemente no las aprovecharía.
Además, las extensiones tratan de pensarse, madurarse y estandarizarse en comité para que sean útiles, bien diseñadas y permitan añadir un valor importante al conjunto de la arquitectura. Lo contrario que ARM, vamos.
#13 GPL vale, porque promueve que se comparta lo que se desarrolle (y ahí va tanto funcionalidades como parches de seguridad; la calidad y el alcance del código sube y todos salen beneficiados) .
El problema que apunta #8 es debido a la moda de usar licencias que permiten hacer lo que quieras con los fuentes. De ahí si que hay muchísima gente que se aprovecha del trabajo de los demás sin que el resto se beneficie.
Por otro lado, nadie evita que alguien pueda cobrar o enriquecerse usando software libre; de hecho, la GPL permite y anima a cobrar por el trabajo que se realiza.
#97 Precalcular siempre es más rápido porque una vez hechos los cálculos, nunca vas a tener que repetirlos (se guardan en disco o memoria y ya está). Y eso no implica hacerlo siempre o la primera vez que ejecutas el juego, lo haces "de fábrica". De hecho, algunos aspectos de todos los niveles son "precalculados" (las luces y sombras de los escenarios de juegos de la época se generan, se dibujan y se guardan, son estáticas, se cargan con el nivel y se añaden como una capa de dibujado más). De hecho, en el quake original y muchos otros juegos, los niveles se compilaban. Eso de lenguajes de scripting dinámicos donde las cosas de un juego se evalúan sobre la marcha llegaría más tarde (a partir del unreal, probablemente el quake 2 o poco antes).
#30 El copro hacía operaciones en coma flotante muy precisas, pero también de manera muy lenta (para los estándares actuales ya ni te cuento). No tanto las operaciones en si (si no hubieran sido rápidas, no tendría sentido) sino la comunicación con el procesador (el procesador se quedaba "bloqueado" a la espera, cedía el control de ejcución al coprocesador por así decirlo y luego lo recuperaba). Esto, como comprenderás, es un lastre muy grande para un juego que quiere mover muchísimas cosas por pantalla muchas veces por segundo.
"nother point not addressed in the existing answers relates to the latency associated with accessing an external coprocessor.
The first math coprocessors, while much faster than doing the same work on a CPU, still took many clock cycles to complete each operation. The overhead (bus cycles) associated with transferring data between the two chips was "lost in the noise". In other words, there was no penalty for putting those functions in a separate chip.
However, as coprocessors got faster, this overhead became a significant bottleneck on throughput, and this is what drove integrating them directly into the CPU chip."
#2 Seguiría tratándose los síntomas y no la causa. Pero claro, las guerras de la región y los intereses de segundos y terceros países en las materias primas, etc. son cosas mucho más complejas y delicadas de abordar porque implicaría cuestionar nuestro modelo económico, social y en parte nuestro modo de vida... eso para cualquier político es un suicidio (ya les cuesta ponerle freno a las corporaciones, incluso cuando se demuestra fehacientemente que están violando leyes, acuerdos y regulaciones...)
#174 Hay juegos de windows que no funcionan en windows y si en linux...
De todos modos, no es una bala mágica, muchos dependen de implementaciones específicas de ciertas cosas (o sea, se programaron con librerías que tenían bugs de forma que se aprovechaban de ellos o los ignoraban y seguían a sus cosas). Es imposible cubrir todos los posibles casos y hacer que todo funcione (en parte porque la solución sería parchear las aplicaciones que no funcionan bien, no poner mil excepciones en la emulación de esas librerías para cubrir todos los casos).
Fíjate la que se ha armado porque AMD en sus últimos drivers, para poder ampliar el número de juegos que soportan su FSR3 (que como los DLSS, necesita que sean incorporados dentro de los propios juegos, no son una simple "capa" de post procesado) se le ocurrió que los drivers podrían coger e inyectar ese código directamente en los juegos en tiempo de ejecución (así, sin necesidad de que los juegos soportaran FSR 3.0, podías tener FSR gratis). El problema es que ciertos medios y controles antipiratería validan que el ejecutable del juego sea íntegro y no haya sido modificado (para filtrar a los hackers que hacen trampas modificando el propio juego y demás) y esto ha cantado por todos lados y muchos han sido baneados... pero vamos, lo suyo sería eso, parchear el propio juego (algo así como lo que hace gog para que ciertos juegos antiguos puedan funcionar en equipos nuevos).
#181 ¿Y qué tiene que ver el kernel con eso? justamente el kernel es la parte más conservadora de todo el sistema. Probablemente aún funcionarían cosas hechas incluso para kernels viejérrimos como los 2.4 o 2.6 en equipos actuales. ¿Qué pasa? las librerías... nadie programa a pelo sólo usando interfaces de kernel, todo el mundo echa mano de librerías, y estas mueren, cambian, se abandonan, mutan... es lo que hace que los programas dejen de funcionar en linux (o en windows... ¿o acaso cuando hay cambio de versión no hay cosas que dejan de funcionar?).
#164 Entonces en lugar de ir a por wine/proton, tira de codeweavers. Es wine/proton, pero de pago y orientado al software en general. Y con el soporte, tienes la potestad de hacer que los desarrolladores se centren en el software en concreto que necesites que funcione (evidentemente si valve les paga para desarrollar proton y parchear los juegos más recientes, ellos van a soportar los juegos más recientes en proton; si tú les pagas para que funcione X, pues buscarán qué es lo que falta o no está haciendo su trabajo y lo añadirán o modificarán). No es tanto que no haya interés, sino que son pocos desarrolladores y no pueden abarcar todo (y si hay empresas o particulares que les pagan para ciertas cosas particulares, evidentemente se enfocarán más en ellas).
NTFS3g llevaba mucho tiempo en desarrollo, pero no estaba lo suficientemente maduro como para permitir que la gente lo usara para el día a día (y por lo tanto, las distribuciones no lo añadían como herramienta por defecto). No es que saliera de la noche a la mañana, es que cuando se consideró usable y estable y que no se iba a comer tus datos, fue cuando se empezó a usar más masivamente.
Usa el mismo hardware y con sistemas linux "tal cual te lo descargas" y va actualizando cada cierto tiempo con comparativas de todo tipo.
Incluso si no te fías o tienes curiosidad por hacer pruebas tú mismo, puedes usar su sistema de benchmark y realizar las mismas pruebas en tu equipo (tiene perfiles para cada aplicación, normalmente aplicaciones libres y abiertas que pueden descargarse y ejecutarse sobre la marcha o juegos que tienen facilidades para obtener datos de rendimiento; no suelen ser lo último del mercado pero porque la gran mayoría no pueden lanzarse de manera automatizada o le dan los datos que necesita).
#38 Yo diría más las steam machines y cuando microsoft amenazó con vallar su windows y hacer que todas las aplicaciones fueran por su tienda. Valve le vio las orejas al lobo y quiso dinamizar y consolizar el mercado para ampliarlo y no depender de windows; el proyecto fue fallido, pero permitió poner en primer plano las limitaciones existentes y darles un toque a los fabricantes (amd estaba en plena transición de drivers y negocio sobre soluciones de software libre, sus drivers daban bastante pena y las cosas potentes y novedosas que se habían sacado de la chistera no les funcionaron por falta de soporte de desarrolladores y de sus propios equipos internos, les pilló en muy mal momento) y replantearse cómo animar a los desarrolladores
Eso es lo que ha llevado a donde estamos ahora: plataforma semiabierta con muchas ventejas y la más completa del mercado sobre SO completamente abierto y un hardware lo más abierto posible, que permite a la gente trastear y desarrollar un ecosistema de aplicaciones propias y optimizarlas sin ningún impedimento o cortapisas. Y eso sin forzar a nadie a elegir desarrollos nativos, con una capa de compatibilidad con windows que asegura que sea fácil y barato que tus juegos funcionen y que si quieres apoyar más directamente el hardware, tengas todas las facilidades para hacerlo (librerías, código, especificaciones abiertas, etc).
#35 Es complicado hacer métricas porque hay muchas cosas que valorar. No sólo influye la cantidad de frames, sino la latencia, el cómo se gestionan los recursos, temperaturas, consumo, etc.
Habrá juegos que vayan mejor en uno y otros que vayan mejor en otro SO. Tampoco es malo que haya competencia y los usuarios tengan elección. Al fin y al cabo, sony usa BSD por debajo de su playstation desde hace algunas generaciones, microsoft sigue con su windows capado en sus consolas y nintendo... sigue a lo suyo, como siempre.
#75 Eso es una aplicación, es (hasta cierto punto) independiente del sistema operativo. Y al final usa un protocolo llamado LDAP (que tiene una versión abierta llamada openldap y muchas derivadas) que puede usarse en linux también. Y también usa un protocolo llamado samba (que también puede usarse en linux). Al final, las funcionalidades del directorio activo pueden usarse en linux (y sospecho que el zenyal este no es más que un software que empaqueta e integra estas y otras cosas por debajo).
Linux tiene muchas facilidades para interconectarse y usar otros "directorios de usuarios y recursos" en su sistema de manera transparente...
#3 Si hubiese una distro enfocada y optimizada para juegos te daría la razón (lo más cercano sería el SO de la deck, pero aún así puedes salir del modo big picture y tienes el escritorio ahí, preparado y dispuesto para enchufarle un docker con pantalla, teclado y ratón y ya tienes un ordenador completo). Pero las distros más típicas y que usa la mayor parte de la gente son como windows: son sistemas de uso general, con un montón de servicios que quizá no necesites corriendo...
#2 Si usa proton, hay capa de compatibilidad. De hecho, como se ponen más recursos y optimización en las versiones de windows de los juegos, no es inusual que incluso habiendo versiones nativas para linux, las versiones windows emuladas vía pronto/wine suelan ser más rápidas...
#53 ¿Y eso es problema de linux o de los fabricantes que no dan un soporte adecuado a su hardware? igual que mucho se criticaba el windows vista cuando la gran mayoría de problemas que tuvo fueron debidos al pésimo soporte de los fabricantes a los cambios disruptivos que se introdujeron con el SO (mira lo bien que iba todo luego con el W7, que básicamente era un vista más maduro y con un soporte de drivers ya fogueado tras la experiencia con vista, con el que comparte casi todo).
Te falta comentar que Proton es un retoque a un software que ya existía llamado Wine. Que con una capa de emulación de las APIs de windows, en linux las cosas vayan más rápido también dice unas cuantas cosas...
#2 Simplemente está en el gobierno y tienen un problema gordo y tienen que quedar como los buenos y los otros presidentes del pp les están dejando en un feo, así que tiene que salir a cubrirse la espalda y de paso darles un toque de atención a los suyos para que se replanteen su estrategia (que ya ha derivado a cargar contra el gobierno central); hace no tanto hubieran deseado "algo" de inmigración para tener la excusa de pedir pasta al gobierno central (cosa que han hecho en todos los frentes, incluso han renunciado a su tan cacareada bajada de impuestos, lo que les hizo subir al poder), pero es que lo que les ha caído desborda a cualquiera. No hace tanto criticaban mucho al gobierno anterior (y aún lo hacen, ya sabes, la herencia recibida)...
<<“Eso sí, lo que hace una y otra vez [el anterior presidente, Ángel Víctor Torres] es mendigar y criticar a las demás comunidades autónomas, sobre todo a las de Partido Popular, por la acogida de menores inmigrantes”, indicó Domínguez, quien añadió “pero se le olvida mencionar que fue el Gobierno de Sánchez, en mayo de 2021, el que se comprometió a alcanzar un acuerdo con todas las administraciones en un plazo de dos meses para la integración de los menores no acompañados”.>>
O sea, los del pp como siempre bloqueando cualquier medida de solidaridad con los demás, pero ahora como les toca sufrirla están en plan "que soy compañero, coño".
m.youtube.com/watch?v=FdzbPX8vrec&pp=ygUNbm9zZmVyYXR1IGJvYw==