Barrapunto

No puedo estar más de acuerdo con una de las cosas que se dicen en el artículo; con ésto se consigue que .NET sea otro "estándar de facto",como si a Micro$oft le hiciera falta que encima le ayudaran.

Lógicamente RMS que ya llevaba un tiempo apoyando las últimas y polémicas decisiones de De Icaza, al final ha estallado...

 

...si no lo veias venir, es simplemente que no estabas prestando atencion. Ya se monto un buen pollo cuando Miguel dijo que para conseguir aplicaciones para Gnome, lo mejor era portar Visual Basic, y por el momento no se han observado grandes progresos, pese a que hay un supuesto gnome basic dando vueltas por ahi.

En mi modesta opinion, la idea de .NET es fantastica, si permite todo lo bueno de Java y ademas de verdad permite que se programe en cualquier lenguaje (no solo ese supuesto C#). Hasta ahi la teoria del mundo de las piruletas. El problema vendra cuando Microsoft empiece a modificar APIs, ocultar especificaciones, etc... De esta forma, nunca tendremos un sistema completo y plenamente compatible con el estandar, y una vez mas bailaremos al ritmo que marque el tito Billy. La solucion... no lo se, la verdad.

La solucion... no lo se, la verdad.

¿Y seguir como hasta ahora? es decir, programando librerías bien diseñadas, multiplataforma y con el código fuente disponible portarlas es un juego de niños. Programa una vez, compila en el sistema que quieras.

Y si alguien quiere hacer las cosas rápido, PHP o Python son el lenguaje a elegir.

Tanto Java como .NET me parecen una bobada teniendo el código fuente del programa disponible, pero si no lo tenemos entonces es lógico que nos inventemos un "código intermedio" multiplataforma con el que ocultamos el código y ejecutamos donde queramos.

... por supuesto voy a argumentarlo:

    Supongamos que quiero realizar una aplicación multiplataforma (con que funcione en Linux y Windows me doy por satisfecho), la aplicación es un sistema cliente-servidor multimedia, por lo que necesito un API que me permita usar sockets, threads, multimedia (ventanitas, openGL, sonido, ...), ficheros, etc. todo esto independiente de la plataforma. ¿Qué podemos usar?

  Opción 1: Treinta librerías de C/C++ (lenguajes en los que llevo programando 10 años), que por supuesto no son totalmente compatibles y tendrás que modificar las fuentes, cambiando como mínimo la parte de threads y sockets. (Resultado final: la mayoría de los programadores hacen una única versión en Windows, porque se usa en el 95% de los PCs, si te gusta Linux: te jodes)

  Opción 2: Realizas el programa en Java, con un API que soporta threads, sockets, ficheros, openGL, vídeo (MPEG, QuickTime, H262, H263, ...), sonido, ventanas, configuraciones, LDAP, Corba, invocación remota, ... y no tienes que hacer nada para que funcione en Linux y Windows. (¿qué va lento? C++ 'sólo' va 3 veces más rápido -ha mejorado la cosa- y GCC 3.0 compila los bytecodes a nativo ;-)

  Opción 3: Utilizas algo parecido a Mono o un API que de VERDAD funcione en varias plataformas y sea lo suficientemente completo. (Irá más rápido que con Java)

  Ahora puedes seguir diciéndo que Java es una 'bobada', pero es la ÚNICA opción para hacer aplicaciones multiplataforma de forma cómoda y sencilla.

Te olvidas de Python.

En mi modesta opinion Icaza esta cometiendo un error de principios

Me temo que Icaza tiene la libertad de tener los principios que más le parezcan ¿no crees? Y de hecho, incluso tiene el derecho a producir software cerrado y a trabajar para Microsoft si es lo que le gusta. ;)

siemplemente podemos tener aqui alguien a quien le apetece tener dinero en el bolsillo y hacer lo que le de la gana, eso puede significar codearse un poco con microsoft, por ejemplo, pero de ahi a que se venda, hay mucha distancia..

  estemos tranquilos. el futuro siempre nos guarda sorpresas..

Opción 1: Treinta librerías de C/C++ (lenguajes en los que llevo programando 10 años), que por supuesto no son totalmente compatibles y tendrás que modificar las fuentes, cambiando como mínimo la parte de threads y sockets. (Resultado final: la mayoría de los programadores hacen una única versión en Windows, porque se usa en el 95% de los PCs, si te gusta Linux: te jodes)

Eso es más falso que un euro de madera. Si utilizas las Qt y las STL, el GUI, Threads, sockets, OpenGL y muchísimas cosas más los tienes solucionados con que programes con un poco de cuidado (como mínimo, en Windows, Linux y Mac, si no te lo crees dale un vistazo al CVS del KVIrc 3, por ejemplo). Para lo que te false casi seguro que vas a encontrar alguna librería portable (porque casi todas las librerías de tamaño mediano de C++ son portables de Linux a Windows). Pero en ningún caso treinta. Java también tiene problemas de portabilidad, y sino dima a mi que pasa si el 'cliente' no tiene la misma versión de las JDK, librerías gráficas (Swing y cía), etc.

Sobre lo de que Java 'sólo' sea tres veces más lento... sólo en los mejores casos, como puede verse aqui en la mayoría de ellos es más de tres veces más lento (y eso sin constar el consumo de memoria ni el tiempo de inicio).

¿Icaza está prostituyendo licencias? ¿Puedes explicar eso, o sólo lo dices porque te apetecía meterte con alguien?

Señores, pero no se preocupen tanto por M$ y su .NET$, trabajen en Java que les proporciona todo lo que necesitan para trabajar, es Gratis y además ellos no modifican el API para no ser multiplataforma, por el contrario pueden correr las aplicaciones en cualquier plataforma y si utilizan el Java WebStart ya no tienen el dolor de cabeza de instalar la aplicación.

Creo que es obvio que lo de las 30 librerías es una exageración (usado como recurso estilístico para enfatizar). Lo de que java sea incompatible entre versiones: depende, si usas clases que estan desde la versión 1.0 seguirá funcionando en las versiones 1.1, 1.2, 1.3 y 1.4, por lo que sólo habrá incompatibilidades de usas una clase que acaba de aparecer, y eso si el cliente tiene instalada una versión antigua (hay una cosa que se llama "actualización", si no estaríamos aún con el kernel 2.0 la mayoría) Por lo que no creo que sea un problema 'real'.

    Los problemas de memoria y velocidad se van solucionando (bastante rápido si tenemos en cuenta que Java tiene 7 años de edad), y podemos pasar a código nativo desde los bytecodes (sigues teniéndo una única versión de código fuente y bytecodes).

    He estado buscando un conjunto de librerías (en C++, los objetos no me los quita nadie, y así tengo más rendimiento) que me permitiesen hacer lo mismo que con Java (ni siquiera me había planteado que fuese igual de fácil el desarrollo, eso sería pedir 'demasiado'), pero no he encontrado ninguna solución aceptable (los sockets, los threads, las bases de datos (JDBC) y la parte multimedia son los grandes olvidados), para hacer ventanitas hay miles (¿otra exageración?) de APIs: wxwindows, GTK, QT, ... pero ninguna me independiza TOTALMENTE del sistema operativo. Podría desarrollar el SW con _mucho_ cuidado (colocando las partes dependientes del SO en una librería con un interfaz perfectamente definido, y posteriormente implementarla para cada plataforma) pero sería un verdadero coñazo, fuente de problemas, ... Otra cosa sería tener una buena librería que te diese todas las posibilidades que te dá Java, entonces no tengo ningún problema en usar C++, pero tal y como están las cosas, intentaré usar Java siempre que me dé un rendimiento suficiente.

    Otro dato: (a ver como haces esto en C/C++, etc.) Ahora estoy haciéndo un programa en Java para servicios de información con Bluetooth. Existe un API en Java para acceder a Bluetooth, puertos serie, paralelo, USB, FireWire, ... de forma independiente al SO (puedo hacer drivers independientes del SO). Así pues, puedo hacer mi sistema en Java y ejecutarlo en Linux, Windows, Windows CE, PalmOS, Symbian, teléfonos móviles con J2ME, ... accediendo al HW y sin tener que tocar una línea de código. Si necesitase acceder a algo específico del sistema o más rendimiento podría definir una clase que tuviese algunos métodos implementados de forma nativa usando JNI, y así, por 'arte de magia' tengo acceso mútuo entre programas en C/C++ y Java.

Hasta ahora he permanecido en silencio (como con las hemorroides) sobre este tema; pero ya que Richard se ha dignado decir algo (ya era hora, jolín), haré un pequeño repaso a la historia reciente tal y como la he vivido.

En este comentario, el amigo Rawsock parodiaba hace un año la aptitud de Stallman con respecto a las disputas entre KDE y GNOME. Parece que las cosas han cambiado mucho desde entonces...

Cuando nació GNOME hubo críticas de ciertos sectores a la duplicación de esfuerzos, puesto que empezaron a hacer lo mismo que KDE llevaba cierto tiempo haciendo; las críticas fueron acalladas en base a la licencia propietaria de las QT. Pero resulta que las GTK, que habían siendo desarrolladas en principio para el GIMP (GTK - Gimp ToolKit), estaban también tan verdes que las excusas para no hacer un clon de las QT (que eran muy superiores a GTK, hasta el propio Linus Torvalds valoró muy positivamente la calidad de las librerias de Troll Tech) libre contra el que compilar KDE (al estilo de lo que se estaba haciendo con motif en lesstif) no resultaban demasiado convincentes. De hecho se comenzó un proyecto denominado "Harmony", que prentendía eso mismo (un clon libre de las QT), creo que incluso fue inicialmente patrocinado por Red Hat, pero finalmente fue abandonado (supongo que en beneficio de GNOME).

Desde entonces hasta ahora han ido ocurriendo muchas "cosas". Como aquellas desafortunadas declaraciones del "unix sucks". Ahora también sabemos que intentó entrar a trabajar en Microsoft. Y ahora lo del .NET y los proyectos propietarios de Ximian...

Si hay algo que Icaza ha hecho muy bien ha sido atraer fondos hacia GNOME, igual me he perdido algo pero... ¿se sabe ya dónde fueron a parar los $13 MILLONES DE DOLARES que se invirtieron en Nautilus antes de que Eazel cerrase?. Como decía Dennis E. Powell en Linux Planet, El KDE entero no costó tanto ni de lejos, y en aquel tiempo el KDE ya tenía mucha mas chicha que GNOME y funcionaba (vamos, lo que yo digo, lo que LiNUX al Minix...).

En fin, que la credibilidad de Icaza está mas en entredicho que nunca después de estas últimas declaraciones, pero que viendo el desarrollo histórico y como se acercaba cada vez mas al $ era algo previsible. No entiendo como Stallman no se percató antes; ¡ay!, ¡Ricardo, Ricardo!... CRIA CUERVOS...!!! ¿Te veremos decir algo ahora de estilo de "Go FORGet'em, KDErs!"?

Perdón, una última duda que me queda... (aparte de la de los $13.000.000...) ¿por qué se creó GNOME cuando ya existía KDE?...
 

  pero no he encontrado ninguna solución aceptable (los sockets, los threads, las bases de datos (JDBC) y la parte multimedia son los grandes olvidados), para hacer ventanitas hay miles (¿otra exageración?) de APIs: wxwindows, GTK, QT, ... pero ninguna me independiza TOTALMENTE del sistema operativo.

No has mirado muy bien. Las Qt te permiten hacer todo eso que comentas (y sí, la versión 3 tiene soporte para bases de datos, y de forma muy elegante, todo hay que decirlo).Y si que te independizan totalmente del sistema operativo (como las STL).

Otra cosa sería tener una buena librería que te diese todas las posibilidades que te dá Java, entonces no tengo ningún problema en usar C++, pero tal y como están las cosas, intentaré usar Java siempre que me dé un rendimiento suficiente

Tiempo al tiempo, si tu preferencia por Java se limita a que tiene una mejor librería, acabarás por usar C++ porque también la acabará teniendo. Ten en cuenta que la estandarización definitiva de las STL es algo más reciente que Java, y la cosa aún no se ha detenido.

Ahora estoy haciéndo un programa en Java para servicios de información con Bluetooth.

No estoy seguro, pero me extrañaría mucho que no hubiera ninguna librería para hacer Bluetooth en C++. En cualquier caso me pones un ejemplo propicio para Java y muy concreto. Es como si yo te empiezo a enumerar las ventajas de Python sobre Java (que son muchas) para decirte que Python es mejor lenguaje ¿lo es? Pues no, dependerá del campo de aplicación, pero si te quiero abrumar a ventajas de Python, no lo dudes, lo puedo hacer muy fácilmente poniéndote ejemplos muy concretos en los que Python destaque.

Por otro lado las librerías actuales (insisto, post-standar) de C++ suelen ser MUY portables entre distintos sistemas. Y yo no perdería de vista la librería C++ GNU.

Mmmm... si no me equivoco (y es posible que lo haga) Bluetooth _si_ te permite hacer drivers, porque define una serie de API's para acceder a puertos seríe y demás zarandajas y a partir de ahí tu te puedes escribir el controlador para _controlar_ el dispositivo que a ellos esté conectado, del mismo modo que los drivers del kernel de Linux no implementa cada uno el código para acceder al puerto serie o al puerto paralelo sino que utilizan un API común para ello (y no por ello se les deja de llamar drivers).

Me da exactamente =, si Microsoft controla .NET Sun controla el API y puede cambiarlo cuando le de la gana, puesto que no está estandarizado, vale que los demás pueden o no pueden hacerle caso pero en el caso de Java ¿donde iría la mayoría borregil? Java sería perfecto para lo que comentas... si Sun quisiera estandarizarlo de una p*ñetera vez (pero tienen mucho miedo a perted el control).

Yo también estoy a favor del "unix sucks" y que la arquitectura de WNT (no la implementación jeje)es mucho más inovadora y más avanzada que UNIX. Por eso estoy a favor de MS? pues no, no tiene nada que ver.

    Si hay algo que me cae bien de Icaza es que siempre ha dicho las cosas claras, y que nadie se sorprenda ahora para bien o para mal.

Yo también estoy a favor del "unix sucks" y que la arquitectura de WNT (no la implementación jeje)es mucho más inovadora y más avanzada que UNIX.

Bueno, si consideras que para que algo "rules" tiene que ser innovador... hay quien considera que lo que de verdad "rules" es lo que "rula" (usease, lo que funciona...)

Creo que volvemos a la misma discursión entre Tanembaum y Torvalds y yo me sigo quedando con la conclusión del último. Minix estará lleno de buenas e innovadoras ideas, pero LiNUX funciona.

Por eso estoy a favor de MS? pues no, no tiene nada que ver.

Tú no, pero Miguel sí; y no (sólo) por eso, creo que hay otras razones por las que la afinidad de Icaza con Micro$oft es incuestionable, pero ya se han citado hasta la saciedad y no voy a repetirlas; se pueden ver todas sin salir de esta noticia.

Si hay algo que me cae bien de Icaza es que siempre ha dicho las cosas claras, y que nadie se sorprenda ahora para bien o para mal.

Pues yo sigo sin ver claro que se hizo con los $13.000.000 de Nautilus (¿ha dicho algo sobre esto, siquiera oscuro, alguna vez?) ni porque se creó GNOME ahora que, el razonamiento inicial (porque las QT son propietarias), resulta ser una falacia.
 

Las Qt no eran libres cuando se inició el proyecto Gnome: que ahora sí lo sean no significa que fuera una falacia entonces... ¿donde está la falacia? Todos teniamos en la cabeza por entonces un precedente muy malo y era lo que habia pasado con Motif. Era peligrosisimo hipotecarse asi. Ademas no es descabellado pensar que la propia existencia de Gnome empujase a que finalmente a que se liberasen las Qt (quiza no lo hubieran hecho si todos hubiesemos dependido de ello y no hubiese habido alternativa libre)... Ademas, fue una apuesta, reprochar a RMS la decision de apoyar entonces a gnome es muy poco razonable (no te jode, a toro pasado, yo tambien digo lo que es mejor: si a RMS le dieran ahora a elegir qué escritorio incorporaba al proyecto GNU, seguro que su decision era otra que entonces)

Y por ultimo preguntas con insistencia por qué se creo gnome... y yo te pregunto ¿y por qué no? El software libre te da a elegir, lo que a a veces ha parecido que es dividir esfuerzos con el tiempo se ha visto que es saludable... ¿Por qué Linux si había BSD? ¿Por que emacs si habia VI? ¿Por qué postfix si habia sendmail? ¿por que apache si habia httpd? ¿por que mahou si hay estrella? etc.
     

Si a "lo que pasó con Motif" te refieres a la guerra de escritorios (XView vs. Motif, OpenWindows vs. CDE), tendríamos que reconocer que el objetivo no se cumplió.

Y efectivamente, es injusto machacar a Stallman por haber tomado partido por Gnome en su momento.

De todas formas, el nuevo cariz que están tomando las cosas me parece interesantísimo; de hecho plantea algo que me parece peligroso y es el control del software libre por parte de empresas. De acuerdo, Ximian no es Gnome, pero aporta bastante código a Gnome. Y, según el proyecto se vaya haciendo más complejo, únicamente será Ximian la que sea capaz de abarcar (o sea, mantener, desarrollar, mejorar...) el código que ella misma aporta al proyecto... ¿no es eso lo que puede ocurrir si Mono acababa en Gnome? ¿No termina ese código siendo secuestrado ---

Muchos de los paquetes que instalo en mi debian comparten dependencias: Que si necesitan un mismo porgrama paa tal cosa, estas librerias para esto otro....Y si yo un dia hago un programa, y esa libreria me permite hacer tal cosa, pues uso la libreria y no empiezo de 0. Eso a mi me parece reutilizar.
Otra cosa es que se pueda hacer mejor.

Tengo en mucha más estima a Stallman que a Icaza. Pienso que Icaza debería cuidar más sus declaraciones. No creo demasiado en el proyecto Mono y en todo caso prefiero DotGNU. No me gustó el cambio de licencia. No entiendo que en una revista dijera junto con Nat que son "colegas" de Stallman y luego a los pocos meses en su página y en Slashdot le diera un pullazo sin que nadie le preguntara ni constara que se hubieran enfadado.

Con todo lo dicho, de ahí a que Icaza esté vendido a Microsoft, que no obre con buena fe o subestimar sus aportaciones, hay un mundo.

-El proyecto Mono no va a hacer que .NET triunfe, su posible efecto de márketing para Microsoft es casi insignificante.

-Tampoco se va a cargar Gnome: todo el trabajo que es está haciendo en Gnome se está haciendo en las librerías en C de siempre y nadie está hablando de migrar nada a Mono. Las declaraciones de Icaza mencionan la versión 4 de Gnome, que desde luego será dentro de algunos años. Para entonces sabremos si .NET es un éxito o no para implementar aplicaciones de escritorio o se queda en las de servicios web, que no interesan al proyecto Mono. Por ejemplo habremos visto si Office e Internet Explorer, las joyas de la corona de Microsoft se portan a NET y funcionan cuanto menos igual (sus programadores se resisten al cambio). Si no se portan o el resultado no es convincente, supongo que el propio Icaza se dará cuenta que la idea no es tan brillante y si él no se da, probablemente los programadores de Gnome sí se den cuenta y actuen en consecuencia no migrando a Mono. Si salen bien, entonces a lo mejor ocurre lo contrario, que nos convencemos que sí es buena idea y nos alegramos que haya salido adelante.

-A quien no le guste Mono, como a mí, que no colabore con el proyecto, pero que les deje trabajar. A ver si al final nos equivocamos y sale algo interesante y lo hemos estado torpedeando. Y mejor que criticar es colaborar con las alternativas que uno cree que son mejores.

-El que el proyecto NET sea de Microsoft, tiene sus problemas que Icaza parece desestimar mirando para otro lado (incompatibilidades, patentes, problemas con Sun y con muchos desarrolladores, la implementación de Microsoft va a poder tomar el çodigo de Mono y no lo contrario, posiblemente será más eficiente), pero que tampoco hay que sacar de contexto. Yo doy por hecho que NET y Mono nunca va a permitir portar aplicaciones entre uno y otro con la facilidad de Java, que el intento de clonar los APIs según los vaya sacando Microsoft pese a tener otros que hagan lo mismo ya en GNU/Linux es jodido. Pero se supone que no se escoge una tecnología basada en NET para la portabilidad, sino por las ventajas técnicas (cada cual juzgará si justifican el esfuerzo y si merece la pena la sobrecarga de una máquina de pila, pero en cualquier caso es su esfuerzo y el de la gente que piensa como él). De modo que lo de la compatibilidad es un efecto paralelo; al menos van a ser más compatibles que hasta ahora, que los programas escritos en Visual Basic o incluso en Visual C++ con las MFC se portan muy mal.

-El argumento de que otras tecnologías portadas de Microsoft ya estaban asentadas, es cierto, pero con matices. Mejor cogerlo a tiempo que luego ir siempre con un montón de retraso. Para esto pienso que está mucho mejor enfocado de todos modos DotGNU (lo mejor que han copiado a Microsoft es el abrazar y extender ;-) y para ello es necesario que la licencia sea copyleft). Lamentablemente este proyecto no atrae la ayuda de empresas como HP e Intel, que sí ha logrado Icaza a consta de hacer concesiones con la licencia (y también porque creen en el proyecto NET), pero que sigue siendo libre. Sin embargo ese código lo podrá utilizar DotGNU (en cambio el código de DotGNU no lo usará Mono).
 

No te das cuenta ni de lo que escribes tú mismo. Acabas de decir que no encuentras nada en C/C++ que te «independice totalmente del sistema operativo»... sin embargo si no encontrases una clase hecha para Java que haga lo que tú necesitas, y que sea dependiente del SO... ¿qué tendrás que hacer?: programártela en C/C++ (probablemente) usando JNI, y currártela para cada SO que necesites, ¿o no? Pues estamos en las mismas que con C/C++. EXACTAMENTE en las mismas.

La única ventaja que quizá te de Java en este sentido es que creo recordar (hace tiempo que no lo miro), que definen exactamente el tamaño de cada tipo básico, da igual la plataforma. Por lo demás, tu famosa clase para Bluetooth, seguro que no es 100%Java (tanto que les gusta decir a los de Sun) ¿verdad? ¿A que no? ¿A que tira de JNI para poder interactuar con el API del sistema? Ah... me parecía a mí :P

Por favor. Cuando discutamos algo, seamos un poco sensatos y al menos demos argumentos que no se limiten a confundir a los novatos.

La idea de un navegador en un lenguaje que tiene una parte importante de maquina virtual, es interesante. No hizo en su dia Sun el navegador HotJava para demostrarnos que Java revolucionaria internet?. Desgraciadamente parece que la velocidad de los lenguajes interpretados siempre va bastante por detras de las expectativas de las personas que estan fundadas en la potencia de las aplicaciones compiladas que siempre son 3 o 4 veces mas agiles.
  Se dice por ahi que la autentica optimizacion no esta en el lenguaje, o la forma de escribir, sino en elegir el algoritmo optimo.
  Para lo que a mi me interesan, juegos, java y cualquier otro lenguaje interpretado nunca estaran a la altura porque aunque me permitiran algoritmos muy elegantes, no estare en el nivel correcto, que es la de programacion de sistemas, sino en uno superior en el que no tendre vision directa de lo que esta haciendo la maquina, y, sobretodo, la optimizacion mas efectiva (antes que el algoritmo) es no hacer algo, cosa que no puedo hacer si la mayoria de las cosas ocurren automaticamente (destruyendo y construyendo objetos, por ejemplo, o pasandose mensajitos de excepciones).
  Por eso, soy exceptico. Llegara el dia en que estas cosas, hotjava, el editor de codigo .NET escrito en .NET, un teorico IE9.NET, etc.. funcionen minimamente agilmente, pero eso no las sacara de la mediocridad ni me quitara de la boca el sabor de boca malo de la primera vez que ejecutas esas cosas y van tan lentas que ni sabes si la maquina se ha colgado.
  Mientros estos llegan a funcionar "aceptablemente" ..con los criterios de hoy (que seran pasado), el resto de aplicaciones habran alcanzado el estado del arte de la tecnologia que sera toda una gozada verlos.
  De todos modos me estais convenciendo a usar java para "tools" y quizas me meta un año de estos (quizas este otoño?), pero mientras mi perl me haga mi papelito, no lo necesitare.

A ver si va a tener la culpa Stallman de lo borricos que son algunos periodistas de la tele.

Stallman es el iniciador e impulsor del movimiento GNU, con lo que eso ha significado y significa para el Software Libre en general y para el GNU/Linux en particular.

Esto es lo que se debería difundir por la tele.

El tema se veía venir ya que el problema de Icaza es que es demasiado joven (al menos para ser sensato) y tiene demasiadas hormonas y ganas de ser el jefe de la manada y hace lo que sea para llamar la atencion (leeros algo de comportamiento animal).

Ademas pienso que un proyecto como Gnome no deberia tener una única cabeza pensante ni tiene porque seguir los designios de una unica persona. Esto es malo, además por la arrogancia de de Icaza por ser un hombre con personalidad, porque si hay una cabeza visible con eliminar esa cabeza ya tienes a todo un proyecto fuera de juego.

Por cierto, si ya no os gusta Gnome probad con Icewm junto con dfmcomo gestor de iconos y ya vereis algo bonito y rapido.

Icaza estaba predestinado a ser el mayor hacker de la historia, pero en su corazon habia miedo. El miedo lleva la odio, el odio al...(y como vaya) y fialmente fue arrastrado por el reverso tenebroso

Pues eso que quiero mi Gnome 2.0

Como dijo Tanembaum, hacer un sistema operativo en los años 90 tipo UNIX es ser muy corto de miras. La capacidad de las máquinas crece a un ritmo descomunal, mientras que el sistema operativo consume menos porcentaje de la máquina.Es decir, los requerimientos del sistema operativo (hablando de kernel...) no crecen de la misma forma que la capacidad de las máquinas. Esto nos lleva a que podemos desarrollar modelos de kernel que antes no hubieramos pensado por falta de rendimiento, por ejemplo un microkernel.( y si, todos sabemos que W2000 no es microkernel, que nos la juegan con las aplicaciones win32, pero a pesar de todos el módelo es bueno)

Sobre todos esos dolares, no tengo ni idea que habrá hecho con ellos o si el tuvo acceso a ese dinero. De todas formas que se lo pida el que se lo dio...si es que se lo dio a el y no a Ezael.
Y sobre esto :
" Minix estará lleno de buenas e innovadoras ideas, pero LiNUX funciona."
Sin comentarios. Me comparas un sistema operativo Academico ( es decir donde se prima la sencillez, para que un alumno aprendaaaa como funciona un s.o) con un sistema operativo no académico y que para más inri ahora es comercial. De todas forma no creo que sea MINIX el sistema revolucionario en cuanto a ideas buenas e inovadoras, aunque la separación de procesos aunque sea dentro del kernel esta muy bien.

Ta lue !

Las Qt no eran libres cuando se inició el proyecto Gnome: que ahora sí lo sean no significa que fuera una falacia entonces... ¿donde está la falacia?

La falacia está en decir que GNOME se creó como alternativa a KDE porque este estaba viciado por la licencia propietaria de las Qt y ahora resulta que GNOME va a tener mas vicio propietario que KDE.

Era peligrosisimo hipotecarse asi.

A mi me parece mas peligroso hipotecarse como pretende Icaza, con Microsoft, una multinacional convicta por prácticas monopolísticas, que con Troll Tech. E insisto, en que había soluciones alternativas que no requerían el desarrollo de otro entorno de escritorio completo.

Ademas no es descabellado pensar que la propia existencia de Gnome empujase a que finalmente a que se liberasen las Qt (quiza no lo hubieran hecho si todos hubiesemos dependido de ello y no hubiese habido alternativa libre)...

Seguramente es cierto lo que dices, pero no menos cierto es que los esfuerzos invertidos en GNOME bien podrían haberse derivado a Harmony o a algo parecido.

Ademas, fue una apuesta, reprochar a RMS la decision de apoyar entonces a gnome es muy poco razonable (no te jode, a toro pasado, yo tambien digo lo que es mejor: si a RMS le dieran ahora a elegir qué escritorio incorporaba al proyecto GNU, seguro que su decision era otra que entonces)

Estoy seguro de haber dicho esto años antes, no sólo a toro pasado :-P De todas maneras a Stallman no se le reprocha el error, que de humanos es equivocarse, lo que se le reprocha fue la aptitud arrogante y partidista que tomó en el asunto y siguió manteniendo hasta cuando las Qt ya eran GPL.

El software libre te da a elegir, lo que a a veces ha parecido que es dividir esfuerzos con el tiempo se ha visto que es saludable...

A veces sí y a veces no, como decía Julito Iglesias... De todas maneras yo lo decía porque el argumento inicial fue el de tener un entorno de escritorio totalmente libre sin problemas de licencias; ahora que si tú me dices que el argumento es otro (porque duplicar esfuerzos puede ser productivo) muchas gracias por aclarar mis dudas y ya lo discutiremos en otro momento.

JAM ha dado de lleno, imaginemos la siguiente situación (aunque es real):

    Realizamos cierto HW (un grabador de EEPROMs controlado por un 68HC11 de Motorola) que se comunica con el PC por el puerto serie, necesitamos hacer un API ('driver' del hardware, es lo que se hace con una impresora o un ratón, dar un API al fin al cabo), que dé acceso a las funciones de HW independizándonos de él, de como lo haya implementado, del protocolo de comunicación por el puerto serie, etc. Si hiciese este API (driver) con Java mi grabador de EEPROMs funcionaría en cualquier sistema operativo con Java (ya se encargará de acceder al puerto serie).

Saludos.

Vamos a ver:

1. Uso Java porque me gusta más que C++ (aunque llevo ya 10 años programando en C y C++, desde 1992), no sólo es lo portable que es, para mí lo más importante es su elegancia, que me permite hacer programas más grandes, en menos tiempo, con menos quebraderos de cabeza (¡¡vaya, si el puto C ha hecho un cast automático a 'int' de mi puntero a un array de punteros a funciones!! ;-).

2. Java es portable de verdad, no 'muy portable', totalmente portable, es una REALIDAD. He estado mirando STL y creo que está en pañales: llegar a la 'independencia del SO' con 30 años de edad, creo que es una verguenza que se hayan empezado a preocupar ahora ...

3. Claro que hay librerías para Bluetooth en C++ (y en C), pero son totalmente diferentes unas de otras (sólo hay que ver las de Linux: BlueZ, OpenBT y BlueDrekar). El diseño de cada una es radicalmente diferente, y eso en Linux, si me voy a otro sistema operativo (PalmOS, WindowsCE, Windows, etc) ... me dá la risa.

Independencia: He comentado JNI para aquellos que no encuentren lo que necesiten en Java y tengan que acceder al SO directamente, aunque a la mayoría les será suficiente con las clases estándar (por lo menos a mí sí). De todas formas, no es lo mismo implementar una _única_ función de forma nativa y hacer el resto del desarrollo en Java que tener que implementar librerías completas (casi ná: threads, sockets, sonido, video, ...), sólo tendrías que implementar un pequeño programa en C o C++ que haga la conversión de tipos entre la llamada de la función en Java y en C/C++, y eso con la ayuda de las funciones que te dá JNI (funciones para convertir Strings Java en arrays de caracteres de C, convertir Unicode a ASCII, etc).

    JNI: Claro que Java acaba llamando a funciones del SO (¿cómo lo iba a hacer sino? ¿por arte de magia?), igual que el C, el C++, el Objetive-C, el Pascal, el Fortran, el Ada, el Python, los scripts del Bash, ... Y todos ellos ejecutándose como código máquina (claro: si al final va a resultar que todo se tiene que ejecutar en el microprocesador). Todas la funciones de Java que tienen que acceder al HW o a algo del SO tienen una función 'final native', pero igual que todas las funciones de C al final tienen código en ensamblador (al final, final), pero a diferencia de otros lenguajes Java tiene TODAS las funciones nativas implementadas en los SO que soporta, no las tienes que hacer tú.

    100% Java: El interfaz que me dan es 100% java, aunque esto normalmente se refiere a que el programa no usa funciones particulares del SO (como hacía el java de M$), algo no estandarizado.

    Bluetooth: La DIFERENCIA es que el api de Java para Bluetooth está perfectamente definido (JSR-82) y quien se curre la implementación hará las llamadas usando JNI al api del SO operativo en concreto, y yo no me tendré que preocupar si el chisme bluetooth está conectado como PCMCIA, USB o puerto serie, ni de cómo han hecho el driver, ... que es lo que sucede ahora mismo (mírate los 'drivers' para Bluetooth de Linux: BlueZ, OpenBT y BlueDrekar y ya me contarás).

    Argumentos: ¿Te parecen pocos? Léete mis respuestas a otros comentarios ...

    Saludos.

Pues sí, me parecen pocos argumentos. Es fácil hablar a toro pasado. Evidentemente, AHORA tienes todo eso en Java... y mucho más, claro. Pero eso está ahí por un esfuerzo de diseño y adaptación (porting). Muy bien... Pero alguien se lo ha tenido que currar, porque evidentemente Java se ejecuta sobre una máquina real (a diferencia de su virtual), y al final tiene que hacer llamadas a sistema.

Sobre lo del 100% Java... Sí, yo lo uso en el sentido: "se hace sin necesidad de llamadas dependientes del SO", que es el que creo que Sun quiere.

Lo que me hace gracia de todo esto es la forma en que lo expones, que parece que Java fuera "el lenguaje definitivo", "el que lo tiene todo", "el que...", cuando lo único que se necesita para que otro lenguaje tenga exactamente lo mismo es un esfuerzo de adaptación igual que el que se ha hecho para Java. El mejor ejemplo me lo das con el de Bluetooth: ¿qué es el API que te han dado? Una mera librería. Diseña un API similar para otro lenguaje, impleméntalo, y listo.

La ventaja de Sun (el problema, para otros), es que ellos deciden cuales son las interfaces estándar del lenguaje, y claro, les es más sencillo decidir qué entra y qué no en una versión estándar del lenguaje... Otro gallo les cantaría si dependieran de comités que se pasan 10 años para estandarizar algo tan sencillo como los elementos básicos del lenguaje (ejemplo: C++)