Petite sortie en départ alpin à Val-David jeudi matin. Galactic Denied, finalement envoyé au dernier essai avant de revenir en ville.

Les mots du curé Morin m'ont inspirés à retourner au Lac Long cette semaine:

Il est de ces choses, telle l'éthique du grimpeur, qui étant de nature intrinsèque et personnelle, ne peuvent être jugées que par le protagoniste lui-même.

Amen

À la lecture de ce message, la bonne chose à faire m'est apparue claire: retourner envoyer One night stand sans donner de coup de pied au bloc de gauche dans la sortie...

Voici donc un autre video lo-fi aux blocs du lac long.

Même concept que la dernière fois, les numéros des blocs sont basés sur le topo du Festiroc 2017

1. Bloc #23 - Poste Canada. Superbe bloc avec de bonnes prises (et quelques mauvaises aussi :)
   Suggestion de cote: v5-6
2. Bloc #29-A.
   Suggestion de cote: v1-2
3. One night stand (encore). La dernière fois, il y a eu une méga touchette sur le bloc de gauche...
   Après vérification du video de Yann, il semble que notre méthode soit une variation de la ligne originale: On passe à gauche au lieu d'aller a droite. Comme on n'était pas certain de la direction où aller et qu'on a tâtonné un peu partout, j'aimerais nommer cette variation One night stand bicurieux. Suggestion de cote: v6-7
4. Un essais dans le projet à droite de One night stand. C'est au moins aussi dur que ça l'air vu d'en bas... malheureusement une chute dans la sortie semble assez risquée

On a aussi brossé un truc dur avec-pas-de-pied, ça prendra quelqu'un de fort ou un magicien pour envoyer ça, j'ai hâte de voir :-)

Video lo-fi de quelques blocs envoyés aux Lac Long dans Portneuf ce weekend.

Les numéros des blocs sont basés sur le topo du Festiroc 2017

Dans l'ordre:

1. Bloc #13-A. S'il n'a pas de nom, je propose: "En dessous des couvertes"
2. Bloc #10. Suggestion de nom: "Capitaine homard part en croisade"
3. All about love. (#32-B)
4. One night stand. (#32-A)
5. One night stand. Charlie qui send.

Note: Les cotations de All about love et One night stand semblent inversées dans le topo.

Un problème qui m'a semblé plus difficile que ce qui est indiqué dans le topo... (v6/7) On dirait bien que je pose mes fesses sur le bloc pendant la sortie à vous de juger s'il y a eu touchette, perso j'y retourne pas :P

I've been thinking about running OpenBSD again for a while now, yesterday I had some inspiration and decided to try to boot it on OVH's VPS machines.

OVH doesn't have the best reputation regarding availability and support (both of which I confirmed in the past...), but they are cheap and they have a datacenter in Beauharnois, Qc, that's less than 50km from home.

They're only offering Linux distribution for their VPS SSD instances at the moment, but since the virtualzation technology is KVM, booting the OpenBSD ramdisk kernel (bsd.rd) and doing the installation is all that is needed to get a working OpenBSD machine.

Here's how I did it.

This week, we had a few weird crashes with an HTTP server which we could not easily reproduce and we had a hard time pin-pointing the source of the issue. We knew the problems were triggered by bad input, but since the process was continuously receiving around 3000 requests per second at the time, it was pretty hard to isolate the exact request(s) that made it crash.

The idea we had was to capture HTTP requests data up to the point where the process crashed. Then, we would open the trace and look for the last successful requests, the faulty one would be in there somewhere.

At work, we have been doing quite a few tests lately to understand what is the maximum number of http queries per second (QPS) that a modern server running Ubuntu 12.04 with a recent Linux kernel could handle.

Magnifique bloc classique de Val-David, l'Égyptien.

Pas de musique dans le video pour cette fois, seulement Pascal Visegrip qui commente. Cherchez bien et vous trouverez le thème du jour: le side core banana

While doing some packet drop testing for a pcap script I'm writing with a collegue a work, I hit a strange situation on my Mac where ab would do ~16k HTTP connections really fast, then stop, then timeout.

Turns out this is caused by the lack of available ephemeral port …

an overview of python modules wrapping libpcap