Avances en computación cuántica

Hace unos años (10 más o menos) me dio por leerme todo lo que encontraba relacionado con computación cuántica. Desde la primera lección: la puerta lógica básica (raíz cuadrada de NOT), me fascinó y durante meses casi no leía otra cosa. Hace poco seguí con entusiasmo (y muchísimo escepticismo) el anuncio de una empresa británica que (falsamente) anunció disponer de un ordenador cuántico comercial.

Hoy he visto una noticia que me ha hecho revivir un poco de aquella época. ¡Nos vamos acercando a la computación cuántica real! ¡Y a temperatura ambiente! ¡Fascinante! Aunque sólo sea por curiosidad no os perdáis el link que os sugiero hoy.

Microsoft Surface

Vale que no sea un acérrimo de Microsoft pero cuando hace algo bien también se lo reconozco. Anoche fue uno de esos momentos triunfales cuando Microsoft dio un giro al mercado de los ordenadores con algo que, si bien ya había presentado hace tiempo, se esperaba tardase mucho más en llegar: Microsoft Surface Computing. El ordenador multitáctil, sin teclado, ratón ni cables innecesarios, aunque con una barriga tremenda :-P

El invento es básicamente un iPhone a lo bestia, con pantalla de 30 pulgadas y sin teléfono móvil, con un coste de unos 10.000$ y pensado inicialmente para hoteles, restaurantes, centros de reuniones, etc.

Sin duda el hecho de presentar anoche esto, un día antes de careo público entre Steve Jobs y Bill Gates en la televisión, forma parte de una estrategia muy bien planteada por Microsoft. Ahora sólo falta ver cómo se da la entrevista y cómo salen ambos. ¿Desvelará Steve Jobs algo nuevo sobre Leopard o sobre el iPhone (por mencionar un producto hardware) para contrarrestar la espectación que haya levantado la MS Surface? (No lo creo, pero en un debate de esta índole puede suceder cualquier cosa).

Es más que probable que esta semana The Joy of Tech nos haga reir mucho.

La Grid de la Unión Europea

Veo en barrapunto una noticia bastante interesante (y que ha desaparecido relativamente rápido de la portada): la Unión Europea ha creado un proyecto para la implantación de Grids con software libre. Lo más interesante es que al estar orientada a su uso con XtreemOS (el Sistema Operativo libre subvencionado por la UE), lo más probable es que cualquier avance en este campo se vea inmediatamente portado a MacOS X. Después de todo, XtreemOS es una variante de Linux y la inmensa mayoría de software abierto para linux funciona directamente (tras compilarlo, claro) en MacOS X... y si no siempre nos quedará la virtualización :-P

No me enrollo porque la noticia viene bien explicada y con enlaces detallados. Ya sabéis dónde poner otro feed ;-)

OpenGL 3.0

Después de muchos años anclados, los responsables de OpenGL han decidido dar otro gran salto, hacer limpieza en miles de lineas de código que llevaban más de una década y media sin ser revisadas y provocar la evolución de OpenGL hacia otra versión más.

La noticia se puede leer aquí y, como veréis, esta nueva versión que saldrá previsiblemente en octubre de este año (2007) promete bastante. Ahora vienen las cábalas y especulaciones. ¿Quién se atreve a hacer una porra sobre la relación entre OpenGL 3 y MacOS X Leopard? Venga, el tema es jugoso. Apple había anunciado grandes cambios en su implementación de OpenGL. Las fechas coinciden: ambos saldrán al público en octubre. OpenGL3 funcionará sobre tarjetas compatibles con DirectX 10. ¿Será esta nueva implementación un intento de ser una DirectX10-killer? ¿Se le darán a los creadores de juegos, por fin, las herramientas necesarias para que se decidan a hacer juegos de calidad en Mac? --no nos engañemos, salvo muy raras excepciones la calidad gráfica de los juegos para Mac, basados en OpenGL, es inferior a la de los juegos para Windows, basados en DirectX, y conste que aborrezco DirectX--

Ya tenemos otro motivo para esperar impacientes a Octubre. ¿Qué nos deparará (en detalle) la nueva versión de OpenGL? ¿Cómo influirá en el mercado?

P.D. Otra vez más queda patente la mala fortuna de Apple al elegir la Intel GMA 950, incapaz siquiera de soportar OpenGL 2.x, como tarjeta gráfica en los MacBook. ¿Hasta cuando Apple seguirá integrando esta basura de tarjeta gráfica?

Programar es cosa de niños

Ya sé que últimamente no escribo demasiado, pero... Aquí os dejo hoy un link que convierte la complicada tarea de la programar en un juego de niños.

En el MIT han desarrollado un entorno de programación para niños inspirado en la idea de "juegos tipo Lego". La idea es tan sencilla como unir bloques de colores para desarrollar programas, sin problemas de sintaxis ni de ideas tremendamente abstractas.

Lo mejor es que el software es completamente gratuito, se encuentra disponible para MacOS X y Windows (prometen una versión Linux dentro de poco), dispone de una magnífica documentación (incluso con video-tutoriales), admite una tarjeta con sesores y da bastante juego. Además, como está en inglés facilita que los más pequeños se vayan haciendo al idioma. ¡Todo son ventajas! ;-)

No perdáis más tiempo y visitad la web: SCRATCH

Incomunicación digital

Me parece sorprendente cómo los programas de comunicaciones pueden suponer un grave problema de comunicación. Lo entiendo, pero me sorprende que nadie haga nada ¿para qué están los comités estandarizadores?

Toda la historia viene por una sencilla razón: A la espera de que alguien se decida a poner un comentario sobre el problema planteado con Xgrids (aunque sólo sea para pedirme que ponga la solución de una vez por todas) he estado "jugando" con las granjas de render (tanto clusters como grids) que tenemos en mi trabajo buscando una forma de unificar recursos y optimizar sistemas integrándolos en un macrosistema. Casi todo es Linux o Mac, por lo que no tengo problemas de software en ese sentido, peeeeeerooo.... cada aplicación usa su propio protocolo de comunicaciones, políticas de seguridad y "scheduling", etc. Así que la pregunta que me surgió directamente fue: ¿se puede unificar de alguna manera? Pues bien, aunque parezca mentira, la capacidad de unificación de aplicaciones (propietarias, todo hay que decirlo) es casi nula.

Sin embargo, existen varias herramientas útiles que pueden ayudar con la gestión de un cluster-grid tan heterogéneo y poco manipulable como éste.

• Por un lado es importante conocer el estado de cada máquina, por lo que habrá que utilizar algún software para "control de clusters". En mi caso, no conozco ninguno comercial u Open Source que me sirva porque todos requieren de la inclusión de algún pequeño complemento al kernel... y las aplicaciones (propietarias) que utilizo están certificadas sólo para las máquinas tal cual las entregan. Cualquier modificación al kernel es un grave problema (a nivel de licencias, soporte, etc). Aquí surge la primera complicación, aunque gracias a Unix no lo es tanto. Como he dicho todas las máquinas son idealmente tipo Unix (y la que no sea... ¡lo será!, aunque sea con un CygWin), por lo que disponemos de herramientas muy útiles y más o menos estándares : uptime, uname, w, netstat, ps, date, free (en Linux) o vmstat (en Mac), df, top (con sus variantes Linux/Mac), renice, kill, etc, etc, etc. De modo que es fácil hacer un shell script (o muchos muy sencillos que se puedan corresponder, por ejemplo, con "comandos") que valga para casi cualquier plataforma y que, en función de unos parámetros dados, ofrezca información y/o manipule procesos a su antojo.
• Manejar toda esta información en modo texto es divertido (al principio), pero acaba siendo engorroso, por lo que se puede hacer uso de aplicaciones tan maravillosas como: MRTG (Multi Router Trafic Grapher) y RRDtool (Round Robin Database Tool).
• ¿Qué es mejor para controlar una red que la propia red? En un servidor con Apache se puede integrar fácilmente la gestión de todos los scripts, representaciones gráficas, etc. HTML, PHP, Perl y otras herramientas se integrarán perfectamente en Apache para facilitar la gestión de nuestro supercomputador con todas las herramientas antes mencionadas más las que podamos crear.
• Un vistazo rápido en Google te permitirá encontrar muchísimos paquetes y programas dedicados a la creación y/o gestión de clusters y grids (OpenMOSIX, OpenMOSIX View, Condor, C3, MC3, Oscar, VACM, Globus, OpenGrid..........). Como por las particularidades del software que utilizo no encuentro ninguna ideal, y ya puestos a picar código, ¿por qué no usar Xgrid? Usando Xgrid se pueden distribuir los shell scripts de control sin necesidad de tener que controlar cada máquina. MacOS X ofrece muchas herramientas para integrar todas las utilidades de las que hemos hablado: desde el servidor Apache configurado y listo, hasta los frameworks para programación directa, sin olvidar todos los extras propios de MacOS X (Automator, AppleScript, herramientas de sistema...)

Moraleja: ¿Os habéis dado cuenta cómo para hacer algo sencillo hay que "complicarse" la vida? ¿Para qué existen los comités estandarizadores? ¿Cuándo veremos que el IEEE o el ISO, por ejemplo, establecen un estándar de "Supercomputador distribuido de uso general" que permita a todos hacer uso de los recursos disponibles a lo largo de toda una red? Yo estaría encantado de que fuese Apple en lugar del ISO quien hiciese el movimiento, pero debería ser más universal que la subestimada e infrautilizada Xgrid. Todo esto tiene mucho que ver con las arquitecturas SOA (Service Oriented Architecture) que tan de moda están (y más que se van a poner), así que ¿por qué no aprovechamos y empezamos a aunar esfuerzos para hacer las cosas bien? ---Ya lo sé, es una pregunta retórica y tonta porque siempre habrá intereses creados que añadan confusión y problemas, pero ¿no estaría genial hacer las cosas bien desde el principio?---

Agentes XGrid autónomos (Ayuda)

Vale, como no os animáis y reconozco que no es fácil hacerlo todo a través de la terminal... "Acepto barco" y os permito soluciones usando XgridLite como primera solución. A ver si así os animáis a proponer una solución sencilla.

Grids, JAVA, Eclipse y tú

Antes de conocer MacOS X de cerca una de mis obsesiones era conseguir la máxima portabilidad de todos mis desarrollos. Por ello, Java era uno de mis candidatos favoritos a la hora de hacer cualquier programa.

Si te gustan la computación de alto rendimiento, las grids, Java y el maravilloso entorno de desarrollo Eclipse, probablemente te llame la atención el proyecto g-Eclipse.

g-Eclipse es un proyecto oficial de Eclipse Foundation para dar soporte a grids. Actualmente están llamando a la colaboración para intentar un soporte básico en su versión 0.5 antes de Junio de 2007. La fecha está próxima, pero aún sigue siendo posible.

¿Te animas? quizás podrías ayudar a que g-Eclipse fuese compatible directamente con Xgrid. Como base podrías ayudarte, por ejemplo, del proyecto Open-Source Xgrid agent for UNIX architectures.

Una Xgrid con Apple TVs

Leo en Appleweblog acerca de un tutorial para crear una Xgrid usando Apple TVs aprovechando que llevan MacOS X integrado.
No digo más...

Magnífico tutorial de Cocoa

Acabo de descubrirlo buscando otra cosa... pero es uno de los tutoriales más interesantes, completos, útiles y sencillos que he visto sobre Cocoa. Altamente recomendable para iniciarse incluso en conceptos relativamente avanzados.

Disfrutadlo. Merece la pena:

Bagelturf

Apuntes de I.S.

Ya tenemos los exámenes encima y, como siempre, a última hora aparecen la dudas, las prisas, y los problemas porque nuestros apuntes se nos quedan cortos (o al menos esa es la sensación que se tiene en el último momento).

Si sois de los que estáis como yo ("atacaos" por los exámenes) y, entre vuestras asignaturas se encuentra algo de ingeniería del software, os paso un link de la Universidad de Castilla La Mancha que tiene unos apuntes muy claros con ejercicios resueltos. Aunque, por desgracia, faltan algunas unidades.

Aquí va el link

Y aquí va otro más sencillo pero con algún que otro material de referencia sencillito

¡Quién me mandaría a mí meterme otra vez a estudiar si yo ya tenía mi título de ingeniero y estaba tan agustito sin exámenes!

Lamport

Sé que puede parecer poco original y pesado que ponga aquí algo que ya ha aparecido por activa y por pasiva por toda la blogosfera, pero a mi me parece importante y lo reflejo brevemente.

El otro día un amigo me avisó (gracias Amarok ;) de que Leslie Lamport (archiconocido gracias a LaTeX) venía a dar un par de charlas a Madrid. Me contó de qué iban y lo muy interesantes que resultaban los problemas que iba a plantear. Como están muy relacionados con la ingeniería del software y aquí hablo bastante de este tema... tocaba dejarlo reflejado.

Serán los próximos días 28 y 29 de mayo (2007) en Madrid. En barrapunto pusieron unos días después los detalles, por lo que no me repito más.

Aquí tenéis el link

Si váis dejadme en los comentarios o en el email vuestras impresiones, conclusiones y demás... yo, muy a mi pesar, dudo que pueda ir.

Xgrid FUSE

Leo en MacResearch que la semana pasada se presentó Xgrid FUSE (proyecto Open Source con licencia GPL), que ofrece una forma alternativa para aprovechar nuestra Xgrid para crear y compartir sistemas de ficheros por red y tenerlos accesibles desde Finder.

Sólo una reseña breve para picaros la curiosidad: FUSE viene de File-system in USEr-space. Cada vez tiene más importancia. En Google Code se puede conseguir una implementación para MacOS X bajo el nombre macfuse, y la semana pasada aparecía una interfaz gráfica para Mac bajo el nombre MacFusion.

Si le echáis un vistazo veréis que abre todo un abanico de posibilidades a aquellos que, como yo, tengan que trabajar en entornos muy heterogéneos o accediendo a sistemas muy distribuidos.

Personalmente creo que estando Google detrás, y siendo una herramienta tan flexible, no tardará en utilizarse muuuucho en los entornos IT.

Tutoriales sobre Cocoa Bindings

El diseño de software basado en Cocoa suele seguir el patrón de diseño MVC (Modelo, Vista, Controlador). Las vistas las proporciona Cocoa en forma de tablas, cuadros de texto, vistas gráficas, etc. El modelo es el modelo de datos subyacente en nuestra aplicación. Y el controlador que une las vistas con los modelos de datos puede ser de dos tipos: cógido "pegamento", que simplemente une ambos; o Cocoa Bindings, que sin apenas programar son capaces de unir ambas representaciones de datos.

Los Cocoa Bindings son un tema muy extenso, pero muy productivo e interesante. Así, pues hoy os dejo aquí un par de enlaces con buenos tutoriales que he encontrado por Internet.

Cocoa Bindings Examples and Hints
Introduction to Cocoa Bindings
Cocoa Bindings 2: not too frustrating, really
MacResearch (Tienen una serie de tutoriales muy buenos -hay que buscarlos- que empiezan desde la KVC y KVO)

P.D. El hecho de poner esto aquí no es totalmente aleatorio. Si os fijáis en la web de la WWDC'07 veréis que se le da bastante importancia en presentaciones y laboratorios... y hasta aquí puedo leer. Sólo digo que es un tema importante (ahora y en el futuro de Mac OS X). Estad atentos e id soltándoos con los bindings. Yo no esperaría a tener Leopard para empezar con ellos.

Agentes XGrid autónomos (Pista)

Bueno, aquí os dejo un par de pistas más sobre nuestro pequeño proyecto de Xgrid con MacOS X Tiger (Client).

Por un lado, si usáis 10.4.9 es posible que los muchos tutoriales que hay por internet no os sirvan. En algún momento --no sé cuándo-- entiendo que se ha hecho alguna modificación (?) que impide seguir los tutoriales de internet al pie de la letra. He hecho pruebas también con la beta de Leopard y, por lo menos, han mejorado ese insidioso mensajito de error que da xgrid en Tiger: "Unknown reason" por otro que sí da explicación a los problemas.

Por otro lado, si os fijáis en la ayuda (man xgrid y man xgridctl) os hace referencia a varios ficheros *-password que no son ficheros de texto, por lo que si pretendéis hacer pruebas con passwords, no intentéis escribirlos sin la ayuda de alguna herramienta.

También se hace referencia a otros dos llamados com.apple.xgrid.* que sí son ficheros de texto (XML para ser más exactos) y que guardan la configuración de la Xgrid. Simplemente llamaros la atención (puede pasar desapercibido en la documentación) a que los que hay en /etc/xgrid/controller y /etc/xgrid/agent NO son los que se utilizan para realizar la configuración. Son ejemplos comentados. Los ficheros de configuración reales van en /Library/Preferences.

¡A ver quién da con la solución antes que yo y la pone como comentario!

Agentes XGrid autónomos (Solución. Paso 1)

Para las soluciones os dejo instalar software, pero no sirve instalar un controlador como Xgrid Lite, eso es trampa. Aunque, claro, esa ya es una solución completa y sencilla ;)

Os voy a ir poniendo una solución paso a paso. Ya sé que es optimizable, pero pretendo que sea sencilla y didáctica. Después allá cada uno con su maestría optimizando o su vaguería instalando soluciones "prefabricadas". Así que ya sabéis: se aceptan correcciones y sugerencias en los comentarios.

Activar una XGrid de pruebas sin MacOS X Server

Lo primero que vamos a tener en cuenta es que vamos a crear la grid para muchos días de pruebas, por lo que haremos que el controlador se active automáticamente cuando se inicie el ordenador. Lo haremos con el comando:

# sudo xgridctl controller on

Usando el panel de "Preferencias de Sistema...", dentro de la opción Compartir vamos a activar el agente Xgrid con las siguientes opciones: "Usar el primer controlador disponible"; "Aceptar tareas: Siempre"; y "Método de de autenticación: ninguno". Vale, no son las mejores opciones en un entorno de trabajo real... pero estamos de pruebas. Si no hemos hecho nada "especial" vamos, el estado de nuestra miniXgrid será el siguiente:

# xgridctl status
822 ?? Ss 0:00.32 xgridagentd

El agente ya está funcionando. Nos falta el controlador. Podemos optar por la solución Microsoft (reiniciar) o por la UNIX (lanzar el demonio sin reiniciar). Vamos a por la segunda:

# xgridctl controller start
# xgridctl status
822 ?? Ss 0:00.46 xgridagentd
922 ?? Ss 0:00.04 xgridcontrollerd

Facil, ¿no? Ya tenemos un agente y un controlador funcionando. Nos falta configurar la Xgrid, pero eso queda para el siguiente paso... a ver si esta vez os adelantáis y lo escribís en los comentarios. Yo ya lo tengo escrito pero no lo publicaré hasta que me apetezca ;)

Agentes XGrid autónomos

Como decía hace un par de días, la tecnología XGrid es una de las grandes maravillas olvidadas e infrautilizadas de las plataformas Mac. Por eso, y porque me encanta el mundo de posibilidades que tiene, hoy es día de deberes y os propongo hoy un problemilla sencillo pero muy útil (ya veréis más adelante dónde quiero llegar...).

La propuesta:
Configurar una XGrid (sin MacOS X Server) con agentes XGrid "autónomos". Entendiendo por "agentes XGrid autónomos" que, en un momento dado, un agente XGrid pueda decidir de manera autónoma si realizar o no un determinado trabajo. Para empezar vamos a poner que el trabajo a realizar sea ejecutar un "shell script" y que la decisión de si hacer un trabajo o no se tome, por ejemplo, en base a la existencia o no de un fichero dentro del ordenador que hace de agente Xgrid.


¡Hala! Ahí queda el ejercicio propuesto... Si os atrevéis a realizarlo espero vuestros comentarios. Yo voy a "implementar" mi solución mientras hacéis vuestras propuestas (ya sé que soy un ingénuo y no váis a poner nada, pero de ilusión también se vive).

Me encanta Leopard ;-P

Sí, podría disimular pero es de mala educación mentir: esta entrada es para daros envidia a aquellos que aún no podéis saborear MacOS X Leopard. Como no puedo dar detalles de cómo funciona (por el NDA aceptado) sólo os diré dos palabras que sí puedo decir: ¡Me encanta!

La versión que tengo instalada (la última distribuida a desarrolladores: 9A410) aún tiene sus bugs y sus cosillas, pero incluso a falta de las tan polémicas "características secretas" ya es una gozada. Da igual que seas usuario, programador o administrador: te encantará.

¿Qué nos deparará la versión (supuestamente completa) que se entregará en la WWDC? No sé, no sé, pero yo ya tengo una partición preparadita para instalarla en cuanto caiga en mis manos ;)

Gestionar una XGrid sin MacOS X Server

Uno de los componentes más infravalorados de MacOS X es la Xgrid. Pocas personas son conscientes de la potencia real de semejante maravilla y, desde mi punto de vista, Apple tampoco hace demasiado para ayudar a mejorar la visión general de su producto. De hecho, fijaos en el programa de la WWDC de este año y veréis que ¡no hay una sola sesión sobre Xgrid!

Para aquellos que no sepan de qué estoy hablando podéis pensar que la Grid es la evolución de la Web. En la web se comparten datos entre máquinas; en una grid además se comparten recursos y potencia de cálculo para crear supercomputadores más potentes que la suma de las partes. ¡Y MacOS X es el único sistema operativo con soporte nativo desde hace AÑOS para grid!

Simplificar la creación y manejo de grids a dos aplicaciones con una sencilla interfaz gráfica (o a sus equivalentes en la línea de comandos), y a una API con unas pocas clases es, sin ningún lugar a dudas, una proeza. Toda la gestión de procesos, seguridad, etc, quedan simplificadas al máximo sin perder su esencia. A un científico/programador/técnico que quiera usar una grid no le importa cómo implementar la seguridad, por ejemplo, sólo le interesa que el sistema funcione y haga lo que se supone debe hacer lo antes posible y sin complicaciones... y eso Xgrid lo consigue muy bien, al menos en las pruebas que he hecho.

Una tontería que me dejó perplejo es que, leyendo únicamente la documentación del ADC de Apple, llegué a pensar -¡ingenuo de mí!- que para usar Xgrid era necesario tener al menos un MacOS X Server. La sorpresa me llegó al buscar links en la entrada correspondiente de la wikipedia: ¡NO es necesario MacOS X Server para usar Xgrid! ¡Sólo hay que hacer uso de los mal documentados comandos xgrid y xgridctl! (Bueno, al menos, la entrada de man para ambos comandos está bastante bien :)

A pesar de que Xgrid no se encuentre especialmente bien documentado dentro de los puntos "oficiales" de información de Apple, se trata de una tecnología tan interesante que hay otros sitios web dedicados a profundizar en ella. A continuación os pongo el par más interesante... aunque si simplemente partís de Google o de la Wikipedia podréis llegar a hacer un viaje fascinante:

• XGridWiki
• Simple. 

Sin duda podréis encontrar otros links muy interesantes (dejadlos como comentarios si queréis), pero creo que en éstos (junto a los "oficiales" de Apple) se concentra la información más interesante. ¡Disfrutad paralelizando!