Quelques nouveautés

En ce début d'année (scolaire, puisque dans l'éducation nationale on fonctionne comme ça), j'ai décidé d'ajouter une version "mobile" à ce blog, et à ma galerie photo. Mon entourage connaît en général mon dédain plus que profond pour tout ce qui ressemble à un téléphone permettant d'accéder à internet (tous les iBidules en général, en fait). J'aurai donc pu facilement m'abstenir de passer de longues heures à ajuster une version "mobile" de mes sites. Finalement, j'ai réalisé que c'est pour moi une manière ironique et provocante d'aller au bout de ma démarche : utilisateurs de iBidules, vous aurez droit à une version amputée du site. Sans doute bien plus lisible, mais partielle.
Cela dit, et sans mauvais esprit aucun : bonne visite à tous.

Et puis, pour justifier le pluriel de mon titre : j'ai aussi cédé aux sirènes des réseaux sociaux, puisque je suis désormais inscrit sur LinkedIn et Viadeo (Shame. On. Me.).

Publié dans Divers | Mots-clefs : | Laisser un commentaire

Cherche modèles et maquilleuses/coiffeuses

Portrait d'E. © Patrick Proniewski Pour perfectionner ma technique et travailler ma créativité, je cherche des jeunes gens (filles, garçons, ou autres), majeurs, pour de la photographie de portrait sur Lyon.
Je cherche aussi des étudiant(e)s dans les branches maquillage, coiffure et éventuellement stylisme pour m'assister. C'est sans doute une bonne occasion pour commencer un "book".

Les détails et conditions sont ici. Et quelques exemples de mon travail se trouvent dans ma galerie photo.

Si vous êtes intéressé(e)s, j'insiste : ne me contactez pas à partir d'une adresse hotmail, ma réponse aurait de grandes chances de ne jamais vous parvenir.

Il y a quelques mois, j'ai diffusé cette annonce sur le site étudiant de Lyon 2 pour recruter des modèles amateurs. À cette occasion, j'ai rencontré plein de jeunes filles très sympathiques (je ne désespère pas de trouver quelques garçons), et j'ai fait plus de 23 Go de photos.

Publié dans Photo | Mots-clefs : , | Laisser un commentaire

Chevelure

Publié dans Photo | Mots-clefs : , | Laisser un commentaire

Valve se moque des utilisateurs Mac

le scout, (c) valveJe me suis réjoui il y a quelques temps de l'arrivée sur la plate-forme Apple des jeux de Valve (Half Life 2, Team Fortress 2, Portal). Je n'aurai peut être pas du baisser la garde de mon scepticisme.
Les jeux sus-mentionnés ont bien été portés sur Mac, je ne peux pas le nier. Néanmoins, je pense (et je ne suis pas le seul), qu'ils ont été portés n'importe comment. Suivant votre configuration matérielle les jeux sont plus ou moins jouables, des problèmes de lenteur (voire de blocage) surviennent presque systématiquement pour de nombreux joueurs. Des problèmes de son ou de vidéo sont aussi constatés. On parle bien de jeux datants de 2004 à 2007, tournants tout à fait normalement sur des PC de la même époque (Pentium 4 et 512 Mo à 1 Go de RAM). Il est totalement inconcevable et inadmissible que ces jeux ne tournent pas de manière fantastique sur des bi-xeon dual core avec 4 Go de RAM, ou sur des Core 2 duo avec 8 Go de RAM (pour ne citer que deux des Mac sur les quels nous avons testé ces jeux).
Notamment, les temps de chargement sont astronomiques. Que vous passiez d'un niveau à l'autre dans Portal, que vous tentiez de rejoindre une partie de Team Fortress 2, ou qu'Half Life 2 fasse une sauvegarde automatique, vous serez immanquablement confronté à un pénible et très injustifiable temps de chargement. Certains ont encore moins de chance, car ils subissent des lenteurs ou des saccades au cœur même de l'action, des problèmes de son qui saute ou devient haché ou encore des temps de chargement avoisinant les 5 minutes.

Valve : vous vous êtes bien foutu de notre gueule.

Publié dans Grrr | Mots-clefs : , | 3 commentaires

Sylights : une idée lumineuse ?

Sylights, c'est un site web intéractif qui vous permet de construire et partager des plans d'installation de lumières pour des prises de vues. Si vous êtes photographe, et que vous travaillez souvent avec du matériel pour façonner votre lumière, vous comprenez ce dont il s'agit.
Boîtes à lumière, réflecteurs, "gobo", fonds, flashes… tout est là, ou presque, pour vous permettre de cartographier fidèlement vos montages de prise de vue. Il manque tout de même de quoi annoter les plans, et peut être quelques éléments comme des murs.

Je pense que c'est un très bon complément à Flickr (même si je n'utilise pas ce dernier).
Sylights devrait s'étoffer rapidement, avec des fonctions d'annotation, et la possibilité de poster des photos illustrant le montage de lumière décrit (ça semble primordial !).

Un petit exemple tout simple pour la route : mon premier essai.

L'avenir nous dira si c'est une idée lumineuse ou pas. Mais quand les plans seront ré-éditables, qu'on pourra y faire des annotations, et qu'on pourra les "hot-linker" depuis un blog, ça deviendra certainement un outil de référence !

Publié dans Photo | Mots-clefs : , , | 1 commentaire

Des filles et des pelles

Peut être le début d'une nouvelle série, qui sait ? En tout cas, c'est une idée à creuser je pense.

M. avec la pelle  A. avec la pelle

Publié dans Photo | Mots-clefs : , | 2 commentaires

Centraliser des logs sous FreeBSD

Utiliser syslogd pour centraliser les logs de machines distantes n'est pas toujours d'une grande facilité. La documentation n'est pas vraiment limpide et les exemples se font rares. Voici rapidement comment procéder pour centraliser des logs sur une machine sous FreeBSD 7.x.

Sur la machine qui reçoit les logs

Il faut remplir deux conditions : votre machine doit accepter les connexions à destination de syslogd, et ce dernier doit savoir quoi faire des données qu'il reçoit.
Pour dire à syslogd d'accepter les connexions venant du réseau, il suffit de modifier les paramètres de lancement dans le fichier /etc/rc.conf. Éditez ce fichier pour que la ligne syslogd_flags ressemble à ceci :

syslogd_flags="-c4C -a machine_distante"

Je vous renvoie au man syslogd pour la signification des options. Par exemple, si votre réseau est en IPv6, remplacer le 4 par un 6. "machine_distante" est le nom ou l'IP de la machine dont vous souhaitez centraliser les logs. Vous pouvez préciser plusieurs fois le paramètre -a, pour ajouter des machines, des netmasks...

Par défaut, syslogd n'accepte que les données qui proviennent d'une machine listée dans le -a, et dont le port distant est 514. Si vous souhaitez agréger des logs de machines sous Mac OS X Server par exemple, il vous faudra préciser le port "*", car ce système utilise un port non privilégié pour envoyer ses données :

syslogd_flags="-c4C -a machine_distante -a macosx_server:*"

Ensuite, il faut régler le contenu du fichier /etc/syslog.conf pour assigner une destination à chaque flux de log. Et c'est ici que la difficulté se trouve. Si on n'y prend garde, des données sont écrites dans de mauvais fichiers, d'autres ne sont pas écrites du tout.
Si les machines sont assez peu nombreuses, je recommande la simplicité : un bloc de définition = une machine. C'est plus verbeux, mais c'est aussi plus simple à corriger/modifier.
Un bloc consiste en une série d'instructions débutant par une définition de machine ou de programme (ou des deux). L'ordre doit toujours être :

  1. définition facultative de machine
  2. définition facultative de programe
  3. sélecteur et action
  4. ...

Pour éviter toute interférence entre deux blocs consécutifs, je recommande de placer à la fin de chaque bloc un "reset" pour la définition de machine. Voici un exemple :

   1: +machine_distante
   2: mail.info                                       /var/log/maillog
   3: +*
   4:
   5: +macosx_server
   6: mail.*                                       /var/log/maillog
   7: local5.*					/var/log/maillog
   8: +*
   9:
  10: +@
  11: *.err;kern.warning;auth.notice;mail.crit		/dev/console

Je suis ici tout au début de mon fichier /etc/syslog.conf. Ma première ligne indique que le bloc qui débute concerne les logs en provenance de la machine "machine_distante". Tout ce qui vient de cette machine, et qui appartient au sélecteur mail.info sera enregistré dans le fichier /var/log/maillog.
La troisième ligne fait un "reset" de la machine.
Ligne 5, j'ouvre un bloc qui concerne la machine "macosx_server". Lignes 6 et 7 je défini mes couples sélecteur/action, puis ligne 8 je ferme mon bloc avec un "reset".
Ligne 10, j'utilise le nom de machine @ qui représente la machine locale. Les lignes suivantes sont les couples sélecteur/action pour localhost.

Une fois tout ceci réglé, il vous suffit de relancer syslogd (en root) :

# /etc/rc.d/syslogd restart

Sur les machines qui envoient les logs

Pour finir, il reste à configurer le syslogd des machines distantes pour qu'ils envoient les données voulues vers votre serveur FreeBSD. À nouveau, je vous renvoie vers le man syslogd, qui à ce niveau est assez clair. Voici par exemple ce qu'il faut ajouter au fichier /etc/rc.conf d'un FreeBSD :

syslogd_flags="-cs"

Cela permet à syslogd de parler sur le réseau, sans l'autoriser pour autant à recevoir des connexions venant de l'extérieur.
Puis dans le fichier /etc/syslog.conf, on indique simplement les sélecteurs que l'on souhaite envoyer vers le serveur. Par exemple, ces deux lignes indiquent que je veux écrire les logs de mail.info en local et sur la machine distante "serveur_syslogd" :

mail.info					/var/log/maillog
mail.info					@serveur_syslogd

Relancez le syslogd de la machine dont vous modifier la configuration, assurez vous bien sûr que les firewall laissent passer le trafic qui vous intéresse, et tout devrait fonctionner.

Si ça coince

Si ça ne fonctionne pas, vous avez deux outils pour trouver le point de blocage. Le premier outil est tcpdump. Il vous aidera rapidement à voir ce qui sort d'une machine et ce qui arrive à l'autre. Par exemple, sur le serveur de log :

# tcpdump -A src or dst host machine_distante and port syslog

Cette commande vous permet de vérifier que les paquets venant de machine_distante vous parviennent bien sur le port 514. La commande suivante permet de vérifier, sur "machine_distante" que les paquets à destination de serveur_syslogd tentent bien de sortir :

# tcpdump -A src or dst host serveur_syslogd and port syslog

Si les deux commandes donnent satisfaction, alors la connexion entre les deux machines est bonne, et le problème ne vient pas d'un éventuel firewall.

Le second outil qui dépanne, c'est l'option -d de syslogd : le mode debug. Ajoutez ce paramètre à syslogd_flags dans votre rc.conf (sur la machine qui centralise les logs), et relancez syslogd. Après quelques lignes indigestes, les informations intéressantes arrivent. Voici un exemple :

   1: cvthname(192.168.0.20)
   2: validate: dgram from IP 192.168.0.20, port 514, name machine_distante;
   3: accepted in rule 0.
   4: logmsg: pri 26, flags 0, from machine_distante, msg ../..
   5: Logging to FILE /var/log/maillog
   6: cvthname(192.168.0.20)
   7: validate: dgram from IP 192.168.0.20, port 514, name machine_distante;
   8: accepted in rule 0.
   9: logmsg: pri 26, flags 0, from machine_distante, msg  ../..
  10: Logging to FILE /var/log/maillog
  11: cvthname(192.168.0.250)
  12: validate: dgram from IP 192.168.0.250, port 50194, name macosx_server;
  13: rejected in rule 0 due to port mismatch.
  14: rejected in rule 1 due to port mismatch.

Lignes 1 à 10, on a deux exemples de trames correctement acceptées par notre agrégateur de log, et venant du port 514 de "machine_distante".
Lignes 11 à 14, on a un rejet de trame, venant du port 50194 de la machine "macosx_server". Sans doute avons-nous oublié d'indiquer :* comme port autorisé pour la machine "macosx_server" dans les options syslogd_flags.
Ici, le mode debug nous dit clairement où est notre erreur : rejected in rule 0 due to port mismatch.
Si vous avez un gros débit de log, coupez rapidement le mode debug (ctrl-c), supprimez le -d de votre syslogd_flags, et relancer syslogd. Vous aurez tous le temps d'analyser la trace ensuite.

Publié dans Unix | Mots-clefs : , | Laisser un commentaire

Arles : Festival européen de la photo de nu

Affiche du Festival, photo  (c) Edouard de PazziPendant le week-end de l'ascension je suis retourné en Arles, pour suivre trois stages d'une journée sur le vaste thème de la photo de nu. Le sujet ne me passionne pas vraiment en tant d'acteur : j'ai bien plus de plaisir à regarder de beaux nus qu'à essayer d'en photographier moi-même. Néanmoins, les propositions étaient intéressantes : lumières continues ou naturelles, modèle contorsionniste…
Ainsi j'ai donc bravé une fois de plus les affres de la SNCF pour faire de la photo dans le beau pays d'Arles.
Malheureusement, si je puis dire, j'avais vécu un mois auparavant une expérience photographique et humaine très forte et très positive sous l'égide de Serge Picard, dans le cadre des Rencontres Photographiques (RP). À part le lieu, rien de commun. Le Festival Européen de la Photo de Nu (FEPN) est une entité plus modeste, et qui attire un public de stagiaires très différent de celui des RP. Pour tout dire, le premier stage m'a carrément mis mal à l'aise : que des hommes, tous plus vieux que moi, ayant pour certains l'air un peu mal dans leur peau, voire limite pervers. Bien sûr, c'est du "délit de faciès", et tous les stagiaires ne méritent certainement pas une telle classification hâtive et, j'espère, sans fondement. Mais les presque-bousculades pour être celui qui prendra plus de photos de la jeune femme dévêtue laissent tout de même un goût amer.
Le second stage s'est passé un peu plus sereinement, mais aussitôt la bride lâchée, les stagiaires se sont rués sur la jeune contorsionniste. Il fût alors bien compliqué d'obtenir un cadrage qui n'inclue pas en plus du modèle deux ou trois photographes.
Le troisième stage, sous la direction d'Édouard De' Pazzi, a été quant à lui bien maîtrisé. Tout le monde a été très courtois, ci-bien qu'aucune impression négative n'est venue obscurcir la journée.

backstage, Stage de Michel Choffray sur les lumières continues

Pris isolément, chaque stage vaut bien l'initiation au studio que j'ai suivie avec l'association Imag'in. C'est plus cher, mais c'est plus long. Et selon le thème on y trouve plus ou moins d'informations techniques. Le gros défaut, c'est le manque de suivi : il est bien évident que sur un stage d'une journée, il est totalement impossible de revenir sur les photos du jour avec le maître de stage, et d'envisager une quelconque progression.
Le stage d'une semaine aux RP offre quant à lui une vraie opportunité de travailler, de progresser, le tout dans une ambiance plus sereine et débarrassée de tous les aspects négatifs énumérés plus hauts.
Si vous cherchez une vraie expérience profitable, choisissez plutôt les stages des Rencontres Photographiques que les stages du FEPN.

note : première photographie © Edouard De' Pazzi

Publié dans Photo | Mots-clefs : , , | 1 commentaire