#15 Si tienes razón, está claro que se podría conseguir un sistema mucho más ágil y eficiente atacando al hardware y saltándose el Java. Pero tampoco hay que olvidar que, gracias a usar Java, no sólo tenemos acceso a lo que Google nos da, sino que podemos hacer todo lo que nos permite el JDK, o lo que haya implementado alguien en alguna librería. ¿Que queremos parsear XML, JSON o lo que sea? Ahí están las clases que lo hacen. ¿Que queremos hacer un juego? Pues en OpenGL.
Eso es algo que otras plataformas más "eficientes" no tienen. Si programas para un iPhone tienes que ceñirte a lo que Apple haya tenido a bien permitirte, aunque implique no poder usar el bluetooth porque Apple no lo contempla en su API. Y si vas a saco a por el hardware, pues te lo tienes que hacer todo a pelo (salvo que te instales un linux y empieces a añadirle capas y capas, por lo que estaríamos igual). Al final es una balanza entre eficiencia computacional y flexibilidad/potencia.
#1 seguro? es decir... has visto el hardware que llevan los teléfonos android para mover el sistema? Necesitan una grúa para mover una cerilla. Es decir, cada aplicación no se ejecuta de forma nativa sino que es necesario emular una máquina java y ejecutar en ella la aplicación. Esto implica que se desperdicia una capacidad ingente de recursos tan sólo para emular la máquina java. Para mostrar una mínima aplicación que haga cualquier chorrada básica necesitas mucho más hardware que con firefox OS. Por ejemplo geeksphone ya tiene teléfonos firefox os disponibles para desarrolladores. Estos teléfonos vienen con un hardware muy inferior al que suelen venir en los teléfonos android habituales (ahora ya nos acostumbramos a los multicores y con velocidades de escándalo) sin embargo el rendimiento es alto.
Como android no empiece a espabilar y saque un buen repositorio de aplicaciones compiladas nativamente para el SO va a tener un futuro incierto dado que necesita mucha más potencia hardware y por tanto sus teléfonos siempre serán más caros que otros que monten sistemas como firefox os.
#3 vale, no he sido semánticamente correcto. Cambiemos emular por virtualizar. Aunque apuesto a que la mayoría de los usuarios no sabrían diferenciarlo.
#2 Lo siento, pero eso que cuentas no tiene mucho sentido.
1. Android acepta aplicaciones nativas perfectamente, son los desarrolladores los que prefieren usar Java
2. Razones para usar Java:
- Al ejecutarse en una máquina virtual, no hay que recompilar cada vez que se cambia de dispositivo.
- Al ejecutarse en una máquina virtual, es más seguro: se reduce la probabilidad de que una aplicación cabrona pueda acceder al kernel del SO.
- Todo el mundo sabe programar en Java y hay muchas herramientas existentes para ese lenguaje.
- La diferencia de velocidad es muy pequeña en casi todos los casos, y aprovechar la velocidad por completo requeriría recompilar y optimizar para cada dispositivo.
A menos que hayan encontrado una manera de solventar en Firefox OS, dudo mucho que los mismos programas puedan funcionar en un hardware más reducido, a menos que se limite el hardware y el acceso de los usuarios al mismo.
#5
1.- por eso he dicho que "Como android no empiece a espabilar y saque un buen repositorio de aplicaciones compiladas nativamente para el SO" . No he negado la posibilidad de que existan sino que hasta ahora no hay un buen repositorio.
2.- Existen mejores opciones que utilizar una máquina virtual como por ejemplo utilizar un buen api incluído en el sistema. Esto sería ideal dado que sólo habría que compilar el api para una serie de dispositivos distintos y una sola vez. Por otra parte... existen los lenguajes script. Si has probado ruby alguna vez, conocerás la cantidad de librerías que hay para hacer de todo y más. La eficiencia es muchísimo mejor que la del java (sí, a pesar de ser un lenguaje script, ya ves). El consumo de memoria mucho mejor (por dios, un "hola mundo" en java es una vergüenza lo que consume). Lo de la diferencia de velocidad... ¿pequeña? ¿lo dices en serio? ¿te refieres una aplicación pesada en java contra una aplicación que haga lo mismo nativamente? ¿has visto la cantidad de memoria que se desperdicia?
En cuanto a seguridad del sistema... bueno, decir que he estado recompilando unos cuantos kernels para dispositivos armv6 y no quieras ver la cantidad de opciones para securizar un sistema en cuanto a protección de memoria, comunicación entre procesos y demás. Esto unido a una política correcta de gestión de usuarios (es decir, que las aplicaciones descargadas se ejecuten siempre con un usuario con limitaciones) te da como resultado un sistema seguro.
Por otra parte, la pre-existencia de dispositivos armv6 como raspberry pi y muchos otros anteriores (sheevaplug, mini2440, mini6410, pogoplug ....) hace que ese camino ya esté recorrido y la existencia de código fuente de la mayoría de paquetes de linux hace que una gran mayoría sea recompilar y listo.
Fíjate en gentoo. Hay paquetes precompilados para diferentes arquitecturas pero también tienes la opción de que el sistema se baje el código y lo compile automáticamente para la tuya.
Lo de que el java lo conoce mucha gente... bien, y el C también, y el ruby también. Hay que estar más al día en cuanto a temas de programación. El java no ha sido eterno. Un día apareció y antes todo el mundo sabía otros lenguajes.
Lo dicho, que lo interesante es un api de sistema que ofrezca una rápida productividad y el resto es no "reinventar la rueda" porque el camino ya está hecho
#6 El que tiene que espabilar en todo caso no es Android, son los desarrolladores de aplicaciones. Si los desarrolladores se molestan en crear aplicaciones nativas para Firefox OS, no se porque no deberían molestarse en hacer lo mismo para Android.
Que Android tenga una maquina virtual Java para ejecutar las aplicaciones es una extra, una ventaja para quien la quiera usar. En ningún caso va a ser un inconveniente pues su uso no es ogliatorio.
#6 Y eso de que Ruby es más eficiente que Java, habrá que ver donde, porque tu comentario no lo deja claro. En consumo de memoria seguro, pero en tiempo de ejecución Ruby ni se acerca a Java.
#2 La máquina virtual Dalvik de Android tiene JIT desde la versión 2.2 (Mayo 2010) y las aplicaciones se pueden hacer totalmente nativas desde la versión 2.3 (diciembre 2010). Ya se que los móviles de ciertos fabricantes y ciertos operadores tardan mucho tiempo en actualizarse pero aún así tu comentario está desfasado.
#8 desde versiones 2.1 llevo ejecutando aplicaciones nativamente diseñadas para linux (el mc haciendo unas cuantas ñapas), no se trata de que "no se pueda", sino de que hay muy poca variedad en comparación con la cantidad de aplicaciones en código fuente disponibles para linux y de fácil portabilidad para android o firefox OS. Por eso digo que deben espabilar para que haya "un buen repositorio de este tipo de aplicaciones" porque si el firefox os las llega a ofrecer entonces por mi parte tendrá la partida ganada.
Por otra parte insisto. Hay teléfonos multicore con frecuencias altísimas y cuyo rendimiento no justifica para nada el hardware.
#2 Cambia java por javascript y máquina virtual por motor de ejecución de javascript y renderizado de HTML, y ya tienes Firefox OS. Bueno, con la diferencia de que en Javascript no hay JIT.
Cosas como "Java is faster than C++" hacen que el segundo artículo sea muy sospechoso.
No obstante, por la experiencia que tengo con diferentes lenguajes de programación no me resigno a depender del java a largo plazo. Me parece un atraso en muchos sentidos. Y no considero que sólo los programadores de aplicaciones para android deban espabilar, sino los propios programadores del sistema. Dado que habiendo tanta aplicación disponible para linux es una pena que no se haya dado acceso o posibilidad de instalar aplicaciones desde repositorios oficiales... pero claro... eso iría en detrimento del negocio del market
#13 Es que el bajo rendimiento de Java es una especie de mito basado en argumentos muy obsoletos ya. Y es cierto que, en algunos casos, un código Java puede ser más rápido que otro en C++.
Por ejemplo, una tarea muy intensiva computacionalmente, si se hace en C++ se compilará para una arquitectura concreta. Normalmente, por compatibilidad, se hará para i686 (lo que viene a ser un Pentium II), de manera que aprovechará lo que tenga esa arquitectura, aunque lo ejecutemos en un Core i7. En cambio, si la misma rutina se hace en Java, a la hora de ejecutar la máquina virtual puede ver que está en un Core i7, y aprovechar lo que nos proporciona esa arquitectura.
Como siempre, hay un montón de matices (se podría compilar el código C++ para que en ejecución "busque" características mejores que las de un i686, y habría que tener en cuenta también el overhead de la máquina virtual Java), pero en definitiva la distancia entre no tanto C++ y Java, sino entre el código compilado y el interpretado, se ha reducido mucho en los últimos años.
#14 permíteme ser cabezón en esto pero habiendo tanto lenguaje disponible sigue pareciéndome un atraso compilar las aplicaciones para una arquitectura virtual. Sigo prefiriendo alguno de los lenguajes script disponibles y eliminar ese layer. Al fin y al cabo las cosas en java son portables porque se ha portado la vm. Es lo mismo que portar un intérprete pero aliviamos mucho el coste en virtualización ( no me gusta, qué le vamos a hacer. Trabajo en un lugar donde tenemos cientos de sistemas virtualizados y otros cientos sin virtualizar y qué quieres... me quedo con las máquinas reales ).
Reconozco una ventaja interesante del java. Que es la protección al programador. El código se distribuye compilado. Vale. Pero hay otros lenguajes de muy alta productividad y gran eficiencia.
En mi opinión, que no tiene que ser la del resto, un sistema debe aportar un api sólido y versátil, una seguridad fiable y un uso de recursos razonable. Existen alternativas interesantes.
Por ejemplo (si no lo conoces te lo recomiendo) en http://narcissus.angstrom-distribution.org/ si en "Choose the complexity of the options below" eliges "Advanced" puedes construir un rootfs con interfaz "Opie" (basado en qt). Tuve la oportunidad de hacerme un rootfs para varios dispositivos arm(entre ellos un netbook chino) que usaban android. Me recompilé un kernel quitando la mayor parte de las opciones relacionadas con android. El resultado fue un sistema mucho más rápido y versátil. Muy sólido. (ya luego hice otras pruebas con debian+hardfp).
La realidad es que en android se ha conseguido que todo vaya bien agregando un hardware sobredimensionado. Móviles con varios núcleos superando el ghz para ejecutar decentemente taplicaciones de unos cuantos kb's o mb's ... me parece exagerado. No se justifica. Se puede conseguir un resultado igual de bueno con una plataforma más racional y permitiendo una reducción en el precio final para los usuarios. Fíjate en la raspberry pi. El precio es aceptable. Con un sistema que aproveche un poco los recursos podría cubrir las expectativas que un usuario le exige a un movil normal.
Bueno, que no me lío más. Sólo que a día de hoy no encuentro un sistema movil que me parezca adecuando. Tuve fe en QNX hace muchos años ya (parecía un BeOS para embebidos), quizás un día Haiku OS... pero por ahora la mejor salida a corto plazo para todo esto me parece Firefox OS
Sorry by the tocho.
Comentarios
#15 Si tienes razón, está claro que se podría conseguir un sistema mucho más ágil y eficiente atacando al hardware y saltándose el Java. Pero tampoco hay que olvidar que, gracias a usar Java, no sólo tenemos acceso a lo que Google nos da, sino que podemos hacer todo lo que nos permite el JDK, o lo que haya implementado alguien en alguna librería. ¿Que queremos parsear XML, JSON o lo que sea? Ahí están las clases que lo hacen. ¿Que queremos hacer un juego? Pues en OpenGL.
Eso es algo que otras plataformas más "eficientes" no tienen. Si programas para un iPhone tienes que ceñirte a lo que Apple haya tenido a bien permitirte, aunque implique no poder usar el bluetooth porque Apple no lo contempla en su API. Y si vas a saco a por el hardware, pues te lo tienes que hacer todo a pelo (salvo que te instales un linux y empieces a añadirle capas y capas, por lo que estaríamos igual). Al final es una balanza entre eficiencia computacional y flexibilidad/potencia.
Pues no le veo ninguna mejora con respecto a lo que ya existe (android, iphone)
#1 seguro? es decir... has visto el hardware que llevan los teléfonos android para mover el sistema? Necesitan una grúa para mover una cerilla. Es decir, cada aplicación no se ejecuta de forma nativa sino que es necesario emular una máquina java y ejecutar en ella la aplicación. Esto implica que se desperdicia una capacidad ingente de recursos tan sólo para emular la máquina java. Para mostrar una mínima aplicación que haga cualquier chorrada básica necesitas mucho más hardware que con firefox OS. Por ejemplo geeksphone ya tiene teléfonos firefox os disponibles para desarrolladores. Estos teléfonos vienen con un hardware muy inferior al que suelen venir en los teléfonos android habituales (ahora ya nos acostumbramos a los multicores y con velocidades de escándalo) sin embargo el rendimiento es alto.
Como android no empiece a espabilar y saque un buen repositorio de aplicaciones compiladas nativamente para el SO va a tener un futuro incierto dado que necesita mucha más potencia hardware y por tanto sus teléfonos siempre serán más caros que otros que monten sistemas como firefox os.
#2 ¿Emular una máquina Java? Todas las aplicaciones Java, que yo sepa, corren en una "máquina virtual".
#3 vale, no he sido semánticamente correcto. Cambiemos emular por virtualizar. Aunque apuesto a que la mayoría de los usuarios no sabrían diferenciarlo.
#2 Lo siento, pero eso que cuentas no tiene mucho sentido.
1. Android acepta aplicaciones nativas perfectamente, son los desarrolladores los que prefieren usar Java
2. Razones para usar Java:
- Al ejecutarse en una máquina virtual, no hay que recompilar cada vez que se cambia de dispositivo.
- Al ejecutarse en una máquina virtual, es más seguro: se reduce la probabilidad de que una aplicación cabrona pueda acceder al kernel del SO.
- Todo el mundo sabe programar en Java y hay muchas herramientas existentes para ese lenguaje.
- La diferencia de velocidad es muy pequeña en casi todos los casos, y aprovechar la velocidad por completo requeriría recompilar y optimizar para cada dispositivo.
A menos que hayan encontrado una manera de solventar en Firefox OS, dudo mucho que los mismos programas puedan funcionar en un hardware más reducido, a menos que se limite el hardware y el acceso de los usuarios al mismo.
#5
1.- por eso he dicho que "Como android no empiece a espabilar y saque un buen repositorio de aplicaciones compiladas nativamente para el SO" . No he negado la posibilidad de que existan sino que hasta ahora no hay un buen repositorio.
2.- Existen mejores opciones que utilizar una máquina virtual como por ejemplo utilizar un buen api incluído en el sistema. Esto sería ideal dado que sólo habría que compilar el api para una serie de dispositivos distintos y una sola vez. Por otra parte... existen los lenguajes script. Si has probado ruby alguna vez, conocerás la cantidad de librerías que hay para hacer de todo y más. La eficiencia es muchísimo mejor que la del java (sí, a pesar de ser un lenguaje script, ya ves). El consumo de memoria mucho mejor (por dios, un "hola mundo" en java es una vergüenza lo que consume). Lo de la diferencia de velocidad... ¿pequeña? ¿lo dices en serio? ¿te refieres una aplicación pesada en java contra una aplicación que haga lo mismo nativamente? ¿has visto la cantidad de memoria que se desperdicia?
En cuanto a seguridad del sistema... bueno, decir que he estado recompilando unos cuantos kernels para dispositivos armv6 y no quieras ver la cantidad de opciones para securizar un sistema en cuanto a protección de memoria, comunicación entre procesos y demás. Esto unido a una política correcta de gestión de usuarios (es decir, que las aplicaciones descargadas se ejecuten siempre con un usuario con limitaciones) te da como resultado un sistema seguro.
Por otra parte, la pre-existencia de dispositivos armv6 como raspberry pi y muchos otros anteriores (sheevaplug, mini2440, mini6410, pogoplug ....) hace que ese camino ya esté recorrido y la existencia de código fuente de la mayoría de paquetes de linux hace que una gran mayoría sea recompilar y listo.
Fíjate en gentoo. Hay paquetes precompilados para diferentes arquitecturas pero también tienes la opción de que el sistema se baje el código y lo compile automáticamente para la tuya.
Lo de que el java lo conoce mucha gente... bien, y el C también, y el ruby también. Hay que estar más al día en cuanto a temas de programación. El java no ha sido eterno. Un día apareció y antes todo el mundo sabía otros lenguajes.
Lo dicho, que lo interesante es un api de sistema que ofrezca una rápida productividad y el resto es no "reinventar la rueda" porque el camino ya está hecho
#6 El que tiene que espabilar en todo caso no es Android, son los desarrolladores de aplicaciones. Si los desarrolladores se molestan en crear aplicaciones nativas para Firefox OS, no se porque no deberían molestarse en hacer lo mismo para Android.
Que Android tenga una maquina virtual Java para ejecutar las aplicaciones es una extra, una ventaja para quien la quiera usar. En ningún caso va a ser un inconveniente pues su uso no es ogliatorio.
#6 Y eso de que Ruby es más eficiente que Java, habrá que ver donde, porque tu comentario no lo deja claro. En consumo de memoria seguro, pero en tiempo de ejecución Ruby ni se acerca a Java.
http://benchmarksgame.alioth.debian.org/u64q/ruby.php
http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
#2 La máquina virtual Dalvik de Android tiene JIT desde la versión 2.2 (Mayo 2010) y las aplicaciones se pueden hacer totalmente nativas desde la versión 2.3 (diciembre 2010). Ya se que los móviles de ciertos fabricantes y ciertos operadores tardan mucho tiempo en actualizarse pero aún así tu comentario está desfasado.
#8 desde versiones 2.1 llevo ejecutando aplicaciones nativamente diseñadas para linux (el mc haciendo unas cuantas ñapas), no se trata de que "no se pueda", sino de que hay muy poca variedad en comparación con la cantidad de aplicaciones en código fuente disponibles para linux y de fácil portabilidad para android o firefox OS. Por eso digo que deben espabilar para que haya "un buen repositorio de este tipo de aplicaciones" porque si el firefox os las llega a ofrecer entonces por mi parte tendrá la partida ganada.
Por otra parte insisto. Hay teléfonos multicore con frecuencias altísimas y cuyo rendimiento no justifica para nada el hardware.
#2 Cambia java por javascript y máquina virtual por motor de ejecución de javascript y renderizado de HTML, y ya tienes Firefox OS. Bueno, con la diferencia de que en Javascript no hay JIT.
Pues si es como el navegador, me da que vamos a tener teléfonos de 8GB de RAM en poco
Cosas como "Java is faster than C++" hacen que el segundo artículo sea muy sospechoso.
No obstante, por la experiencia que tengo con diferentes lenguajes de programación no me resigno a depender del java a largo plazo. Me parece un atraso en muchos sentidos. Y no considero que sólo los programadores de aplicaciones para android deban espabilar, sino los propios programadores del sistema. Dado que habiendo tanta aplicación disponible para linux es una pena que no se haya dado acceso o posibilidad de instalar aplicaciones desde repositorios oficiales... pero claro... eso iría en detrimento del negocio del market
#13 Es que el bajo rendimiento de Java es una especie de mito basado en argumentos muy obsoletos ya. Y es cierto que, en algunos casos, un código Java puede ser más rápido que otro en C++.
Por ejemplo, una tarea muy intensiva computacionalmente, si se hace en C++ se compilará para una arquitectura concreta. Normalmente, por compatibilidad, se hará para i686 (lo que viene a ser un Pentium II), de manera que aprovechará lo que tenga esa arquitectura, aunque lo ejecutemos en un Core i7. En cambio, si la misma rutina se hace en Java, a la hora de ejecutar la máquina virtual puede ver que está en un Core i7, y aprovechar lo que nos proporciona esa arquitectura.
Como siempre, hay un montón de matices (se podría compilar el código C++ para que en ejecución "busque" características mejores que las de un i686, y habría que tener en cuenta también el overhead de la máquina virtual Java), pero en definitiva la distancia entre no tanto C++ y Java, sino entre el código compilado y el interpretado, se ha reducido mucho en los últimos años.
#14 permíteme ser cabezón en esto pero habiendo tanto lenguaje disponible sigue pareciéndome un atraso compilar las aplicaciones para una arquitectura virtual. Sigo prefiriendo alguno de los lenguajes script disponibles y eliminar ese layer. Al fin y al cabo las cosas en java son portables porque se ha portado la vm. Es lo mismo que portar un intérprete pero aliviamos mucho el coste en virtualización ( no me gusta, qué le vamos a hacer. Trabajo en un lugar donde tenemos cientos de sistemas virtualizados y otros cientos sin virtualizar y qué quieres... me quedo con las máquinas reales ).
Reconozco una ventaja interesante del java. Que es la protección al programador. El código se distribuye compilado. Vale. Pero hay otros lenguajes de muy alta productividad y gran eficiencia.
En mi opinión, que no tiene que ser la del resto, un sistema debe aportar un api sólido y versátil, una seguridad fiable y un uso de recursos razonable. Existen alternativas interesantes.
Por ejemplo (si no lo conoces te lo recomiendo) en http://narcissus.angstrom-distribution.org/ si en "Choose the complexity of the options below" eliges "Advanced" puedes construir un rootfs con interfaz "Opie" (basado en qt). Tuve la oportunidad de hacerme un rootfs para varios dispositivos arm(entre ellos un netbook chino) que usaban android. Me recompilé un kernel quitando la mayor parte de las opciones relacionadas con android. El resultado fue un sistema mucho más rápido y versátil. Muy sólido. (ya luego hice otras pruebas con debian+hardfp).
La realidad es que en android se ha conseguido que todo vaya bien agregando un hardware sobredimensionado. Móviles con varios núcleos superando el ghz para ejecutar decentemente taplicaciones de unos cuantos kb's o mb's ... me parece exagerado. No se justifica. Se puede conseguir un resultado igual de bueno con una plataforma más racional y permitiendo una reducción en el precio final para los usuarios. Fíjate en la raspberry pi. El precio es aceptable. Con un sistema que aproveche un poco los recursos podría cubrir las expectativas que un usuario le exige a un movil normal.
Bueno, que no me lío más. Sólo que a día de hoy no encuentro un sistema movil que me parezca adecuando. Tuve fe en QNX hace muchos años ya (parecía un BeOS para embebidos), quizás un día Haiku OS... pero por ahora la mejor salida a corto plazo para todo esto me parece Firefox OS
Sorry by the tocho.