Je feuilletai la documentation de l'outil grep lorsque mon fil de pensée a abouti sur mon camarade Suédois Pierre (appellons le comme ça).
J'ai rencontré Pierre sur IRC par l'intémédiaire du channel de Jeri Ellsworth il y a quelques année.
Pierre est très fort en électronique, il est ce que j'aurais pu être si mon dada avait été le fer à souder.
Cependant Pierre n'est pas du tout patient lorsqu'il s'agit d'apprendre l'informatique, si ça ne fonctionne pas du premier coup, alors ça ne vaut pas un clou.
Je me sers de GNU/Linux tout les jours. J'ai une passion pour UNIX et j'ai voulu la partager avec lui... à plusieures reprises... sans succès...
Au mieux Pierre installait Ubuntu pour le désintaller aussitôt au moindre hic (ie: ne pas comprendre comment installer les drivers vidéos...).
Il m'a confié un jour qu'il n'utiliserait GNU/Linux que si il pouvait y faire tourner toutes ses applications Windows et si le terminal acceptait toutes les commandes DOS.
Bien que ce soit théoriquement possible (à grand coup de Wine est d'alias), j'ai compris sa réplique.
Et aujourd'hui une idée me frappe. C'est le contraire que l'on fait ! Ce ne sont pas les commandes/outils Windows que l'on porte vers d'autres OS, mais ce sont les outils UNIX ! Vim, grep, bash, etc...
On les porte d'UNIX vers Windows car ils sont meilleurs que ce que propose Windows par défaut.
Mais Pierre ne s'en servira jamais. Il est à ce stade ingrat (que j'ai connu aussi) où, à défaut d'avoir connu DOS pendant trop longtemps, l'on arrive pas à comprendre exactement ce qu'est un Terminal UNIX et comment cela puisse-t-il parfaitement cohabiter avec une interface graphique.
Et c'est là que j'ai compris. Pierre ne comprends pas ce qu'il manque.
Quel fut mon bonheur lorsque j'ai découvert et appris à manipuler les scripts shell, vim, et les commandes de base d'UNIX. Je n'en suis qu'au début et j'ai tant à apprendre ! Je n'en verrais sûrement jamais la fin (au sens propre du terme... à mon grand regret).
C'est pour cela donc. Pierre ne peux pas regretter cela, parce qu'il ne peux pas comprendre ce que je vis avec mon terminal.
mardi 10 juillet 2012
mardi 26 juin 2012
Le meilleur gâteau à la banane au monde.
Je viens de réaliser un gâteau à la banane vraiment délicieux aujourd'hui et j'en suis extrêmement fier.
Voici la recette :)
Voici la recette :)
- Préchauffez le four th. 7 (210°C).
- Mélangez les ingrédients suivants dans une jatte :
- 2 oeufs
- 1 yaourt nature
- 2 pots de farine (utilisez le pot de yaourt)
- 2 pots de sucre
- Un peu de levure, utilisez la dose conseillée sur le sâchet
- 1/3 ou 1/4 de pot d'huile
- 5 bananes réduites en purée grossière
- Versez la pâte dans un moule à savarin
- Laissez le gâteau cuire pendant 25minutes au four (il est conseillée de surveiller le gâteau de près pendant les 5 dernières minutes, on ne sait jamais).
- Une fois cuit, laissez le gâteau s'ahérer
- Mangez :)
samedi 23 juin 2012
Créer des "time-lapse" avec une webcam simplement sous GNU/Linux
J'ai toujours eu une fascination pour les time-lapse. Il y a quelques années, j'en avais déjà produit un avec la webcam de mon Père sous Windows XP. J'avais trouvé une petit outil... probablement payant et que j'avais cracké, je ne sais plus.
Le temps à passé, j'ai accumulé des webcams diverses et variées et je ne me sers plus que de Arch Linux (ou Parabola lorsque le matériel me le permet).
Je me sers ici d'une 808 Car Keys Micro Camera en mode webcam (modèle #3, le modèle #8 ne fonctionne pas sous GNU/Linux).
Ce que j'aime avec la communauté du libre, c'est qu'il existe toujours un logiciel simple et concret qui correspond à ce que vous avez envie de faire.
Mes connaissances en informatiques étant largement supérieures à ce qu'elles étaient, j'ai trouvé un moyen "plus simple" pour créer un time-lapse :
1) Trouver un logiciel en ligne de commande qui prend une photo avec la webcam.
2) Faire un simple script bash pour répéter l'action toutes les X secondes.
3) Utiliser FFMpeg ou MEncoder pour produire le fichier vidéo.
Le seul problème réside dans l'étape 1). Une simple recherche Google m'a amené sur des dizaines (littéralement) d'articles de blogs sur la question qui proposaient tous des solutions alambiquées allant jusqu'à utiliser trois ou quatre logiciels différents (!?), ou des solutions simples mais avec des logiciels qui n'existent plus ou qui ne fonctionnent pas.
À force de persévérance j'ai fini par trouver le logiciel fswebcam qui remplit parfaitement la tâche 1). Je pensais pouvoir tout faire uniquement avec FFMpeg, mais celui-ci n'arrive pas à lire /dev/video0 directement.
fswebcam permet d'enregistrer une photo de la webcam au format PNG ou JPG, en y incrustant la date et l'heure (option activée par défaut) et/ou d'autres textes encore.
Le but maintenant est de faire un script qui enregistre une photo toutes les X secondes avec un nom différent, de préférence un nom qui permet de classer les images par ordre chronologique (bien qu'il soit possible de faire ce tri après sans se baser sur le nom des fichiers mais c'est trop d'ennuis).
Si vous êtes familier avec Unix, vous connaissez sans doute l'existence du temps Unix qui compte les secondes écoulées depuis le 01/01/1970. Ainsi il suffit de nommer le fichier avec le temps Unix où celui-ci est enregistré et le tour est joué.
Vous pouvez afficher le temps Unix dans le terminal en tapant la commande "date +%s".
Le script est donc le suivant :
Peu importe...
La boucle est donc en marche, les paramètres --no-timestamp --no-banner permettent d'obtenir simplement l'image de la webcam sans la date imprimée dessus, --png permet de sauver l'image au format PNG, et enfin --save %s.png permet d'utiliser le temps Unix comme nom du fichier (ne me demandez pas pourquoi %s tout seul et pas date +%s comme dans l'exemple).
sleep 5 permet effectivement d'attendre cinq secondes avant de répéter la boucle.
Pour l'encodage de la vidéo à partir des images capturées, je me suis inspiré d'une commande trouvée sur un des blogs. Je me pencherai plus tard dessus pour la remplacer par une commande FFMpeg car elle ne me plaît pas.
Il faut d'abord lister les fichiers obtenus dans un fichier texte avec la commande ls -1tr *.png > files.txt, puis demander à MEncoder de créer un fichier vidéo à partir de cette liste :
mencoder -nosound -ovc raw -o test.avi -mf type=png:fps=30 mf://@files.txt
Le résultat est suffisant, mais pas assez bon selon mes critères (le fichier n'est pas lisible avec FFPlay, allez savoir pourquoi).
Après quoi on obtient un joli time-lapse à mettre sur YouTube ! :)
Le temps à passé, j'ai accumulé des webcams diverses et variées et je ne me sers plus que de Arch Linux (ou Parabola lorsque le matériel me le permet).
Je me sers ici d'une 808 Car Keys Micro Camera en mode webcam (modèle #3, le modèle #8 ne fonctionne pas sous GNU/Linux).
Ce que j'aime avec la communauté du libre, c'est qu'il existe toujours un logiciel simple et concret qui correspond à ce que vous avez envie de faire.
Mes connaissances en informatiques étant largement supérieures à ce qu'elles étaient, j'ai trouvé un moyen "plus simple" pour créer un time-lapse :
1) Trouver un logiciel en ligne de commande qui prend une photo avec la webcam.
2) Faire un simple script bash pour répéter l'action toutes les X secondes.
3) Utiliser FFMpeg ou MEncoder pour produire le fichier vidéo.
Le seul problème réside dans l'étape 1). Une simple recherche Google m'a amené sur des dizaines (littéralement) d'articles de blogs sur la question qui proposaient tous des solutions alambiquées allant jusqu'à utiliser trois ou quatre logiciels différents (!?), ou des solutions simples mais avec des logiciels qui n'existent plus ou qui ne fonctionnent pas.
À force de persévérance j'ai fini par trouver le logiciel fswebcam qui remplit parfaitement la tâche 1). Je pensais pouvoir tout faire uniquement avec FFMpeg, mais celui-ci n'arrive pas à lire /dev/video0 directement.
fswebcam permet d'enregistrer une photo de la webcam au format PNG ou JPG, en y incrustant la date et l'heure (option activée par défaut) et/ou d'autres textes encore.
Le but maintenant est de faire un script qui enregistre une photo toutes les X secondes avec un nom différent, de préférence un nom qui permet de classer les images par ordre chronologique (bien qu'il soit possible de faire ce tri après sans se baser sur le nom des fichiers mais c'est trop d'ennuis).
Si vous êtes familier avec Unix, vous connaissez sans doute l'existence du temps Unix qui compte les secondes écoulées depuis le 01/01/1970. Ainsi il suffit de nommer le fichier avec le temps Unix où celui-ci est enregistré et le tour est joué.
Vous pouvez afficher le temps Unix dans le terminal en tapant la commande "date +%s".
Le script est donc le suivant :
#!/bin/bash
while (( 1 )) ; do
fswebcam --no-timestamp --no-banner --png --save %s.png
sleep 5
done
Pour la petite histoire, je n'ai jamais compris comment les boucles while fonctionnaient lors d'un script shell. J'ai beau avoir essayé while [ 1 ], while [[ 1 ]] avec ou sans le do à la ligne. Peu importe, il n'y a que while (( 1 )) ; do qui fonctionne. Il me semblait pourtant avoir réussi plusieurs fois à faire des scripts contenant des boucles infinies avec while [ 1 ].while (( 1 )) ; do
fswebcam --no-timestamp --no-banner --png --save %s.png
sleep 5
done
Peu importe...
La boucle est donc en marche, les paramètres --no-timestamp --no-banner permettent d'obtenir simplement l'image de la webcam sans la date imprimée dessus, --png permet de sauver l'image au format PNG, et enfin --save %s.png permet d'utiliser le temps Unix comme nom du fichier (ne me demandez pas pourquoi %s tout seul et pas date +%s comme dans l'exemple).
sleep 5 permet effectivement d'attendre cinq secondes avant de répéter la boucle.
Pour l'encodage de la vidéo à partir des images capturées, je me suis inspiré d'une commande trouvée sur un des blogs. Je me pencherai plus tard dessus pour la remplacer par une commande FFMpeg car elle ne me plaît pas.
Il faut d'abord lister les fichiers obtenus dans un fichier texte avec la commande ls -1tr *.png > files.txt, puis demander à MEncoder de créer un fichier vidéo à partir de cette liste :
mencoder -nosound -ovc raw -o test.avi -mf type=png:fps=30 mf://@files.txt
Le résultat est suffisant, mais pas assez bon selon mes critères (le fichier n'est pas lisible avec FFPlay, allez savoir pourquoi).
Après quoi on obtient un joli time-lapse à mettre sur YouTube ! :)
lundi 18 juin 2012
L'ordinateur au service de l'homme.
Il faut vraiment que j'apprenne à exploiter à fond les scripts bash et mon fichier .bashrc.
Je me souviens avoir découvert ce que je manquais en jetant un coup d’œil au .bashrc de Aaron Griffin. Cela m'a fait un choc.
La simple fonction "mkcd" qui crée un dossier et se déplace directement dedans m'avait bluffée.
J'ai donc commencé à écrire les miennes. Une fonction pour effectuer une recherche DuckDuckGO dans lynx et une autre pour faire une copie d'un disque dans un fichier binaire.
function cd2bin () {
if [ $1 != 0 ]; then
sudo cdrdao read-cd --read-raw --datafile "$1".bin --device /dev/sr0 --driver generic-mmc-raw "$1".toc
else
echo Please enter a filename
fi
}
Peut-être que cela aidera quelqu'un.
Je me souviens avoir découvert ce que je manquais en jetant un coup d’œil au .bashrc de Aaron Griffin. Cela m'a fait un choc.
La simple fonction "mkcd" qui crée un dossier et se déplace directement dedans m'avait bluffée.
J'ai donc commencé à écrire les miennes. Une fonction pour effectuer une recherche DuckDuckGO dans lynx et une autre pour faire une copie d'un disque dans un fichier binaire.
function ddg () {
if [ $1 != 0 ]; then
lynx https://www.duckduckgo.com/?q="$1";
else
lynx https://www.duckduckgo.com/;
fi
}
if [ $1 != 0 ]; then
lynx https://www.duckduckgo.com/?q="$1";
else
lynx https://www.duckduckgo.com/;
fi
}
if [ $1 != 0 ]; then
sudo cdrdao read-cd --read-raw --datafile "$1".bin --device /dev/sr0 --driver generic-mmc-raw "$1".toc
else
echo Please enter a filename
fi
}
Peut-être que cela aidera quelqu'un.
dimanche 12 février 2012
La puce graphique Intel i810
À chaque fois que je parle d'un truc technique, je pers confiance en moi car je sais que je n'ai ni les connaissances ni le vocabulaire nécessaire/suffisant.
C'est un peu comme si je savais à la fois que ce que je dis est vrai que je ne sais absolument pas de quoi je parle.
Aujourd'hui donc je vais parler de quelque chose que je maîtrise affreusement mal (comme tout le reste en informatique) le framebuffer.
J'ai la (mal)chance d'avoir un petit tas d'ordinateur ici qui ne possèdent rien d'autre qu'une puce Intel i810 pour l'affichage.
En vérité, le nom de la puce qui apparaît lorsque l'on fait un lspci est tout autre, mais à grand coup de recherches sous DuckDuckGo, j'ai fini par comprendre qu'il s'agissait d'une i810.
Le défaut du driver fourni par Intel (pour Xorg) est qu'il ne donne aucun accès au framebuffer. Ce n'est pas un secret, Intel le dit lui même sur son site (j'ai la flemme de refaire les recherches nécessaires pour vous le prouver).
Par dessus tout, le support pour Mesa a été retiré récemment (ainsi que pour d'autres appareils) donc le support pour la 3D (aussi maigre soit il) se voit lui aussi amputé.
Apparemment l’intérêt du framebuffer est que des applications graphiques peuvent communiquer directement avec le matériel sans passer par un serveur X pour afficher quelque chose, ce qui rendrait tout plus rapide. Le projet MESS prétend pouvoir atteindre des gains de performances jusqu'à 300% en utilisant le framebuffer plutôt que X pour l'affichage.
J'ai récemment découvert que quelques années plus tôt, quelqu'un s'était penché sur la question et avait fait un driver pour avoir accès au framebuffer du i810. Le driver fait partie du noyau GNU/Linux (depuis la version 2.6 ce celui-ci) en tant que module sous le nom "i810fb".
Le petit problème étant que le périphérique /dev/fb0 n'est pas créé au démarrage du système. Un modprobe i810 ne mène donc à rien puisqu'il n'y a pas de périphérique à initialiser/utiliser.
Il faut donc créer le périphérique à la main en utilisant la commande mknod /dev/fb0 c 29 0.
Malheureusement, une fois l'ordinateur redémarré, il faut tout recommencer.
J'ai donc modifié mon fichier /etc/rc.local pour contenir les lignes suivantes :
mknod /dev/fb0 c 29 0
modprobe i810fb
Ainsi, le framebuffer est activé automatiquement à chaque démarrage de l'ordinateur.
Comment être certain que cela fonctionne ? Il suffit de lire une vidéo avec MPlayer en utilisant le paramètre -vo fbdev2. La vidéo s'affiche en mode console, sans avoir besoin de X.
C'est un peu comme si je savais à la fois que ce que je dis est vrai que je ne sais absolument pas de quoi je parle.
Aujourd'hui donc je vais parler de quelque chose que je maîtrise affreusement mal (comme tout le reste en informatique) le framebuffer.
J'ai la (mal)chance d'avoir un petit tas d'ordinateur ici qui ne possèdent rien d'autre qu'une puce Intel i810 pour l'affichage.
En vérité, le nom de la puce qui apparaît lorsque l'on fait un lspci est tout autre, mais à grand coup de recherches sous DuckDuckGo, j'ai fini par comprendre qu'il s'agissait d'une i810.
Le défaut du driver fourni par Intel (pour Xorg) est qu'il ne donne aucun accès au framebuffer. Ce n'est pas un secret, Intel le dit lui même sur son site (j'ai la flemme de refaire les recherches nécessaires pour vous le prouver).
Par dessus tout, le support pour Mesa a été retiré récemment (ainsi que pour d'autres appareils) donc le support pour la 3D (aussi maigre soit il) se voit lui aussi amputé.
Apparemment l’intérêt du framebuffer est que des applications graphiques peuvent communiquer directement avec le matériel sans passer par un serveur X pour afficher quelque chose, ce qui rendrait tout plus rapide. Le projet MESS prétend pouvoir atteindre des gains de performances jusqu'à 300% en utilisant le framebuffer plutôt que X pour l'affichage.
J'ai récemment découvert que quelques années plus tôt, quelqu'un s'était penché sur la question et avait fait un driver pour avoir accès au framebuffer du i810. Le driver fait partie du noyau GNU/Linux (depuis la version 2.6 ce celui-ci) en tant que module sous le nom "i810fb".
Le petit problème étant que le périphérique /dev/fb0 n'est pas créé au démarrage du système. Un modprobe i810 ne mène donc à rien puisqu'il n'y a pas de périphérique à initialiser/utiliser.
Il faut donc créer le périphérique à la main en utilisant la commande mknod /dev/fb0 c 29 0.
Malheureusement, une fois l'ordinateur redémarré, il faut tout recommencer.
J'ai donc modifié mon fichier /etc/rc.local pour contenir les lignes suivantes :
mknod /dev/fb0 c 29 0
modprobe i810fb
Ainsi, le framebuffer est activé automatiquement à chaque démarrage de l'ordinateur.
Comment être certain que cela fonctionne ? Il suffit de lire une vidéo avec MPlayer en utilisant le paramètre -vo fbdev2. La vidéo s'affiche en mode console, sans avoir besoin de X.
Inscription à :
Articles (Atom)