Trente-six chandelles. Trente-six vues du mont Fuji (ou de la Tour Eiffel). Y'a pas trente-six manières de faire. Mais y'a trente-six pouces dans un yard. Numéro atomique du krypton (rien à voir avec Superman).
Trente-six ans !Posted jeu. 11 avril 2013 18:30:02 CEST
Bon alors bon. Y'a bien longtemps que je n'ai rien écrit en français ici, ça manque. Mes geekeries sont à peu près bien documentées en anglais, mais contrairement aux rumeurs je fais aussi autre chose à côté.
Je fais du monoski, par exemple. Et cette année, j'ai bien l'impression d'être le dernier… j'ai beau entendre parler de gens qui en font, pour la première saison depuis que je fais du mono, je n'ai pas croisé un seul collègue en une semaine sur un grand domaine skiable, malgré la neige abondante et le soleil radieux (surtout en début de semaine).
En parlant de soleil radieux : la tradition veut que les saisons du ski et du barbecue s'enchaînent avec un délai de carence de quelques jours au plus, mais là après la redescente en plaine ça traîne, et ça reste bien humide. Donc je prends les devants, et je décide & décrète que je vais pas me laisser faire. Les saucisses et côtelettes seront peut-être cuites à la vapeur, mais ce sera de la vapeur au feu de bois. Les invités seront les bienvenus.
Sur le front de la musique : côté rock chez Eleven, on continue à répéter, ajouter des chansons à notre répertoire, et faire des petites apparitions publiques à gauche et à droite. On a temporairement égaré un guitariste (mais il va revenir un jour), et on continue de chercher mollement un chanteur (ou une chanteuse). Si jamais vous êtes dans la région de Montpellier/Nîmes et que vous voulez vous lancer…
Deuxième front musical : je me suis laissé embarquer dans un autre groupe, mais cette fois c'est pour faire du tambour japonais (on dit taiko pour faire bien). On est encore en phase de mise en place, mais c'est déjà marrant.
Bref, on s'occupe, quoi.Posted ven. 29 mars 2013 11:00:02 CET
Open question to enthusiasts, theoretical computing scientists and mathematicians of all sorts: is it possible to construct a valid QR-code that leads to interesting results when used as an initial configuration for the Game of Life?
- QR-code or DataMatrix or whatever, I'm not picky;
- valid code as in maybe not exactly what would be produced from the text, but which the error-correction can reconstruct;
- interesting results, as in not decaying to a stable state (or not too soon, at least);
- for bonus points, it would lead to at least one glider;
- for extra bonus points, a glider gun or a breeder of such;
- for awesomeness, the QR-code should encode an URL pointing at the demonstration of its own evolution in Life.
Update: The answer seems to be yes. Jurij Smakov assembled a QR-code generator and a Life engine and plugged them together for easy experimenting. And Stefano Zacchiroli noticed that using "free software" (no quotes) as the input leads to a couple of gliders endlessly traveling a field with a few still lifes. This is way beyond awesome.Posted mar. 19 févr. 2013 20:34:44 CET
Dear reader, I know you're wondering what I'm getting up to these days. Or at least, I guess there's a possibility that you're wondering. So since there's no single bit of news that would be worthy of a post here by itself, here's one summarizing things, in the hope that the accumulation makes a tiny bit of a difference.
On the rock'n'roll front: Eleven did its first true gig on our own in a pub last Saturday. And when I say “on our own”, it could almost be taken literally, for we must have had a grand total of about 10 people. A bit of a disappointment, to say the least, especially since the pub was about 120 kilometers from home, 60 of which I rode on my motorbike at 2 AM (and close to 0 °C). However, the landlord seemed to like us and hinted at further gigs during seasons where people are more likely to go out for drinks and music than to stay warm at home.
In a related note: we got ourselves a small set of stage lights (LED-powered, of course), and they have, in addition to the power cord and various switches, two sockets at the back for plugging XLR-3 cables. On investigation, it seems that this means they can be controlled by a protocol known as DMX 512, which opens up a lot of possibilities for someone who likes to control various things from a computer. I read a few web pages to get an idea of how this is supposed to work, it seems rather simple and straightforward, but the required software isn't in Debian yet. So I guess that if/when I get the necessary hardware, I'll have a new hobby and new toys to play with. Maybe our next gig will have bursts of lights on the big accented beats, triggered by “strong enough” hits on my drum cymbals.
This allows me to link to… a new minor release of Wiimidi. The only addition is a new configuration section mapping to the default drumkit provided by Hydrogen.
And finally, to stay in the “small bits of software”, I was prompted to give my simple GPG-encrypted password store, a.k.a. SGEPS, its own page, with a proper release and so on. So there, 0.1 is out, with minimal Debian packaging included.Posted mer. 30 janv. 2013 18:56:33 CET
A long time ago, I spent many many hours playing Frontier (Elite 2) on the family Atari ST. It was nice-looking (oh, those sunrises on distant planets!), playable, varied, had ample room for progression, very different possible roles, a huge universe of which nobody could ever hope of exploring more than a tiny fraction, and it was basically the first game I encountered with no set goals. You are a spaceship pilot in a galaxy colonised left and right, and it's up to you to decide what you want the game to be. Pirate, headhunter, mercenary, trader, taxi, explorer, there's no end goal to achieve except what you fix for yourself. That was, for me as a youngster, a mind-opening experience, which I never felt as strongly since (with the possible exception of the Creatures game, but I barely tried it).
Then came modernity, the PC, and the First Encounters sequel (Elite 3). It added moderate complexity to the gameplay, some sort of political evolution among the factions and a kind of plot so the galaxy was no longer quite so static, but the end results were still a bit disappointing. It felt like Frontier with a few not-exactly-overwhelming textures stuck onto the ships, a loose plot arc, and a third faction, the Alliance of Independent Systems, beyond the Federation and the Empire. Not that exciting, although the name of the Alliance's capital star system stayed in my mind.
So, like many others, I came to wait for Elite 4. That wait started in 1995, more than seventeen years ago. During that time, Duke Nukem Forever was announced, promised, developed, postponed, abandoned, found again, developed again, and it was even actually released in 2011, while Elite 4 went into the same kind of hell only without the actual release (yet).
At some point I started trying various substitutes to help pass time.
There was Parsec which was a nice-looking space combat simulator, multiplayer and all, but never felt like finished. Development slowed down to a thin trickle, and it seems like it only recently started again as Open Parsec. Hopefully it won't wither off again, but since it's only focused on combat, it's not exactly the same spirit as Elite.
There's Oolite, but it looks and feels very much like a lightly-modernised Frontier. Better textures, sure, but the UI still looks like it got taken from the times where games mentioned they required an EGA/VGA video card.
There's Vega Strike. It's very promising too, and I did try it at some point, but it was crashing too often for my tastes. Development seems to have slowed down, but not stopped; maybe it's time I gave it another go.
I just recently found out about Pioneer, and I admit I'm excited. Really excited. It feels like… like Frontier felt at the time. It's not finished yet (the on-planet cities in particular look a bit weird), but from the alpha I tried and the videos on the website it's really impressive. I'm going to keep an eye on that, knowing I could spend quite some time in there even before it's quite finished, if only to fly a spaceship in the canyons of Europa with Jupiter rising in the distance. I'll let you know if I find a black monolith.
But the main event triggering this blog post is that apparently Elite 4 is not dead (yet). Much better, it's under heavy development, under the Elite Dangerous name, and the current state seems to be rather good already. And Frontier Developments, the company behind it, opened a Kickstarter campaign to fund the project. The screenshots and the videos look impressive, and the interviews of the lead developer imply that the gameplay will be awesome. The galaxy will apparently be really dynamic, and the player's actions could really influence its geopolitical (galactopolitical?) evolution, the profitability of trade routes, the prevalence and repartition of space pirates in various sectors, and so on. Combine with a multi-player mode, and this could become the greatest game ever made (for my personal taste at least). So I'm very much hoping the funding campaign reaches its target.
The release date is set to March 2014. It's going to be a long wait, fraught with incertitudes.
But then again, Duke Nukem Forever was eventually released, wasn't it?
[No, I never played the original Elite. I'm not that old.]Posted ven. 14 déc. 2012 15:15:02 CET
Not that I'm bored or anything, but I spent some more time on this
since last month, and apparently some people are interested enough, so
here's the recent news about
- First, I think it's got generic enough that the “GH” part is no longer warranted. I've looked for a suitable name, and the best I found was the simplest. From now on, this piece of code will be known simply as Wiimidi. Various searches on the web led me to believe that it's a traditional name that's been used a couple of times already by projects that stopped evolving years ago. So mine will either continue in that vein and maintain the tradition, or stay alive and keep the name. Time will tell.
- I ended up doing the Debian packaging. It's fairly minimal, and I don't currently plan to actually upload it (unless asked to), but it's there.
- I also added support for sending MIDI “program change” events in addition to notes. Why, you wonder? See next item.
- A new set of settings called
program_changesin the sample configuration file, and a new
rhythmbox-midiscript. The goal is to control a Rhythmbox music player with your Wiimote (or possibly the attached drumkit).
- I also slapped a GPL-2+ license on it, which is consistent with the
Also, since the code moved (and it doesn't harm mentioning it again):
Wiimidi is developed with Bazaar, and the public branch is at
https://alioth.debian.org/~lolando/bzr/wiimidi/trunk/. So, to
grab a copy:
bzr checkout https://alioth.debian.org/~lolando/bzr/wiimidi/trunk/
Patches welcome, of course! Also, I'll be interested to hear about your applications. I've been told about a Wiimote-powered foot controller, which is exactly the kind of unpredictable results I was hoping to achieve by publishing my code. Keep it up, I want to hear about Wiimote-controlled robot dinosaurs next!
Update: Wiimidi now has its dedicated page at Wiimidi.Posted jeu. 29 nov. 2012 21:01:11 CET
Almost a year after my
previous post, I
felt inclined to spend another Sunday (this one was chilly rather than
rainy) working on my script to integrate the drumkit of Guitar Hero
World Tour for Wii within a MIDI environment. And
wiigh2midi got, if
not a rewrite, then at least a few enhancements since I last mentioned
- The buttons are now handled. The “cross-stick”, the A and B buttons, + and -, Home, 1 and 2. And if the Wiimote is plugged into a drumkit, you get even more buttons: another set of + and -, plus another mini-joystick. Thunder! Martians! Bubbles! Yay for sound effects!
- A side-effect: the drumkit is no longer even necessary. Run several instances with different configurations, give a wiimote each to a bunch of kids, and get them to perform a batucada by pressing the big round button in time. I tried and failed, but it was due to the age and over-excitedness of the bunch of kids in question rather than the technical side of things.
- Yeah, configurations. It's all in a nice
.inifile now, and you can define several “kits” (input-to-MIDI-note mappings) in different sections, and select which kit to use when running.
- The configuration can also define which MIDI device to send events to, and which channel to use. My use case is that sometimes I want to use my GHWT drumkit as a set of extra pads and send the MIDI stuff to my “real” electronic drumkit (over an USB adaptor), and sometimes I just want to send the MIDI events to a software synthesiser such as Hydrogen, to have a second, cheaper, lighter drumkit.
- Speaking of Hydrogen: since the MIDI-to-instrument mappings are
somewhat strange in there, I provided a template Hydrogen file with
a reasonable drumkit that matches the example configuration if
- Hey, you know, three toms, two cymbals and one pedal are really a small kit, even for beginners. And what about open/closed hi-hats? Well, we could, you know, split some of the pads so they can produce different “sounds” depending on context. Like, maybe if you hit the left pad real soft, you get a cross-sticks sound, but you get the standard snare drum sound if you hit it a bit harder (or very hard). And the open hi-hat could be obtained by hitting the yellow cymbal harder, with normal hits still sounding like closed hi-hats. And since the crash cymbal is usually hit markedly, while the ride is usually more of a soft-to-medium hit, you guess what we could do with the orange cymbal. Well, scratch the “could” there, that's exactly what we do now. So my cheap drumkit has hi-hats that open, a cross-stick sound on the snare drum, ride and crash cymbals, a bass drum and two toms. Not so bad.
It's still not something that I'd put in everyone's hands, but it's coming to be seriously usable. I wonder if there'd be any interest in me packaging that and uploading it to Debian? It would need some cleanup first (and a more generic name, since it's far from restricted to Guitar Hero controllers or drumkits), but I guess it could be useful. Ping me if you're interested.
Update: Wiigh2midi has been renamed to Wiimidi, and has its dedicated page at Wiimidi.Posted dim. 28 oct. 2012 21:00:03 CET
Hey, long time no see!
Okay, so what's new in FusionForge land these days? Well, I guess the most prominent news is that we've just declared 5.2 stable. It's been uploaded to fusionforge.org already, and Debian packages are on their way to Debian unstable. Yay!
Not-yay: the final weeks convinced us that the state of the 5.2 release candidates, and especially the packages in Debian Wheezy, wasn't near good enough for inclusion in a stable Debian release. So the packages won't be officially part of Wheezy when it comes out, to our great shame. The packages from unstable should work fine however, and we'll provide backports via the official Debian channel, backports.debian.org as soon as possible.
And finally: the developers (and some users) of FusionForge will gather for a work session in Paris on the 10th of October, as described on the Meeting/Oct2012 page on the FusionForge wiki. Join us if you're interested!Posted ven. 28 sept. 2012 16:00:02 CEST
This article documents how I'm currently building my firewalls. It builds on netfilter-based-port-knocking, and tries to integrate several components of a firewall as gracefully as possible.
For some context: I'm getting involved with servers where the firewall
policy goes beyond a handful of “SSH from my home and my other
servers” rules. There are many different network streams that need to
be policed, some of them are common across several (potentially many)
servers, and so on. So I'm gradually giving up on my hand-made
scripts, and trying out higher-level tools. I settled on FWbuilder,
which seems nice. However, it only allows static policies, and I
still want to keep dynamic policies such as what
as well as my own port-knocking system.
The problem I had was that
fail2ban isn't really made to play nice
as part of a complex firewalling setup, my port-knocking system was
too tightly integrated within my firewall script, and FWbuilder wasn't
too flexible when it came to delegating part of the firewall policy to
something external. Fortunately, this was only a perceived problem
(or a real problem in my understanding), because it is actually
possible to have all three blocks playing nicely together.
More context: as usual, I'm focusing on Debian-like systems. More
precisely, on those with a Linux kernel; it may be that FreeBSD's
firewalling subsystem has a feature comparable to Linux's
module, but I don't know.
Let's start with FWbuilder. This is not the place for a manual, the official documentation is rather complete. I'll assume you have defined most relevant blocks in there: firewall, hosts, IP addresses, services, and so on. You define your “static” policy with the standard rules. From then on, we want to integrate the external tools for dynamic rules.
Step 1: Integrating
fail2ban to have its own playground, so that it doesn't
overwrite anything in the standard policy. The trick is to define a
new “policy rule set” named
fail2ban. Leave it empty in FWbuilder.
So far so good, but
fail2ban (the daemon) still operates on the
INPUT chain in the firewall, and could therefore still mangle the
static rules. Fortunately, starting with
fail2ban 0.8.5 (available
from Debian Wheezy, or in the backports for Squeeze), you can define
what chain to operate on: with a configuration item such as
fail2ban (the daemon) will now only add its rules to
fail2ban (the firewall chain), and won't be able do damage the other
The missing part is to send some of the traffic to it using the
standard policy: i defined a rule sending the incoming SSH connections
fail2ban policy (“branching” in FWbuilder jargon).
Voilà: the static policy delegates part of the decision-making to a
sub-policy controlled by the
Step 2: Integrating port-knocking
This is a bit trickier, but we'll use a similar method.
First, the traffic used for port-knocking needs to be directed to the
chain that does the listening. Define a “policy rule set” named
portknocking, and leave it empty in FWbuilder. It'll be used by the
dynamic rules to track progression of source IP addresses through the
port-knocking sequence, so you'll need to send (“branch”) incoming
traffic there, probably after the rules allowing incoming connections
from known hosts.
The dynamic part of this will only concern the refreshing of this
“listening chain“, which we assume will do its work and mark IP
PK_ESTABLISHED once the sequence is completed. What we
do with these marked IP addresses will still be defined within the
We're going to need some complex rules since we want to filter
according to this
PK_ESTABLISHED bit and according to destination
port, for instance; unfortunately FWbuilder doesn't allow combining
filter criteria with and, so we define a new policy rule set called
accept_if_pk_ok. This ruleset has two rules: the second is an
ACCEPT and should be easy to understand. The first rule needs to
ACCEPT is only reached for connections coming from
PK_ESTABLISHED addresses, so it's going to be a bit tricky.
- The “service” needs to be a custom service (I called it “PK not
established”), since FWbuilder doesn't know about the marking
-m recent ! --rcheck --seconds 86400 --name PK_ESTABLISHEDfor the definition (change the duration to the number of seconds the door should stay open after the port-knocking sequence has been completed). Note the exclamation mark.
- The “action” is also going to be custom, defined as
-j RETURN. Again, this feature is
iptables-specific and FWbuilder doesn't provide any UI for it.
(Explanation: the first rule matches packets coming from IP addresses
not marked as
PK_ESTABLISHED, and returns them to the calling
policy. Packets remaining after this rule are those coming from the
appropriate addresses, and they go on to the
ACCEPT. We could have
had the first rule match on IP addresses that are marked, and branch
to yet another ruleset with the
ACCEPT part, but that would make it
harder to read, I feel.)
Now let's get back to the main policy and add rules concerning what
kind of traffic we want to allow once the port-knocking sequence
completed. For instance, we define a rule matching on the SSH
“service”, where the action is to “branch” to
an incoming packet tries to establish a connection to the SSH port,
it's passed to the
accept_if_pk_ok ruleset. If it comes from the
same IP as a recent port-knocking sequence, it goes on to be
ACCEPTed. If not, it returns to the main policy. Maybe static
rules further on will allow it to go through.
Step 3: tying it all together
Now that we have all the pieces, the rest is plumbing.
- Get FWbuilder to “compile” a script from the data. I called mine
$hostname.fw, and stored it into
- Write a
/usr/local/sbin/port-knockingscript that operates on the
portknockingchain and manages the
PK_ESTABLISHEDbit. It need not do more than what's described in netfilter-based-port-knocking.
- Write an initialisation script that calls both
/usr/local/sbin/port-knocking. I called mine
- Make sure that
fail2ban's initialisation script is called after ours. Either with boot sequence numbers, or with the LSB dependency pseudo-headers: I made my
Provides: iptables; since
fail2ban's script declares that it
Should-Start: […] iptables, we're fine.
/usr/local/sbin/port-knockingevery hour, or as often as needed to recalculate the port numbers.
With this setup, at boot time, the
$hostname.fw script creates the
static policy and the extra playgrounds; then the
script implements the listening for the magic sequence; then
fail2ban inserts its own rules. And there we are: three different
parts for the firewall policy, all integrating nicely. Mission
Note: (Mostly copy-and-pasted from the previous article) This article is deliberately short on details and ready-to-run scripts. Firstly because firewall scripts vary wildly so any script would have to be adapted anyway, but mostly because security is best handled with one's brain switched on. Fiddling with a firewall can easily open gaping holes or lock everyone out. So please make sure you understand what goes on before blindly pasting stuff into your own setup. Some bits are left as an exercise to the reader.Posted ven. 31 août 2012 18:00:02 CEST
Juste un petit mot en passant pour signaler que le merveilleux groupe Eleven dispose à présent d'un formidable site web, avec un fabuleux blog, des photos magnifiques, des vidéos de malade et même de la musique entraînante (les qualificatifs sont nécessairement subjectifs, à vous de vous faire votre idée). Et un blog, dont l'aspect visuel n'est pas sans rappeler celui du mien propre, on se demande bien pourquoi.
Donc sauf événement majeur (genre le jour où on fera la première partie de Guns 'n' Roses au Stade de France), les annonces relatives à ce génial groupe de rock et blues/rock, ses concerts et ses apparitions publiques se feront dorénavant là-bas. Cliquez, ajoutez le flux RSS, diffusez, faites tourner, profitez.
Là-bas, c'est sur http://eleven.entierement.nu.
Et un, deux, un-deux-trois-quatre !Posted lun. 23 juil. 2012 13:48:39 CEST