Emilcar

Etiqueta: experimento128

  • Experimento 128: sobreviviré

    Pues he terminado. Ya os he relatado aquí todo lo que he tenido que hacer para adaptarme a tener un MacBook Pro 13′ con un SSD de 113 GB como único ordenador. La mayor pega que le he encontrado al asunto no ha sido precisamente el tamaño del disco sino la potencia de este equipo, que si bien no está nada mal (Core 2 Duo 2,26 GHz), dista lo justo de mi iMac anterior como para que se me atranque en determinadas circunstancias.

    Sufro viendo como mi batería sufre. Antes la cargaba si acaso una vez o dos por semana y ahora es una vez o dos por día. Aunque los MacBook Pro actuales llegan a 7 horas de autonomía, éste «sólo» tiene 3 y al cabo del día requiere repostar, máxime cuando aun no estando usándolo, es el equipo que sirve contenido a nuestro Apple TV.

    La veleta del rumor dice hoy que no habrán nuevos iMacs ni Macs mini junto con Mountain Lion el día 25. Aunque salieran, no iba a comprar un iMac el 25 de julio para aparcarlo un mes, así que ya tenía claro que agosto era para el MacBook Pro 13′. Si este rumor se confirma, seguramente también tendré que pasar septiembre usándolo como único ordenador y quien sabe si más.

    Aunque estoy disfrutando mucho de las ventajas que supone tener un único equipo, os aseguro que voy a coger mi nuevo iMac con muchas ganas 😉

  • Emilcar 128: dos pantallas con Swiss Arrows

    Desde un mes antes de desprenderme de mi iMac 24′, tenía ya en casa un monitor secundario, un Acer S192HQL de 18’5 pulgadas que me costó 69 € y que tiene una calidad equivalente a su precio. Para mover las ventanas en la pantalla de mi iMac yo ya usaba la app Double Pane, y pensé que con la configuración de dos pantallas le sacaría partido por fin a los 2,39 € que me costó. No llegué a hacerlo.

    Antes siquiera de sacar mi monitor nuevo de su caja, recibí un email del desarrollador de Swiss Arrows, una aplicación para el manejo de ventanas en OS X, competencia pues de Double Pane. Tras mirar el vídeo de demostración le pregunté directamente: «¿Por qué un usuario satisfecho de Double Pane debería comprar Swiss Arrows?». Él me contestó lo siguiente:

    – Precio 2,39 frente a 0,79 de Swiss Arrows

    – La ventana a modo de panel HUD de Swiss Arrows está a prueba de usuarios muy muy básicos «alérgicos» a menús o teclas rápidas (p.e mi madre y mi suegro que tiene ambos un imac).

    – Permite capturar tus propios estado de ventana personalizados (la posición y tamaño que sea de una ventana) para reutilizarlos después. En el video puedes ver un ejemplo de uso con safari y la twitter app de mac. Según parece esto no lo hace DoublePane.

    – Estos estados de ventana personalizados se pueden importar de, por ejemplo, un iMac a un MacBook Air sin importar que tengan distinta resolución o trabajen con más de un monitor porque los tamaños capturados y después aplicados a las ventanas son proporcionales a cada pantalla. En alguna versión futura quizás añada que se sincronicen directamente por iCloud (como me ha indicado hoy Pedro Santamaría de Applesfera).

    – En las preferencias además puedes mostrar/ocultar los botones del panel HUD y activar/desactivar teclas rápidas por grupos: principales, estados de ventana por defecto, personalizados y múltiples monitores. Por ejemplo para los estados por defecto yo utilizo las teclas rápidas pero para mis estados personalizados uso el panel HUD (que no recuerdo de memoria cada uno y así veo el texto que puse al capturar) y para las acciones para múltiples monitores como uso un iMac sin monitores adicionales he desactivado/ocultado todo.

    Resumiendo, tanto a alguien que ya tenga una app para gestión de ventanas como si no, le diría que Swiss Arrows ofrece bastantes posibilidades por menos de lo que vale un café. Todo es cuestión de que cada uno valore sus necesidades y si le sacaría partido…

    Sinceramente creo que no se puede describir mejor las ventajas de esta aplicación desde mi punto de vista completamente imprescindible y más por 0,79 €.

    Todo esto viene a cuenta del Experimento 128 porque he decidido cambiar mi configuración de escritorio. Hasta ahora usaba el portátil como pantalla principal, usando también su teclado y trackpad, y el monitor Acer como pantalla secundaria. Pero es verano, amigos, y vivo en Murcia, así que hoy, harto de quemarme las yemas de los dedos, he decidido usar la misma configuración que he visto en tantas fotos, esto es, el Acer como monitor principal, un teclado y trackpad aparte, y el portátil subido a un soporte como monitor secundario y CPU del sistema.

    Con esta configuración mejoro la temperatura media de mis dedos y tengo un monitor principal más grande, pero de bastante menos calidad que el panel que monta Apple en mi MacBook Pro 13′; nada es perfecto, pero creo que así voy a esperar mejor a mi anhelado iMac.

    Si bien Swiss Arrows se había convertido en una aplicación muy útil con mi iMac, ahora es sin duda imprescindible en mi actual configuración. Por obra y gracia de su desarrollador, vamos a regalar 5 códigos promocionales para los primeros cinco lectores que escriban un comentario añadiendo un enlace a una foto de su configuración de escritorio con dos o más monitores.

  • Experimento 128: iMovie

    Si bien resulta relativamente fácil llevar la biblioteca de iTunes a un disco externo (USB o NAS), hemos visto sin embargo que hacer lo propio con Aperture tiene sus particularidades. iMovie también tiene algunas consideraciones previas al respecto que debemos tener en cuenta.

    iMovie es una aplicación especialmente ávida de espacio en disco duro. Esto se debe al formato propio de Apple al que iMovie convierte los vídeos para facilitar su edición. Ya usando el iMac, yo tenía muchos proyectos de iMovie pasados al NAS para que la copia de seguridad completa del disco duro local pudiera entrar en un disco duro de 500 GB.

    Me voy a ahorrar la explicación sobre cómo mover los eventos y proyectos de iMovie desde el disco duro del Mac a un disco externo, ya que un reciente screencast de Applesencia resuelve fantásticamente esta duda. Sin embargo sí quiero añadir la particularidad que se produce cuando ese disco externo es un NAS.

    iMovie es capaz de ver los discos duros externos que están en una ubicación de red. El problema es que en las diversas actualizaciones del programa y tras OS X Lion, esa característica ha sido activada y desactivada por Apple en varias ocasiones. Si estando en iMovie no veis las unidades de vuestro NAS, os tocará pasar por Terminal. Esto también ha sido explicado antes, por ejemplo en Applesfera.

    Una vez que iMovie reconoce vuestro NAS y que ya sabéis cómo mover eventos, pues toca moverlos. ¿El problema? Trabajar desde un NAS doméstico en iMovie es insufrible.

    La idea general sería tener todos los proyectos y eventos en el NAS y pasar al Mac aquel proyecto con el que estemos trabajando en el momento. El problema viene cuando ese proyecto y sus eventos ocupan tanto espacio en disco duro que no entran en mi raquítico SSD de 113 GB. En este caso, tengo que tirar de un disco duro USB, desde el cual es bastante más rápido trabajar vídeo que desde el NAS; no es la mayor velocidad del mundo pero es algo aceptable. Si el disco externo del que disponéis es FireWire o Thunderbolt entonces ya hablamos de lujo asiático.

    En mi caso, yo estoy usando un disco USB de 500 GB donde ya puesto he pasado varios proyectos y eventos que me gustaría terminar durante este mes de julio; ocupan unos 100 GB. Os preguntaréis ¿y por qué demonios ocupan TANTO los eventos de iMovie? Bueno, en los comentarios del screencast de Applesencia que he citado antes, su autor Marcos Matas, ofrece una magistral explicación al respecto que cito aquí:

    iMovie procesa todos los archivos en un formato propio de Apple, llamado AIC. Ese formato no es exactamente el habitual H264 que usan la mayoría de dispositivos de vídeo domésticos. El códec H264 en una película divide cada secuencia en fragmentos de 24 o 30 frames. El primer frame se guarda entero (con todos sus bits de datos), pero los 23 restantes se guardan como variaciones respecto al primer frame. Es decir: si hay una parte de un color cualquiera que no varía durante esos 24 frames, el códec simplemente dice “esto es lo mismo que en el fotograba anterior” y sólo da datos de las partes de los frames que sí han variado. Así se ahorra mucho espacio en el tamaño de la película.

    Todo esto está muy bien a la hora de ver una película, pero el problema se nos muestra cuando queremos hacer una edición en la mitad de esa secuencia de 24 frames. Si en el frame número 8 quiero hacer una modificación, el programa va a tener que usar muchísimos recursos del procesador para llevarla a cabo, y en muchos casos no podremos ver la edición en tiempo real para ver cómo va quedando nuestro proyecto.

    Por eso cada vez que importamos una película a iMovie la película se nos convierte a AIC. En este formato el vídeo tiene información de cada frame por separado (guarda absolutamente todos los bits de datos de cada frame y ninguno de esos frames se basa en lo que aparecía en un frame anterior). ¿Ventajas? que en cualquier momento podemos “cortar” y empezar a editar el vídeo. ¿Inconvenientes? Pues que ese vídeo va a ocupar más. Es inevitable.

    Podéis ver más screencasts de Marcos Matas en su canal de YouTube.

  • Experimento 128: Aperture

    Este artículo versa sobre lo que sin duda ha sido la joya de la corona de mi experimento: la deslocalización de la librería de Aperture.

    Mi librería de Aperture pesaba ni más ni menos que 100 GB. La copié a un disco externo USB y procedí a aplicar las recetas habituales para adelgazarla, esto es, borrado de miniaturas, borrado de previews y eliminación de algunos duplicados (buscados a mano) y de basura traída por Photostream. ¿Qué conseguí? Adelgazar hasta 56 GB, algo todavía insuficiente para el espacio real disponible en el disco SSD de mi MacBook Pro.

    Entonces empecé a leer sobre librerías referenciadas y a prestar atención a algunas opciones de Aperture por las que hasta la fecha ni me había preocupado. Básicamente, Aperture permite ubicar los originales de las fotos en una ubicación distinta a la librería. La opción se llama Relocate originals for project… y como podéis deducir se hace por proyectos; Aperture nos pregunta por una ubicación y sobre los nombres a dar tanto a la carpeta como a los archivos originales. Las fotos muestran entonces una indicación que indica que están referenciadas, que no están en el archivo de la librería.

    Con paciencia franciscana, fui relocalizando todos los proyectos, dejando en la librería de Aperture los proyectos en curso (que son unos cuantos) y todos los de 2012. ¿Tamaño actual de mi librería? 12,49 GB, perfecta para mi MacBook Pro. Asimismo, en mi NAS tengo una carpeta llamada Aperture Originals que ocupa 17 GB.

    Cuando no estoy conectado al NAS, Aperture no me da ninguna indicación de error. Incluso puedo seguir trabajando con las fotografías referenciadas en lo que a metadatos se refiere y, dado que las previews están en la librería de Aperture, todavía están disponibles para otras aplicaciones y para usarlas en pases de diapositivas y similares.

    Debo aclarar que dado que borré todas las previews, ahora mismo todavía están en proceso de regeneración, por lo que la cifra de 12,49 GB de mi actual librería de Aperture es más falsa que el beso de Judas 😉 No obstante, aunque finalizado el proceso mi librería se vaya a 20 o 25 GB, habré ganado muchísimo. A partir de ahora, cuando termine un proyecto, sacaré los originales al NAS y tan ricamente.

    Estoy tan contento de haber descubierto esto, que estoy 100% convencido de que incluso si al final compro un nuevo iMac seguiré usando este mismo sistema, porque una librería que pesa tan poco es una librería más fácil de manejar y más exenta del típico problema de las librerías: la corrupción de datos.

    Una propina. Desde las últimas versiones de iPhoto y Aperture, ambos programas pueden leer mutuamente sus librerías. iPhoto por sí mismo no es capaz de hacer todo esto, es decir, no permite sacar los originales fuera. Sin embargo ahora, cuando abre una librería de Aperture, sí es capaz de gestionar los archivos referenciados.

    Más cosas. Podemos seguir manteniendo ultradelgada nuestra librería de Aperture impidiendo la generación automática de previews.

    El proceso sería sencillo, primero borramos todas las previews existentes y a continuación desmarcamos la casilla que veis en la captura superior. La «pega» de esto es que perdemos automatización, es decir, tenemos que acordarnos de generar manualmente las previews de los proyectos que nos interesen porque si no, dichas fotos no podrán ser sincronizadas con nuestros dispositivos iOS ni estarán tampoco disponibles para el resto de aplicaciones del Mac como iMovie, iWeb o cualquiera susceptible de usarlas. Limitar el tamaño y la calidad de las previews también ayuda a mantener una librería de Aperture ligera; si yo no le he hecho es para aprovechar al máximo la Retina Display de mi nuevo iPad, que es de facto mi álbum de fotos.

    Esto de la deslocalización es un chollo y me siento como un switcher de primer año por no haberlo aprovechado desde el principio. Incluso se puede hacer desde el mismo momento de importación de las fotos, indicando a Aperture que no quieres añadir los originales a su librería sino que deseas que se guarden en tal ubicación.

    Pero además, Aperture es plenamente consciente de esto y las referencias no se pierden. Si, por ejemplo, decidís que vais a partir vuestra librería en varias librerías, una por año, en la exportación irán incluidas las referencias a la ubicación de los originales, o incluso en ese proceso podréis decidir copiar de nuevo los originales dentro de las librerías resultantes.

    Yo me pasé de iPhoto a Aperture por dos motivos: 1) tener más herramientas de retoque fotográfico para sacar más partido a los RAW de mi Canon 1000D 2) para aprovechar sus mayores capacidades de gestión de la librería. Si yo hasta ahora pensaba que apenas estaba aprovechando Aperture para lo primero, ahora además veo que estaba en mantillas respecto a lo segundo.

    Ahora mismo puedo irme con mi MacBook Pro sabiendo que llevo las fotos en las que estoy trabajando y que las demás me esperan plácidamente en mi NAS cuando vuelva a casa, todo ello de manera natural y sin «traumas». No tiene precio.

  • Experimento 128: iTunes

    Cuando este MacBook Pro 13′ era mi ordenador secundario, yo tenía en él configurada una librería de iTunes donde lo único que tenía era iTunes Match activado, de manera que tenía acceso a mi música en streaming siempre que la necesitara (y que tuviera conexión a Internet, claro).

    Este tipo de configuración es muy práctico para un portátil y no quería perderlo, pero siendo ahora este el único Mac en casa, recae sobre él la función de servir contenido a nuestro Apple TV 2 (al cual no voy a hacerle jailbreak, así que ahorraos el consejo).

    Por todo ello he decidido… dejarlo todo como estaba. Sigo teniendo la biblioteca de iTunes propia de este equipo, que se encuentra en el disco SSD pero que no ocupa nada, porque apenas tengo 10 pistas descargadas. Cuando estoy en casa y necesito que este ordenador sirva contenidos al Apple TV, inicio iTunes pulsando alt para que me permita elegir biblioteca, y entonces elijo la de mi antiguo iMac, que está entera en el NAS, no sólo los archivos multimedia, sino también los XLM y todos los archivos de la librería.

    Así tengo lo mejor de dos mundos sin renunciar a nada. Para mí iTunes Match ha sido la respuesta a mis plegarias en múltiples sentidos. No concibo ahora mismo la posibilidad de no renovar el servicio.

  • Experimento 128: sleepimage

    Hoy me he puesto manos a la obra. He cogido mi MacBook Pro 13′ y he empezado a limpiarlo de cosas inútiles para que esté en condiciones de encajar lo que se le viene encima. Para ello no conozco otra app como DaisyDisk. En breves minutos tenía un informe gráfico del estado de mi disco duro y de las carpetas y archivos que más ocupan.

    No he avanzado mucho, en la primera pantalla ya me ha llamado la atención que el subdirectorio private ocupara 9,5 GB. ¡A por él! Indagando hacia las entrañas de este subdirectorio DaisyDisk me dice que un archivo llamado sleepimage ocupa él solito 8,5 GB.

    OS X tiene un fantástico sistema de hibernación para portátiles que hace que cuando tu Mac se queda sin batería, todos los procesos abiertos en memoria se guarden, de manera que cuando vuelves a tener batería, el equipo se restaura en la misma situación que estaba cuando se apagó. Para esto, OS X crea un archivo llamado sleepimage que por definición ocupa el mismo espacio que la RAM que tiene tu equipo, 8 GB en mi caso.

    Muy pocas veces se me ha apagado el portátil estando trabajando con él. En mi caso en el que (hasta ahora) el portátil era un equipo secundario, la circunstancia más habitual es que guardo el MacBook Pro suspendido y se me olvida, de manera que pasados los días (a veces muchos) sin usarlo, la batería se le acaba y se hiberna.

    Puedes evitar la creación de este archivo desactivando la función de hibernación mediante Terminal, pero no me parece una buena idea. Lo que sí puedes hacer con Terminal de manera segura es eliminarlo después de cada hibernación, para lo cual debes usar la siguiente instrucción:

    sudo rm -rf /var/vm/sleepimage

    El término sudo vale para borrar archivos protegidos, así que OS X os pedirá la contraseña y os advertirá contra el idus de marzo.

    Yo veo más práctico (aunque quizá tostón) borrar a mano este archivo cada vez que se produzca una hibernación que desactivar las hibernaciones, que a más de uno nos han salvado el culo alguna vez. Quizá algún mago de Hazel o de Automator pueda crear una alarma que nos avise de la existencia del archivo y nos invite a ir a borrarlo.