Minar ethereum


  • Minador
  • Ubuntu Server 16.04
  • Opcional(tarjeta de video)
  • Python y python-twisted
  • Ethereum
  • cpp-ethereum

NOTA: Se considera Ubuntu Server, en caso de Ubuntu Desktop algunos requerimientos ya vienen instalados en el sistema.


  1. Instalar ubuntu 16.04

  2. Instalar python y python-wisted

sudo apt-get install python
sudo apt-get install python-twisted
  1. Un vez que se tiene instalado el sistema operativo, activar el ppa de ethereum
sudo add-apt-repository ppa:ethereum/ethereum
sudo add-apt-repository ppa:ethereum/ethereum-qt
sudo add-apt-repository ppa:ethereum/ethereum-dev
sudo apt-get update
  1. Instalar ethereum
sudo apt-get install ethereum
  1. Instalar cpp-ethereum
sudo apt-get install cpp-ethereum
  1. Clonar el repositorio de eth-proxy.

  2. Crear un wallet con geth o parity.

  3. Instalar los drivers de vídeo, en el caso de usar una tarjeta de vídeo.

  4. Modificar el archivo de configuración de eth-proxy para usar el wallet.

  5. En el directorio eth-proxy, ejecutar eth-proxy.py

sudo python eth-proxy/eth-proxy.py
  1. Ejecutar ethminer apuntando a localhost
ethminer -F -G

NOTA: La opción -G indica a ethminer que utilice GPU para minar, en caso de no contar con GPU utilice --allow-opencl-cpu.


https://github.com/paritytech/parity https://github.com/Atrides/eth-proxy https://launchpad.net/~ethereum/+archive/ubuntu/ethereum http://ethdocs.org/en/latest/ethereum-clients/cpp-ethereum/installing-binaries/linux-ubuntu-ppa.html

Crowdtesting with the Ubuntu community: the case of IPFS

Here at Ubuntu we are working hard on the future of free software distribution. We want developers to release their software to any Linux distro in a way that's safe, simple and flexible. You can read more about this at snapcraft.io.

This work is extremely fun because we have to work constantly with a wild variety of free software projects to make sure that the tools we write are usable and that the workflow we are proposing makes sense to developers and gives them a lot of value in return. Today I want to talk about one of those projects: IPFS.

IPFS is the permanent and decentralized web. How cool is that? You get a peer-to-peer distributed file system where you store and retrieve files. They have a nice demo in their website, and you can give it a try on Ubuntu Trusty, Xenial or later by running:

$ sudo snap install ipfs

screenshot of the IPFS peers

So, here's one of the problems we are trying to solve. We have millions of users on the Trusty version of Ubuntu, released during 2014. We also have millions of users on the Xenial version, released during 2016. Those two versions are stable now, and following the Ubuntu policies, they will get only security updates for 5 years. That means that it's very hard, almost impossible, for a young project like IPFS to get into the Ubuntu archives for those releases. There will be no simple way for all those users to enjoy IPFS, they would have to use a Personal Package Archive or install the software from a tarball. Both methods are complex with high security risks, and both require the users to put a lot of trust on the developers, more than what they should ever trust anybody.

We are closing the Zesty release cycle which will go out in April, so it's too late there too. IPFS could make a deb, put it into Debian, wait for it to sync to Ubuntu, and then it's likely that it will be ready for the October release. Aside from the fact that we have to wait until October, there are a few other problems. First, making a deb is not simple. It's not too hard either, but it requires quite some time to learn to do it right. Second, I mentioned that IPFS is young, they are on the 0.4.6 version. So, it's very unlikely that they will want to support this early version for such a long time as Debian and Ubuntu require. And they are not only young, they are also fast. They add new features and bug fixes every day and make new releases almost every week, so they need a feedback loop that's just as fast. A 6 months release cycle is way too slow. That works nicely for some kinds of free software projects, but not for one like IPFS.

They have been kind enough to let me play with their project and use it as a test subject to verify our end-to-end workflow. My passion is testing, so I have been focusing on continuous delivery to get happy early adopters and constant feedback about the most recent changes in the project.

I started by making a snapcraft.yaml file that contains all the metadata required for the snap package. The file is pretty simple and to make the first version it took me just a couple of minutes, true story. Since then I've been slowly improving and updating it with small changes. If you are interested in doing the same for your project, you can read the tutorial to create a snap.

I built and tested this snap locally on my machines. It worked nicely, so I pushed it to the edge channel of the Ubuntu Store. Here, the snap is not visible on user searches, only the people who know about the snap will be able to install it. I told a couple of my friends to give it a try, and they came back telling me how cool IPFS was. Great choice for my first test subject, no doubt.

At this point, following the pace of the project by manually building and pushing new versions to the store was too demanding, they go too fast. So, I started working on continuous delivery by translating everything I did manually into scripts and hooking them to travis-ci. After a few days, it got pretty fancy, take a look at the github repo of the IPFS snap if you are curious. Every day, a new version is packaged from the latest state of the master branch of IPFS and it is pushed to the edge channel, so we have a constant flow of new releases for hardcore early adopters. After they install IPFS from the edge channel once, the package will be automatically updated in their machines every day, so they don't have to do anything else, just use IPFS as they normally would.

Now with this constant stream of updates, me and my two friends were not enough to validate all the new features. We could never be sure if the project was stable enough to be pushed to the stable channel and make it available to the millions and millions of Ubuntu users out there.

Luckily, the Ubuntu community is huge, and they are very nice people. It was time to use the wisdom of the crowds. I invited the most brave of them to keep the snap installed from edge and I defined a simple pipeline that leads to the stable release using the four available channels in the Ubuntu store:

  • When a revision is tagged in the IPFS master repo, it is automatically pushed to edge channel from travis, just as with any other revision.
  • Travis notifies me about this revision.
  • I install this tagged revision from edge, and run a super quick test to make sure that the IPFS server starts.
  • If it starts, I push the snap to the beta channel.
  • With a couple of my friends, we run a suite of smoke tests.
  • If everything goes well, I push the snap to the candidate channel.
  • I notify the community of Ubuntu testers about a new version in the candidate channel. This is were the magic of crowd testing happens.
  • The Ubuntu testers run the smoke tests in all their machines, which gives us the confidence we need because we are confirming that the new version works on different platforms, distros, distro releases, countries, network topologies, you name it.
  • This candidate release is left for some time in this channel, to let the community run thorough exploratory tests, trying to find weird usage combinations that could break the software.
  • If the tag was for a final upstream release, the community also runs update tests to make sure that the users with the stable snap installed will get this new version without issues.
  • After all the problems found by the community have been resolved or at least acknowledged and triaged as not blockers, I move the snap from candidate to the stable channel.
  • All the users following the stable channel will automatically get a very well tested version, thanks to the community who contributed with the testing and accepted a higher level of risk.
  • And we start again, the never-ending cycle of making free software :)

Now, let's go back to the discussion about trust. Debian and Ubuntu, and most of the other distros, rely on maintainers and distro developers to package and review every change on the software that they put in their archives. That is a lot of work, and it slows down the feedback loop a lot, as we have seen. In here we automated most of the tasks of a distro maintainer, and the new revisions can be delivered directly to the users without any reviews. So the users are trusting directly their upstream developers without intermediaries, but it's very different from the previously existing and unsafe methods. The code of snaps is installed read-only, very well constrained with access only to their own safe space. Any other access needs to be declared by the snap, and the user is always in control of which access is permitted to the application.

This way upstream developers can go faster but without exposing their users to unnecessary risks. And they just need a simple snapcraft.yaml file and to define their own continuous delivery pipeline, on their own timeline.

By removing the distro as the intermediary between the developers and their users, we are also making a new world full of possibilities for the Ubuntu community. Now they can collaborate constantly and directly with upstream developers, closing this quick feedback loop. In the future we will tell our children of the good old days when we had to report a bug in Ubuntu, which would be copied to Debian, then sent upstream to the developers, and after 6 months, the fix would arrive. It was fun, and it lead us to where we are today, but I will not miss it at all.

Finally, what's next for IPFS? After this experiment we got more than 200 unique testers and almost 300 test installs. I now have great confidence on this workflow, new revisions were delivered on time, existing Ubuntu testers became new IPFS contributors and I now can safely recommend IPFS users to install the stable snap. But there's still plenty of work ahead. There are still manual steps in the pipeline that can be scripted, the smoke tests can be automated to leave more free time for exploratory testing, we can release also to armhf and arm64 architectures to get IPFS into the IoT world, and well, of course the developers are not stopping, they keep releasing new interesting features. As I said, plenty of opportunities for us as distro contributors.

screenshot of the IPFS snap stats

I'd like to thank everybody who tested the IPFS snap, specially the following people for their help and feedback:

  • freekvh
  • urcminister
  • Carla Sella
  • casept
  • Colin Law
  • ventrical
  • cariboo
  • howefield


If you want to release your project to the Ubuntu store, take a look at the snapcraft docs, the Ubuntu tutorials, and come talk to us in Rocket Chat.

Maperespeis #2: Volcán Poás

El domingo pasado fuimos a hacer mapas libres al Volcán Poás.

Esta es la segunda excursión geek del JaquerEspéis. De la primera aprendimos que había que esperar al verano porque con tormenta no se puede mapear. Y el día fue perfecto. No sólo estuvo soleado, sino que el cráter estaba totalmente despejado y así pudimos agregar un nuevo lugar al tour virtual de Costa Rica.

Además, esta vez llegamos mucho mejor preparados, con varios teléfonos con mapillary, osmand y OSMTracker, una cámara 360, un GPS Garmin, un dron y hasta una libreta y dos biólogos.

La procesión del MaperEspeis

Así funciona el asunto. Todos y todas con el GPS del teléfono activado esperamos a que el teléfono encuentre la ubicación. Después cada persona usa la aplicación que prefiere para recolectar datos: fotos, audios, videos, notas de texto, trazas, anotaciones en la libreta...

Luego, en nuestras respectivas casas, subimos, publicamos y compartimos todos los datos recolectados. Estos nos sirven para mejorar los mapas libres de OpenStreetMap. Agregamos desde cosas tan sencillas como la ubicación de un basurero hasta cosas tan importantes como qué tan accesible es el lugar para una persona en silla de ruedas, junto con la ubicación de todos estos accesos o las partes en las que faltan. Cada persona mejora el mapa un poquito, en la zona que conoce o por la que pasó. Con más de 3 millones de usuarios, OpenStreetMap es el mejor mapa del mundo que existe; y es de particular importancia en zonas como la nuestra, que tienen poco potencial económico para las megacorporaciones que hacen y venden mapas cerrados robando datos privados a sus usuarios.

Como los mapas que hacemos son libres, lo que sigue no tiene límites. Hay grupos trabajando en reconstrucción de modelos tridimensionales a partir de las fotos, identificación e interpretación de señales y rótulos, aplicaciones que calculan la ruta óptima para llegar a cualquier lugar usando cualquier combinación de medios de transporte, aplicaciones para asistir en la toma de decisiones al diseñar el futuro de una ciudad, y muchas otras cosas más. Todo basado en conocimiento compartido y comunidad.

La imagen de arriba es el tour virtual en Mapillary. Como lo grabamos con la cámara 360, pueden hacer clic y arrastrar con el mouse para ver todos los ángulos. También pueden hacer clic arriba, en el botón de reproducir para seguir el camino que tomamos. O pueden hacer clic en cualquier punto verde en el mapa para seguir su propio camino.

Muchas gracias a todos y todas por apuntarse a mapear, en especial a Denisse y Charles por servirnos de guías y llenar el paseo de datos interesantes sobre la flora, fauna, geología e importancia histórica del Poás.

Miembros del MaperEspeis (Aquí más fotos y videos)

El próximo maperespeis será el 12 de marzo.

Call for testing: MySQL

I promised that more interesting things were going to be available soon for testing in Ubuntu. There's plenty coming, but today here is one of the greatest:

$ sudo snap install mysql --channel=8.0/beta

screenshot of mysql snap running

Lars Tangvald and other people at MySQL have been working on this snap for some time, and now they are ready to give it to the community for crowd testing. If you have some minutes, please give them a hand.

We have a testing guide to help you getting started.

Remember that this should run in trusty, xenial, yakkety, zesty and in all flavours of Ubuntu. It would be great to get a diverse pool of platforms and test it everywhere.

In here we are introducing a new concept: tracks. Notice that we are using --channel=8.0/beta, instead of only --beta as we used to do before. That's because mysql has two different major versions currently active. In order to try the other one:

$ sudo snap install mysql --channel=5.7/beta

Please report back your results. Any kind of feedback will be highly appreciated, and if you have doubts or need a hand to get started, I'm hanging around in Rocket Chat.

Soluciones modernas para usar firma digital desde la web

En el mundo de los estándares web no ha habido ni hay (por ahora) un mecanismo que permita acceder a dispositivos de seguridad para poder firmar digitalmente. Mientras avanzan los esfuerzos en este sentido y con cierto retraso, en estos años han existido diversas formas no estándar para poder firmar, siendo todas ellas soluciones propietarias de cada navegador o bien utilizando tecnologías de complementos. Una de las más extendidas por su portabilidad era un firmador en Java utilizando applets, pero esta tecnología se está eliminando de los navegadores modernos y también siendo eliminada en futuras versiones de Java.

En la actualidad hay navegadores modernos como Edge que no disponen de ninguna forma de agregar complementos que permitan ejecutar código privilegiado y hasta la fecha no hay planes todavía para ello. Estos cambios fuerzan a utilizar formas más ingeniosas para resolver este problema de falta de interacción de sistemas de firma digital con los nuevos navegadores.

Afortunadamente existe una posible solución para comunicar sitios web con el hardware sin necesidad de complementos especiales en el navegador. La empresa que desarrolla y mantiene el proyecto DSS utiliza una técnica sencilla pero eficaz, mediante una aplicación de escritorio que ejecuta un servicio escuchando en un puerto en particular que tiene privilegios para acceder a los dispositivos de firma digital, los sitios web pueden comunicarse con este servicio local y enviarle la información que debe ser firmada y el resto del proceso se realiza en el lado de la web. Una de las aplicaciones existentes que utilizan esta técnica es software libre y se llama NexU, el cual se ha integrado en DSS a partir de la reciente versión 4.7.0, la cual ha decidido utlilizarla como reemplazo a los obsolescentes applets y JNLP.

Demostración de firma sin complementos de navegador

En el momento de escribir esto, he encontrado en línea una instalación de la WebApp de DSS 4.7 para poder probar NexU, que una vez descargado hay que ejecutar el jar que contiene el zip y recargar la página de la webapp, que detectará que se está ejecutando y el botón de formulario Install NexU cambiará a Submit. Para ejecutar el jar en GNU/Linux hay que tener instalado OpenJFX, que se explica en una entrada de blog previa. Para probarlo se puede desde una terminal mediante java -jar nexu.jar y manteniendo la terminal abierta. Para verificar que el servicio está ejecutándose correctamente se puede ingresar en el navegador en el sitio http://localhost:9776/nexu-info, donde debería aparecer un pequeño objeto JSON con la versión de la aplicación.

El problema del contenido mixto

El sitio web enlazado podría funcionar con HTTPS y el servicio local con HTTP, por lo que los navegadores modernos suelen bloquear esta comunicación. En Chromium aparece el icono de un escudo en la parte derecha de la barra de direcciones, donde haciendo clic se puede permitir la carga insegura y en Firefox aparece un candado verde con un triángulo gris con una exclamación, donde haciendo clic y a continuación en la parte derecha donde aparece un símbolo “>” se puede deshabilitar la carga insegura y finalmente el sitio web podrá acceder al servicio local.

A partir de las versiones 1.6.x de NexU se soporta HTTPS, una solución a este problema sería modificar la WebApp de DSS para que conecte a local por HTTPS y que exista un certificado para un host local, confiado e instalado en la máquina para que permita el acceso seguro a localhost y evitar el inconveniente del contenido mixto. La versión de NexU que sugiere DSS de momento es la 1.3, que no soporta HTTPS, por lo que debe descargarse la 1.6.2 o la 1.7 aparte y hacer los ajustes necesarios a DSS. En cualquier caso si bien la confianza SSL a localhost no se puede realizar con autoridades de certificación públicas, disponer de un nombre de host apuntando a con una CA autofirmada, creada en la propia máquina, instalada y confiada y con ella firmando un certificado (para luego desechar la clave privada de la CA por seguridad) evita este problema. Otra opción sería usar un servidor seguro intermedio que se comunique con la aplicación de escritorio y el sitio web por backend, aunque esta opción también es relativamente compleja y requiere configuración a una dirección específica que haga conexión permanente desde la aplicación que accede a la tarjeta y mantener la comunicación abierta mientras esté el firmador en ejecución, pero esta solución requiere infraestructura adicional y la misma herramienta se alejaría de ser multipropósito sin previa actualización de la configuración.

Escenario ideal

Si bien esta solución es relativamente nueva y requiere algunos ajustes de configuración y previamente instalar la herramienta de acceso a la tarjeta, se perfila como una solución viable para poder realizar firma digital en la web de manera interoperable y multiplataforma. La posibilidad de que existieran actualizaciones a los instaladores de Firma Digital actuales del país contemplando la preinstalación de una herramienta de este estilo abriría la posibilidad de poder integrar esta solución en sistemas Windows, GNU/Linux y macOS y de que las instituciones adoptaran este mecanismo para solucionar el problema con los navegadores modernos.

Cómo firmar documentos PDF con firma digital de Costa Rica con software libre

Actualización: he publicado un nuevo artículo con una herramienta propia que simplifica la firma de PDF en el siguiente enlace: Firmador digital de documentos para Costa Rica.

La información de este artículo ha quedado obsoleta.

La Política de Formatos Oficiales de los Documentos Electrónicos Firmados Digitalmente de Costa Rica especifica el tipo de documentos y su formato de firma digital. En el caso de PDF se utiliza un estándar especificado en Europa para firma digital avanzada (AdES) y en el caso de los PDF se llama PAdES. En el documento oficial enlazado previamente se muestra que tiene que soportar PAdES-LTV (permite la validación de forma longeva) y sugiere que se use el perfil Baseline. El asunto es que no hay mucho software libre en el mercado que permita la firma digital avanzada en PDF, sin embargo la propia Comisión Europea tiene un proyecto para ello (Digital Signature Services), que es un conjunto de librerías y herramientas en Java que permiten trabajar con firma digital con los estándares europeos, incluyendo soporte para PDF.

Hasta no hace mucho tiempo, una de las pocas implementaciones libres para trabajar con firma digital avanzada en PDF era iText, sin embargo este proyecto cambió de licencia y las condiciones de uso contradecían la propia licencia, además de presuntas incompatibilidades en contribuciones del código por parte de terceros que la hacían incompatible con la nueva licencia. Afortunadamente, el proyecto DSS (usando Apache PDFBox como alternativa a iText) permite firmar documentos PDF cumpliendo con la política de formatos oficiales nacional.

Instalación en GNU/Linux

Existe un firmador en formato independiente que funciona en el escritorio. Se puede descargar DSS standalone app package 5.1 (este es el más reciente en el momento de escribir esta entrada de blog).

Una vez descargado, descomprimir el archivo, contendrá dss-app.jar y un par de scripts para lanzar el jar de forma sencilla. El firmador que hay dentro del jar utiliza por defecto un servidor TSA europeo, para cambiarlo habrá que modificar un fichero que hay dentro del jar en la ruta spring/applicationContext.xml y buscar el texto: http://tsa.belgium.be/connect para reemplazarlo por el siguiente: http://tsa.sinpe.fi.cr/tsahttp/ y guardarlo modificado con este cambio dentro del archivo jar (un archivo jar es un archivo zip realmente).

Para poder ejecutar este jar en GNU/Linux se necesita el JRE de OpenJDK 8 y además OpenJFX 8 (JavaFX). En Fedora se instala java-1.8.0-openjdk-openjfx y en Ubuntu se instala openjfx.

Una vez instaladas las dependencias de Java, se puede ejecutar desde la terminal en la carpeta donde se haya descomprimido con sh dss-run.sh o bien con java -jar dss-app.jar.

Firmado de un documento PDF

En fichero a firmar (File to sign) se selecciona el documento PDF que se desea firmar digitalmente.

En formato de firma (Signature format) se debe elegir PAdES porque se trata de un PDF.

En PAdES solamente existe el formato envuelto (Enveloped), por lo que este campo lo selecciona automáticamente.

En el nivel (Level) se elige el nivel de perfil de PAdES. PAdES-BASELINE-LTA es el equivalente a PAdES-LTV.

En algoritmo de resumen hash encriptado (Digest algorithm) se recomienda que sea como mínimo de tipo SHA-2, en la imagen de ejemplo se ha seleccionado SHA-512.

En Signature token API se tiene que seleccionar PKCS #11, entonces se desplegará PKCS #11 library donde hay que especificar dónde está la librería del módulo de Firma Digital (libASEP11.so).

En contraseña (Password) se ingresa el PIN de la tarjeta de Firma Digital.

Cuando se presione sobre Sign se iniciará el proceso de firmado y tras unos segundos aparecerá una ventana para guardar el PDF generado en la ubicación que se desee.

Eso es todo. El documento PDF ya tiene una firma válida en el país.

Existen formas de validar la firma del documento PDF con software libre (para no tener que usar Acrobat Reader DC como en este ejemplo), pero se explicará en próximas entradas de blog.

Aunque este firmador no tiene campo de estampa visible (“firma visible”), la política de documento oficial no indica que el documento requiera disponer este detalle visual en los PDF.

Autotools básico

Autotools son un conjunto de herramientas para crear paquetes de código fuente utilizando las herramientas de construcción de GNU (Autoconf, Automake y Libtool) a partir de uno o más ficheros de código fuente y los ficheros configure.ac y Makefile.am.


Esta guía muestra cómo a partir de un fichero fuente holamundo.c y el par de ficheros mencionados anteriormente se generará un archivo llamado holamundo-1.0.0.tar.gz que una vez desempaquetado se pueda compilar e instalar con el típico “./configure && make && sudo make install“.

En una próxima entrada se explicará cómo trabajar con dependencias (librerías).


  • Portabilidad, permite generar makefiles compatibles con diferentes implementaciones de Make, múltiples compiladores e intérpretes y generar scripts compatibles con múltiples shell.
  • Multiplataforma, los scripts generados facilitan las comprobaciones y configuraciones necesarias para generar una compilación cruzada, por ejemplo generar binarios para otra arquitectura agregando pocos parámetros.


  • autoconf, se encarga de generar el script configure a partir del fichero configure.ac.
  • automake, genera el fichero Makefile.in a partir del fichero Makefile.am.
  • libtool, gestiona la creación de librerías estáticas y dinámicas, y también la carga (en tiempo de ejecución) de librerías dinámicas.

Dentro del paquete autoconf hay otras herramientas relevantes como aclocal y autoheader. En este ejemplo básico se ejecutan de forma automática todas las herramientas mencionadas utilizando la herramienta autoreconf.

Herramientas relacionadas

  • make, procesa archivos Makefile. Existen varias implementaciones (GNU Make, BSD Make…) con algunas incompatibilidades que autotools solventa.
  • pkg-config, facilita información sobre la mayoría de las librerías instaladas en el sistema (ubicación, dependencias, versión, etc.).

¡Hola, Autotools!

Para crear el ejemplo básico de paquete es conveniente disponer de una carpeta de trabajo para tenerlo mejor organizado.

  • Crear una carpeta holamundo con una subcarpeta src para el código fuente y a continuación ubicarse en la carpeta de trabajo:
mkdir -p holamundo/src
cd holamundo


  • Crear un fichero de código fuente C en src/holamundo.c:
#include <stdio.h>

int main() {
    printf("Hola Mundo!\n");

    return 0;


  • Crear un fichero Makefile.am:
bin_PROGRAMS = holamundo
holamundo_SOURCES = src/holamundo.c


  • Ejecutar la herramienta autoscan en la carpeta de trabajo. Creará un fichero llamado configure.scan que hay que renombrar a configure.ac:
mv configure.scan configure.ac

Nos habrá generado un fichero configure.ac parecido al siguiente:

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.


# Checks for programs.

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.

  • Modificar la macro AC_INIT del fichero configure.ac para mostrar el nombre del paquete, versión y dirección para avisar sobre errores (correo electrónico o web):
AC_INIT([holamundo], [1.0.0], [****@fran.cr])
  • Agregar la macro AM_INIT_AUTOMAKE en el fichero configure.ac para poder generar los Makefiles. Un buen lugar sería después de la línea de AC_CONFIG_HEADERS:
AM_INIT_AUTOMAKE([foreign subdir-objects])

Una vez modificado el fichero configure.ac debería ser parecido al siguiente:

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_INIT([holamundo], [1.0.0], [****@fran.cr])
AM_INIT_AUTOMAKE([foreign subdir-objects])

# Checks for programs.

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.


Generar configure y Makefile.in

  • Ejecutar:
autoreconf -i

Generar Makefile


Generar paquete (“tarball”)

make dist

Se habrá generado holamundo-1.0.0.tar.gz

Instalación genérica del paquete

  • Descomprimir:
tar xf holamundo-1.0.0.tar.gz
  • Entrar en la carpeta comprimida:
cd holamundo-1.0.0
  • Generar Makefile:
  • Construir:
  • Instalar:
sudo make install

Detalles de los ficheros creados


bin_PROGRAMS indica la lista de programas (binarios en este caso) que va a crearse. En este caso se va a crear un binario llamado holamundo.

holamundo_SOURCES indica que nuestro holamundo tiene un listado de _SOURCES (ficheros fuente). En este ejemplo solamente hay uno (src/holamundo.c). Si el proyecto tuviera más ficheros de código fuente para crear el programa se separan con espacios. Si se desea poner un fichero por línea para hacer el mantenimiento de Makefile.am más limpio se puede utilizar \ al final de la línea para indicar que continúa en la siguiente, por lo tanto:

holamundo_SOURCES = \
    fichero1.c \
    fichero2.c \

es lo mismo que:

holamundo_SOURCES = fichero1.c fichero2.c fichero3.c


foreign indica que no se está creando un paquete GNU estándar (no exigirá la existencia de los ficheros ChangeLog, COPYING, NEWS y README para funcionar).

subdir-objects indica que se está usando el modo recursivo, es decir, no se van a usar múltiples ficheros Makefile.am para cada carpeta con objetivos a procesar.

AC_PREREQ indica la versión mínima de autoconf requerida para funcionar con el archivo de configuración.

AC_CONFIG_SRCDIR comprueba que el código fuente existe en la carpeta indicada mediante la comprobación de algún fichero fuente de la misma.

AC_CONFIG_HEADERS indica el nombre que tendrá el archivo de configuración de código fuente generado. Esto permite crear definiciones (por ejemplo, #define LOQUESEA 1) en el archivo indicado (por defecto, config.h) que podrá ser incluido en el código fuente. Estas definiciones podrían variar según lo que compruebe el script configure, resultando muy útil por ejemplo para verificar si el programa se ha compilado con o sin soporte de una característica en particular, por ejemplo para dependencias opcionales de librerías o comprobaciones de funcionalidad del compilador o de un sistema operativo en tiempo de compilación.

AC_PROG_CC comprueba la existencia de un compilador de C. Como autoscan ha detectado código fuente en C se ha agregado esta macro automáticamente.

AC_CONFIG_FILES recibe en el primer parámetro una lista de ficheros separados con espacios. (en este caso solo Makefile, que generará a partir de Makefile.in). Los ficheros con extensión .in se utilizan para sustituir los valores de las variables que contienen y generar el archivo de salida, normalmente con el mismo nombre sin el .in. Este proceso lo realiza la macro AC_OUTPUT.

Algunos parámetros del script configure

El parámetro --prefix permite indicar el directorio base de instalación, que por defecto suele ser /usr/local. Por ejemplo el programa holamundo se copiaría por defecto a la carpeta /usr/local/bin si no se cambia el --prefix. Las distribuciones suelen usar en sus paquetes --prefix=/usr. Si se quiere instalar un paquete y no se tienen permisos de superusuario se podría indicar una ruta dentro de la $HOME donde usualmente se suelen tener permisos de escritura.

./configure --help muestra información detallada de los parámetros.

Compilación cruzada con el script configure

El parámetro --host permite utilizar de forma sencilla toolchains para compilación cruzada, por ejemplo en una máquina Intel con Ubuntu e instalando el paquete gcc-arm-linux-gnueabihf proporciona el toolchain para ARMv7 (hard float) y puede realizarse esto:

./configure --host=arm-linux-gnueabihf

A continuación podemos verificar que el ejecutable holamundo es un ELF para arquitectura ARM y no para Intel mediante:

file holamundo

por lo que podremos comprobar que efectivamente se utilizaron las herramientas del toolchain sin tener que prefijar individualmente compilador, enlazador y demás ejecutables.

Como programar un microcontrolador stm32 con cpp

Que se necesita

  • Microcontrolador STM322
  • GDB o un debugger, editor de texto o IDE
  • Una maquina con Linux

Requerimientos con Gnu/Linux

  • arm-none-eabi-gcc – The GNU Compiler Collection – cross compilador para ARM EABI (directo en el procesador)
  • arm-none-eabi-gdb – The GNU Debugger for the ARM EABI (bare-metal) target
  • arm-none-eabi-binutils – A set of programs to assemble and manipulate binary and object files for the ARM EABI (bare-metal) target
  • openocd – Debugging, in-system programming and boundary-scan testing for embedded target devices
  • vim – Editor de texto

Terminos importantes

CMSIS = Cortex Microcontroller Software Interface Standard info





En este momento de la historia, en la mayoría de los casos el consumidor no conoce el origen de los productos. Con una plataforma que brinde la posibilidad de compartir información entre productores y consumidores, se pueden solucionar varios problemas que presenta esta cadena de consumo.


Una plataforma, diseñada para compartir información entre productores, proveedores y consumidores, fue creada en Australia por la fundación Open Food Network.

Esta plataforma permite conocer el origen de los productos, la situación del productor, métodos de producción y otros factores que pueden tener alto impacto en la decisión del consumidor de orientarse a un producto o a otro.



Por el momento lo que hemos logrado:

  • Comprar el dominio
  • Configurar ofn en ubuntu 14.04
  • Necesitamos alguien con experiencia en ruby y rails para que revise
  • Tenemos un ambiente de pruebas


Ambiente de Producción

  1. Agregar el "Host" a la configuración de la Base de datos en config/database.yml:
  adapter: postgresql
  encoding: unicode
  database: open_food_network_prod
  pool: 5
  host: localhost
  username: ofn_user
  password: toor
  1. Crear la base de datos:
/opt/openfoodnetwork/www# RAILS_ENV=production rake db:schema:load db:seed
  1. Precompilar los activos en el ambiente de producción:
/opt/openfoodnetwork/www# RAILS_ENV=production rake assets:clean
/opt/openfoodnetwork/www# RAILS_ENV=production rake assets:precompile
  1. Correr Unicorn en producción manualmente
 cd /opt/openfoodnetwork/www && bundle exec unicorn -c ../shared/config/unicorn.rb -E production -D

Solucion de Problemas

  • Información del Log de Unicorn:
$ tail -f /opt/openfoodnetwork/shared/log/unicorn.log
  • Encontrar la ubicación del Unix Socket en /opt/openfoodnetwork/shared/config/unicorn.rb

  • Verificar que el Unix socket se encuentre creado:

$ ls -lah /tmp/unicorn.openfoodnetwork.sock
  • Verificar que Unicorn esté corriendo:
$ ps aux | grep unicorn


(1) http://teotti.com/use-of-rails-environments/ (2) https://www.digitalocean.com/community/tutorials/how-to-deploy-a-rails-app-with-unicorn-and-nginx-on-ubuntu-14-04

Utilizar Nikola por primera vez


La forma mas simple de instalar Nikola es con pip y virtual, también se podría utilizar uno de los paquetes de la distribución que se este utilizando, en si son usuarios de Linux.

En el directorio del repositorio del sitio

virtualenv --python=python3 .env
source .env/bin/activate
pip3 install --upgrade "Nikola[extras]"

Primeros usos

En este momento se tiene el sistema instalado, ahora hay que crear el contenido del primer sitio de prueba, estando en el directorio que va a mantener el código, se ejecuta el comando nikola init --demo ., luego se debe de construir el sitio con el comando nikola build.

El siguiente paso es ver el sitio, para lo que va a utilizar el comando nikola serve -b, pero es mucho mas fácil utilizar nikola auto -b para reconstrucciones automáticas.

Utilizar markdown

Para utilizar markdown para crear los post se debe usar uno de los múltiples lenguajes de marcado ligero soportado, para eso se debe de editar el archivo config.py en la raíz del sitio en Nikola.

Primero se debe de verificar que este en la estructura COMPILERS

# 'rest' is reStructuredText
# 'markdown' is MarkDown
# 'html' assumes the file is HTML and just copies it
    "rest": ('.rst', '.txt'),
    "markdown": ('.md', '.mdown', '.markdown'),
    "textile": ('.textile',),
    "txt2tags": ('.t2t',),
    "bbcode": ('.bb',),
    #"wiki": ('.wiki',),
    "ipynb": ('.ipynb',),
    "html": ('.html', '.htm'),
    # PHP files are rendered the usual way (i.e. with the full templates).
    # The resulting files have .php extensions, making it possible to run
    # them without reconfiguring your server to recognize them.
    "php": ('.php',),
    # Pandoc detects the input from the source filename
    # but is disabled by default as it would conflict
    # with many of the others.
    # "pandoc": ('.rst', '.md', '.txt'),

Luego se debe de agregar a la estructura del tipo de entrada, en el ejemplo de abajo se agregó la linea, ("posts/*.md", "posts", "post.tmpl") a los dos tipos de entras POST y PAGES.

    ("posts/*.rst", "posts", "post.tmpl"),
    ("posts/*.txt", "posts", "post.tmpl"),
    ("posts/*.md", "posts", "post.tmpl"),
    ("stories/*.rst", "stories", "story.tmpl"),
    ("stories/*.txt", "stories", "story.tmpl"),
    ("stories/*.md", "stories", "story.tmpl"),

Utilizar locales para Costa Rica

Este proceso debería funcionar para la mayoría de idiomas.

  1. Generar el locale necesario con `locale-get
  2. Definir cual es el locale que debe de utilizar Nikola por defecto.
# What is the default language?

# What other languages do you have?
# The format is {"translationcode" : "path/to/translation" }
# the path will be used as a prefix for the generated pages location
    DEFAULT_LANG: "es_CR",
    # Example for another language:
    # "es": "./es",
    "es": "./",
    "en": "./en",
  1. Definir el locale que se va a utilizar para es, por defecto es es_ES.

El locale a utilizar puede ser probado, importando locale import locale y llamando al locale necesario locale.setlocale(locale.LC_ALL, 'es_CR.utf-8')