I hate docker! Yes, I hate a bit. Why? Just because I tried a lot to do a simple application that uses a mysql everything internal into a docker and I failed, terrible! I did researches a lot about how to set it and also failed terrible. Every piece of tutorial I found was about using a docker image container and linking it to another container running the application or even some bullshit about docker mysql image and web applications. NO! That wasn’t what I looking for at all. After did more research I found docker-compose, but yet nothing about put my application in a single image/docker together with mysql. I don’t care how it’s for some people that like things separated, but I also think in docker to do things that are easy to delivery and that was why I tried that. But let’s forget the rage and focus in the tutorial itself that I hope will help some people that are/were looking for the same as me.

Step 1: Install docker and docker-compose.

I choose for docker-ce and you can follow the steps to download/install here. For docker-compose I just did a sudo apt-get install docker-compose (I’m using ubuntu 16.04 LTS).

Step 2: You probably will see some error while trying to run docker. So, before you see that add you $USER to the docker group. Do this:

  1. sudo usermod -aG docker $USER 
  2. newgrp docker

Now you can use docker without issues.

Step 3: Write your docker-compose.yaml file: In my case I wanted to use mysql and everything into the same docker container image. When I say everything I mean my mysql databases, my mysqlserver with my databases, my application itself running internally to the container accessing the database and so on…

  image: mysql
  container_name: application.v1
    - ./somefolder/some_script_to_install_your_app.sh:/tmp/install_your_app.sh
    - ./data_volume:/opt/data_volume/
    - "3306:3306"
   MYSQL_DATABASE: "your_data_base_name"
   MYSQL_USER: "some_user"
   MYSQL_PASSWORD: "some_user's_password"
   MYSQL_ROOT_PASSWORD: "root_passwd"

Using the docker-compose.yaml above you’ll be able to create a mysql image/container. Cool! But what about my application? The way I did it can be a little hack or not right but in few words, who cares! In essence a mysql image is a debian imagem with mysql set in it. So you can just install things into it and put your application to into that container/image as you want. In order to do that I just add some scripts in volume to install my application and internally the application access mysql through localhost host, simple! YEAH! The only thing is that you need to run first a docker-compose up (in the same directory were you .yaml file is)   to put your mysql server to run and in separated run your application as: docker exec application.v1 application (supposing your install it in /bin). If you don’t like or don’t want do type docker exec … you can just create a shell/bash wrap around the command that 1) starts the mysql server and 2) runs your application \o/. And finally you have an application running beautifully with a internal docker container mysql.  For the inconvenience of run a docker-compose up and so your application you can just hack this and run a: docker-compose stop && docker-compose up &> /dev && docker exec application.v1. It’s not pretty as you wish probably, but it works as a charm.
I hope that I have help you somehow because the internet is fully of garbage that don’t explain nothing right of with all details. I’m sure I not put all details here, but I’ willing to help in the comments session or even when I edit this post. For now, just try as an exercise put a script into your docker-compose.yaml that e.g:  install git and git clone your app and compile it and install into /bin. See if it runs, if it access mysql internally and that is all!


AVISO: Caso você opte por realizar os passos descritos aqui saiba que você está por sua conta. O guardião do banco X ou  keylogger/malware do banco X (como é apelidado carinhosamente) serve para dar segurança nas suas transações via browser. (Ao menos é o que dizem – Talvez se você achar em algum lugar o site ou o canal com a cia de Software, que codou ele você consiga uma melhor informação).

Faz algumas semanas que tenho enfrentado a dor de cabeça que é realizar transações online via o banco X e não consigo porque o guardião simplesmente parou de funcionar. Não adianta tentar reinstalar, nem numa VM eu consegui fazer ele funcionar novamente (Eu uso ubuntu 16.04 LTS). Há erros com o certutil na hora da instalação e nada se consegue tentando instalá-lo. O que parece uma instalação normal termina com uma tela dizendo que o guardião não está instalado e dores de cabeça se você precisa pagar algo ou realizar alguma transação online.

Mas eis que hoje me passaram esta dica. Existem addons que modificam o user-agent do seu browser e ao fazê-lo o guardião é jogado de lado e você consegue realizar as transações tranquilamente (Lembre-se do disclaim acima, você está por sua conta em risco). Mas se o seu browser não possui nenhum addon que faça isso você pode adicionar o novo user-agent na mão.
Aqui eu usei o Firefox 59.01 (Quantun).

  1. Na área de por a URL digite: about:config
  2. Agore pesquise por: general.useragent.override
  3. Provavelmente o seu browser não tem essa flag, então basta adicioná-la. Clique com o botão direito no corpo da página: new->string. Adicione o nome da variável e logo em seguida o valor dela: Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
  4. Se tudo deu certo agora você pode tentar acessar o site do banco X e verificar que ele não reclama mais sobre a instalação do guardião.

Boa sorte e lembre-se, por sua conta em risco.





Backports are those thing that are done every time. Even if you aren’t looking right now to it :P. Most distros does a lot of it.

What’s a backport? Backport is when you need to get code from, let’s say,  an upstream version and get it back to fix or fit in an old version than upstream one. Sometimes to do that is quite simply, if the patch’s piece that touches the code was not changed yet in upstream version or if was changed but in a minimum way. Otherwise sometimes you need to practically do a ‘surgery’ at the code to backport some pieces of the fixe. Things can become a nightmarry if you have a bunch of code to touch and a bunch of them were already changed in upstream. If you don’t have choice other than fix/backport I’ll share with you some of my steps that maybe help you, but I’m also open to hear from you what the methods you use in this situation.

Do backports often can be resume in these few steps:

  1. get the package code to backport
  2. get the patches to fix into backported version
  3. apply the patches
  4. build the package and pray to not see any errors/warnings or regression (here in the test phase)

For me things works like this…Once I get the package source I copy with another name: git-version and git init and  git add  * creating a git repository to handle with my patches. Sometimes the package has a git upstream, I also get this one. Here you probably wondering ‘why not just get the upstream git and jump to the branch or commit that match with the package’, well, sometimes it doesn’t happen, there is no match between packages on the distros and upstream. It happens because in distros it’s often to keep distro-version (let’s call this way).  Continue… with my git-version I start to apply the patches using git apply --check. It gives you a test check to see if the patch you want to apply really works or fails. If it works (yataaaaa! –  Japanese word for: uhuuuuuuuuu), if not (zanen desu ne! – Japanese word for: it’s a pity). Second scenario will request from you a lot of job sometimes, or just a few adjustments. But the case here is that if you use the git-version you can use things like gitgutter if you use vim and follow the changes you are doing at the moment you are typing – that’s really nice!. When I finish my re-patch or backport I often commit it as the same name of the patch I’m based on, this way things becomes more easy to track and checkout. Supposing everything was ok with the re-patch is time to generate the patch file: git format-patch -1 <sha-code> will do it for you. Now it’s just a question of apply against the original package source (quilt, dpatch, patchless …), build and check if everything goes fine 🙂

Some other tools and tips would be:

  • vimdiff: for show the diffs between two files in the same window, but…
  • diff: you can also use diff -Naur old new | less -S , and check your diff

If you play with debian packages you probably know what is quilt. This nice tool makes the life of any developer easy. But what about if you don’t have a debian package and still want to play using such magic?
It’s quite simple, believe me :).

First thing you need to do is, of course, install quilt, if it wasn’t already there.

  • sudo apt-get install quilt

Once you done now is time to see what it does for you. But before it let’s configure a simple .quiltrc (this one need to be there in your /home/username/.quiltrc,  OK). Into it add those lines:

QUILT_PATCHES=debian/patches # change debian/patches for patches, by example
QUILT_DIFF_ARGS="--color=auto" # this is for colors

This file says basically that your patches will be in your patches folder or debian/patches if it’s debian package and that’s the basic you need to know, but if you want dig more in those variables just type man quilt on your terminal, the explanation will be there for sure.

In your source directory, if you already has a patch folder and want to apply the patches are there type quilt push -a everything will be applied.


If you want to check just type quilt applied.


Here are the main commands you’ll need to know:

  • quilt new name_of_your_patch.patch: create a new patch ‘session’ with the passed name
  • quilt add src/somecode.c: after create a patch you need to add what files you’ll change in order to create in fact the patch.
  • quilt refresh: when you finish to edit those files add into your patch ‘quilted’ you do a refresh. If you cat patches/name_of_your_patch.patch you will see your nice patch there :).
  • quilt pop: it’s used if you want to take off a patch of the stack of patches to be applied, as you can see bellow it also restore the changes you did in the file.


I think quilt is that kind of tool that make things magic to you. Imagine that you have a lot of patches to apply or a lot of backport changes to do and apply. Quilt gives to you a easy way to manager this task in a quite beautiful mode. And if you are thinking to use it only in your .deb, well I pretty sure you have fun using it in any project/source you dev.


[1] https://wiki.debian.org/UsingQuilt

Yep, the title is exactly that you got. If you don’t have a raspberry PI (like me) your dreams to play with  ARM programming doesn’t end yet. I’m saying that because you can do everything just using your old friend x86_64.
How to do that? First let’s install some cross compile (gcc, in our case)

$ sudo apt-get install libc6-armel-cross libc6-dev-armel-cross
$ sudo apt-get install binutils-arm-linux-gnueabi
$ sudo apt-get install libncurses5-dev

Once you did that, type in your terminal: arm-linux-gnueabi-gcc  if everything goes fine it’ll be there. Only thing you need to do now is coding and that has no secret.

#include <stdio.h>

int main(void) {
    printf("Hello World!\n");

    return 0;

$ arm-linux-gnueabi-gcc -o hello hello.c

Now you compiled how to run it? The answers will be qemu-arm. Install it: sudo apt-get install qemu . After that try to run your ARM executable.

Everything goes OK? Probably no. It’s because your executable needs some shared libs, yep, it’s a pain. But you can fix it in two flavors: i) qemu-arm -L /usr/arm-linux-gnueabi/  hello; ii) recompiling passing a static flag: arm-linux-gnueabi-gcc -static -o hello hello.c , and so run qemu-arm hello. Between those two ways the first is the better, since you don’t want your executable with a giant size that is the result of all the lib that will be put into it. But for test cases you can do it anyway.  You can see other approaches here

In a scenario where you have a board you can just scp your code to there and run, in cases you haven’t, qemu-arm and cross compile can works exactly the way you need.


[1] http://tuxthink.blogspot.com.br/2012/04/executing-arm-executable-in-x86-using.html
[2] https://www.acmesystems.it/arm9_toolchain
[3] https://stackoverflow.com/questions/16158994/qemu-arm-cant-run-arm-compiled-binary

These days I was just thinking. Sometimes when you build something for debian by example you have a nice .diff it generates in /temp, but how about all those builds or compiles you do and don’t have any diff to check if anything is different?
The case is that is very easy to check a log difference, you just need to run diff log1 log2. Ok, it’s easy, it’s nice, but if you want to play a little bit with python you can do something like  this:

import sys
from difflib import unified_diff

# first read the previous or original log
_log1 = None
with open('log1', 'r') as log1:
    _log1 = log1.read()

# now get the output log 'dynamically' from your program
log2 = sys.stdin.read()

# finally, call unified_diff for them
from line in unified_diff(_log1, log2, fromfile='log1.txt', tofile='log2.txt'):

Now when you run this it’ll show you a nice unified diff format the differences between these log files.
I know it’s very silly, but still useful in some way 🙂

[1] difflib

It’s not always that you’ll get something you want in your life. It’s up to you to keep fighting everyday. In this crazy tech world we have a lot of pathways and you don’t need to follow all them. Choice wisely one, put things in a note book, learn, learn every day.
Even if you failed in some interviews, keep learning something new everyday. The worst that can happens is you become less ignorant. Success happens even when you fail since through it you can fix everything wrong and try again, and again, and again…
Said that, maybe today is the time to learn more about ARM arch and assembly in ARM. Let’s diving in it? See the references you’ll need here