Original post of Romaine Lubrique.Votez pour ce billet sur Planet Libre.

Suite du billet PHP-FPM et HTTPD 2.4

Jusqu'à présent, on devait passer par la directive ProxyPassMatch, pas très souple, voici comment faire plus simple.

La version Apache HTTP Server 2.4.9 récemment publiée sera bientôt disponible dans les mises à jour de Fedora 20.

Cette version intègre un correctif (pas encore appliqué dans la version officielle) qui permet de rediriger les requêtes vers un mandataire FastCGI à l'aide de la directive SetHandler.

La directive ProxyPassMatch étant évaluée au tout début d'une requête

• les directives AddType (pour le MultiView) ou DirectoryIndex ne sont pas utilisables
• la gestion des droits par dossier n'est pas prise en compte
• chaque Alias doit être complété d'une règle de proxy

La directive SetHandler qui est évaluée à la fin est donc beaucoup plus pratique, elle est d'ailleurs utilisée pour mod_php

      SetHandler application/x-httpd-php-source

Grâce à cette évolution on va pouvoir utiliser php-fpm aussi simplement que mod_php.

Pour rediriger les scripts PHP vers le serveur FPM:

         SetHandler "proxy:fcgi://127.0.0.1:9000"

Attention, si vous désinstallez ou désactivez mod_php vous devez aussi supprimer toutes les directives php_value et php-flag, par exemple en les rendant conditionnelles :

        php_value session.save_handler "files"
        php_value session.save_path    "/var/lib/php/session"
        php_value soap.wsdl_cache_dir  "/var/lib/php/wsdlcache"

Au passage, on peut en profiter pour abandonner le MPM prefork au profit d'un mode utilisant les threads :

#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
LoadModule mpm_event_module modules/mod_mpm_event.so

Ensuite, les applications web en PHP fonctionnent normalement (sauf celle utilisant l'authentification http, qui n'est pas encore supportée par FPM).

A suivre : l'utilisation des Sockets du domaine Unix, annoncé pour la 2.4.9 mais ne fonctionne que partiellement (les correctifs sont en cours de revue).

Original post of Remi Collet.Votez pour ce billet sur Planet Libre.

Le « moteur de rendu » de Firefox (le cœur de Firefox, si on veut) est actuellement Gecko. C’est un logiciel issu d’une longue évolution, stable, mais qui date de l’époque où les processeurs étaient mono-cœur (encore une histoire de cœur !). Désormais, même le moindre petit smartphone dispose de deux cœurs minimum. Nous sommes donc complètement dans l’ère du parallélisme, qui permet d’améliorer la vitesse d’exécution et la réactivité des logiciels. Le moteur de rendu expérimental Servo que Mozilla développe depuis environ un an avec Samsung, répond à cette nouvelle donne. Bien que Mozilla déclare officiellement qu’il ne s’agit que d’un projet expérimental, le développeur Patrick Walton vient d’annoncer sur Twitter que Servo a réussi le test Acid2. On se doute bien que Mozilla ne s’amuse pas à consacrer des ressources à un tel projet pour le simple plaisir d’expérimenter sans penser un jour à remplacer Gecko… et cette étape marque un avancement intéressant dans ce sens. Cela provoque aussi des débats entre développeurs, certains contestant l’utilité du test Acid2 par rapport à l’objectif d’expérimentation en matière de parallélisme. Affaire à suivre…

Original post of mozillaZine-fr.Votez pour ce billet sur Planet Libre.

N'étant pas un grand fan du WYSIWYG, j'ai commencé à écrire des documents en LateX, sous un simple éditeur de texte, du type gEdit ou SublimeText, et un terminal avec la commande qui va bien pour construire mon PDF. Puis j'ai découvert Gummi, un éditeur LateX qui affiche en temps réel une preview du document final.

En effet, le Latex est un langage de balise, qui nécessite d'être "compilé" pour générer le document final, généralement un PDF. Moi qui préfère garder le contrôle de ce que j’écris, en passant par un éditeur WYSIWYG je perd cette proximité avec le texte et on laisse finalement, le logiciel écrire lui même en LateX. Sans parler du faite qu'on fini par oublier la syntaxe LateX par manque de pratique. L’inconvénient de tout écrire soit même, c'est que je doit garder un terminal ouvert pour relancer la commande qui va régénérer le PDF, à chaque paragraphe que j'écris.

J'ai finalement trouvé un juste milieu, il s’appelle Gummi. Il s'agit d'un éditeur LateX, qui vous laisse écrire le "code" et qui affiche, en temps réel, une preview du document final.


Parmi les autres fonctionnalités, on trouvera la possibilité de gérer un projet de plusieurs feuilles LateX, et de gérer une bibliographie au format BibTeX. Et puis bien sûr, Gummi est capable de générer le document final au format PDF.

L'éditeur est donc léger, très simple d'utilisation et fait ce qu'on attend d'un éditeur LateX, rien de plus, rien de moins. Parfait pour moi, et je le recommande vivement à tous ceux qui écrivent en LateX ou qui souhaitent apprendre.

Pour l'installation c'est simple. Le nécessaire est disponible dans les dépôts officiels des principales distributions, il s'agit des paquets : gummi et texlive.

Si vous connaissez d'autres outils de ce type n'hésitez pas à les partager en commentaires ;-)

Site officiel : http://dev.midnightcoding.org/projects/gummi
Wiki installation : http://dev.midnightcoding.org/projects/gummi/wiki/Downloads

---

Un article à retrouver sur P3ter.fr

Original post of P3ter.Votez pour ce billet sur Planet Libre.

Le site de Pyfreebilling , softswitch voip et plateforme de facturation pour l’activité d’opérateur Wholesale vient d’être lancé. Vous y trouverez une présentation du projet, des screenshots (je vais en ajouter d’autres, pas d’inquiétude), le détail des mise à jour et très important la licence du projet (GPL v3). Une section blog a aussi été créée et bien entendu un lien vers le repo bitbucket.

Et maintenant, ben c’est la nouvelle mise à jour, la 1.3 (vous avez le détail sur le site )

Original post of Mathias.Votez pour ce billet sur Planet Libre.