Portada
mis comunidades
otras secciones
![Linus Torvalds tira de la anilla y lanza la granada: "x86 ha ganado, olvidaos de ARM en servidores" [ENG]](https://cdn.mnmstatic.net/cache/2f/1c/media_thumb_2x-link-3087400.jpeg?1550897946)
#9:
#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.
"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.
#89:
#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.
#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.
#41:
#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.
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.
#45:
#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.
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.
#19:
#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)
(Por mucho que exista Windows 10 arm)
#17:
#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
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
#2:
¿Lo ha dicho sin insultar a nadie?
Comentarios
#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.
#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.
#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
#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.
#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.
#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.
#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.
#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.
#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.
#9 #41 ¿y qué significa eso que decías/decían de compilación cruzada a bajo nivel? un saludo, gracias.
#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.
#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.
#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.
#45 Una Raspberry no es ARM? Puedes desarrollar en Ella.
#66 Vas a desarrollar software para un servidor en una PI. Claro que sí.
#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.
#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.
#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.
#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.
#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.
#66 claro que si Guapi! Ahora compila en una RPi el ejecutable que va a rular en un Xeon de 16 núcleos.
#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.
#119 goto #9 y #15
El que parece que no lo has entendido eres tu.
¿Lo ha dicho sin insultar a nadie?
#2 Vienes a aportar algo positivo o sólo a reírte de la gente.
#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.
#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.
#89 Tiene 49 años.
#4 #moralWarrior
#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
#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
#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
#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
#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.
#93 jajajajaja es que es un puto personaje.
Sí, hay que aguantarle. Yo creo que en este caso lo da la nacionalidad
#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.
#93 tal como le describes ahora le admiro un poco más. Linux no sigue vivo a pesar de él sino GRACIAS a él
#22 es el Perez Reverte de la informática.
#85 No lo veo tan facha...y menos cuñado, más o menos siempre habla con base.
#22.
#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.
#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.
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.
Estoy de acuerdo con Linus
#79 Estamos hablando de programación de sistemas operativos. Ahí si hace falta compilar.
Otra cosa es para el desarrollo de aplicaciones.
#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.
#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, ...
#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.
#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.
#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
#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
#31 Windows para ARM. Ah, sí, ya lo recuerdo. Se llamaba Windows RT ¿no?
#31 ¿Te parece invento nuevo el meterle navegadores y demás a los coches?
#21 Pues no y a la mayor parte de los mortales tampoco nos afecta. Solo afecta a los desarrolladores de servidores, principalmente linux.
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...
#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
#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).
#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
#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?
#36 pues eso, que para el que pine la nube es mas barato, lo que yo decia.
Y no, la cpu nunca sobra. Sobre tod ahora que cada vez se pide mas a las aplicaciones y hay que meter IA en todo.
#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
#37 de las empresas que dominan un mercado*
#37 la autocomplacencia es un problema, cierto, pero el ejemplo de Apple no es muy valido porque:
- Apple es una religion
- los que eligen Apple no son profesionales que miran numeritos
#75 tienes razón, me ha quedado pedante de cojones. Mis disculpas, era solo ociosidad.
#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ú.
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)
#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.
#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.
#75 No. Te está diciendo que el 99.9% del codigo incluso en C no necesita distinguir la arquitectura.
Yo programo para bastantes plataformas a la vez con un mismo código y solo una vez en mi vida tuve que distinguir si la arquitectura era arm y solo fue para optimizar una instrucción.
La situación que planteas sí que se da bastante para dentro del mismo código distinguir windows, linux y android (y dentro de android que versión es), pero por ejemplo cuando sale la version linux, el mismo codigo funciona perfecto en raspberry (ARM) y en pc tan solo recompilando, o sea que de lo que menos depende es de la arquitectura.
Este año es el año de Linus en el x86
#65 llegas tarde. El mercado de servidores lleva dominado por Linux tiempo ha.
#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.
#95 Ok, lo que dices es cierto pero dado que ya hay Kernel para ARM, no veo que sea inconveniente para que ARM siga avanzando en los campos donde todavía no llega: servidores empresariales.
En escritorios depende de lo que haga Microsoft.
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.
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.
#82 Lo que hace notar Linus es que a la hora de desplegar puedes encontrar problemas (rendimiento, compatibilidad, etc) que no se dan en tu x86 precisamente porque no puedes probar tu código en esa plataforma hasta que lo subes al server, cosa que no pasaría si programaras directamente en esa arquitectura. Que los arm no triunfan en servidores precisamente porque no hay equipos arm a nivel de usuario para programar las aplicaciones. El lenguaje es lo de menos, son cosas como que utilizas cierta función porque resulta ser más eficiente que cierta otra y luego cuando subes la aplicación a producción resulta ser al revés y rendir como el culo. O cosas como usar una librería y comprobar al subir a producción que esa librería para esa arquitectura es tres versiones más antigua y no soportar las características que necesitas (o tener bugs molestos).
#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.
#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.
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.
#27 desplegar por deployar.
#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...
#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.
#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.
#52 Yo lo que dudo y me refería es a lo que has dicho de "Llegará el dia que usaremos el teléfono para el escritorio con algún dispositivo tipo samsung DEX".
Que ARM pueda acabar funcionando bien no tengo suficiente información para discutirlo.
#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.
#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
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.
#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)
#19 Resuélveme una duda: hablas por ti o has visto mucho IT Crowd (o sucedáneos similares)?
#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.
#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.
#98 Linux le da mil vueltas como plataforma de desarrollo a macosx. El problema es que ahora muchos desarrollos tienen que convivir muy estrechamente con el diseño ( front end, mobile, prototipado, ..), y ahí Linux carece de un ecosistema decente.
Si al menos Adobe portara sus aplicaciones...
#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.
#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.
#35 falta mucho mucho para que eso sea una alternativa competitiva.
#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"
#57 Si tu lo dices ...
#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.
#40 Sea esto cierto o no, le funciona, ¿verdad?
#40 Los procesadores de Apple de Iphone van dos generaciones por detras??!!!
#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.
#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.
#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
Pero eso es como decir que Windows ha ganado en el escritorio, olvidaos de Linux.
pero se le va a poder instalar el güasap?
#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?
#7 Si. Los de guasap los van a usar en sus servidores.
#79 Claro, y el intérprete es a su vez interpretado, y el kernel también es interpretado.
#87 No. El intérprete funciona si te un Linux que ya está disponible desde hace muchos años para ARM.
Que el señor Torvalds disculpe mi ignorancia pero, ¿qué te impide desarrollar en un entorno ARM?
#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).
#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.
#6 Que meada fuera del tiesto de #3 y lo peor que está muy votada.
¿Compilar a bajo nivel? Ahora me entero que existe esa palabra.
A ver , hoy por hoy si eres fabricante y no eres tonto das todas las especificaciones de tu hardware para que la expriman, no es como los ochenta que había instrucciones ocultas en las CPU.
Es que aunque sea ensamblador, tienes acceso a toda la máquina, no hay trucos (o no debería) hacer trucos rollo demoscene.
Lo único, es el rodaje de las máquinas, que no es lo mismo las décadas, que si que las x86 llevan una eternidad y se sabe como aprovecharlas y sus fallas, y que con ARM hay que volver esa experiencia (que creo que ya hay un % alto) pues si.
#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.
#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.
#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.
#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".
#15 Yo te entendí desde el principio hermano, no sufras.
#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
#15 no, no, si yo lo entendí así. Cuando hablaba de él amigo, hablaba de Linus.
#155 goto #15
#15 gracias.
#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
#3 y si usas docker esto te afecta en algo?
#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.
#46 falta, si. Pero con AWS ofertando arm y si apple migra, tienes dos movimientos que pueden mover el mercado
#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.
#3 Yo tengo una objeción: los lenguajes compilados están quedando en desuso.
#79 ¿Perdón? ¿Es irónico? La inseguridad y propensión a errores del software desarrollado con lenguajes interpretados ha llegado a tal punto que Angular le dió la patada a JS
#3 Intel confirma que Apple cambiara la CPU de sus Mac en 2020 [Ing]
Intel confirma que Apple cambiara la CPU de sus Ma...
amp.tomshardware.com#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.
#1 El problema es que cuando desarrollas en una plataforma esperas un rendimiento y condiciones de tu programa, porque lo desarrollas y testeas en esa plataforma. El hecho de compilar y desplegar en otra puede dar problemas (caídas de rendimiento inesperado, problemas de compatibilidad, etc) que no ves sobre la marcha, encareciendo costes de desarrollo y de despliegue que puede ser que no compensen las ventajas. De lo que se queja Linus es que si no hay herramientas de desarrollo nativas y por lo tanto desarrolladores nativos en una plataforma no x86 no va a poder despegar el uso de otras arquitecturas en los servidores y que por eso x86 está ganando la partida.
Sería algo similar a por qué no despegaron las steam machines. El ecosistema estaba verde, los desarrolladores trabajan en windows, los que hacían el esfuerzo en portar sus juegos encontraban problemas, los que encargaban ports a terceros encontraban productos que no rendían igual (por no haber sido diseñados para ser multiplataforma y trabajar bien en algo que no fuera windows) y muchas quejas...
Dios mío. Que importante
#8 Dios mío. Que ignorante.