.NET o no .NET, esa es la cuestión : MAC, Apple

Compilar wxWidgets en mac

Rafael Ontivero — Wed, 04 Jul 2012 11:24:00 GMT

Decía ayer que wxWidgets podría ser una buena herramienta para desarrollar aplicaciones multiplataforma a partir de un único código fuente, quizás incluso mejor que QT ya que utiliza los controles nativos allí donde los haya.

WxWidgets es muy similar a MFC en cuanto a jerarquía de clases y a “concepto”, y de hecho el paso de una tecnología a la otra es mucho menos traumático que el paso, por ejemplo a QT. De wxWidgets se han dicho muchas cosas negativas. Que si no soporta excepciones, que si ocupa mucho tamaño, que si es muy complicada, y en general que tiene una arquitectura obsoleta.

Personalmente creo que ninguna de esas cosas es cierta, no al menos en el sentido en que se dice. Ciertamente su jerarquía de clases no tiene excepciones, pero nadie impide que las uses en tu código. Otra ventaja es que su API es genérica para todas las plataformas, y que tiene un montón de clases de soporte que nos evitan la compilación condicional.

Por ejemplo, tenemos soporte directo para impresión, depuración, bases de datos, modelo documento/vista, arrastrar y soltar, ficheros de configuración, sincronización y threads, protocolos de red, OpenGL y hasta para la creación de diagramas…

Aparte existen varias herramientas de soporte, algunas de ellas realmente buenas aunque sean de pago. El problema es que sólo están disponibles para Windows, y tendremos que tener la clásica solución de una máquina virtual bajo OS X.

La única pega para desarrollar bajo MAC es que, hasta hace bien poco, el Framework estaba basado en Carbon (ya sabéis, el API de C de OS X que ya está obsoleto), pero la última versión, la 2.9.3 soporta compilar sobre Cocoa y 64 bits sin problema alguno.

Otra pega es que tenemos que compilarla nosotros, ya que sólo se distribuye en código fuente. Para Windows ya lo expliqué hace tiempo. De todos modos no es muy difícil una vez que has atinado con las opciones adecuadas.

***

Lo primero es bajarnos el tema, de aquí. Os recomiendo que elijáis la opcion de “With Unix line endings (for Unix and OS X). Yo lo he descomprimido en mi HOME, a partir de una carpeta que he llamado “wxWidgets”. Debemos entrar en ella, y una vez ahí, como en todo proyecto tipo Unix, configuramos la compilación:

./configure --with-cocoa --prefix=$HOME/wx --enable-stl --disable-shared --with-macosx-version-min=10.7 --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/

Una vez hayamos terminado, un simple make seguido de otro make install nos dejará el sistema listo y en producción.

***

Fijaos en las opciones que he elegido. “—With-cocoa” hace que se compile con el API de OS X actual, y con la de “—prefix” le estamos diciendo que use nuestro HOME para no enmarranar las carpetas del sistema operativo. Esto es muy útil porque si luego queremos desinstalarlo tendremos problemas.

Con “—disable-shared” le estamos diciendo que queremos las bibliotecas estáticas y no las dinámicas. Si vamos a poner alguna aplicación en la Tienda, es la mejor opción, ya que nuestro programa será un único ejecutable.

Y finalmente las dos últimas opciones. Yo he puesto Lion (10.7), pero vosotros podéis poner Snow Leopard (10.6). Si os fijáis, la ruta de los SDK ha cambiado en las últimas versiones de Xcode. Recordadlo para otras ocasiones.

Se me olvidaba comentar que necesitamos instalar las “Command Line Tools” para poder compilar cualquier cosa desde la consola de comandos. Abrimos Xcode, nos vamos a las Opciones (Command + ;) y las seleccionamos de allí.

Multiplataforma de la buena (mismo código fuente)

Rafael Ontivero — Tue, 03 Jul 2012 18:32:00 GMT

Antes de empezar, y de que me deis caña de la buena, quiero decir que todo esto son elucubraciones personales mías y que lo más seguro nadie esté de acuerdo conmigo. Dicho esto, vamos al meollo del asunto.

Ya sabéis que me he ido distanciando un poco de la plataforma Windows a la vez que me he acercado a la de Apple sin realizar el cambio total. De Linux no quiero hablar, porque cada vez que tengo que hacer algo con él, sudo tinta china y al final, tras muchos cabezazos, suelo terminar desistiendo.

Lo último fue compilar el SDK de lector del libros electrónicos Boox i62HD. Tras instalar una Debian 6 x86 virtual en vmWare Fusion (el Workstation del MAC) por segunda vez, ya que la primera falló estrepitosamente porque el instalador sí que reconoció el discos duro SCSI pero luego el kernel instalado no, fui incapaz de compilarlo.

Primero me encontré con una serie de paquetes que no estaban presentes y que el comprobador del SDK no avisó que faltaban, lo que te obliga a recorrer la cadena de errores para descubrir que te falta esto o aquello.

Lo último, y que todavía está sin solucionar, es que falta una dependencia en un fichero de proyecto, en concreto incluir “-l z” en el lugar correcto, que es enlazar con la biblioteca zlib. En mi caso el problema no es saber qué falta, sino dónde añadirlo. Tras varios intentos infructuosos y muchas páginas de internet leídas, no conseguí solucionarlo.

Había un bug similar si instalabas el SDK en un linux x64, pero el mío era x86, y el parche existente intentaba modificar ficheros que no existen (al menos en mi instalación).

Pues bien, ni me han hecho ni *** caso ni tampoco lo han solucionado, lo que me lleva a preguntarme cómo cojones están programando. Y menos mal que usé una Debian, que es la misma distribución que usan los que han creado el SDK, que si llego a instalarme otra cosa…

Esto es un ejemplo de la desidia reinante en Linux. Lo dije en un foro hace tiempo. Los programadores de linux me parecen muy poco profesionales, tendentes a montar cualquier cosa que les parezca c00l y luego, cuando viene la hora de la verdad y demostrar que se es un programador con dos cojones, pasan del tema porque eso de solucionar bugs ya no es tan fascinante como lo otro, y encima solventar cualquier cosa son un montón de horas en las que no estamos subiendo nuestra supuesta caché c00l en la comunidad.

Aparte de deleznable, me parece una práctica muy poco seria y que sigue dejando a Linux como lo que es: o bien un juguete para niños falsamente interesantes, o bien algo destinado a servidores de bajo coste, y si no contadme cómo es el único sistema operativo que ha reventado con el segundo extra añadido hace unos días.

Por lo tanto, para mi el desarrollo en Linux queda completamente descartado a corto y largo plazo, por lo menos hasta que se pongan un cohete en el culo, cosa que dudo mucho que ocurra jamás (y espero equivocarme).

***

Luego vino el tema del swtiching. Lo cierto es que tras el entusiasmo inicial, la cosa deja mucho que desear en cuanto a usabilidad y, sí, rendimiento. Ya lo he ido comentando por este blog con anterioridad. OS X Lion y Mountain Lion, si los comparamos con XP, son la rehostia, pero comparados con Windows 7 dejan mucho, pero mucho que desear. La usabilidad es pésima, aparte de ciertos problemas de ergonomía a los que al final uno termina acostumbrándose.

También es cierto que cuando le coges el tranquillo ya no hay vuelta atrás, más que nada por la integración de todos los elementos, más todavía si tienes un iPad o un iPhone. Puedes conseguir casi lo mismo en Windows, pero no de forma tan integrada ni coherente.

Respecto al rendimiento, diré que por fin tengo un MAC que funciona como yo quiero, tras gastarme más de 300 euros en añadirle un segundo disco SSD al iMac de 27”. Es decir, en este momento mi máquina principal es un iMac de mediados del 2011 con un i7 a 3.4 GHz, un disco SSD de 256GB como disco de sistema para el OS X y uno de 1TB como secundario para datos. En este momento el disco FireWire de 2TB que usaba como secundario lo tengo como copia de Time Machine y, aparte de que arranca en 8 segundos (antes tardaba más de dos minutos y el disco seguía rascando hasta casi los diez), sólo veo la roseta multicolor de la muerte cuando se para el disco mecánico y tiene que arrancar. Además, la carga de aplicaciones, incluso las pesadas como Pages o Word, es prácticamente instantánea.

Y justo ahora, mientras escribo esto en Scrivener, tengo abierta una máquina virtual en Unity con Windows 7 x86 en la que se está instalando el SP1 de Visual Studio 2010 porque he instalado el AtmelStudio, que es un IDE basado en el Microsoft para generar ejecutables para los microprocesadores de Atmel.

***

Acabo de hacer una pausa para lanzar el JTAG MK-II, conectarlo a Windows y verificar que el AtmelStudio lo reconoce y funciona, todo ello virtualizado. Que es una de las cosas a las que quería llegar. Con un buen producto de virtualización, uno puede tener lo mejor de ambos mundos. Un equipo silencioso a más no poder que ejecuta de forma transparente tanto aplicaciones Windows como OS X sin mayor complicación que molestarse un poco en configurar las cosas, y encima con un rendimiento equivalente a si se ejecutara en real.

Evidentemente tenemos BootCamp, pero os aseguro que Windows no funciona igual que en un PC real, y perdemos todas las cosas buenas que puedes hacer con un MAC.

***

Pero no es a eso a lo que me refiero. Más bien todo esto es una especie de parche o pegote. De lo que realmente quiero hablar es de desarrollar para al menos Windows y MAC sin tener que crear dos programas diferentes.

Descartamos de entrada que un mismo ejecutable pueda funcionar en ambas plataformas. Por parte de los dos contendientes queda descartado. Microsoft podría haber hecho .NET para OS X o Apple Cocoa para Windows, pero no creo que eso vaya a ocurrir nunca jamás.

La única posible solución es Mono, pero ignoro sin un EXE de Windows se lanzará en un MAC o no, y lo voy a descartar por razonamientos que expondré más adelante.

***

Por lo tanto, la otra posible solución es compatibilidad en el código fuente. Que yo conozca, sólo tenemos dos grandes contendientes: QT y lo que ahora es Embarcadero pero que todos conocemos como Delphi y/o C++Builder.

De QT he hablado ya por aquí, pero no como plataforma cruzada. He estado usándolo un poco, en un proyecto en donde trabajaba, pero sólo para generar aplicaciones Windows.

En principio QT es multiplataforma si no te sales del propio Framework, y de hecho he podido compilar un mismo código fuente en ambas plataformas sin más que compilar o bien desde Windows o bien desde OS X. Hay que tener mucho cuidado y usar el propio Creator de QT, y todos los ficheros servirán sin problema. Eso sí, necesitas dos ordenadores, uno para cada plataforma. Tres si quieres también Linux.

Esto nos trae a lo que hemos tratado antes. Como no es posible ejecutar OS X desde una máquina Windows (no sin violar licencias y sin hacks y sin limitaciones y fallos aleatorios), la única solución es tener un MAC más o menos potente y usar un Windows virtualizado, compartiendo la carpeta de desarrollo.

En mi caso, pese a no estar haciendo nada más que estudiar ahora que estoy en paro y tengo tiempo para jugar con todo esto, tengo una carpeta en donde está todo mi código fuente, carpeta que está compartida con SkyDrive y de ese modo puedo verla también en mi ordenador Windows (no el virtualizado), aparte de hacer copia de seguridad de forma automática.

Ojo con sincronizar mediante SkyDrive entre real y virtual, porque el tema no es instantáneo y puedes armar un buen jaleo. La solución es compartir una carpeta de tu MAC en tu Windows virtual. Con Fusion la cosa funciona muy bien, y hasta Embarcadero ha solucionado los problemas que tenía para compilar sobre carpetas de red (Microsoft siempre lo ha tenido resuelto, incluso dando la posibilidad de cachear localmente los ficheros intermedios).

Si nos damos cuenta, con QT tenemos que compilar y ejecutar en cada máquina, lo que en principio no es un gran problema, pero sí cuando quieres algo que no está en el Framework. Ahí si que tienes que, mediante compilación condicional, sacarte tu mismo las castañas del fuego. Dada mi escasa experiencia con QT multiplataforma, no puedo asegurar si es algo muy habitual o no.

***

El otro participante es Embarcadero, con su FireMonkey bajo Delphi/C++ Builder. La historia de todo esto es un poco rocambolesca, ya que la empresa ha llevado muchos años implementando compilación condicional en su VCL. Sólo hay que mirar el código fuente de cualquier versión (creo que desde la 2009) y ver cómo muchos ficheros tienen secciones para Windows, MAC y Linux.

Uno, por tanto, se esperaba que cualquier día anunciaran que la VCL se había convertido en multiplataforma y que se podría compilar para estos tres sistemas operativos.

Pero no, Embarcadero compró un producto a medio hacer y en seis meses lo transformó en su FireMonkey, que anunció a bombo y platillo con su nueva versión de RAD Studio XE2. Que por cierto se encuentra completamente lleno de bugs y no hay entrada de blog explicando esta o aquella característica que no hable de que hay un problema y que han tenido de resolverlo de alguna manera. Y es que seis meses es muy poco tiempo.

FireMonkey es una gran idea implementada muy pobremente. La idea es usar el IDE de Delphi o de C++ Builder para, a partir de un mismo código fuente, generar un ejecutable Windows o MAC, pero siempre desde Windows, por lo que estamos ante el mismo problema que antes.

La ventaja aquí es que puedes hacerlo todo desde Windows, hasta depurar. Es decir, es necesario instalar un servidor en el lado MAC, servidor que te va a permitir enviar el bundle OS X al MAC y depurarlo.

Y como todo primer producto, está completamente lleno de bugs y da muchos problemas, tanto el IDE como la depuración remota y el framework en sí. Embarcadero lleva sacados cinco parches, uno de ellos tan grande que exige reinstalarlo todo, que mejoran algo pero no mucho.

Y para más INRI, son aplicaciones de 32 bits, cosa que en los MAC se está acabando a pasos agigantados.

Esperemos que el XE3, que saldrá este verano, mejor algo la cosa.

***

Nos falta comentar Mono, el C# multiplataforma y de código abierto. Ya he hablado algo de él aquí con anterioridad, pero ahora voy a matizar un poco más. Mono engloba una serie de tecnologías más o menos integradas que comparten un mismo lenguaje de programación: C#.

Basado en ports, todo el meollo se centra en un IDE (disponible para ambas plataformas, como el de QT) que permite crear aplicaciones basadas en los ya citados ports, de los que disonemos de varios según qué plataforma.

Por un lado tenemos el de Windows.Forms, que nos permitirá generar código compatible con la tecnología de Microsoft y ejecutar en Windows, MAC y Linux. GTK# es otro de ellos. También está MonoMAC, en exclusiva para MAC. Hay más pero nos detenemos aquí.

La idea es que cada port conserva la idiosincrasia de cada origen. Es decir, el API de GTK# es el GTK pero traducido a C#, y así con todos. Es una buena idea y en general, se puede generar código para Windows y MAC sin problemas mayores que los que tendríamos con QT.

***

Pero ahora viene el tío de la rebaja. Hemos visto algunas pegas que tienen todos estos sistemas de desarrollo, pero no son las peores de todas. De todos modos, si desarrollas para MAC necesitarás un MAC, y lo mismo para Windows, así que llevar a cabo esas tareas en ambas máquinas no es todo lo malo que se puede esperar, y de hecho en todos los casos existen soluciones bastante óptimas, aunque lo más deseable sería el acercamiento de Embarcadero, con compila en un sitio, ejecuta en dos.

La mayor pega de todas consiste en que prácticamente ninguno de estos sistemas pinta los controles como nativos. QT podría salvarse por los pelos, pero ni FireMonkey ni Mono, salvo MonoMac, aparecen como aplicaciones nativas. En la documentación de algunos productos la llaman hasta “alien”. Ya os podéis imaginar. Y si bien en Windows un usuario normal puede aceptar ciertos interfaces exóticos, un fanboy (perdón, maquero) de pro seguro que te manda a la mierda con todas sus palabras, y encima con razón.

El caso de MonoMac no se aplica, ya que no podremos compartir código fuente con Windows puesto que se trata de un envoltorio sencillo sobre el propio Cocoa con la idiosincrasia de OS X.

Por lo tanto, el único Framework que sé de forma fehaciente que ha entrado en la App Store de los MAC ha sido QT tras aplicar unos parches para evitar que el propio QT modificara ficheros dentro del bundle. De todos modos no sé qué pasará con el Sandboxing y si QT (y los demás) lo soportan.

Finalmente, está completamente claro que, a fecha de hoy, desarrollar en multiplataforma de manera coherente continua prohibido, principalmente por limitaciones de los Frameworks existentes que de problemas técnicos, dado que el rendimiento y las herramientas base (como compiladores de plataforma cruzada o lenguajes comunes en diferentes plataformas), están más que maduros.

Tan sólo habría que crear un Framework que utilizara los controles nativos de cada plataforma, cosa que a fecha de hoy no existe (más sobre esto luego).

***

¿Qué nos queda, pues? Tan sencillo y tan complejo como dividir nuestra aplicación en dos partes. La primera, la parte visual, tendremos que hacerla diferente para cada plataforma. Objective-C en MAC, Win32 (MFC, o cualquier otro que pinte nativo), y la parte no visual o el núcleo de nuestro programa en algún lenguaje común, como puede ser C++ y STL y mantener al loro todo el tema para que compile y funcione en todos los sistemas de destino…

Es más trabajo, pero creo que es la única forma de mantener un interfaz visual nativo y coherente. El problema viene cuando nuestra aplicación es demasiado simple de modo que mantener esta estructura es más costoso que crear dos programas de forma independiente.

Aparte, claro está, la bajada de rendimiento al tener que desacoplar ambas partes, aunque esto es muy bueno y debería ser una constante en cualquier desarrollo no trivial, aunque estemos haciéndolo solo para Windows o sólo para MAC. No obstante, a veces la caída de rendimiento es tal, o el programa es tan meramente visual que este acercamiento no es aplicable.

***

Si os dais cuenta no he entrado en el tema de código abierto versus código cerrado, y es que para el programador medio, se la trae floja si tiene el fuente o no de lo que esté usando: no lo va a mirar porque o bien no tiene tiempo o bien no está capacitado.

Tampoco he cubierto el tema Metro de Windows 8, que está de lado del tema móvil, en el que no he entrado pese a haber también Frameworks genéricos. Aquí estamos igual, pero ahora las plataformas son Windows Phone, Windows Metro (o RT), Android e iOS, y si las de Windows y MAC son disparejas, no os digo estas. Y, a fecha de hoy, que yo sepa, no hay ningún Framework multiplataforma y compatible. FireMonkey promete llegar a Android, Metro y a C++ en próximas versiones, pero si ya con dos plataformas la cosa está como está, no quiero saber cuando haya tantas…

***

Me falta hablar de un jugador que no he nombrado y que tiene muy buena pinta, quizás la mejor de todas pero, como apenas lo he probado, lo dejo para una futura entrada. Se llama wxWidgets y hace tiempo que hablé de él aquí, pero para Windows. Estamos ante un Framework con mucha solera en el mundo del desarrollo y que usan empresas como Google en su producto Google Drive a través de wxPython.

Y la mayor ventaja está en que, aparte de estar disponible para alguna que otra plataforma embebida, los controles son los nativos de cada sistema operativo.

***

QT en Windows y OS X (Fijaos cómo los controles son casi nativos en cada sistema).

FireMonkey en Windows y OS X (Esto no pasa la MAC App Store ni a golpe de talonario. Por no aparecer ni el menú aparece donde debe).

WxWidgets en OS X (Todos los controles son nativos).

Un poco hasta los cojones del OS X sí que estoy, la verdad

Rafael Ontivero — Fri, 01 Jun 2012 14:02:55 GMT

No sé quién diría eso de en MAC eso no pasa, pero el hecho es que, a fecha de hoy, OS X Lion no llega ni a la suela de los zapatos de Windows 7. Esperemos que el Montañés mejore algo, porque lo que es la versión actual, es un mucho mierdosa.

Aparte de las infinitas carencias en usabilidad, con un Finder al que hay que meterle diez extensiones o instalarse sustitutos para se que acerquen un poco al Explorador de Windows, los programas más o menos mierdosos que necesitan sustituto (léase Mail, iCal, …), las porquerías del Spotlight que unas veces va lentísimo, otras antepone los propios programas de Apple a otros de terceros aunque los de origen no se hayan usado nunca (y por eso uso Alfred), la necesidad de gastarte una pasta en sustitutos que en la mayor parte suelen ser gratuitos en Windows, las pifias de programas serios como iPhoto que unas veces sí y otras también es incapaz de recordar que tengo activo el photo streaming, los petes del Pages porque él lo vale y que me hace rememorar las primeras versiones de Open Office, que cascaban o iban mal sí o sí, los enganches y autismos varios del iTunes, la ruedecilla multicolor de la muette, que aparece de vez en cuando, sobre todo en Safari, la lentitud en arrancar el sistema completo…

… Todo eso, a lo que hay que sumar la pésima gestión de memoria y, ahora mismo, dos problemas con el kelmer o que creo que vienen directamente del mismo.

***

Tengo un monitor secundario enganchado a un puerto Thunderbolt pero usado como DVI con su adaptador correspondiente. Pues bien, cada dos por tres pierde lo que quiera que pierda y ambas pantallas se ponen a parpadear. La anexa porque se ha perdido, y la principal poniendo y quitando el escritorio como si eso fuera a solucionar en algo la otra pantalla.

***

El otro problema viene con el puerto de la SD, que sólo me permite insertar una tarjeta por reinicio. Sí, una vez que he insertado una tarjeta, y tras su expulsión, ya no vuelve a leer nada de ella.

***

En ambos casos no es el hardware, porque en Windows con Boot Camp en ningún momento me ha pasado nada parecido. Es el *** OS X que, tras cada actualización, va peor que la anterior.

***

Y ya para finalizar, ¿quién es lumbrera al que se le ha ocurrido poner el puerto de la SD justo debajo de la ranura del DVD? Porque manda cojones, mucho diseño, mucha tontería pero lo dicho: ergonomía poca o ninguna. Justo hace un momento casi tengo que desmontar mi iMAC (que todavía está en garantía) porque he metido por error la SD en el hueco del DVD…

En fin, que mucho ruido pero pocas nueces.

***

Perdonadme la entrada, pero creo que tengo razón al quejarme de todas estas cosas y de más que no os cuento porque tengo la duda de si es el layer 8 o el sistema.

MonoTouch: muy bonito pero una guarrería

Rafael Ontivero — Wed, 30 May 2012 09:17:01 GMT

Ayer estuve jugando un poco con MonoTouch, más que nada por curiosidad. Para los que no lo sepáis, es un IDE más una biblioteca que envuelve de forma conveniente todo el desarrollo para iOS, tanto iPhone como iPad y que permite a un programador de C# desarrollar para estas plataformas sin tener que aprender nada de Objective-C y demás zarandajas.

Es un decir, porque realmente no es más que un envoltorio fino a todo eso. Por lo tanto, si estás desarrollando para Windows o Silverlight, no esperes sentarte y ponerte a ello porque aparte de usar la sintaxis de C#, todo lo demás es iOS. Incluso se usa el IDE de xCode para crear los elementos gráficos y su interactuación, como son los outlets (propiedades) y las actions (los eventos).

La ventaja es que al ser una capa fina apenas introduce sobrecarga y todo es nativo. El inconvenientes es que tienes que aprenderte todas las idiosincrasias del iOS.

Y otra cosa que no me creo mucho es el tema de la compartición de código. No esperes tener el mismo código fuente de tu aplicación y compilar para Android, iOS, OS X y Windows. Podrás compartir bloques de código, pero nada más.

***

Otra cosa es que estas herramientas son de pago. Desde 400$ la más barata hasta viarios miles de dólares. Depende de qué quieras y cómo. Las versiones gratuitas para Android e iOS no caducan pero sólo permiten ejecutar código en el simulador.

Las versiones para escritorio son completamente gratuitas.

Se me olvidaba decir

***

Ahora bien, como decidas desinstalar algo… arreglado vas. Aparte de que no hay desinstalador, los procesos para hacerlo son completamente insuficientes y te dejan el sistema hecho unos zorros con miles de archivos desperdigados por todo el disco.

Versiones anteriores traían un desinstalador embebido dentro del PKG que realizaba la instalación, pero al menos la que yo he instalado no lo trae.

Primero ejecuta los comandos descritos aquí. Eso te va a limpiar digamos que las partes públicas del entorno. Y si tienes la última versión de xCode instalada, te puedes cargar la carpeta /Developer de un plumazo sin problemas porque sólo tendrás el Mono de los cojones en ella. Pero antes de hacerlo, míralo por si acaso.

Una vez pasado ese script, si te pica la curiosidad, haz una búsqueda global con la palabra “mono”.

En mi caso he usado CleanMyMac para limpiar el ordenador de basura, pero tu puedes hacerlo a mano o con otra herramienta. Ojo con los ficheros que no son del mono.

Finalmente tenemos que desinstalar MonoDevelop. En mi caso, de nuevo con CleanMyMac.

Y creo, sólo creo, que tengo limpio de nuevo el sistema.

Hay que joderse.

Menuda porquería de gestión de memoria que tiene el OS X

Rafael Ontivero — Sun, 06 May 2012 18:24:35 GMT

A veces, cuando uno es un swicher de pro como yo, se encuentra con cosas que le resultan un tanto kafkianas como la que os voy a contar.

¿Tiene alguien queja de la gestión de memoria de Windows? No me refiero a si consume más o menos, sino a si funciona como debe, sin que haga cosas raras. ¿A que no? Pues en OS X (los MAC para los despistados), dicha gestión deja mucho que desear.

Hace tiempo empecé a leer en los blogs fanboys la existencia de ciertas aplicaciones que liberaban y optimizaban la memoria de los MAC. En principio algo similar a los supuestos optimizadores de memoria en Windows, pero para OS X. Y si en Windows no hacen falta y sólo consumen recursos, en OS X debería ser lo mismo o, en opinión de los expertos, todavía más inútiles que en la plataforma de Microsoft.

Yo fui uno de esos que comenzó a defender a capa y espada la gestión de memoria del OS X sin haber hecho ninguna prueba porque suponía que era una cosa que se caía por su propio peso: si un sistema operativo es incapaz de gestionar bien su memoria, poco útil va a ser…

Y de hecho, igual que pasó en su momento cuando se promocionaban ese tipo de aplicaciones para Windows, con artículos pagados y demás, se armaron en los citados blogs unas buenas trifulcas sobre el tema, con razonamientos a favor y en contra más o menos elaborados y veraces…

Una puntualización. En OS X, cuando tu cierras una aplicación, está no se cierra realmente, sino que se suspende y queda residente en memoria. Es lo que ocurre cuando le das al aspa de cerrar, o cuando presionas Command-W. Si realmente quieres retirarla de la memoria, o cerrarla ala Windows, tienes que presionar Command-Q o hacerlo a mano desde el Dock. Aquí hablamos de cerrarla realmente, que es cuando se debería liberar su memoria. No obstante, hay programas que realmente se cierran ellos solos, como el gestor de libros Calibre.

Por lo tanto, en OS X tenemos dos formas de cerrar una aplicación. En la primera realmente no se está cerrando, sino que se está ocultando y no es aplicable lo que estamos hablando aquí. Sería el equivalente de minimizar en Windows.

En OS X, la memoria se va asignando pero no liberando. Es decir, tu abres un programa, lo usas y luego lo cierras del todo. La memoria asignada no se libera, sino que queda asignada por si se vuelve a abrir la aplicación y se aprovecha la huella de memoria ya existente.

Por lo tanto, conforme vas abriendo y cerrando aplicaciones la memoria se va llenando poco a poco hasta que apenas queda libre. Hasta aquí la cosa está bien, porque de este modo mantenemos una caché que podría resultar en un aumento de rendimiento.

Y a veces es así. La segunda vez que abres ciertos programas, estos se cargan mucho más deprisa porque recuperan su imagen de la memoria física. Por ejemplo, en el caso del Opera con varios miles de mensajes de correos y de news, la diferencia es abismal. De tardar como treinta segundos o más a ser completamente instantánea.

Según la teoría, una vez que se ha ocupado toda la memoria y se necesita más, es esa caché la que se va liberando según un algoritmo que no me he preocupado en mirar.

Eso es la teoría. La práctica es otra: se tira de swap y el rendimiento de tu MAC empieza a caer en picado y oyes cómo empiezan a rascar los discos duros. Y nadie puede negármelo porque lo he comprobado yo mismo esta mañana.

Todo ha comenzado pasándome del iMAC al Air la biblioteca del iTunes. Para ello he iniciado el AirDrop y con ambos iTunes cerrados, lo he copiado. En el Air estaba vigilando el uso de procesador del Sparrow, que me tiene mosca, así que he abierto el monitor de actividad en el iMAC.

La primera en la frente: de los 12GB de RAM que tiene el iMAC, he visto cómo conforme si iban pasando los ficheros de uno a otro se iba quedando en cero libres. Una vez ha terminado de copiar, he abierto varios programas como el Word, el Pages y el ordenador ha comenzado a tirar de swap en lugar de liberar la memoria inactiva. Los he cerrado del todo y no ha decrecido el consumo.

Para completar el ejercicio he lanzado una máquina virtual que consume 2GB de memoria y ni aun así se ha liberado lo ocupado, sino que los discos han empezado a rascar todavía más furiosamente y el rendimiento ha caído en picado…

Tras eso me he ido a la App Store y me he bajado un liberador de RAM. Al poco de ejecutarlo y lanzar la limpieza de la misma, mano de santo, oye. Los discos han dejado de rascar y me ha dejado algo más de 8GB de RAM libres, que han subido a 10 cuando lo he vuelto a ejecutar tras cerrar la máquina virtual.

El problema, evidentemente, no está en el consumo de RAM. Por mi como si se ocupa toda, sino en el hecho de que un consumo real de 2GB del sistema operativo más otros 2 GB de la máquina virtual, han tirado abajo el rendimiento de un iMAC con 12GB de RAM y un i7 con 8 cores…

Pensaba que Apple podía hacerlo mejor, pero al final resulta que son unos chapuceros de mucho cuidado…

Por si os interesa, he probado el FreeMemory y tras comprobar que funcionaba bien, he comprado la versión Pro por tres cuartos de euro.

Win/MAC: arranque dual y jodimiento de particiones

Rafael Ontivero — Sat, 19 Nov 2011 12:14:42 GMT

Os lo juro. Estoy hasta los putísimos cojones de Windows, de MAC y de la madre que los parió a todos. El primero por pensarse que todo le pertenece, incluyendo las particiones HFS+, y el segundo por pensar que todos los usuarios son tontos del culo.

No tengo muchas ganas de escribir, así que voy a ser bastante escueto.

Escenario: Windows/MAC con Boot Camp y arranque dual. Como Windows asigna las unidades como le sale de los cojones, entro en el Administrador de Discos y las cambio a los valores que quiero.

Vale, todo bien en Windows. Inicio OS X y… una de las tres particiones no se carga. Es decir, habiendo cambiado la letra de unidad a dos particiones HFS+ desde Windows, una de ellas luego no se carga desde OS X porque Windows, en su maravilloso afán de poseerlo todo, ha decidido cambiar cierta cadena de las tablas internas del disco por “Microsoft Basic Data”. Hay que joderse con tomate. ¿No saben reconocer una partición ajena y no tocar nada? Pues parece ser que no, que tienen ganas de joder la marrana.

Bueno, la Utilidad de Discos de OS X se ve incapaz de recuperar la partición. Hala, nueva pérdida de datos. Cuatro máquinas virtuales y un montón de descargas.

***

Pues no, hay solución. Está aquí. Otro geek de la más alta alcurnia se ha encontrado con el mismo problema y ha creado una aplicación en Python para solucionar el problema. Lo único que hace es cambiar dicha cadena por su valor por defecto. Y entonces OS X reconoce la partición como suya y la monta.

Olé sus cojones.

Os cuento cómo hacerlo.

***

Desmonta el disco completo en donde esté la partición afectada. Luego graba el fichero gpt_surgeon.py en disco (ojo con grabar el html y no el contenido del mismo). Aquí viene cuando Apple piensa que somos imbéciles o así. Tu grabas un archivo, que te lo pone como texto de lectura escritura. Pero tu lo quieres de ejecución, porque si no ya puedes darle de sopapos porque se negará a correr.

Hay que añadir el bit de ejecución. ¿Cómo? Ahí está el problema. Desde la interfaz gráfica no se puede, porque CMD-I sólo te dejar cambiar entre lectura y escritura, pero no ejecución.

Quizás haya algún botón por algún lado para activarlo, pero no lo he encontrado, así que tienes que abrir una ventana de terminal y cambiarlo ala UNIX: “chmod u+x gpt_surgeon.py”. Claro, puede que algún imbécil siga la secuencia desde el Finder y sea capaz de cambiarle los permisos a un troyano. En fin, viva la ergonomía y usabilidad maqueras.

Luego sigues la secuencia explicada en el enlace de arriba:

./gpt_surgeon.py list /dev/disk<n>, en donde <n> es el disco malo.
Localiza la partición jodida, en la que debe aparecer el infame texto de “Microsoft Basic Data”.
sudo ./gpt_surgeon.py repair /dev/disk<n> <y>, en donde <y> es la partición rota.
Al poco, OS X (o el script) montará todas las unidades, habiendo reparado la estropeada.

Y ya está, esta ha sido la crónica del día de hoy. Cagontó…

iCloud o la flagrante tontería

Rafael Ontivero — Sun, 16 Oct 2011 11:09:38 GMT

¿Sabéis lo que es iCloud? Aunque digáis que sí, me juego un gallifante a que no. ICloud es una mierda envuelta en papel brillante, un trozo de bisutería rodeado de oro del que cagó el moro.

Acabo de comprobarlo. Tengo dos iMAC, un iPad, un iPod y un iPhone (este del curro, que todavía no he actualizado).

Como sabéis, hace unos días salieron todas las actualizaciones de golpe, tanto para el escritorio como para los dispositivos móviles. En mi caso la actualización a Lion 10.7.2 se realizó sin problemas, salvo una notable ralentización del sistema una vez reiniciado, ralentización que parece es temporal ya que ahora funciona todo casi igual de rápido que antes… excepto algún que otro rosetón multicolor de la muette que deja mi i7 de cuatro núcleos dobles y 12 GB de RAM como autista unos segundos… Eso no lo hacía antes de aplicar el parche.

No obstante, la actualización de los dispositivos móviles ha sido más que penosa. En primer lugar falló la descarga y la actualización. Me dio el infausto “internal error” causado por la caída de los servidores de Apple. Hay que joderse, con la expectativa generada y que la empresa no fuera capaz de preverlo con antelación. Joder, hasta Microsoft, el denostado Microsoft, cuando saca un producto nuevo que es muy esperado, aumenta y confía en terceros para las descargas…

Pero no todo termina ahí, no. El iPod se actualizó más o menos bien, a la tercera o la cuarta, pero el iPad hubo de sufrir bastantes intentos. O bien se quedaba autista o bien simplemente fallaba. Como tengo casi 40 GB de datos en él, y la interrupción se producía casi al final, la cosa llevaba su tiempo. Al final, restauración de fábrica, instalación de las aplicaciones y vuelta a meter los datos. Menos mal que soy un chico previsor y los tengo en el MAC, listos en sus carpetas. Eso sí, todavía estoy configurando programas…

¡Quietos parados, fanboys! A ver. Uno mete el iPad, te dice que tiene una actualización, le dices que sí, y a medias falla. No hay otra. No es mi culpa. Es de Apple. Por el motivo que sea. Mi iPad está impoluto, sin Jailbreak, sin cosas raras. Ya que está todo cerrado, debería funcionar a la primera, porque si no me vuelvo a Windows que me deja hacer lo que quiera sin más, y si falla puedo achacarlo a mi ineptitud, no a la de Apple. [Como colofón a esto, no soy el primero que ha tenido problemas. Básicamente la actualización a iOS 5 ha sido pésima. También quiero pensar que no se trata de un intento de que estampe mi iPad 1 contra la pared y me compre un 2.]

***

Bueno, ahora sí, ahora hablemos de la magia de la cosa esa del iCloud. ¿Os pensáis que es una versión mejorada de Dropbox? Juas, ni se le acerca. Hasta el infausto SkyDrive de Microsoft es mejor.

No, no es que vaya mal, es que no cumple mis expectativas. Es una decepción total, más que total, humillante. Lo único que te va a guardar iCloud son los documentos de Pages, de Office (a mi no me lo hace), tus fotos y los calendarios… pero los que crees en la nube. Es decir, la cacareada sincronización sólo se va a producir entre los documentos políticamente correctos que, como siempre, le vengan en gana a Apple. No mis documentos. No mis fotos ya hechas, no los documentos que yo quiera, no.

Y encima, como elemento de obsolescencia programada, si quieres tus documentos en la nube, paga por nuevas versiones que lo soporten. Asco me da. Decepción. Tristeza.

***

En serio, tengo una extraña sensación que me parece que, conforme va pasando el tiempo, es más fuerte y coherente: cuanta más cuota de mercado coge Apple, más se parece a los peores tiempos de Microsoft, con fallos estúpidos, dejadez en atender los requisitos de los clientes y olvidarse de que uno debe estar al loro con las actualizaciones de seguridad y que no debe esperar dos meses a, por ejemplo, invalidar una entidad certificadora. Es una especie de deja-vu, una sensación como de inquietud y de malestar… Ahora que Jobs ya no está, quizás la cosa mejore… aunque lo más seguro es que empeore.

Básicamente, maldita la hora en que me pasé a Apple.

OS X Lion: Ver la carpeta Librería desde dentro del Time Machine

Rafael Ontivero — Fri, 05 Aug 2011 15:37:47 GMT

De nuevo volvemos a Lion y a sus chipirtifláuticas nuevas características súper fashion de la muette. Ahora hablamos de cómo mirar dentro de la Librería de nuestra carpeta de usuario cuando estamos dentro de Time Machine porque queremos recuperar algo de allí. No, no se ve. Aparte de que es un poco complicado acceder a la carpeta de usuario porque Apple nos quiere ocultar cada vez más el sistema de ficheros de OS X, cuando entras en ella la carpeta Librería no está aunque le hayas cambiado el atributo de oculto… Mola, ¿no? Si buscas por la red verás un montón de páginas que explican cómo hacerlo, matando el Finder y con otras técnicas un tanto barrocas. La mía no es que sea muy directa, pero al menos no le tocamos las pelotas al sistema operativo y se hace todo de forma ordenada. Lo primero que hay que hacer es montar la unidad en donde se guarda la copia de seguridad. Hay varias formas, como lanzar una copia de seguridad manual, entrar en el Time Machine y luego salir o simplemente haciendo clic en la unidad en donde estemos realizando la copia. Una vez montada, es tan fácil como abrir un Terminal y movernos al home de la copia que queramos. Partimos de la carpeta "/Volumes" y nos vamos adentrando en la copia. También podemos hacer doble clic en el disco montado en el escritorio o seguir navegando por el Finder… La cosa es llegar al home de la fecha que nos interese, ya sea por terminal o con el Finder. Una vez allí podemos pulsar CTRL-I (o Ver información) sobre la ruta, para saber dónde estamos. Si hemos usado el terminal no tenemos que hacer nada más que, una vez en nuestro home, picar "cd Library" y estaremos dentro. Si lo hemos hecho con el Finder, ahora es turno de abrir un Terminal y seleccionar y copiar la ruta completa que nos aparece en la ventana de información, picar "cd " en el terminal y pegar dicha ruta sobre el mismo. Al pulsar Enter estaremos en la misma situación que el párrafo de arriba. Ahora viene el truco del almendruco. Podemos usar el terminal para copiar lo que queramos con los comandos de Unix (ya sabéis, cp), pero resulta mucho más cómo hacerlo con el Finder. Por lo tanto ahora picamos pwd en el terminal y presionamos enter. Justo arriba del cursor nos aparece la ruta completa en donde estamos. La seleccionamos con el ratón y la copiamos. Hacemos clic sobre el escritorio para que en el menú del sistema nos aparezca el del Finder. Elegimos "Ir -> Ir a la carpeta" y en cajetín, pegamos la URL que acabamos de copiar. Se nos abrirá una ventana del Finder en todo su esplendor. [Sí, ya sé que hay una forma muy fácil de mostrar la Libería, que es explica en infinidad de sitios, pero sólo sirve para la carpeta de la cuenta actual, no dentro del Time Machine.] Por supuesto también vale hacer esto para entrar en la Libería del home actual de nuestra cuenta de usuario. Otra forma para, desde cualquier carpeta, ir retrocediendo carpetas padre, es pulsar Commando+Flecha Arriba o, sobre el título de la carpeta en el Finder, retroceder haciendo clic con el botón secundario del ratón.

¿Se cree Apple que somos imbéciles?

Rafael Ontivero — Thu, 21 Apr 2011 16:59:51 GMT

Supongo que a estas horas, con toda la parafernalia mediática que lo está rodeando, todo el mundo sabe que el sistema operativo iOS realiza una triangulación y seguimiento de nuestros aparatos siempre que lleven 3G…

Mención especial de la noticia son los blogs voceros y defensores de Apple a toda costa, transformando lo terrible y lo intolerable en algo leve y sin mucha importancia… Estoy hablando de entradas como esta, esta y esta. Y ya de paso, un olé al amigo Malo Maloso de Spectra, Chemita y su entrada por decir las cosas claras.

Ya cuando empecé a leer sobre el tema, anoche, en mis aplicaciones dentro de un, vergüenza me da escribirlo, iPad, empezó a hervirme la sangre.

Hace ya tiempo que veo un enorme paralelismo entre los malos tiempos de Microsoft y la actualidad de Apple. Microsoft hizo muchas cosas malvadas y de las que debería hacer acto de contrición, como robar a Stacker y envolver su driver en otro simulando que lo habían hecho ellos, o cuando metieron un payload en Windows 3.1 para que éste fallara si corría sobre DR-DOS…

Pero lo de Apple no tiene nombre. Aparte del oscurantismo y el control dictatorial, aparte de ese aura de estúpida magicidad, de ese espíritu cool y guay del Paraguay se esconde una de las empresas más ingentemente malignas, más absurdamente controladoras, manipuladoras y aberrantes de toda la historia de la informática. Para mi Apple es el Cuarto Reich, Steve es Hitler, con la evidente distinción de que, y solo de momento, Apple no mata, o casi (sólo hay que recordar lo que pasa en Foxconn).

Para aquellos que no lo sepáis todavía, iOS guarda en un fichero sin encriptar la geolocalización de todas las iCosas que tengan 3G. No sólo lo guardan los dispositivos, sino que también está presente en las copias de seguridad de los ordenadores. Si bien es cierto que este hecho viene indicado en el contrato de treinta páginas que te obligan a aceptar, la verdad es que resulta inconcebible que se pueda hacer impunemente algo así.

El hecho no es malo en sí, el hecho es que se trata de algo que ha sido ocultado, manipulado y que pone en peligro la integridad física de algunas personas. Es evidente que, en principio, poca importancia tiene por dónde haya pasado un iPhone. Pero no para un juez antiterrorista, ni para un político en el punto de mira de alguna organización terrorista, o incluso como herramienta de chantaje. Es tan fácil como entrar en casa del interfecto, volcar la copia de seguridad de su iPhone en un pincho USB y conocer por dónde se pasa… o pagarle a un chorizo para que robe la iCosa en un descuido de la persona vigilada.

Pero lo peor de todo no es eso. Lo peor ha sido la respuesta de Apple. Con toda su desfachatez, con toda su cara dura, ha dicho que es un bug y que será solucionado en la siguiente versión.

Apple, ¿te crees que somos imbéciles? ¿Que nos chupamos el dedo? Hay que joderse y hay que ser muy cínico y muy jodidamente oscurantista para que el común mortal se crea una mandanga así… No obstante, seguro que más de un fanboy salta a pies juntillas con la justificación…

En fin, que cada vez me dan menos ganas de seguir con esto de programar para las herramientas construidas por tales interfectos…

MAC Rationale vs Windows Rationale en el desarrollo

Rafael Ontivero — Sat, 19 Mar 2011 14:42:00 GMT

Todavía estoy leyendo temas generales sobre el desarrollo en MAC, de hecho aún no he pasado de los manuales que describen las tecnologías y los diferentes bloques en que se divide el desarrollo en MAC.

No obstante me ha surgido una curiosa reflexión que quiero compartir con vosotros. Todavía no estoy muy seguro de que sea completamente cierta, porque todavía no he profundizado en los conceptos MAC y lo que he leído tiene más que ver con la publicidad del desarrollo en esta plataforma que otra cosa, pero creo que tiene muchos visos de ser real como la vida misma.

Y lo más curioso de todo es que tiene mucho que ver con el desarrollo Windows, y más cercanamente al de las tecnologías .NET. Cuanto más leo sobre Cocoa, QuickTime (que no sólo es un programa sino una tecnología), etc., más me parece estar leyendo sobre .NET, o más bien sobre la forma en la que se publicita .NET.

Se habla de grandes grupos de tecnologías orientadas a objetos, con grandes rendimientos y grandes facilidades ofrecidas a los desarrolladores. Calcado uno de otro. Ahora habrá que ver la pura realidad.

Del lado .NET ya lo tengo claro: mucho ruido y pocas nueces, al menos para desarrollo de sistemas. Quiero creer que del lado MAC no será igual, pero cualquiera sabe. Ya os iré diciendo.

***

Pero no, no es sobre eso sobre lo que os quería hablar. Veamos por un lado la arquitectura lógica expresada por los manuales de MAC, que creo es más real que la dicha por los de Windows.

Debajo del todo un ordenador de Apple hay un Kernel BSD que no es otra cosa que una variante de UNIX igual que es Linux. Y luego hay un sistema POSIX de toda la vida que de nuevo tiene que ver con el mundo UNIX (que viene a ser como una serie de servicios que simplifican el acceso al núcleo del sistema igual que una consola de comandos en Windows permite trabajar con ficheros sin tener que tocarlo).

Aunque Apple lo ha llamado Darwin, no deja de ser lo que es, y de hecho Apple publica todo el código fuente de ello. Al ser un estándar debe estar separado. Realmente está separado.

Encima de eso hay una serie de capas, Cocoa, Carbon, QuickTime. Más o menos. Pero lo que es cierto es que esos subsistemas están completamente separados del núcleo o más bien encima de él.

En Windows creo que no es así. En su momento, en las versiones NT originales sí que lo era (o al menos así se publicitaba). Recordemos la capa HAL que podía ser para un montón de procesadores y luego el sistema NT Executive nativo, que corría sobre dicha capa. Pero ahora, después de la unificación con la plataforma 9x en lo que fue Windows XP dudo mucho que siga siéndolo.

Porque ahora no hay soporte para ARM, ni para SuperH, ni para PPC. Sólo Intel x86 y dando gracias. Me juego un gallifante a que ahora está todo mezclado y revuelto (y de ahí los problemas de Microsoft para volver a añadir soporte para ARM). Porque si no fuera así no se entendería cómo puede funcionar el sistema de vídeo sobre Win32 accediendo al driver que está en el núcleo (sí, ya sé, anillos, gateways y todo eso, pero no voy por ahí)…

Bueno, quizás en esto me equivoque, pero si alguien me explicara cómo el hecho de reproducir un vídeo dentro de un navegador pueda generar una BSOD estando los sistemas separados, que me lo diga. Porque me ha pasado. Y no una, sino varias veces. Putas ATI.

De todos modos luego veremos alguna razón más de ello y quizás uno de los puntos más fuertes de por qué Microsoft está un poco contra la espada y la pared.

***

Apple ya lo ha hecho al menos dos veces y lo va a hacer una más. En x64 no va a haber Carbon, que es como se le llama al subsistema que soporta programar en C y C++ de forma nativa. En x64 sólo vamos a tener Cocoa (Objetive-C y Objetive-C++) y POSIX (que yo sepa). En su momento, con el cambio de PPC a x86 repitió jugada, haciendo borrón y cuenta nueva y forzando a muchas empresas de software a reescribir sus programas. Como cosa curiosa os diré que Apple encargó a Adobe la creación de su iPhoto, iVideo y demás programas de esa plataforma y Adobe los mandó a freír espárragos porque estaban como locos rehaciendo sus propios programas. Creo que hubo otro cambio rompedor más en los MAC pero ahora no recuerdo qué.

Bueno, el meollo del asunto está en que a veces es conveniente hacer borrón y cuenta nueva. Hasta donde sé, el API de MAC OS X y el de iOS es un API moderno, orientado a objetos y bastante potente. Ya os diré si realmente es cierto cuando me enfangue las manos con ello.

***

Ahora volvamos a Windows. Aquellos que hayan leído sobre el tema, sabrán lo que son los subsistemas. Para los que no, una pequeña introducción.

Win32 es un subsistema. POSIX es un subsistema (o lo era hasta que lo quitaron). De hecho, en las primeras versiones de NT había hasta un subsistema OS/2.

Un subsistema es una API completa que sirve para que las aplicaciones escritas para tal subsistema se ejecuten en él, sean independientes del núcleo y no puedan afectarlo en ninguna manera. Ved la siguiente imagen de la Wikipedia y fijaros arriba a la derecha.

http://en.wikipedia.org/wiki/File:Windows_2000_architecture.svg

Básicamente esa debería ser la arquitectura de Windows. Fijaros también en lo que hemos hablado antes sobre el HAL y el Executive.

¿Realmente Windows es así? Creo que no. Teóricamente si cogéis un programa 100% compatible POSIX y lo ejecutáis en Windows 2000, debería funcionar. ¿Lo hace? Pues no. En su momento lo probé y no funcionaba. Tampoco lo hacía uno de OS/2 cuando ese subsistema estaba, todavía, presente. No es que no funcionaran bien o hicieran alguna cosa rara, es que la mayoría de veces simplemente no cargaban.

¿Ha visto alguno de vosotros un Windows NT ejecutado en un ARM o en un SuperH? Yo no y no creo que funcionen. ¿Vais viendo ya por dónde voy?

Con esto no quiero decir que nunca hayan llegado a funcionar, lo que quiero decir es que yo al menos no lo conseguí en su momento. En un MAC moderno podemos ejecutar prácticamente cualquier comando típico UNIX, desde un “ls” hasta un “ps” pasando por un “dd” o lo que queramos. Aparte de los que la propia Apple ha añadido, que hay unos cuantos.

De nuevo no me malinterpretéis, en ningún momento estoy diciendo que un MAC sea mejor que un Windows por eso. Simplemente estoy diciendo que en un MAC sí que están separadas y presentes las distintas piezas, o al menos así lo creo. De nuevo el tiempo me lo dirá, y yo a vosotros.

***

Y ahora entramos de lleno en .NET. ¿Por qué .NET no es un subsistema y sin embargo está construido sobre Win32, que no es precisamente un API limpia y ordenadita sino más bien todo lo contrario? ¿Por qué no aprovecha Microsoft la arquitectura de los subsistemas para hacer a .NET miembro de derecho propio dentro de Windows y no un mero envoltorio que cada vez se va pareciendo más a lo que envuelve, sobre todo en el tema de la guarrería?

Si ya .NET es algo grande en el aspecto del rendimiento y funcionalidad (comparado con su contrapartida Java y a veces con el propio Win32), ¿qué rendimiento no tendría si fuera un subsistema independiente?

¿O es que toda la estructura arquitectónica de Windows es una mentira como un castillo y no puede haber otros subsistemas cooperando sobre el ejecutivo?

Me gustaría que alguien me aclarara todo esto, porque sinceramente no lo entiendo. Yo tengo mi teoría, que no voy a exponer aquí no sea que se me acuse de lo que creo no soy, y menos ahora que tengo mi calentón de fanboy…

iPad/iPod/i vs. E-ink y otras petisoperías

Rafael Ontivero — Sat, 12 Mar 2011 16:26:00 GMT

[Esta entrada también se ha publicado aquí]

Llevo como una semana leyendo exclusivamente con el iPad y mi nuevo iPod Touch de cuarta generación, que para quien no lo sepa tiene una resolución casi idéntica a la del iPad pero en una pantalla mucho más pequeña, por lo que si tienes buena vista la calidad de lectura es acojonante. Y no, no me molesta el brillo de la pantalla, y si con treinta años pegado diez horas al día a una no me he quedado ciego, no creo que me quede en otros treinta, no al menos por culpa de ellas.

Pese a las críticas a las plataformas de Apple, y su evidente limitación en algunos dispositivos, cada vez estoy más convencido de su utilidad, por encima de Windows. Vamos, que me estoy convirtiendo en un switcher de pro y al completo, pues le estoy dando un tiento al Xcode 4 y me he bajado (y estoy leyendo –que es diferente a bajarse-) un montón de documentación sobre programar en OS X.

A lo largo de mi historia de amor/odio con Apple, he ido rodeándome, sin quererlo, de muchos de sus dispositivos.

Primero fue un iPod de segunda generación, que ahora duerme el sueño de los justos pues lo tengo de mero despertador pero que en su momento me acompañó en muchos viajes y cuitas.

Unos meses después vino un iMac (2008) como quien no quiere la cosa, o más bien como capricho. Ya llevaba un tiempo echándole los ojos a un portátil de Apple, pero los precios me echaban para atrás. Sin embargo, un día en el Mediamarkt mi hermana me dio el empujón que me faltaba y me volví con un flamante Core2Duo de 24”.

Tras la emoción inicial también quedó criando malvas, más por no entender el OS X que por otra cosa, ya que es un aparato silencioso y que cumple como un jabato. De hecho se quedó como plataforma para actualizar el iPod y luego el iPad.

Porque el iTunes en Windows es una mierda. Se atasca y atasca el sistema (incluso en mi i7 con 8 núcleos) sin subir ninguna CPU a un porcentaje de uso remarcable. Es como si el driver USB fuera una castaña pilonga. En algún momento tuve las bibliotecas compartidas entre mi anterior PC (un QuadCore) y el iMac gracias a algún que otro truco, pero ya no.

Más tarde vino el iPad. ¡Ay el iPad! Ese elemento denostado por todos pero que ha tenido un éxito inmenso, más allá de cualquier expectativa… Y es que, pese a las bocas llenas de despectiveces de los expertos, ese tipo de tabletos (expresión copiada de Juan Luis Chulilla) era algo esperado con ansia.

No voy a entrar aquí en que si no es un PC, que no lo es, o la era post-PC del haba de Steve. Es lo que es. Un aparato para estar tumbado en el sofá y ver una película, o leer, o revisar el correo. Y quien niegue la utilidad de eso está más ciego que un topo. Por lo menos para los singles como yo que se pasan el día a solas… y hay unos cuantos singles por el mundo.

Bueno, como os decía, vino el iPad. El mismo día que salió en USA lo compré a un revendedor americano, por lo que el lunes o el martes siguiente lo tuve aquí y pude, por fin, pasar más tiempo en el sofá que delante del ordenador. Sí, yo soy ese tipo de gandul que es capaz de hacer los trabajos de Hércules si luego va a estar tranquilo tocándose las bolas.

Se me olvida decir que antes de esto vino un Time Capsule como disco de copia de seguridad para el Time Machine, Windows y como router. Lo cierto es que como disco de seguridad para Windows no sirve porque la mitad de las veces se desconectaba solo, y Windows 7 terminó de rematarlo. Pero como router es insuperable, y cuando viene alguna visita que quiere WiFi le activo la de invitados y me ahorro de compartir claves y demás zarandajas. Y es un equipo robusto. El cable modem ha sido cambiado dos veces, mientras que el TC ahí sigue, haciendo de Time Machine para mi Snow Leopad.

No me cansaré de repetirlo: el iPad es la rehostia. Y no, no me voy a comprar el iPad 2. Porque la inclusión de las cámaras me la trae floja, y el que pueda ir hasta nueve veces más rápido también. No soy un gamer. Soy un reader. Lo actualizaré cuando le pongan una pantalla más grande o con más resolución. O se rompa el que tengo.

Durante el día, en el trabajo, voy revisando las RSS en los tiempos muertos y las entradas que me interesan las envío al Instapaper. Por tiempo no siempre puedo hacerlo, pero es lo habitual.

Cuando llego a casa y hago las tareas comunes (revisar el correo y las news en el PC MAC, cenar, ducharme, ponerme cómodo), me tumbo en el sofá (en cursiva porque es una cama de esas con motor que puede adoptar la postura que quieras) con mi iPad a mano. Leo las RSS que me han quedado y las que me interesan las voy pasando al Instapaper desde el propio programa. Para mis sindicaciones principales uso MobileRSS, y para las secundarias (libros gratis, libros gratis, y algún que otro relacionado) NewsRack (tengo dos cuentas de Google).

Luego le toca el turno a Fipboard y a Zite. Este último es un reciente descubrimiento y todavía me estoy haciendo a él (y él a mi). Digamos que utiliza una serie de algoritmos basados en tu cuenta de Twitter y de Google Reader para ofrecerte noticias relacionadas a tus intereses. Y se va auto configurando según lo que hagas, lo que leas y cuánto tiempo le dediques a cada tarea. Sí, ya sé, todo termina en unos servidores que a saber qué van a hacer con la información que capturen. Hablando en plata me la trae más que floja que sepan que mis intereses sean C++ o los piticos de boina…

Tras eso cargo el Instapaper y me recreo en la lectura de todo lo que me he ido pasando. A veces reenvió por correo o saco a Facebook o Twitter algo. Eso me ocupa sobre una hora u hora y media, dependiendo de las novedades que haya.

El siguiente paso consiste en o bien cerrar el iPad y abrir un libro-e o libro-p o bien seguir con el iPad, que es lo que estoy haciendo últimamente. Y luego a mimir, a veces incluso en el mismo sofá si hace frío, tengo la chimenea encendida, y estoy perraco para cambiar de cuarto… En verano no sé cómo será mi rutina, porque el anterior mi casa estaba de otra forma y la habitación que ahora es mi cuarto de estar era la de trabajo…

Sí, la tele la tengo de adorno, en otro cuarto, y que siga así por muchos años.

***

Ahora metamos el PC en medio. Es decir, cuando llego a casa lo enciendo y encendido se queda hasta más o menos cuando me voy a dormir. A ratos me levanto y miro las news o miro algo que no puedo hacer en el iPad.

Algunos días, cuando estoy de humor y la jornada de trabajo no ha sido muy opresiva, programo en casa mis cosas tras la sesión con el iPad (o antes). Sí, tengo proyectos personales a medio hacer, algunos de ellos interesantes.

Y es aquí dónde viene la crisis del PC… y personal. Entre septiembre y noviembre de 2010 mi situación laboral cambió drásticamente. Básicamente fui miserablemente engañado por mi jefe, aunque él diga que no. Yo curraba en casa. La central en Madrid cerró por temas que no tienen que ver con la crisis y de los que ni puedo ni quiero hablar, y fue trasladada a una ciudad a media hora de coche de dónde vivo. O al pueblo en donde vive mi jefe.

Yo trasladé mis cosas allí temporalmente para terminar un proyecto que corría prisa. ¡Qué inocente que fui! Pasaron dos meses y seguía allí. Al final todo explotó. Tuve una gordísima con mi jefe y todo quedó claro: no sólo fui engañado para cambiar mi forma de trabajar, sino que luego encima se regodeó diciéndome que ya no podía protestar, que legalmente tenía un mes y ya habían pasado dos. Las promesas de ir sólo uno o dos días a la semana se las llevaron el viento. Mintió como un cosaco.

Pero no sólo fue eso. En el proceso se perdieron 1000 euros que se me debían de unos extras realizados un tiempo antes y no se me pagaron y “hazte cuenta de que eso no lo vas a ver nunca”. Y también perdí mi PC. Mi versión es que cuando yo empecé a trabajar en mi casa había un PC de nivel medio/alto que era mío. Cuando dejé de currar en mi casa no quedó ninguno. Según mi jefe, el PC lo había pagado él. En cierta medida así era, puesto que del original no quedaba ya ninguna pieza, todas ellas rotas u obsoletas en el desarrollo de mi labor profesional. El hecho de facto es que al empezar yo tenía un PC y al terminar no tenía ninguno.

Depresión al canto, ideas muy malas de llevarlo a los tribunales con todo y a por todas. Sondeo de familiares y conocidos para el tema. Todos me daban la razón y afirmaban las palabras y promesas que habían oído de mi jefe, pero nadie se comprometió a decirlas ante un juez (y dándoles gracias por avisarme antes y no hacerlo en el momento crucial). Su palabra contra la mía. Y mejores abogados, como llegó a decirme. Hubo unos días en los que la baja por depresión se tornó una salida demasiado tentadora, una baja larga y demoledora par él…

Lo curioso y lo que más me jode es que encima él queda como el bueno de la película. Como Steve Jobs, su distorsión de la realidad es legendaria entre sus conocidos y familia (por desgracia yo mismo). Según él me dio posibilidad de traérmelo y usar la morralla que había en la empresa, pero claramente las facturas de muchas cosas estaban a nombre de la empresa. Es preferible perder un ordenador que luego ser acusado de robar material de la empresa. Aun así me traje todo lo que tenía una factura a mi nombre…

Pero no, había de por medio otras razones para seguir de las que no debo hablar… así que decidí tragar y seguir. Horario a rajatabla. Cero concesiones. Pasar de él. Todavía tengo cartas en el bolsillo para jugar, pero las cosas se están volviendo “amigables” de nuevo. De nuevo vueltas a casa a las diez de la noche (antes no eran “vueltas a casa” pero eran “retiradas de currar”)… Pero no, no lo voy a consentir.

***

Bueno, centrándonos en el tema, yo estaba en casa, depresivo y sin ordenador. No, sin ordenador no. Tenía mi fiel iMAC, ya algo obsoleto y con un rendimiento no muy bueno al menos comparado con el PC… Así que volví a usarlo.

Pero cometí un error. Instalé el vmWare Fusion y le metí todo lo que tenía en una máquina virtual con Windows 7. Imaginaros un iMAC con 4GB de RAM corriendo una VM con 2GB asignados… Lento.

Por mi cabeza pasó un Mac Pro de 12 cores con mucha RAM. Pero el precio se iba –mucho- de madre. Además, no es oro todo lo que reluce, el rendimiento en determinadas circunstancias no era el esperado en semejante bestia. Así que del de 12 cores bajé al de 4… y me dije que por ese precio tenía un PC el doble de potente, así que eso hice.

Un i7 de 4 núcleos HT que son 8, 16GB de RAM, 4 discos SSD y uno SATA II en una súper placa Gigabyte con más chipsets que operaciones cosméticas llevan algunas, además de una ATI 6850. Y un monitor de 24” a 1920 x 1200 (en lugar de los ahora 1080 habituales) para complementar el que había podido rescatar del ordenador que era mío pero no era mío. Una bestia parda, vamos. El iMAC de nuevo a la otra mesa, como actualizador del iPad e iPod…

Pero la procesión iba por dentro. Como un runrún. Cada vez que cogía un libro para ponerme a estudiar como antes me venían a las mientes que eso iba a servir para mejorar mi curro… y lo dejaba. Si abría el Visual Studio lo mismo. Empecé a usar C++ Builder, que no uso en el curro, pero daba igual.

No quiero. No quiero mejorar para mi jefe. Lo siento. Las tres horas al día menos de tiempo libre que tengo las tiene que pagar de alguna manera. Sí, ya sé, pensaréis que no estaba mejorándome para mi jefe sino para mi. Pues sí y no, pero no es una cosa de querer, es una cosa de poder. A fecha de hoy no puedo estudiar si lo que estudie sirve para lo dicho. Está en mi y en mi espíritu. Punto.

Por lo tanto estoy en crisis. Crisis profunda. No puedo hacer código en casa. Ni siquiera puedo leer un tema técnico sobre desarrollo sin que me de asco. Sí, ya sé. La depresión… O simplemente largarme. Tengo para vivir una muy larga temporada sin trabajar. Pero no, esa es la solución fácil. Es el camino que no debo tomar. O al menos no ahora. Como dice el refrán, a todo cerdo le llega su San Martín. Veremos.

***

Y seguimos con el runrún. También me comentaron en algún foro que para qué cojones quería un MAC si lo iba a usar como un Windows. Así que fui a por un PC de gama alta. Y me lo compré. Estamos ya en diciembre, han pasado tres meses desde el desastre. Gracias, Noelia, a ti también te las tengo que dar. Por ser como eres. Simplemente por eso.

Pero la realidad estaba en que quería usar el MAC como un Windows, o metiéndole un Windows dentro, o como queráis verlo. ¿Y por qué no usar un MAC como… un MAC? Aceptar sus ventajas e inconvenientes y tirar hacia delante…

Joder, a veces uno es tonto y se le escapa lo evidente… Pero todavía no estaba convencido del todo. Yo soy un windowsero rabioso, un fanboy de Windows… Y vino el león. Y Xcode 4.

Ha habido un par de semanas en la que un día he tenido el PC y al otro el MAC. Y vuelta a cambiar de nuevo. Eso de perder 20 años de experiencia a mis 40 suena un poco fuerte… Indecisión. Culo inquieto. Y eso que el rendimiento de mi iMAC en real es bastante decente.

Hala, de nuevo a confesarme. No, claro que no es perder 20 años de experiencia, ni mucho menos. Es como cierta lástima a abandonar, a tomar un camino nuevo y diferente. Perder el MVP. No es que lo vaya a perder de la noche a la mañana ni mucho menos. Todavía respondo en los foros, pero si os dais cuenta desde la crisis no he publicado apenas nada en mi blog de desarrollo. Y tengo temas para hacerlo, pero me faltan las ganas, sobre todo cuando te das cuenta de que encima eres un MVP incómodo.

Yo no escribo en el blog ni respondo en los foros para ser MVP. Sólo faltaría eso. Escribo y respondo porque me apetece y punto. Pero ahora ya no me apetece, o apenas lo hace. Se suma mi crisis, la incomodidad que genero, el hecho de que MS esté perdiendo puntos a pasos agigantados. Nada es decisivo, pero afecta. Bueno, las ganas y mi crisis sí que son decisivas, pero siempre se puede hacer un esfuerzo. Pero no, simplemente no me apetece.

Y es que, también, el proyecto MVP está muerto. Microsoft lo ha matado lentamente. ¿Cómo pueden estar tan ciegos? ¿Cómo cojones pueden llevar 10 años con un sistema de ayuda para Visual Studio que simplemente no funciona (por poner un ejemplo evidente)? ¿Es que no ven lo evidente?

Así que se me quitan las ganas cuando encima tengo pocas. La opción fácil es mandarlo todo a tomar por culo. Sin más… Pero no, de nuevo esa es la salida fácil. No hablo del MVP, al final eso me da igual. Si he perdido el interés la culpa es de Microsoft. Simplemente que se jodan.

Hablo de mandarlo TODO a tomar por culo. Es una opción. No la mejor pero una de ellas.

***

Hay otras. La cacharrería de Apple me mola. El Magic Mouse es… mágico. El Trackpad ya ni os digo. El teclado extendido en el centro. A la izquierda la tableta. A la derecha el ratón. Enfrente hacia la derecha el iMAC, a su izquierda el monitor secundario. Mola.

Detrás del iMAC, un Book Studio Edition II for MAC de 2TB en RAID 0, recientemente adquirido, conectado al iMAC por FireWire 800. Conectado al PC por eSata va más rápido, pero yo lo quiero en mi MAC.

El iTunes no hace cosas raras cuando actualiza mi iPad o mi iPod. El iMac no hace ruido alguno. Se suspende solo (bueno, el PC también, pero el iMAC lo hace con más estilo. :-P). Y la pantalla es acojonantemente buena. El monitor secundario tampoco está mal, es un BENQ que tiene entradas para todo y en su momento costó casi lo que se me debe...

Alfred, Snap. CleanMyMac, BetterZip, VideoLAN, Transmission, Speed Download 5, Calibre. Mola. El Fusion para abrir una máquina virtual Windows de tarde en tarde. Ahora ya no cometo el error de usar Windows virtualizado. Si me hace falta algo que requiera rendimiento enciendo el PC y lo controlo por escritorio remoto. El sempiterno Office (Versión 2011), a la espera de que salga Pages 11…

No me hace falta nada más.

Bueno, sí, un iMAC algo más rápido y con más RAM, pero con el añadido del Book Studio de momento me sobra. Esperemos a la próxima actualización de los iMAC (los expertos dicen que para junio o julio), aunque un i7 con 8GB de los actuales tampoco estaría mal. 27” de monitor. Qué gozada.

Vendo mi PC recién comprado. Y mi Touchsmart TM2 con algo más de un año.

Xcode 4, en este momento compilando QT 4.7.2, aunque no creo que lo use. Un montón de PDF para leer en el iPAD en relación a Cocoa, Xcode y desarrollo MAC. Mola. Mola mazo. J

El iPad no tiene sistema de ficheros, pero me la trae al pairo. Mi mayor preocupación a la hora de leer un PDF es si hacerlo en el GoodReader o en el iAnnotatePDF. Mi mayor preocupación a la hora de leer un EPUB o un MOBI es si hacerlo en el iPod o en el iPad, y luego en qué aplicación (tengo para elegir. Las que más me gustan son el iBooks, el Kindle for iPad/iPhone, el Stanza o el i2reader).

Si quiero meter un fichero al iPAD, lo enchufo al MAC, lo paso a la aplicación correspondiente y a otra cosa mariposa. Sí, ya sé, se puede hacer igual desde Windows. Pero solo cuando el iTunes quiere (no entro si es a propósito o no). Las copias de seguridad del i<Cosa> me tardan un montón en Windows. En MAC son rapidísimas.

No hay multitarea real. No me hace falta. El GoodReader habla con las otras aplicaciones compatibles. Y el MobileRSS, y el NewsRack, y el Instapaper. Y el Dropbox.

Mola.

Mola mazo.

Y tengo un nuevo reto: aprender a programar en MAC. Y eso a mi jefe no le sirve para nada. Lo mismo hasta vendo alguna aplicación en la tienda…

Mola.

Mola mazo.

El RFOG se renueva, por dentro y por fuera

Rafael Ontivero — Thu, 02 Dec 2010 20:40:45 GMT

Sí, pese a lo que dijo sobre su MAC, al final se ha comprado un PC que sin ser lo último de lo último, tiene su cosa. El MAC está bien, pero le echa a faltar muchas cosas, muchos programas y otros temas, así que, al final, en lugar de comprarse un MAC PRO, se ha decidido por un clónico.

Si os preguntáis qué le ha pasado con su ordenador viejo, no lo hagáis directamente a él, porque va a coger un cabreo de cojones y posiblemente os deje con la palabra en la boca… si no os suelta alguna fresca.

Básicamente su QUAD con 8 GB de RAM se ha quedado en la empresa. Para evitar jaleos y tener la fiesta en paz, ha decidido que no vale la pena batallar por cosa tan nimia (Si no lo sabíais, el RFOG ha pasado, por ordeno y mando, de trabajar en su casa a tener que ir, todos los días, a una empresa, gastando por ello al menos hora u hora y media más de su vida por las mismas prestaciones económicas, y de hecho sigue preguntándose por qué no se ha ido sin más... Corramos un estúpido velo sobre el tema y dejemos la cosa como está.

Bueno, el nuevo ordenador del RFOG está compuesto por una placa Gigabyte (Modelo P55A-UD4) que tiene hasta tres chipsets para discos. Uno para el eSata, otro para los SATA II normales y un tercero para dos discos SATA III. Aparte la placa tiene FireWire 400. Ahí es nada, y también ahí es nada el tiempo que tarda toda la rutina del POST, de hecho más tiempo que el necesario para arrancar su Windows.

Esa placa ejecuta un Core i7 870 a 2.93 GHz que tiene cuatro núcleos dobles con HyperThreading, lo que suman 8. Y bien bonitos que se ven en el Administrador de Tareas. Y también, de momento, no les ha visto el culo, porque no suben del 40% total de tiempo de proceso.

La idea original era ponerle 16GB de RAM, pero al final sólo pudo disponer de 4 porque no le pudieron encontrar módulos de 4GB, aunque le han dicho que en cuanto los consigan lo avisan y se los cambian. De todos modos, 8GB ya son gigas para lo que el RFOG quiere.

La tarjeta de vídeo es una ATI HD6850. El rendimiento es tal que ni el StarCraft II ni el Civilization V a plena resolución hacen que la el ventilador de la misma se revolucione. Ahí es nada. De hecho, apenas nota que tiene algunas cosas con vmWare en modo Unity (que ya es decir).

Luego están los discos. Un SATA II de 1 TB normalito como disco de datos y de seguridad. Y cuatro discos SSD de 64GB en dos RAID 0. Sí, lo que oís, los discos valen más que el resto del ordenador.

Pero ¡chico!, cómo van. Y eso que no son de los más rapiditos que hay, que si no… El arranque de Windows hasta mostrar el escritorio es unos 10 segundos. La tasa de transferencia en copia entre las dos agrupaciones RAID es de unos 220-230 MB/s sostenida (unos 40 GB de una tacada).

A todo eso ha añadido a su ya existente monitor de 24”… otro más. Y como el primero tiene resolución de 1920x1200, el nuevo también la tiene (los modernos traen una de 1920x1080, quizás para poder bajar precios). Y el RFOG se pierde entre tanta pantalla.

***

Eso en cuanto al hardware. Respecto al software la cosa es algo más normal. El SATA II tiene dos particiones, en una de ellas está su trabajo y en la otra se mantienen las copias de seguridad de los otros dos conjuntos RAID, que el RFOG no se fía mucho ni de los SSD ni de los RAID. Relativamente amargas experiencias ha tenido con los últimos.

En uno de los RAID está Windows 7 x64 al completo con algunos programas más, entre ellos vmWare y Office. En el otro hay almacenadas varias máquinas virtuales, en donde se han instalado diferentes programas. En una de ellas está Visual Studio 2010, y en otra, Visual Studio 2008SP1 con los SDKs embebidos. Y así. Esas dos son Windows 7 Ultimate x86 con 3GB de RAMy 2 procesadores con 2 cores, y se pueden tener ambas abiertas sin mucha penalización de rendimiento (en su i7, claro, y más cuando tenga 16GB de RAM).

Y la idea es mantener limpio su HOST e ir intercambiando las máquinas virtuales según necesidad. Su nueva máquina lo da, y de momento la cosa está funcionando bien, con algunos detalles que está puliendo a ratos. Puede poner accesos directos a los programas en su barra de tareas como si una aplicación no virtualizada se tratara, y cuando la lanza primero se abre la máquina virtual en modo Unity y luego se lanza la aplicación.

El único problema es que Visual Studio no se lleva bien con los proyectos situados en carpetas de red, aunque sean compartidas a nivel de vmWare, así que ha metido todos sus proyectos en un disco duro virtual de Windows (VHD) y lo ha añadido a la configuración de la máquina virtual.

Un detalle del que se ha dado cuenta es que la máquina virtual, salvo el acceso a video, es sensiblemente más rápida que la real. Ignora si eso se debe a que es de 32 bits en lugar de 64, o a que al estar el disco comprimido sobre un SSD la rapidez es impresionante…

Evidentemente todo esto es a nivel particular. A nivel de curro la cosa sigue como antes. (Bueno, mucho peor, pero sigue haciendo proyectos interesantes, que quizás sea lo único que lo mantenga apegado a él).

***

Bueno, ya para finalizar, la idea original era hackintoshear la placa base (que se puede, es una de las que tienen el parche de la BIOS) para instalarse un Snow Leopard en nativo y virtualizar todos sus Windows, pero una vez que tuvo delante de sí el PC… se le quitaron las ganas de hacerlo. Es muy posible que en un arranque de aburrimiento lo intente, o que se instale una VM pirateada.

Ya veremos.

Las pifias de OS X (y de Office 2011)

Rafael Ontivero — Sat, 13 Nov 2010 20:47:45 GMT

Dado que el RFOG está últimamente bastante MACoso, y que criticar a los demás le levanta algo el ánimo, os va a contar hoy algunas aventuras con su iMAC, y como no sería justo criticar a unos y no a otros, ha decidido escribir un potpurrí de anécdotas y de paso explicaros cómo medio subsanar algunas de las carencias de OS X, que ciertamente algunas tiene, sobre todo comparándolo con Windows 7.

Para empezar os diré que, pese a gustarme mucho OS X, le veo ciertas durezas y rugosidades, y es que prefiero funcional a bonito. Será que soy diferente, pero si funciona, me da igual que sea feo, sobre todo si es bonito y no lo hace bien.

Y es el caso del Finder. Es completamente increíble que a fecha de hoy no exista ningún atajo de teclado para llamarlo desde cualquier sitio teniendo en cuenta que es el componente más usado de todo el MAC. Bueno, el más usado es el Spotlight, pero por las carencias del anterior, o al menos a veces se usa Spotlight porque no estamos al alcance del Finfer.

Eso, o a mi se me escapa algo, que todo pudiera ser.

***

Efectivamente, no existe atajo de teclado para lanzar el Finder desde cualquier sitio. O en otras palabras: no existe atajo de teclado equivalente al Win+E de Windows. Menos mal que podemos solucionarlo de aquella manera. No obstante, resulta tremendamente extraño que OS X no tenga dicho atajo… sabiendo que existe un shortcut para casi cualquier cosa (menos esa).

Veamos cómo solucionarlo. EL truco lo encontré aquí, pero no me funcionó hasta que lo arreglé. Para aquellos que no estén muy familiarizados con el uso del Automator (que digamos es un generador visual del equivalente de los ficheros .bat en MAC), sería conveniente que abrierais dicha página y la pusierais lado a lado con la mía, porque voy a traducir y expandir los puntos que allí se tratan y así aprovecháis las imágenes, que yo no tengo ganas de repetir.

1. Abrimos el Automator y elegimos un Servicio como flujo de trabajo. Digamos que un Servicio es una especie de programa disponible globalmente y que nada tiene que ver con los Servicios de Windows.

2. Después, en la ventana de la izquierda, elegimos “Utilidades” -> “Ejecutar AppleScript”. Y lo soltamos sobre la zona de la derecha, quedando algo similar a la imagen de la otra Web.

3. Ahora borramos ese texto y pegamos el nuestro. Para facilitaros la tarea, copiad y pegad al completo esto:

on run {input, parameters}

tell application "Finder"

activate

make new Finder window to home

end tell

return input

end run

4. Dadle al icono de ejecutar. Se debe abrir una ventana del Finder. Si no lo hace revisad el texto. Si os fijáis, el script es auto descriptivo, o casi: “le decimos al Finder que se active y que cree una nueva ventana en Home. Tenéis que guardar el script y darle un nombre que recordéis. Poned, por ejemplo: “EjecutaFinder”. Ya está, ya podemos cerrar el Automator.

5. Ahora nos vamos a Sistema -> Preferencias -> Teclado -> Funciones rápidas de teclado y nos colocamos en “Aplicaciones” en el listado de la izquierda. Luego pulsamos el “+” que hay debajo y se nos abre la ventana del punto 5 de la otra Web.

6. Introducimos el nombre que le dimos al servicio (“EjecutaFinder”) en el campo de Título del Menú, asegurándonos de que en Aplicación aparece “Todas las aplicaciones”. Y finalmente, seleccionamos “Función rápida de teclado” y apretamos la combinación de teclas con la que queramos lanzar el servicio. Yo he apretado ALT+CMD+F.

7. Ya está, ya hemos terminado. Al cerrar las opciones de teclado debería activarse y cada vez que apretemos dicha combinación, debería aparecer una ventana del Finder.

Pero no lo hace porque se nos ha olvidado una cosa. Volvemos a abrir el servicio en el Automator y arriba del todo, justo encima de “Ejecutar AppleScript”, tenemos que cambiar los dos desplegables y poner “El servicio recibe sin datos de entrada en cualquier aplicación”. Grabamos y ya está, ahora sí que funciona bien.

***

Vale. ¿Cuál es el problema? Pues que tarda como diez segundos a aparecer la ventana del Finder. Al menos en mi Core2Duo con 4GB de RAM, y todavía tarda más si tengo activa la máquina virtual con Windows para poder ejecutar lo que no se puede en OS X, como el servidor NNTP para las comunidades de Microsoft.

La respuesta es que nos jodemos y punto. Es lo que hay. Carencia de MAC solucionada a trancas y barrancas.

Sí, ya sé, podemos abrir la carpeta o el fichero que queramos desde Spotlight, pero no es lo mismo y el tiempo que se tarda es más o menos el mismo si no más.

***

Otras carencias del OS X: no existe el concepto de “ir al final de la línea”. Y no veáis lo que me jode, porque en Windows es algo a lo que estoy más que acostumbrado. Tampoco existe el concepto de “saltar palabra” (Ctrl+Flecha en Windows).

Dos problemas a los que no he encontrado solución y que me traen por la calle de la amargura y hacen que mi rendimiento en OS X caiga en picado. Primero porque le doy a la tecla de fin y me salta al final del documento, y tengo que volver con el teclado, o peor todavía: armo un desbarajuste de cuidado.

Menos mal que las aplicaciones de Microsoft (léase Office) sí que aplican el concepto a sus productos. O no tan menos mal, porque entonces el lío está armado.

Me refiero a que cada vez es más automático: si estoy en el curro bajo Windows, uso los atajos de Windows. Si estoy en casa usando MAC, uso los de MAC… Pero con el Office me lío, y no poco.

En fin, a sanjoderse, de nuevo, tocan.

***

Más.

La última actualización de Office hace algo raro porque cada vez que reinicio el MAC me coloca unos ficheros recuperados en la papelera. Es algo que le ocurre a todo el mundo y está más o menos documentado, buscad “wkresources” y veréis. Esperemos que Microsoft lo solucione en breve, pero vaticino un “NOT REPRO” en los informes de Bugs… o un NEXT VERSION o un NOT TO BE SOLVED… Deseo ardientemente equivocarme.

Además, si reinicias con el Word abierto tras haber editado y cerrado ficheros, también te recupera morralla de ellos.

***

Todavía más.

No veais lo que me jode, pero en profundidad, que en MAC no exista el concepto de “ir al siguiente mensaje sin leer”. Y encima que Outlook le siga a pies juntillas.

¿A qué superlumbreras se le habrá ocurrido que a la gente no iba a interesarle, no un atajo de teclado para saltar entre mensajes sin leer, sino ni que ni siquiera exista el concepto de tal cosa? Perdonadme la expresión: es de imbéciles.

Tenemos las carpetas inteligentes, y podemos crearnos una (o varias) en las que nos aparezcan los mensajes sin leer, pero sueltos y fuera de concepto, y en Outook no nos marca que hay nuevos sin leer.

En fin, otra cagada más.

***

Y ya para finalizar, la última de la última.

¿Cómo cojones se escribe el símbolo de HOME, la tilde esa horizontal? Y ya de paso, ¿cómo puñetas se escriben los símbolos especiales que con Windows es Alt-número?

***

Pues eso, que si sabes alguna respuesta a lo que pongo, escribe un comentario. Todas son preguntas a cosas que no he podido encontrar ni en Internet ni en los libros sesudos sobre Snow Leopard que he podido consultar…

Os garantizo un profundo agradecimiento por mi parte y seguro que de muchos otros.

Addenda. Después de tener escrita la entrada e intentar publicarla, no he podido hacerlo desde MAC. Suelo escribirlas en Office para MAC, y luego las guardo en HTML. Finalmente veo el código fuente, lo copio, me voy al IE virtualizado, pego como HTML limpiando alguna morralla y entonces la entrada sale bien.

Pues en este caso ni así. Y no sé por qué. Bueno, sí que lo sé: la *** mierda de interoperabilidad entre Windows/MAC. Al final he instalado el Word en la máquina virtual, he abierto el DOCX en dicho Word, copiado/pegado sobre Live Writer… y por fin ha salido bien.

No obstante, para tener un Windows dentro de un MAC… lo tengo fuera y punto.

Timers, alarmas y el iPhone

Rafael Ontivero — Sun, 07 Nov 2010 12:32:36 GMT

Con esta entrada vamos a matar tres pájaros de un tiro y evitar que dios, en su infinita sabiduría, mate más gatitos. Porque sí, porque cada vez que falla la alama de un iPhone o un iPod, dios se carga uno. Pero antes de llegar al meollo de la cuestión tenemos que ver otras cosas. Aprovecharé para contaros cómo funcionan los timers en un microprocesador (el primer ave defenestrada), os explicaré el concepto para construir una aplicación que sea un reloj con alarma (el segundo pajarraco) y dejaremos una pregunta en el aire para mofa y escarnio de la gente del iOs.

Todos hemos oído hablar de la frecuencia a la que funciona un microprocesador. Los, primero megaherzios, y luego gigahercios. Y no oiremos hablar de los terahercios porque están en el rango de los efectos cuánticos y no nos valen para mover un microprocesador… (Chiste para físicos cuánticos: tengo un ordenador a 3 terahercios pero nunca estoy seguro de dónde está).

Ese reloj genera una serie de pulsos (parecidos a los que aparecen en un cardiograma pero más regulares) y son para el procesador y aledaños como nuestro corazón. O como un mecanismo de cuerda, que hace girar los engranajes. Imaginaros la rueda de escape de un reloj. Pues el funcionamiento interno de un procesador es igual: ante cada punto de escape (que en informática se llama ciclo máquina) las ruedas de engranajes se van moviendo poco a poco y al final vemos cómo la aguja del segundero va trazando su arco.

Si nos da por mirar una placa base en detalle, no vamos a ver un reloj de los gigahercios que se supone tiene nuestro equipo. Con suerte veremos uno de 40 o 60 MHz. Lo demás se realiza dentro de chips especiales que dividen esa frecuencia en otras mayores mediante electrónica. Y más dentro del micro, ya que muchas partes dentro de él no necesitan tanta velocidad y a veces es contraproducente, como veremos.

Uno de los elementos que comparten absolutamente todos los microprocesadores son los timers, nombre con el que suelen conocerse en la literatura técnica. El mínimo es uno, el máximo viene determinado por el tipo y destino del microprocesador, más todavía en los microcontroladores. Existen dos modos generales de funcionamiento. A veces ambos están presentes, a veces un mismo timer se puede comportar de las dos formas, y a veces sólo hay de un tipo.

En uno de ellos tenemos acceso a un contador que se va incrementando periódicamente y que nosotros podemos leer para comparar con nuestro valor. En el otro, llegado a un punto (generalmente cero), se dispara una interrupción.

Es decir, cuando nosotros queremos activar un timer, lo que hacemos es escribir en una serie de registros del microprocesador para configurarlo. Decimos registros pero lo habitual son direcciones de memoria que están mapeadas dentro del procesador. Si os acordáis de otra entrada, nosotros escribimos en una dirección del procesador y las patillas del mismo cambian de estado. Pues ahora es lo mismo, pero en lugar de subir o bajar la tensión de una de ellas, configuramos el timer.

O en otras palabras: conectamos una serie de ruedas de engranajes que estaban detenidas, ruedas que nos permitirán tener un evento periódico, ya sea un contador que se vaya incrementando solo o una interrupicón que se lanzará con cierta frecuencia.

Pero hay un problema. En un procesador de 8 bits, los registros serán, a lo sumo, de 16 bits. En uno de 16, de 32. En uno de 64 lo habitual es que sean de 64 bits, no de 128. Para ponerlo en marcha o detenerlo sólo necesitamos un bit, pero para programar el prescaler, cuantos más bits tengamos, mejor.

Suponiendo que tenemos un registro de 16 bits, tendremos 65536 posibles valores respecto a la base de tiempos. Por decirlo de otro modo, si en ese registro ponemos el valor de 10, el procesador hará la acción (ya sea incrementar otro registro o generar una interrupción) cada vez que ese valor llegue a cero. Si tenemos una base de tiempos de 1 ns, nuestro timer será de 10 ns. Si ponemos un valor de 50000, entonces tendremos un tick cada 50 us (microsegundos).

Si os fijais, en esta situación, nuestro valor más alto será de un poco más de 65 microsegundos. Esta es la limitación de la que hablábamos antes. Algunos fabricantes lo solucionan ofreciendo DOS registros para programar el timer, o que cada salto de 1 en en ese registro sea de 10 en la base de tiempos, o ambas cosas, e incluso tendremos dentro de un mismo microprocesador varios tipos de timers.

Al final, el tema está en que lo habitual es que no podamos tener ticks mayores de unos cientos de milisegundos lo que para los programas puede ser un tiempo excesivamente largo, pero para un reloj normal son demasiado cortos.

En ambos casos la limitación es la misma: tanto la interrupción como el contador interno del microprocesador se van a disparar demasiado rápido para lo que queremos. No he dicho que en el caso del incremento de la variable, normalmente es otro registro del procesador el que se va incrementado (o decrementando), y cuando decimos registro queremos decir dirección de memoria, que podremos leer y consultar. El mayor problema de este tipo de temporizadores está en que cuando la variable llega a su mínimo o su máximo, o bien vuelve a empezar o bien el timer se detiene. Y si no lo consultamos con la frecuencia suficiente, no sabremos que se ha detenido y habremos perdido nuestra base de tiempos.

Si os acordáis, hubo en Windows 95 un fallo que hacía que el ordenador se colgara si estaba más de unos días sin reiniciar. El problema era este mismo: Windows tenía un contador interno que se iba incrementando y cuando llegaba al máximo, volvía a empezar por cero. Y entonces todo se iba al garete porque lo que quiera que lo usara para su funcionamiento esperaba un incremento, no un decremento del orden de 2³⁰ ó 2³¹.

Incidentalmente el problema tiene solución, y encima no es compleja en exceso pero sí que necesita código y saber la frecuencia media de consulta al timer, solución que debe ser compartida entre el timer y la parte que lo consulta. De hecho existen TRES soluciones. Os lo dejo como ejercicio de clase.

Por lo tanto yo no suelo recomendar el uso de este tipo de timers, aunque a veces es inevitable, y entonces es obligatorio evaluar si se puede producir dicho desbordamiento, o al menos es lo que hacen los buenos programadores. De todos modos, al final, veremos que es muy posible que siempre nos pueda ocurrir. Y no, incidentalmente, no creo que sea este el problema con los iPhone.

***

Bueno, ahora que sabemos qué es un timer y cómo funciona, vamos a construir un ejemplo práctio… en C.

//Este es el contador global de nuestro timer.

int g_timerCntr=0;

//Esto se debe llamar una sola vez al principio de todo

//Configura y pone los registros adecuados para que nuestro

//timer sea de 1 ms.

void InstallItmer(void)

{

//Configurar los registros

//...

}

//Arranca el timer con un intervalo

void SetTimer(int interval)

{

g_timerCntr=interval;

//Arrancar el timer

}

//Devuelve "cierto" si el timer ha terminado.

int HasEnded(void)

{

return g_timerCntr==0;

}

//La interrupción que se lanzará periódicamente.

//Aquí el linker deberá poner su dirección en el lugar adecuado.

INTERRUPT_TIMER TimerInterrupt(void)

{

g_timerCntr--;

if(g_timerCntr==0)

; //Detener el timer

else

;//Recargar el timer

}

La llamada a InstallTimer() debe hacerse al arranque del procesador, o al menos antes de que vayamos a usarlo por primera vez. Lo que hace esta función es configurar los registros según lo hemos explicado, de modo que, en base a la frecuencia de trabajo del procesador, más los registros adecuados, se nos dispare una interrupción cada milisegundo (en nuestro ejemplo). Pero no lo pone en marcha, simplemente lo configura.

TimerInterrupt() es la interrupción que nos saltará cada vez que transcurra un milisegundo. Fijaros que decrementamos en una unidad una variable local y que si llega a cero, detenemos el timer y si no lo recargamos. Esto es un ejemplo, porque a veces no será necesario recargarlo, es decir, el procesador disparará la interrupción cada 1 ms, otras veces lo hará sólo una vez y se detendrá, todo depende del modelo y características de casa procesador y del timer que estemos usando.

Aquí, con INTERRUPT_TIMER he ejemplificado el hecho de que debemos indicarle al compilador y al enlazador que dicha función es una interrupción y que debe ser instalada en el lugar adecuado. De nuevo estamos ante las particularidades de cada compilador y enlazador, aunque cuanto más moderno sea, más fácil nos lo pondrá.

Básicamente, una interrupción está localizada en una dirección de memoria exacta, y es ahí dónde se debe poner la dirección en la que está la rutina a modo de puntero a función: cuando se dispare el timer, el hardware del micro hará un call a lo que quiera que esté apuntando esa dirección. Si hay código bueno se ejecutará. Si no, lo habitual es que se cuelgue, aunque a veces también se puede producir una excepción hardware que nos permitirá resumir, de algún modo, el funcionamiento. Además, en algunos microprocesadores la instrucción de retorno de función (ret, para entendernos) será alguna instrucción especial como iret, retorno de interrupción. De nuevo estamos ante el hecho de que hay tantas variaciones como familias y fabricantes de electrónica.

Bueno, la parte difícil ya está. La fácil son las dos funciones que nos quedan. SetTimer() asignará un valor a la variable global y HasEndend() nos devolverá cierto cuando el contador haya llegado a cero. Si, por ejemplo, pasamos 1000 a SetTimer(), habremos obtenido un metrónomo de 1 segundo. Terminar nuestro reloj es casi trivial:

int _tmain(int argc, _TCHAR* argv[])

{

int segundo=0, minuto=0, hora=0;

InstallTimer();

for(;;)

{

//NOTA: Con esto simulamos la interrupción

if(g_timerCntr!=0)

TimerInterrupt();

//FIN DE NOTA

if(HasEnded())

{

SetTimer(1000);

segundo++;

if(segundo>=60)

{

minuto++;

segundo-=60;

}

if(minuto>=60)

{

hora++;

minuto-=60;

}

return 0;

}

¿Lo veis, no? Lo único a destacar en el ejemplo es que hemos puesto la interrupción en nuestro bucle for (para evitar que el autor tenga que crear un thread para el timer o suscribirse a uno de windows, etc). Obviando eso, tenemos un reloj en nuestro PC que ejemplifica cómo podríamos construir uno si TimerInterrupt() realmente se disparara cada milisegundo.

Copiaros el código a un proyecto de C++ de consola de Visual C++, definid

#define INTERRUPT_TIMER void

Al principio de todo, y os debe funcionar.

Añadir alarmas es relativamente fácil. Deberíamos tener una lista de variables hora, minuto y segundo y, en el bucle, comprobar si la hora actual es igual o superior a la programada, y si lo es, lanzar el sonido.

***

Bueno, ya tenemos nuestro reloj. Bonito, ¿no? Pues NO. Ese programa es una mierda de programa, y desde luego no creo que esté hecho así en iOS, y si lo está sería para matarlos lentamente (aunque el tipo de problema que tiene me hace pensar que…). Ese programa nos sube la CPU al 100% y en un dispositivo con batería se la iba a chupar en un tris.

No, la solución es algo más compleja, y pasa por mover bastantes cosas a la interrupción. Algo así:

//Este es el contador global de nuestro timer, y los datos

//Para mantener el reloj.

int g_timerCntr=0;

int hora=0,minuto=0,segundo=0;

//La interrupción que se lanzará periódicamente.

//Aquí el linker deberá poner su dirección en el lugar adecuado.

INTERRUPT_TIMER TimerInterrupt(void)

{

g_timerCntr--;

if(HasEnded())

{

SetTimer(1000);

segundo++;

if(segundo>=60)

{

minuto++;

segundo-=60;

}

if(minuto>=60)

{

hora++;

minuto-=60;

}

//Recargar el timer

}

int _tmain(int argc, _TCHAR* argv[])

{

InstallTimer();

Sleep(INFINITE);

return 0;

}

Este ejemplo ya no nos va a funcionar en el PC, pero gasta un montón menos de batería y nos deja la CPU al 0% o casi. Ahora sí que tenemos un reloj de verdad, optimizado al 100%. Y ahora es cuando entra el tío de la rebaja: tenemos que medir (con un sistema de traza, por ejemplo), cuánto tiempo tarda la ejecución del bloque que hay dentro del primer if, y si es superior al milisegundo, debemos anotarlo y corregir el contador para evitar que nuestro reloj atrase. También debemos comprobar si la interrupción es reentrante (en el caso de que no haya acabado y si llega el momento de volver a ejecutarla, el procesador lo hará o no) y actuar en consecuencia. De todos modos, por el código usado, os aseguro que se tarda menos de 1 ms a hacer todo lo que hay dentro del if.

¿De dónde viene el ahorro de energía? Es muy sencillo: si os fijás en este último caso, sólo se ejecuta código cuando es estrictamente necesario, y cuando no el programa está durmiendo sin hacer nada. En el caso anterior el programa estaba continuamente comprobando si el timer había llegado a cero o no, de continuo, usando el 100% de la CPU.

Una solución intermedia al primer programa podría haber sido poner un else y dormir el programa durante 1 ms, pero aun así sigue siendo bastante inefectivo (y en Windows esa dormida será de, al menos, 15 ms).

***

Ya, ahora sí, ahora ya está todo perfecto… ¡NO! ¡Ni mucho menos! Lo de arriba sigue siendo una enorme pérdida de tiempo, un absurdo sólo válido como explicación teórica y poco más. ¿Realmente necesitamos tres variables para el reloj? Pues no, esas tres variables sólo son necesarias para cuando tengamos que verlas los seres humanos, por lo tanto debemos plantearnos la pregunta de qué precisión necesitamos. ¿1 segundo? Pues hagamos lo siguiente:

//Este es el contador global de nuestro timer, y los datos

//Para mantener el reloj.

int g_timerCntr=0;

unsigned long g_hora=0;

//La interrupción que se lanzará periódicamente.

//Aquí el linker deberá poner su dirección en el lugar adecuado.

INTERRUPT_TIMER TimerInterrupt(void)

{

g_timerCntr--;

if((g_timerCntr%1000)==0)

g_hora++;

//Recargar el timer

}

void MuestraHoraActual(void)

{

int hora, min,seg;

hora=g_hora/3600;

min=g_hora/60;

seg-=(hora*3600+min*60);

printf("%02d:%02d:%d2d",hora,min,seg);

}

Fijaros en la interrupción, reducida a la mínima expresión a costa de crearnos una función de muestra de hora algo más compleja (que no estoy seguro si funcionará bien o no, pero sin lo hace pocas diferencias tiene que haber con la correcta). A simple vista hemos perdido, pero realmente hemos ganado, y no poco. ¿Qué relación hay entre las veces que vemos el reloj y las que se ejecuta la interrupción? Pues prácticamente infinitas.

Ahora me diréis que el iPhone muestra la hora arriba del todo. Sí, pero en minutos. Es decir, que podemos reducir incluso el contador de la interrupción a minutos en lugar de segundos. Y entonces añadimos el truco del almendruco, que es un flag para indicar a la shell que debe actualizar el reloj. Algo así:

INTERRUPT_TIMER TimerInterrupt(void)

{

g_timerCntr--;

if((g_timerCntr%1000)==0)

g_hora++;

if((g_hora)%60==0)

g_flagCambiaMinuto=1;

//Recargar el timer

}

Y será tarea de la interfaz del iPhone la de pintar cada vez que cambie el minuto.

Este acercamiento para el aviso de cambio de minuto es muy burdo. Lo que yo haría es tener llamar a un callback que me repinte la hora si el iPhone no está a pantalla completa y si eso no se puede hacer (que no se podrá, porque pintar en pantalla desde una interrupción como que es chapucero y a veces simplemente el hardware no lo permite), ese callback invalidaría el rectánculo de pintado y entonces el controlador de pintado, al recibir dicha invalidación, repintaría el área… con la nueva hora.

Fijaros cómo una tarea en principio simple tiene más miga de la que parece, sobre todo si quieres hacer las cosas bien. De hecho no sé cómo lo está haciendo Apple (y de paso Microsoft) con el tema de las horas, pero si yo tuviera que hacer algo así esa sería MI forma.

***

Ya está, ya terminamos. ¿Cómo podríamos añadir alarmas (y que suenen) al último ejemplo? La solución más sencilla es tener un array de variables del mismo tipo que g_hora. El tamaño podría ser dinámico con una lista enlazada, o un array estático con, pongamos, 16 variables que nos permitirian tener un máximo de 16 alarmas diferentes. Eso ya depende de la implementación. Esta sería la nueva interrupción, ya definitiva:

#define NUM_ALARMAS 16

unsigned long g_alarmas[NUM_ALARMAS];

INTERRUPT_TIMER TimerInterrupt(void)

{

g_timerCntr--;

if((g_timerCntr%1000)==0)

g_hora++;

for(int i=0;i<NUM_ALARMAS;i++)

if(g_alarmas[i]!=0 && g_alarmas[i]<g_hora)

PreparaAvisoAlarma(i);

if((g_hora)%60==0)

g_flagCambiaMinuto=1;

//Recargar el timer

}

Fijaros qué código más minimalista y completo: tenemos alarmas, tenemos reloj en tiempo real, actualización de la hora en el escritorio con apenas unas líneas y que apenas consumen una miseria de energía y tiempo de proceso.

Cuando g_alarmas[i] vale cero, es que esa alarma está desactivada, y si no vale cero y su valor es inferior a la hora actual, es que debe sonar. De nuevo PreparaAvisoAlarma() debe ser una función mínima que simplemente indique al sistema que la alarma debe tocar, ya sea despertando un hilo dormido o activando cualquier flag que luego alguien leerá y actuará en consecuencia.

Luego, la tarea del programa de interfaz con el usuario que le permita añadir, quitar o modificar alarmas, será la de “tocar” dichas variables a gusto del consumidor.

¿Cuál es, pues el fallo del iPhone? Pues que ante el cambio de hora, al programador de turno se le olvidó actualizar también ese array de alarmas (o su equivalente), con lo que ellas tienen el valor antiguo y sonarán cuando el valor de disparo antiguo se corresponda con el nuevo…

Peeeeeeeeeeeeeeeeeeeero, hay un gran pero, y aquí es donde vienen las risas. En mi caso, ninguna solución propuesta funciona. Ni en mi flamante iPhone 4G, ni en mi iPod Touch 2G. Ni por cierto en el de mi jefe, lo que supuso una seria discusión sobre lo inútil que era (yo) y que antes de hablar debería asegurarme de que la culpa es mía y no de los demás, como siempre hago (palabras textuales), a lo que yo le dije que probáramos el tema… Cuando vio que ni en el mío ni en el suyo funcionaban… se fue a recoger el correo (en fin, que la cosa se va acercando a su final lógico…).

La solución que me funciona es poner una alarma y activarla para TODOS LOS DÍAS de la semana, de lunes a domingo. Si no se hace así suena una hora más tarde, aunque sean alarmas antiguas o recién creadas, o apagues y reinicies el iPhone, o incluso lo restaures desde la copia de seguridad: falla.

Por lo tanto, alguna chapuza remiendosa debe de haber dentro del software del iPhone, porque, como os he demostrado, tener alarmas en un dispositivo como el que hablamos es, a nivel de desarrollo, completamente trivial, y si regenerarlas desde cero no funciona…

[NOTA: El código de ejemplo, salvo la primera parte, no está probado, así que lo mismo puede haber algún gazapo si a alguien se le ocurriera probarlo].