2011-12-30

Resizing the system NTFS partition on Windows XP

I didn't find a way to grow the boot partition on a live system (I think OS X has been able to do that for some time now?). I used BootIt, free for this kind of partition work. Quick download, quick self-install on a USB stick, reboot, unnervingly unresponsive while working, but finally problem-free.

In my case I was growing the boot partition into free space. And this XP uses some Intel SATA AHCI driver, and installed in a non-standard way at that, which made me a bit weary. But everything turned out right.

The next best option seemed to be GParted Live, which also has an easy way to be installed on a USB stick via TuxBoot.

Directory permissions vs local Portfiles in MacPorts

~/MacPorts/ports$ sudo port install socat
--->  Computing dependencies for socat
could not read "/Users/mija/MacPorts/ports/sysutils/socat/Portfile": permission denied

I was having strange problems to use a locally edited portfile. Turns out the permissions were wrong in a directory in the path; each of the directories should have at least o+rx permissions, and strangely my $HOME had none of those (strange because other users in my computer had o+rx, admins or not).

Note that MacPorts lately (from 2.0?) has started to use the user nobody at some points of its workings, and root at others; in this case the user nobody was the one unable to reach the Portfile. A way to check what this user sees is "sudo -u nobody ls -leda@ /Users/mija/blabla".

A workaround is setting macportsuser in /opt/local/etc/macports/macports.conf to root, but that's not a good idea. MacPorts is doing the the sensible thing, de-escalating privileges when they are not needed; that way, if something went awry, the problems should be much smaller. Lion is doing a lot to be secure, let's keep it that way.

So fix those permissions, goddamit.

2011-12-21

Custom software for interfacing via USB with multimeters UNI-T UT81B

These multimeters are rather pocket oscilloscopes. Quite an interesting package. And the possibility of interfacing via USB with a computer should multiply the possibilities.

Alas, the included software could hardly be crappier. (why do so many manufacturers do something justifiably interesting and then neuter it by blowing up what should be a minor part of the whole?)

2011-12-05

Límites absurdos de longitud de paths en APIs de Windows

Ordenando cosas viejas me he encontrado con un problema interesante que tuvimos en los tiempos de gvSIG (hace unos 4 años)...

Problema: si se intenta descomprimir el ZIP en un Windows, nos encontramos con la incapacidad de Windows de crear ficheros con path completo de más de 260 chars. Esto sucede tanto en NTFS como en FAT, y es un problema (por ejemplo) si se quiere descomprimir el ZIP en un Windows para meterlo en una unidad USB o un CD / DVD.
No es una limitación de FAT: la copia o descompresión se puede hacer en un OS no-Windows y va bien.
Es una limitación de API de Windows (como mínimo incluyendo Windows 2003 Server): aunque filenames pueden ser de mas de 255chars, paths completos no pueden superar 260 chars.

http://msdn2.microsoft.com/en-us/library/aa365247.aspx

2011-12-03

Steve Jobs' Commencement Speech at Stanford (2005)

This was difficult to find, so I guess any links will help.
So here it is: a polish translation of Steve Jobs' commencement speech at Stanford (2005). With even some comments on translation accuracy.

2011-12-02

Steve Jobs and the Monomyth

Just realized that Steve Jobs' trajectory could be somewhat compared to the Monomyth: the fall from grace when fired from Apple, the struggles in NeXT and Pixar which ended nicely but were quite a bet, the coming back to the beleaguered Apple (look, that infamous sentence!) and the multiple concurrent struggles (Mac vs Windows, iPod vs constellation of MP3 players, iPhone vs telephone industry, iPad vs computer industry), and the final fight against cancer itself.

(What a crescendo!)

Maybe that's why even people who only passingly knew about the story were hit by the news of his death? Maybe just because he was that "Hero" fighting all those impossible fights - and winning!

Mhm, now I am worried about what kind of film are they wanting to make about him... I can't really imagine it being interesting nor good, but if they think about the Monomyth angle, I can imagine it getting crappy.

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-11-23

    dtrace'ing paging to disk

    How to know which processes are paging to/from disk (as opposed to other VMM management) in OS X, and how much exactly:

    sudo dtrace -n maj_fault'{@[execname] = count()}'

    reference (with examples and other options): http://wikis.sun.com/display/DTrace/vminfo+Provider

    I had been meaning to look for ways to do this, and tried some of the tools included in OS X (Activity Monitor, top, Instruments, vm_stat, vmmap, top, ...). But nothing really helped, and/or seemed to miss the exact level of information I was targeting (only resulting in real I/O; relationship between I/O and process; realtime... ). Finally I had the inspiration to google for "dtrace pagefaults". Bingo.
    (dtrace in this example isn't realtime, but is the best approximation so far, and I'm guessing some tuning should fix it. Heck, it's a one-liner!)

    Learning dtrace is still something I'd love to do, and once again it is tempting me to let it jump to the front of queue...

    (Mhm, will Oracle's Java for OS X support dtrace too?)

    Oh, and of course Firefox was by far the greatest pagefaulter, even with the great improvements in the v9 betas. (I actually saw it diminish its VM usage by some hundreds of MB when it was freshly launched!... though after some days it has gone back to its habit of hovering over 20% CPU and 2 GB VM even while idle)
    But it's interesting that the second offender is Skype, even if more than one order of magnitude less than Firefox; but also one order of magnitude greater than the 3rd and rest of offenders. Interesting because it looks very good mannered in Activity Monitor, and it was unused during all of the measuring time. Maybe its P2P routing thing...? Would be good to keep an eye on it.

    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.

    2011-02-22

    "OpenSSL speed" on iPhone 4

    A test I thought could be interesting to get some (diffuse) idea of the processing power of the iPhone 4:

    Mijails-iPhone:~ mobile$ uname -a
    Darwin Mijails-iPhone 10.4.0 Darwin Kernel Version 10.4.0: Wed Oct 20 20:14:45 PDT 2010; root:xnu-1504.58.28~3/RELEASE_ARM_S5L8930X iPhone3,1 arm N90AP Darwin
    Mijails-iPhone:~ mobile$ openssl speed
    To get the most accurate results, try to run this
    program when this computer is idle.
    Doing md2 for 3s on 16 size blocks: 113903 md2's in 2.93s
    Doing md2 for 3s on 64 size blocks: 59789 md2's in 2.96s
    Doing md2 for 3s on 256 size blocks: 20740 md2's in 2.94s
    Doing md2 for 3s on 1024 size blocks: 5722 md2's in 2.95s
    Doing md2 for 3s on 8192 size blocks: 741 md2's in 2.95s
    Doing md4 for 3s on 16 size blocks: 962184 md4's in 2.99s
    Doing md4 for 3s on 64 size blocks: 808365 md4's in 2.94s
    Doing md4 for 3s on 256 size blocks: 553565 md4's in 2.94s
    Doing md4 for 3s on 1024 size blocks: 251644 md4's in 2.96s
    Doing md4 for 3s on 8192 size blocks: 41204 md4's in 2.94s
    Doing md5 for 3s on 16 size blocks: 512656 md5's in 2.88s
    Doing md5 for 3s on 64 size blocks: 446107 md5's in 2.70s
    Doing md5 for 3s on 256 size blocks: 323702 md5's in 2.65s
    Doing md5 for 3s on 1024 size blocks: 169849 md5's in 2.79s
    Doing md5 for 3s on 8192 size blocks: 30073 md5's in 2.68s
    Doing hmac(md5) for 3s on 16 size blocks: 933276 hmac(md5)'s in 2.62s
    Doing hmac(md5) for 3s on 64 size blocks: 741506 hmac(md5)'s in 2.72s
    Doing hmac(md5) for 3s on 256 size blocks: 490370 hmac(md5)'s in 2.62s
    Doing hmac(md5) for 3s on 1024 size blocks: 202907 hmac(md5)'s in 2.63s
    Doing hmac(md5) for 3s on 8192 size blocks: 28168 hmac(md5)'s in 2.32s
    Doing sha1 for 3s on 16 size blocks: 466460 sha1's in 2.83s
    Doing sha1 for 3s on 64 size blocks: 498797 sha1's in 2.92s
    Doing sha1 for 3s on 256 size blocks: 298535 sha1's in 2.90s
    Doing sha1 for 3s on 1024 size blocks: 114257 sha1's in 2.94s
    Doing sha1 for 3s on 8192 size blocks: 16773 sha1's in 2.94s
    Doing sha256 for 3s on 16 size blocks: 577481 sha256's in 2.93s
    Doing sha256 for 3s on 64 size blocks: 350266 sha256's in 2.96s
    Doing sha256 for 3s on 256 size blocks: 158648 sha256's in 2.96s
    Doing sha256 for 3s on 1024 size blocks: 49984 sha256's in 2.93s
    Doing sha256 for 3s on 8192 size blocks: 6722 sha256's in 2.88s
    Doing sha512 for 3s on 16 size blocks: 120505 sha512's in 2.93s
    Doing sha512 for 3s on 64 size blocks: 121406 sha512's in 2.91s
    Doing sha512 for 3s on 256 size blocks: 43968 sha512's in 2.92s
    Doing sha512 for 3s on 1024 size blocks: 15084 sha512's in 2.94s
    Doing sha512 for 3s on 8192 size blocks: 2119 sha512's in 2.96s
    Doing rmd160 for 3s on 16 size blocks: 500321 rmd160's in 2.88s
    Doing rmd160 for 3s on 64 size blocks: 518314 rmd160's in 2.93s
    Doing rmd160 for 3s on 256 size blocks: 294776 rmd160's in 2.93s
    Doing rmd160 for 3s on 1024 size blocks: 108497 rmd160's in 2.92s
    Doing rmd160 for 3s on 8192 size blocks: 14321 rmd160's in 2.69s
    Doing rc4 for 3s on 16 size blocks: 8838055 rc4's in 2.96s
    Doing rc4 for 3s on 64 size blocks: 2573509 rc4's in 2.91s
    Doing rc4 for 3s on 256 size blocks: 670210 rc4's in 2.93s
    Doing rc4 for 3s on 1024 size blocks: 168703 rc4's in 2.92s
    Doing rc4 for 3s on 8192 size blocks: 20854 rc4's in 2.71s
    Doing des cbc for 3s on 16 size blocks: 1656140 des cbc's in 2.75s
    Doing des cbc for 3s on 64 size blocks: 425114 des cbc's in 2.83s
    Doing des cbc for 3s on 256 size blocks: 108385 des cbc's in 2.87s
    Doing des cbc for 3s on 1024 size blocks: 28718 des cbc's in 2.76s
    Doing des cbc for 3s on 8192 size blocks: 3510 des cbc's in 2.81s
    Doing des ede3 for 3s on 16 size blocks: 646206 des ede3's in 2.83s
    Doing des ede3 for 3s on 64 size blocks: 164355 des ede3's in 2.87s
    Doing des ede3 for 3s on 256 size blocks: 41628 des ede3's in 2.83s
    Doing des ede3 for 3s on 1024 size blocks: 10274 des ede3's in 2.87s
    Doing des ede3 for 3s on 8192 size blocks: 1241 des ede3's in 2.80s
    Doing aes-128 cbc for 3s on 16 size blocks: 2403683 aes-128 cbc's in 2.89s
    Doing aes-128 cbc for 3s on 64 size blocks: 649635 aes-128 cbc's in 2.81s
    Doing aes-128 cbc for 3s on 256 size blocks: 174904 aes-128 cbc's in 2.89s
    Doing aes-128 cbc for 3s on 1024 size blocks: 45134 aes-128 cbc's in 2.94s
    Doing aes-128 cbc for 3s on 8192 size blocks: 5175 aes-128 cbc's in 2.68s
    Doing aes-192 cbc for 3s on 16 size blocks: 2168292 aes-192 cbc's in 2.91s
    Doing aes-192 cbc for 3s on 64 size blocks: 600481 aes-192 cbc's in 2.93s
    Doing aes-192 cbc for 3s on 256 size blocks: 155498 aes-192 cbc's in 2.90s
    Doing aes-192 cbc for 3s on 1024 size blocks: 39192 aes-192 cbc's in 2.91s
    Doing aes-192 cbc for 3s on 8192 size blocks: 4777 aes-192 cbc's in 2.86s
    Doing aes-256 cbc for 3s on 16 size blocks: 1983041 aes-256 cbc's in 2.94s
    Doing aes-256 cbc for 3s on 64 size blocks: 540276 aes-256 cbc's in 2.90s
    Doing aes-256 cbc for 3s on 256 size blocks: 137713 aes-256 cbc's in 2.89s
    Doing aes-256 cbc for 3s on 1024 size blocks: 35393 aes-256 cbc's in 2.93s
    Doing aes-256 cbc for 3s on 8192 size blocks: 4384 aes-256 cbc's in 2.93s
    Doing aes-128 ige for 3s on 16 size blocks: 2375637 aes-128 ige's in 2.92s
    Doing aes-128 ige for 3s on 64 size blocks: 698695 aes-128 ige's in 2.94s
    Doing aes-128 ige for 3s on 256 size blocks: 183967 aes-128 ige's in 2.91s
    Doing aes-128 ige for 3s on 1024 size blocks: 46891 aes-128 ige's in 2.86s
    Doing aes-128 ige for 3s on 8192 size blocks: 5870 aes-128 ige's in 2.93s
    Doing aes-192 ige for 3s on 16 size blocks: 2129667 aes-192 ige's in 2.94s
    Doing aes-192 ige for 3s on 64 size blocks: 615957 aes-192 ige's in 2.90s
    Doing aes-192 ige for 3s on 256 size blocks: 159366 aes-192 ige's in 2.89s
    Doing aes-192 ige for 3s on 1024 size blocks: 40431 aes-192 ige's in 2.90s
    Doing aes-192 ige for 3s on 8192 size blocks: 4566 aes-192 ige's in 2.62s
    Doing aes-256 ige for 3s on 16 size blocks: 1874993 aes-256 ige's in 2.85s
    Doing aes-256 ige for 3s on 64 size blocks: 546698 aes-256 ige's in 2.93s
    Doing aes-256 ige for 3s on 256 size blocks: 143584 aes-256 ige's in 2.87s
    Doing aes-256 ige for 3s on 1024 size blocks: 36373 aes-256 ige's in 2.82s
    Doing aes-256 ige for 3s on 8192 size blocks: 4479 aes-256 ige's in 2.88s
    Doing idea cbc for 3s on 16 size blocks: 1616991 idea cbc's in 2.84s
    Doing idea cbc for 3s on 64 size blocks: 419827 idea cbc's in 2.85s
    Doing idea cbc for 3s on 256 size blocks: 107747 idea cbc's in 2.91s
    Doing idea cbc for 3s on 1024 size blocks: 26694 idea cbc's in 2.90s
    Doing idea cbc for 3s on 8192 size blocks: 3366 idea cbc's in 2.91s
    Doing rc2 cbc for 3s on 16 size blocks: 1456945 rc2 cbc's in 2.86s
    Doing rc2 cbc for 3s on 64 size blocks: 387618 rc2 cbc's in 2.92s
    Doing rc2 cbc for 3s on 256 size blocks: 98467 rc2 cbc's in 2.89s
    Doing rc2 cbc for 3s on 1024 size blocks: 24847 rc2 cbc's in 2.92s
    Doing rc2 cbc for 3s on 8192 size blocks: 3091 rc2 cbc's in 2.95s
    Doing blowfish cbc for 3s on 16 size blocks: 3588480 blowfish cbc's in 2.92s
    Doing blowfish cbc for 3s on 64 size blocks: 969771 blowfish cbc's in 2.92s
    Doing blowfish cbc for 3s on 256 size blocks: 244745 blowfish cbc's in 2.89s
    Doing blowfish cbc for 3s on 1024 size blocks: 63589 blowfish cbc's in 2.97s
    Doing blowfish cbc for 3s on 8192 size blocks: 7246 blowfish cbc's in 2.65s
    Doing cast cbc for 3s on 16 size blocks: 2605484 cast cbc's in 2.93s
    Doing cast cbc for 3s on 64 size blocks: 689905 cast cbc's in 2.88s
    Doing cast cbc for 3s on 256 size blocks: 158869 cast cbc's in 2.80s
    Doing cast cbc for 3s on 1024 size blocks: 44980 cast cbc's in 2.90s
    Doing cast cbc for 3s on 8192 size blocks: 6318 cast cbc's in 2.92s
    Doing 512 bit private rsa's for 10s: 2657 512 bit private RSA's in 9.77s
    Doing 512 bit public rsa's for 10s: 29891 512 bit public RSA's in 9.75s
    Doing 1024 bit private rsa's for 10s: 507 1024 bit private RSA's in 9.81s
    Doing 1024 bit public rsa's for 10s: 9986 1024 bit public RSA's in 9.80s
    Doing 2048 bit private rsa's for 10s: 79 2048 bit private RSA's in 9.53s
    Doing 2048 bit public rsa's for 10s: 2934 2048 bit public RSA's in 9.85s
    Doing 4096 bit private rsa's for 10s: 13 4096 bit private RSA's in 10.50s
    Doing 4096 bit public rsa's for 10s: 818 4096 bit public RSA's in 9.70s
    Doing 512 bit sign dsa's for 10s: 3096 512 bit DSA signs in 9.80s
    Doing 512 bit verify dsa's for 10s: 2681 512 bit DSA verify in 9.78s
    Doing 1024 bit sign dsa's for 10s: 1004 1024 bit DSA signs in 9.58s
    Doing 1024 bit verify dsa's for 10s: 877 1024 bit DSA verify in 9.78s
    Doing 2048 bit sign dsa's for 10s: 297 2048 bit DSA signs in 9.68s
    Doing 2048 bit verify dsa's for 10s: 249 2048 bit DSA verify in 9.73s
    OpenSSL 0.9.8k 25 Mar 2009
    built on: date not available
    options:bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) 
    compiler: arm-apple-darwin9-gcc -fPIC -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D__DARWIN_UNIX03 -O3 -fomit-frame-pointer -fno-common
    available timing options: TIMEB USE_TOD HZ=100 [sysconf value]
    timing function used: getrusage
    The 'numbers' are in 1000s of bytes per second processed.
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    md2                622.00k     1292.74k     1805.93k     1986.21k     2057.72k
    mdc2                 0.00         0.00         0.00         0.00         0.00 
    md4               5148.81k    17597.06k    48201.58k    87055.22k   114810.60k
    md5               2848.09k    10574.39k    31270.83k    62338.84k    91924.63k
    hmac(md5)         5699.40k    17447.20k    47914.02k    79002.57k    99462.18k
    sha1              2637.23k    10932.54k    26353.43k    39795.64k    46736.20k
    rmd160            2779.56k    11321.53k    25755.17k    38048.26k    43612.50k
    rc4              47773.27k    56599.51k    58557.60k    59161.60k    63039.10k
    des cbc           9635.72k     9613.89k     9667.79k    10654.79k    10232.71k
    des ede3          3653.46k     3665.06k     3765.64k     3665.71k     3630.81k
    idea cbc          9109.81k     9427.69k     9478.77k     9425.74k     9475.69k
    seed cbc             0.00         0.00         0.00         0.00         0.00 
    rc2 cbc           8150.74k     8495.74k     8722.34k     8713.47k     8583.55k
    rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00 
    blowfish cbc     19662.90k    21255.25k    21679.83k    21924.29k    22399.71k
    cast cbc         14227.90k    15331.22k    14525.17k    15882.59k    17725.02k
    aes-128 cbc      13307.59k    14795.96k    15493.23k    15720.14k    15818.51k
    aes-192 cbc      11921.88k    13116.31k    13726.72k    13791.27k    13682.93k
    aes-256 cbc      10792.06k    11923.33k    12198.80k    12369.43k    12257.25k
    camellia-128 cbc        0.00         0.00         0.00         0.00         0.00 
    camellia-192 cbc        0.00         0.00         0.00         0.00         0.00 
    camellia-256 cbc        0.00         0.00         0.00         0.00         0.00 
    sha256            3153.48k     7573.32k    13720.91k    17468.81k    19120.36k
    sha512             658.05k     2670.10k     3854.73k     5253.75k     5864.48k
    aes-128 ige      13017.19k    15209.69k    16184.04k    16788.95k    16411.96k
    aes-192 ige      11590.02k    13593.53k    14116.85k    14276.33k    14276.59k
    aes-256 ige      10526.28k    11941.53k    12807.49k    13207.78k    12740.27k
                      sign    verify    sign/s verify/s
    rsa  512 bits 0.003677s 0.000326s    272.0   3065.7
    rsa 1024 bits 0.019349s 0.000981s     51.7   1019.0
    rsa 2048 bits 0.120633s 0.003357s      8.3    297.9
    rsa 4096 bits 0.807692s 0.011858s      1.2     84.3
                      sign    verify    sign/s verify/s
    dsa  512 bits 0.003165s 0.003648s    315.9    274.1
    dsa 1024 bits 0.009542s 0.011152s    104.8     89.7
    dsa 2048 bits 0.032593s 0.039076s     30.7     25.6

    OpenSSL has optimizations for different architectures; if I remember correctly, when I checked the sources there were implementations using vector extensions (MMX, SSE and such) and downright assembler for Intel processors.

    So it would be interesting to see if any of those optimizations do exist for ARM (and if so, how good are they). I already had this "problem" when trying the openssl speed command to compare speeds between OS X/PowerPC and Windows/Intel: the PowerPC version seemed stupidly slow, when it should be faster, given that Seti@Home, which is supposedly actively ported and optimized, reported better speeds on the PowerPC machine.

    Of course the comparison still is interesting in that at the end of the day you get a comparison of how fast the full "stack" (CPU/hardware, compiler, sources and optimizations) is going to work; but it's difficult to get any better granularity than that.

    Would be interesting to see how would a JIT change the speeds, absolutely in each platform (vs hand-optimized vs non-optimized) and relatively between them (maybe all platforms would be closer to each other?).