+1 Usefulness

El control incómodo

2026-10-14T23:05:58.000+02:00

El primer ensayo de Rasputin con Shinka y GPT-OSS-20B funcionó. La propuesta directa del modelo siguió siendo más rápida que las cuatro salidas del proceso de búsqueda.

Después de conseguir que la Raspberry Pi minara correctamente, tocaba probar la idea que justificaba buena parte del laboratorio: utilizar un modelo local para proponer cambios y dejar que los resultados de las pruebas orientaran la búsqueda. El 6 de septiembre pusimos a trabajar a GPT-OSS-20B con Shinka. Había una referencia con la que comparar, comprobaciones independientes y una pregunta concreta. Al terminar, el sistema había ejecutado el trabajo previsto. El minero no había mejorado respecto al control directo.

Me parece un buen punto de partida para contar esta parte de Rasputin. Cuando uno dedica tiempo a conectar un modelo, un evaluador y una máquina remota, resulta bastante fácil confundir el alivio de verlos funcionar con la satisfacción de haber conseguido algo mejor. El registro se llena de candidatos, puntuaciones y comprobaciones. Todo eso acredita actividad. La utilidad del procedimiento sigue necesitando una comparación.

En la primera entrega dejamos una versión del minero que había superado una hora de funcionamiento. Para el siguiente ensayo mantuvimos fijo su código de cálculo. El modelo no tenía permiso para reescribir el ensamblador de las QPUs, las unidades de la GPU que ejecutaban los hashes. Su margen de intervención consistía en elegir cuántas utilizar: una, dos, cuatro, ocho o doce. Era un encargo deliberadamente limitado. Antes de darle más libertad, convenía averiguar si podíamos evaluar lo que propusiera.

El reparto de tareas seguía siendo el mismo. GPT-OSS-20B se ejecutaba en el PC con la NVIDIA, mediante llama.cpp y con cuantización MXFP4. Shinka organizaba las propuestas y recogía sus evaluaciones. La Raspberry Pi hacía los cálculos; una implementación independiente en CPU comprobaba los resultados. El modelo podía proponer una configuración. La medida y la corrección quedaban fuera de su criterio.

También hicimos algo menos aparatoso: pedir una propuesta directamente al modelo, sin pasar por la búsqueda de Shinka. Ese control eligió utilizar doce QPUs y obtuvo unos 53.247 hashes por segundo en el ensayo. Las cuatro propuestas de Shinka utilizaron cuatro QPUs y se movieron entre 25.582 y 26.782 hashes por segundo. Son medidas del mismo banco de prueba, con el tiempo contado por el ejecutor. No son nuevas pruebas de una hora ni cifras que debamos intercambiar con el rendimiento sostenido del primer capítulo.

Hay un detalle que cambia la lectura. La política inicial de Shinka utilizaba una sola QPU y rondaba los 7.644 hashes por segundo. Respecto a ese punto de partida, pasar a cuatro fue una mejora. Si hubiéramos enseñado únicamente esa progresión, habríamos podido contar una historia bastante agradecida sobre un sistema que aprende a optimizar. El control directo la complicaba: una respuesta del mismo modelo había elegido una configuración más rápida. Mejorar una mala referencia no basta para justificar el procedimiento que produce la mejora.

Además, aquellas cuatro propuestas repetían la misma política. Sus puntuaciones eran distintas porque las mediciones variaban, no porque hubiéramos obtenido cuatro maneras nuevas de calcular. Conviene detenerse en algo tan poco espectacular. Una lista de resultados puede dar una impresión de exploración que el código no sostiene. En un espacio de opciones tan pequeño, probar las configuraciones posibles de forma sistemática era una alternativa que el propio informe dejaba pendiente de comparación. La búsqueda con un modelo también tenía que ganarse su sitio frente a eso.

La parte que sí quedó comprobada fue la integración. Las seis evaluaciones —el control directo, la política inicial y las cuatro propuestas— acumularon 4.608 comprobaciones de hashes, todas coincidentes con la referencia independiente. El registro cuenta 24 llamadas consecutivas a la Pi, incluidas las de calentamiento, cuyos tiempos se excluían de la puntuación. La ejecución completa, con las comprobaciones previas, duró 582,5 segundos. Habíamos conseguido que una propuesta recorriera el circuito de evaluación y volviera con un resultado verificable. Era un avance de infraestructura, aunque no proporcionara una mejora del minero frente al control.

Tampoco sería serio convertir este ensayo en un veredicto sobre Shinka o sobre los modelos locales. Cuatro propuestas, una política de ejecución limitada y un programa de cálculo que no podían tocar dan para una conclusión bastante más estrecha. En esas condiciones, la búsqueda no superó la propuesta directa. Quedaban por probar otros presupuestos, otros márgenes de intervención y la comparación con una enumeración sencilla. Ninguna de esas posibilidades modifica lo que ocurrió en esta ejecución.

Para mí, el dato más útil fue conservar aquel control de doce QPUs. Obligaba a explicar por qué merecía la pena añadir el proceso de búsqueda, en lugar de dar por hecho que más pasos implicaban un método mejor. Habíamos montado el circuito necesario para seguir experimentando. La siguiente propuesta tendría que justificar su coste con algo que ese control todavía no hiciera.

La primera hora de Rasputin

2026-10-13T21:20:30.000+02:00

Antes de buscar mejoras con modelos locales, necesitábamos un minero cuyo funcionamiento pudiéramos comprobar.

Para valorar si un modelo de lenguaje ayuda a programar, me parece necesario contar también el trabajo que deja después de entregar el código. Hay que entenderlo, ejecutarlo, localizar los errores y comprobar si cumple lo que se le había pedido. En un proyecto de optimización queda, además, una cuestión pendiente: demostrar que la nueva versión mejora a la anterior. La rapidez con la que aparece una propuesta en pantalla puede tener bastante poca relación con el tiempo que exige llegar a ese resultado.

Rasputin formaba parte de un laboratorio que intentaba examinar precisamente esa relación. Disponíamos de un PC con Windows y una NVIDIA RTX 5070 Ti de 16 GB, capaz de ejecutar GPT-OSS-20B localmente mediante llama.cpp. La hipótesis era que una inferencia rápida permitiría probar más propuestas y aprovechar mejor los resultados de cada prueba. Había que averiguar si eso producía mejoras dentro de un mismo presupuesto de tiempo. Generar candidatos era una parte del experimento; disponer de una forma fiable de evaluarlos era la otra.

La máquina sobre la que queríamos intervenir era una Raspberry Pi 1. Su GPU VideoCore IV incluye unas unidades de cálculo, las QPUs, que pueden aplicar las mismas operaciones a varios datos en paralelo. El proyecto consistía en utilizarlas para ejecutar el cálculo de minería de Bitcoin. El reparto entre las dos máquinas importa: la NVIDIA ejecutaba el modelo que proponía cambios; los hashes del minero se calculaban en la Pi. La cifra de rendimiento que buscábamos mejorar correspondía a esta última.

El caso tenía algunas ventajas como experimento. Un hash tiene un resultado preciso que se puede contrastar con otra implementación. También es posible medir cuántos cálculos se completan en un intervalo. Eso nos permitía establecer condiciones de aceptación bastante concretas, algo que resulta más difícil cuando se pide a un modelo que «mejore» un texto o reorganice una aplicación. Aquí una modificación debía conservar el resultado del cálculo y justificar con medidas cualquier mejora de rendimiento.

Tampoco empezábamos desde cero. qpusha ya implementaba SHA-256 para las QPUs del BCM2835, y Rasputin parte de ese código. Había otros trabajos sobre el mismo hardware: en 2014, la propia Raspberry Pi había publicado una referencia al proyecto rpi-playground de Lorimer. Esa procedencia limita lo que podemos atribuirnos y ayuda a definir el trabajo pendiente. Había que adaptar e integrar una capacidad de cálculo existente hasta obtener un minero que pudiéramos poner a prueba.

Para organizar la búsqueda contábamos con ShinkaEvolve, que permitía generar propuestas y recoger los resultados de su evaluación. OpenEvolve y OptiLLM también estaban incorporados al laboratorio, aunque los primeros ensayos de esta rama utilizaron Shinka. Codex aportó, en otro ensayo, una propuesta de modificación del kernel. El resto del trabajo dependía de herramientas menos visibles: código de control en Python, el ensamblador de las QPUs, Docker, Bitcoin Core y una comprobación independiente en CPU. Sin esa parte, las propuestas de los modelos habrían sido difíciles de valorar.

El primer objetivo era disponer de una versión correcta que sirviera de referencia. Bitcoin aplica SHA-256 dos veces a la cabecera de un bloque; el minero modifica un campo, el nonce, y busca un resultado que cumpla el objetivo de dificultad. La documentación de Bitcoin describe ese formato y sus condiciones. Llevarlo a las QPUs exigía preparar los datos, respetar el orden de los bytes, ejecutar las dos pasadas y recoger los resultados. En aquella primera versión, las pasadas se lanzaban por separado. Las mejoras que reducirían esa intervención del procesador llegarían más adelante.

Empezamos comprobando la construcción de bloques con CPU y Bitcoin Core en modo regtest, una red privada de pruebas con dificultad reducida. Esa preparación ya permitió detectar un error: la altura del bloque estaba mal codificada en la transacción que crea la recompensa, la coinbase, y Core lo rechazaba. Hubo que corregirlo antes de continuar. El episodio ayudaba a separar los problemas del entorno de prueba de los que pudiera introducir el código de la GPU. Aquel control con CPU, por cierto, no proporcionó una comparación de velocidad equivalente; no tenemos un multiplicador CPU/GPU que pueda deducirse de él.

La comprobación de las QPUs tuvo varias partes. En una prueba se obtuvieron 102.400 hashes que se recalcularon de forma independiente y se compararon byte a byte. En otra, un resultado producido por las QPUs permitió construir un bloque que Bitcoin Core aceptó en regtest, a altura 4. La primera examinaba el cálculo; la segunda comprobaba su integración. Todavía no habíamos probado la conexión a un pool público.

El 6 de septiembre quedó registrada la primera prueba de una hora: 195.801.024 hashes contabilizados en 3.600,33 segundos, unos 54.384 por segundo. Se utilizaron doce QPUs, sin reinicios, con un máximo de 61,6 °C y sin limitación de frecuencia reportada. También se comprobó el estado del sistema y la liberación de recursos al terminar. Durante esa hora se conservaron sesenta muestras de resultados que volvieron a verificarse. Eso no equivale a recalcular de manera independiente los casi 196 millones de intentos, y conviene mantener la distinción al contar el resultado.

Algo más de un mes después, el 13 de octubre, Rasputin completaría una observación de un día conectado a CKPool: 1,288 millones de intentos por segundo de media, con 32 participaciones aceptadas y ninguna rechazada, repartidos en 25 sesiones. Esas participaciones acreditan trabajo aceptado por el pool; no son bloques encontrados en la red pública. La distancia entre ambas etapas contiene buena parte de la historia del proyecto, pero no permite atribuir toda la mejora a una herramienta o a una sola idea.

La primera hora dejó una referencia que podíamos conservar. A partir de ella, las propuestas de GPT-OSS-20B, los ensayos con Shinka y los cambios de código podían evaluarse frente a un comportamiento conocido. Ése era el trabajo previo necesario para estudiar la utilidad de los modelos: decidir cómo reconoceríamos una mejora antes de pedirles que la encontraran.

What's the minimum PHP version supported by Composer?

2015-10-15T12:25:00.000+02:00

Composer requires PHP version 5.3.2 or higher. For reference see:

their documentation
their README
their own composer.json

Panic's Coda and Ruby's Pry integration

2011-10-27T13:24:00.001+02:00

Adding a few things here and there and you will integrate the awesome Pry edit command with your Panic's Coda editor. You will need the great Coda CLI tool and you will have to apply my pull request (if it's not already done in the master branch) that adds the "go to line number" feature. Alternatively you can clone my own fork of the project with my changes applied.

Follow the instructions to install Coda CLI after applying the fix and then:

$ coda --help
Usage: coda [options] [file ...]
Options:
-h, --help show this help message and exit
-w, --wait wait for file to be closed
-d, --change-dir change Coda's working directory
-n, --new-window open in a new window
--ls-tabs show all open tabs
--version print version information and quit
-l LINENUMBER, --line=LINENUMBER
set the current line number of the editor
To read input from stdin, use a pipe or pass `-` for [file]
Piping output from coda implies `-w`.

Now you can do "coda -l 2 ~/.profile " to go to line 2 of your .profile file

Now the Pry part: you have to add some options into your .pryrc:

$ coda ~/.pryrc

Add the following line and save the file:

Pry.config.editor = proc { |file, line| "coda -l #{line} -w #{file}" }

That's it! Now in your pry console you can run "edit-method object.yourtmethod" and it will open Coda and position the cursor selection into the right line number. Please pry for me!

Resources:

Upgrade to Ruby 1.9.2, Rails and Psych lib

2011-09-22T19:51:00.000+02:00

When I tried to upgrade my app to use the new Ruby 1.9.2, I faced some errors thrown right away after running rails s. The errors were related to a merge! call from the Psych lib. It turns out that the Psych lib is used as the new YAML parser and could break things in your Rails application.

So after a 20 min research I found a couple of post, patches, etc. Finally the solution was to add this at the top of your application.rb file to switch back to the old YAML parser syck.

Resources:

[Fixed] Boot Camp partition error

2011-09-06T11:52:00.000+02:00

After some days of having to deal with this issue I finally got it fixed. I read several post in lots of forums and I can assure you that this is the final solution, without the need to buy any kind of software :D
First let's have a look at the error that Boot Camp throw at us:

The disk cannot be partitioned because some files cannot be moved.
Back up the disk and use Disk Utility to format the disk as a single Mac OS Extended (Journaled) volume. Restore your information to the disk and try using Boot Camp Assistant again.

Wow, that sounds very risky to me. I started to look for a solution for this and several hours later I stepped by with this post: https://discussions.apple.com/thread/1545380. Basically, what it's saying is that instead of letting the Boot Camp Assistant do the resize, you have to do it with the Disk Utility. The Disk Utility will try to move those "Cannot-Be-Moved" files, resizing your own partition and later, you will restore it with faith in that the files be now moved from the bottom of your hard drive.
This made sense to me, so I gave it a try and 20 mins later It also failed. BUT with good news, because it thrown a new error:

Partition failed
Partition failed with the error:
The partition cannot be resized. Try reducing the amount of change in the size of the partition.

The later led me to this great superuser post: http://superuser.com/questions/72896/cannot-resize-os-x-partition. The most voted answer said something that I've already seen about iDefrag. But I don't want to pay to fix this! If you keep reading there's a great, much commonsense answer: http://superuser.com/questions/72896/cannot-resize-os-x-partition/291378#291378.
Now I'm going to describe this manual proper solution. It's a kind of lengthy process but I can say that it works! You have to open the "Console" app, click in "All Messages" and search for the word "hfs_". In there you will see a bunch of log lines: take a look at the one that says something like:

hfs_reclaimspace: Error reclaiming datafork blocks of fileid=57695517

You have to copy the "fileid" number. Then you open your "Terminal" app and execute the following command:

sudo find -x / -inum 57695517

It will ask you for your password, this way it can run with full root privilege and also look in those restricted folders. The number after -inum is the number you had previously saved . What this command does is to search in your harddrive (that's the -x for), starting at the root of your filesystem (that's the / for), and try to find the file with the inode number 57695517 (in your case will be another number). You run this with sudo to have access to all the filesystem. When it finishes you will see the path of one file. Grab that file and move it to a safe location or just delete it if you don't need it.

Now run the disk utility again. It may fail again and you will have to repeat the find-the-inum process until you moved all those bad files.
After a couple of tries the Disk Utility finally succeed in shrinking your partition. Now you have to do the oposite resize operation and restore your disk to the seize it had. Then go back to the Boot Camp Assistant and retry the partition process, it should succeed without any issues!

Resources:

[Fixed] MySQL, MacPorts and OS X Snow Leopard

2011-08-19T13:10:00.000+02:00

After almost a year of having installed Mac OS X Snow Leopard and the 1.8.x MacPort and after several failed tries, I finally worked out the issues I had when installing MySQL using MacPorts. My issue was somehow similar to this one: mysql_install_db5 works without '--user=_mysql' option, but mysql.user table not populated, where the mysql root password can't be set. Basically, after doing:

> sudo port install mysql5-server

And follow the steps by steps instructions:

> sudo mysql_install_db5 --user=_mysql

I ended with the directory /opt/local/var/db/mysql5 somehow corrupted. It seems that I, maybe, already had a old installation of MySQL, so the install scripts couldn't reset the permissions for the correct mysql user (which is _mysql). So to solve this I did:

> sudo port uninstall mysql5-server
> sudo rm -rf /opt/local/var/db/mysql5

Deleting the problematic dir and then re-installing:

> sudo port install mysql5-server
> sudo -u _mysql mysql_install_db5

Set the root password and securing the MySQL installation:

> /opt/local/lib/mysql5/bin/mysqladmin -u root password 'new-password'
> sudo /opt/local/share/mysql5/mysql/mysql.server start
> sudo /opt/local/lib/mysql5/bin/mysql_secure_installation

So that's it. I finally have my working MySQL database working! Yeaaah!

Resources:

[Google+] How to edit the privacy setting for the photos and videos?

2011-08-15T01:10:00.000+02:00

Last month I was invited to the new Google+ social network. It looked cool, so I also connected my Picasa account into it without realizing that when doing it, all my personal photos and videos where suddenly public. Don't get me wrong, the albums I'm sharing in my picasaweb dashboard are all public, but I don't like the idea of people searching for me in Google and see all my life there, for everyone to see. This is the similar issue that Facebook once had but luckily for us FB fixed that and Google also let's you edit the privacy settings for the photos and videos of your picasa account.

So it is very easy to restrict the visibility of your photos and videos tab in your Google+ profile:

Login into your Google+ account and go to your Plus Settings page
Select the Google+ section and scroll to the bottom of the page.

Now click on those photos and videos links to edit the privacy of each of them.
Now uncheck the checkbox "Show this tab on your profile"

And that's it. Now your Google+ will hide the Photos and the Videos tabs from displaying public in your profile page.

How to get an RSS feed out of an Amazon Wish List?

2011-08-02T12:02:00.000+02:00

You have 2 ways to get an RSS out of a Wish List:

You just Sign you in using your Twitter account, add your Amazon Wish List and then you will see the orange feed (Rss) icon. That's the URL of your feed. Piece of cake!

Anonymous way (advanced users)

Go to your Amazon Wish List and get the URL from the "Share with friends" tool. Double url encode it using DuckDuckGo: http://duckduckgo.com/?q=urlencode+. Just remember to do it twice. Then build the url of your feed like this:

http://www.wishandbam.com/list/[your_double_encoded_url_here]/20/rss

That's it. If you want more than 20 items to show up in your feed, increase the number at the end of the url.

Disclaimer: I am writing this post here in a follow up of my personal small project called Wish and BAM!. Wishandbam.com lets you Auto Tweet the items you add into your Amazon Wish List. But it also gives you a great way to do what ever you want with your Wish List, because it also provides you with a RSS Feed of it. Here I'm going to copy the post I wrote in the support site (How to get an RSS feed out of my Amazon Wish List? @getsatisfaction)

[Fixed] Why Google Chrome is Slow?

2011-07-11T20:31:00.000+02:00

In the last 3 or 4 months I started to note that my Google Chrome was way slower than it was. In fact it was so slow that it started to pissed me off. I thought it was something with my MacBook Pro, after all it has almost 3 years old and already started to note some hardrive issues with it.
Luckily, I decided to, somehow, fix or (at least) improve my Google Chrome performance. So first thing, first I googled it. After a few minutes of reading and taking note of the dates in the replies I extracted a few possible solutions:

It seemed that it wasn't my HD. Lots of people're asking about the same, some were migrating back to Firefox, others, like me, still believing..
Couldn't find the "Use DNS pre-fetching to improve page load performance." option in my current Chrome version (v12). So I figured out the equivalent of that is "Predict network actions to improve page load performance"and turned that Off.
Also, as I am on a Mac, I applied another solution: turned Off the IPV6 TCP/IP features in my Network > System Settings.

These seems to have solved my problems, let's see for how long. I will update this post in the future if things aren't improving. Let me know if you found any other working solutions to improve the performance of this great browser.

How to remove a Google Analytics account

2011-02-21T18:18:00.000+01:00

I was taking a look at how to insert the Analytics's tracking code into this Blogger blog and somehow I ended up with two, exactly equal, accounts in my Dashboard. I wanted to get rid of the duplicated one, and guess what? I couldn't find how to delete my Google Analytic account! Well, I do know now thanks to this link: Now it's easier to delete accounts by Dai Pham, Google Analytics Team

So the quick answer is:

Go to your Analytics Settings page at https://www.google.com/analytics/settings/home
Click in the "Edit" link, under the Actions column. You will enter in the edit options for the account you want to remove.
Now check out the "Delete account" link, just under the the "Default Time Zone" option. Click that link and that's all!

Where to find the Google OpenID URL?

2011-02-20T22:44:00.000+01:00

So, you want to get a pass to your preferred website and it let's you login using OpenID. You also have a Google account, and you also know that Google is an OpenID provider.

The issue now is that the website is asking you for the URL of your OpenID Google Profile. So what a hell is that?

The Google Profile URL is the address of your Google account. BUT not all accounts have a profile. To get your URL or create a Google Profile:

Go to http://www.google.com/profiles
Click "Create my Profile". This means that you haven't any Profile yet.
If you already have one, click "View my Profile" and then click "Edit Profile" at the right top menu.

Edit your Profile info and scroll down until the bottom. If your profile is a new one, you have to complete the textbox input to have a Google OpenID URL and hit "Create a Google Profile".

You should now have a profile URL. You can copy it, remember it and use it everywhere where the OpenID protocol is supported. So that's all, you now have a Google Profile URL and a OpenID username for your preferred website.