[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]
> --- Cristian Othon Martinez Vera <cfuga en itam mx>
> wrote:
>>Estoy de acuerdo. En cualquier libro de programacion
>>de manufactura relativamente reciente encontraras que
>>la verdad de la vida es la programacion orientada a
>>objetos. Pero desafortunadamente, siempre existe una
>>diferencia entre el texto academico y la Vida
>>Real(mr). Las ventajas de C++ con respecto a C
>>desaparecen porque en ambos tienes que manejar
>>apuntadores, y administrar la memoria sin utilizar un
>>recolector de basura. Las maravillosas ventajas de
>>OOP (encapsulamiento, polimorfismo, herencia, reuso
>>de codigo) se esfuman cuando desbordas la pila, o
>>tienes fugas en la memoria, sin importar que haya
>>sucedido en una funcion, o en un constructor de
>>clase. Combinado esto con algunos 'goto's,
>>indispensables en ambos lenguajes, puedes hacer
>>spaguetti estructurado u orientado a objetos, a tu
>>eleccion.
>>Puedes solucionar algunas cosas utilizando
>>Objective-C, pero muchos ni siquiera lo han
>>escuchado mencionar. :-|
>>De verdad es mas facil depurar un nucleo orientado
>>a objetos multihilos? Como puedes determinar cual de
>>los hilos fallo, a partir de la informacion de
>>volcado de memoria? Como puedes depurar un sistema,
>>si el objeto que administra la memoria muere, sin
>>tener tiempo de notificar (por paso de mensajes) al
>>objeto que administra el sistema de archivos para
>>generar un volcado de memoria? Ojo, no estoy diciendo
>>que sea imposible, pero las soluciones para estos
>>problemas no son triviales, y no facilitan en nada el
>>desarrollo de un nucleo de dichas caracteristicas.
>
> *****
> Ahora resulta que la programación OO no sirve para
> nada, que no ofrece ventajas sobre la programación
> estructurada. Nunca había escuchado algo así.
> O sea que todos los doctores en ciencias de la
> computación están equivocados, tu sabes mas que ellos,
> si es así, mis respetos.
> *****
Epa epa. Yo no dije que la programacion orientada a objetos no sirve. Voy
a ser puntual para aclarar mi posicion:
- C++ no es un lenguaje muy bueno para programacion orientada a objetos,
porque, al preservar la compatibilidad con ciertos aspectos de C, permite
salirse de un esquema estricto OOP y cometer los mismos errores que en C
llano y directo. Para nuestra mala fortuna, los lenguajes que son
estrictos para OOP (Smalltalk, Java, Python, por mencionar algunos), no
se utilizan aun para desarrollo de sistemas operativos.
- Se pueden hacer malos programas, tanto estructurados, como orientados a
objetos. El utilizar una filosofia u la otra no asegura automaticamente
facilidad de desarrollo y depuracion.
- El dise~o de Hurd es muy bonito en el papel, pero en la practica es muy
dificil de depurar, y esto hace lento su desarrollo. La version 0.2 salio
en 1997, y no hay indicios de que la version 0.3 (o la 1.0) aparezca en
un futuro muy cercano.
>> Ahora con los clusters, Como incrementas su
>>eficiencia con multihilos, cuando el cuello de
>>botella principal en un cluster es la comunicacion
>>entre los nodos?
>
> *****
> Igualmente, debemos creer que todos los doctores en
> ciencias de la computación, sobre todo los
> especialistas en cómputo paralelo están equivocados, y
> que un kernel construido con programación OO no ofrece
> ninguna ventaja para el supercómputo.
> *****
Computo paralelo no es equivalente a computo distribuido. Cuando trabajas
con computo paralelo, utilizas hardware especializado (como por ejemplo
simputers) y software especializado (como el lenguaje OCCAM), y NO
escribes programas orientado a objetos, sino programas paralelos.
Cuando trabajas con computo distribuido trabajas con cumulos (o clusters)
y con paso de mensajes (como PVM, o HIPPI). En ambos paralelizas tareas,
pero en computo paralelo generalmente se resuelve dentro del mismo
hardware, y en computo distribuido entregas a cada nodo la tarea
paralelizada a resolver, y al terminar cada nodo, regresa su respuesta al
controlador de nodos, quien casi siempre muestra el resultado final.
La ventaja que ofrece HURD para los cumulos es que, al ser inherente al
nucleo la comunicacion por paso de mensajes, la adicion de nodos es
transparente, ya que es igual que se comunique a un proceso dentro de la
misma maquina, que a un servidor remoto. Por supuesto, esto sera cuando
el soporte para el paso de mensajes del nucleo HURD a traves de la red
funcione, lo cual no sucede el dia de hoy.
Despues de las aclaraciones anteriores, cabe mencionar que los problemas
a resolver en computo paralelo y distribuido son:
- Como determinar si una tarea es paralelizable o no?
- Como disminuir la latencia en la comunicacion para maximizar el tiempo
de respuesta?
Para responder estas preguntas no es relevante si la solucion es
estructurada u orientada a objetos. Ninguna de las dos filosofias de
programacion ofrece una solución para paralelizar tareas, y la latencia
se combate con eficiencia en la comunicacion entre los elementos que
realizaran el computo. Y en este aspecto, los lenguajes OOP tienen un
"overhead" que en muchas ocasiones los hace impracticos.
>>Y como último detalle: no es indispensable que tu
>>núcleo sea orientado a objetos para poder crear
>>nuevas extensiones. En Linux, como en cualquier otro
>>sistema operativo moderno, puedes crear controladores
>>sin necesidad de reiniciar y/o interferir con otros
>>usuarios. Y de cualquier forma, hay modificaciones o
>>extensiones que (por el momento), te forza a
>>reiniciar tu equipo. En este momento pienso en el
>>administrador de memoria, aqui se puede agregar otros
>>mas.
>
> *****
> Las creación de extensiones y controladores sin
> interferir con los demás usuarios y sin necesidad de
> reiniciar el equipo son nada mas unas de las ventajas,
> también bajo este esquema se podrá tener mas
> privilegios sin necesidad de ser root, es decir se
> pueden hacer mas modificaciones sin interferir para
> nada con otros usuarios y sin poner en riesgo nada del
> sistema.
> http://www.gnu.ai.mit.edu/software/hurd/hurd.html
> http://www.gnu.org/software/hurd/hurd.html
> *****
Lo que describes son ACL (Access Control Lists), que te permite asignar
de forma granular privilegios para cada uno de los recursos de tu
sistema, y no es ninguna novedad de HURD; si mal no recuerdo, conoci a
estos bichos cuando utilice VMS (Uuuuuuh!). Si alguien necesita en este
momento un control de ese tipo en un nucleo de codigo abierto, no
necesita esperar a HURD: lo unico que necesita es aplicar el parche de
grsecurity para Linux, o utilizar FreeBSD u OpenBSD (no lo puedo asegurar
para NetBSD, no me ha tocado lidiar con eso). El inconveniente es la
administracion de ACLs, pero eso es otro tema. :-)
>>Desafortunadamente, le falta mucho a HURD para
>>convertirse en una alternativa viable a cualquier
>>otro sistema operativo que se encuentra en produccion
>>en estos dias. Las mismas dificultades que he
>>mencionado anteriormente hacen mas lento su
>>desarrollo (no mas rapido, como argumentas), y se
>>vuelve tedioso trabajar con el.
>>Toma en cuenta que funcionara de maravilla cuando la
>>plataforma que ofrece este madura, pero esa
>>plataforma ni siquiera esta completa en este momento.
>>No quisiera ser ave de mal aguero, pero, si HURD
>>llega a una version 1.0, sera simplemente un juguete
>>academico mas en desuso, como Minix, o Amoeba.
>
> *****
> El profesor Andrew Tanenbaum desarrolló Minix con
> fines puramente académicos, este fue el primer Unix
> para PCs, el solo se preocupó por alcanzar una pequeña
> versión estable y la congeló, fue Linus Torvalds que
> al ver la renuencia del profesor Tanenbaum para
> superar las limitaciones de Minix, quien argüía que el
> sistema debía mantenerse lo mas sencillo posible para
> seguir siendo apto para la enseñanza básica en el
> diseño de lo sistemas operativos, quien decide tomarlo
> como base para la creación de Linux. Igualmente el
> profesor Tanenbaum desarrollo Amoeba con el mismo
> propósito, y yo no los llamaría juguetes.
> Hurd, por el contrario desde sus inicios siempre a
> sido un proyecto ambicioso propuesto por Richard
> Stallman quien además fundó GNU y la filisofía de
> código abierto, el problema de Hurd fue que hace 20
> años la capacidad del hardware estaba muy limitada y
> hablar de programación OO para el desarrollo de un
> kernel era demasiado.
> *****
Quien utiliza Minix o Amoeba el dia de hoy? Tuvieron su momento de
relevancia, pero el dia de hoy son reliquias historicas. Al paso que va
el desarrollo de Hurd, corre el riesgo de acabar en el museo antes de ver
la luz del dia.
Y en cuanto al problema de Hurd, Richard Stallman opina diferente:
"This part of the program had been done already in Mach and we expected to
debug the Hurd servers as user programs. But it took a long time to make
that possible and the multi-threaded servers that send messages to each
other have turned out to be very hard to debug. Making the Hurd work
solidly has stretched on for many years". La entrevista completa se
encuentra en
http://www.blonnet.com/businessline/ew/2001/10/01/stories/0101a20g.htm
Afortunadamente para el proyecto GNU, la capacidad del hardware nunca fue
una limitante para el desarrollo; tampoco si era orientado a objetos o
no.
>>De verdad el tedio de programar estructuradamente
>>impide el desarrollo posterior? De verdad el hecho
>>que el codigo sea escrito en C es un problema para
>>Linux? Yo diria que al contrario. En realidad, la
>>cantidad de personas que hace programacion
>>estructurada es mucho mayor que la que hace
>>programacion orientada a objetos. Y la cantidad de
>>programadores que conocen C es mayor que la que
>>utiliza C++. Ahi Linux aprovecha una masa critica
>>importante de desarrolladores, que pueden entender,
>>modificar y actualizar codigo en este momento, no en
>>algun futuro feliz donde todo se vuelva mas facil.
>
> *****
> La masa de programadores se seguirá aprovechando en
> Hurd, ya que el desarrollo de aplicaciones puede
> seguirse haciendo con solo programación estructurada.
> Los encargados de sacar las nuevas versiones del
> kernel son siempre solo una elite como en el caso de
> Linux.
> http://www.debian.org/ports/hurd/
> *****
De acuerdo. Pero para el desarrollo de HURD requieres una elite mas
especializada, que no solamente sepa programar (y depurar) en C de forma
decente. Tambien debe conocer con cierta profundidad:
- Micronucleos
- Multihilos
- Cliente servidor
- Paso de mensajes
Asi que esa elite tiende a ser menor que aquellos que pueden contribuir a
Linux.
>>De acuerdo: Linux debe ser superado. No me queda la
>>menor duda. Pero no he visto la menor pista para que
>>HURD corresponda al siguiente paso evolutivo de Linux
>>en un corto o mediano plazo.
>> Saludos
>
> *****
> Respeto tu opinión mas no la comparto, yo si veo las
> suficientes pistas para suponer que el siguiente paso
> son los kernel hechos con programación OO, el proyecto
> Darwin es el ejemplo viviente, en este están usando el
> kernel Mach 3.0 que es la base del OS X de Macintosh.
> http://developer.apple.com/darwin/
> http://www.macuarium.com/macuarium/actual/especiales/2000_01_18_graphicrevolution.shtml
> El movimiento open source no puede quedarse a la zaga,
> por ello ya se trabaja en Hurd y en otros.
>
> Saludos.
> *****
Otra confusion: no es lo mismo micronucleo (como Mach) que un nucleo
programado con filosofia orientada a objetos. Puedes programar un
micronucleo en ensamblador, y es dificil afirmar que el lenguaje
ensamblador de una maquina ofrece muchas facilidades para hacer algo
orientado a objetos.
Los micronucleos son importantes, es innegable. Pero tanto como "el
siguiente paso"? Los creadores originales de Mach dejaron de trabajar
sobre su proyecto en 1994, y antes de Darwin, Mach fue utilizado por OSF
para crear lo que ahora se conoce como Tru64 (antes conocido como Digital
UNIX, antes conocido como OSF/1). Mach se utiliza, no por su novedad,
sino por ser un micronucleo bien conocido; es software maduro que no es
dificil de adaptar para las necesidades particulares de algun fabricante.
Si alguien quiere verse realmente innovador utilizando un micronucleo,
podria utilizar L4.
OS X es importante. Pero no porque utilice un micronucleo, o un
micronucleo desarrollado en base a objetos. Su importancia radica en:
- Apple (una empresa) desecho su desarrollo propio de sistema operativo
(System 9.x y anteriores) y decidio adoptar un UNIX libre (FreeBSD, un
proyecto comunitario y voluntario) como base. El uso de Mach le permite a
Apple mantener el control sobre el desarrollo del hardware.
- Logro integrar una interfaz innovadora (Aqua) a un sistema UNIX
tradicional.
- Ofrece grandes facilidades para los desarrolladores, con tecnologias
como Cocoa, Carbon y Quartz, una API rica y abierta, y facilidades que no
se encuentran en otros sistemas operativos (el manejo de bibliotecas
dinamicas es impresionante).
Otra cosa que se debe aclarar es que HURD no utiliza Mach 3.0, sino un
desarrollo propio (GNUMach) derivado del codigo de CMU.
Ahora, regresemos al punto original: HURD es lo que sigue a continuacion
de Linux? Por lo que yo veo, no, y segun Antonio, si. Pero hacerla de
futurologos es muy incierto, no concede a ninguno la respuesta correcta,
y no tengo interes en contribuir con mas bytes al asunto. Por lo tanto,
sugiero una inocente apuesta, a mediano plazo: si [inserte el nombre de
su(s) deidad(es) predilecta(s) aqui] lo permite(n), ambos llegamos con
vida al martes 6 de noviembre de 2007, y HURD supero a Linux, invitare a
comer a Antonio. Si en esa fecha HURD no ha demostrado ser el siguiente
paso evolutivo de Linux, Antonio tendria que invitarme a comer. Y si
sucede que tanto Linux como HURD son irrelevantes, nos dividimos la
cuenta. De acuerdo? ;-)
Saludos
--
__(o< | Nombres/Names: Cristian Othón | cfuga en itam mx
\/|/ | Apellidos/Last Names: Martínez Vera | http://cfuga.net/
/_/_ | | http://linuxppp.com/
| "Pulchrum est paucorum hominum" - Horace
_______________________________________________
Ayuda mailing list
Ayuda en linux org mx
Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/