Archive for the ‘Hacks’ Category

Routage ferroviaire pour raildar.fr avec Openstreetmap et OSRM

Saturday, January 11th, 2014

Pour fêter la nouvelle année, que je vous souhaite à toutes et tous joyeuse et heureuse, voici une petite application web que j’ai écrite récemment pour aider au débogage des trajets de raildar.fr, qui permet d’identifier plus rapidement les problèmes à corriger dans openstreetmap.org. Voir plus bas pour des précisions de fond.

Ça se révèle assez ludique (pour les amateurs de trains).

Voici l’URL temporaire “de travail” chez moi avec un exemple de trajet Londres-Amsterdam :

http://signal.eu.org/osm/?fromto=51.534377,-0.128574,52.379018,4.899988

Pour demander un trajet, on déplace simplement les deux marqueurs et le logiciel de routage se débrouille, et affiche la distance résultante.

En voici une copie d’écran (cliquer pour agrandir) :

LondresAmsterdam

Attention, ne bourrinez pas trop sur le serveur, le calcul des routes prend quelques secondes et utilise l’instance OSRM de raildar.fr.

L’application est aussi déployée sur les serveurs de @Turblog (Bruno Spiquel) dans une version un peu moins à jour.

Quelques précisions pour ceux qui ne connaissent pas : raildar.fr utilise les données SNCF de retard, ainsi que la base cartographique openstreetmap.org. openstreetmap.org est en quelque sorte le Wikipédia de la cartographie. Chacun peut y apporter des corrections. En complément, OSRM (Open Source Routing Machine) extrait les différents graphes (routiers, ferroviaires, etc) afin de calculer des trajets de toutes sortes dans le graphe.

Mon application est éhontément dérivée du code initial de raildar.fr (écrit par , basé sur leaflet et jQuery) auquel j’ai ajouté le décodage de la sortie OSRM.

 

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1CUH3vK4HsCvAmqWWdZqtHvZfU65PmDD87

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)

Quand la fibre Free se fait attendre, même à Paris

Monday, October 8th, 2012

(précision sur le titre : le “même à Paris” est une allusion à la densité de la ville, où donc la rentabilité par rapport à l’investissement, prétexte souvent soulevé par les opérateurs, est le moins susceptible de poser un problème)

À l’heure où beaucoup monde se plaint de ne pouvoir obtenir la fibre (à part une poignée de privilégiés qui l’ont déjà, sans compter les très rares qui pourraient l’avoir mais n’en veulent pas), une étude OCDE signalée par Numerama confirme le colossal retard français en la matière.

Récemment, Orange a annoncé triomphalement activer 4000 prises par semaine.

La situation dans mon immeuble :

  • immeuble construit en 2008
  • convention Free signée début 2011
  • repérage puis pose par Free de la desserte horizontale (égouts -> immeuble) en octobre/novembre 2011
  • depuis… rien !

On appelle “desserte horizontale” le raccordement par la rue, les égouts, etc, d’un immeuble au réseau d’un opérateur.

La “desserte verticale” est le câblage interne de l’immeuble, reliant l’arrivée horizontale aux logements à desservir.

Lorsque les deux sont réunis, on parle d’accès FTTH (fiber to the home, fibre jusqu’à l’habitation).

Voici donc une photo, prise le 13 novembre 2011, de l’arrivée de la fibre Free dans le sous-sol de mon immeuble, via les égouts de Paris. La fibre est munie d’une jolie étiquette verte “FREE INFRASTRUCTURE” avec une référence et un numéro de téléphone qui tombe sur un répondeur, renvoyant l’appelant vers d’autres numéros “spéciaux syndics d’immeuble” qui ne permettent jamais d’obtenir quelqu’un. On voit que la fibre est sagement enroulée, inutile, en attente d’être branchée sur un réseau vertical qui n’est toujours pas là, près d’un an après.

Dans mon immeuble, les questions logiques des résidents : “On a bien voté la convention fibre pour Free en assemblée générale annuelle ? Ça en est où ? Faut-il qu’on demande à un autre opérateur ?”

Notre immeuble est très loin de représenter un cas isolé, j’ai entendu parler d’exemples similaires à Paris et à Lyon. Les opérateurs se sont fait la course pour mettre un pied le plus rapidement possible dans les immeubles, mais se font tirer l’oreille pour terminer les travaux, prétextant une faible demande des abonnés..

Parallèlement, pour masquer le retard français, les pouvoirs publics utilisent les statistiques faussement flatteuses de Numéricâble, un réseau câblé de télévision vieux, à quelques rénovations près, de 30 ans, en fibre (moderne à l’époque) prolongée dans les immeubles par du câble coaxial tout à fait classique et aux performances bien moindres que la fibre optique de bout-en-bout.

Quant aux opérateurs, par souci d’économie, ils misent sur la technologie VDSL2 pour donner une “2ème vie” [sic] au réseau cuivre du téléphone classique. On ignorait que celui-ci était mort une première fois.

Mise à jour : je ne regrette pas d’avoir écrit et diffusé ceci sur twitter, j’ai pu avoir des retours sur la procédure à suivre pour avancer. Free semble avoir résilié la convention d’immeuble.

Il nous appartient donc de choisir un nouvel opérateur d’immeuble  lors de la prochaine assemblée générale ; cet opérateur pourra effectuer la pose du câblage vertical et utiliser la fibre posée par Free.

Mise à jour 2 : il s’avère que les deux seuls opérateurs installant du FTTH en France en tant qu’opérateur d’immeuble actuellement sont SFR et FT/Orange. Merci beaucoup aux personnes qui m’ont donné des contacts (SFR très réactif…).

L’ARC (association conseillant les syndics de copropriété) arrive aux mêmes constatations, mais conseille carrément de rester en ADSL, ce qui est absurde et désolant. L’ARC soulève des arguments spécieux à mon sens contre les conventions des opérateurs (en fait reprises d’un modèle ARCEP) : durée de 25 ans (compréhensible, cela limite les interventions perpétuelles en AG, mais elles peuvent être résiliées avec préavis de 18 mois) et non-propriété du câblage à l’issue de la convention (compréhensible également : je vois mal les copropriétés se charger de la maintenance/entretien/évolution technique ou avoir un prestataire supplémentaire à trouver pour cela).

Voir :

1 tip so far
0.00609148 BTC

Like this post? Tip me with bitcoin!

1AEpLSSo9UHTmzzCdrxXCE5kcLVNstK4ra

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)

Lossless import of MPEG-TS or HDV video files to iMovie

Friday, June 1st, 2012

Here’s a little trick I learned and wanted to share. As it’s not complete, comments and additional hints are welcome!

The problem

I have a Canon HDV camcorder with many hours of HDV video. HDV is mpeg2-compressed video with a bitrate of about 25 Mbps.

I also have a MacOS X computer where I can run iMovie, Apple’s consumer-grade video editing application.

The camcorder video can be easily imported to FreeBSD using the built-in fwcontrol tool. It generates MPEG-TS files (mostly like IP TV channels) which read nicely in vlc, mplayer and other video tools. It’s easy and reliable.

The video can also be imported directly from the camcorder to iMovie, but it is painful and not adapted to easy archiving of the rushes. The import process is slow and buggy and you often have to rewind the tape and restart it.

I wanted to get the best of both worlds — fwcontrol’s easy import followed with iMovie editing.

But iMovie doesn’t know how to directly import MPEG-TS files. It can only import video from .mov (Quicktime) or .mp4 (MPEG4) containers. It’s difficult to know which video codecs are supported by iMovie but it seems to accept MPEG2, which means it can losslessly import HDV files, it’s just a matter of converting their container format from MPEG-TS to Quicktime.. It saves us from the slow, error-prone, lossy and painful process of transcoding.

So how do you do that?

The (mostly complete) solution

Here’s the incantation that mostly works for me. input.mpg is my MPEG-TS file; it can come from a fwcontrol import or from a IPTV capture (Freebox file for example); output.mov is the resulting Quicktime-container file:

ffmpeg -i input.mpg -acodec copy -vcodec copy output.mov

On my server (a double-core Intel Atom D525 processor with SATA disks, ie not a very fast machine) it converts at about 80-100 frames per second (3x to 4x real time), which is very fair (IO bound probably) and 12 to 20 times faster than transcoding the video.

From an IPTV capture you may have to explicitly transcode audio to AAC using -acodec libvo_aacenc instead.

Your second-best bet if the above doesn’t work is to let ffmpeg make a (much slower) almost-lossless transcoding to MPEG4, using option -sameq, yielding a bigger file (was almost twice as big as the original in my trials):

ffmpeg -i input.mpg -acodec copy -sameq output.mov

It works, but…

Why do I say it mostly works? Because there are two remaining gotchas:

  1. the original video timestamps (date and time of the video) are lost and set to the date and time of the conversion process — it’s constant and doesn’t even increment throughout the file duration. It is probably a ffmpeg bug. I tweaked the import with -copyts option but this apparently handles the time index from the camcorder (duration from the beginning of the tape). This may (or may not) be related to the following error message from ffmpeg: [NULL @ 0x806c1d920] start time is not set in av_estimate_timings_from_pts
  2. iMovie doesn’t seem to grok huge files. It works for a couple hundred megabytes, but not for a couple gigabytes. So you may have to split files take by take, and I don’t know how to do that easily, especially given the above regarding broken timestamps.

Thanks to Benjamin Sonntag for the excellent idea of using ffmpeg for this ;)

Comments and especially clues/solutions more than welcome ;)

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1LQJBAnmqSSwDaFCAuoG6iHxZ6LiAPZ69o

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)

Petite expérience de DNS et de Twitter avec wikileaks

Friday, December 3rd, 2010

On a tout à fait le droit de ne pas partager à 100 % les idées et les procédés de Wikileaks, actuellement sur le devant de l’actualité, et certaines de ces critiques sont légitimes. Mais, a contrario, certains des procédés utilisés pour les faire taire ont un petit parfum qui, à titre personnel, me dérange.

L’expérience du jour : wikileaks.org ayant vu son DNS coupé par son hébergeur (problèmes d’attaques, officiellement), les discussions de ce matin sur Twitter consistaient à s’échanger “à la main” les adresses IP des miroirs… pas très pratique. Cette coupure de DNS fait suite à un déplacement du site de chez Amazon, aux USA, vers OVH, un hébergeur français.

Et puis j’ai fait une proposition toute bête qui a bien décollé et j’ai créé wikileaks.eu.org pour accomplir ma part, merci à tous ceux qui ont suivi et qui ont été ajoutés dans cete liste plus générale (section “miroirs DNS”).

Jean-Michel Planche ayant pris la peine de faire un résumé du contexte, je ne vais pas le paraphraser, allez voir son billet.

Voir aussi la lettre de mission d’Éric Besson (à Pascal Faure du CGIET) divulguée par LePost, qui vaut franchement le déplacement. Pour résumer, Éric Besson cherche un moyen d’expulser le site de France.

Un autre billet général chez Authueil sur la censure en général et celle de Wikileaks en particulier résume bien la question.

Et un article d’Écrans (Libération) résume bien la situation à l’exception d’une erreur : FDN n’héberge pas un miroir de Wikileaks, wikileaks.fdn.fr est juste un renvoi DNS suivant la méthode exposée ci-dessus.

Désolé pour ce billet un peu décousu mis à jour au fur et à mesure…

Mise à jour 18h45 : c’est maintenant le nom wikileaks.ch actif depuis ce matin qui est en carafe…

Mise à jour 4 décembre 2h35 : une liste plus complète chez Bluetouff.

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Lm2mqbTJtVajdeNM1nxxWD9iAKGBejsNx

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)

TCP-Estimated round-trip test

Wednesday, November 24th, 2010

In an attempt to evaluate different methods for measuring the performance of a TCP/IP connection, I’ve bumped into FreeBSD‘s getsockopt(TCP_INFO) system call, cloned from a similar call invented by Linux, which kindly returns interesting data about the current TCP connection.

I was mainly interested about round-trip time (RTT, called tcpi_rtt) and its standard deviation, mistakenly called tcpi_rttvar even though it’s not a variance.

I’ve written a small proof-of-concept tool accessible at http://eu.org:4500/ to display operating system information retrieved from the current HTTP access. The page currently runs on a FreeBSD 9-CURRENT machine; feel free to try it out, it works either in IPv4 or IPv6. Here’s a sample as of today:

This experimental page displays raw system TCP estimates, in microseconds.

Address: 2a01:e35:8b50:2c40::4
Estimated round-trip time: 15437
Estimated standard deviation: 27937

Note that the measures are very rough. First, the real resolution is about 1 millisecond (one kernel tick), not 1 microsecond. Then, several RTT samples are smoothed into the provided values, with a bigger weight for more recent samples. I left the actual values obtained from the kernel, for clarity, even though giving them up to a 1 microsecond resolution is somewhat misleading.

Then, of course, the results also depend on the number of samples, which tends to be low: the above page waits for the client HTTP headers to be fully received, then emits its own headers in reply, then waits for one second to give some time for the TCP ack(s) to come back, then displays the then-current estimations.

The results are probably sufficient for TCP’s internal needs, but they may differ wildly from real RTT values. Plus, the real RTT value depends on packet size, which TCP doesn’t seem to take into account. The above example is taken from my local network and displays over 15 ms for the RTT, whereas the real RTT is well below 1 ms (0.23 min, 0.4 average with 0.01 standard deviation, according to ping). The results are not always wildly up, I’ve noticed the opposite effect from a remote mobile phone displaying ~100 ms whereas the ping time was more like ~200 ms…

Feel free to use it and add comments below.

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1JkS4gdxzf3exHnLf3ULyfw6vHnPESvp3A

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)

Android pattern locking: a horror story

Monday, February 8th, 2010

45 seconds of play, ~5 hours of desperate hacking.

A few days ago, my 4 year old daughter was playing with my mobile phone running Android 1.6. To let her play with the screen while avoiding any mishap, I locked the phone. It was obviously not enough, she instantly found the MENU key to unlock it.

So I had the brilliant idea to put on a locking pattern, the pretty method used on Android to really lock the screen.

After 5 unsuccessful tries, which my daughter reached in about 15 seconds, the pattern unlocking incurs a 30-second guard delay. I decided that the game was too risky (I found out later there’s also a 20-try hard limit, but we didn’t reach it) and took my phone back.

There, I had another brilliantly fatal idea: I clicked on the “forgot the unlock pattern” button which just appeared, just out of curiosity to see what would happen next. The phone asked for my Gmail account and password. I filled the requested information, but it didn’t unlock the phone; apparently this is a known Android bug that I didn’t know about. And, contrary to what I naively assumed, there was no way to get back to the unlock pattern screen. I rebooted the phone. No change, no escape.

Then it dawned on me that I was 600 kilometers away from home, for almost a full week, without all my computer tools. And I was locked out of my own phone.

(more…)

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

19VLfxc4QjTTXYPxbs8cN8eeoKUCEHL3dn

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)

Train nucléaire

Friday, January 8th, 2010

Un train miniature est utilisé à Princeton pour faire tourner un morceau de californium-252 afin de calibrer les équipements d’un petit réacteur à fusion…

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1MWLayFYXSY5ca8WbuZokoWJp9VFjWEcEV

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)

Pi avec 2 699 999 990 000 chiffres décimaux

Tuesday, January 5th, 2010

[via Slashdot]

C’est Fabrice Bellard (qui n’en est pas à son coup d’essai, ni concernant Pi, ni sur d’autres sujets) qui nous gratifie d’un de ses nouveaux exploits… le résutat en décimal (1/2 octet par chiffre) prend à lui seul 1137 Go d’espace disque… Des extraits sont .

Le record précédent d’août 2009 est dépassé de peu (120 milliards de chiffres en plus, tout de même), c’est surtout l’économie comparée des moyens mis en oeuvre dans le nouveau record qui est stupéfiante : un simple PC à peine gonflé.

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1KyR92WbaFdNk4esabSCR1hVFpJwFuKCYf

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)

IPv6 en prison

Sunday, November 30th, 2008

Ça y est ! Depuis ce matin, IPv6 est maintenant utilisable dans les jails FreeBSD (version 8 seulement pour l’instant), grâce au travail que Bjoern Zeeb vient d’intégrer dans les sources.

Cela m’a permis de me débarrasser de la petite manipulation un peu tordue montée l’an dernier pour mettre en place la passerelle v6 -> v4 de ce blog.

Il a juste fallu que dans /etc/rc.conf je change la ligne :

   jail_signal_ip="192.168.58.99"

en :

   jail_signal_ip="192.168.58.99,2001:660:330f:f800::2"

Et bien sûr recompiler Apache et refaire sa configuration avec l’option IPv6, et régler quelques menus détails comme la création d’une nouvelle adresse v6, son ouverture dans les filtres IP, et sa mise à jour dans le DNS…

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

14bkY96J8GyVs7PMb1LPQh9r9XHn9yQc4i

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)

Adieu RFC 2817, bonjour RFC 3546

Tuesday, November 25th, 2008

L’an dernier, ayant lu les docs Apache 2.2 dans un moment d’égarement, je parlais des extensions RFC 2817 du module SSL permettant de ne plus multiplier les adresses IP (maintenant de plus en plus rares en v4) lorsqu’on héberge plusieurs serveurs web sécurisés sur une même machine, une plaie avec https. On attendait alors la sortie de Firefox 3.

Celui-ci étant maintenant arrivé depuis un bon moment, je me suis réattaqué ce soir à la question, titillé par un article récent de Stéphane consacré à la légèreté proverbiale de X509.

(more…)

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

13DNKbDGj2bS2uVtQPSzwn7gUa2wbNVAMX

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind :-)