Linus Torvalds tira de la anilla y lanza la granada: "x86 ha ganado, olvidaos de ARM en servidores" [ENG]

"Algunas personas piensan que'la nube' significa que el conjunto de instrucciones no importa", dijo Torvalds en un mensaje en el foro. "Desarrollar en casa, desplegar en la nube. Eso es una estupidez. Si desarrollas en x86, entonces vas a querer desplegar en x86, porque podrás ejecutar lo que pruebes `en casa' (y por `en casa' no quiero decir literalmente en tu casa, sino en tu entorno de trabajo)".

[#9 yarkyark]

#6 No. No he dicho compilación a bajo nivel. He dicho compilacion cruzada a bajo nivel. No manipules lo que digo. Y deberías saber que me refiero a los lenguajes de bajo nivel, visto el nivel de suficiencia con el que respondes.

"Además realizar una compilación cruzada no tiene ningún misterio. "

A bajo nivel cuando los procesadores usan conjuntos de instrucciones diferentes si es mucho mas compleja de realizar.

Pero oye, que dado que lo tienes todo controlado vete a los foros en los que escribe Torvalds y corrigele.

[#3 yarkyark]

#1 Nada, pero ¿conoces a alguien que use ARM en el escritorio?

Aparte que la compilación cruzada a bajo nivel es mucho mas compleja de realizar.

Al final lo que usas en el escritorio también condiciona lo que se usa en los servidores. (o por lo menos eso es lo que viene a decir Torvalds).

[#22 pip]

#2 bueno, ha dicho que es una estupidez y se ha mordido la lengua antes de decir que son todos una panda de hijos de puta

[#2 Desactivado]

¿Lo ha dicho sin insultar a nadie?

[#16 Desactivado]

#10 Pero para Android y iOS no puedes elegir. En los servidores si. Y puestos a elegir, prefiero evitarme capas de emulacion y desplegar los mismos binarios que verifico en mi portatil. Por no hablar de que gcc siempre va por delante en x86.

[#19 Nathaniel.Maris]

#12 En casa las tablets serán ARM, pero dudo mucho que triunfe un cacharro arm de escritorio fuera de eso, hay algo que tiene mucho mucho mucho peso y son los juegos, la mayoría de gente metida en IT echa sus partidas a cosas en los ratos libres y de igual forma que Windows predomina en el escritorio, x86 va de la mano.
(Por mucho que exista Windows 10 arm)

[#61 albandy]

#4 más bien lo que acaba de demostrar es que tu de Torvalds sabes poco.
Y te lo dice un linuxero desde los 16 y tengo 38.

[#4 samsaga2]

#2 Vienes a aportar algo positivo o sólo a reírte de la gente.

[#41 uno_ke_va]

#9 a ver, realizar una compilación cruzada no tiene ningún misterio. El problema es que o compilas para el target y pruebas en remoto, o compilas para el host y pruebas en local con lo que puede haber problemas que no detectes al ser entornos distintos.

Trabajar así se lleva haciendo desde que el mundo es mundo, aunque si no hay restricciones raras del proyecto lo lógico es desarrollar y desplegar en entornos similares por pura comodidad, que creo que es a lo que se refiere Tolvards.

[#17 mgm2pi]

#9 releyendo mi mensaje si que suena un poco mal, no era esa mi intención, sólo pretendía debatir un poco.
Yo creo que si dispones de hardware puedes sin ningún tipo de problema desarrollar en x86 y probarlo inmediatamente en ARM. Es un poco más ortopédico pero vamos no creo que sea ese el motivo que lleve a ARM a no triunfar en servidores

[#45 EspañoI]

#6 conoces poco entonces. #9 está totalmente en lo cierto.

Cross compiling es desarrollar ejecutables en un entorno distinto a nivel arquitectura.

Cada vez que se desarrolla una aplicación de smartphone se debe probar en el mayor número de arquitecturas posibles para garantizar su funcionamiento, porque programas en una máquina con un set de instrucciones totalmente diferente. Hay que emular el procesador y compilar para esa instancia.

Emular un smartphone es relativamente fácil, pero un servidor suele ser más potente que un desktop, por lo que se desarrolla en la misma plataforma que el servidor receptor del código.

Es difícil ver un escenario en el que el desarrollador y el servidor sean ARM, al menos en el futuro inmediato.

[#89 empanadilla.cosmica]

#2 A mi también me ha sorprendido.

#4 De hecho hace algún tiempo dijo que todos los que desarrollan SoC ARM merecían morir.

#61 Para mi que Linus se esta haciendo viejo. Es complicado estimar la edad de un finlandés. Son tan rubios que pueden tener mogollón de canas y se nota poco. Y de hecho hay hombres y mujeres que desde la adolescencia tienen el pelo gris y se lo tiñen de rubio.

[#13 Desactivado]

#9 Estoy con #6. A que narices te refieres con compilacion cruzada a bajo nivel? Compilacion es compilacion. Cruzada ya se refiere a que estas compilando para una arquitectura y/o procesador diferente.

[#20 yarkyark]

#17 Bueno, eso no te lo discuto. Pero es que ese no es el argumento que expone Torvalds.

En realidad la conclusión que yo saco de lo que dice Torvalds es "la comodidad" y mal que nos peses algo de razón tiene.

[#10 bewog]

#3 claro, porque todo el mundo que desarrolla para Android e iOS lo hace con arm... Con la cantidad de paas que hay, arm entrará el servidores si mejora en precio y costes a x86, no hay más.

[#11 crateo]

#3 hombre, teniendo en cuenta que prácticamente él 95% de los servidores usan Linux igual es relación entre escritorio y servidor que dices no es del todo correcta .

En realidad a la inmensa mayoría de los desarrolladores les da exactamente igual la arquitectura del servidor, pero el amigo habla de desarrollo de bajo nivel.

Para todo lo demás, máquinas virtuales y middleware.

[#53 pip]

#38 bueno para que te importe la CPU a nivel de implementación tendrás que bajar un poco más abajo, a nivel de intrínsecos de C o directamente ASM.
En principio incluso en C deberías de estar razonable aislado de la CPU como para que no te importe a nivel de implementación, ese código que pones de ejemplo es muy raro (sería en todo caso con #if preprocesador).

Pero el problema no ese. El problema es que hay bugs que en una arquitectura no se manifiestan y otra sí, porque el layout de memoria es diferente, porque el código máquina es diferente, o porque las librerías de las que dependes son diferentes.

Quiero decir a lo mejor tu programa es perfecto, pero dependes de la librería A que depende de B y resulta que B tiene un bug en ARM que acaba en un segment fault.

Cuando trabajas en software un poco crítico lo que quieres es que todo el SO y todo tu conjunto de librerías, compiladores y en general todo sea idéntico, cualquier otra cosa te mete una capa de complejidad que si no la necesitas mejor quitarla.

[#28 minossabe]

Me parece que sin decirlo explícitamente está cargando contra la filosofía "todo en la nube, servidor en la nube, aplicaciones en la nube" y dando a entender que los servidores seguirán rehuyendo este tipo de soluciones para seguir dentro de x86. Al final, las capas de emulación y los peajes varios que pagas en cloud hacen que optimizar recursos también sea importante.

[#48 Desactivado]

#27 desplegar por deployar.

[#77 crafton]

#4 #moralWarrior

[#5 Desactivado]

Estoy de acuerdo con Linus

[#30 pip]

#23 hombre creo que Linus está al tanto de lo que son los lenguajes interpretados, y sigue teniendo razón porque tu programa Python cuando lo ejecute el intérprete de ARM puede tener bugs que en x86 no tiene.
Puede que el riesgo sea bajo pero no es nulo.

Ejemplo: https://bugs.python.org/issue34957

[#81 yarkyark]

#79 Estamos hablando de programación de sistemas operativos. Ahí si hace falta compilar.

Otra cosa es para el desarrollo de aplicaciones.

[#24 bewog]

#16 eso si tienes que elegir, pero si eliges una base de datos gestionada como rds, a ti te da igual en que arquitectura este implementada, tu vas a hacer inserts y querys, y la arquitectura sobre la que corra da igual. Ya se preocupara Amazon, azure o Google de buscar la plataforma más barata y eficiente.

[#31 slow_biker]

#14 y muchos fabricantes harán lo mismo en cuento se pasen los grandes, MS ya tiene versiones de windows para ARM igualmente google tiene más interés en arm que en intel,
para las empresas de hw asiaticas puede suponer una ventaja competitiva enorme no depender de un dinosaurio como intel y poder fabricar sus propias versiones de CPU/GPU a menor precio y con mayor rotación tenológica como ya se está haciendo para los móviles,
Ahora mismo el hw que más se vende son móviles pero es un mercado que está saturado pero eso puede cambiar en cuanto a alguien se invente un nuevo gadget.

[#88 Desactivado]

#46 Obviamente, durante ese tiempo Intel se va a quedar tumbado en la bartola y no va a investigar incrementos de potencia, de escalabilidad, de paralelismos, reducciones de consumo,...

De verdad, leyendo menéame a veces tengo la sensación de que he sido abducido a un mundo paralelo.

[#15 yarkyark]

#11 Creo que se sobreentiende que hablo de programación de bajo nivel. Pero por lo que veo no se ha entendido.

Lo digo mas claro: "La compilación cruzada en los lenguajes de bajo nivel que se usan en la programación de sistemas operativos donde se usan conjuntos de instrucciones diferentes en procesadores de arquitecturas diferentes es mas compleja".

[#60 higochungo]

#8 Dios mío. Que ignorante.

[#40 darkdead4]

#12 Apple es experta en colarte una placa sin IO's o vender cpu 2 generaciones por detrás o diseños capados en potencia.
La cpu es importante pero los chipsets también y ARM en ese sentido va por detrás.

[#73 pip]

#71 todos los hijos de puta de lo políticamente correcto de los cojones, están estropeando a un hacker de puta madre, como Linus

[#6 mgm2pi]

#3 ¿compilación a bajo nivel? sólo conozco un tipo de compilación.
Además realizar una compilación cruzada no tiene ningún misterio.

[#55 DangiAll]

#1 Yo creo que lo explica en la noticia, los programadores usan equipos X86 para el desarrollo y testeo de las aplicaciones que luego querran usar en una nube x86 tambien.

No es que les impida desarrollar en ARM, es que si todo lo que tocas es x86 para que matarte con los ports.

[#78 EspañoI]

#59 pues sí, leyendo tus comentarios veo que algo controlas , pero vaya que laccompilación cruzada existe desde los tiempos del Z80, se me hace raro que no conozcas el término.

De hecho si empaquetas blobs para routers, lo que haces es precisamente una compilación cruzada.

[#159 Jakeukalane]

#15 gracias.

[#85 xenko]

#22 es el Perez Reverte de la informática.

[#133 darkdead4]

#69 El problema es que un movil es un soc all in one y un servidor /desktop suelen tener la mala leche de necesitar buses como pci express con lanes que un chipo ALL in one no dispone.
Los ARM desktop son un pelin penosos en especto cosas como sata 2 y pci express 1x

[#64 Desactivado]

#31 Windows para ARM. Ah, sí, ya lo recuerdo. Se llamaba Windows RT ¿no?

[#142 crateo]

#15 no, no, si yo lo entendí así. Cuando hablaba de él amigo, hablaba de Linus.

[#23 xizor]

Pues creo que esta vez Linux se equivoca porque la mayoría de lo que se pone "en la nube" está escrito en lenguajes interpretados. Puede ocurrir alguna cosa por cambiar de juego de instrucciones, pero me parecería muy, muy raro. Un mundo de servidores ARM será más lento, pero como será más barato para el que pone el ordenador, al final los servidores de la nube serán ARM.

Aunque tengo la sensación de que la gente está suponiendo muy pronto que en Intel, AMD o NVidia se van a quedar quietos. Es como si unos fulanos que llevan 20 años haciendo chips para teléfonos fueran a quitarle la tarta a unos fulanos que llevan haciendo procesadores 50 años para llevar cosas al espacio de forma inevitable...

[#25 yarkyark]

#21 Pues no y a la mayor parte de los mortales tampoco nos afecta. Solo afecta a los desarrolladores de servidores, principalmente linux.

[#46 gonas]

#3 A ARM le falta mucho para que se popularice en el escritorio o un servidor. Pero al final se impondrá. Aunque pueda tardar 10 ó 20 años.

[#83 pip]

#75 tienes razón, me ha quedado pedante de cojones. Mis disculpas, era solo ociosidad.

[#50 pip]

#48 tienes razón, no me salía en ese momento la palabra en castellano, en mi empresa somos de decir deployar, debugear, comitear, mergear, etc
Sabemos que está mal pero aún así lo hacemos, quizás porque se le añade un matiz de precisión técnica que igual el castellano no tiene.
Llámalo jerga...

[#59 mgm2pi]

#45 si lees mis siguientes mensajes, a lo mejor no me dices que no conozco mucho del tema.
Llevo más de diez años desarrollando drivers y BSP para ARM de forma profesional, algo del tema sí que sé, otra cosa es que no haya entendido bien el mensaje o no me haya explicado bien.

[#75 Opinator_2.0]

#53 He puesto un ejemplo para aclarar un poco en qué puede consistir hacer un código que funcione en varias arquitecturas en un lenguaje cualquiera, y tú vienes a dar una chapa en plan "yo sé más que nadie y te puedo dar mil detalles técnicos".
Pues vale. Mis dieses.

[#38 Opinator_2.0]

Si ya de por sí es muy jodido programar a bajo nivel, imaginaos la pesadilla:
if (cpu == X86)
else if (cpu == ARM_SU_PTA_MADRE)

[#65 Desactivado]

Este año es el año de Linus en el x86

[#66 llorencs]

#45 Una Raspberry no es ARM? Puedes desarrollar en Ella.

[#68 llorencs]

#67 Es la misma plataforma, no? 😃

Ahora, mi punto es que sería posible, no que lo sea ahora mismo. Puedes montar una Pi mas potente y orientada a escritorio. Pero una Pi ya te permite hacer cosas, imagínate algo un poco mas potente.

[#74 blid]

#68 En ese sentido sí, pero no es lo suficientemente potente. Para desarrollar necesitan un buen equipo que te permita tener el IDE corriendo, servicios, y un montón de cosas más. Yo desarrollo para Cloud, con un Xeon de los últimos + 64GB de RAM, SSD-M2... y a veces, le cuesta.

[#84 Desactivado]

#74 tendrías que ir a esto: https://e.huawei.com/en/products/cloud-computing-dc/servers/arm-based/taishan-2280-v2 o si Fujitsu saca a la venta equipos con el A64FX.

[#95 empanadilla.cosmica]

#92 Pues eso. El kernel no es interpretado, todo el código que está en el hardware como firmware de casa dispositivo casi seguro que no es interpretado, el intérprete tampoco es interpretado...

Vamos, que depende de lo que hagas. Hay cosas en las que casi todo es interpretado ¡hola fronend! Y lugares donde todo es compilado, a veces incluso desarrollado directamente en ensamblador o lenguajes muy cercanos a la máquina. ¡Hola, sistemas empotrados! Y otros lugares en los que hay de todo.

[#96 Desactivado]

#90 lo de ahora, terminales ligeros sobre servidores con máquina virtual sobre servidores presumiblemente más baratos y que balancea mucho mejor la carga y el consumo de energía hasta la sustitución a contenedores que puedan correr de forma nativa, para correr aplicaciones nativas ya están, es su presente.

[#43 Libertual]

Los ultimátums no funcionan.
Yo quiero desarrollar una vez y que funcione en todas las plataformas.
Con la fama de bocazas que tiene Torvalds no me lo tomaría muy en serio.

[#56 array]

#15 Yo te entendí desde el principio hermano, no sufras.

[#67 blid]

#66 Vas a desarrollar software para un servidor en una PI. Claro que sí.

[#131 Razhan]

#15 yo también entendí que te referías a eso. Si escribo código en algo como java, pues como que posiblemente me importe menos la arquitectura de destino que si escribo ensamblador

[#26 RubiaDereBote]

#19 Resuélveme una duda: hablas por ti o has visto mucho IT Crowd (o sucedáneos similares)?

[#70 EspañoI]

#66 claro que si Guapi! Ahora compila en una RPi el ejecutable que va a rular en un Xeon de 16 núcleos.

[#112 Desactivado]

#89 Tiene 49 años.

[#165 slow_biker]

#154 tu me dirás: al paso que va la innovación y teniendo en cuenta que lo más novedoso que nos deparan los móviles es que van a ser plegables la cosa está clara.

[#14 lutxo25]

#3 Parece que Apple se puede pasar a ARM en sus Macs

https://computerhoy.com/noticias/tecnologia/apple-cambiara-procesadores-intel-mac-procesadores-arm-2020-378957

[#32 mgm2pi]

#20 hablando de desarrollar con dispositibos enbebidos, ya ni se nota si estas desarrolando en tu maquina o en una remota con un IDE + gdb server + ssh.
Si económicamente sale rentable ya se harán cosas para que sea igual de comodo.

[#71 Desactivado]

#22 una pena... Yo pensaba que había vuelto!!
Y creo, espero y deseo que vuelva. Al final la cabra acaba tirando al monte, SIEMPRE.
https://thumbs.gfycat.com/WhiteAllGannet-small.gif

Enserio, le echo MUCHO de menos

[#82 anv]

Opino que Linus olvida que a nivel empresarial lo que más se usa son lenguajes interpretados (Python, Perl, PHP, node.js o Java). En ninguno de esos casos importa la arquitectura del procesador.

[#132 Razhan]

#46 falta, si. Pero con AWS ofertando arm y si apple migra, tienes dos movimientos que pueden mover el mercado

[#140 Hopo]

#70 Efectivamente, es todo el software stack encima de x86 lo que dificulta la posible migración a otras arquitecturas no solo la ISA.

Alguien se acuerda cuando Intel intentó entrar en el mercado de smartphones? Se comió los mocos. Porque? Porque no es facil migrar todo un software stack a otra ISA por el mero hecho de hacerlo.

[#175 Desactivado]

#174 Pones a Risc-V como alternativa cuando no deja de ser ni mínimamente implementado, ni siquiera de forma seria en FPGA, muy bien. Sobre SPARC, el T8 parece trabajar bien, pero del ultimo trimestre de 2017 y 20 nanómetros, 7 nanómetros, por ahora cosa de GPUs, FPGAs y ARM, incluso para procesadores en mercado de servidores, el primer 10 nanómetros es ARM, y es de la misma fecha que el T8: https://www.qualcomm.com/products/qualcomm-centriq-2400-processor
Sobre potencia: https://www.theinquirer.net/inquirer/news/3061552/fujitsu-details-a64fx-arm-cpu-ahead-of-post-k-supercomputer-debut

Creo que crees que tengo especial fijación por ARM por algo en especial, me encantaría que una arquitectura abierta triunfara y realmente no ARM me parece esencialmente mejor, sencillamente es la arquitectura menos estancada y por eso parece que se va a a salir del mercado de móviles o tabletas para otros equipos por simple traspaso tecnológico, va a ser más fácil meter 40.000 millones de transistores en un SoC ARM de CPU puro(sin GPU) que en x86 porque donde hay más dinero para el desarrollo es en ARM, simplemente hay millones de procesadores que van a dar el salto a 20.000 millones de transistores en un móvil.

[#27 pip]

Es lógico que si desarrollas en x86 quieres deployar en x86, si puedes.
Las cosas fallan, a veces un binario compilado para una arquitectura no funciona para otra, incluso no funciona por cambiar la versión del compilador.

Idealmente debería funcionar, pero en el mundo real hay bugs que se manifiestan por esos cambios.

Vamos, que si no lo necesitas o no te queda otra, el desarrollar en x86 para luego ejecutar en ARM es mejor evitarlo.

[#35 XrV]

#19 yo soy un ferviente defensor de la convergencia. Llegará el dia que usaremos el teléfono para el escritorio con algún dispositivo tipo samsung DEX. Entonces veremos de que forma se compatibiliza el desarrollo de x86 sobre plataforma arm.

[#49 Desactivado]

#39 a grandes requisitos de rendimientos hay procesadores monstruosos de ARM como los Huawei para servidores por seguir la noticia o los de Baidu para conducción autónoma, por poner procesadores con requisitos diferentes.

[#52 XrV]

#39 arm relación calor-consumo/potencia son más optimos que x86. El tema es que necesitas meter el doble, pero son mucho mas baratos y su consumo te da un ahorro brutal.
Si no se usa es porque la arquitectura mas madura es x86, pero en 15 años ya veremos.

[#62 DangiAll]

#29 Apple buena herramienta de desarrollo ? Eso sera si quieres desarrollar para OSX o para IOS.
Linux esta muy por delante en desarrollo de aplicaciones.

[#42 foxaxel]

#21 pues depende lo que metas en el docker. Si metes dependencias de sistema pues te afecta. Si solo metes código Python como te dice #33 pues mayormente no.

Las images te las bajas para x86, no todas las puedes poner en la RPi por ejemplo

[#80 Desactivado]

#73 totalmente de acuerdo. Y me jode muchísimo.
Y ojo, que no creo que haya que llegar a tales extremos, pero cierto es que con presión muchas veces se rinde mejor y que en ciertos sectores, cómo es el caso de Linus, estás trabajando PARA EL PUTO KERNEL DE UN SISTEMA OPERATIVO. Es decir, de hacer BIEN tu puto trabajo, depende prácticamente el mundo entero de la IT. No estás haciendo una app de mierda para niños rata pajeros. Es el puto Kernel. Si la cagas, creo que no está de más un poquito de caña.
Hay que saber encajar los golpes cuando sabes, pero sobre todo cuando no sabes y cuando eres un puto paquete. Y si no te gusta que Linus se cague en tus muertos por qué eres un inútil, pues coges la puerta y te piras

[#173 anv]

#167 Pues mira... podemos hacer rápidamente una prueba con php que es uno de los intérpretes más usados últimamente.
Hagamos este programa:

[#33 XrV]

#21 los binarios ejecutan unas instrucciones que entiende cada tipo de arquitectura de cpu. Docker sobre arm tiene que ejecutar binarios que hablen las instrucciones de arm. Si programas en php o python mayoritariamente te va a dar igual.

[#104 Jakeukalane]

#93 yo me vi la conferencia entera de cuando dijo lo de NVIDIA fuck you y fue muy entretenida. Supongo que depende del nivel de cabreo basal de cada uno.

[#105 Jakeukalane]

#37 de las empresas que dominan un mercado*

[#106 Jakeukalane]

#65 llegas tarde. El mercado de servidores lleva dominado por Linux tiempo ha.

[#113 Desactivado]

#50 Vamos que en tu empresa no tenéis ni puta idea de hablar.

Luego pasa lo que pasa: Venís aquí a Estados Unidos y os daís cuenta de que ni los americanos os entienden ni tampoco los hispano-parlantes.

Me recuerdas a una compañra dominicana que siempre dice: Se me frisó la computadora.

[#155 Jakeukalane]

#9 #41 ¿y qué significa eso que decías/decían de compilación cruzada a bajo nivel? un saludo, gracias.

[#158 Conde_Lito]

#83 Así en conjunto no veo que te haya quedado para nada pedante lo que has escrito, ya me gustaría que la gente por aquí fuera igual de pedante y le diera por aclarar y explicar las cosas como lo has hecho tú.

[#134 JanSmite]

#3 Intel confirma que Apple cambiara la CPU de sus Mac en 2020 [Ing]

Intel confirma que Apple cambiara la CPU de sus Ma...

[#148 yarkyark]

#119 goto #9 y #15

El que parece que no lo has entendido eres tu.

[#157 yarkyark]

#155 goto #15

[#47 gonas]

#3 A ARM le falta mucho para que se popularice en el escritorio o un servidor. Pero al final se impondrá. Aunque pueda tardar 10 ó 20 años.

[#12 eldelmedio]

A lo mejor su razonamiento es válido pero olvida que cada vez está más cerca la situación de que "en casa" lo que haya sea un ARM. Por otro lado leo que Apple pretende sacar portátiles con ARM, sin ir más lejos.

[#29 eldelmedio]

#19 Como decía, no me lo invento, lo he leído en otro lado: https://www.elotrolado.net/noticia_apple-ya-ultima-la-migracion-de-algunos-de-sus-ordenadores-a-arm-segun-fuentes-de-la-industria_39562
Y cuidado, que si Apple lo hace entonces ya es cool y otros pueden venir detrás, por no decir también que los Apple son buenas herramientas de desarrollo.

[#37 u_1cualquiera]

#23 es como suponer que Apple, que llevaba 0 años haciendo teléfonos le fuera a quitar el pastel a Nokia (ya sé que no fue solo Apple, pero entiendes la simplificación ), que llevaba 20a
Nunca subestimes la capacidad de auto complacencia de todas las empresas

[#44 eldelmedio]

#40 Sea esto cierto o no, le funciona, ¿verdad?

[#90 blid]

#84 Y en estos casos, ¿que haces con todas las herramientas que usamos que están hechas para x86-64? El coste de esos equipos y la migración que supondría hacer todo eso, dificilmente valdrá la pena. Lo veo complicadete.

[#107 frankiegth]

#22.

[#136 emdi]

Arm se centra en el consumo por eso ha triunfado en dispositivos moviles. Los procesadores para servidores se centran en la fiaibilidad y el rendimiento.
La programación a bajo nivel y me refiero al nivel de programar un driver para una grafica o para un disco es compleja y nada tiene que ver con la programación de alto nivel o lenguajes interpretados.

[#138 emdi]

#130 si no has visto un buffer overflow es porque el que ha programado a bajo nivel la maquina virtual lo ha hecho bien.

[#143 emdi]

#141
Yo creo que arm es mejor en rendimineto. Arm a dia de hoy no puede competir con un simple x86_64 doble nucleo que va a casi 4GHz.
Rendimiento me refiero rendimiento bruto. Y fiabilidad me refiero a fiabilidad del hardware ante fallos, que tenga bugs es otra cosa.

[#152 Desactivado]

#86 Si lo piensas, no hace tanto tiempo, la potencia que tiene una RPi era la que tenías en un sobremesa o, yendo un poco más para atrás, un servidor. Pero es que la RPi no es precisamente el buque insignia de ARM.

[#154 Desactivado]

#31 ¿Te parece invento nuevo el meterle navegadores y demás a los coches?

[#156 Desactivado]

#91 O en el momento en que Apple se pase totalmente a ARM y empiecen a sacar procesadores sin los límites de los smartphones, tirando de ventiladores en lugar de refrigeración pasiva, sin tener que limitar la potencia consumida, ...

[#161 Desactivado]

#6 Por experiencia, la compilación cruzada no siempre es trivial. Me explico: hace unos años trabajé en un proyecto en el que desarrollábamos software para un cacharro con un micro raro, y necesitábamos tener webkit en él. La cuestión es que el fabricante sólo nos daba una versión concreta que no nos servía, por lo que teníamos que usar compilación cruzada. Usábamos una gentoo y sus herramientas, pero el problema era que la versión de webkit que necesitábamos no estaba disponible en gentoo, y cada vez que intentábamos nosotros hacer una compilación cruzada con las autotools, siempre fallaba en algún punto.

Al final desistimos, montamos el compilador en la propia placa y compilábamos sobre ella. Un día y pico necesitábamos para compilar una versión, pero al menos funcionaba.

Por eso no diría que la compilación cruzada no tiene ningún misterio: coger el gcc y decirle que te compile un fichero en C para otra arquitectura puede ser trivial, pero cuando tienes que compilar código que usa autotools o cmake puede ser una pesadilla. Por experiencia.