texto:   A-   A+
eliax

Editorial eliax: La Era del Procesamiento Distribuído en consumidores
eliax id: 8624 josé elías en abr 4, 2011 a las 12:08 AM (00:08 horas)
eliaxEn un artículo reciente en eliax escribí un comentario en donde explicaba que no nos engañemos pensando que dispositivos móviles como el iPad o celulares iPhone/Android no serán capaces de manejar la dura carga de programas de procesos intensos que programas como Photoshop requieren, ya que existe una solución justo en el horizonte, y de eso se trata este artículo de hoy...

Desde los inicios de la computación ha existido un concepto de "procesamiento distribuído", lo cual en palabras sencillas no es más que tomar una tarea de trabajo de algún software, y distribuir su carga entre dos o más entidades.

Sin embargo, salvo ciertas excepciones bastante particulares, ese tema nunca ha sentado pie en el mercado de consumidores, y mi propuesta de hoy es decir que no falta mucho para que eso suceda, y en grande...

Algunos técnicos tratarán de corregirme diciendo que procesamiento distribuído ya existe, dentro de los CPUs y GPUs de nuestras PCs (e incluso celulares y el mismo iPad), en donde un procesador tiene ya varios núcleos y la carga es distribuída entre estos. Incluso está el caso en servidores más potentes y en super-computadoras en donde se utilizan no solo núcleos, sino que decenas, centenares o miles de procesadores para entre todos atacar un problema en particular.

Pero no estoy hablando de eso.

Estoy hablando a un nuevo paradigma de lo cual o nadie aun sea ha percatado que ya prácticamente poseemos la tecnología para hacerlo, o simplemente lo mantienen en secreto hasta tanto lo perfeccionen, y la mejor manera de explicarlo es con un escenario...

Imaginen que tenemos un futuro descendiente del iPad en nuestras manos, y que arrancamos la aplicación Photoshop en esta. Imaginen además que estamos cómodamente sentados en nuestra oficina en casa.

Imaginen ahora que abrimos una imagen inmensa dentro de Photoshop, y que deseamos aplicar un filtro que requiere bastante procesamiento bruto. En este punto, tenemos dos opciones:

1. Opción 1, la manera tradicional: El usuario debe esperar hasta tanto el filtro complete su trabajo, sea un par de segundos o incluso minutos.

2. Opción 2, de lo que se trata este artículo: Distribuir la carga a dispositivos cercanos vía conexiones inalámbricas (o alambradas de ultra-alta velocidad).

Con la opción #2, el iPad (o cualquier otro dispositivo de otra empresa) detectaría que en tu casa tienes un Apple TV, un iPod Touch, un iPhone y una MacBook Air, a los cuáles previamente habías autorizado para que interactúen con tu iPad, por lo que el iPad decide que necesita más ciclos de CPU para terminar la tarea más rápidamente, así que toma el software de Photoshop y distribuye la carga automáticamente de forma paralela en todos esos dispositivos, de modo que ahora no es solo el iPad el que ejecuta el filtro de Photoshop, sino que todos los dispositivos en tu hogar, terminando el filtro su trabajo en 1 segundo en vez de 1 minuto, de paso ofreciendo muchísima más velocidad que la versión de Photoshop que utilizamos hoy día en el hardware más potente que podamos imaginar.

Pero, ¿y cómo funciona esto y cuál es la magia o ingrediente secreto necesario para que esto funcione?

Pues lo primero, es que se necesita una plataforma estandarizada que permita que código se pueda enviar entre un nodo y otro de la red, y que sea ejecutable de forma transparente y sin problemas de compatibilidad, y da la casualidad que una empresa ha estado forjando una estrategia para hacer exactamente esto desde hace un par de años: Apple (aunque ya veremos más adelante quien más podría ofrecer algo similar).

Noten que hoy día un Apple TV, un iPod Touch, un iPhone y un iPad tienen todos el mismo hardware en su núcleo, y el mismo sistema operativo, tal cual predije hace 4 años sucedería, con la diferencia de que en ese entonces yo lo llamaba "OS X Mini" y ahora Apple lo llama "iOS".

Con iOS, y su primo OS X (los cuales se fusionarán en algo que llamo "iOS X", como predije el año pasado), Apple está en la envidiable posición de tener un sistema operativo escalable desde un mini reproductor de audio como el iPod Nano, hasta una super-computadora, utilizando el mismo hardware y software de base en todos estos.

Hablamos de un "enjambre" de iOS, en donde cualquiera de ellos podría tomar ventaja del poder de computación de todos los demás en la cercanía. Incluso me puedo imaginar a Apple vendiendo cajitas similares al AppleTV para este fin, a US$99 dólares, que se venderían por millones a una población de consumidores hogareños y profesionales que desean más velocidad cada vez más.

El otro ingrediente necesario es un arquitectura de intercomunicación de alta velocidad, sea inalámbrica o alambrada. La versión alambrada ya no tiene que esperar, pues está aquí y se llama Thunderbolt, y curiosamente fue ideada por Apple y desarrollada por Intel, que ofrece velocidades (en su implementación actual en la MacBook Pro) de 20Gbps de ancho de banda agregado, lo que es mucho más que suficiente para implementar el escenario que propongo.

Por otro lado, ya existe un estándar en proceso para el 2012 de WiFi a 1Gbps, así como ya se está experimentando con otras tecnologías inalámbricas de más corto alcance y con velocidades de hasta 15Gbps, por lo que lo mismo que podremos hacer de forma alambrada se podrá de forma inalámbrica próximamente (aunque recuerden que incluso 1Gbps es suficiente para este escenario).

Y el tercer ingrediente es una plataforma de software sobre la cual los programadores escribirían sus aplicaciones para que estas escalen natural y automáticamente para tomar ventaja de periféricos cercanos (o incluso lejanos con lineas de Internet de alta velocidad y de baja latencia) y distribuir sus cargas de trabajo.

Una vez más, Apple ha estado desarrollando esa tecnología bajo las narices de todo el mundo, y se llama Grand Central Dispatch (GCD), una tecnología que ha sido parte de OS X desde hace un par de años, y que en la superficie aparenta ser una herramienta para el uso de multi-núcleos, pero algo me dice que Apple tiene planes muchos más extensos para GCD, posiblemente alineados a mis predicciones en este artículo.

Ahora, algunas personas no-técnicas es posible que estén incrédulos ante la posibilidad de que esto se haga realidad a corto plazo, pero lo cierto es que desde hace años en el sector profesional existen decenas de herramientas que hacen esto, solo que de forma propietaria a un software en particular.

Por ejemplo, existe un concepto llamado un "render farm" (o "granja de renderizadores") que se utiliza muchísimo en software de renderización de 3D, en donde uno instala varias copias de un software especializado en varios servidores, y la carga de renderización se distribuye entre todos los nodos. Esto incluso existe en programas de edición de video no-lineal (como Final Cut Pro), así como para programas de edición de imágenes, arquitectura, etc.

Sin embargo, esos son casos aislados, y cada uno de esos render farms son especializados a un software en particular, en vez de ser soluciones genéricas. Noten que eso no significa que no existan soluciones genéricas, sino que las genéricas no han tomado tracción por varias limitaciones (como la falta de plataformas estandarizadas, etc).

Sin embargo, más allá de Apple hay una empresa que puede hacer algo similar, y esa es Google. Sucede que una de mis tecnologías favoritas de todos los tiempos, llamada Jini, fue creada para resolver específicamente este escenario del cual hablo hoy, pero Jini lamentablemente fue un caso más de una solución en busca a un problema demasiado temprano. Jini estuvo al menos una década adelantada a su tiempo (y a propósito, si eres un arquitecto de software, recomiendo no solo que aprendas sobre Jini, sino que sobre su tecnología hermana, JavaSpaces, que quizás sea una de las piezas de software más elegantes y sencillas que he visto en mi vida).

Pero he aquí lo interesante: Jini tiene sus raíces en el mismo corazón de los desarrolladores originales de Java, y hace apenas unos días (como reporté por Twitter) que "El Padre de Java", James Gosling, dejó a Oracle/Sun para irse a Google, cosa que muchos se preguntaban para qué. Pues como podrán ver ahora, yo ya tengo una muy buena idea...

La plataforma Android OS de Google es en realidad una plataforma mayoritariamente Java (Linux solo ofrece servicios de bajo nivel y es en teoría incluso reemplazable sin afectar la funcionalidad de los niveles superiores del Android OS), y ya me puedo imaginar algo similar a Jini en una futura versión del Android OS, el cual de forma similar al iOS de Apple, fue diseñado para al menos en su núcleo funcionar desde en celulares hasta en televisores y servidores. Así que imaginen a Google ofreciendo un estándar abierto en donde cualquier empresa pueda fabricar y/o ofertar una "caja de computación" similar al Apple TV pero para estos fines. Sería fenomenal...

Así que en mi opinión, tras bastidores, lo sepan o no estas dos empresas, ambas se encaminan rápidamente hacia lo que será una nueva batalla titánica por nuestros dispositivos en el hogar y en nuestros negocios.

Y no puedo hablar por ustedes, pero esto me emociona muchísimo y no puedo esperar a ver el día en que veamos anuncios de estas dos (u otras) empresas sobre estos escenarios. No lo duden, estamos viviendo los tiempos más emocionantes de la humanidad...

Nota a técnicos: Jini a evolucionado a convertirse en Apache River. También visiten la página oficial de Jini, y la especificación oficial de JavaSpaces.

autor: josé elías

Comentarios

  • Interesante idea la mayoria de los dispositivos no son usados ni al 30% cuando estan en uso,solo se usan al 100 en momentos puntuales.
    Pero balance de carga y hacer software distribuido es muy muy muy dificil ,sabes de los problemas esta causando el uso de procesadores multinucleo, las GPU y distributivas.Ahora hacer una aplicacion que aproveche todo al mismo tiempo y sean realmente flexibles.
    Se necesitaria un cambio en el paradigma de programacion ,procesamiento de datos,algoritmos y estructura de datos.
    Para hacer que un desarrollador avanzado en tiempo razonable pueda programar algo asi.
    por lo que no creo que object-c o lenguajes similares puedan con esto.
    Seria un entorno como la maquina virtual de java,mas un enfoque de programacion funcional.
    Lo bueno Google tiene MapReduce.
    por ejemplo:

    for(int i =0 ;i menor n.length;i++)
    n[i]=funcion(n[i]);

    Es una estructura que no se puede ejecutar en varios procesos.
    Se necesita en cada iteracion hacer un incremento y una comparacion,esto de manera secuencial.

    Por otra parte:

    Map(funcion) datos

    Solo se indica que para todos los elementos de datos se aplica una funcion independientemente del orden en se aplica.
    Esto si permitiria poder partir y enviar los datos a otros dispositivos.
    Podria usarse un protocolo de comunicacion parecido a bittorrent para no saturar la red.
    En tu ejemplo seria el ipad corta la imagen y manda la orden a cada dispositivo y que se tiene que hacer y si se usa CPU o GPU.
    los dispositivos toman procesan la informacion.
    la envian y el ipad la reconstruye.
    Pero todavia necesitamos una revolucion en la ingenieria de software.
    Aunque en cuestion de hardware ,evoluciona como siempre ,dejando al software como obsoleto.

    PD: disculpa el doble post parece que tu parser en los comentarios los corta si se identifica un simbolo de menor o mayor.

    • Hugo,

      Jini y JavaSpaces solucionan estos problemas de una manera súper sencilla y elegante. Después que entiendes el concepto detrás de estas tecnologías te preguntará por qué todo no funciona de esa manera hoy día... :)

  • no me parece que no encontremos tales innovaciones en el mercado porque no se le haya ocurrido a nadie O porque no contemos con la tecnología para aplicarlo, el tema es que se retiene toda nueva tecnología para explotar y maximizar la ganancia que se puede alcanzar con lo que ya esta en el mercado. Cuando se agote y empiece a descender el consumo de lo ya instalado en el mercado sera el momento de sacar algo nuevo... sino para que? Con el esfuerzo que conlleva la innovación, hay que explotar todo al máximo de ganancia.

    • Daniel,

      No estoy de acuerdo con eso que dices, pues de ser así no existiría la competencia en los mercados.

      Algo como lo que sugiero le podría dar una gran ventaja competitiva a quien lo haga primero de manera efectiva, por lo que no tiene sentido decir que una empresa X, aun teniendo los medios de traerlo al mercado, no lo hará. Eso solo ocurre con monopolios herméticos...

      • La competencia existe... generalmente... pero saben muy bien hasta qué punto llevarla.

        Muchísimas veces las empresas hacen convenios. Muchas otras veces simplemente tienen mucho cuidado de no presionar demasiado a la competencia.

        Un ejemplo muy claro: Estaban todos vendiendo netbooks entre 150€ y 250€ (licencia de windows incluida). Viene Apple y saca un netbook sin teclado por 500€. ¿Qué hace Samsung? Saca un tablet con pantalla mucho más chica, sin windows, pero no lo vende por 150 ni 250: pone un precio similar al del iPad.

        Así funcionan las empresas: si no hay competencia venden lo más caro posible. Si hay que competir, se vende al mismo precio que el competidor y se compite con publicidad, o con convenios de exclusividad con los vendedores. Por ejemplo no hace mucho se multó a una gran cadena europea que entre otras cosas vende computadoras, por tener un convenio para vender exclusivamente PCs y laptops con procesador Intel.

        Uno dirá "qué bien, ahora sí podremos elegir". Pues no. Ya ha pasado bastante tiempo y sigue habiendo exclusivamente equipos Intel. Se habrán limitado a pagar la multa y a seguir haciendo lo mismo.

        Existen muchos métodos para competir pero sin bajar precios ni "quemar" las novedades rápidamente.

      • hay muchísimos ejemplos de lo que digo, me sorprende que no quieras abrir los ojos, empezando por la medicina que para mi es lo mas importante que podemos adquirir. Por que si se busca la máxima ganancia en algo tan importante, con las implicaciones morales y éticas que tiene brindar salud a los demás, no lo harían con chucherías electrónicas?

        • Daniel cuando mencionaste medicina me llego a la mente que todos los años veo mas de 1 noticias de descubrimiento de algun factor que cura el VIH Sida, pero nunca he visto que implementen nada de eso, sino que siguen apareciendo noticias del mismo caso de que alguien "accidentalmente" curo el sida.

  • Este tipo de procesamiento distribuido existe hace tiempo pero se utiliza muy poco porque en comparación con los tiempos de procesador, las comunicaciones (incluso utilizando varios cables de 1Gbit) son muy lentas. Sobre todo cuando no sólo hay que transferir datos a procesar sino el programa mismo que lo procesará y a demás el acceso a los datos guardados se tiene que hacer en remoto.

    En Linux, por ejemplo, hace ya más de 10 años yo estuve probando Mosix. Un agregado al kernel que le permite migrar procesos de forma automática y transparente ente los diferenes equipos que conforman la red. Su funcionamiento era muy sencillo y a la vez poderoso: cuando un proceso necesitaba mucha CPU y había disponible en otro equipo de la red, automáticamente el proceso se suspendía, se copiaba por la red, y se reanudaba en el otro lado. La migración se podía forzar manualmente o se realizaba en función de parámetros preseleccionados.

    Desventaja: que con los parámetros supuestamente óptimos, realmente muy pocos procesos se migraban. ¿Por qué? Porque era necesario que el proceso requiriera mucha CPU y al mismo tiempo poco acceso a dispositivos de su host de origen (pantalla, red, disco, puertos) ¿Por qué? Porque todo esto tiene que hacerse por la conexión de datos, e incluso siendo rápida, todo el proceso que requiere empaquetar la información, transmitirla, y desempaquetarla en el otro lado introduce un retardo considerable.

    Con considerable me refiero a que incluso ahora con varios núcleos de varios Gigahertz, sentimos que los equipos reaccionan "lento" o "a los saltos", imagina agregar a eso el overhead de tener que transmitirse por el medio que sea.

    La solución? Programas específicos destinados al procesamiento distribuido. Las "granjas" de servidores normalmente tienen una copia del programa ya ejecutándose en cada nodo. Pero sólo es válido para un uso muy específico.

    • anv,

      En el artículo mencioné eso que dices, de que esto existía desde hace años (y no solo desde hace 10 años en Linux, sino que existe desde los días de time-sharing en los 1960s).

      El problema de lo que mencionas es lo siguiente.

      1. Es Linux, y eso dejó ese tipo de tecnología en manos de personas extremadamente técnicas. Mosix ya lo he visto un par de veces y requiere de casi un doctorado en ingeniería espacial para que alguien lo entienda y configure de forma más o menos óptima. Simplemente no está diseñado para el usuario o técnico común, y por ende nunca fue (ni será por el momento) algo que iba a ser exitoso a gran escala. Su nicho es en super-computadoras e instituciones académicas de investigación.

      2. Varios de los temas técnicos a los cuales te refieres son problemas debido a que arquitecturas como Mosix tratan de ser inteligentes por sí mismas. Soluciones como GCD y Jini hacen algo mucho mejor: Dejan de asumir cosas, ponen ciertas reglas que los programadores deben seguir implícitamente, y para los que deseen les da control explícito sobre como distribuir los procesos, y eso hace una *gran* diferencia.

      3. Debemos entender que no todos los programas son paralelizables, o fácilmente paralelizables con tecnologías actuales (por eso dar siempre ejemplos de Photoshop, Autocad, Maya 3D, video-juegos, etc, que son programas óptimos para ser paralelizables), sin embargo, conforme la Ley de Moore continúe su marcha, mover un proceso local a uno externo será una operación poco cara en términos de recursos, debido a la baja latencia y alto ancho de banda disponible, lo que hará factible que incluso programas "normales" obtengan ventajas de computación distribuída.

      4. Al final del día sin embargo (y valga la redundancia de repetir lo mismo), el problema principal de adopción de estas tecnologías es de acceso: Si se hace muy difícil, nadie la utilizará (como sucede con Mosix), por eso deposito mi confianza en empresas no-tradicionales como Apple y Google para que propongan algo muchísimo más accesible y transparente al usuario común.

      • Realmente a mi no me pareció complicado configurar Mosix. Las configuraciones que trae por defecto funcionaron muy bien y cuando las miré me parecieron muy razonables.

        Se trata simplemente de agregar el parche al kernel (cosa que obviamente requiere algunos conocimientos en ese tema) y después poner una tabla con las IPs de los equipos que compondrán el grupo.

        La ventaja de Mosix respect a otros sistemas de cluster es que no requiere que los programas sean compilados especialmente para usarlo, y que tampoco requiere que haya un programa especial corriendo en los otros nodos como pasa con los sistmas de renderizado por ejemplo. Sin embargo, en sistemas que requieren programas específicos corriendo en los nodos tenemos una ventaja: es independiente de la plataforma de hardware e incluso del sistema operativo.

  • Excelente artículo Elías. Cada día me impresionan más tus dotes videntes...

    Por otro lado, este último comentario anterior al mío (http://www.eliax.com/index.cfm?post_id=8624#c798504) me hace dudar de que ahora se pueda implementar este servicio de manera útil para el usuario final. Si no es para Photoshop o Final Cut, no sé qué tipo de programas pueden utilizar esta tecnología.

    Sigue así!

  • Muy interesante esta tecnología. Aunque creo que esto estaría en el medio de los profesionales (menos de lo que necesito) y los consumidores (mas de lo que necesito).

    Por un lado los profesionales que se pudieran beneficiar de esto ya usan "render farms", u otras tecnologías, para procesar la inmensidad de cargas que necesitan para sus trabajos 3D, edición de películas, etc. Agregar esta tecnología no se beneficiarían mucho porque prácticamente ya la tecnología la tienen. A menos que esta tecnología sea mas barata, mas fácil de implementar y mucho mas potente lo que pueden conseguir actualmente.

    Por el otro lado no todos los consumidores sacarían el beneficio que esta tecnología les pudiera dar. Actualmente la mayoría de los consumidores no le sacan el 100% a sus dual y quad cores. Si de 10 consumidores normales, uno de ellos utiliza programas como photoshop, 3dmax, etc, no creo que valga la pena sacar esta tecnología solo para esa persona.

    Pero hay que ver como se desarrollan las cosas. Quizás esta tecnología sea tan revolucionaria e importante como lo fue el ipad para las tablets. Nadie sabe si Apple sacando esta tecnología esta dando otro primer golpe revolucionario.

    • Juan C,

      El problema de estos Render Farms es que en muchos casos son complicadas configurarlas, y como dije en el artículo, específicas a una sola función.

      El profesional promedio utiliza al menos 4 o 5 diferentes tipos de herramientas, y casi siempre lo que ocurre es que solo una o dos de estas ofrece funciones de computación distribuída, y en muchos casos con software adicional que se debe obtener.

      Con lo que propongo, un solo sistema le daría servicio de computación distribuída a todo software que lo necesite, y lo mejor de todo, con casi cero configuración, y eso sí que es una gran ventaja.

      En cuanto al usuario común, cosas como juegos en 3D con Raytracing en tiempo real, manipulación de videos de HD (y les aseguro que en los próximos 3 a 5 años ya estaremos hablando todos de video 4K en consumidores), así como una nueva generación de aplicaciones que necesiten de mucho poder crudo (como por ejemplo, sistemas al estilo Kinect), serán todas posibles gracias a esto que contemplo.

  • Yo creo k la cosa va mas por el camino de la computacion remota en nube. Es decir pantalla o tablet LTE - GRANJA GOOGLE - y respuesta. Es un sistema mucho mas sencillo y controlable por las empresas software como MSoft Apple Google. Estos no kieren fabricar y vender harware, kieren k uses su hardware y la gente esta mas por la labor de k se gestione todo en la nube k tener k sincronizar mil aparatos supercaros con sus contraseñas y usuarios. De aki a 5-10 años la capacidad de proceso sera practicamente infinita en la nube. Lo k marke la potencia de un sistema sera el contrato k tengas kon la compañia telefonica.

    • Anónimo,

      Aunque existen puntos compartidos, son en realidad dos cosas distintas y ambas coexistirán. La primera es Computación en la Nube (y ya he escrito varios artículos en eliax al respecto), y la otra es esta, Computación Distribuída (en lo que llamo "versión para consumidores").

      Al final tendremos una mezcla de todo esto, y será toda transparente para el usuario final, una mezcla de computación y datos remotos (en particular para el almacenamiento a largo plazo y cosas importantes) y de computación local distribuída (para cosas que requieran de mucha potencia).

  • ¿Esto es Grid?

  • Y que tal si una empresa como Google aprovecha toda esa infraestructura y convierte a Android en una especie de terminal bruta (no tan bruta), aprovechando el acelerado aumento de ancho de banda de internet en dispositivos móviles?

    O sea, en vez de solo usar el poder de procesamiento de dispositivos cercanos, también ofrecerlo directamente desde sus propios servidores.

    Todo esto me recuerda mucho las clases sobre Sistemas Operativos distribuidos, donde para entonces quien se llevaba toda la atencion era Amoeba, muy recomendable para este concepto.


    Saludos,

  • Bueno, con eso se me acabarian las excusas para seguir utilizando una PC de escritorio o una laptop "pesada" (procesamiento, memoria, recursos, bla bla bla bla).

    Cuando esto salga me veran delante en la fila para comprarme mi ipad/android tablet/dispositivo X que soporte esta tecnologia.

  • por que insisten en un photoshop para el ipad???

    soy usuario del photoshop. por que soy fotografo profesional (el 100% de mis ingresos vienen de la footgrafia) y uso photoshop al menos 4 horas al dia, tiempo que disminuyo al usar lightroom.

    pero por que insisten en un programa de y para diseno que lo corra un dispositivo tan pequeno.

    es incomdo trabajar una foto, imagen, ilustracion en una pantalla de 10". tengo una imac 21.5 y quiero una de 27 y es todo por el tamano para mas comodidad.

    la idea de este articulo es muy interesante, pero el ejemplo es muy pobre.

    • jorgen,

      No se si sabías que Apple ofrece un adaptador que conecta un iPad a un monitor externo de cualquier tamaño, con resolución de 1920x1080 pixeles.

      Además existe la opción del teclado Bluetooth si es necesario.

      ¿Qué modelo utilizará Adobe? No sabemos aun, pero una combinación de monitor externo de 24" o 32", con la superficie multi-táctil del iPad, y opcionalmente teclados externos, hace para una potente combinación (y lo mejor de todo, es que te puedes llevar el iPad contigo cómodamente a cualquier lugar con mucho menos peso que una laptop tradicional).

      • para ser franco no pense en el adaptador...

        sobre al idea de pantalla multitactil, existe el pen tablet que es lo mejor y creeme que la version mas sencilla (unos 80 dollares) es completamente precisa y funciona de mil maravillas. tanto asi que hay gente que una vez se acostumbra a ese sistema no vuelve a ponerle la mano a un mouse o trackpack.

        que salga un photoshop para ipad sera algo interesante, pero no creo que sea un version tan terminada o pesada como lo conocemos.

  • eso ya existe desde hace algun tiempo solo que no se ha explotado...creo que el ipad tiene una aplicacion de splashtop donde se puede correr windows (incluido juegos y videos flash) dentro del ipad...no he investigado mucho pero tengo entendido que se conecta a la pc de escritorio que tengamos por wifi y asi interactua...

    tambien estoy leyendo un libro de programacion distribuida con ruby y realmente es algo interesante..aunque mas interesante es hacerlo por wifi como dices

    • Angel,

      A lo que te refieres no tiene nada que ver con esto. No es más que una aplicación al estilo VNC o RDP que simplemente despliega de forma remota el contenido de la pantalla de tu PC.

  • Elias como dijistes mas arriba, es basicamente el concepto de Grid Computing, pero al final de cuentas no es una grid. La razon es simple seria orientado a una plataforma (apple o quien lo saque primero) cosa que lo quita de la lista de Ian Foster para reconocer a una grid.

    Siguiendo con el tema, la distribucion que mencionas, no es tan facil, aun teniendo leguajes que ayudan a programar con esta orientacion.

    Como dijistes en el articulo original, "que previamente hayas autorizado", seamos sinceros si la mayoria de personas terminan con cuentas tomadas por hacker por el simple echo de mala seguridad en una clave te imaginaras como sera para la seguridad de una red de trabajo, y es algo delicado.

    Lo otro es el consumo de ancho de banda, imagina cuantas personas lo tendran por ser la moda y lo usaran para cosas inutiles o algo por el estilo, ademas de que el envio de data empezaria a crea cuellos de botellas, he incluso el hecho de que tienen solo cierta escalabilidad, debido a que la linea que separa el (n° de nodos)/tiempos es delgada ya que llega el punto en que agregar un nuevo dispositivo solo aumentara los tiempos de respuesta.

    En fin, es una tecnologia muy tentadora pero a la cual hay que hacercarse con pie de plomo porque aun esta en desarrollo y faltan ya unos cuanto años para que sea usable a ese nivel.

    PD: mi proyecto de grado fue basado en tecnologia grid y distribuida tal vez por eso puedo ver las cosas desde otra perspectiva mas tecnica, sin decir imposible sino que hay que desarrollarla y bastante.

  • Interesante artículo, yo he pensado precisamente estos días en hacer esto de otra manera que habrá pensado mucha gente supongo. Llevar encima una pantalla con lo justo y necesario para tener internet y poder usar desde esa pantalla un PC u otro dispositivo que esté en casa. Ya que nos hemos gastado el dinero... habrá que sacarle partido, jeje.

    Un saludo!!

  • Tengo un estudio de animacion 3d y demas tecnologias 3d, utilizo 3dsmax en varias maquinas a la vez para renderizar con el renderizador vray, pudiendo distribuir cada cuadro (o render) de una animacion en varias maquinas, esto lo hace por red desarmando el cuadro a renderizar en una cuadricula de cuadros mas pequeños y usando varias maquinas para renderear un solo cuadro.

    Es muy util, pero tiene varias contras, como el seteo de la escena a renderizar q tiene que ser igual y con las mismas rutas en cada pc, y solo permite usar varias pcs para renderizar uno o varios cuadros, no para usar el programa en si.

    Espero con ansias esta tecnologia mejore para poder usar el poder de varios cpus a la vez.

    Saludos!!

Añadir Comentario

tu nombre
tu email
(opcional)
web personal
(opcional)
en respuesta a...
comentario de caracteres máximo
3 + 9 = requerido (control anti-SPAM)
 

"wow muy interesante ahí me tienes en la oficina haciendo el tonto con las manos jeje gracias"

por "Danx" en jun 21, 2012


en camino a la singularidad...

©2005-2014 josé c. elías
todos los derechos reservados
como compartir los artículos de eliax