Archive for the ‘Tecnología’ Category

Android, iOS, tiempos de respuestas y por qué nada es gratis en sistemas informáticos

febrero 16, 2013

Hace unas pocas horas escribí esta respuesta sobre Por qué iOS es más fluido que Android (con buen criterio, eliminaron la entrada). Obviamente, por cuestiones de longitud y la “respuesta rápida” que requiere un comentario, no me quedó todo lo completo que requiere el tema. Lo que me gustaría explicar daría para muchas horas de charlas. De hecho, enseño estos temas en mi asignatura de Sistemas Operativos (II), dedico al menos unas 12 hs de clase, y aún así no entramos en muchos detalles importantes. Pero intentaré resumirlo en este apunte, fundamentalmente para que se entiendan los problemas de arquitectura, y de cómo toda decisión que se tome en una arquitectura, lenguaje o programa tiene implicaciones positivas y negativas, siempre.

Lo básico

Apple tomó muchas decisiones técnicas con el objetivo de mejorar la “experiencia de usuario”, pero por sí mismas serían inútiles -o más perjudiciales- si no van acompañadas de medidas de control estrictas. Es fundamental el papel de los controles de las aplicaciones en el App Store (¡ojo! no los justifico). Independientemente de otras consideraciones políticas, dado su simplicidad y soluciones ad hoc, el iOS sería muy fácil de “abusar” por los desarrolladores y aplicaciones.

Por el contrario, Android es una plataforma abierta que puede user cualquier fabricante, que permite la instalación de cualquier aplicación. El control de aplicaciones del Market por parte de Google es prácticamente inexistente. Esto hace que no valgan soluciones ad hoc, obliga a implementar en el sistema operativo medidas de seguridad y control “canónicas”, en el sentido que mantenga las condiciones fundamentales de todo sistema operativo de propósito general: eficiencia, equidad (fairness) y seguridad.

Cualquiera que haya estudiado la teoría y arquitectura de sistemas operativos (o que haya leído sobre el tema) entiende perfectamente que la eficiencia, equidad y seguridad son objetivos contradictorios. Mayor equidad o seguridad afectan negativamente a la eficiencia, y viceversa.

Hay otro problema importante. Se desea que los sistemas operativos de teléfonos actúen como sistemas de tiempo real también para las aplicaciones (ya tienen que serlos en otros aspectos, como la “radio” a interacción con protocolos de red de telefonía).  Es decir, con límites precisos de “tiempo de respuesta”: el tiempo que transcurre desde que ocurre un evento (como tocar la pantalla) hasta que se empieza a ejecutar al “gestor” de ese evento (la aplicación).

Los sistemas Unix (como Linux o Darwin) no son de tiempo real, su planificador de procesos (scheduler) es no-determinístico. No lo es por una sencilla razón: si se pretende una buena “multiprogramación” (llamada comunmente “multitarea”) se deben cumplir los objetivos de equidad y otros más complejos, como evitar los tiempos de espera muy largos (starvation). Esos dos objetivos impiden asegurar (formalmente) que el sistema sea de tiempo real. Además, los sistemas de tiempo real exigen que el tiempo de ejecución de cada ráfaga de ejecución de las aplicaciones (CPU bursts) críticas sea lo suficientemente breve para poder asegurar “tiempo real” a las demás aplicaciones (recordad que el scheduler debe ser determinístico, por ende no puede asegurar equidad).

En pocas palabras, si deseas comportamientos próximos al tiempo real necesitas relajar los requerimientos de un sistema de propósito general, y aumentar el control de las aplicaciones que se ejecutan en ese sistema.

¿Se entiende el balance y decisiones contradictorias que hay que tomar? En un sistema de multiprogramación, con el hardware equivalente (los dispositivos iOS y Android lo son), si  se desea disminuir las latencias se deben relajar otras condiciones del planificación de procesador (por lo que se obtiene una “peor multitarea”) y aumentar el control de aplicaciones (lo que genera otros problemas polítics, éticos, sociales y de negocio). Si pretende más apertura y libertad, se debe ser muy estricto con equidad y seguridad, lo que genera efectos negativos sobre el tiempo de respuesta.

Al final el tema de fondo no es [sólo] técnico, sino de otros aspectos más filosóficos: control vs apertura.

Creo que ya expliqué la base del problema técnico-filosófico, ya puedes dejar de leer si te agobian los detalles técnicos. Pero si te interesan, intentaré resumirlos en las cuatro partes que tienen más responsabilidad en los “tiempos de respuesta” de un sistema: las aplicaciones, el lenguaje y plataforma, la gestión de memoria, y el scheduler.

Las aplicaciones

El tipo de programación para móviles es esencialmente “dirigida por eventos” . Cuando el usuario toca la pantalla se llama la función que debe responder a ese evento (en Android se llaman “actividades”). La recomendación es que la aplicación no necesite mucha CPU ni tiempo para generar la respuesta, especialmente en los menús principales. Por supuesto, a este nivel, todo depende de los programadores de la aplicación, y supongo que estos son los mayores culpables de la “reacción lenta” de los menús cuando se interactúa con una aplicación.

Las aplicaciones también pueden tener otros malos comportamientos, por ejemplo consumir mucha CPU (aún cuando están en background o como servicio), no sólo molesta a todos los demás procesos, también aumenta el consumo de batería y la temperatura.

¿Cómo solucionar este problema? O se hace un control estricto de cada aplicación, o se implanta un scheduler más sofisticado y genérico que puede tener algunas aristas.

Ya sabéis qué decisión se tomó en Apple, y cuál en Google.

El lenguaje y plataforma

iOS y Android difieren mucho en este aspecto.iOS usa el mismo lenguaje estándar del Mac OS X, el Objective-C. Los programas se compilan directamente en código ejecutable para el procesador. En cambio Android optó por usar Java, que se convierte a un lenguaje intermedio ejecutado por una máquina virtual optimizada (similar la máquina virtual de Java, pero es diferente), Dalvik.

Obviamente el rendimiento entre ambas es muy diferente, el código ejecutable siempre será más eficiente que otro se que no se ejecuta directamente en el procesador. Pero esto no significa que los diseñadores de Android sean unos imbéciles, de nuevo, fueron decisiones estratégicas que están muy por encima de temas técnicos, aunque terminan afectando dramáticamente a este último.

Si el sistema operativo se va a ejecutar siempre sobre una única arquitectura, como hizo históricamente Apple (aunque tuvo dos migraciones importantes, exitosas pero dolorosas y muy molestas para los desarrolladores), la opción natural es generar directamente el ejecutable. Además, Apple licenció el diseño de ARM [*] y compró una empresa de diseño de chips (Intrinsity) para que se encargue del diseño de sus procesadores y no depender ni de fabricantes externos (antes lo hacía Samsung).

Por otro lado, la intención de Android era entrar a competir en el mercado con un sistema libre/abierto y multiplataforma (después de varios intentos fallidos, como OpenMoko), por  lo que era preferible un sistema que no obligase a compilar una aplicación para cada tipo de procesador. Si no, estaría condenada al fracaso. Para solucionar el problema de la eficiencia diseñaron desde cero el Dalvik, que al usar el lenguaje Java ya tenía a su disposición muchas herramientas (como Eclipse), librerías de desarrollo (como las clases estándar de Java), y una comunidad enorme de progamadores (me abstengo de opinar sobre Java, pero afortunadamente Android lo ha mejorado muchísimo con su API y framework  de programación).

Aunque Java ya está preparado para multithreading, por cuestiones de seguridad los diseñadores de Android prefirieron, muy acertadamente, ejecutar cada aplicación como un proceso diferente y completamente aislado. Dejaron esta parte de la gestión de procesos al núcleo Linux, que es muy eficiente y está más que probado.  Con esta arquitectura de máquinas virtuales replicadas en procesos independientes, se generan otras infeficiencias: cada proceso debe cargar su máquina virtual, y éste debe cargar después todas las clases estándar de Java que hacen falta para la aplicación. Esto haría que el tiempo de arranque de cada programa fuese inaceptable, y han recurrido a un truco muy guapo para solucionarlo (por eso digo que la arquitectura de Android es una obra impresionante de ingeniería informática): el zygote.

El kernel Linux implementa un mecanismo llamado copy-on-write ( COW) que permite que los procesos hijos (creados con el fork()) compartan memoria con el padre (por eso la creación de procesos es muy rápida de Linux). Cuando un proceso crea un hijo, éste reusa la misma memoria y tablas de páginas del padre, pero todas las páginas se marcan como “sólo lectura”. El hijo puede comenzar a ejecutarse muy rápidamente. Cuando uno de los procesos intenta escribir sobre una página compartida, se genera una interrupción de error (trap), el sistema operativo coge el control, verifica que se trata de memoria COW, asigna una nueva página, copia el contenido de la página afectada, modifica la tabla de páginas de uno de los procesos para apuntar a esta nueva, y permite la continuación de ambos procesos. Además de la rapidez con que puede crear y ejecutar procesos, se ahorra mucha memoria RAM, por ejemplo, el código ejecutable y las librerías comunes siempre se comparten (nunca se modifican).

¿Cómo aprovecha Android este mecanismo? Crea un proceso inicial, el zygote, que carga la máquina virtual y las librerías estándares de Java y del API de Android. Cada nueva aplicación que se arranca es hija de este zygote, et voilà, ya ganaron eficiencia y se ahorra muchísima memoria (Chrome y Chromium usan la misma técnica para abrir pestañas y ventanas rápidamente).

¿Es o no es una obra maestra de ingeniería? Claro que sí, se han tomado todo ese trabajo para compensar el problema de eficiencia y seguridad de una máquina virtual. Por eso, cuando pienso que por debajo hay una máquina vrtual ejecutando el código, me maravillo con la velocidad de ejecución de las aplicaciones en Android.

Por supuesto, esta arquitectura con memoria virtual tiene otros efectos negativos a la hora de medir los tiempos de respuesta: en la gestión de memoria y cache, que trato más adelante.

[*] En la biografía de Steve Jobs cuentan como despuésde evaluar usar Intel para los iPad, Jobs le dijo muy cabreado a los ejecutivos de Intel algo así como: “son muy buenos para procesadores de alto rendimiento, pero sois unos inútiles para procesadores de bajo consumo”.

La gestión de memoria del núcleo

Los procesadores que usan iOS y Android son similares en cuanto a su gestión de memoria (también similares a los ordenadores que usáis). Ambos gestionan memoria virtual conpaginación. Los procesos no generan direcciones físicas de RAM, sino direcciones lógicas que son convertidas a direcciones físicas en cada ejecución por el módulo conocido como Memory Manager Unit (MMU). Cada proceso tiene sus propias tablas de página que mantienen la relación de número de página del proceso (es el índice a la tabla) a ubicación en la memoria RAM. Los procesadores ARM permiten páginas de 4KB a 64KB (lo usual son 4KB), así que cada aplicación tiene miles de páginas, y por lo tanto tablas de miles de entradas (en ARM hay tablas de dos niveles, en la arquitectura Intel o AMD, cuatro niveles).

Cada entrada de la tabla almacena propiedades de la página: lectura (r), escritura (w), ejecución (x), accedida (a, o acces bit), modificada (d, o dirty bit), cargada en memoria (p, present bit), etc. Por esta razón las tablas se mantienen en la memoria RAM, lo que genera otro problema ¿cómo hace el MMU para no tener que acceder dos veces a la memoria -primero a la tablas de página y luego a la dirección que se pretende acceder-? Sin un mecanismo que lo solucione, el tiempo efectivo de acceso a la memoria sería al menos el doble de lo que permite la memoria RAM (o sea, una patata de lento).

Para solucionar este problema se usan sistemas de cache que almacenan en registros del procesador un conjunto de entradas de las tablas: el translation-lookaside-buffer (TLB). El TLB de los ARM suelen tener 128 entradas, cada una de ellas es una copia idéntica de la entrada de la tabla de páginas. Se intenta tener en el TLB las entradas más usadas, así, cada vez que el MMU encuentra la entrada en el TLB puede acceder directamente a la memoria (hit), si no, tiene que descartar una entrada y cargar la que hace falta (fault). El hit ratio es una indicación de la velocidad de acceso efectivo a memoria, viene dado por el procesador y el algoritmo de sustitución que se use, a mayor número de entradas en el TLB, el hit ratio sube.

Cada vez que el scheduler selecciona otra aplicación para ejecutar se produce un cambio de contexto, entre otras cosas significa que las entradas del TLB deben ser invalidadas (ya no sirven para el nuevo proceso, por seguridad tampoco debe poder usar esos datos), además las entradas que han sido modificadas por el procesador (por ejemplo, que una una página fue accedida o modificada) deben ser copiadas a la tabla original en memoria (flush). Por eso se dice que los cambios de contexto son “caros”, y es muy importante las decisiones que toma el scheduler para minimizar los cambios de contexto “inútiles” (¡pobre el scheduler!, las cosas que tiene que tener en cuenta para que lo usuarios no se quejen porque el audio pega saltos).

Un proceso con máquina virtual como Android mete mucha más presión al TLB (y por ende baja el hit ratio) que un proceso que ejecuta código nativo. Para ejecutar una función equivalente en máquina virtual se necesita más memoria, la del código del intérprete, la memoria usado por éste, más el código en lenguaje intermedio y la memoria que necesita el programa. No sólo eso, prácticamente cada ejecución del código intermedio implica cambios en las variables del propio programa, también en las de la máquina virtual, forzando a que en cada cambio de contexto sean más las entradas del TLB que deben ser copiadas a la RAM. O sea, los cambios de contexto son también más caros.

Lo mismo que pasa con el TLB (recordemos que es un tipo específico de cache), pasa con la memoria de cache de RAM en el procesador, la máquina virtual mete más presión, por lo que también bajan sus hit ratios.

De nuevo, una decisión de negocio (y política y filosófica), genera muchas complicaciones técnicas que hay que resolver. Si uno las tiene en cuenta, empieza a dejar de pensar en términos de fanboy y se cuestiona muchas cosas. Entre otras, lo eficiente que tiene que ser Linux para gestionar esta complejidad adicional sin que se note demasiado la diferencia.

El scheduler

Se llama scheduler al módulo del sistema operativo que selecciona cuál será el siguiente proceso a ejecutar. A cada proceso se le le asigna un tiempo máximo de ejecución: el cuanto (o quantum). Si al proceso se le acaba el cuanto, el sistema operativo se apropia de la CPU (por eso se llaman apropiativos o preemptive), y llama al scheduler para seleccionar el siguiente de la lista de procesos que esperan para ejecutar (este mecanismo se denominaround robin). El scheduler de Linux (como la gran mayoría) no son determinísticos, significa que a priori no se puede conocer la secuencia de ejecución de procesos, por lo que no se puede asegurar analítica o formalmente que los procesos se ejecuten en un tiempo máximo predeterminado (si éste es suficientemente pequeño).

No todos los procesos tienen los mismos requerimientos, aquellos interactivos, o de reproducción multimedia necesitan menores tiempo de respuesta que un servicio enbackground, o que consume mucha CPU. Para eso se usan las prioridades, cada proceso tiene una prioridad inicial (por ejemplo “multimedia”, “normal”, “de fondo”, etc.), luego el scheduler la ajusta dinámicamente (prioridad dinámica) dependiendo del comportamiento del proceso y las necesidades de los otros. Por eso, el comportamiento de un sistema que use prioridades depende del comportamiento global de todos los procesos, estos no se pueden predecir, y de allí que sea no determinístico, y que se generen tiempos de respuesta variables.

El scheduler  además tiene que tomar en cuenta muchos factores adicionales (p.e., minimizar los cambios de contexto), y evitar que se produzcan esperas muy largas (starvation) que se pueden producir porque procesos con mayor prioridad están cogiendo siempre la CPU y no dejan ejecutar a otros de menor prioridad. Imaginaros que tenéis el reproducto de música de fondo, y que estáis por sacar una foto. La aplicación de foto podría estar consumiendo el 100% de CPU para actualizar la imagen, por lo que produciría cortes en la música, insoportablemente molesto ¿no? Pues es el pobre scheduler el que tiene que evitar estos problemas, tomando decisiones muy rápidas, cientos de veces por segundo.

Para evitar estas esperas tan largas en los casos extremos (corner cases) como el que acabo de decir, el scheduler mantiene dos colas, la activa y la inactiva. Siempre asigna procesos desde la cola activa. A cada proceso se le asigna un tiempo máximo (además del cuanto) que puede estar en la cola activa (el timeslice, por ejemplo 500 mseg), cuando consume todo su tiempo se le mueve a la cola inactiva. Cuando ya no queda nadie en la cola activa, el scheduler cambia, la activa pasa a ser la inactiva, y viceversa. Esto aumenta aún más el efecto “no determinístico” del scheduler, y puede producir saltos o latencias elevadas si el procesador está temporalmente sobrecargado.

Para evitar estas latencias que molestan a la interactividad del usuario se pueden tomar varias medidas ad hoc, por ejemplo subir la prioridad al máximo a la aplicación que está activa (así hacía Windows), pero esto genera otros problemas: ¿si la aplicación activa abusa y no deja de usar la CPU? (un truco obvio de programador para que su aplicación parezca que es más rápida y eficiente ¿no?) ¿y si hay procesos en background que necesitan la CPU  -por ejemplo un SMS, o responderá la red antes que pase el timeout- y esperan demasiado tiempo?

Pues es muy complicado, y cualquier “truco” que se ponga al scheduler deja la puerta abierta para que los programadores abusen… salvo que hagas un control exhaustivo de cada aplicación que se vaya instalar en el teléfono. ¿Se entiende por qué Apple puede recurrir a trucos ad hoc y evitar al mismo tiempo el abuso de las aplicaciones?

Si por el contrario renuncias a hacer ese control, no queda más remedio que el scheduler haga su trabajo, como en cualquier sistema operativo de uso genérico. Y que la solución adoptada sea lo suficientemente buena, simple, genérica y segura. ¿Se entiende por qué la solución en el Linux de Android es más difícil de encontrar? ¿o por qué le llamé una “solución canónica?

¿Como puede Android mejorar los tiempos de respuesta?

Evidentemente hay dos caminos obvios.

Por un lado, mejorar paulatinamente el scheduler (si es que allí reside el problema). No es una cuestión de un día, ni un año, en Linux se tardó años en encontrar un planificador que funcione tan bien como la actual para sistemas interactivos (el scheduler CFQ).

La otra parte, la gestión de memoria, depende en gran medida del apoyo del hardware. Un procesador con más capacidad de cache y TLB mejoraría mucho, pero también tiene su coste: más transistores, más consumo, más temperatura, mayor tamaño. A medida que se mejore el proceso de fabricación (más transistores en el mismo chip), seguramente incluirán TLB y cache con más capacidad. Lo mismo ocurre con el aumento de la potencia bruta y el aumento de cores (aunque  creo que afectan en mejnor medida a los tiempos de respuesta de la interfaz).

Tampoco me extrañaría que el código de los drivers de la pantalla sea de baja calidad (como suelen ser todos los drives, comparados con el núcleo del sistema operativo, se hacen bajo presión, y la prioridad es el hardware, no el SO) y encuentren big locks que no tocan.

De todas formas, los tiempos irán mejorando paulatinamente hasta que no podamos detectar diferencias en las latencias de la interactividad. Al mismo tiempo, iOS tendrá que ir incluyendo mejores capacidad de “multitarea” (como ya pasó desde que salió la primera versión de iOS, y seguramente irá reduciendo los controles de calidad que hace a cada aplicación).

Supongo que os dáis cuenta de la complejidad técnica de estos “cacharritos”, y que las decisiones de negocio imponen muchas restricciones y problemas al desarrollo del software, lo que obliga a los ingenieros a aplicarse a fondo. No es que los ingenieros de iOS son unos genios, y los de Android unos inútiles, los requerimientos y grados de libertad son diferentes.

Ley informática: optar por la apertura tiene costes técnicos iniciales, optar por el software libre tiene costes técnicos iniciales, pero producir una plataforma totalmente bajo control también tiene costes (sociales), y a más largo plazo.

 

Vía: gallir.wordpress.com

Anuncios

Llega Mailbox a la App Store, un nuevo cliente de correo que pretende revolucionar nuestra bandeja de entrada

febrero 8, 2013

Hace escasas horas se ha anunciado el lanzamiento oficial de Mailbox en la App Store, un cliente de correo que analizamos hace pocas semanas y que propone e introduce una forma diferente y más productiva de controlar nuestros correos, como si de una lista de tareas se tratase. Después de meses de espera, Mailbox ya está disponible para iPhone e iPod Touch aunque, por el momento, no podremos hacer uso de la aplicación.

¿Y por qué digo esto? Por lo siguiente. Mailbox está obteniendo una acogida espectacular y, para evitar colapsos y controlar la gran masa de usuarios, han decidido activar la aplicación de manera progresiva a través de invitaciones. Una vez iniciada la aplicación por primera vez nos mostrará el número asignado para la cola de invitaciones. Así es, podremos descargar la app desde la App Store pero no podremos probarla hasta pasada varias semanas.

Mailbox está destinado principalmente para aquellos usuarios que controlan, responden y gestionan decenas de correos al día. Permite marca los correos como completado, pendiente de resolver (deslizar levemente hacia la izquierda), eliminarlo (deslizar más rápido hacia la derecha) o archivarlo (deslizar suavemente hacia la derecha) con solo un simple gesto. La gestión de nuestra bandeja se reduce a unos pocos movimientos de dedo.

Ojo, por el momento Mailbox solo es compatible con cuentas de correo de Gmail y no está adapatado para iPad. Desde hoy puedes descargar gratuitamente la aplicación desde la App Store para dispositivos iPhone e iPod Touch de la manzana, pero ten en cuenta que no podrás usarla hasta dentro de semanas o hasta que se normalice el servicio.

 

Sitio oficial | Mailbox
Descarga | Mailbox (App Store)

Ubuntu se convertirá en el quinto competidor del mercado móvil a partir de octubre

febrero 8, 2013

Al final hasta se adelantarán y todo: Canonical va a poner su Ubuntu para móviles a disposición de los desarrolladores a finales de este mismo mes con intenciones de lanzarlo en “dos mercados geográficamente grandes” durante octubre. Los primeros pasos, con la compañía buscando apoyo de la comunidad de programadores, ya está dado.

No podían haber elegido un mejor año para adentrarse en el mercado de los móviles y las tabletas: el mercado sigue dominado por Google y Apple, pero tenemos a Windows Phone 8 y a BlackBerry 10 dispuestos a diversificar un poco más esta competencia. Ubuntu se convertiría en el quinto frente, y sería el segundo sistema operativo de código abierto que intenta colocarse como un rival serio después de Android.

Ubuntu es una de las distribuciones Linux más populares, y su entrada en los móviles podría calar. Pero una cosa es ofrecer la instalación de Linux en los ordenadores, donde un usuario puede decidir instalarlo en cualquier momento; y otra muy diferente es ofrecerla en el mercado móvil mayoritariamente controlado por las operadoras.

La esperanza recae en los móviles con Android capaces de modificar su arranque. El mercado móviles que ejecutan este sistema es el más grande ahora mismo, con lo que Canonical tiene oportunidades. Faltará, como siempre, que los usuarios se animen a probar algo nuevo. Mark Shuttleworth lo tiene claro, declarando que Ubuntu estará presente como un sistema único en todas las plataformas.

Vía | Wall Street Journal

Apps.co, a punto de cerrar convocatoria para recibir idea innovadoras

febrero 8, 2013

Apps.co

Apps.co sigue madurando.

Apps.co va por buen camino. Según Claudia Obando, líder del proyecto en el Ministerio TIC, se recibieron aproximadamente cerca de 15.000 inscripciones a ellos. De los registrados, 4.000 están aprendiendo en Codecademy, y cerca de 6.000 personas desarrollando y aprendiendo tecnologías Microsoft. De los últimos, 1.500 van a tener la oportunidad de postularse para certificarse en tecnología.

 

La segunda etapa de la convocatoria de Apps.co ya se está llevando a cabo. En esta las personas que tengan buenas ideas de proyectos o aplicaciones, pueden registrarse para participar en el proyecto que lidera el Ministerio TIC. Quienes se inscriban recibirán entrenamiento enfocado en enseñar a hacer crecer esas ideas, y convertirlas en proyectos que tengan demanda en el mercado. La convocatoria se vence mañana viernes.

Los requisitos para entrar en esta convocatoria no son tan altos, solo tener una idea y un plan para convertirla en un producto, como ya nos había dicho Obando. La idea es que la aplicación o proyecto en el que estén trabajando llegue a tener buena demanda (si es una aplicación gratuita) o a tener un buen comprador asegurado.

“Estamos esperando recibir 500 propuestas”, aseguró Obando, “y tenemos 280 cupos en todo el país”. Cuando terminen el ciclo, todos los beneficiarios se pueden postular a la siguiente etapa para recibir todo el apoyo de consolidación”. Además, “a los 20 mejores que salgan de ideación les vamos a hacer un reportaje desde el Ministerio, para moverlo en todos nuestros canales y en televisión y darlos a conocer.” 

El proceso de entrenamiento durará 8 semanas. Luego de este empezaría la tercera etapa de Apps.co. Este ya es dirigido a startups que ya tengan una validación en el mercado y quieran consolidar y escalar  su negocio.

Amazon y su moneda virtual: la clave está en aportar valor en el proceso de compra

febrero 7, 2013

Amazon nos sorprendió  anunciando Coins, su moneda virtual para la tienda de aplicaciones del Kindle Fire. Una forma (diferente) de pago para los usuarios que quieran comprar apps, libros e incluso contenidos in-app en la Amazon Appstore. La compañía de Jeff Bezos no es la primera en adentrarse en el terreno de las monedas virtuales; otras empresas como Facebook o Xbox (Microsoft) ya lo hicieron en su momento y sin tener demasiado éxito.

Como explicó mi compañero Miguel, las monedas de Amazon tendrán un valor de un céntimo de dólar y sólo estarán disponibles para usuarios americanos, para ser gastadas en aplicaciones y juegos para el Kindle fire. Amazon afirmó ayer que, para promocionar el lanzamiento primaveral de Coins, regalará “decenas de millones a sus clientes” para que las gasten en cualquier app, lo que puede generar un incremento temporal en el número de transacciones que se producen en la Appstore.

Sin embargo, la gran pregunta que muchos se hacen en estos momentos es si realmente las Amazon Coins aportan un valor claro a desarrolladores y consumidores. Algo que suponga una ventaja competitiva frente a comprar esas apps y contenidos utilizando dinero de toda la vida, cosa que va a seguir siendo posible.

Una nueva moneda virtual = más trabas para los usuarios

Las primeras reacciones a la noticia de ayer son una mezcla de positivismo e indiferencia. Uno de los argumentos más utilizados para poner en duda la utilidad de Amazon Coins es el que se centra en el extra complejidad que, se supone, añade el proceso.

Si cada vez que los usuarios quieren hacer una compra utilizando Amazon Coins tienen que pararse a convertir su dinero en la nueva moneda virtual de Amazon, se añade un paso extra en el proceso de compra que no aporta demasiada utilidad a simple vista. En un entorno en el que cada vez las empresas centran sus esfuerzos en facilitar y acortar el proceso de compra, Amazon estaría caminando en dirección contraria y sin tener en cuenta los intereses de desarrolladores y consumidores.

Amazon Coins también supone una forma de fidelización de cliente. Supongamos que un usuario tiene un millón de Coins. Ese millón de Coins tendrán que ser gastadas en contenidos de la Amazon Appstore y no podrán ser utilizados en un entorno diferente al de Amazon. Por lo tanto, lo que Amazon consigue es retener al cliente en su ecosistema y limitar sus opciones de gasto.

Monedas y divisas virtuales: la gallina de los huevos de oro

Sin embargo, y observando la trayectoria de Amazon en estos últimos años, resulta difícil pensar que Jeff Bezos y compañía vayan a caer en los errores del pasado, los que empresas como Facebook y Microsoft cometieron en su momento con sus monedas virtuales.

Amazon se caracteriza por entender perfectamente las necesidades del usuario y facilitar al máximo el proceso de compra (son inventores del one-click buying). Por eso resultaría sorprendente que el proceso de conversión de dinero tradicional a Amazon Coins fuese un proceso sin utilidad real, que no aportase un valor añadido y claro.

Además, Amazon parte con una ventaja que ni Microsoft ni Facebook tuvieron en su momento, y es el hecho de tener millones de tarjetas de crédito ya en su base de datos. Muchos consideran también que esta es una de las razones por las que los desarrolladores ganan más dinero, en términos relativos, en la Amazon Appstore que vendiendo esas mismas aplicaciones en Google Play para el resto de usuarios de Android.

Como parte del anuncio, Amazon aseguró a los desarrolladores que el hecho de utilizar o no Amazon Coins no perjudicará a sus ingresos ni al reparto 70/30 por ciento que todas las tiendas de aplicaciones realizan. De forma que el dinero recibido será el mismo si el consumidor compra una aplicación pagando €2.99 euros que 299 Amazon Coins.

Un aspecto que podría suponer una ventaja importante para Amazon está en el pago de comisiones por el uso de tarjetas de crédito. En estos momentos, para comprar apps para Kindle Fire es necesario asociar una tarjeta de crédito a la cuenta de Amazon. Con cada compra, la empresa tiene que pagar una comisión a los bancos en concepto de utilización de dichas tarjetas. Si Amazon Coins tiene una buena acogida por parte de desarrolladores y usuarios, Amazon podría ahorrarse bastante dinero en este tipo de comisiones si tenemos en cuenta que, la única transacción real se produce en el momento de comprar miles o millones de Amazon Coins.

Una gran oportunidad a corto y medio plazo

Es muy pronto para juzgar Amazon Coins e intentar predecir su impacto a corto y medio plazo. Los usuarios americanos comenzarán a recibir “decenas de millones de Coins” en abril, cuando la nueva moneda virtual de Amazon entre en escena. Tendrán que pasar varios meses para poder analizar la apuesta del gigante del eCommerce y para confirmar si realmente estamos ante un caso de éxito o un nuevo intento fallido, como lo fue en su momento Facebook Credits.

Si consiguen que desarrolladores y consumidores se acostumbren a realizar transacciones utilizando Coins, pueden tener mucho terreno ganado y una nueva forma para fidelizar a sus clientes. Y aunque no se prevee que la nueva moneda virtual de Amazon llegue a Europa y España en el corto plazo, seguiremos atentos la evolución de esta nueva apuesta de Jeff Bezos y su pequeño juguete.

Usando Google Drive como hosting para páginas web

febrero 7, 2013

Google ha incorporado a Google Drive una nueva funcionalidad: a partir de ahora podemos usarlo como hosting de páginas web con HTML, JavaScript y CSS.

Hay que dejar claro que esta posibilidad no sustituye a los servicios de hosting que solemos usar para alojar páginas de cierta envergadura, sino que más bien sirve para hacer pruebas y compartirlas de forma rápida. Al fin y al cabo sólo necesitamos tener una cuenta de Gmail.

El procedimiento es muy sencillo:

  • Una vez en Google Drive le dais al botón “Crear” y seleccionáis la opción “Carpeta”.
  • Con la carpeta creada, pasamos el ratón por encima de ella, desplegamos la lista de opciones que aparece justo a su derecha y seleccionamos “Compartir…”/Compartir.
  • En la ventana que se abre a continuación veremos que, allí donde se indica “Quién tiene acceso”, la carpeta aparece como privada por defecto. Clicamos en “Cambiar…”, marcamos “Público en la web” y guardamos.
  • Una vez dentro de la carpeta basta con subir nuestros archivos. Para hacer la prueba he subido un archivo html y una imagen.
  • Ya está todo listo, sólo nos queda obtener el link que usaremos para que los demás puedan ver la página que hemos creado. Para ello entramos en el html y le damos a “Vista previa”. Esto abre una ventana nueva en la que aparece la página web que hemos creado. Basta copiar la url de la barra de direcciones y enviarla o enlazarla donde queramos. El sencillo test que he hecho en un minuto con el bloc de notas tiene esta pinta: https://googledrive.com/host/0BxG6zx8qHMblVGx6anMzTWlULWc/test.html

Vía | Google Plus

Trece programas gratuitos esenciales [Acceso Directo]

febrero 7, 2013

Afortunadamente en Internet encontramos muchos programas hechos por personas que no tienen ningún problema en ofrecer gratis. Muchos de estos son aveces mejores que los programas contra los que compiten, o, por le menos, puede suplir perfectamente las necesidades básicas de un usuario promedio. En este sitio web, pueden descargar con toda la confianza, el software que recomendaremos a continuación.

 

1.   Pidgin

Pidgin es un cliente para múltiples cuentas de mensajería. En este se pueden integrar varias cuentas de AIM, ICQ, Google Talk, Jabber/XMPP, MSN Messenger, Yahoo!, Bonjour, Gadu-Gadu, IRC, MXit, Novell GroupWise Messenger, Lotus Sametime, SILC, SIMPLE, MySpaceIM y  Zephyr. Muy recomendado para personas que manejan varias cuentas y quieran administrarlas todas desde un solo programa.

Ir al sitio web

2. VLC

Casi todo el mundo hoy conoce VLC. Puede ser, fácilmente, el programa más reconocido de reproducción de video en el mundo. Es compatible con casi todos los formatos de video que existen hoy en día. Además de eso, el programa permite un manejo fácil de cosas como las pistas de audio, los subtítulos y el volumen.

Ir al sitio web 

3. Format Factory

No hay nada peor que descargar un archivo de una cámara que grabe en un formato rarísimo que no pueda reproducir ni VLC y que además sea pesadísimo. Por eso, existe Format Factory. El único propósito de este programa es el de convertir archivos de un tipo a otro. Es increíble la cantidad de formatos con los que es compatible y maneja todo: Audio, video, imágenes, etc.

Ir al sitio web

4. Audacity

Audacity es un programa muy bien hecho, que sirve para grabar y editar audio. Para pesar apenas 20 megabytes, este software ofrece al usuario las herramientas básicas para editar sonido bien. Lo bueno es que es muy fácil de manejar, cualquier usuario puede lograr manejarlo sin mucho esfuerzo.

Ir al sitio web 

5. Paint.NET

No todos necesitamos usar Photoshop para editar nuestras imágenes. Paint.NET no está en el extremo de ser software hiperespecializado, pero tampoco es un programa demasiado simple como Paint. Con este se puede desarrollar tareas sencillas como cortar y modificar una imagen; y agregarle una serie de efectos. La interfaz permite manejar fácilmente las imágenes.

Ir al sitio web.

6. SumatraPDF

No todos necesitan usar los programas que vienen preinstalados con Windows para leer PDF. SumatraPDF es un programa sencillo: sirve para simplemente leer este tipo de documentos con varias opciones diferentes. Su simpleza es su mayor virtud: pues al ser así de sencillo también carga los archivos mucho más rápido y no molesta tanto la memoria del computador.

Ir al sitio web. 

7. Foxit Reader

La versión amplificada de SumatraPDF. Con este se puede leer los PDF con más opciones: se pueden hacer anotaciones dentro de los textos, editarlos o cambiarle el color y tipo a la fuente. Es rápido y no come mucha memoria RAM; y además se le puede agregar software desarrollado por terceros para ampliar el catálogo de herramientas.

Ir al sitio web.

8. uTorrent

Para compartir archivos a través de torrents uTorrent puede ser uno de los mejores programas. Algunos sitios de tecnología lo nombran como uno de los mejores programas para Windows. Aunque hay muchos programas para manejar torrents gratuitos, uTorrent se destaca en permitir la búsqueda de archivos desde el mismo programa. A través de RSS se pueden automatizar las descargas que se quieren hacer. Además, el programa maneja inteligentemente la banda de Internet.

Ir al sitioweb.

9. Dropbox

Dropbox puede ser fácilmente el servicio de almacenamiento en la nube más popular que existe hoy en día. Por si no saben cómo funciona, el programa ofrece 2GB de almacenamiento gratuito en la nube y la posibilidad de manejar los archivos que almacenen en este en todos los dispositivos en los que esté instalado.

Ir al sitio web. 

10. Evernote

Si es un aficionado a la nube usted va a amar Evernote. Con este programa se puede producir cualquier tipo de archivos: audio, texto, imágenes, borradores y páginas web; y lo mejor de todo es que quedan almacenados en todos los lugares donde tenga instalada la aplicación. Para las personas que viven haciendo anotaciones rápidas o que graban información Evernote es la aplicación y programa perfecto.

Ir al sitio web

11. Keepass

Hoy en día todos manejamos muchas cuentas a diferentes sitios. La recomendación de los expertos es que no se utilice la misma contraseña para todos los sitios, pero eso se hace difícil cuando se manejan demasiadas cuentas. Este programa soluciona ese problema, pues el usuario puede meter en su base de datos todas las contraseñas que tiene y protegerlas con una sola y única contraseña maestra.

Ir al sitio web.

12. Launchy

Este programa le hace el trabajo mucho más fácil a los usuarios de  un computador. Con solo presionar alt+espacio y escribir el nombre del programa que quiere abrir y Launchy se encarga de abrirlo sin la necesidad de buscarlo en el explorador.

Ir al sitio web.

13. Winrar

Este puede ser otro programa muy conocido por los usuarios de Windows. Winrar es un programa que sirve para comprimir y descomprimir archivos. Es muy recomendado pues es muy fácil de manejar y permite el manejo de grandes archivos, partiéndolos en varias partes.

Ir al sitio web.

Vía: Enter.co

¿Cuándo y cómo cambian los términos de uso de los principales sitios web? Terms of Service Tracker nos lo dice

febrero 7, 2013

¿Cuándo y cómo cambian los términos de uso de los principales sitios web? Terms of Service Tracker nos lo dice

Los términos de uso debe de ser el tipo de documento menos leído en la web. Y si ya de por sí muchos no lo leen, peor cuando se realizan cambios. A menos que estos sean señalados por alguna publicación especializada o sean comunicados por la misma compañía, generalmente no nos enteramos cuando se producen. Es por eso que se creo Terms of Service Tracker, para enterarnos de cuándo cambia algo, cómo cambia y cómo era anteriormente.

Terms of Service Tracker ha sido creado por Docracy, un servicio donde los usuarios pueden compartir y hasta firmar documentos legales, y lo que hace es algo similar al control de versiones de software pero aplicado a los términos de uso de casi mil sitios en la web.

Su funcionamiento es simple: rastrean la página correspondiente de cada sitio diariamente y si hay algún cambio, la guardan en caché y la comparan con la versión anterior. En el sitio, podemos ver un listado de los sitios que han hecho cambios hace poco y, al pinchar sobre ellos, se despliega un resumen de los mismos. Si accedemos a la versión completa, como podéis apreciar en la siguiente imagen, se nos mostrará el texto anterior tachado y la nueva incorporación resaltada en verde.

Cambios en un documento

El rastreo de cambios se inició el 16 de enero de este año, así que por este medio no se puede encontrar modificaciones que se hicieran antes de esa fecha. Desde entonces hasta ahora, y al momento de escribir estas líneas, se están rastreando 968 sitios y se tienen almacenadas 1.126 versiones de estos documentos. Todos ellos están en inglés y la mayoría son de sitios de Estados Unidos.

Hay que tomar en cuenta que muchos cambios son apenas detalles insignificantes, como correcciones ortográficas o gramaticales, ajustes de formato o pequeñas modificaciones sin importancia; es decir, cosas que en la práctica no nos afectan como usuarios pero que son detectadas por el sistema. Por ejemplo, se señala que Twitter hizo un cambio el 6 de febrero, pero tan sólo se limito a cambiar http por https en una URL.

Pero esto no significa que el servicio pierda su validez, ni mucho menos. Es una excelente herramienta para monitorizar los cambios que introducen las compañías muchas veces sin decírselo a los usuarios y que pueden afectarlos de manera directa. Además, cuenta con un RSS, así que si nos suscribimos, iremos recibiendo en nuestro lector enlaces a los cambios que vayan detectando.

Vía | The Verge
Enlace | Terms of Service Tracker

Nuevo supercomputador quiere simular un cerebro humano

febrero 5, 2013

Hasta ahora no se había visto un proyecto tan ambicioso en la historia de la computación. Un grupo internacional de investigadores en sistemas están recaudando fondos para financiar lo que se llama Human Brain Project. El proyecto trataría de hacer un mapa para entender la manera como las miles de millones de redes neuronales se conectan al y con el cerebro, para así terminar desarrollando un computador que simule este organo. Esto demoraría cerca de diez años.

Los resultados de esta investigación ayudarían evidentemente a  la evolución de la robótica. Lograr rastrear y emular la manera en la que el cerebro funciona para producir un computador que logre hacer lo mismo, ayudaría a que los robots en el futuro pudieran -en teoría- llegar a ser como nosotros.

Los mismos investigadores dicen que este proyecto, en términos de ambiciones y objetivos, es tan grande como el del Colisionador de Hadrones. El proyecto consistiría en reclutar a más de 200 investigadores de 80 diferentes institutos alrededor del globo. Laussane, Suiza, será la ciudad donde se establecerá el centro de operaciones.

En unas declaraciones recientes por parte del equipo, dicen que además de contribuir a la robótica, las investigaciones ayudarían a responder muchas preguntas sobre el cerebro que aun no tienen respuesta. Además de eso, ayudaría al desarrollo de mejores y más poderosos computadores. 

La neurología sería otra de las grandes beneficiadas por estos estudios, pues podrían utilizar el estudio para tratamientos de enfermedades en el cerebro. Si se desarrolla este supercomputador, se podría llegar a utilizar como una especie de conejillo de indias en el que se pueden hacer pruebas sobre cerebros.

 

vía : Enter.co

¡Si tienes una idea de negocio a partir de las TIC, esta es tu oportunidad!

febrero 1, 2013