Crítica a HURD, kernel oficial de GNU, de la mano Neal Walfield y Marcus Brinkmann, dos de sus desarrolladores principales. Ha sido enviada a Usenix Annual Technical Conference 2007 para presentarla en este evento.(Vía Barrapunto).
#2:
¿alguien se va a leer eso antes de menear?, a eso hay que meterlo mano con tiempo y ganas.
Este SO si que es un monstruo, aunque me parece que todavia me quedan unos años para verlo correr.
De momento lo guardo a mis documentos y meneo.
¿alguien se va a leer eso antes de menear?, a eso hay que meterlo mano con tiempo y ganas.
Este SO si que es un monstruo, aunque me parece que todavia me quedan unos años para verlo correr.
De momento lo guardo a mis documentos y meneo.
Me quedo con esto: "Due to their centralized nature, monolithic kernels have a higher level view of how users and processes use resources [...] These abstractions can provide important hints regarding expected resource usage. A monolithic kernel, for instance, can relatively straightforwardly implement file based read-ahead. On the Hurd, these abstractions are implemented by user-space servers, which Mach does not only not regard as special but of which Mach has no additional knowledge. As such, by itself, Mach is only able to implement disk based read-ahead. Such optimization techniques cannot be reliably implemented in the respective user-space servers as these processes do not have information regarding memory pressure and thus cannot correctly determine how aggressively to act"
Traduciendo: Hay un solo ordenador y un solo hardware, y la manera más eficiente de gestionar ese hardware es a través de un solo árbitro que tenga disponible toda la información, no cien árbitros que cada uno no sabe qué está haciendo el otro y por lo tanto no pueden globalmente manejar el hardware de forma óptima, solo puede manejar de manera óptima su pequeño universo. Los de Hurd intentan justificarlo con que cada servidor sabe mejor que nadie qué recursos necesita y por lo tanto puede manejar más eficientemente sus recursos, pero globalmente siguen sin poder exprimir de manera eficiente el hardware.
Llevan desde el 84 trabajando en ello y apenas van por la 0.2, me pregunto si de verdad este proyecto avanza algo o es vaporware como ya comentan muchos.
#4 En la propia Wikipedia citan el desarrollo de Hurd como vaporware ("obsolete on delivery"): para que un producto sea vaporware no es necesario anunciar una fecha de salida y retrasarla continuamente (véase Longhorn/Vista), basta con que el desarrollo se alargue durante taaanto tiempo que la gente (¡y los programadores!) acabe pensando que nunca estará listo. Es igual que Duken Nukem Forever: aunque no puedas bajarte el código porque es cerrado, se considera vaporware porque está en desarrollo desde hace demasiados años.
Y en el caso de Hurd estamos hablando de nada menos que 23 años: eso en un campo que evoluciona tan increíblemente deprisa como es la informática resulta simplemente impensable.
¿Que faltan cosas? Cuando el propio Stallman dice que el desarrollo del sistema está dando muchos más quebraderos de cabeza de los que pensaban en un principio, "poco" no debe ser lo que falta por hacer...
Podrían hacer una pelicula con la historia de HURD, el primer desarrollador se pasó al lado oscuro... nada menos que a M$, lo cuenta Thomas Bushnell en una entrevista (en ingles, no he encontrado la transcripción): http://technetcast.ddj.com/tnc_play_stream.html?stream_id=381
(siguiendo #6) Oh, y se me olvidaba: Hurd argumenta que la técnica de los kernels resulta en una infrautilización de los recursos, a diferencia de su sistema. Lo que no dicen es que puesto que carecen de una gestión de memoria unificada, no pueden saber exactamente cuando una aplicación debe o no debe manejar sus recursos "eficientemente". En un kernel como linux, esa función podría implementarse de manera tan sencilla como una nueva señal, que se mandaría a los procesos cuando fuera necesario, obteniendo lo mejor de los dos mundos - si es que la "autogestion" de recursos es necesaria en algun entorno
Mecachis... y de verdad no hay forma de solucionar esos defectos?
Tenía yo muchas esperanzas en Hurd, pero que los mismos desarrolladores digan que Hurd solo sirve para aprender como no se deben hacer las cosas no es muy alentador.. ^^U
Una vez le preguntaron a Edisón que cómo habia descubierto la bombilla y él respondió que él sólo había descubierto millones de maneras de que no funcionara y una sola en la que si.
Así que si esos desarrolladores dicen "que Hurd solo sirve para aprender como no se deben hacer las cosas" es muy alentador creo yo. Puede quizá quieran decir como Edison.
Comentarios
¿alguien se va a leer eso antes de menear?, a eso hay que meterlo mano con tiempo y ganas.
Este SO si que es un monstruo, aunque me parece que todavia me quedan unos años para verlo correr.
De momento lo guardo a mis documentos y meneo.
Vaporware? Sabes qué es el vaporware? Si quieres puedes descargarte el código fuente. Otra cosa es que le falten cosas, pero vaporware no es.
Me quedo con esto: "Due to their centralized nature, monolithic kernels have a higher level view of how users and processes use resources [...] These abstractions can provide important hints regarding expected resource usage. A monolithic kernel, for instance, can relatively straightforwardly implement file based read-ahead. On the Hurd, these abstractions are implemented by user-space servers, which Mach does not only not regard as special but of which Mach has no additional knowledge. As such, by itself, Mach is only able to implement disk based read-ahead. Such optimization techniques cannot be reliably implemented in the respective user-space servers as these processes do not have information regarding memory pressure and thus cannot correctly determine how aggressively to act"
Traduciendo: Hay un solo ordenador y un solo hardware, y la manera más eficiente de gestionar ese hardware es a través de un solo árbitro que tenga disponible toda la información, no cien árbitros que cada uno no sabe qué está haciendo el otro y por lo tanto no pueden globalmente manejar el hardware de forma óptima, solo puede manejar de manera óptima su pequeño universo. Los de Hurd intentan justificarlo con que cada servidor sabe mejor que nadie qué recursos necesita y por lo tanto puede manejar más eficientemente sus recursos, pero globalmente siguen sin poder exprimir de manera eficiente el hardware.
Pues mientras yo sigo con mi Kelmer 2.6 Linux... Rula.
Llevan desde el 84 trabajando en ello y apenas van por la 0.2, me pregunto si de verdad este proyecto avanza algo o es vaporware como ya comentan muchos.
#4 En la propia Wikipedia citan el desarrollo de Hurd como vaporware ("obsolete on delivery"): para que un producto sea vaporware no es necesario anunciar una fecha de salida y retrasarla continuamente (véase Longhorn/Vista), basta con que el desarrollo se alargue durante taaanto tiempo que la gente (¡y los programadores!) acabe pensando que nunca estará listo. Es igual que Duken Nukem Forever: aunque no puedas bajarte el código porque es cerrado, se considera vaporware porque está en desarrollo desde hace demasiados años.
Y en el caso de Hurd estamos hablando de nada menos que 23 años: eso en un campo que evoluciona tan increíblemente deprisa como es la informática resulta simplemente impensable.
¿Que faltan cosas? Cuando el propio Stallman dice que el desarrollo del sistema está dando muchos más quebraderos de cabeza de los que pensaban en un principio, "poco" no debe ser lo que falta por hacer...
Podrían hacer una pelicula con la historia de HURD, el primer desarrollador se pasó al lado oscuro... nada menos que a M$, lo cuenta Thomas Bushnell en una entrevista (en ingles, no he encontrado la transcripción):
http://technetcast.ddj.com/tnc_play_stream.html?stream_id=381
Éste, a su vez, fue apartado del desarrollo de hurd por discrepancias con RMS sobre la licencia de la documentación, eso fue a finales de 2003, no se si luego hicieron 'las paces' o que pasó... el misterio envuelve a hurd:
http://lists.softwarelibero.it/pipermail/discussioni/2003-November/008465.html
He corregido el enlace, gracias a suntzu por el aviso
Edito: ¡BIBA!, esto me pasa por no fijarme en quien ha enviado la noticia
(siguiendo #6) Oh, y se me olvidaba: Hurd argumenta que la técnica de los kernels resulta en una infrautilización de los recursos, a diferencia de su sistema. Lo que no dicen es que puesto que carecen de una gestión de memoria unificada, no pueden saber exactamente cuando una aplicación debe o no debe manejar sus recursos "eficientemente". En un kernel como linux, esa función podría implementarse de manera tan sencilla como una nueva señal, que se mandaría a los procesos cuando fuera necesario, obteniendo lo mejor de los dos mundos - si es que la "autogestion" de recursos es necesaria en algun entorno
Mecachis... y de verdad no hay forma de solucionar esos defectos?
Tenía yo muchas esperanzas en Hurd, pero que los mismos desarrolladores digan que Hurd solo sirve para aprender como no se deben hacer las cosas no es muy alentador.. ^^U
#10 Nuncas has oido eso de...
Una vez le preguntaron a Edisón que cómo habia descubierto la bombilla y él respondió que él sólo había descubierto millones de maneras de que no funcionara y una sola en la que si.
Así que si esos desarrolladores dicen "que Hurd solo sirve para aprender como no se deben hacer las cosas" es muy alentador creo yo. Puede quizá quieran decir como Edison.