Portada
mis comunidades
otras secciones
#3:
Es una puta pasada.
Y debe ir fino filipino. En este mundo siniestro donde todo son capas y capas y capas y capas de abstracción para conseguir que hasta un mono sea capaz de programar, estos héroes de la computación han tenido las pelotas de picar un sistema operativo en puro ensamblador, ni C ni pollas en vinagre.
Y ahí lo tienes: con gráficos de puta madre, su escritorio, reproductores multimedia, videojuegos
Qué huevazos. ESO son programadores. Los demás somos micos que picoteamos lo que nos manda el jefe contra APIs, frameworks y toda suerte de guarrerías, sin preocuparse de si el código contra el que programamos está bien escrito o es una chufa (y muchísimas veces lo es).
Y debe ir fino filipino. En este mundo siniestro donde todo son capas y capas y capas y capas de abstracción para conseguir que hasta un mono sea capaz de programar, estos héroes de la computación han tenido las pelotas de picar un sistema operativo en puro ensamblador, ni C ni pollas en vinagre.
Y ahí lo tienes: con gráficos de puta madre, su escritorio, reproductores multimedia, videojuegos
Qué huevazos. ESO son programadores. Los demás somos micos que picoteamos lo que nos manda el jefe contra APIs, frameworks y toda suerte de guarrerías, sin preocuparse de si el código contra el que programamos está bien escrito o es una chufa (y muchísimas veces lo es).
#11:
#3 Hombre, hoy en día ya no es lo que era: antes sí podías ser mejor que el compilador; hoy en día, un buen compilador de C será mejor que tú el 99,9999% de las veces, y sólo le podrás superar en cosas muy puntuales. Otra cosa es crear un sistema operativo en lenguajes de alto nivel, o con el objetivo de que sea muy portable, etc.
#34:
#20 Y ahora freidme a negativos si queréis.
Joder, es que te los merecerías por soltar el comentario ese.
¿Los conoces? ¿Sabes de qué trabaja cada uno de ellos? ¿Quién te dice a ti que ese proyecto no es su "pasatiempo" y luego se dedican a otras cosas? ¿Por qué alguien debería dedicar su talento a "curar el cáncer" y no a cualquier otra cosa menos popular y sensacionalista... pero que le llena más y le divierte más? ¿Tienen ellos conocimientos para saber cómo empezar a desarrollar el software que les estás pidiendo que desarrollen, o necesitarían de biólogos y bioquímicos para ayudarles? ¿Por qué no van esos biólogos, médicos y bioquímicos a pedirles que trabajen con/para ellos?
Son tantas preguntas que tiran por tierra lo que acabas de decir...
Y conste que te lo digo sin acritud, eh... no te culpo de nada. Hoy en día parece que todo en Ciencia se tiene que hacer con fines médicos, especialmente "para curar el cáncer". Y es ridículo. Conozco de cerca a montones de científicos y ninguno se dedica a "curar el cáncer". Sin embargo, son gente que descubre cómo optimizar procesos químicos que hasta ahora contaminaban y enguarraban de forma masiva y ellos los han convertido en procesos limpios que no generan mierda durante su fabricación, o que gastan menos energía. Otros se dedican a investigar partículas subatómicas. Otros han trabajado desarrollando el sistema "Root" del CERN... en fin macho, que hay todo un mundo ahí en la Ciencia y la "chorradita" de "curar el cáncer" o "darle la vista al ciego" es sólo una milmillonésima parte. Y a la mayoría de los científicos, se la trae bastante floja
Joder, es que te los merecerías por soltar el comentario ese.
¿Los conoces? ¿Sabes de qué trabaja cada uno de ellos? ¿Quién te dice a ti que ese proyecto no es su "pasatiempo" y luego se dedican a otras cosas? ¿Por qué alguien debería dedicar su talento a "curar el cáncer" y no a cualquier otra cosa menos popular y sensacionalista... pero que le llena más y le divierte más? ¿Tienen ellos conocimientos para saber cómo empezar a desarrollar el software que les estás pidiendo que desarrollen, o necesitarían de biólogos y bioquímicos para ayudarles? ¿Por qué no van esos biólogos, médicos y bioquímicos a pedirles que trabajen con/para ellos?
Son tantas preguntas que tiran por tierra lo que acabas de decir...
Y conste que te lo digo sin acritud, eh... no te culpo de nada. Hoy en día parece que todo en Ciencia se tiene que hacer con fines médicos, especialmente "para curar el cáncer". Y es ridículo. Conozco de cerca a montones de científicos y ninguno se dedica a "curar el cáncer". Sin embargo, son gente que descubre cómo optimizar procesos químicos que hasta ahora contaminaban y enguarraban de forma masiva y ellos los han convertido en procesos limpios que no generan mierda durante su fabricación, o que gastan menos energía. Otros se dedican a investigar partículas subatómicas. Otros han trabajado desarrollando el sistema "Root" del CERN... en fin macho, que hay todo un mundo ahí en la Ciencia y la "chorradita" de "curar el cáncer" o "darle la vista al ciego" es sólo una milmillonésima parte. Y a la mayoría de los científicos, se la trae bastante floja
#18:
#3 Ya estamos con lo de siempre: https://xkcd.com/378/
#116:
#3 Esto... Creo que algunos tenéis muy mitificado el ensamblador. Para empezar coincido con #11 en que un compilador moderno genera código tan sofisticado y optimizado que dudo que un humano pueda mejorarlo, y si lo hace estaríamos hablando de ganar unas decenas de ciclos de reloj entre los miles de millones que se ejecutan por segundo. Además el ensamblador, en especial el de x86, es muy sencillo de aprender y medianamente fácil de dominar. Yo mismo escribí varios juegos en ensamblador para mi 486. Lo hice porque en aquella época no disponíamos de conexiones a Internet, así que no podía aprender otro lenguaje ni disponía de compiladores de alto nivel ni otras herramientas. Más tarde aprendí C y me di cuenta de lo que es un auténtico lenguaje de programación. Han pasado 20 años desde que lo uso y aún no me considero un experto. Con C puedes programar a tan bajo nivel como quieras, y desde luego no supone ninguna capa de abstracción redundante que engorde y ralentice el programa. Encima es muy portable, en mi opinión casi tanto como ese BASIC de nuestros días que es Java.
O sea, que IMHO y sin querer quitarle mérito a los protagonistas de la noticia, lo que han hecho está muy bien, como curiosidad, y desde luego que tiene mérito. Lo que no le veo es demasiada utilidad... Más o menos como usar una moneda para atornillar cuando podrías usar un destornillador eléctrico. Por ejemplo, cada vez que Intel o AMD añadan instrucciones nuevas o introduzcan cambios en la arquitectura de sus procesadores, estos señores tendrán que reescribir la mitad del código. De haberlo hecho en C sería tan fácil como esperar a que actualicen el compilador y volver a compilar.
O sea, que IMHO y sin querer quitarle mérito a los protagonistas de la noticia, lo que han hecho está muy bien, como curiosidad, y desde luego que tiene mérito. Lo que no le veo es demasiada utilidad... Más o menos como usar una moneda para atornillar cuando podrías usar un destornillador eléctrico. Por ejemplo, cada vez que Intel o AMD añadan instrucciones nuevas o introduzcan cambios en la arquitectura de sus procesadores, estos señores tendrán que reescribir la mitad del código. De haberlo hecho en C sería tan fácil como esperar a que actualicen el compilador y volver a compilar.
#120:
#3 a ver, el SO tiene muy buena pinta, es un currazo de la leche y no voy a ser yo quien les quite merito. Les doy la enhorabuena. Pero hoy en dia esa programacion ya esta muy superada, no se puede ir desarrollando en ensamblador. Y te lo dice uno al que le encanta el ensamblador y que empezó en este mundo desarrollando en ensamblador librerias graficas para poder usarlas en videojuegos. Los desarrollos a muy bajo nivel, para temas puntuales, se seguira haciendo, pero los supersistemas que hay hoy en dia, hacerlos y mantenerlos en ensamblador es inviable, y que sean portables y compatibles con multiples plataformas, etc, etc. Lo de als capas y capas, estoy de acuerdo que empieza a ser preocupante, ya hace tiempo que considero que hay exceso de capas, bastantes años. Este exceso lo que hace es alejarte cada vez mas de la maquina, baja la concrecion y aumenta la abstraccion, a veces hasta niveles ridículos. Es tal a veces la abstracción a la que se llega, que su complejidad hace que una tarea sencilla se convierta en un rompecabezas. Para programar una puta mierda tienes que configurar montones de cosas, manejar entidades que no sabes para que coño valen, etc. La mayoria de las veces los programadores no saben ni como funciona ni por qué o por qué deja de funcionar su programa.Al rey lo que es del rey.
#104:
#99 ya, pero si has hecho tu programa para un juego de instrucciones o arquitectura concreta, adaptarlo a la nueva arquitectura supone reescribir de nuevo el programa. Con lo cual, puedo tener el programa más óptimo, que cuando salga un nuevo modelo de CPU o arquitectura ya he perdido toda la optimización.
Además, el ensamblador aprovechaba el 100% de las CPUs hace 35 años, cuando se programaba para el Z80. La actual complejidad de las CPUs (superescalares, centenares de instrucciones, varios niveles de cache, ejecuciones fuera de orden, ejecución de hilos predictiva...) requiere tal cantidad de aspectos a tener en cuenta que optimizar a mano en ensamblador supondría pasarse horas para escribir unas pocas instrucciones.
Las pocas ineficiencias que puedan tener los compiladores modernos son compensadas sobradamente por un código más óptimo en todas las arquitecturas, mucho más que el que cualquier ser humano puede hacer para un modelo concreto de procesador.
Ya sé que no queda guay decirlo. Pero no, los artesanos del software no solo son ineficientes económicamente, sino que tampoco lo son técnicamente.
Además, el ensamblador aprovechaba el 100% de las CPUs hace 35 años, cuando se programaba para el Z80. La actual complejidad de las CPUs (superescalares, centenares de instrucciones, varios niveles de cache, ejecuciones fuera de orden, ejecución de hilos predictiva...) requiere tal cantidad de aspectos a tener en cuenta que optimizar a mano en ensamblador supondría pasarse horas para escribir unas pocas instrucciones.
Las pocas ineficiencias que puedan tener los compiladores modernos son compensadas sobradamente por un código más óptimo en todas las arquitecturas, mucho más que el que cualquier ser humano puede hacer para un modelo concreto de procesador.
Ya sé que no queda guay decirlo. Pero no, los artesanos del software no solo son ineficientes económicamente, sino que tampoco lo son técnicamente.
#8:
Ahora hagamos una máquina virtual de java
#32:
#25 tienes razón, los que ven la programación como una herramienta son simples albañiles y los programadores son los ingenieros.
Lo curioso es que los ingenieros titulados suelen ser los albañiles del código en las cárnicas.
¿que utilidad puede tener un SO en ensamblador ,superreducido y que optimiza al máximo la máquina? dentro de unos años cuando haya un ordenador hasta en la tapa del water, lo comprenderás.
Lo curioso es que los ingenieros titulados suelen ser los albañiles del código en las cárnicas.
¿que utilidad puede tener un SO en ensamblador ,superreducido y que optimiza al máximo la máquina? dentro de unos años cuando haya un ordenador hasta en la tapa del water, lo comprenderás.
#85:
Es una frikada insensata: tirarse 10 años programando un código que sólo va a servir a un tipo de procesador muy concreto (y que se va a quedar obsoleto a ojos vista).
Unos resuelven sudokus y otros programan en ensamblador un SO. Desde ese punto de vista, ningún problema.
Unos resuelven sudokus y otros programan en ensamblador un SO. Desde ese punto de vista, ningún problema.
#90:
#13 C permite escribir código portable, pero lo escrito no tiene por qué ser portable. Por ejemplo por temas de low-endian y big-endian, o si nos vamos a temas de drivers, arquitecturas, etc (por ejemplo: un gestor de memoria puede estar escrito en C, pero eso no lo hace portable entre x86 y PowerPC, porque la estructura de tablas de memoria y demás es distinta).
Comentarios
Es una puta pasada.
Y debe ir fino filipino. En este mundo siniestro donde todo son capas y capas y capas y capas de abstracción para conseguir que hasta un mono sea capaz de programar, estos héroes de la computación han tenido las pelotas de picar un sistema operativo en puro ensamblador, ni C ni pollas en vinagre.
Y ahí lo tienes: con gráficos de puta madre, su escritorio, reproductores multimedia, videojuegos
Qué huevazos. ESO son programadores. Los demás somos micos que picoteamos lo que nos manda el jefe contra APIs, frameworks y toda suerte de guarrerías, sin preocuparse de si el código contra el que programamos está bien escrito o es una chufa (y muchísimas veces lo es).
#3 Ya estamos con lo de siempre: https://xkcd.com/378/
#3 Hombre, hoy en día ya no es lo que era: antes sí podías ser mejor que el compilador; hoy en día, un buen compilador de C será mejor que tú el 99,9999% de las veces, y sólo le podrás superar en cosas muy puntuales. Otra cosa es crear un sistema operativo en lenguajes de alto nivel, o con el objetivo de que sea muy portable, etc.
#20 Y ahora freidme a negativos si queréis.
Joder, es que te los merecerías por soltar el comentario ese.
¿Los conoces? ¿Sabes de qué trabaja cada uno de ellos? ¿Quién te dice a ti que ese proyecto no es su "pasatiempo" y luego se dedican a otras cosas? ¿Por qué alguien debería dedicar su talento a "curar el cáncer" y no a cualquier otra cosa menos popular y sensacionalista... pero que le llena más y le divierte más? ¿Tienen ellos conocimientos para saber cómo empezar a desarrollar el software que les estás pidiendo que desarrollen, o necesitarían de biólogos y bioquímicos para ayudarles? ¿Por qué no van esos biólogos, médicos y bioquímicos a pedirles que trabajen con/para ellos?
Son tantas preguntas que tiran por tierra lo que acabas de decir...
Y conste que te lo digo sin acritud, eh... no te culpo de nada. Hoy en día parece que todo en Ciencia se tiene que hacer con fines médicos, especialmente "para curar el cáncer". Y es ridículo. Conozco de cerca a montones de científicos y ninguno se dedica a "curar el cáncer". Sin embargo, son gente que descubre cómo optimizar procesos químicos que hasta ahora contaminaban y enguarraban de forma masiva y ellos los han convertido en procesos limpios que no generan mierda durante su fabricación, o que gastan menos energía. Otros se dedican a investigar partículas subatómicas. Otros han trabajado desarrollando el sistema "Root" del CERN... en fin macho, que hay todo un mundo ahí en la Ciencia y la "chorradita" de "curar el cáncer" o "darle la vista al ciego" es sólo una milmillonésima parte. Y a la mayoría de los científicos, se la trae bastante floja
Ahora hagamos una máquina virtual de java
#20 Tienes toda la razón, imaginate; si los hay que escalan montañas y todo. Y los que corren 41 km. Con la de patatas que se podían plantar con ese esfuerzo.
#20 Y los niños muriéndose de hambre en África, no olvides eso también.
#1 Pues en VirtualBox te los instalas en un par de minutos
#3 Se rumorea que a un equipo de programadores de Zaragoza les dijeron hace 15 años a que no había gúevos de programar un SO en binario y nunca más se supo de ellos!
#25 tienes razón, los que ven la programación como una herramienta son simples albañiles y los programadores son los ingenieros.
Lo curioso es que los ingenieros titulados suelen ser los albañiles del código en las cárnicas.
¿que utilidad puede tener un SO en ensamblador ,superreducido y que optimiza al máximo la máquina? dentro de unos años cuando haya un ordenador hasta en la tapa del water, lo comprenderás.
#21 La versión 32-bits es GPL, la de 64 es la que tiene esa licencia que pones.
#4 Entendieron "vinario", y una cosa llevo a otra... ponte a buscarles a estas alturas.
#23 La diferencia radica en que yo el programar lo veo como una herramienta, no como un fin. Allá cada cual.
#14 Debe de ser porque esta en contacto con los extraterrestres como El Niño de E.T.
Licencia:
1) Free for personal and educational use.
2) Contact menuetos.net for commercial use.
3) Redistribution, reverse engineering, disassembly or decompilation
prohibited without permission from the copyright holders.
Hasta donde yo sé, la tercera clausula es al menos parcialmente inválida en la UE, no pueden prohibirlo si se hace para mejorar la compatibilidad.
Mejor buscar uno con una licencia más favorable. En el 99'99% de los casos, seguro que un línux lo reemplaza fácilmente.
#3 Pues no sé yo que decirte. Yo mas bien lo que veo es que son personas que desaprovechan su talento, del cual no dudo, en realizar algo que más allá de para salir en un reportaje en algún medio especializado, va a valer para poco.
Podrían dedicarse, por ejemplo, usando los métodos actuales de programación que facilitan el trabajo, a desarrollar un software que sea capaz de localizar células intestinales cancerígenas, mediante un TAC. Entonces sí diría eso de "son los putos amos". Pero esto, lamentablemente, sólo sirve para decir "nos dijeron que no seríamos capaces y lo hemos hecho". A parte de eso, poca utilidad más tiene.
Y ahora freidme a negativos si queréis.
#2 Lo más probable es que el frigorífico sea x64
#3 Estos son programadores de verdad, el resto son putos usuarios de interfaces gráficos
héroes de nuestro tiempo.
Es una frikada insensata: tirarse 10 años programando un código que sólo va a servir a un tipo de procesador muy concreto (y que se va a quedar obsoleto a ojos vista).
Unos resuelven sudokus y otros programan en ensamblador un SO. Desde ese punto de vista, ningún problema.
Este "niño prodigio" creo que esta detrás del desarrollo de este proyecto
La página web es tan cutre que también debe haber sido escrita en ensamblador.
#13 los cojones. Me avalan 10 años manteniendo un framework para windows y unix escrito en c/c++.
Y ya que estamos, un offtopic para desahogarme: las boost son la montaña mas grande de mierda que se ha programado jamás.
¡¡Tiembla Windows 10!!
Bromas aparte hace tiempo que tengo curiosidad por probarlo, hay que tomarse el trabajo
#11 no hombre no... dónde vas a parar. Cuánto mejor es programar en ensamblador con el conjunto de instrucciones de hace 15 años, y crear un sistema operativo que tira 100% de CPU. Los 64 bits y las GPU son cosa de maricones.
#13 C permite escribir código portable, pero lo escrito no tiene por qué ser portable. Por ejemplo por temas de low-endian y big-endian, o si nos vamos a temas de drivers, arquitecturas, etc (por ejemplo: un gestor de memoria puede estar escrito en C, pero eso no lo hace portable entre x86 y PowerPC, porque la estructura de tablas de memoria y demás es distinta).
#99 ya, pero si has hecho tu programa para un juego de instrucciones o arquitectura concreta, adaptarlo a la nueva arquitectura supone reescribir de nuevo el programa. Con lo cual, puedo tener el programa más óptimo, que cuando salga un nuevo modelo de CPU o arquitectura ya he perdido toda la optimización.
Además, el ensamblador aprovechaba el 100% de las CPUs hace 35 años, cuando se programaba para el Z80. La actual complejidad de las CPUs (superescalares, centenares de instrucciones, varios niveles de cache, ejecuciones fuera de orden, ejecución de hilos predictiva...) requiere tal cantidad de aspectos a tener en cuenta que optimizar a mano en ensamblador supondría pasarse horas para escribir unas pocas instrucciones.
Las pocas ineficiencias que puedan tener los compiladores modernos son compensadas sobradamente por un código más óptimo en todas las arquitecturas, mucho más que el que cualquier ser humano puede hacer para un modelo concreto de procesador.
Ya sé que no queda guay decirlo. Pero no, los artesanos del software no solo son ineficientes económicamente, sino que tampoco lo son técnicamente.
No es que quepa en un diskette de 1,45 Mb es que el S.O. ocupa solo 54.000 bytes. Podiras meter 30 veces este S.O. en un diskette.
Me he liado con los archivos para hacer pasarlo a un CD
Voy a probar a ver si se puede hacer "booteable" desde un USB
#39 Han diseñado un sistema operativo, no un pantallazo de la agencia tributaria...
Problema: solo para x86: CISC. Imposible portarlo sin empezar de cero.
Sería más intersante para RISC (ARM), para micros muy pequeños de muy bajo consumo que requieran un S.O. eficiente que les saque rendimiento a pocos Mhz.
#42 BIll Gates no dijo esa frase de la que está pensando. Lo niega diciendo que dijo muchas estupideces pero no esa y no existe ninguna fuente que lo demuestre
#3 Esto... Creo que algunos tenéis muy mitificado el ensamblador. Para empezar coincido con #11 en que un compilador moderno genera código tan sofisticado y optimizado que dudo que un humano pueda mejorarlo, y si lo hace estaríamos hablando de ganar unas decenas de ciclos de reloj entre los miles de millones que se ejecutan por segundo. Además el ensamblador, en especial el de x86, es muy sencillo de aprender y medianamente fácil de dominar. Yo mismo escribí varios juegos en ensamblador para mi 486. Lo hice porque en aquella época no disponíamos de conexiones a Internet, así que no podía aprender otro lenguaje ni disponía de compiladores de alto nivel ni otras herramientas. Más tarde aprendí C y me di cuenta de lo que es un auténtico lenguaje de programación. Han pasado 20 años desde que lo uso y aún no me considero un experto. Con C puedes programar a tan bajo nivel como quieras, y desde luego no supone ninguna capa de abstracción redundante que engorde y ralentice el programa. Encima es muy portable, en mi opinión casi tanto como ese BASIC de nuestros días que es Java.
O sea, que IMHO y sin querer quitarle mérito a los protagonistas de la noticia, lo que han hecho está muy bien, como curiosidad, y desde luego que tiene mérito. Lo que no le veo es demasiada utilidad... Más o menos como usar una moneda para atornillar cuando podrías usar un destornillador eléctrico. Por ejemplo, cada vez que Intel o AMD añadan instrucciones nuevas o introduzcan cambios en la arquitectura de sus procesadores, estos señores tendrán que reescribir la mitad del código. De haberlo hecho en C sería tan fácil como esperar a que actualicen el compilador y volver a compilar.
#12 si es que no entendía su letra desde el primer momento...
#52 hombre, es que no es mantenible
además, dominar el ensamblador de una arquitectura tampoco me parece algo sobrehumano. Y bueno, que también hay gente cuyo trabajo se basa en comprender esas pequeñas particularidades. Pero vaya, que estoy de acuerdo contigo en que en general, el coste de mantener un programa escrito íntegramente en ensamblador es demasiado.
De hecho, esto me recuerda a lo que le pasó a OS/360, tiene su gracia: http://www.cosy.sbg.ac.at/~clausen/PVSE2006/printerfriendly.asp.htm
#12 hostia palmando asignaturas en 4º y este ha llegado a ser registrador de la propiedad....lo dudo
#47 Yo lo que he dicho es que #11 tiene toda la razón, y por tanto, la mayoría de las veces el código emitido por el compilador es mejor que el que pueda escribir un humano. Los procesadores actuales son máquinas muy complejas, con un montón de detalles que determinan cómo acaba ejecutándose el código y que, aunque la ejecución mantiene la semántica de tu programa, el orden en que se pueden acabar ejecutando tus instrucciones puede ser muy distinto al que tu piensas. Si eres capaz de estudiarte todos estos detalles y como interaccionan entre sí (para un procesador concreto, ya que para otro será una historia distinta), y estás dispuesto a pasar media vida optimizando tus instrucciones para un programa muy pequeño (para uno grande ya no sería viable para un humano), puede que acabes dando con un código mejor, pero vamos, hay que tener ganas
#100 Un movil de 250 pavos es capaz de ejecutar Android de modo fluido hoy día. Ni hablemos del rendimiento de uno de precio parecido al iPhone. No hemos tenido que esperar hasta 2060 . La apuesta de Android fue poder ejecutarse en multitud de arquitecturas, y eso lo consiguieron usando un a máquina virtual. Los de Google no tienen un pelo de tontos.
#3 a ver, el SO tiene muy buena pinta, es un currazo de la leche y no voy a ser yo quien les quite merito. Les doy la enhorabuena. Pero hoy en dia esa programacion ya esta muy superada, no se puede ir desarrollando en ensamblador. Y te lo dice uno al que le encanta el ensamblador y que empezó en este mundo desarrollando en ensamblador librerias graficas para poder usarlas en videojuegos. Los desarrollos a muy bajo nivel, para temas puntuales, se seguira haciendo, pero los supersistemas que hay hoy en dia, hacerlos y mantenerlos en ensamblador es inviable, y que sean portables y compatibles con multiples plataformas, etc, etc. Lo de als capas y capas, estoy de acuerdo que empieza a ser preocupante, ya hace tiempo que considero que hay exceso de capas, bastantes años. Este exceso lo que hace es alejarte cada vez mas de la maquina, baja la concrecion y aumenta la abstraccion, a veces hasta niveles ridículos. Es tal a veces la abstracción a la que se llega, que su complejidad hace que una tarea sencilla se convierta en un rompecabezas. Para programar una puta mierda tienes que configurar montones de cosas, manejar entidades que no sabes para que coño valen, etc. La mayoria de las veces los programadores no saben ni como funciona ni por qué o por qué deja de funcionar su programa.Al rey lo que es del rey.
#38 eso no siempre es así, a veces tienes que darles pistas sobre cuál es el resultado más probable de una comparación, hacer prefetch de variables, etcétera. Y aparte de eso, cuando se pretende un código ultraminimalista, el compilador a veces no te puede ayudar. Sigue habiendo formas tremendamente retorcidas de optimizar un algoritmo en ensamblador que en un compilador no se pueden prever.
Hay por ahí gente que se dedica sólo a esto, vi por ahí alguna que otra demo impresionante en ensamblador de 16 bits que animaba de forma bastante fluida una celosía tridimensional con perspectiva, iluminación y sombreado. Y el código era ridículamente pequeño, cabía en un folio, sin hacer trampas.
#87 Se puede programar perfectamente y con calidad usando lenguajes de mayor nivel. Además, es más fácil y rápido.
Lo voy a instalar en mi frigorífico
#3 Vaya cantidad de tonterías acabas de decir. Y ahí lo tienes, con tus positivos. Te corregiría frase por frase, pero es mucho tiempo, estoy cansado, y no vale la pena que gaste mis energías y sabiduría en un desconocido de internet.
#27 No lo olvido. Mira mi avatar.
#8 oye, que está escrita en C. Igual valía la pena hacerla en ASM.
#3 Lo que es de gilipollas es despreciar los avances existentes por querer ser más "hardcore". Con un lenguaje de alto nivel haces en una hora lo que tardarias un mes en ensamblador. Si Google hubiera contratado "programadores reales" para hacer Android en ensamblador, a lo mejor en 2030 tendríamos la versión 1.0 (pero iría más rápido, eso si).
#11 C es portable.
Muy bien, ahora necesito un lector se diskettes para experimentarlo en todo su esplendor.
#68 No hace falta irse a extremos ridículos. Con un tipo de letra diferente, mayor tamaño y separación entre líneas ya ganaban mucho.
#69 Es como coger granos de arena de una playa uno a uno o con la mano. La segunda es más rápida pero se te pueden colar otras cosas, mientras que la primera es más lenta pero solo obtienes los granos. Eficiencia del código (siempre que se haga bien) frente a rapidez de desarrollo
Si ya existen problemas de seguridad en sistemas operativos programados casi enteramente en C o incluso C++, no me quiero ni imaginar la cantidad de bugs que se podrán explotar en un sistema operativo escrito completamente en ensamblador!
Ensamblador hoy día es una locura y poco productivo. No existe una gran ventaja de rendimiento frente a C actualmente.
#69 la manera más eficiente para decir que tienes hambre sería gruñir mientras te tocases la barriga pero usamos palabras que constituyen idiomas para evitar que en el pueblo de al lado no entiendan que tienes un cólico de narices, aquí ya pasamos de la eficacia a la potabilidad, la capa intermedia del lenguaje te asegura que los dos pueblos entiendan lo mismo.
Luego es cuando te vas al país de al lado y no entienden tu idioma, aquí ya es donde entra el java, que ya es otra capa encima del idioma para que los idiomas se entiendan entre ellos.
Resumiendo, de un gruñido cargado de información que debería bastar para que te den de comer pasas a una cantidad ingente de esfuerzos, recursos y conocimientos acumulados para consegui lo mismo, comer.
#12 #14 Igual hasta llega a presidente...
hay q ser masoquista
#12 Aprobó religión a mi me suspendieron en ella.
#51 Sí sí, mucho reírnos de los 64bits, pero luego resulta que IPv6 usa direcciones de 128-bit y no son tan excesivos.
Por cierto, según la Wikipedia:
"Se considera que, sin contar con la materia oscura, hay alrededor de 1072 hasta 1087 átomos en el universo"
1087 = 2289... o sea que todavía falta un trecho (una diferencia de 50 órdenes de magnitud, que se dice pronto).
#5 Pues cuando he visto la captura de Quake, he pensado que sí o sí tiene que correr Doom. Buscando ahora algún aparato antiguo donde instalar este S.O.
#21 de acuerdo respecto a lo de la licencia. De todos modos, yo creo que lo interesante aquí son los casos de uso que otros sistemas operativos no cubren.
#94 En ese caso si saben programar bien en ensamblador seguramente tendrá menos bugs que si lo hacen en C. Falso, en caso de que sepan programar bien en C. Además, los lenguajes de alto nivel tienen una semántica bien definida que te permite razonar sobre la corrección de tu programa, sin saber cual es exactamente el código de bajo nivel generado.
Sobre la asignación de registros, el una fase fundamental en cualquier buen compilador.
#17 la única parte de Linux en ensamblador es la que está bajo los directorios arch/, y se corresponde con el código específico de cada máquina. El grueso del sistema, lo que es la algoritmia gorda de Linux, está en C. No se puede comparar.
#53 Lenguaje cercano al lenguaje máquina (ensamblador) != código optimizado != programar de forma optimizada.
#101 Te pongo un ejemplo claro:
"Xvid is an open source MPEG-4 video codec, written in C with assembler optmizations for quality and speed"
Si se pudiera optimizar tanto en C como en ensamblador, no haría falta que los desarrolladores de Xvid añadieran código ensamblador al suyo en C ¿No es así?
Parece como si a alguno le partiera el alma que le digan que C no es el lenguaje más optimo, cosa normal si se hizo para facilitar y agilizar el desarrollo de programas de forma que se ha podido avanzar bastante gracias a la abstracción, pero la optimización es un grado de prioridad menor que la abstracción del código en este caso.
Creo recordar que había un spin-off ruso de ese SO de su época libre que se llamaba Kolibri OS y que tenía algunas aplicaciones más que este.
#52 ¿Y quien crea los compiladores y les dice como compilar el código?
Dejaré un vídeo para que lo veáis en marcha (no es de la versión 1.0, pero se acerca):
Uhmmm, a ver como digo todo lo que me viene a la cabeza y quede medio bien...
Quizá por falta de conocimientos o por repetir mitos y demás pero estamos confundiendo y mezclando cosas, y hay mitos hacia los dos lados de la discusión.
------------------------
Ensamblador, C, otros, lenguaje vs librería, código generado...:
+ Las rutinas escritas en ensamblador son, aun casi sin querer ir a hacer buen código, muy pequeñas, no hay instrucciones superfluas y hacen justo lo que deben, ni más ni menos.
+ Los lenguajes de alto nivel, aun poniendo el compilador en optimize for size ( a menudo, indirectamente mejor que optimizar para velocidad, salvo en algoritmos con mucho bucle, donde el desenrollo de bucles si ayuda ) desensamblas el código y a menudo te tiras las manos a la cabeza con la de instrucciones o construcciones superfluas que te encuentras ( y hablo de compiladores de MS, GCC,... quizá los de intel no pequen tanto, pero hace mucho que no veo código de eso ).
Por ejemplo, la gestión de marcos de pila para funciones, con un buen planning de registros y demás puedes evitarlo por completo en ensamblador, en x86-64 esto ha mejorado gracias a tener 16 registros normales en vez de 8 como en 32 bit, y el ABI ( el conjunto de convenciones de llamada, preservar registros, etc. ) aprovecha esos 16 registros, asique ya es algo más limpio, pero aún hay cosas mejorables.
NOTA: También es verdad que parte de este código superfluo es por seguir unos estándares y hacer que la interoperabilidad entre diferentes módulos/librerías sea posible, que la depurabilidad de las rutinas sea algo mejor, etc.
+ Antes ( época de primeros pentium y en adelante ) se programaba en ensamblador pensando en el pairing de instrucciones en el pipeline, evitando stalls ( periodos donde el procesador que ejecutaba varias instrucciones al mismo tiempo "paraba" un poco a esperar a que operaciones necesarias para poder hacer otras operaciones se completaran ) por cadenas de definición-uso muy cercanas, haciendo hinting a los saltos condicionales en bucles o incluso cambiando "if"s por indexación según multiplicandos ligados a condición... vamos, mucha "magia negra".
+ Hoy día todo esto lo hace el mismo procesador, no hay procesador que no funcione a nivel de microinstrucciones hoy día. Hay una circuitería que decodifica las instrucciones en micro-operaciones, las reordena y hace mil virguerías más y, por mal que este hecho todo, la cosa va muy fina ( al menos en x86 o x86-64 ).
* El problema no es tanto esa optimización enfermiza, el problema es la morralla que se evita usando ensamblador o al menos C. Hay muchos niveles de optimización:
+ Optimización en el diseño, sea en algoritmos o en la organización del código en sí, esto es lo más importante ( hacer diseños simples y compactos, organizar las matrices de manera que haya "shortcuts" matemáticos que optimicen el algoritmo a nivel conceptual, aplicar conocimientos teóricos, ... son ejemplos, sin más )
+ Optimización en el código. No hablo aun de si es C o ensamblador, hablo de que un bucle para recorrer un array puede hacerse peor o mejor incluso a nivel de pseudocódigo o "receta escrita". Esto es bastante importante y esta medio-difuso con el punto anterior, pero es diferente.
+ Optimización del código. Aquí es donde entra el lenguaje a utilizar, la calidad del código generado, usar ensamblador o no... esto no es tan importante por las micro-optimizaciones del código generado, lo que si que importa es el tamaño de las rutinas, donde el ensamblador gana siempre.
Pero luego están las optimizaciones del compilador como desenrollo de bucles, vectorización, reorganización de las instrucciones para evitar stalls,... y AQUI es donde los compiladores, la mayoría de las veces, ganan a la mayoría de gente que escribe en ensamblador ( me incluyo ), aunque hay excepciones.
Estas optimizaciones son a dos niveles, lo dicho en la frase anterior por un lado y algo similar a lo dicho en el punto anterior, o sea, podríamos decir que "arreglan un poco la mala programación del programador", cosas como quitar código redundante, plegar ramas de código que son comunes en cierta parte, cambiar la estructura de árbol del código para que haya menos condicionales,...
------------------------
"El código en ensamblador optimizado para procesadores de hoy dentro de unos años no es optimo" puffff, esto es falso en un 95% ( por decir algo ). Y es aplicable por igual al ensamblador como a lenguajes de alto nivel.
+ He leído algún comentario que habla de que si haces todo en ensamblador te encuentras con que al de poco tiempo, eso que has optimizado ya no es óptimo para un procesador más nuevo.
Esto no es así. A nivel de instrucciones, lo que hagas hoy para x86 o x86-64, más del 90% se va a mantener igual para muchos, muchos años y los procesadores nuevos ejecutaran esas instrucciones con mejor rendimiento. Punto.
Cuando se habla de optimizar para un procesador nuevo, hablamos sobre todo de cosas no tanto del sistema operativo o de aplicaciones en general, sino de optimizar solo los algoritmos matemáticos o movimientos de memoria bestias, etc. y esto se hace en juegos, apps multimedia, edición de imagen, software de simulación industrial, médica y de otros dominios.
Sean echas en C, C++, Fortran o en ensamblador, no cambia: los algoritmos se ponen en rutinas optimizadas para SSEx, AVX y otros juegos de instrucciones y se decide a cuales llamar ( funciones metidas en tablas de punteros que apuntan a una implementación determinada, puestas en fase de inicialización tras detectar las características o funcionalidades opcionales del procesador, detectadas usando la instrucción CPUID, consultas al SO,... ). Así, mi código, ya sea hecho en C o ensamblador, tiene un 95% del código fijo, que se ejecuta en cualquier procesaodor y, para el 5% restante, detecta si tengo un core 2 duo o un core i7 y, para ciertas rutinas o librerías, según esa detección, llama a rutinas optimizadas para juegos de instrucciones SSEx o AVX o lo que sea.
------------------------
Pero todo esto son temas a nivel de rutinas, y aquí hablamos de Sistemas Operativos completos:
+ El mayor problema no es si un SO esta hecho en ensamblador o en C, sino lo ligero que es a un nivel o dos de mayor abstracción, esto es: como de engordado está el SO.
Hoy día todo el mundo piensa "bah, si hay RAM de sobra", pero luego tienes máquinas de 4GBs paginando a disco... y si, vamos sobrados de RAM, pero la velocidad a la que crece la RAM va ahí-ahí con la velocidad a la que crece la mierda. No me malinterpretéis, esa mierda puede que no ocupe ni el 10% de la RAM, pero esa mierda es un cáncer, lo es, por varios temas: uso de CPU, generación de conflictos, seguridad ( a más superficie de código, más agujeros de seguridad ),...
El problema no es usar ensamblador vs lenguajes de alto nivel, el problema es que no hay un par de nazis ( nazis necesarios ) diciendo NO a muchas cosas: SDKs que son flor de un día y que requieren servicios, librerías, capas, parches, ponzoña ( no siempre usables según necesidad ).
Y el problema no está tanto en el kernel del SO, sino en el conjunto de todo en general. Por ejemplo, en kernel de NT que conozco un poco, aunque si esta algo engordado, esta bastante bien, pero todo lo que le rodea… pufff.
Si yo quiero navegar, jugar a juegos, mandar emails, hacer ofimática, etc. ¿ por que cojones tengo miles de ficheros que no se ni lo que son ? Es más, le daré la vuelta: solo quiero tener aquello que se necesita.
Este es el mal endémico de todo SO hoy día:
a) todo es una metástasis multinivel donde todo vale y todo se añade
b) mucha de esa morralla no es de quitar y poner a nuestro gusto.
La filosofía del ensamblador no es tanto optimización de código, sino CONTROL, quiero controlar casi casi cada puto byte que se va a ejecutar. Y esto se puede mantener suficientemente en C, pero no se mantiene, por no hablar de cuando ya te vas a toda la parafernalia de lenguajes y componentes y más mierdas que ejecuta nuestra maquina hoy día.
Y que nadie me venga diciendo que es por necesidad, NO, nos hemos ido por derroteros muy difíciles de retroceder... incluso a alguien que necesite, por ejemplo un lenguaje de scripting porque el desarrollo es más rápido, pues bien, que instale su python o lo que sea y lo use. No me refiero a eso ( que habría que ver si muchas de esas cosas no podían haberse hecho con una filosofía mucho más conservadora; ejemplo: LUA y otros ) sino al que todo está inflado y sucio en general, es el "Síndrome de Diógenes informático".
Para acabar: ¿ Sabéis una cosa que sin ser importante del todo si es indicativa de que no adolece del engorde de la mayoría de SOs ? MenuetOS ejecuta la mayoría de cosas, incluidas todas las aplicaciones y demás, en la cache L2 de muchos procesadores. ¿ Que os parece eso ? Es un poco por estar hecho en ensamblador y un mucho porque tiene LO JUSTO.
Hay una frase en el diseño que dice algo así como: un buen diseño no es aquel donde ya no queda nada que añadir, un buen diseño es aquel donde ya no queda nada que quitar.
Perdón por la chapa O;)
#70 Si google hubiese hecho un sistema operativo… pero compró una compañía que tenía una máquina virtual, y asi todos las apps de android van emuladas en un jit a lo java. Y así les llevará hasta el 2060 alcanzar el aprovechamiento de los dispositivos que alcanza apple en iOS con metal.
Capas sobre capas y mas capas, eso si se puede ejecutar android hasta en un mechero a pedales.
Un sistema operativo en tiempo real no es una broma, ni una machada, y en determinados ámbitos como el científico se necesita.
Ahhh!! Si se puede ejecutar el Doom, lo compro
#108 Yo interpreto el mensaje de #3 como una descripción histriónica de una aversión que tiene ciertos fundamentos. Porque las capas de abstracción tienen sus ventajas pero son proclives a acumular bastantes inconvenientes. Y dicho de otro modo, tú lo usabas para ejemplificar el bajo nivel de los comentarios, y a mí me pareció que el que lo redactó hizo algo ameno de un tema ya trillado.
No soy ni de lejos el más adecuado para opinar sobre esto, pero me parece que lo encomiable de GNU/Linux es más su idea de la reutilización del código que no la implementación de capas de abstracción.
Un saludo, y buenas noches.
#69 ... y la notícia viene a decir que han escrito un libro a base de gruñidos.
Unos opinarán que sería la manera más eficiente aunque muy laboriosa de hacerlo y otros que es un esfuerzo inútil habiendo como hay idiomas que simplifican la transmisión de información.
#103 Yo lo he visto en teléfonos de 60 €, y no me parece que vaya lento.
#86 a ti te la pela como se hagan las cosas. Las quieres y punto.
A mi me la pela lo que tu quieras o lo que tu opines. Me la pelas.
Y no te sientas ofertas ofendido. Te entiendo perfectamente.
Pero mereces el mismo respeto que das.
#13 "potable". Depende de lo que uses.
#20 no puedo estar menos de acuerdo contigo, lo siento. El tiempo libre de cada uno es sagrado.
#20 Yo cuando alguien me pide un negativo, no me puedo contener.
#43 En asm puedes aprovechar el 100% del ordenador 64bits y gpu incluidas. Y no, ningun otro medio de programación aprovecha el 100%.
Uhmmm, a ver como digo todo lo que me viene a la cabeza y quede medio bien...
Quizá por falta de conocimientos o por repetir mitos y demás pero estamos confundiendo y mezclando cosas, y hay mitos hacia los dos lados de la discusión.
------------------------
Ensamblador, C, otros, lenguaje vs librería, código generado...:
+ Las rutinas escritas en ensamblador son, aun casi sin querer ir a hacer buen código, muy pequeñas, no hay instrucciones superfluas y hacen justo lo que deben, ni más ni menos.
+ Los lenguajes de alto nivel, aun poniendo el compilador en optimize for size ( a menudo, indirectamente mejor que optimizar para velocidad, salvo en algoritmos con mucho bucle, donde el desenrollo de bucles sí ayuda ) desensamblas el código y a menudo te tiras las manos a la cabeza con la de instrucciones o construcciones superfluas que te encuentras ( y hablo de compiladores de MS, GCC,... quizá los de intel no pequen tanto, pero hace mucho que no veo código de eso ).
Por ejemplo, la gestión de marcos de pila para funciones, con un buen planning de registros y demás puedes evitarlo por completo en ensamblador, en x86-64 esto ha mejorado gracias a tener 16 registros normales en vez de 8 como en 32 bit, y el ABI ( el conjunto de convenciones de llamada, preservar registros, etc. ) aprovecha esos 16 registros, asique ya es algo más limpio, pero aún hay cosas mejorables.
NOTA: También es verdad que parte de este código superfluo es por seguir unos estándares y hacer que la interoperabilidad entre diferentes módulos/librerías sea posible, que la depurabilidad de las rutinas sea algo mejor, etc.
+ Antes ( época de primeros pentium y en adelante ) se programaba en ensamblador pensando en el pairing de instrucciones en el pipeline, evitando stalls ( periodos donde el procesador que ejecutaba varias instrucciones al mismo tiempo "paraba" un poco a esperar a que operaciones necesarias para poder hacer otras operaciones se completaran ) por cadenas de definición-uso muy cercanas, haciendo hinting a los saltos condicionales en bucles o incluso cambiando "if"s por indexación según multiplicandos ligados a condición... vamos, mucha "magia negra".
+ Hoy día todo esto lo hace el mismo procesador, no hay procesador que no funcione a nivel de microinstrucciones hoy día. Hay una circuitería que decodifica las instrucciones en micro-operaciones, las reordena y hace mil virguerías más y, por mal que este hecho todo, la cosa va muy fina ( al menos en x86 o x86-64 ).
* El problema no es tanto esa optimización enfermiza, el problema es la morralla que se evita usando ensamblador o al menos C. Hay muchos niveles de optimización:
+ Optimización en el diseño, sea en algoritmos o en la organización del código en sí, esto es lo más importante ( hacer diseños simples y compactos, organizar las matrices de manera que haya "shortcuts" matemáticos que optimicen el algoritmo a nivel conceptual, aplicar conocimientos teóricos, ... son ejemplos, sin más )
+ Optimización en el código. No hablo aun de si es C o ensamblador, hablo de que un bucle para recorrer un array puede hacerse peor o mejor incluso a nivel de pseudocódigo o "receta escrita". Esto es bastante importante y esta medio-difuso con el punto anterior, pero es diferente.
+ Optimización del código. Aquí es donde entra el lenguaje a utilizar, la calidad del código generado, usar ensamblador o no... esto no es tan importante por las micro-optimizaciones del código generado, lo que sí que importa es el tamaño de las rutinas, donde el ensamblador gana siempre.
Pero luego están las optimizaciones del compilador como desenrollo de bucles, vectorización, reorganización de las instrucciones para evitar stalls,... y AQUI es donde los compiladores, la mayoría de las veces, ganan a la mayoría de gente que escribe en ensamblador ( me incluyo ), aunque hay excepciones.
Estas optimizaciones son a dos niveles, lo dicho en la frase anterior por un lado y algo similar a lo dicho en el punto anterior, o sea, podríamos decir que "arreglan un poco la mala programación del programador", cosas como quitar código redundante, plegar ramas de código que son comunes en cierta parte, cambiar la estructura de árbol del código para que haya menos condicionales,...
------------------------
"El código en ensamblador optimizado para procesadores de hoy dentro de unos años no es optimo" puffff, esto es falso en un 95% ( por decir algo ). Y es aplicable por igual al ensamblador como a lenguajes de alto nivel.
+ He leído algún comentario que habla de que si haces todo en ensamblador te encuentras con que al de poco tiempo, eso que has optimizado ya no es óptimo para un procesador más nuevo.
Esto no es así. A nivel de instrucciones, lo que hagas hoy para x86 o x86-64, más del 90% se va a mantener igual para muchos, muchos años y los procesadores nuevos ejecutaran esas instrucciones con mejor rendimiento. Punto.
Cuando se habla de optimizar para un procesador nuevo, hablamos sobre todo de cosas no tanto del sistema operativo o de aplicaciones en general, sino de optimizar solo los algoritmos matemáticos o movimientos de memoria bestias, etc. y esto se hace en juegos, apps multimedia, edición de imagen, software de simulación industrial, médica y de otros dominios.
Sean hechas en C, C++, Fortran o en ensamblador, no cambia: los algoritmos se ponen en rutinas optimizadas para SSEx, AVX y otros juegos de instrucciones y se decide a cuales llamar ( funciones metidas en tablas de punteros que apuntan a una implementación determinada, puestas en fase de inicialización tras detectar las características o funcionalidades opcionales del procesador, detectadas usando la instrucción CPUID, consultas al SO,... ). Así, mi código, ya sea hecho en C o ensamblador, tiene un 95% del código fijo, que se ejecuta en cualquier procesaodor y, para el 5% restante, detecta si tengo un core 2 duo o un core i7 y, para ciertas rutinas o librerías, según esa detección, llama a rutinas optimizadas para juegos de instrucciones SSEx o AVX o lo que sea.
------------------------
Pero todo esto son temas a nivel de rutinas, y aquí hablamos de Sistemas Operativos completos:
+ El mayor problema no es si un SO esta hecho en ensamblador o en C, sino lo ligero que es a un nivel o dos de mayor abstracción, esto es: como de engordado está el SO.
Hoy día todo el mundo piensa "bah, si hay RAM de sobra", pero luego tienes máquinas de 4GBs paginando a disco... y si, vamos sobrados de RAM, pero la velocidad a la que crece la RAM va ahí-ahí con la velocidad a la que crece la mierda. No me malinterpretéis, esa mierda puede que no ocupe ni el 10% de la RAM, pero esa mierda es un cáncer, lo es, por varios temas: uso de CPU, generación de conflictos, seguridad ( a más superficie de código, más agujeros de seguridad ),...
El problema no es usar ensamblador vs lenguajes de alto nivel, el problema es que no hay un par de nazis ( nazis necesarios ) diciendo NO a muchas cosas: SDKs que son flor de un día y que requieren servicios, librerías, capas, parches, ponzoña ( no siempre usables según necesidad ).
Y el problema no está tanto en el kernel del SO, sino en el conjunto de todo en general. Por ejemplo, en kernel de NT que conozco un poco, aunque sí esta algo engordado, esta bastante bien, pero todo lo que le rodea… pufff.
Si yo quiero navegar, jugar a juegos, mandar emails, hacer ofimática, etc. ¿ por que cojones tengo miles de ficheros que no se ni lo que son ? Es más, le daré la vuelta: solo quiero tener aquello que se necesita.
Este es el mal endémico de todo SO hoy día:
a) todo es una metástasis multinivel donde todo vale y todo se añade
b) mucha de esa morralla no es de quitar y poner a nuestro gusto.
La filosofía del ensamblador no es tanto optimización de código, sino CONTROL, quiero controlar casi casi cada puto byte que se va a ejecutar. Y esto se puede mantener suficientemente en C, pero no se mantiene, por no hablar de cuando ya te vas a toda la parafernalia de lenguajes y componentes y más mierdas que ejecuta nuestra maquina hoy día.
Y que nadie me venga diciendo que es por necesidad, NO, nos hemos ido por derroteros muy difíciles de retroceder... incluso a alguien que necesite, por ejemplo un lenguaje de scripting porque el desarrollo es más rápido, pues bien, que instale su python o lo que sea y lo use. No me refiero a eso ( que habría que ver si muchas de esas cosas no podían haberse hecho con una filosofía mucho más conservadora; ejemplo: LUA y otros ) sino al que todo está inflado y sucio en general, es el "Síndrome de Diógenes informático".
Para acabar: ¿ Sabéis una cosa que sin ser importante del todo sí es indicativa de que no adolece del engorde de la mayoría de SOs ? MenuetOS ejecuta la mayoría de cosas, incluidas todas las aplicaciones y demás, en la cache L2 de muchos procesadores. ¿ Que os parece eso ? Es un poco por estar hecho en ensamblador y un mucho porque tiene LO JUSTO.
Hay una frase en el diseño que dice algo así como: un buen diseño no es aquel donde ya no queda nada que añadir, un buen diseño es aquel donde ya no queda nada que quitar.
Perdón por la chapa O;)
creo que la cuestion que ha hecho a menuetOS famoso no es que sea en ensamblador, porque linux esta escrito en c con muchas instrucciones de ensamblador, y punteros y tal. Lo que hace reto a menuetOS es que se han fijado como limite ocupar un disco de 3.5
#11 uf, no estoy muy de acuerdo con eso, ¿eh?
#30 Pues #11 tiene toda la razón. Hay cosas que las máquinas hacen mejor que los humanos y emitir código es una de ellas
#3 tampoco creo que seamos micos. Bueno yo si
#76 boost es c++ . Y bueno . originariamente UNIX se escribio en C para portarlo entre maquinas.
#47 conoces alguna pagina de algoritmica?
Es un tema interesante, muy importante en programacion pero que se toca poco.
Es curios lo que pueden hacer algoritmos muy pequeños. Me acuerdo un programa de 4k en JScrip de 4 en raya y me ganaba. A la 3 o 4 vez me decia ahora si voy a poner interese y me ganaba, se me ponia una cara de tonto.
Luego ya le pillabas el truco. Es como el Jaque al pastor del ajedrez si no lo conoces te gana siempre.
En esta pagina he encontrado algoritmos que no conocia.
http://www.strchr.com/
Yo creo que hay optimizaciones que estan mas basadas en el micro que la puede hacer mejor el compi y otras que son más relacionadas con los algoritmos que se quieren hacer que el compilador no sabe mejorar, porque tampoco sabe muy bien que objetivo tiene el programador. Pero muchas de ellas se puedn hacer en lenguajes tipo C.
La optimizacion humana tambien puede ser contraproducente.
http://diegocg.blogspot.com/2011/06/error-procesador-demasiado-inteligente.html
Para acabar estrellados contra unas maquinas que ya en el firmware tienen backdoors para que se meta la NSA...
"Puede caber en un diskette"
Los sistemas operativos deberían estar escritos en brainfuck.
#46 Bueno, apretujándolo todo bien arrejuntadito no sabes lo que puede llegar a caber en diskettes.
#54 Cuando un humano crea una herramienta es para utilizarla, no para volver a hacer las cosas desde cero sin utilizarla. Por otro lado, no se si has oído hablar del Machine Learning .
Son programadores Vascos?
#88 Muy ilustrativo. Gracias. Sirvan tus observaciones para descubrir los oscuros entresijos de una broma jocosa.
Y yo que pensaba que por saber formatear ya era un hacker.. Jajajja
#92 No critico que no te gusten las capas de abstracción, me parece perfecto que no te gusten, lo que me fastidia es que tratéis los avamces como retrocesos, muy habitual en la comunidad linuxera por cierto, si por muchos fuera seguiríamos en la cueva haciendo fuego con palos y piedras porque claro, es lo más "puro",
Y para terminar, nadie ha dicho que tu opinión sea de bajo nivel, es más, me parece una opinión muy útil y respetable sólo que no la comparto.
#101 En caso de que sepan programar bien en C sigue dependiendo del compilador generar el código sin bugs. Un compilador como el gcc es robusto y no generará errores, pero añadiendo varias lineas de código de protección ante fallos no previstos, por lo que igualmente el rendimiento será menor. Primero es la seguridad del código, después la optimización.
Evidentemente la asignación de registros es una de las partes principales de un compilador, sin embargo el compilador siempre optimiza sobre el programa en C. El único compilador que sería capaz de optimizarlo a lo máximo seria aquel capaz de analizar tu código, entender todo lo que hace, tirarlo a la papelera y escribir el suyo propio.
Yo en mi marcapasos sólo quiero MinuetOS. 💖
#77 si, son c++ envenenadas hasta el paroxismo de templates. Por eso decía que es offtopic.
#32 De verdad te crees o entiendes una mínima parte de todo eso que dices?
#121 Perfecto!¡
#3 Te he votado negativo porque has dicho una soberana gilipollez. El código de aplicaciones no tiene que ser óptimo, tiene que ser mantenible. Y te aseguro que el ensamblador, cualquiera, dista bastante de ser mantenible. Además de que también tiene que ser portable y otra serie de características que no vienen al caso. Y eso sólo se consigue con lenguajes de alto nivel.
Además de que, hoy, cualquier compilador moderno es capaz de producir muchísimo mejor código ensamblador que cualquier desarrollador.
No hablemos ya de las capas esas de las que te quejas. Esas capas también están para algo. Qué casualidad, ¿no? Entre otras cosas para que un programador que quiera hacer un nuevo componente para el sistema operativo no tenga que escribir todo el código de todas las partes que necesita, sino que el propio sistema operativo se las de para facilitarle el trabajo. Y te aseguro que este sistema operativo, aunque esté hecho en ensamblador, también tiene todas esas capas.
Y lo peor de todo es que eres el comentario más votado. Ay…
#33 Bill Gates podría decir ahora que con 64 bits direccionas todo lo que haga falta
¿Está mal pedir que alguien nos explique de qué va la noticia a aquellos que no entendemos nada de programación?
#127 Aquí están las instrucciones para conectarte a internet:
http://www.menuetos.net/vbset.htm
Pero yo no lo he conseguido. Algo estaré haciendo mal
#54 el demonio.
#116 escribir ASM es ineficaz en productividad, se tarda mucho y es difícil de mantener. Eso es obvio.
Pero no es verdad que un compilador "gane" a un programador de ASM que sepa lo que hace y hoy en día de hecho en algunos puntos se sigue usando.
Por ejemplo yo tengo librerías de matrices en ASM ARM porque simplemente en C no puedes usar bien la vectorización. El compilador de C (armcc o gcc) puede apañar a veces, pero tienes que ayudar mucho al compilador y ni de lejos es tan óptimo como ASM.
Como se hacen millones de cálculos con matrices por frame es un punto crítico y sigue saliendo a cuenta el ASM.
Otro ejemplo seria MMX, SSE,...son cosas que simplemente C no tiene forma de expresar y el compilador está limitado porque tiene que literalmente inventarse el código. No llega.
Otra cosa es que estas cosas estén en lo más profundo de las librerías o motores y un programador normal ni sepa que existen, pero ahí están.