Android, iOS, tiempos de respuestas y por qué nada es gratis en sistemas informáticos "Ricardo Galli", de software libre

#102   #99 Probablemente (lo digo por suposición) tiene algo que ver en el malware el que tenga que ser cada fabricante el que dé las actualizaciones, con lo que igual algunos agujeros que ya están reparados en la rama principal no se reparan hasta meses después en algunas versiones de algunos fabricantes.

Encuentro que sería más lógico que Android tuviera un repositorio central independiente de los fabricantes para las actualizaciones y un repositorio propio de cada fabricante para las paridas propias (fondos de pantalla, colocación de los botones, ...).

#103   #99 iOS tiene menos malware porque Apple impone más control sobre las aplicaciones que Google, no porque el sistema sea mejor y el impacto de Carrier fue nulo en los Android oficiales.

Windows está preparado para que lo ejecute el 90% de la población pero sólo para que lo usen un 5% y el que un sistema tenga o no más malware responde al control que se ejerce sobre las aplicaciones más que a la seguridad que pueda implementar dicho sistema.

#104   El artículo está fenomenal porque explica muy bien los conceptos clave y, a diferencia de la mayoría de la información existente en estos temas, los pone en contexto respecto a los sistemas operativos actuales. En la universidad normalmente explican en tercero en la asignatura de Sistemas Operativos lo de Round Robin, TLB's, etc, pero de una forma tan distante al mundo real que tras haber aprobado parece que uno sabe lo mismo que antes de empezar a estudiar.

#105   #73
Sí, sí que las puedes hacer con iOS. El problema de los compiladores es que hay situaciones en las que no saben qué valores contienen las variables por ejemplo. Tampoco son conscientes de la arquitectura sobre la que trabajan para aprovechar mejor los buses de datos.

El inlining de bucles lo pueden hacer pero en muchos casos es mejorable a mano por el propio programador. Además existe el uso de las intrínsecas y la posibilidad de meter ensamblador en línea mezclado con el propio código C.

Muchas veces optimizaciones que aplica el compilador no son adecuadas para un momento determinado, aunque evidentemente si se equivocaran muy a menudo no se dejaría optimizar a los compiladores.

Todo se reduce a una cuestión muy simple: los compiladores no tienen información de ejecución del programa.

Tener una máquina virtual siempre será más lento: recolección de basura, más memoria utilizada, control de límites de los índices de acceso, etc. Una cosa es marcar las áreas de memoria disponibles para un proceso y otra distinta es andar controlando la memoria de cada objeto y los accesos que realiza. Todo eso tiene un coste alto.

Poner funciones en línea dinámicamente y desenrollar bucles al vuelo...

JIT fundamentalmente lo único que añade es que el código Java deja de ser interpretado para ser ejecutado de forma nativa ya que lo compila a código nativo, pero obviamente sigue utilizando la máquina virtual java y los intérpretes o JITs nunca han hecho optimizaciones avanzadas porque los compiladores no son capaces de hacerlas.

#106   Yo _{también quiero probar}

#107   #84 Sin animo de polemizar o molestar, el artículo al que se fundió a negativos decía exactamente eso, que iOS es más fluido que Android. Los motivos serán estos o aquellos, pero matar al mensajero porque no te gusta el mensaje que te trae es comportarse como un fanboy/hateboy.

#108   Tengo amigos con iPhone, y envidio lo fluido que les va todo (yo tengo un Nexus S que no va nada mal, pero aún así no es lo mismo).

Pero los que le han hecho jailbreak y han empezado a meter cosas de cydia (algunas apps por ser gratis, otras porque no las permite Apple), en poco tiempo han empezado a sufrir los mismos problemas de Android, pero mas severos y frecuentes (ya no va tan fluido, se les cuelga, aplicaciones no funcionan como deberían...)

Así que la conclusión como usuario es fácil. Si te conformas con lo que hay en la Apple Store, un iPhone seguramente te de mejor experiencia de usuario. Si quieres libertad total con tu móvil, hazte con un Android y compra el que se ajuste a tus necesidades (que los hay desde 100€ hasta 600€, y obviamente no van a funcionar igual con según qué aplicaciones)

#109   #103 Sí, IOS tiene menos malware porque Apple impone más control sobre las aplicaciones que google... ¿y eso no es bueno?, en teoría supongo que no, en la práctica es cojonudo porque te libra de un montón de problemas. Quizás sea hora de que google imponga un poco más de control, no una dictadura pero tampoco la anarquía que reina ahora.

Y windows está tan infestado porque lo usa el 90% de la gente entre la cual mucha (demasiada)desactiva el antivirus para piratear office, cuando no crackean el propio antivirus habiendo alternativas gratuitas pero es curioso que nos demos cuenta de eso ahora cuando nos tocan lo nuestro (android).

En cuanto a lo de estar preparado para que lo ejecute el 90% pero sólo para que lo use el 5%, explícate.

Después: "el que un sistema tenga o no más malware responde al control que se ejerce sobre las aplicaciones más que a la seguridad que pueda implementar dicho sistema. "

Ahora se llama así, antes se llamaba "windows es una mierda".

Si en el fondo tienes toda la razón, yo tan solo pretendo hacer notar que cuando se trata de, por ejemplo, google, el sistema es una maravilla pese a que no vaya tan fluido y el malware haya crecido un 450%, por contra, si se llamase Whindows Phone el sistema sería una mierda porque no va tan fluido y el malware ha aumentado un 450% .

P.D: el impacto de Carrier fue nulo en los androids oficiales porque es algo que hay que instalar, por contra, no ocurrió lo mismo con millones de androids en los cuales sí se instaló por una política demasiado laxa por parte de google. Así mismo, hay mucho malware que está afectando a Android indiferentemente de si es oficial o no.

#102 No sé cuantos agujeros están ya tapados y por tanto una actualización solucionaría todos los problemas pero es suficiente malware como para pensar que al menos una parte de él seguiría afectando incluso actualizado. No obstante, lo de los repositorios sería una buena idea, una idea que no existe porque google está dejando demasiada libertad y eso nos está perjudicando.

#110   #93 Un rendimiento desastroso de Windows 98/Me en los primeros Pentium IV y Athlon , sobre todo al tener múltiples programas abiertos. Aún recuerdo lo mucho que se ralentizaba mi98 en el Athlon con 4 aplicaciones y 256MB de RAM, mientras que Suse 8 volaba.

#111   #109 No tiene sentido tu argumentación, dices que IOS tiene menos malware porque Apple impone más control que Google pero luego afirmas que Windows tiene más malware porque lo usa más gente igual que pasa con Android ... o es una cosa o es otra. ¿Que pasa que IOS no lo usa nadie? No, ni mucho menos, el tener un repositorio centralizado dónde además todas las aplicaciones que entran en dicho repositorio son revisadas por varias personas es lo que hace tener menos malware al sistema, es lo que las distribuciones de Linux llevan haciendo desde hace años y es ahora cuando todos se están dando cuenta de que es lo que realmente funciona.

Que Windows tenga más o menos malware no tiene nada que ver en que sea un buen sistema o no lo sea, del mismo modo que pasa con Android. Ni Windows ni Linux son capaces de evitar la idiotez de los usuarios y si un usuario se empeña en bajarse un programa con un virus e instalarlo lo va a hacer sin importar el sistema. Es lo que no entendéis los fanboys de Windows, el problema de Windows han sido las malas políticas de seguridad empleadas durante años en un empeño por intentar facilitar la vida de los usuarios y lo que han conseguido es crear usuarios imbéciles, ocultando las extensiones de los ficheros cosa que impide saber a la gente lo que realmente está haciendo u obligando a trabajar con una cuenta de administrador, además de su nula portabilidad, aplicaciones desastrosas en cuanto a estándares y seguridad como IE6 integradas en el sistema, su mala gestión de la memoria, su escasa escalabilidad y su empeño por dificultar la interoperabilidad con otros sistemas.

#112   Debo decir que estoy sorprendido por el nivel de comentarios (y visitas) que generó este apunte:

twitter.com/#!/gallir/status/144795993953681408
Y Menéame generó casi 10.000 visitas a un artículo muy técnico, y muchos comentarios razonables. A veces recupero la fe en MnM :-P

Hay muchos comentarios muy razonables, no podría contestar a todos, demasiados, pero si me preguntáis contestando a a éste, intentaré responder.

#113   #112 Has descubierto que no eres el único que sabe cosas. Supongo que estarás muy impactado.

#115   #114 #101

C++ es un lenguaje mucho peor que Java ¿por qué habría que usarlo? C++ tiene sentido para un sistema operativo, o librerías (Android las tiene programadas en C y C++), pero no para programación de aplicaciones de móviles. Además el Java ya se usaba para aplicaciones móviles (en Nokia y teléfonos compatibles con Java ME.

Por otro lado, Google compró Android cuando ya estaba desarrollado a medias, supongo que poco podían cambiar.

#116   #107 Yo solo soy responsable de mis actos. Yo no lo voté negativo.

#117   #116 No me refería a nadie en concreto.

#118   #111 Para no entenderlo lo has explicado bastante bien en la primera mitad de tu segundo párrafo:

"Que Windows tenga más o menos malware no tiene nada que ver en que sea un buen sistema o no lo sea, del mismo modo que pasa con Android. Ni Windows ni Linux son capaces de evitar la idiotez de los usuarios y si un usuario se empeña en bajarse un programa con un virus e instalarlo lo va a hacer sin importar el sistema. "

Del mismo modo que android no va tan fluído porque tiene que adaptarse a diferente hardware (al contrario que apple) y también, por no querer ser tan restrictivo y revisar las aplicaciones como lo hace apple, muchas de estas no están tan optimizadas y por otra banda se llena de malware, el problema de windows viene por tener que soportar usuarios imbéciles. Resumiendo, no toda la culpa es de windows, ni de android y sin embargo la norma siempre fue echar pestes contra windows.

En la segunda mitad del segundo párrafo te contradices, primero dices que la culpa no es del SO, después echas pestes contra él. A ver, o una cosa u otra.

Lo de las extensiones no tiene tanta importancia, la tiene para ti porque sabes lo que significan y sabes que un exe es un ejecutable y un jpg una imagen, pero la mayoría de la gente no lo sabe aun cuando las tienen visibles desde un principio, así que seguirían sin saber lo que hacen.

Lo de las cuentas de administrador sí fue un error (que ahora ya está corregido) pero no obligan desde el XP donde siempre se pudo usar una cuenta de usuario.

IE6 en cuanto a estándares da igual, da igual porque no respectar los estándares no afecta a la seguridad y da igual porque en aquellos tiempos "sólo existía" IE6. Lo tocante a la seguridad es admisible.

Todo lo demás es más tema de un mal rendimiento que de seguridad, por tanto se sale de esta discusión, aunque huelgue decir que no estoy de acuerdo.

#119   #105 solo un apunte


"Aunque Java no permite la expansión manual de llamadas a métodos, muchos compiladores JIT realizan esta optimización durante la carga de la aplicación y pueden aprovechar información del entorno en tiempo de ejecución para llevar a cabo transformaciones eficientes durante la propia ejecución de la aplicación. Esta recompilación dinámica, como la que proporciona la máquina virtual HotSpot de Sun, puede llegar a mejorar el resultado de compiladores estáticos tradicionales, gracias a los datos que sólo están disponibles durante el tiempo de ejecución."

es.wikipedia.org/wiki/Java_%28lenguaje_de_programaci%C3%B3n%29#Rendimi

Algunos compiladores jit si que ponen en linea funciones "en tiempo de ejecución". Ademas esto no es solo cosa del compilador existen directivas que le permiten decir al programador que funciones se pueden poner en linea y segun que condiciones

Había por ahí un documento técnico de microsoft sobre el .net (que ahora mismo no doy encontrado) que explicaba esto e incluso como podía poner en linea no solo funciones sino también bucles, todo esto en tiempo de ejecucion.

#120   #105 Lo encontre!

msdn.microsoft.com/en-us/library/ms973838#dotnetperftechs_topic4

#121   #119
En la Wikipedia sajona encontrarás información mucho más completa: en.wikipedia.org/wiki/Java_performance

JIT no hace un inlining con cabeza ya que para eso hay que perfilar el programa entero (ejecutarlo y analizar su rendimiento) y no es algo barato de hacer, redundando por tanto en la lentitud de ejecución y restricciones de tiempo. Hace un análisis simple pero no realiza especializaciones ni nada por el estilo por restricciones obvias de tiempo. Y no hablemos de jugar con punteros y distintos tipos de datos para manejar información adecuándose al hardware.

Lo mismo en el caso de Microsoft y .NET con el desenrollado de bucles. Esas cosas no permiten obtener óptimos resultados.

GCC puede hacer inlining sin indicarlo de forma expresa y diría que es un compilador "tradicional". El desenrollado lo hacen también los compiladores tradicionales y lo mismo a la hora de hacer inlining o predicción de saltos mediante indicadores que el programador habrá averiguado después de ejecutar el programa de forma completa y analizar resultados de ejecución.

Lo que hacen JIT y .NET básicamente son desenrollados e inlining con mayor precisión al tener información en tiempo de ejecución, pero tampoco es algo especial de JIT o .NET dado que GCC también permite tomar datos de profilings para hacer mejor su trabajo (que no es poco tampoco).

en.wikipedia.org/wiki/Adaptive_optimization
en.wikipedia.org/wiki/Just-in-time_compilation
en.wikipedia.org/wiki/HotSpot

Evidentemente, las técnicas JIT son muy buenas, pero la compilación estática también permite hacer lo mismo con información adicional (ventaja de JITs que lo hacen solos) y aún así se puede mejorar con modificaciones a mano.

#122   No conozco en profundidad la arquitectura del software de Android, pero sí de OSX e IOS.
Estoy de acuerdo con el artículo (lamento no haber llegado a leer el referido).

No obstante, si IOS es más fluido es sin duda por su supervisor gráfico, que controla el dibujado de las aplicaciones de forma muy eficiente. En IOS, los contextos gráficos son texturas mapeadas en memoria transferidas por DMA y la mayoría de operaciones gráficas las provee el hardware.

Obviamente, las estrategias del núcleo en gestión de memoria y procesamiento son muy significativas, pero en la práctica, tareas tan insulsas como una animación, video o dibujado de texto pueden suponer la mayor parte del tiempo de procesamiento. Y si la CPU tiene que esperar para transferir datos, apaga y vámonos.