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

[#1 Desactivado]

Que el señor Torvalds disculpe mi ignorancia pero, ¿qué te impide desarrollar en un entorno ARM?

[#2 Desactivado]

¿Lo ha dicho sin insultar a nadie?

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

[#4 samsaga2]

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

[#5 Desactivado]

Estoy de acuerdo con 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.

[#7 danimourinho]

pero se le va a poder instalar el güasap?

[#8 txusmah]

Dios mío. Que importante

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

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

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

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

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

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

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

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

[#18 Sofrito]

Pero eso es como decir que Windows ha ganado en el escritorio, olvidaos de Linux.

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

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

[#21 Zade]

#3 y si usas docker esto te afecta en algo?

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

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

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

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

[#26 RubiaDereBote]

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

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

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

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

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

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

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

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

[#34 XrV]

#7 es provable que si a facebook le sale bien de precio cambiar a servidores arm la respuesta sea positiva. Mientras el cambio de arquitectura sea mas caro en desarrollo que roi en hardware no va a correr sobre arm... ah, que estabas troleando?

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

[#36 XrV]

#23 en estos mismos momentos, si usas apache sobre arm te da un tiempo de respuesta identico a su homonino en x86. X86 es necesario en cuanto a computo, pero para las tareas de un servidor web...

Si hablamos de otras tecnologias, te puedo garantizar que la balanza entre consumo energetico entre arm y x86 puede llegar a decantarse por la primera. Vaya si es que los microservers arm ya estan aquí (http://www.ambedded.com.tw/solutions.php?NT_ID=20140723004).

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

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

[#39 Kereck]

#35 Yo no estoy tan seguro de eso. Está claro que eso llegará para el usuario medio que no tiene grandes requisitos de rendimiento, pero para desarrolladores, diseñadores y jugadores medio serios la potencia necesaria siempre será la última diseñada, y los componentes primero se crean a un tamaño que permita su funcionamiento y luego ya se van optimizando y miniaturizando. Por no hablar de los temas de disipación de calor y tal, que ahí ya entramos en los límites que ponga la termodinámica.

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

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

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

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

[#44 eldelmedio]

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

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

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

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

[#48 Desactivado]

#27 desplegar por deployar.

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

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

[#51 manson2000]

#40 Los procesadores de Apple de Iphone van dos generaciones por detras??!!!

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

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

[#54 darkdead4]

#51 Sus pc's hasta hace nada tenia sus mac pro sin renovar es bien conocida por migrar a x86 precisamente por que sus chipsets eran una mierda vs el mercado general.

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

[#56 array]

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

[#57 Desactivado]

#19 "la mayoría de gente metida en IT echa sus partidas a cosas en los ratos libres" -> "Los 4 frikis windowseros que conozco yo"

[#58 DangiAll]

#31 Pues puede que en el mundo domestico se llega a ARM en un futuro lejano, en el empresarial no.

Si windows tiene un montón de mierda en su código para asegurar la compatibilidad con aplicaciones de hace 20 años, un cambio de arquitectura se pela esa compatibilidad.
Que se lo digan a OSX cuando se paso a x86, donde quedo todo el software anterior

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

[#60 higochungo]

#8 Dios mío. Que ignorante.

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

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

[#63 DangiAll]

#36 Si partimos que la base de ARM era limitar el consumo energetico, esta claro que consumen mucho menos que x86.
Siempre se puede volver a la vieja discusion RISC vs CISC

[#64 Desactivado]

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

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

[#67 blid]

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

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

[#69 manson2000]

#54 Pero eso no son procesadores ARM de Apple que es de lo que estamos hablando. En cuanto a procesadores ARM, los que tiene Apple de mancos nada.

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

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

[#72 Nathaniel.Maris]

#57 Si tu lo dices ...

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

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

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

[#76 slow_biker]

#58 casi todas las apps. empresariales estan en la nube, pocos utilizan ERP nativas, luego está el mundo del CAD, desarrollo y diseño donde los principales fabricantes ya están preparados para migrar. para aplicaciones anteriores tienen una capa de compatibilidad

[#77 crafton]

#4 #moralWarrior

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

[#79 anv]

#3 Yo tengo una objeción: los lenguajes compilados están quedando en desuso.

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

[#81 yarkyark]

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

Otra cosa es para el desarrollo de aplicaciones.

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

[#83 pip]

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

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

[#85 xenko]

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

[#86 empanadilla.cosmica]

#32 Pero estamos hablando de desarrollar para servidor. Ahora AWS tiene instancias ARM.

Obviamente para sistemas empotrados siempre vas a hacer compilación cruzada. Vamos, que yo no me veo desarrollando un microcontrolador AVR desde el propio AVR, por llevarlo a un caso extremo. Pero vamos, que tampoco me veo desarrollando desde un placa raspberry pi nada más grande qu un script en python para leer unos pines GPIO.

Desarrollo en mi portátil x86-64 y compilo donde haga falta. ¿O tu tienes una estación de trabajo ARM en la que puedas trabajar cómodamente, probar en local y luego desplegar a las instancias cloud de testing?

Que ni digo que en el futuro no las tengamos, pero de momento no veo estaciones de trabajo ARM en ninguna parte, aunque en uno de los comentarios del envío hay uno que dice que desarrolla directamente sobre ARM en local.

[#87 empanadilla.cosmica]

#79 Claro, y el intérprete es a su vez interpretado, y el kernel también es interpretado.

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

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

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

[#91 anv]

#81 Ah, si es el sistema operativo si... Pero el avance de ARM, so se da, será en servidores empresariales sobre todo.
En teléfonos y tablets ya ganó ARM y en escritorios está Windows. En cuanto Microsoft haga un trato con los fabricantes de PCs para impulsar Windows sobre ARM, en cosa de unos cuantos años podemos llegar a tener un número importante de escritorios con ARM.
A nivel de empresas, como dije, se usa generalmente lenguajes interpretados así que usar servidores ARM no supondría un problema. ¿Por qué no se hace? Porque a las empresas no les preocupa mucho el consumo de energía que es en donde destacan los ARM. Lo que más importa son las presentaciones.

[#92 anv]

#87 No. El intérprete funciona si te un Linux que ya está disponible desde hace muchos años para ARM.

[#93 empanadilla.cosmica]

#80 No se si has estado en una confererencia con el, así como a cinco metros de él, pero ya te digo que las ganas de meterle una hostia eran enormes.

El menda es como un compendio de humor británico que a todo el mundo le gusta hasta que las bromas las hacen sobre uno mismo. Y si solo se limitarse a hablar de las cosas que sabe pues vale, pero tiene opiniones sobre absolutamente todo y además no se las calla. Es como un cuñado supremo. Eso sí, su trabajo lo hace bien. El problema es que si hay dos formas de hacer algo, las dos válidas y las dos igual de buenas la suya es la buena y todas las demás son mierda, y los que han optado por esa otra forma alternativa son unos hijos de puta ignorantes que merecen morir por estar fragmentando la comunidad por proponer una solución técnica diferente.

[#94 XrV]

#63 estamos hablando de cual será la mejor solución en relación al ratio consumo/potencia para datacenter para los futuros 20 años? O vamos a discutir sobre vhs vs betamax?

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

[#97 empanadilla.cosmica]

#7 Si. Los de guasap los van a usar en sus servidores.

[#98 empanadilla.cosmica]

#29 Depende de que quieras desarrollar. ¿Desarrollas para Mac o IOS? Estupendo, puedes probar en local.

¿Desarrollas el kernel de Linux? Igual. Una máquina Apple es lo que necesitas.lara desarrollar Linux para esas máquinas.

¿Desarrollas sistemas empotrados, a priori no es una buena plataforma. Desarrollas aplicaciones para Windows?

Parece una plataforma pésima.

¿Desarrollas juegos para PC o consola? Dependiendo de que hagas puede ser buena plataforma o bastante mala. Si los portas para Mac seguro que es buena plataforma.

¿Llamas desarrollo a hacer livecoding? Dime donde haces los bolos y nos montamos una Jam.

[#99 mgm2pi]

#86 obviamente se necesita el hw donde vas a correr tu aplicación para probar.
Yo trabajo en x86_64 como todo el mundo y pruebo mi software en dispositivo que tengo en mi misma mesa.
Está claro que en un desarrollo en un servidor ARM no se podría tener uno en cada mesa de cada desarrollador pero se podría tener un dispositivo de la misma arquitectura.
Es curiso por que ahora mismo estoy trabajando en una prueba de concepto con raspberry y docker para un proyecto iot que se quiere que escale horizontalmente. Esto mismo es una maqueta de una infraestructura cloud con ARM.

[#100 Desactivado]

#93 jajajajaja es que es un puto personaje.
Sí, hay que aguantarle. Yo creo que en este caso lo da la nacionalidad