"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)".
|
etiquetas: linus torvalds , x86 , cpu , cloud , nube
"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.
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).
Además realizar una compilación cruzada no tiene ningún misterio.
"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.
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.
computerhoy.com/noticias/tecnologia/apple-cambiara-procesadores-intel-
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".
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
(Por mucho que exista Windows 10 arm)
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.
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...
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.
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.
Puede que el riesgo sea bajo pero no es nulo.
Ejemplo: bugs.python.org/issue34957
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.
Si económicamente sale rentable ya se harán cosas para que sea igual de comodo.
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í (www.ambedded.com.tw/solutions.php?NT_ID=20140723004).
Nunca subestimes la capacidad de auto complacencia de todas las empresas
if (cpu == X86) {
blah, blah, blah...
}
else if (cpu == ARM_SU_PTA_MADRE) {
bloh, bloh, bloh...
}
La cpu es importante pero los chipsets también y ARM en ese sentido va por detrás.
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.
Las images te las bajas para x86, no todas las puedes poner en la RPi por ejemplo
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.
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.
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...
Si no se usa es porque la arquitectura mas madura es x86, pero en 15 años ya veremos.
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.
No es que les impida desarrollar en ARM, es que si todo lo que tocas es x86 para que matarte con los ports.
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
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.
Y te lo dice un linuxero desde los 16 y tengo 38.
Linux esta muy por delante en desarrollo de aplicaciones.
Siempre se puede volver a la vieja discusion RISC vs CISC
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.
Y creo, espero y deseo que vuelva. Al final la cabra acaba tirando al monte, SIEMPRE.
thumbs.gfycat.com/WhiteAllGannet-small.gif
Enserio, le echo MUCHO de menos
Pues vale. Mis dieses.
De hecho si empaquetas blobs para routers, lo que haces es precisamente una compilación cruzada.
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
Otra cosa es para el desarrollo de aplicaciones.
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.
De verdad, leyendo menéame a veces tengo la sensación de que he sido abducido a un mundo paralelo.
#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.
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.
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.
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.
¿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.
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.
Sí, hay que aguantarle. Yo creo que en este caso lo da la nacionalidad