kiwnix@yahoo.es
raciel@x0und.net
Copyright © 2000 Ximian, Inc (C)
R: Mono es un proyecto libre y compatible patrocinado por Ximian, que consiste en desarrollar una plataforma de desarrollo libre y basada en Linux compatible con Microsoft .NET, Su objetivo es permitir que los desarrolladores de GNU/Linux desarrollen aplicaciones multiplataforma basadas en .NET. El proyecto mono implementará varias tecnologías desarrolladas por Microsoft que han sido enviadas al ECMA para su estandarización.
R: La iniciativa .NET es un esfuerzo de la compañía Microsoft que tiene limites poco claros, una parte de ese proyecto, es una arquitectura de desarrollo multiplataforma, Mono es una implementación de este entorno de desarrollo, pero no es una implementación de nada relacionado con la iniciativa .NET , por ejemplo Mono no es una implementación de passport, software como servicio o ****
R: Mono contiene un numero de componentes útiles para implementar nuevo software:
Una maquina virtual de lenguaje común de infraestructura (CLI) que contiene un cargador de clases, un Compilador en tiempo de ejecución (JIT), y unas rutinas de recolección de memoria.
Una biblioteca de clases que puede funcionar en cualquier lenguaje que funcione en el CLR (Common Language Runtime).
Un compilador para el lenguaje C#. En el futuro, podríamos trabajar en compiladores que generasen CIL (lenguaje intermedio) para el CLR (Entorno de ejecución del lenguaje común).
Windows tiene compiladores que compilan para la maquina virtual tales como: C++ Manejado (managed), Java Script, Eiffel, Component Pascal, APL, Cobol, Oberon, Perl, Python, Scheme, Smalltalk, Standard ML, Haskell, Mercury y Oberon.
El CLR y el Sistema de tipos común (CTS) permite que la aplicación y las bibliotecas sean escritas en una amplia variedad de lenguajes diferentes que compilen para "byte code"
Esto significa por ejemplo, que si defines una clase que haga una manipulación algebráica en C#, esa clase puede ser reutilizada en cualquier lenguaje que soporte el "CLI". Puede crear una clase en C#, una subclase en C++ y instanciar esa clase en un programa en Eiffel.
Un sistema de objetos único, sistema de hilos, bibliotecas de clases y sistema recolector de memoria pueden ser compartidos por todos estos lenguajes.
R: Puedes encontrar documentación aún no definitiva en la web grupo T3G ECMA aquí: Web T3G ECMA
R: Si, se están implementando las API's de las bibliotecas de clases de la plataforma .NET.
R: Cada cierto tiempo se hará, pero el objetivo actual es la interoperabilidad con el entorno de desarrollo de Microsoft, pero también se ofrecerá un conjunto de bibliotecas compatibles con ECMA.
R: Mono significa Mono en español, nos gustan los monos.
R: El motor de compilación en tiempo de ejecución para la arquitectura Intel x86 es usable, un interprete puede ser usado en maquinas no basadas en dicha arquitectura.
Las bibliotecas de clases no están todavía lo suficientemente maduras para ejecutar aplicaciones reales, pero si está interesado en probar mono, definitivamente puede empezar a probar cosas, ya que muchos programas se ejecutan correctamente.
El Compilador de C# ha hecho progresos significativos, puede incluso compilarse a si mismo ahora, pero aun no puede compilar las bibliotecas de clases, ya que hay varias características que aun no están implementadas.
R: Es prematuro fijar una fecha de liberación para el código, pero anticipamos que estará disponible sobre la mitad de 2002.
R: Consulta la sección de "Contributing" el la pagina web de Mono: Seccion de contribuciones
R: El proyecto mono esta interesado en contribuir a proveer las mejores herramientas a los programadores que desarrollan el sistema operativo libre, El proyecto también quiere contribuir a la interoperabilidad que permitirá a estos sistemas ajustarse a los estándares.
Para mas detalles puedes leer los **White Papers del proyecto mono** White Papers del proyecto mono
R: Ximian está interesada en proveer las mejores herramientas de trabajo a los programadores para desarrollar aplicaciones para el Sistema Operativo Libre. Para mas información lee la Pagina de definición del proyecto. Pagina de definicion del proyecto
R: Por supuesto que no. Ximian apoya el proyecto mono, pero la única forma de implementar algo de este tamaño es cuando toda la Comunidad de Software Libre se involucre. Visita la pagina de contribuciones Contribuciones" si quiere ayudar.
R: Ximian proveerá la mayor parte de sus recursos en hacer funcionar partes criticas del entorno de desarrollo y de ejecución. Una vez el proyecto este en un estado que sea útil para el mundo real, habrá alcanzado un numero suficiente de desarrolladores para mejorarlo.
R: Cuando mono este listo para ser distribuido y empaquetado, Ximian ofrecerá soporte y servicios comerciales para mono.
R: Mono sera ofrecido en varias etapas a medida que el proyecto madure. Habrá gente que solo requiera un subconjunto de tecnológicas, para estos, el desarrollo estará completo antes. Características mas avanzadas tomaran mas tiempo de desarrollo. Un calendario de soporte estará disponible en Junio de 2002
R: De muchas formas. Este proyecto nació de la necesidad de proveer herramientas mejoradas para la comunidad GNOME, y usara componentes existentes que han sido desapoyados para GNOME estén cuando estos estén disponibles. Por ejemplo se preve usar Gtk+ y Libart para implementar los API's Winforms y Drawings2D y se esta considerando usar soporte GObject.
R: Mono es demasiado nuevo para ser adoptado por esos grupos. Buscamos que las herramientas que mono provee sean adoptadas por programadores de software libre incluyendo a los miembros de la Fundación GNOME y el proyecto gnome en general.
R: Es todavía muy pronto para hablar de un cambio, Ninguna parte de Mono estará lista en los próximos seis meses, y una implementación completa esta mas o menos a un año de ser conseguida.
Nos gustaría que los desarrolladores de GNOME continuasen usando las herramientas existentes, bibliotecas y componentes. Las mejoras hechas a GNOME tendrán su impacto en Mono, ya que estas serán la parte no visible para varias clases.
R: Si, Mono incluirá un conjunto de clases para implementar y usar componentes Bonobo desde Mono. Mono siempre podrás escribir componentes bonobo fácilmente, tal y como .NET en Windows permite exportar componentes .NET a COM.
R: No, Mono no depende de Gnome, Solo se usan unos pocos paquetes producidos por el equipo GNOME, tal y como la biblioteca glib.
R: Si, seras capaz de escribir aplicaciones con GUI. De hecho es nuestro mayor objetivo. Mono proveerá las implementaciones de Windows.Forms y las de Gtk#.
R: Gtk es un conjunto de recubrimientos para el toolkit Gtk+ para C# (y otros lenguajes que usen CIL). System.Windows.Forms es un API definido por Microsoft para escribir aplicaciones con GUI.
R: No. El Director técnico de Ximian, Miguel de Icaza tienen una buena relacion con el arquitecto de software David Stutz, pero eso esta fuera de todo contacto. Microsoft esta interesada en otras implementaciones de .NET y esta contribuyendo a hacer la especificación ECMA mas precisa para este fin. Los representantes de Ximian han hablado también con Sam Ruby del comite ECMA TG3 para discutir del mismo tema.
R: No. Microsoft ha probado con CLI y el lenguaje C# que es posible crear una fundación poderosa para que muchos lenguajes interoperen. Nosotros siempre tendremos esto.
Hasta si los cambios que ocurriesen en la plataforma fuesen indocumentados, la plataforma existente tendría valor por si misma.
R: Si, El proyecto mono se ha escrito tomando la especificación ECMA y el material impreso sobre .NET.
R: No. Mono no esta relacionado con la iniciativa de Microsoft de software como servicio.
P: ¿Esta el proyecto Mono relacionado con El esfuerzo de "Microsoft HailStorm"?, ¿Ximian apoya Hailstorm?
R: No. El proyecto Mono esta dirigido a proveer un conjunto de herramientas compatibles con la plataforma de desarrollo .NET . Esto no incluye o requiere, que apoyemos la estrategia HailStorm basada en MS Passport que es parte de Windows XP y otros servicios.
R: No. MS Passport no esta relacionado con ejecutar aplicaciones compatibles con .NET realizadas con las herramientas de Mono. La única cosa que necesitara es un Compilador en tiempo de ejecución (JIT).
R: Una "aplicación 100% .NET" es la que usa las API's definidas bajo el espacio de nombres System y no hace uso de P/Invoke. Estas aplicaciones se ejecutarían sin cambios en Windows, Linux, HP-UX, Solaris, MacOS X y otros.
P: Si Microsoft liberase un "port" de su plataforma .NET bajo la licencia "Shared Source", ¿Por que debería preocuparme por algo mas?
R: La implementación "Shared Source" seria cara y su uso estaríimplementacióna bastante restringido, sobre todo para uso comercial. Estamos trabajando hacia una implementación que incluya un numero de importantes derechos: Uso para cualquier fin, redistribución, modificación y redistribuir modificaciones.
Nosotros llamamos a eso Software Libre
R: No. Mono es solo un entorno de ejecución, un compilador y un conjunto de bibliotecas de clases.
R: No. Las aplicaciones pueden hacer uso del API para contactar con un sitio Passport, pero no es necesario que lo hagan.
Mientras su aplicación no haga uso de Passport, no necesitaras passport.
R: No. Pero de todas formas, el toolkit Passport para servidores web basados en Linux esta disponible en Microsoft.
R: No, no lo hará. Microsoft Office es una aplicación de Windows. Para aprender mas sobre ejecutar aplicaciones de Windows en una plataforma Unix Intel, dirijase al proyecto WINE
R: Mono solo esta relacionado con los Servicios Web en que implementa el mismo conjunto de clases que han sido integrados en el Entorno .NET para simplificar y centrar el proceso de construir Servicios Web.
Pero lo que es mas importante, Mono es una implementación Libre de la plataforma .NET
R: Podrá escribir servicios web en .NET que se ejecuten en mono y viceversa.
R: Si. Cuando el proyecto este terminado, usted podrá utilizar la mismas tecnologías que están disponibles a través del entorno de desarrollo .NET en Windows para escribir servicios Web.
R: SOAP es una biblioteca de Aplicaciones GNOME para crear servidores SOAP y clientes SOAP, y pueden usarse sin Mono. Puede navegar por el código fuente de SOAP usando el Bonsai de GNOME
R: Si. El CLI contiene suficiente información sobre una clase que exponerla a otros sistemas RPC (como CORBA) es realmente simple y no requiere una implementación en el propio objeto.
Mono implementará la interacción con CORBA como una extensión de las clases Mono, así podremos integrar Mono con Bonobo, tal y como Microsoft facilita interoperabilidad con las clases COM y mecanismos de soporte.
R: Si, el motor de CLI sera hecho accesible como una biblioteca compartida. El motor de recolección de memoria, la abstracción de hilos, el sistema de objetos, el sistema dinámico de códigos y el JIT serán accesibles a los desarrolladores de C para integrarlos con sus aplicaciones si estos lo desean.
R: Con suerte, Los entusiastas del software libre, contribuirán herramientas para mejorar el entorno de desarrollo. Estas herramientas pueden ser desarrolladas usando la implementación de Microsoft del CLI y luego ejecutadas en Mono.
P: Que tipo de normas hacen al Lenguaje Intermedio Común (CIL) útil para JITers (Compiladores en Tiempo de ejecución)
R: La norma principal es que la pila en CLI no es una pila de propósito general, No esta permitido usarla para otros propósitos que el de computar valores y pasar argumentos a funciones o retorno de valores.
En cualquier instrucción de llamada o de retorno, los tipos en la pila deben ser los mismos, independientemente del camino de ejecución del código.
R: Puedes obtener herramientas muy buenas para hacer desarrollos en java en sistemas libres. Red Hat ha contribuido a hacer un frontend de GCC para java que puede tomar código Java o Bytecode JVM y generar ejecutables nativos, Transvirtual ha implementado Kaffe un motor JIT para java. Incluso Intel ha realizado un JVM llamado ORP.
Pero JVM no esta diseñada para ser una Maquina virtual de propósito general. El CIL, por otra parte, ha sido diseñado para ser destino de un gran número de lenguajes de programación. Y tiene una serie de reglas para ser óptimo para ser compilado en tiempo de ejecución.
R: Si, el código java puede ser compilado para CLI. Tenemos detalles de un proyecto que alguien puede tomar para hacer que esto se convierta en realidad.
Microsoft tiene una implementación del lenguaje Java llamada J# que puede tener como objetivo el motor de ejecución de CIL.
R: Si, es posible, aquí hay varios posibles puntos de comienzo:
Una representación en ByteCode es realmente un bosque de arboles aplanados. Mira al motor JIT de Mono, para ver como procesamos los bloques básicos, (esto serian los arboles).
El bosque es solo un array de arboles.
Por supuesto si ejecuta el motor JIT con la opción -d (mono -d programa.exe) veras como se ven estos arboles.
Vera algo similar para Java: Cada "Bosque de arboles" tiene un significados. Este significado puede ser traducido al significado equivalente en la tierra del CRL.
R: Si. La colección de clases de Microsoft es muy grande, pero eso no significa que sea completa. Seria bueno tener "Camel" (El API de Correo que usa evolution inspirado en JavaMail) portado para aplicaciones Mono.
También deberíamos pensar implementar CORBA para Mono, no solo por que seria útil, sino por que suena como algo divertido, dado que CLI es un sistema con muchos tipos.
Para mas información sobre la Ampliación de Mono, Vea nuestra pagina de Ideas.
R: Adoptar una buena tecnología es buena. Extender una tecnología de un modo incompatible es malo para los usuarios, por lo que no tenemos planeado extender la tecnología.
Si tiene ideas innovadores y quiere crear nuevas clases, le animamos a que haga que esas clases funcionen correctamente tanto en Mono como en .NET.
R: Por el momento, El proyecto mono esta haciendo el trabajo en un sistema Linux y en Windows, No esperamos hacer demasiado Linuxismo en el código, por lo que debería ser fácil portar Mono a otras variables de UNIX.
R: La mayor intención en Ximian es permitir desarollar aplicaciones GNOME con mono, pero si esta interesado en proveer las clases Winform. a otras plataformas (Frame Buffer o MacOS X por ejemplo), nosotros las integraríamos, mientras estas tengan licencia compatible con código libre.
R: Eso esperamos. Actualmente algunas partes de Mono se ejecutan solo en Windows (el compilador C# es un ejecutable .NET) y otras partes solo han sido compiladas en Linux pero funcionan en Windows usando Cygwin.
R: Queremos que Mono llegue a las manos de los programadores pronto. Estamos interesados en reutilizar el software libre existente.
R: En este momento estamos investigando como podemos usar elementos de ORP para Mono. El desarrollo realizado por ORP en el tema de los motores JIT define un API diferenciado que separa el JIT del sistema de recolección de memoria y la implementación del ByteCode actual.
R: El equipo de Mono también esta investigando sobre GNU Lightning
P: Esta trabajando Ximian en un Front-End de GCC para C#?, y Soporte para que GCC crease CIL? Que hay sobre hacer un front-end de GCC que coja CIL y genere codigo nativo?
R: Estamos buscando voluntarios para estos proyectos. Visite la sección de contribuciones si estas interesado. Contribuir en Mono
R: No podemos predecir el futuro, pero una estimación conservadora es que sera al menos "tan rápido como otros motores JIT". Al Proyecto mono le gustaría suministrar múltiples motores JIT con mono, tal y como Microsoft ha hecho con la plataforma de desarrollo .NET. Podremos proveer un JIT mas rápido para tiempos de carga bajos pero un rendimiento pobre, y una JIT optimiza que sera mas lenta en la generación de codigo, pero producirá un codigo mas optimizado. El CIL tiene bastantes ventajas sobre el ByteCode de Java: Es realmente una representación inmediata y hay un conjunto de restricciones de como puedes general codigo CIL que simplifica la creación de mejores JIT's. Por ejemplo, en CIL, la pila no es realmente una abstracción de la que disponga el generador de codigo para ser usada. Sino que es una forma de crear representaciones en post-fija de los arboles analizados. Dada una llamada cualquiera o un punto de retorno, los contenidos de la pila contendrán el mismo tipo de objeto, independientemente de como se llego a esa instrucción.
R: Si. El esquema de licencias planeado permite que desarrolladores propietarios escriban aplicaciones con Mono.
R: El compilador de C# esta liberado bajo los términos de GNU GPL. El compilador en tiempo de ejecución bajo GNU LGPL. Y las bibliotecas de clases bajo los términos de la licencia MIT X11.
P: Me gustaría contribuir codigo a Mono bajo una licencia particular. Que licencias Acepta el Proyecto Mono?
R: El proyecto debería evaluar la licencia por temas de compatibilidad, pero en general, acepta el codigo bajo los mismos términos de licencia que el modulo que contiene al codigo.
P: Pueden las patentes inutilizar Mono (las patentes ocultas actuales, o cambios realizados por Microsoft realizados específicamente para crear problemas de patentes)?
R: No. Para empezar las funcionalidades básicas han preexistido lo suficiente para ser bloqueadas por las patentes. Los componentes básicos de Mono son tecnológicamente equivalentes a la tecnología Java de Sun, que ha existido durante años. Mono también implementa soporte multi-lenguaje y multi-arquitectura, pero hay tecnologías anteriores como UCSD p-code y ANDF que también soportan múltiples lenguajes y múltiples arquitecturas usando un lenguaje común intermedio. Las bibliotecas son similares al las bibliotecas de otros lenguajes, pero de nuevo son demasiado similares para se patentadas.
De todas formas, si Microsoft patenta alguna tecnología, nuestro plan es (1) buscar una alternativa (2) Eliminar la parte patentada, (3) buscar arte previo que vuelva a la patente Inutil. No proveer de una tecnología patentada, reduciría la interoperabilidad pero todavía proveería a la comunidad del software libre una buena herramienta de trabajo, que es la herramienta principal para desarrollar.
P: Dicen que CLI permite que varios lenguajes se ejecuten en el mismo entorno. No es este el propósito de CORBA?
R: La diferencia principal entre CORBA (y COM) y CLI es que CLI permite interoperabilidad a nivel de dato, ya que todo lenguaje/componente usa la misma representación de datos y de gestión de memoria.
Esto significa que puedes operar directamente sobre los tipos datos que otro provee sin tener que ir a través de su interface. Eso también significa que no tiene por que convertir parámetros y no tiene que preocuparse por el manejo de memoria. Ya que todos los lenguajes/componentes comparten el mismo recolector de memoria y espacio de direcciones. Esto significa mucho menos copiado y poder olvidarse de contar las referencias a un dato.
R: El soporte en el entorno de ejecución soportara XPCOM en sistemas Unix y COM en Windows. La mayor parte de los trampolines dinámicos están ya implementados.
R: Es posible. Pero no hay ningún plan sobre esto. Así que la respuesta a corto plazo es no.
R: Intenta cambiar la linea "./mono-rss.exe ../index deploy/index.rss" por "mono ./mono-rss.exe ../index deploy/index.rss"
R: La mejor forma es hacer un seguimiento del bug y realizar un test sencillo que muestre el bug. Puedes añadir el bug al bugzilla: http://bugzilla.ximian.com/enter_bug.cgi or simply send it to mono-list@ximian.com.
R: El compilador de C# de mono del CVS soporta la misma línea de comandos que el compilador de C# de Microsoft.
R: Hay que seguir una serie de pasos para evitar incosistencias a la hora de compilar el runtime de mono y la corlib, las librerías del núcleo del Mono.
El primer paso es instalar la última release de mono (que incluye el runtime, mcs.exe y las dll).
El segundo paso es obtener el módulo mcs del CVS lo más reciente posible (si no tienes acceso al otro, el CVS anónimo vale, salvo en casos de extrema mala suerte :-). Luego, 'make -f makefile.gnu'. Esto usa mcs.exe y el runtime x.xx (la última release del momento), con lo cual no hay problemas de que no esté sincronizado. Después de esto, tenemos mcs/mcs/mcs.exe y mcs/class/lib/*.dll.
El paso 2.a) sería (opcionalmente) copiar estos a un lugar 'seguro' para conservar siempre una copia de lo último que has compilado
El paso 3 consiste en actualizar el runtime (mono). Para ello se puede usar el script mono-build.sh (está en la web y en mono/doc/mono-build.sh).
En este momento, tenemos instalados mcs.exe y las dll de la release x.xx y el runtime del CVS, con lo cual puede haber inconsistencias, pero... tenemos el resultado del paso 2.
Copiar mcs.exe y las dll resultantes del paso 2 a su lugar correspondiente, es decir, ${prefix}/bin (para mcs.exe) y ${prefix}/lib para las dll.