meneandro

#20 En un primer momento dijeron que era por un tema (indeterminado) de calidad y que querían asegurarse y hacer más pruebas:

https://arstechnica.com/gadgets/2024/07/quality-issue-pushes-amds-ryzen-9000-cpu-launch-from-july-to-august/

Puede que lo del etiquetado fuese coincidencia... o que han aprovechado para hacer un poco de márqueting a costa de Intel. Quien sabe...

#1 #2 #7 #8 Haced caso a #43

Este titular lleva a confusión, se puede pensar que habla del driver de las tarjetas gráficas y sólo es una parte concreta. De hecho, esto no lo hace un driver libre. Eso sólo es un componete que simplemente empata las cosas con los drivers cerrados de AMD en cuanto a "libertad", o sea, la parte integrada en el kernel libre y abierta para que sea distribuído libre y abierto, mantenido y actualizado constantemente, el resto del driver cerrado a cal y canto, sólo accesible vía la distribución del fabricante, con funcionalidades cerradas, etc.

Se trata de la parte de kernel que forma parte de los drivers, un cacho de lo que en los antiguos drivers de nvidia tenías que compilar cada vez que actuaizabas a una versión nueva de kernel (que antes se tenía que hacer a mano reinstalando los drivers, luego con DKMS se hacía automáticamente porque se enganchaba a cada actualización y se hacía sin intervención del usuario). El que haya sufrido que de pronto el ordenador no te arrancara, no te pasara de la consola de texto o salieran todo tipo de problemas gráficos sabrá de lo que hablo.

La ventaja es obvia, en lugar de tener un módulo de kernel con un montón de código y unas interfaces genéricas que tenían que compilarse para cada nueva versión de kernel, ahora esta parte está integrada en el kernel, con lo que las actualizaciones de la máquina ya no te van a romper nada y la calidad del soporte de drivers y nuevas funcionalidades en linux no afectarán como antes a las gráficas nvidia.

Ahora, sólo es un componente. Todo lo que está fuera del kernel (la parte del driver que "toca" el hardware"), sigue siendo completamente cerrada. O sea, ahora nvidia sigue el mismo modelo que los drivers cerrados de AMD desde hace muchos años.

Todo lo que tenga que ver con sus tecnologías propietarias y cerradas seguirá siendo propietario y cerrado. Todo lo que tiene que ver con computación o IA o tecnologías para juegos. Esto sólo es un cambio convenientte para nvidia (y también para los usuarios, pero como "daños colaterales") y que tarde o temprano iba a realizar. Que siga adelante y empiece a abrir otros componetes sería genial, pero muy dudoso.

La otra ventaja que tiene esto es que actualmente los drivers abiertos que antes funcionaban de aquella manera por falta de documentación, ahora tienen una base completamente funcional sobre la que trabajar, será más fácil desarrollarlos y tendrán acceso a las funcionalidades de nvidia que antes sólo podían ver desde lejos, empezando por la gestión de energía (importante porque el control de voltajes y temperaturas es lo que hace que puedas "darle caña" al hardware convenientemente y sacarle rendimiento, cosa que en muchos modelos de tarjetas de nvidia no podían arriesgarse por poder freír las tarjetas y tenían valores seguros pero que permitían rendimientos muy mediocres).

Pero vamos, buena noticia, lejos de ser LA NOTICIA que vende el titular.

#31 pues no sé qué decirte, sigue las mismas políticas de siempre. Esto del módulo de kernel abierto simplemente es modularizar, facilitarse la mantenibilidad e integración con el código de linux y poco más. Para hacernos una idea, ni siquiera se puede usar en otros unix, así que los drivers cerrados de nvidia seguirán existiendo o empezarán a dejarlos sin soporte (que la gente porte de su driver de linux a otros unix si quieren).

#24 ¿Tienes el vsync desactvado o algún problema con freesync? ¿estás en x11? muy extraño lo que comentas... yo tengo una 6600 y nunca he llegado a ver problemas de sincronización con mi monitor, incluso a grandes frecuencias.

#55 vaya pedazo de respuesta. Muchas gracias.

#55 vaya pedazo de respuesta. Muchas gracias.

#46 A un SteamOs más directo, quiero poder gestionar el 99% con el mando y olvidarme de lo demás.

#59 en las sociedades socialistas era igual ,los viejos edemas no tenian nada

#85 Otro negativopor mentiroso, en la URSS si habia sistema de pensiones

#88 https://www.nytimes.com/1978/11/19/archives/pension-system-in-soviet-leaves-many-of-the-aged-impoverished.html

#110 Una cosa es que elssitema falle y otra muy diferente lo que tu mientes, que "no habia", eso es literalmente has dicho y no es cierto ni en este caso ni en el de China

#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.

En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.

#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.

La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.

#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

#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/[email protected]/
https://lwn.net/Articles/954941/

La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado:

#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...

#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.

En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.

#64 tú y el grueso de los consumidores quieren que sea así, quién fabrica puede querer lo contrario y pagar el desarrollo, sea propio o por una empresa externa como Sifive o Andes, para lo contrario. Por mucha filosofía que pongas el que paga manda, y si la clientela no va a castigar el caos de la incompatibilidad a propósito, ya que eso se premia en la obsolescencia, la evolución de compatibilidades a a ser peor que ARM.
Por eso openrisck, opensparck y otras que depende de una sociedad superior que es de arquitectura abierta aparte de una ISA abierta no se tocan.
Que hay núcleos y algunas arquitecturas abiertas en risc-v si, que Andes o Sifive tienen su arquitectura propia también.

#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.

Si no me crees a mi sobre lo de riscv, léete esto:
https://www.kernel.org/doc/html/v5.12/riscv/patch-acceptance.html

"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.


Compara con el infierno que es ARM, lleno de documentos de SOCs específicos e incompatibles entre si en mayor o menor medida:
https://www.kernel.org/doc/html/v5.12/arm/index.html

Al menos ARM64 está mejor organizado y saneado (de hecho, RiscV parte un poco de esto y lo mejora para su arquitectura):
https://www.kernel.org/doc/html/v5.12/arm64/index.html

#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.

La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.

#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

#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/[email protected]/
https://lwn.net/Articles/954941/

La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado:

#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...

#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.

En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.

#17 nada legal impide que mierdas sean mucho peores en risc-v y por nada es que los que están poniendo dinero precisamente es la característica que están vendiendo, modifico mi IP core para vendertela y hacer el sistema incompatible con otros clientes a los que les vendo mi IP, lo que viene a ser «configuracion y personalizacion».

#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.

#64 tú y el grueso de los consumidores quieren que sea así, quién fabrica puede querer lo contrario y pagar el desarrollo, sea propio o por una empresa externa como Sifive o Andes, para lo contrario. Por mucha filosofía que pongas el que paga manda, y si la clientela no va a castigar el caos de la incompatibilidad a propósito, ya que eso se premia en la obsolescencia, la evolución de compatibilidades a a ser peor que ARM.
Por eso openrisck, opensparck y otras que depende de una sociedad superior que es de arquitectura abierta aparte de una ISA abierta no se tocan.
Que hay núcleos y algunas arquitecturas abiertas en risc-v si, que Andes o Sifive tienen su arquitectura propia también.

#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.

Si no me crees a mi sobre lo de riscv, léete esto:
https://www.kernel.org/doc/html/v5.12/riscv/patch-acceptance.html

"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.


Compara con el infierno que es ARM, lleno de documentos de SOCs específicos e incompatibles entre si en mayor o menor medida:
https://www.kernel.org/doc/html/v5.12/arm/index.html

Al menos ARM64 está mejor organizado y saneado (de hecho, RiscV parte un poco de esto y lo mejora para su arquitectura):
https://www.kernel.org/doc/html/v5.12/arm64/index.html

#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.

La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.

#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

#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/[email protected]/
https://lwn.net/Articles/954941/

La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado:

#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...

#17 yo hablo de mejores prestaciones no de filosofía tecnología

#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 productos específicamente optimizados para ninguna arquitectura y verás que el consumo para hacer las mismas tareas está equilibrado o incluso es menor en la solución de amd). Y quitando apple, el resto de soluciones arm que han tratado de competir, no han podido (ya sea por compatibilidad/software, porque el rendimiento sin ser malo no podía compararse, etc). Del mismo modo, Intel también tiene soluciones que compiten de tú a tú con el resto en determinadas condiciones o para determinado software (optimizado).

Está claro que el problema es definir correctamente qué prestaciones necesitas y en qué entornos te mueves (soluciones de refrigeración púramente pasivas y limitadores de voltaje, etc. existen también en el mundo x86).

Volviendo al tema Risc-V, ya hay disponibles numerosas placas de desarrollo de dispositivos Risc-V, muchas más para probar cosas y desarrollar mientras se ponen al mercado productos realmente competitivos de nueva generación. Aún no ha salido un producto que sea killer usando RiscV, pero si hay alternativas relativamente competitivas respecto de algunos productos. Y RiscV tiene un importante papel en sitios donde menos pensarías. Por ejemplo, las gráficas NVIDIA tienen un controlador RISCV integrado desde 2016 que se encarga de hacer cosas que antes hacían los drivers por software, descargándolos y permitiendo bajar las latencias de ciertos procesos internos. Igualmente, todo es cuestión de pasta, se avanza más rápido cuanta más pasta tengas (que se lo pregunten a apple, por ejemplo, la pasta que se deja en desarrollar procesadores que sólo usan ellos, incluso comparada con la que se dejan fabricantes que venden y licencian sus procesadores a terceros, donde se juegan sus ingresos). A RiscV la apoyan empresas más bien emergentes (comparados con los monstruos que son los apple, qualcomm, intel, amd... y los fabricantes chinos). Y aún así, no están tan lejos en ciertas cosas comparados con "las grandes arquitecturas" y cada vez atraen más atención y recursos.

#2 Yo creo que la mejor explicacion sobre Risc-V que es y que implica, es esta serie de artiiculo. Por si alguien quiere ampliar informacion.
https://architecnologia.es/risc-v-introduccion-a-la-isa
#6 Basicamente libertad. Seguramente las ventajas se veran mas en el futuro que ahora. O el hecho de que haya una alternativa RISC-V puede evitar que lo fabricantes propietariios de las licencias abusen.

Explicacion Mas elaborada en #17

#14 Yo entiendo que no es obligatorio como se sepa como funciona el micro por dentro. Solo que como se interactua con él. Las instrucciones que se usan y qué hacen.

#22 Excelente artículo, muchas gracias.

#39 Es una serie de articulos, por si tienes interes en mas.

#40 Sí, ya lo ví. Gracias!

#15 #13 Licencias "absolutamente libres", con todas las consecuencias, como las MIT.
Cuando uno licencia sfw con una licencia "haz con esto lo que te salga del rabo", es normal que lo hagan.

#48 y cuando no, también. Con el tiempo se ha visto que el software libre no es la solución sino un parche. La solución es luchar contra las patentes de software y dar la propiedad a quien la haya copiado de manera que se pueda hacer lo que les dé la gana con la copia.

#52 Eso es otra guerra, que también.
Además viendo como evoluciona la cosa, a lo que se tiende no es a compraras un software o licencia de uso sino a contrataras un servicio que está disponible online.

#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).

#4 Así es. Estos países no prosperan porque las multinacionales y los estados serviles a las mismas, no les dejan directa o indirectamente. Un país necesita una generación en paz como mínimo para comenzar a desarrollarse. Las migraciones son el trágico efecto secundario de nuestro bienestar.

#20 En un primer momento dijeron que era por un tema (indeterminado) de calidad y que querían asegurarse y hacer más pruebas:

https://arstechnica.com/gadgets/2024/07/quality-issue-pushes-amds-ryzen-9000-cpu-launch-from-july-to-august/

Puede que lo del etiquetado fuese coincidencia... o que han aprovechado para hacer un poco de márqueting a costa de Intel. Quien sabe...

#55 vaya pedazo de respuesta. Muchas gracias.

#59 en las sociedades socialistas era igual ,los viejos edemas no tenian nada

#85 Otro negativopor mentiroso, en la URSS si habia sistema de pensiones

#88 https://www.nytimes.com/1978/11/19/archives/pension-system-in-soviet-leaves-many-of-the-aged-impoverished.html

#110 Una cosa es que elssitema falle y otra muy diferente lo que tu mientes, que "no habia", eso es literalmente has dicho y no es cierto ni en este caso ni en el de China