Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
Multiples vulnerabilidades en el kernel de linux | 11 comentarios (11 temáticos, editoriales, 0 ocultos)
Me pregunto (none / 0) (#1)
por melenas a las Sun Jul 25th, 2004 at 12:47:15 PM CET
(Información Usuario)

Me pregunto si quizás si el núcleo de Linux está en crisis debido a su arquitectura monolítica y difícilmente mantenible. Quizás si sigue avanzando es por la fuerza bruta de miles de programadores que programan, revisan y envían parches y nuevas características.

¿Quizás sea la hora de volver al núcleo microkernel? ¿una oportunidad para Hurd? ¿o volverá Tanembaum a vender licencias de Minix a 160$?


FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.


Recurrente el microkernel (none / 0) (#2)
por ridiculum a las Sun Jul 25th, 2004 at 08:43:14 PM CET
(Información Usuario)

Linux nunca ha sido microkernel, por mucho que tenga la posibilidad de cargar y descargar modulos, asi que dificilmente puede volver a algo que nunca ha sido.

[ Padre ]


Ya lo sé (none / 0) (#3)
por melenas a las Mon Jul 26th, 2004 at 01:56:49 AM CET
(Información Usuario)

Yo me refería que a finales de los ochenta y principio de los noventa parecía que se imponían los núcleos microkernel, estaba el proyecto Hurd (que no termina de salir) y el propio Minix, además de que por la mitad de esa misma década otros sistemas operativos como OS/2, Windows NT y un proyecto fracasado del que ya nadie se acuerda llamado Freedows 98 también lo utilizaba (o trataba de hacerlo) y que quizás Linux fuera en su época un paso atrás tecnológico.

Por ello digo que quizás Tanembaum tenía razón al decir que un núcleo monolítico es difícilmente mantenible frente al diseño de microkernel y a los últimos fallos de seguridad me remito, estamos plagados de ellos y aunque se resuelven rápidamente gracias a la infraestructura que provee el software libre, ésto hace que nos pensemos si no debemos volver la mirada a los núcleos microkernel.

Si sendmail está siendo sustituido por postfix y/o qmail, mucho más seguros y menos complejos y bind sustituido en varias ocasiones por djbdns (aunque no tanto debido al cerramiento de Bernstain en algunas cuestiones), puede que no esté lejos la hora de que la gente se ponga en serio con el Hurd o con otro proyecto paralelo de parecidas características.


FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.
[ Padre ]


Pues sí que te salen microkernels :) (none / 0) (#7)
por man ls a las Tue Jul 27th, 2004 at 01:33:12 AM CET
(Información Usuario)

Según Tanenbaum, aunque los de Microsoft vendieron que NT estaba basado en en un microkernel, era mentira cochina:
Microsoft afirmaba que Windows NT 3.51 era un microkernel. No lo era. Ni se parecía siquiera. Hasta ellos dejaron de decirlo con NT 4.0.
Lo mismo dicen de NeXT y Mac OS X: supuestamente basado en el microkernel Mach, en la práctica han tomado tantas cosas de FreeBSD que ya no tiene sentido decirlo. Los *BSD no usan microkernel ninguno de ellos, ¿verdad? Luego Tanenbaum sigue:
Algunos microkernels han tenido bastante éxito, como QNX y L4. No soy capaz de ver por qué la gente arma tanto ruido por una pérdida de rendimiento del 20% que puede causar un microkernel, cuando programan en lenguajes como Java y Perl que a menudo te hace perder rendimiento por un factor de 20x. ¿Qué problema hay con convertir un PC a 3.0 GHz en un PC a 2.4 GHz por un microkernel? Seguramente has tenido un sistema más lento que eso y estabas tan contento con él. Yo daría un 20% de rendimiento a cambio de un sistema robusto, estable, y sin muchos de los males que vemos en los sistemas operativos masivos de hoy.
No sé, no sé: los microkernels no acaban de despegar fuera de algunos sistemas en tiempo real, parece. Cuando todo el mundo se mueve en la misma dirección, algo debe haber, no sé si bueno o malo. Melenas, Linux (el kernel) será un paso tecnológico hacia atrás, pero compara con como van los de Hurd -- si hubiéramos tenido que esperar a que estuviera listo para usar un sistema operativo decente, a estas alturas estaríamos todos con algún *BSD, y leyendo *BSDToday, *BSDWN, escompos*bsd. Y a lo mejor, tan agusto :)

[ Padre ]


Panaceas (5.00 / 1) (#8)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Tue Jul 27th, 2004 at 11:24:26 AM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Yo daría un 20% de rendimiento a cambio de un sistema robusto, estable, y sin muchos de los males que vemos en los sistemas operativos masivos de hoy.
Tanenbaum puede decir lo que quiera, pero yo no me creo esto de las panaceas. Si piensa que porque sea un nucleo tenga una arquitectura microkernel, automáticamente va a ser más robusto, estable y sin bugs, es que no vive en el mundo real.

La arquitectura y las decisiones de diseño pueden ayudar, pero no van a evitar jamás que haya bugs.

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]


 
WNT es microkernel en la línea de Mach (none / 0) (#9)
por jorginius ("jorginius" en Google Mail) a las Tue Jul 27th, 2004 at 03:17:49 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Depende del cristal con que lo miras. Si consideras a Mach un microkernel entonces supongo que WNT deberías ponerlo en el mismo saco.

Por problemas de eficiencia (de propagación las interrupciones), Mach incluye en el nucleo los manejadores de dispositivos, además de la comunicación entre procesos, el manejo de las interrupciones y el soporte del diagrama de estados. En teoría ningún microkernel debería incluir tal cosa.

El WNT original incluye los drivers, igual que Mach, y además el subsistema de control de objetos (seguir la pista a los recursos y control de acceso de los mismo) y el sistema de archivos.

Por otra parte, si lo que quieres es un Linux microkernel existen implementaciónes servidor Mach (MkLinux), de NT (coLinux) o de L4 (L4Linux)

[ Padre ]


 
Stallman dijo en Valencia... (none / 0) (#5)
por pbenavent a las Mon Jul 26th, 2004 at 04:37:42 PM CET
(Información Usuario) http://www.benavent.org

Stallman dijo en Valencia...que los desarrolladores del microkernel pensaban tomar otro rumbo y abandonar Hurd en favor de otro microkernel.

Invito a la audiencia del congreso de Lliurex a que colaboraran en el proyecto, pero advirtió a los que quisiesen sumarse que hay qu ser muy buen programador (melenudo sí, tonto no)

Hay dinero de empresas en OSDL, y por eso se mueve, pero ¿lo hay en Hurd? ultimamente estoy escéptico con algunas cosas, detras de grandes desarrollos hay desarrolladores, detras de ellos alguién pagandoles la jornada completa ... y eso lo hacen empresas que legítima y loablemente apoyan el desarrollo de Linux. (Ir a la portada y leer el hilo sobre el fork de Gnome)

Si todos tomasen en consideración la firma de melenas no sería a veces tan necesario el apoyo de las empresas.

En cualquier caso: lo que me gusta de esto es la libertad, aún ando buscando hardware y tiempo -más lo segundo- para echarle un tiento a OpenBSD para frontal de mi LAN doméstica, aunque me asusta un poco la sintaxis para las reglas del firegüal.

--
"El hombre es la medida de todas las cosas"
Protágoras
[ Padre ]


Sintaxis de pf (5.00 / 1) (#10)
por ridiculum a las Wed Jul 28th, 2004 at 12:49:42 AM CET
(Información Usuario)

Que ese detalle no te tire para atras. A mi juicio, la sintaxis del pf.conf es una maravilla. Es tremendamente simple comparada con, lo que a mi juicio es, el follon de iptables. En la faq de pf tienes practicamente todo lo necesario para poder hacer un fw bastante decente, QoS incluido.

[ Padre ]


Sintaxis de pf (none / 0) (#11)
por iarenaza a las Thu Jul 29th, 2004 at 02:02:14 AM CET
(Información Usuario) http://www.escomposlinux.org/

Aun estando de acuerdo en que la sintaxis de pf es bastante buena, sin embargo echo en falta algo que con iptables se puede hacer: usar toda las posibilidades del lenguaje de programación del shell a la hora de crear las reglas. Algo como lo siguiente es imposible de hacer con pf (no la funcionalidad, sino el escribirlo de forma tan condensada):

for port in 22 80 443
do
     iptables -A INPUT -p tcp --dport $port -j ACCEPT
done
Si bien es cierto que en las ultimas versiones de pf se pueden definir variables, la excesiva rigidez de su formato (primero variables y solo variables, luego reglas de nat/rdr y solo nat/rdr y por ultimo reglas de filtrado) hacen que para mi sea menos "mantenible" el conjunto de reglas si esta es amplia (en mi caso alrededor de las 100 reglas en total, entre NAT/RDR y filtrado), al no tener todos los aspectos "logicos" de una misma accion juntos.

Supongo que tendrá su razón de ser, pero se me escapa.

Saludos. Iñaki.

[ Padre ]


 
Sin miedo hombre!! (none / 0) (#6)
por toomany a las Mon Jul 26th, 2004 at 07:10:49 PM CET
(Información Usuario) http://www.toomany.net

Verás cómo te alegras enormemente de haber instalado el OpenBSD. Es una auténtica maravilla donde las haya... Y si es por el tema de la documentación, podrás comprobar (mejor manera que esta ninguna) por tí mismo como, después de ver la documentación del OpenBSD, o de cualquier otro BSD, la documentación existente alrededor de GNU/Linux te parecerá corta, vieja y un puro caos.
Si quieres, me lo dices y te paso links para que no tengas problemas algunos con el sistema de filtrado PF.
¡¡Aaaahhh!! ¡Que increible la familia *BSD! XDDD


Have a nice day ;-) TooManySecrets
[ Padre ]


 

Multiples vulnerabilidades en el kernel de linux | 11 comentarios (11 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda