Showing posts with label Mac tips. Show all posts
Showing posts with label Mac tips. Show all posts

2016-05-24

BPM-showing players for iOS

It's surprisingly difficult to find a way to browse one's music library on the iPhone together with the BPM values that were set on iTunes.

Note that the BPM value is stored in the iTunes database, not in ID3 tags in the individual songs. I was surprised by this; I rather expected iTunes to offload as much information as possible onto the actual files. And probably that would be the best option to avoid end up slaves to iTunes' database. On the other hand, storing metadata aside saves us from absurdly bulky TimeMachine backups...

2013-12-04

TimeMachine encryption performance: Synology's vs. Mac OS X's

A quick experiment to see what is faster to encrypt a TimeMachine network volume: using Synology's folder encryption or OS X's automatic TM encryption.

Copying a directory with 1200 files and directories in it (source files and compilation products), about 125 MB in total:
Unencrypted: 86 sec
Synology's encryption: 90 sec
OS X's encryption: 10 sec

So, not much to discuss about it: OS X's encryption wins.

Notes:
  • This was done by the verily scientific method of trying a couple of times and counting seconds aloud. At the beginning I was thinking about doing it in some scripted, repeatable, strict way to control for things like caching and blah blah. But, a 1:9 difference? That's convincing enough for me, kthxbai.
  • I simulated OS X's TM encryption by creating an encrypted disk image (AES 256 bit, sparsebundle) in an unencrypted folder in the Synology's server. This might not be the same than the real TM encryption, since that seems to be done by FileVault 2, but should be close enough. It certainly looks the same from the outside, judging by a verily scientific cursory look.
  • Probably the huge difference comes from the Synology server receiving just a bulk write of the pre-condensed small writes in OS X's side. Yet, that means a lot of work in OS X (right? caching all of the filesystem activity and encryption itself). But it was so quick that I didn't even realize. That's ironic in a way: I was rather expecting that Synology's server-side encryption would offload the work from the OS X client. Well, forget about that - I prefer such a burst (that I didn't even notice over the normal system activity) than seeing the TM updates languishing for what feels like hours.
  • The Synology server (DS412+) is using a SHR1 volume over 3 disks. Connection via WiFi, max substained speed about 9 MB/s.
  • The Synology OS version is DSM 4.3. OS X is Mavericks (10.9.0). Server folders mounted via the AFP protocol (which depending on who you listen to might be not the best option, with SMB2 being the new official recommendation, but that's what TimeMachine uses anyway).
  • Synology's terribly slow file indexing is disabled, so that's not the cause of the slowness. Just to confirm if it could be as bad as expected, I enabled it and repeated the unencrypted copy, and after 100 sec it was still half-way through the copy - so, yes, it really is so bad.  I just cancelled it.
  • An added convenience for using OS X's encryption: the Synology encrypted folder has to be hand-mounted (in the server) after every reboot (unless you use the point-defeating, password-remembering automounting). The OS X encryption is client-side, so you only need to turn on the server and can then forget about it.
  • Just for completeness' sake, I also tried copying the set of files to an unencrypted disk image in an encrypted and unencrypted Synology folder. The results were 20 sec for the encrypted folder, 10 sec again for the unencrypted one. So, looks like Synology's encryption plainly adds about a 2x penalty, and OS X's is pretty much transparent.
Given all of this, looks like even if Time Machine was not implemented as disk images, it would be very convenient to (try to) force it to use one, even if not caring for encryption!

2012-01-15

Tcpflow and connections between local interfaces


Looks like tcpflow doesn't see connections between local interfaces. After a bit of digging, looks like such connections are "routed internally by the kernel", at least in Linux. And there are patches for Linux to force those packets out of one interface and in from another, but even that is only useful if you have an external network connecting both interfaces (looks like a simple crossover cable should be enough).

http://www.ssi.bg/~ja/send-to-self.txt

There is another option: using iptables to first make the packets leave the machine towards some external IP, and then using arpd to make a router send back those packets.

http://serverfault.com/questions/127636/force-local-ip-traffic-to-an-external-interface

And I see people reporting that tcpflow -i lo does work for them, capturing flows having local addresses even though different than 127.0.0.1.

http://fixunix.com/tcp-ip/327123-capturing-tcpdump-local-traffic.html

The interesting thing is that people seem to take for well-known that Linux routes through the "lo" interface the traffic between local interfaces; but I didn't find any authoritative source which explains any rationale, any configurability, any implementation. Which I guess would make it somewhat easier to find such things in the BSD's and OS X.

(I surely should go straight to the source code, but that feels fragile. I am not interested on the current implementation, but on the design: how should it work vs. how does it work right now. Although surely that kind of networking would be pretty baked in into the kernel...)

Would be interesting to know if this something missing in the BSD's/OS X or in libpcap.

2011-11-30

canalmac.es y #mac en irc-hispano

Escribo esto por si alguien intenta googlear sobre Antispasm (yo!) en el canal #mac en irc.irc-hispano.org, o en canalmac.es .

Después de unos cuantos años allí, y de incluso plantearme escribir en canalmac.es , la cosa se ha puesto inaguantable hasta el punto de tener que escribir esto. Si buscas consejo o ayuda para algún problema, primero que nada (y para mantenerme en mi línea): has googleado ya? ;P

Y si ya lo has hecho, lo siento pero en #mac dudo que encuentres nada de interés. Poco a poco hay menos gente, y hace tiempo que no veo a nadie con idea; el último creo que era yo, modestia aparte ;P, y cada vez estoy menos por allá. Hay dos o tres personas allí que trabajan en IT de una forma u otra, pero por lo que preguntan o dicen de vez en cuando yo no confiaría en ellos, por lo menos cuando se trata específicamente de Mac OS X.

Y concretamente, y ésto es lo peor: ojo con Tuti. Es operador allí, y es el... editor? de canalmac.es. Es usuario de Mac desde hace tiempo, pero creo que nunca le he leído diciendo algo "serio". Y desde hace unos meses algo le ha pasado y se ha convertido en algo peor que inútil para la gente interesada en OS X. Basta con que te pases por la web de canalmac y veas lo que escribe por allá: las pocas veces que dice algo técnico, suele estar mal o MUY mal, y en cualquier caso por alguna razón parece que es 99% trolleo.
Durante un tiempo estuve corrigiendo cosas en los comentarios de cada artículo, pero al final me bloqueó (aunque dice que no me ha bloqueado).
No sé cómo sigue, ya hace tiempo que no entro porque no quiero quemarme la sangre viendo lo que escribe si ni siquiera puedo arreglarlo.

No entiendo por qué están así las cosas, pero no importa. Supongo que la pregunta importante es a dónde dirigirse para encontrar información técnica en español.

Y por desgracia no puedo decir mucho, yo me manejo principalmente en inglés. Macuarium no estaba mal hace unos años, ahora no lo sé. Y he oído hablar de FAQ-Mac de vez en cuando, no sé si es bueno. Tuti lo odia, así que quizás esté bien.
Pero por supuesto, en general las páginas españolas sólo copian lo que dicen las inglesas.

Así que en general recomiendo usar Google Translate para traducir páginas en inglés (o por supuesto leer directamente en inglés!). Las páginas que yo suelo frecuentar:
  • MacRumors es sobre rumores conectados con Apple en general, con foros muy activos. Mucha discusión inútil, pero puedes hacerte una idea de las opiniones de la mayoría pro-Apple, pro-Android, incluso alguno pro-RIM, pro-WebOS...
  • DaringFireball es el blog de un antiguo programador de BareBones Software (los autores de BBEdit), que suele escribir / seleccionar cosas relacionadas con Apple (no exclusivamente) y parece respetado en la blogosfera.
  • RoughlyDrafted escribe artículos muy interesantes y generalmente profundos sobre Apple, la competición y las alternativas. A veces suena quizás demasiado pro-Apple, pero la verdad es que se justifica tan bien y está tan estudiado que es difícil llevarle la contraria.
Y bueno, si tienes una duda interesante, siempre estoy interesado en oír qué tipo de problemas tiene la gente y cómo solucionarlos. Pero si es el tipo de duda que se soluciona con escribirla en Google sin que siquiera haga falta pulsar Return... te mandaré como siempre a http://www.usaelputogoogle.com/marlo.php .

    2011-07-31

    Compiling Transcode 1.1.6 and 1.2 in OS X

    (express post, too much time spent on this but too much work spent to let it slip without benefitting someone else)

    1.1.6 is not released, had to be hg-cloned. In fact, the repository looks like the 1.1.6 tag was at some moment added but then deleted?? That branch also has the latest video stabilization, no idea yet if it is also in 1.2

    Can be compiled. Get the hg repository via hg itself, not one of the zip/bz/etc packaged from the website since the compilation scripts expect to find the .hg files. Read the README and INSTALL, you'll need to create the configure yourself (easy, just read)

    I am using MacPorts, and even installed the included Transcode 1.1.5, so all the requirements are already installed. Most of the expected work was about configuring tne non-macports transcode to use the /opt dirtree.

    (Incidentally: 1.1.5 has horribly mismatched documentation, I have had to resort to using strings and source code to understand what some of the utils were supposed to be doing and how. The wiki doesn´t help. Also, not really working some of the combinations of export module/codec blow up without saying anything, no idea if that's because of transcode itself or because of lame, ffmpeg versions, who knows. Also, seems to be accepted that mp4 container files can't be generated directly by Transcode. I am interested on using the video stabilization plugin, but I if I had known that the time invested would be this much, ...)

    1.2's generation of configure uses a script named hgversion.sh, which doesn't work right and causes problems: the generated configure fails with
    ./configure: line 4: .: filename argument required
    .: usage: . filename [arguments]
    Inspection of the configure source shows that it was badly generated. configure.in uses echo -n blabla trying to output a "blabla" with no line feed. But echo in sh doesn't work like that, so the actual output is "-n blabla\n". (mhm, no, both sh and bash use /bin/echo but it behaves differently, interesting). Anyway: that's nasty, didn't anyone check it? And the errors it causes are insidious, I wasn't sure if those were status messages, warnings or plain errors. The easy fix is change the echo -n $1$HGVER for printf $1$HGVER .

    Even after having fixed that, 2 telltale failed output strings remained (something like
    configure.in:6: warning: AC_INIT: not a literal: -n 1.2.0-0a9d7c95b961
    ). But I could not find where they were coming from. No, configure.in:6 was not it, and I could not find any file which had cached the string or parts of it. Before the fix in hgversion.sh there were about 6 of those, after there were 2. Anyway, after some infructuous searching, I decided to try to go on... at least configure now worked and nothing exploded in a seemingly related way.

    The ./configure line I used:
    ./configure --prefix=/opt/local --enable-libavcodec --enable-ffmpeg --enable-experimental --enable-statbuffer --enable-lame   --enable-xvid   --enable-x264   --enable-libquicktime   --enable-faac    --enable-libavformat --with-lame-prefix=/opt/local --with-lame-includes=/opt/local/include --with-xvid-prefix=/opt/local --with-xvid-includes=/opt/local/include --with-xvid-libs=/opt/local/lib --with-faac-prefix=/opt/local/bin --with-faac-includes=/opt/local/include --with-faac-libs=/opt/local/lib --disable-libdvdread --disable-libjpeg 

    The xvid support is half-baked. I had to
    export CC=I/opt/local/include
    so the xvid support finally worked, since sometimes the --with-xvid-includes was left unused by the Makefile.

    Incidentally, I think that also helped x264.

    Transcode 1.2 has been seemingly abandoned for about 18 months now. The last post in the website says it should be about alpha quality, and that they were desperately looking for new developers...

    The make failed because in a number of submakefiles the tcmodule libs  path was not being added to the linker. I fixed it by adding $(LIBTCMODULE_LIBS) whenever the linker failed (with errors like:
    Undefined symbols:
      "_tc_module_info_match", referenced from:
          _tc_module_match in tcmp3cut.o
      "_tc_module_info_log", referenced from:
          _tc_module_show_info in tcmp3cut.o
    ld: symbol(s) not found
    collect2: ld returned 1 exit status
    make[2]: *** [tcmp3cut-1.2] Error 1

    )

    (note the "_tc_module_info_match": "tc_module_info_match" is a function in the "tcmodule-info" file in the "tcmodule" directory (sometimes Spotlight is useful! ;P). Then, note the "tcmp3cut": that was the part being compiled. Looking for it in the makefile showed that it was not including the $(LIBTCMODULE_LIBS), which was defined in the beginning of the file, but not being used as much as the rest of definitions)

    The tools directory had worse problems. The tcstub.c file is used when compiling other files, and 4 definitions conflict with libtc.a. Since libtc  seems to be generic for all of Transcode and the stub seems to be less important, I guessed the stub versions of the definitions had to go. I commented them out (tc_new_video_frame, tc_new_audio_frame, tc_del_video_frame, tc_del_audio_frame).
    The errors were like this:
    ld: duplicate symbol _tc_new_video_frame in ../libtc/.libs/libtc.a(tcframes.o) and tcmodchain-1.2-tcstub.o

    With that, it finally compiled.
    Beware, make install is supposed to install in parallel to existing 1.1-line transcodes (the new files should have "-1.2" added to their names), but some files had the same name and got overwriten. Example: avifix.
    Which is doubly insidious because the tools directory had those stub file problems, which make all the directory contents suspicious...

    When I have a moment to check / compare the 1.1.5, 1.1.6 and 1.2, I'll try to leave a note.

    2011-06-16

    Discos duros dañados, salvar datos y huir de SpinRite

    Últimamente me he encontrado a gente hablando de usar SpinRite para recuperar discos duros (incluso en Macs!), así que quizás ayude si cuento mi experiencia.

    Hace unos años (quizás 5?), el disco duro de mi iMac G3 de por entonces empezó a fallar. El ordenador se quedaba de repente congelado, sin responder a nada durante alrededor de 10 minutos, y luego de repente continuaba funcionando como si nada. Si recuerdo correctamente, las pausas siempre eran igual de largas, y ni siquiera respondía al ratón. No recuerdo si el disco hacía algún ruido extraño.

    Cómo supe que era el disco duro? Probé con algún CD o DVD de Linux y todo parecía ir bien, excepto al acceder al disco duro.

    Quería sacar los datos, así que empecé a buscar posibilidades. Una cosa que encontré fue SpinRite, que según lo que decía en su página web, sonaba a magia... lo cual en cosas de informática no es buena señal, creo yo. Se supone que SpinRite "revive" el disco duro. Pero bueno, llevaba tiempo con curiosidad, y tenía acceso a un PC y al programa, así que metí en él el disco duro y lo probé.
    Lo dejé trabajar más de 24 horas, y sólo había recorrido unas cuantas KB de los alrededor de 100 GB que tenía el disco duro.
    Lo paré y volví a empezar, esta vez esperando sólo unas 6 horas, pero seguía atascándose en el mismo punto. A ese ritmo tardaría meses en acabar (si es que acababa!), así que pasé a intentar otras cosas. Pero vamos, que por de pronto mi recomendación es clara: no perder el tiempo con SpinRite. Si tienes suerte sólo es una pérdida de tiempo; pero si no tienes suerte, todo lo que intenta hacer en el disco duro sólo lo acabará de estropear. (ya que cuando un disco duro empieza a fallar por algo mecánico, irá de mal en peor, así que hay que darse prisa para salvar lo que puedas)

    Al final usé un LiveCD o LiveDVD de Linux (Knoppix primero y Ubuntu después), que llevaba dd_rescue y ddrescue (y si no los llevaba no eran muy difíciles de meter con un pendrive o de descargar de la red, no recuerdo ahora). Se llaman así porque dd es la herramienta básica y tradicional en unixes para copiar discos al más bajo nivel, pero que si encuentra errores se para. ddrescue es como dd pero si encuentra fallos intenta continuar. Y dd_rescue (nombre parecido pero herramienta bastante diferente) no sólo resiste fallos sino que cuenta con ellos, y hace lo posible por salvar la mayor cantidad de datos en el menor tiempo: si encuentra un error, salta adelante en el disco hasta encontrar una zona sin fallos y sigue leyendo; lee hacia delante y hacia detrás desde cada punto del disco (porque a veces eso ayuda); y recuerda todos los saltos dados para recomponer una imagen de disco lo más utilizable posible.

    Por qué es importante lo de los saltos? Porque como he dicho, cada vez que el disco intentaba leer en un punto con errores, había un timeout de minutos. Y había muchos errores salpicados por el disco, así que cualquier intento de leer a lo loco se hacía imposiblemente lento. Además, acabé descubriendo que parte del problema era que para mejorar la velocidad (caché de lectura/read-ahead) el OS y el propio disco normalmente intentan leer bloques grandes del disco, en vez de sectores (que son sólo 512 bytes). Y en realidad cada sector con problemas tenía un timeout de quizás 2 segundos. Pero es típico que los sectores dañados están juntos, así que una lectura de digamos 8 MB (que parece un valor típico) podía estar tropezando con cientos de sectores dañados, multiplicando los tiempos de espera; por eso puede ser útil acercarse a un punto dañado "desde atrás", para tropezar sólo con un sector dañado en vez de con muchos.

    Y no sólo eso, sino que además es posible desactivar los cachés y read-ahead con hdparm en Linux. Así que, añadiendo a dd_rescue la configuración del disco con hdparm para minimizar los timeouts, pude acabar de salvar más del 80% del disco en unas pocas horas.
    dd_rescue sigue intentando leer las partes dañadas para extraer todo lo posible, pero llegó un momento en que el disco duro ni siquiera respondia ya. Quizás si no hubiese perdido tiempo con SpinRite hubiese conseguido sacar más, quién sabe.

    Después de todo esto acabé con una imagen de disco, que pude montar en OS X con hdiutil (creo recordar, eran tiempos de OS X 10.3 o 10.4) y semiarreglar con DiskWarrior. Aunque creo que también usé Data Rescue II para rebuscar ficheros sueltos, aunque eso ya es a lo desesperado y sin garantías de que valga la pena (porque los ficheros recuperados pueden estar corruptos). Aconsejable si tenías ficheros sueltos que aprecies, ya sean documentos o fotos; pero las cosas que iban en directorios (por ejemplo, programas) mejor darlos por perdidos, aunque a veces hay alguna sorpresa.
    En vez de Data Rescue II creo que también probé otras herramientas, pero Data Rescue II fue lo mejor al final. Photorec es una opción, y gratis/open source; creo que la descubrí cuando ya había acabado con Data Rescue.

    Cosas que aprendi con todo esto:
    • los discos duros fallan. Sin más.
    • Hacen falta backups. 
    • Linux da un nivel de control impagable para arreglar discos duros fallados. 
    • Se pueden salvar muuuchas cosas con herramientas gratuitas. 
    • Cuando el disco duro empieza a fallar mecánicamente, hazte a la idea de que tiene las horas contadas (literalmente!), y piénsate bien cómo las usas para salvar lo que puedas. 
    • Usar SMART puede avisarte con algo de tiempo de que el disco va a fallar.

    Respecto a SMART, smartmontools (open source, disponible en macports) hace de todo: desde chequeos puntuales hasta tests en profundidad periódicos. Pero ojo, han habido un par de estudios (hechos por Google y otra empresa, analizando fallos en miles de discos de varios fabricantes) en que la conclusión es que SMART sólo detecta alrededor del 50% de los fallos. Pero eso sí, cuando avisa, al disco duro le quedan menos de 24 horas.
    Y en cualquier caso para que SMART chequee todo lo que puede chequear hace falta usar sus tests periódicamente, como hace smartmontools (si lo configuras como toca).
    Pero de todas formas, desde que pasó todo esto, me han fallado 2 discos duros más y SMART no avisó pese a los tests y bla bla bla. En fin, es gratis... menos da una piedra, supongo.
    Ah, y aún no he visto ninguna caja externa que dé acceso a SMART. Y eso que tengo 5 (USB y Firewire, y de diferentes marcas).

    Más cosas: cuando un disco duro "moderno" (los PATA ya contaban como "modernos"!) detecta que un sector está fallando, intentará recuperar la información automáticamente (por ejemplo repitiendo la lectura de un sector que da errores de lectura), y si lo consigue, lo substitutye por otro sector sano; los discos duros llevan ocultos unos cuantos sectores de reserva para ello. Esto sucede en el disco duro por sí mismo, sin que el OS haga nada. Cuando un sector realmente no se puede leer tras varios intentos, es cuando empezamos a recibir errores de lectura en el OS. Y en esa situación una posibilidad para ayudar a arreglarlo es escribir ceros en ese sector, lo cual puede hacerse sobreescribiéndo el fichero afectado con ceros, ... o simplemente formateando todo el disco (con ceros! ojo, que hay programas de formateo que no usan ceros! El de DOS por defecto no lo hace, el de Windows XP creo que tampoco, OS X tiene la opción). Cuando la unidad detecta la escritura de ceros, aprovecha para substituir los sectores dañados que tenía pendientes de leer, de forma que ya no darán problemas.
    ...pero en cualquier caso la existencia de esos fallos eso ya debería ser una mala señal sobre el futuro del disco!
    Con smartmontools se puede consultar la lista interna de la unidad que dice cuántos sectores están en esa situación de mala lectura/esperando substitución. Si no recuerdo mal, si ese valor es mayor de 0, puede ser porque ya no quedan sectores de reserva para la substitución, ... así que la cantidad de errores seguirá aumentando. Hora de preparar un disco nuevo.

    Y volviendo a SpinRite: hay bastante gente online diciendo que va muy bien. Pero también hay mucha gente que cree en el horóscopo, y eso no hace que sea verdad. Y es interesante que normalmente la gente que está en contra de SpinRite son los que saben explicarse técnicamente. Es decir: la presentación oficial de SpinRite suena a basura de Teletienda, y los argumentos de la gente que lo defienden suenan también casualmente a "happy customers" de Teletienda (cosas como "hazme caso, soy informático en una gran empresa y SpinRite ha salvado mi culo más veces de lo que puedo recordar, te lo recomiendo, no te arrepentirás!": explicaciones muy técnicas, vamos). Me imagino que a veces puede ayudar, porque lo que hace SpinRite es básicamente lo mismo que he explicado de la lectura repetida de sectores y escribir ceros en sectores fallados. Pero lo hace de una forma absurdamente basta, provocando enormes timeouts, repitiendo cada operación varias veces incluso cuando es contraproducente, afectando igual a sectores sanos y dañados, ... y encima es de pago, cuando el mismo efecto lo puedes conseguir con herramientas gratuitas o incluso incluidas por defecto en el sistema.

    Y por último, SpinRite hace una cantidad de estupideces asombrosa para dar la sensación de que hace algo realmente mágico. Parece que es el estilo general del autor ( www.grc.com ), que ya ha dado la nota alguna vez en otros temas, como cuando intentó convencer al mundo que un bug del formato WMF en Windows era una conspiración de Microsoft para controlar todos los PCs. Por suerte de vez en cuando hay alguien que da una referencia para ponerle en su sitio... como cuando un desarrollador de Snort desmontó las tonterías que decía sobre escaneo de redes.

    2009-07-04

    Smart Crash Reports, Input Managers y otras alimañas

    Smart Crash Reporter es un Input Manager creado por Unsanity (creadores de los "haxies").
    La historia completa está en http://daringfireball.net/2006/01/smart_crash_reports . El resumen de la historia en español es que los Input Managers son en teoría una forma de añadir al sistema formas de entrada de texto. Pero en la práctica, los Input Managers pueden hacer muchas más cosas. Se cargan automáticamente en cualquier programa y pueden alterarlo (en memoria, al ejecutarse; los programas no son alterados en disco). Un Input Manager conocido es (era?) Pith Helmet, que añade capacidades anti-anuncios a Safari.
    Así que los Input Managers son muy potentes, y también pueden ser muy peligrosos. Hay quien dice que son el sueño de cualquier programador de malware, y de hecho Leopard trajo como mejora de seguridad serias restricciones al uso de Input Managers.
    Smart Crash Reporter es otro Input Manager típico, y mosqueante porque suele ser instalado por varias aplicaciones sin avisar al usuario. Lo que hace es modificar el Crash Reporter de Apple para que no sólo envíe los informes de crash a Apple sino también a Unsanity, donde otros desarrolladores podrán ver esos informes, lo cual será útil para que encuentren los problemas que causaron el crash.
    Peeero, esa meta se puede conseguir de otras formas más... higiénicas que instalar (a escondidas o no) un Input Manager, que va a trastocar todas las aplicaciones que ejecutas. Parece que SCR está bien hecho y no debería dar problemas, pero aún así, siempre será mejor no jugar con fuego.
    Si en tu directorio Librería/Input Managers tienes el dichoso SCR, puedes empezar eliminándolo a mano y mantener un tiempo abierta la carpeta para ver cuándo vuelve a aparecer (seguramente al arrancar alguna de las aplicaciones que lo instalan).
    Otra cosa que puedes hacer es añadir una Acción de Carpeta para que te avise automáticamente si aparece algo nuevo en la carpeta. Pero eso sólo avisa, no lo evita. (...a no ser que uses una acción que además borre, claro...)
    Y otra posibilidad es añadir una carpeta llamada igual que el Input Manager que quieres evitar ("Smart Crash Reports" en este caso); así cuando quieran instalarlo otros programas, creerán que ya está ahí y lo dejarán. (aunque aparecerán mensajes en el system.log cada vez que arranques un programa, avisando de que no han podido cargar el Input Manager...)
    En mi caso, el programa que había hecho aparecer el SCR era Graphic Converter. Es una versión algo atrasada (6.2), no sé si la actual aún lo usará...
    Y parece que QuickSilver no lo instala, aunque era mi primer sospechoso.

    2009-06-19

    Semi-automating piece-wise translating texts through Google Translate

    I am having to translate a horribly old program (1992?, DOS' Turbo Pascal)… and in german, to make it funnier… to an only-slightly-less-horribly-old environment (Delphi 4, circa 1999). To think that I was complaining about how outdated Borland's C++ Builder 5 felt… oh my.

    I guess/hope/fear that later there will be a more modern target. But that will be easy, given that by then I should understand everything and the program itself is not complicated.

    2009-01-27

    Toshiba G450 en OS X - funcionando sin reiniciar

    Por fin me he dedicado a jugar un poco con el driver oficial. El resultado esperado, como Nexus había comentado antes en otro post, era que el G450 sólo funcionase si estaba enchufado desde el arranque.

    Pero en mi caso era peor: ni siquiera así funcionaba. Además he visto por la red más gente con el mismo problema. El "Toshiba PC Tool.app" que se instala junto al driver simplemente dice que no encuentra el modem, y ni siquiera aparece montado el disco USB que debería aparecer al conectar el G450.

    El Perfil del Sistema muestra sin embargo que en el bus USB está conectado un disco de Toshiba, y la Consola muestra que diskarbitrationd no ha podido crear un disco ("unable to create /dev/disk2"). Esto se mantuvo así aunque reseteé el G450 y reformateé el disco con el propio menú del teléfono/modem/bicho.

    Pero he encontrado una solución, que aunque no es ideal, tampoco cuesta mucho. Cuando el G450 está apagado y es enchufado al ordenador, la pantalla muestra una animación de carga de batería. Y el Perfil del Sistema muestra que hay un disco USB conectado. Cuando el G450 está encendido y es enchufado al ordenador, también se comporta como un disco. Pero se enciende un LED verde en la pantalla del modem. En Windows y Linux, cuando el G450 pasa al modo modem (gracias a un comando que el driver le manda), ése LED verde se pone azul. Y esto no estaba sucediendo en el Mac.

    Pero en uno de los reinicios que probé, resultó que el LED se puso azul justo cuando el ordenador se apagaba. Y así se quedó cuando reinicié (no lo desconecté). Así que esta vez el Toshiba PC Tool sí que encontró el modem y ofreció un botón de "Conectar". Por fin! (también creó 3 interfaces de red nuevos, que seguramente permitirán manejar el modem más fácilmente mediante los Ross' Scripts, igual que ya hago con el Huawei E220. Pero eso, para otro día)

    Así que: por alguna razón, el G450 está pasando a modo modem cuando el ordenador se apaga. Supongo que el driver de almacenamiento USB de OS X se adueña del G450 (aunque no consigue crear el disco!) así que el driver de Toshiba no puede mandar el comando de cambio de modo; y durante el apagado, cuando el driver de almacenamiento USB libera el disco, el driver de Toshiba por fin consigue mandar el comando justo antes del apagado final. O quizás es sólo un efecto secundario del apagado del bus USB, oiga. Quién sabe. En cualquier caso, funciona y es repetible.

    Pero lo mejor es que no hace falta el apagado. Resulta que si pones el Mac a dormir (menú manzana -> reposo, o por ejemplo cerrando la tapa del Macbook) el efecto es el mismo: el LED se pone azul, y después el Toshiba PC Tool funciona. (ojo, el Mac no se queda dormido! Debe haber algún problema, porque inmediatamente después de empezar a dormir se despierta, y si la tapa está cerrada vuelve a dormir y a despertarse..... lo cual me temo que provocará algún cuelgue en algún momento. Así que si vas a probar esto, primero guarda lo que tengas abierto. De todas formas, quizás el problema del duerme-despierta sea cosa de los chungos drivers de Huawei que tengo instalados, que también instalaron un kext sobre algo de "USB wakeup"...)

    En fin: finalmente he podido usar el G450 en mi Macbook. Ahora tocará ver si es mejor que el E220... que da bastantes problemas cuando lo usas con programas P2P con el operador Play. (aún no sé si es por drivers chungos o porque Play esté haciendo alguna jugarreta... cuando pueda, tendré que experimentar un poco con algún detector de gracias, como el Switzerland de la EFF).

    Por completitud: he probado a descargar el driver de almacenamiento USB para ver si así el driver de Toshiba funciona mejor (mediante "sudo kextunload -b com.apple.iokit.IOUSBMassStorageClass"). Pero no sólo no funciona, sino que deja de funcionar el truco de dormir al mac. Así que mejor no tocarlo.

    Otra forma de forzar el paso al modo modem sería usando USB_ModeSwich, que en OS X funciona tras desactivar el driver de almacenamiento USB... pero mientras no me provoque algún cuelgue, seguiré usando el truco de dormirlo. Más rápido ;P.

    Toshiba G450 working in OS X - whitout a reset!

    Finally I have had the chance to play a bit with the official driver. Remember, the expected result was that it would only work if plugged since the booting of the Mac. That would be unfunny, but in my case it was even worse: as a lot of other people has reported, it didn´t seem work at all. The "Toshiba PC tool.app" reported that no modem was found, and no USB disk appeared, even though I tried resetting and reformating the G450 internal disk (through its own configuration menu). But finally I have found a solution. Not ideal, but not too painful, and it works. The problem was that the modem would remain in the disk mode - which in my Mac at least doesn´t even work properly, since it doesn´t get mounted as a disk. The only way I can see that it is supposed to behave like a disk is because it appears in System Profiler.app, in the USB devices list. And Console.app shows something about diskarbitrationd "unable to create /dev/disk2". When the G450 is turned off and gets connected to the computer, it displays a charging battery animation. And System Profiler reports a USB disk. When the G450 is turned on and gets connected to the computer, it also behaves like a disk. But a green LED glows in the modem´s screen. In Windows and Linux, when the G450 does switch to the modem function (thanks to a command which the driver should be sending to it), this green LED turns blue. And this wasn´t happening in the Mac. But during one of the reboots I tried, I noticed that the LED went blue just when the computer shut down. So, next start up, the G450 (which was still connected) was still in the modem mode, and this time the Toshiba PC tool app started up, detected the modem and offered a "Connect" button. Finally! (it also created 3 network interfaces, which surely will allow to control the modem through Ross' Scripts instead of the shitty Toshiba app, like I am doing now with the Huawei E220. But more on that some other day) So: somehow the G450 is switching to modem function when the computer shuts down. My guess is that the USB storage driver of OS X takes control of the G450 so the Toshiba driver can´t send the mode switch command, and when shutting down the USB storage driver finally lets go and the Toshiba driver manages to send the command just before the final shut down. Or maybe it is just some secondary effect of the USB bus going down. Anyway, it works, and is repeatable. But the best part is: there is no need to shut down. Turns out, that by putting the Mac to sleep (with the Sleep option in the Apple menu, or by closing the lid of the Macbook, for example) the effect is the same: the green LED turns blue, and afterwards the Toshiba PC tool works. (also, the Mac won´t really go to sleep! Looks like the G450 makes it to wake up as soon as it starts sleeping - but if the lid is closed the Mac will keep trying to sleep and immediately waking up. Not nice, I won´t be surprised if that causes some crash, and would recommend to save anything important you may have before trying that. Anyway, maybe this waking up effect I am seeing has something to do with the also nasty drivers from Huawei, which also installed some "USB wakeup" kext...). So finally I have been able to use the G450 in the Macbook. Now I will have to see if it is any better than the E220... which with polish operator Play is quite difficult to keep connected while using P2P apps. (I still don´t know if that is because of the Huawei drivers or because of the operator doing something funny... When I can I will experiment a bit with EFF's Switzerland or some other "funnyness detector") Just for completeness: I have tried to unload the USB Mass Storage driver in OS X to see if the Toshiba driver would work (with "sudo kextunload -b com.apple.iokit.IOUSBMassStorageClass"). No joy, and that even prevents the sleeping trick from working. So, better to leave that alone. (It works again after reloading the storage driver) Another way to force the mode switch would be using USB_ModeSwitch, which in OS X works after unloading the storage driver. But, until the sleeping trick causes any crash, I'll stick to it.

    2008-09-08

    Bus error in MacPorts' Python

    PyQt4 (MacPorts' py25-pyqt4) was causing a Bus Error.

    Some previous problems with the Python 2.5 installed by MacPorts made me think it could be some dependency with the native library called by the Python module; that is what I think that was also happening with py25-hashlib, which caused an error about being unable to find _md5 or some such, and which got fixed by uninstalling MacPorts' openssl 0.9.8g and installing 0.9.8h (and reinstalling py25-hashlib afterwards).

    (and I say "think" because maybe that problem was unrelated to openssl, and in fact could be related to python_select, which I maybe had or had not run. Read on for more on that. Anyway, there was also some report online of problems between Pythons' hashlib and openssl because of the exact version used, and mentioned Python being a bit fragile in that respect — although it didn't say if that was because of a not-too-robust build/installation process, or because of Python's design.)

    But here the problem was different. Reinstalling Qt 4 and PyQt4 did not help. After some googling, I found someone (thanks jherm) with the same problem... and who in some chat log is told by some MacPorts developer (?) the anticlimactical solution: follow the instructions at the end of the installation of MacPorts' Python 2.5. That is,
    $ sudo port install python_select $ sudo python_select python25
    Looks like this has to be run "to complete the installation". Sheesh. So that was a hard requisite? Shouldn't that have been told pretty explicitly then? (I'm seeing a number of reports about this kind of problem, so yes, I think the warning should be quite more explicit... I should start some bug reporting, I guess.)

    So the problem seems to be that PyQt4 uses Python in its build process, assuming that it is the same in which it will be run afterwards. But in my case I had not run python_select after installing MacPorts' python25, because it seemed optional, and I didn't want to use it as the default… so PyQt4 was building against OS X's default Python.

    So, after python_select, PyQt4 builds OK. It doesn't manage to get fully installed, mind you, but I guess that this other problem has more to do with MacPorts. Anyway, with a
    $ sudo port -f install py25-pyqt4
    it finally gets installed (although something remains to be finished, like the MacPorts' database getting properly updated; that can be checked with -d).

    All of this was in the process to try to make Anki run from source. I was trying to test some modifications before sending the patches, but making sense out of the tortuous source and setting up the environment have required much more time than expected. I should be studying Polish instead! The exam is coming! :P