H. Mijail's Blog

Gruber, de Daring Fireball, escribió hace tiempo sobre la posibilidad de crear URLs que enlazan a mensajes en tu buzón de Mail.app . Y es algo tremendamente útil y que no veo publicado en español, así que aquí pongo un pequeño resumen. Primero: de qué se trata exactamente? Pues que es un enlace que, cuando clicas en él, se abre Mail.app y te muestra el mensaje concreto que sea, en medio de tu buzón. Muy útil si por ejemplo dentro de 2 semanas tendrás que usar un mensaje que acabas de recibir: puedes usar el enlace al mensaje en iCal, de forma que la alarma que te saltará dentro de 2 semanas tiene un link que al clicarlo abre el mensaje correspondiente. La cosa es que Mail.app entiende esas URLs, y se crean automáticamente si por ejemplo arrastras un mensaje desde Mail.app a iCal. Tienen este aspecto: message:// , donde MESSAGE-ID está contenido en las cabeceras de cualquier mensaje. Y sí, es muy útil, pero Mail.app no tiene una forma directa de crear tales links. Una forma es...

Safari on desktop and iOS has a feature called "Reading List". It is a way to store URLs in iCloud, synchronize them between Safaris, and mark them as read or not. Somewhat like Instapaper maybe. I was a bit surprised that there is no Chrome or Firefox extensions for tapping into Safari's Reading List. So I wanted to try poking a bit into the protocol, maybe something interesting would appear or someone could get some headstart from this. Safari always seem to start contacting p05-bookmarks.icloud.com, which resolves to the Akamai CDN, some p05-bookmarks.icloud.com.akadns.net. Luckily the IP always was the same, and there is no client certificate check, so I could mount a little Man In The Middle via /etc/hosts. Then, a couple of socats: one to pose as the original SSL server and resend the plaintext; and the second to receive the plaintext and send it to the original IP. The first socat shows everything that goes out of it (in plaintext) thanks to the -vx option. ...

I recently installed Mac OS X 10.7 Lion, and found that it already had drivers for the Huawei E220 3G modem. But the drivers are 32 bit, so they won't work for machines which use a 64 bit kernel. And there seem to be no 64 bits drivers, so the only solution for now is booting in 32 bit kernel mode (pressing 3 and 2 when booting). I seriously doubt that Huawei are going to publish updated drivers; they were already rather unsupporting even when the modems were new. Eventually, I plan to try to make my own driver, but that won't be short-term...

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...

I first thought about this as a lsof substitute, but no, it's more like a primitive / simple FileMon/fs_usage. It shows the executable and the file it opened. Could be improved, of course. Dtrace is amazing. sudo dtrace -qn 'syscall::open*:entry{ printf("%s %s\n",execname,copyinstr(arg0)); }' fs_usage shows much more information... but is not a one-liner ;P

Typically, when I start seeing a film, I only have enough time to quickly get some subtitles, try to make them more-or-less work with the film at hand and ... that's it. So, lots of repetitive, rushed fixes but no long-term solutions. But this time I got sick of it and tried to get to understand the problem. Which is: Polish subtitles don't work with mplayer, or at least not with the mplayer built with MacPorts' mplayer-devel port, which uses mplayer's SVN HEAD. The option -subcp cp1250 does select the codepage (cp1250 is variously called Windows Latin 2 or Windows Central European encoding, which seems to be the typical encoding used by polish subtitles on the net) The option -subcp enca should auto-detect the encoding, but the port disables enca at configure time, and provides no way to enable it. I'll try to send a patch for that. In the meantime, enca -L pl -i file by itself works nicely (enca is provided by a port). For difficult cases when enca fails...

Tcpflow 1.0.2, as built with MacPorts, doesn't work when net expressions are used. But 1.0.6 does work. I already submitted a new portfile so it should be available soon.