Joris Dedieu a écrit 1610 commentaires

que personne n'est tout noir #000000 ou tout blanc #FFFFFF

L'été certains parviennent quand même au #FF0000 et au #00FF00 à noël. Pour le #0000FF c'est plus dur.

Je pense qu'un outil comme alfresco est exactement ce dont vous avez besoin. Édition collaborative, découpage en projet, publication, lien avec les réseaux sociaux … voir aussi nuxeo, twiki …

Pour l'autentification, Un ldap ne suffira sans doute pas. Il te faudra sans doute un web-sso (Si vous conservez un milliard d'outils en tout cas) : lemonldap::ng est ton ami

ut rentrer le bon nom du paquet sinon c'est sûr que rien ne va s'installer. Il faut donc installer xfce4

Tout est d'ailleurs ici : https://wiki.archlinux.fr/Xfce

Normalement - je ne connais pas trop les machins de MS - mais tu dois pouvoir faire du reverse assez simplement si ce n'est pas un moteur de stockage maison.

Il faut aussi voir ce qu'on gagne en passant à du binaire.

Je crois que plus trivialement la question qui se pose est d'éviter la compression et d'être efficace dans l'implémentation. Tes en-tête binaires, tu les colles dans une structure (qui au passage existe déja dans toutes les implémentations ou presque (ici httpd.h de chez apache)) :

#define M_GET        0
#define M_PUT        1
#define M_POST       2
#define M_DELETE     3
#define M_CONNECT    4
#define M_OPTIONS    5
#define M_TRACE      6
#define M_PATCH      7
#define M_PROPFIND   8
#define M_PROPPATCH  9
#define M_MKCOL     10
#define M_COPY      11
#define M_MOVE      12
#define M_LOCK      13
#define M_UNLOCK    14
#define M_INVALID   15

Oh ! surprise, on traduit en binaire des en-têtes texte pour pouvoir appliquer des masques comme par exemple dans nginx (modules/ngx_http_static_module.c) :

 if (r->method & NGX_HTTP_POST) {

Pour la surabondance et le foutoir, on peut toujours prier ou militer. Apparemment c'est mal barré (http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-19). Mais je crois qu'il ne faut surtout pas se tromper de débat. La question qui est posée est texte compressé vs binaire, pas texte rationnel vs binaire. On peut concevoir que ce ne soit pas le bon débat mais c'est ainsi qu'il se pose. C'est ce que j'ai essayé d'évoquer en filigrane dans l'article. HTTP/1.1 ayant la place qu'il a aujourd'hui, il va être remplacé par un protocole beaucoup plus agressif. C'est un fait. Cela signifie entre autre que le débat binaire / texte est déja tranché. Ce sera binaire, reste à savoir si ce sera du binaire intelligent que tu colles dans ta structure après t'être posé trois questions ou le charabia actuel comprimé qu'il faudra décomprimer avant de le parser pour finir par faire finalement une structure binaire (retour en 1) que tu va exploiter, puis refaire le chemin inverse.

Et il me semble qu'au niveau de l'efficacité d'une implémentation, il n'y a pas photo entre les deux propositions.

Suffit de dire que le port spécifié dans l'url écrase celui du srv

Oui par exemple. Il faut juste le standardiser :)

Pourquoi donc ?

Pour clarifier la question du port qui peut être spécifié et dans l'url et dans le srv.

Il n'y a pas que le filtrage. Il y a aussi le load-balancing.

En fait, il y a plein de cas pour lesquels des reverse proxies sont nécessaires.

C'est un moyen couramment utilisé par exemple pour transmettre une requête à un serveur applicatif (tomcat, thin …). Décider si la requête est applicative ou non nécessite alors un cycle de décompression.

Ce n'est qu'un exemple. Dans toute les archi web un peu lourde, il est courent d'avoir des chaines de traitement des requêtes complexes mettant en oeuvre divers niveaux de proxies et de caches.

Je me demande dans quelle mesure, ça ne sort pas du scope. Historiquement http est un protocole indépendant du transport. Donc qui peut en théorie être très bien utilisé sur autre chose que de l'IP. Bon on voit bien que ça parle quand même beaucoup de "connexions tcp" donc c'est peut-être un peu illusoire. Mais sans doute l'une des raisons.

Une raison plus fondamentale est que cela demande de revoir le format des URL.

Il y a eu un draft en 2002 à ce sujet : http://tools.ietf.org/html/draft-andrews-http-srv-01

Il y a suexec mais d'après ce que j'ai lu, aucun n'est vraiment efficace en terme de performance…

De mon experience, suexec n'est pas vraiment pénalisant. Le problème est surtout de passer de module vers fastcgi.

En fastcgi tu as moulte solutions qui permettent de contourner ce problème : suexec, spawn_fcgi, php-fpm

Après des délibération dont le contenu reste secret (sur demande de Mr Croset)

Décidément, il y en a qui n'ont toujours strictement rien compris à rien.

C'est normal. Google utilise DKMS, ce qui permet d'éviter le

DKIM …

très délicat en cantines pour maintenir les plats assez chaud 40°c de mémoire, sans avoir de pâtes trop cuites.

Or tu n'as pas le droit de maintenir quelque chose au chaud en dessous de 60° durant plus de 2 heures (pour cause de terrain favorable au développement microbien). D’où la seule bonne façon de faire des pâte en grand nombre :

• les cuire bien al dente dans de l'eau bien salée (à cause du rinçage)
• les égoutter et le rafraichir vivement avec de l'eau froide et de la glace
• les égoutter une seconde fois
• les huiler un peu et le stocker au frigo bien filmé/
• les réchauffer à la minute dans de l'eau bouillante (plonger la passoire avec la quantité ad-hoc de pâtes dans un grand volume d'eau bouillante salé).
• les assaisonner et servir.

Autant saler avant de servir

Saler l'eau te donne un salage uniforme.

Une bonne bière, ça se boit tiède !

La bière c'est Belge ou ça n'est pas !

Toujours de l'huile d'olive sauf pour les coquillette. Parce que les coquillettes au beurre ça le fait.

Question : qui a encore des cartes-son avec accélération "audio"?

Personne. On préfère faire du passthru vers l'ampli qui lui fait du décodage hard.

x et y ont une messagerie email Orange qui d'une manière générale marche bien

Marrrrffffffffff :) Celle là c'est la meilleure.

Je ne crois pas que ce soit un problème entre la chaise et le clavier

Le problème est les serveurs smtp de AOLOrange qui (après avoir été openrelay durant des années) ne marchent simplement plus.

• mails qui mettent des jours à arriver
• mails qui disparaissent
• mails silencieusement refusés …

Durant un moment comme évoqué plus bas, il suffisait d'utiliser orange-msa. Mais les problèmes ont fini par les gagner aussi. La seule solution est de ne pas utiliser leurs serveurs. Y compris si ton domaine est hébergé chez eux. Par chance, il n'y a pas de spf sur aolorange.fr

(uw-imap) savait désormais présenter de grosses boîtes mbox - sans doute grâce à la montée en puissance des machines actuelles.

Pas si tu as beaucoup d'io par ailleurs. Dovecot est largement supérieur sur des grosses mbox dans un contexte très chargé.

J'espère juste que cela ne va pas se finir en fragmentation à la Unix…

Fragmentation ou diversité ?

C'est beaucoup trop compliqué. La vente lié, c'est facile, tu allumes, ça marche…

Non, tu allumes, tu acceptes le cluf et ça marche. Rien que le fait que le cas ou tu refuses ne soit pas prévue est un scandale en soit.

Si tu as 1000 vhost, ce n'est pas un gouffre en performance d'utiliser mpm_itk ?

Même sur 100. ITK n'est clairement pas utilisable en prod.

lancer une instance de nginx/apache par utilisateur, plus un reverse-proxy devant ?

Sur quelques dizaines de sites c'est une bonne solution mais elle est pour l'heure relativement difficile à industrialiser.

• le monitoring et la conf sont très difficiles à gérer. Tu passes d'une sonde globale à une sonde par site (on parle des services pas de l'applicatif), d'un fichier de conf, php.ini unique … à un par site. Tu multiplie le risque d'erreur et le risque d'oublie. Si tu as par exemple 1000 vhosts par serveur web, cela multiplie tous ces éléments par mille et suppose une mise à l'échelle importante de tes outils (tes serveurs nagios par exemple). Si tu rajoutes à cela de la haute dispo ça devient vraiment très compliqué.

• au niveau des ressources tu es obligé de partager à priori (typiquement avec apache un max_client par site). Tu gagne donc en cloisonnement mais tu perd en souplesse ("burst" d'un site). Eg : ton site fonctionne bien mais plante lors du passage d'un bot.

• sur un très grand nombre de socket tu peux avoir des effets de bord difficiles à diagnostiquer.

• idéalement tu chroot / jailise tout ça, alors tu as la problématique de gérer les points de montages (nullfs ou -o bind + /dev), les mails (fonction mail du php -> commande sendmail donc spool … )…

Par contre :
- le gain est énorme en sécurité
- le partage des ressources est efficace

Je suis en train d’essayer de prototyper ça sur une échelle assez importante. C'est loin d'être évident.

Avoir un serveur qui gère les différents utilisateurs est déja possible dans apache avec suexec. Cela offre un cloisonnement raisonnable (pour le fastcgi par exemple), facile à mettre en oeuvre et surtout une solution "facile" pour l'utilisateur final (son cms marche out of the box dans 90% des cas). Il est juste dommage de ne pas pouvoir en profiter pour les fichiers statiques également. Ce qui te permettrait de réduire considérablement les permissions sur les répertoires.

D'un point de vue d'adminsys l'un des grands intérêt des logiciels de la famille nosql est la facilité d'une scalabilité horizontale (ajouter de nouveau serveurs) globalement mieux prévue et beaucoup moins complexe que sur les services de base relationnelle type mysql / postgresql.

Tu as un très bon tuto sur la façon d'utiliser les données osm avec mapserver ici :
http://trac.osgeo.org/mapserver/wiki/RenderingOsmDataUbuntu

A noter le dépôt UbuntuGIS : http://trac.osgeo.org/ubuntugis/wiki

Négatif, l'objet n'a aucune importance,

Non c'est bien de l'objet qu'on parle ici. Un texte n'est pas immatériel. Un texte a forcément un support. A l'image d'un tableau, d'une sculture, d'une morceau de musique, un film. C'est bien l'objet qui caractèrise l'oeuvre. Un texte c'est des mots sur un support.

Le fait qu'un texte soit facile à reproduire ne change rien. Sans support tu n'as pas de texte, pas de musique, pas de film, pas de logiciel. Contrairement à une idée qui elle est immatérielle. Elle n'a pas besoin de support pour exister et se diffuser.

Je pense que tu confonds immatériel et oeuvre de l'esprit.

une fois diffusé, ça circule ; vouloir restreindre sa diffusion ne peut être qu'artificiel.

On peut militer pour une libre circulation des oeuvres de l'esprit et reconnaitre un droit moral à l'auteur. Respecter la volonté de l'auteur tu le fais pour les logiciels pourquoi ne le ferais-tu pas pour du texte ?