Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Futuro Gnome

pbenavent's Diary
Por pbenavent
departamento La bola de cristal , Sección Diarios
Puesto a las Thu May 12th, 2005 at 09:29:00 PM CET
Vengo divagando sobre esto en mi diario e intentando ver que pensais, pero no acabo de obtener respuesta, fíjate por donde, otros son menos comedidos que yo.

 


Recorreré algunas entradas del diario de más antiguas a más recientes:

Mi opinión es que independientemente de la bondad de una solución u otra, independientemente de problemas legales o no, hay algo que no podemos perder de vista: en el mundo empresarial hay una base implantada sobre Java (J2ee, jsp, java, clientes en swing, ...). La baza de Mono puede ser la proximidad tecnológica a plataformas Microsoft (?)

P.D estoy oyendo el último podcast de jcantero y tiene una factura muy buena, enhorabuena.

< Debian en mac mini (I) (32 comments) | Optimizando paquetes (5 comments) >
Enlaces Relacionados
· escomposlinux.org
· elecciones en Gnome
· Novell
· Redhat
· Miguel de Icaza sobre la evolución de Gnome con Mono
· Redhat sin Mono pero con Java
· Yogurt Griego habla sobre la guerra de lenguajes en Gnome
· More on pbenavent's Diary
· Also by pbenavent

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Futuro Gnome | 10 comentarios (10 temáticos, editoriales, 0 ocultos)
Yo soy chico KDE (none / 0) (#1)
por shamkao a las Fri May 13th, 2005 at 11:51:08 AM CET
(Información Usuario)

Aún así, soy capaz de usar un montón de aplicaciones GTK y no tengo nada en contra de Gnome, es sólo cuestión de gustos.

Pero lo que si que veo en toda esta historia son dos situaciones que están afectando a Gnome seriamente.

Por un lado está la guerra de los lenguajes, y el caso es que es complicado puesto que ninguna de las plataformas dependen de la comunidad totalmente, por un lado está .Net que depende de hassefroch y por otro está java que depende de Sun. Vale que los proyectos de los que se habla sean de la comunidad, pero les va a ser muy difícil mantenerse al día, puesto que no tienen capacidad de influencia en el planteamiento original de las plataformas.

Por otro lado está la guerra entre RedHat (java) y Novell (mono), que están en competencia directa en tanto en cuanto ambos apuntan a los mismos grupos de usuarios, los corporativos. Cuando uno está en competencia necesita un factor diferenciador para destacar sobre los demás. Por esta razón RedHat no puede claudicar y meter mono, porque sino se convertiría en una especie de clon de Novell y la gente preferiría llevarse Novell porque se encuentra ante dos productos de características muy similares, sólo que uno de ellos es una copia del otro.

El caso de Novell es parecido, sólo que en este caso han invertido una gran cantidad de recursos en Mono y no podrían desechar todo lo que llevan y empezar a trabajar con java, en este caso ellos se convertirían en un clon de RedHat.

Lo único que espero es que se resuelva pronto este tema, porque al final los que salen perdiendo son los usuarios, en cuanto a la calidad de los programas, homogeneidad y desperdicio de recursos (necesitarían tener cargado en memoria dos máquinas virtuales bastante pesadas).



De .NET a Java y viceversa (none / 0) (#4)
por jorginius ("jorginius" en Google Mail) a las Sat May 14th, 2005 at 11:49:15 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Esto es poco más que una nota al margen:

El caso de Novell es parecido, sólo que en este caso han invertido una gran cantidad de recursos en Mono y no podrían desechar todo lo que llevan y empezar a trabajar con java, en este caso ellos se convertirían en un clon de RedHat.

Novell no tiene que romper con todo. Tampoco Redhat.

Existen máquinas virtuales Java para .NET. Una de ellas es IKVM.NET, que funciona en Mono y es GPL.

La opción propietaria es JuggerNET.

Tanto como si quieres migrar paulatinamente a .NET o quieres usar partes de .NET desde Java o código Java que no existe en .NET, usar una vm como éstas podría ser una buena opción: te permiten ejecutar bytecode Java y un escape a .NET.

[ Padre ]


Arggg! (none / 0) (#5)
por shamkao a las Sat May 14th, 2005 at 12:15:21 PM CET
(Información Usuario)

Por favor, no más capas de abstracción, al final lo único que conseguiremos es tener un consumo de memoria altísimo para correr aplicaciones que sólo irían fluidas en los ordenadores de última generación y daría la impresión de que los ordenadores se quedan anticuados cada vez más rápido. Similar al efecto "sale al mercado una nueva versión de hassefroch *"

Yo soy de la vieja escuela, los programas que uso prefiero que sean compilados. Desde el punto de vista del usuario te la p***, te da igual que el desarroyo de las aplicaciones sea más rápido y con menos errores con máquinas virtuales, lo que quieres es usar programas que vayan rápidos y no desaprovechen recursos.

[ Padre ]


Puedes compilar a nativo, si lo prefieres (none / 0) (#7)
por jorginius ("jorginius" en Google Mail) a las Sat May 14th, 2005 at 01:43:00 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Con IKVM y Mono se puede hacer, al menos. IKVM es, en el fondo, un compilador JIT de bytecode Java a CIL pero también lo puedes usar para traducir a CIL que luego compilarás con el compilador AOT de Mono (Ahead Of Time, lo contrario de JIT).

Como máquina virtual de Java libre IKVM es bastante completa. De hecho fue la primera que pudo correr Eclipse hace dos años. Sólo ahora los últimos snapshots de gcc 4.0 son capaces de compilar Eclipse.

[ Padre ]


 
Centrate, pequeño Padowan (none / 0) (#2)
por trukulo (mzv-at-menta-dot-net) a las Fri May 13th, 2005 at 12:01:25 PM CET
(Información Usuario) http://mercurio.homeip.net

¿Qué es lo más importante del Software Libre? La libertad.

¿Es Java Libre? No.

¿Hay alguna maquina virtual de java libre que ofrezca buen rendimiento? No.

¿Es Mono una trampa de Microsoft? Puede que sí, puede que no. Se va a arriegar tu puta madre. Con perdón para las madres implicadas en el comentario.

Yo lo que propongo es lo que están proponiendo muchos desarrolladores de gnome, ni Java, ni Mono: Put^^ython.


Miguel Angel Zarza.
Aka trukulo.
email: trukulo(at)menta(dot)net
jabber ID: trukulo(at)bulmalug(dot)net
web: http://mercurio.homeip.net


Centrado estoy, pero en ... (none / 0) (#3)
por pbenavent a las Fri May 13th, 2005 at 04:26:14 PM CET
(Información Usuario) http://www.benavent.org

Centrado estoy, pero en entorno empresarial. Estoy pensando desde el punto de vista de las empresas, de las grandes empresas, que pagan un montón de dinero en mantenimiento y licencias de IBM, o de Oracle, o de Office de Hasefroch.

Si lo mirase desde el punto de vista de usuario doméstico analizaría otras cosas, ahí sí, que aplicamos culo veo, culo quiero y mis preferencias domésticas no van por Redhat o Novell, pareciendome muy respetables ámbas.

P.D creo que la ortografía correcta es padawan (como se puede ver en el banco de datos de StarWars) y no padowan

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


 
Mi no entender (none / 0) (#6)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Sat May 14th, 2005 at 01:34:57 PM CET
(Información Usuario) http://speedball.servemp3.com

Java, Mono, Python... ¿y GNOME? ¿exáctamente cual es el problema?

Quiero entender que el asunto es la necesidad de un lenguaje de alto nivel para desarrollo rápido o de desarrollo de maquetas de software, ya que el C es de demasiado bajo nivel (¿quién dijo ensamblador multiplataforma?). Es decir, algo que cumpla las funciones del VisualBasic del Windows, y así hacer que porrociento inútiles piquen código absurdo para GNOME.

Si es esto, ¿realmente hace falta una puñetera máquina virtual? es más ¿cuantas máquinas virtuales (basadas en la máquina de pila) necesitamos en nuestros ordenadores? porque si empiezo a mirar el mio: Python, Perl, Java, Flash!... todavía no me he instalado Mono (y soy gnomero), y seguro que me dejo alguna más que tengo instalada y no me he fijado o me he olvidado de ella.

Personalmente me gusta Python como lenguaje, pero detesto los problemas de las diferentes versiones. ¿Es de recibo que al actualizar a Python 2.4 dejen de funcionar aplicaciones del 2.2?. Puedo comprender, aceptar, e incluso alagar, que el paso de la versión 1.x a la 2.x deje de haber compatibilidad hacia atras, pero ¿de la x.y a la x.y+1? ¿y además por sistema?

Entonces, volviendo al problema original, ¿qué lenguaje de alto nivel se puede emplear para desarrollar aplicaciones rápidamente por inútiles en GNOME? descartando C por no ser de alto nivel y necesitar programadores competentes, automáticamente descartamos el C++ por mismas razones (además, ¿qué empleamos? gtkmm o vdkbuilder?). Tenemos FreePascal, que además es compatible con ObjectPascal, también conocido por Delphy. Y ADA, un escalofrío recorre la espalda recordando los viejísimos tiempos de la universidad, pero supongo que todos aquellos que llegaron sin vicios de programación a la carrera no le tienen la famosa urticaria y debe haber bastantes recienlicenciados o casi-licenciados con experiencia en ADA, a menos que ya hayan jubilado a todos los profesores fanáticos de dicho lenguaje.

Como ya he expresado mis reticencias a las máquinas virtuales (a menos que empecemos a unificarlas y acabemos con una mega-maquina virtual para todos los lenguajes), abogo a que en GNOME se pueda usar indistintamente cualquiera de los lenguajes soportados directamente por el gcc, y que eso sea prioritario y forme parte del núcleo duro de GNOME (una biblioteca no pueda formar parte oficial de GNOME mientras no este accesible por todos los lenguajes del gcc). Y a final de cuentas no son tantos: C, C++, Objective-C, Fortran, ADA y Java.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar


Lenguajes es uno de los debates Gnome (none / 0) (#8)
por pbenavent a las Sat May 14th, 2005 at 05:27:20 PM CET
(Información Usuario) http://www.benavent.org

Lenguajes es uno de los debates Gnome, en un enlace del diario se habla de C++ en KDE, que me corrija melenas, pero se programa en C++. Ya está.

Parece que en Gnome no lo tienen tan claro, en cualquier caso, hay una cosa que en Gnome ha pasado y es el cambio de las APIs de programación, pero en KDE, con una librería controlada por Trolltech parece que es otra cosa.

La guerra de lenguajes tiene dos vertientes:
  1. ¿en qué programamos el escritorio?
  2. ¿en qué lenguajes se pueden programar aplicaciones para el escritorio de manera más adecuada?
En la guerra de en qué lenguajes programo aplicaciones para el escritorio, tenemos a Redhat (y a OpenOffice con Sun detrás de ellos) favoreciendo Java, por el otro lado tenemos a un buen número de desarrolladores de Gnome en plantilla de Novell defendiendo Mono

El debate puede ser bueno si es conducido con buenas intenciones. Pero, vuelvo a hablar de lo mismo, en el entorno empresarial, por lo menos en el que conozco -no solo la empresa en que trabajo- hay mucha aplicación hecha en Java y nada hecho en .NET ... de momento. El de momento es importante, porqué dentro de nada cualquier cosa que quieras instalar en un desktop hasefroch instalará automágicamente el framework .NET y estará escrito en C#. A mi ya me ha pasado.

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


 
No estoy de acuerdo en una cosa (none / 0) (#9)
por shamkao a las Sun May 15th, 2005 at 06:59:55 PM CET
(Información Usuario)

¿Por qué se empeña la gente en decir que C y C++ es un lenguaje de bajo nivel? No lo es.

Los lenguajes de bajo nivel son los ensambladores, en los que el código de una arquitectura no vale para otra, sin embargo el código escrito en C vale para cualquier arquitectura utilizando un compilador apropiado.

[ Padre ]


Por comparación (none / 0) (#10)
por man ls a las Mon May 16th, 2005 at 10:28:25 AM CET
(Información Usuario)

Todo depende de qué uses como referencia. Si pones frente a frente C++ con el ensamblador, es de alto nivel; pero si lo comparas con perl, está claro que C está más cercano a la máquina. Sin embargo, lo que se suele entender como lenguaje de programación es siempre independiente de la máquina (el ensamblador de 68k sirve para programar, pero sólo cierta familia de procesadores).

Creo que se suele considerar C como de bajo nivel porque apenas oculta la organización interna de la máquina: accedes a la memoria byte a byte, las variables pueden mapearse directamente a registros, y puedes decirle al compilador que no optimice lo que escribes. Es difícil llegar más bajo en lenguajes de programación propiamente dichos.

También hay que tener en cuenta que eso de C/C++ es una entelequia. C es una cosa, C++ otra muy distinta y de más alto nivel.

[ Padre ]


 
Futuro Gnome | 10 comentarios (10 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

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