🚲 Tanguy Ortolo a écrit 12706 commentaires

Pareil, avec un esprit que je veux synthétique, chaque fois que je conçois quelque chose, avant tout j'essaie de simplifier au maximum sa mise en œuvre, et je ne comprends pas qu'on puisse mettre en place de telles usines à gaz alors qu'une simple taxe sur le carburant aurait suffi, surtout vu les inconvénients de la méthode choisie à la place.

Et si les logiciels le mettent en œuvre. Comme on parle surtout du web, je vous rappelle que cette application d'Internet est restée fossilisée à une époque antérieure à la simple introduction des enregistrements DNS dédiés aux protocoles, le premier étant le MX pour le courrier électronique, et n'a pas évolué depuis. HTML a évolué, HTTP est resté figé. Donc l'adoption d'un truc pareil, ce n'est pas pour demain, enfin dans Firefox il y a peut-être une chance, encore que, mais alors dans les autres…

Par contre j'ai vraiment du mal a comprendre pourquoi il faut absolument vérifier la véracité de l'identité de la personne. Pourquoi ne pas simplement se borner a vérifier que l'on est bien le locataire/gérant du nom de domaine ?

C'est la seule chose qui est vérifiée pour les certificats de six mois. Et je suis d'accord, il n'y a pas de raison de vérifier l'identité, à moins de la mettre dans le certificat, ce qui n'est pas fait aujourd'hui. C'est d'ailleurs une absurdité du modèle actuel : quand tu vas sur le site de ta banque, ou que tu consultes ton courrier, tu te moques du nom de domaine, ce qui t'intéresse, c'est en réalité l'identité de la personne qui possède les serveurs auxquels tu te connectes.

Édit : non rien (j'avais mis un commentaire qui n'était pas pertinent parce que répondant à aurte chose en fait).

Je l'avais écarté à dessein ;)

Je ne comprends pas la raison. Autant écarter l'auto-signé dans ce cas.

D'un point de vue purement pragmatique, un certificat CAcert est aussi utile pour les usages d'auto-hébergement vu qu'il faut faire une manipulation technique pour le faire reconnaître à une machine.

Pas compris.

Ça a l'air facile sous Debian, qu'en est-il sur un poste Windows, un Mac, un smartphone, une tablette ?

Aller sur le site de CAcert, installer le certificat racine, sans garantie sur son intégrité.

Ca ressemble fortement au cas 1 cette histoire…

En un peu plus sérieux.

Tu as oublié de mentionner CAcert. Je complète donc.

utiliser un certificat de chez CAcert

• Avantages : demander un certificat ou son renouvellement est facile et gratuit.
• Contraintes : les utilisateurs doivent récupérer le certificat racine de CAcert par un canal sécurisé, par exemple en installant le paquet Debian ca-certificates puis en important le certificat en question dans leur navigateur depuis leur système de fichier. À noter que même si ce n'est pas automatique, c'est déjà plus sérieux que d'accepter aveuglément un certificat auto-signé.
• Usage propices : hébergements de services avec volonté libriste ou sécuritaire ou rejet des autorités de certification commerciales.

On peut également mentionner le fait que la vérification d'identité par les membres de la communauté CAcert est nettement plus sérieuse que celle qu'effectuent les autorités de certification commerciales, dont l'intérêt est en fait de ne rien vérifier du tout pour éviter de devoir refuser des ventes. Mais cet avantage concerne le (mauvais) système X.509 en général et non les utilisateurs.

Eh bien c'est tordu. LNMP serait plus compréhensible non ?

LEMP ? LAMP, je connais, ça veut dire GNU/Linux, Apache, MySQL et PHP, mais LEMP ? Que signifie le E ?

Et ils sont adhérents à l'April. J'ai eu quelques pannes avec eux, suite à des tempêtes en Bretagne, où ils sont installés, mais ils rétablissent le service rapidement une fois l'événement passé.

• gestion de commentaire (par exemple avec disqus)

Non, pitié, pas Disqus… On n'installe pas son propre service d'albums photos pour aller mettre les commentaires sur un service privateur centralisé !

Une galerie ? De quel logiciel parles-tu ?

Accessoirement, c'est également une fonctionnalité qui différencie assez bien les services libres, dont il est facile d'extraire les données, des services privateurs dont il est difficile de sortir et qui encouragent l'utilisation exclusive de leur propre écosystème. Google Picasa par exemple…

(après dans mes contraintes il y a des points bonus, comme l'utilisation de mots-clefs ou la localisation par exemple)

Note que je ne prétends pas que c'est une fonctionnalité qui sera demandée ou utilisée par beaucoup de gens, simplement que c'est une fonctionnalité très importante. C'est comme pouvoir changer soi-même l'huile d'un moteur ou l'eau d'un circuit de refroidissement, je doute que les gens le fassent souvent, il est très important de pouvoir le faire.

Là, le cas d'usage c'est un événement avec plusieurs personnes. A priori, tout le monde est intéressé par les photo. Les regarder en ligne, c'est une chose, mais il est important de pouvoir les récupérer définitivement, pour pouvoir les consulter lorsque le site sera retiré. Après, que les gens le fassent ou non, c'est leur problème, ce qui est important c'est de leur permettre de le faire.

En ce qui me concerne, ça fait partie des fonctionnalités indispensables. Actuellement, pour choisir un logiciel d'album photo en ligne, je regarde ceux qui :

• permettent l'organisation en albums hiérarchiques (exit MediaGoblin) ;
• permettent le téléchargement (exit EnVadrouille pour le moment) ;
• ne nécessitent pas de serveur de base de données (exit Gallery).

Bon, actuellement j'utilise Gallery, mais c'était clairement un choix par défaut à l'époque où j'avais dû choisir. Aujourd'hui, je me tournerais plutôt vers PhotoShow je pense. Si EnVadrouille évolue et se trouve répondre à mon besoin, j'en profiterais bien pour l'empaqueter pour Debian.

Parce que c'est un langage qu'on choisit souvent par défaut. Comme langage, c'est de la merde, c'est incohérent au possible, avec de grosses fautes de conception. Mais c'est disponible presque partout. Les hébergements mutualisés proposant le plus souvent PHP.

Bref, on choisit PHP pour être accessible, mais on n'aime pas ça, donc on n'est certainement pas enthousiaste à son sujet.

Comme API cartographiques, tu peux regarder du côté d'OpenLayers et de Leaflet. J'ignore s'ils conviendront, vu que je ne connais strictement rien à ce sujet.

Une fonctionnalité essentielle pour tout logiciel d'albums photos à mon avis, dès qu'il s'agit de partager des photos avec des gens : fournir un moyen de télécharger un album entier. Aujourd'hui, à moins que je n'aie loupé quelque chose avec HTML5, il n'y a à ma connaissance qu'une seule façon de faire : générer une archive contenant toutes les photos. Et ça implique d'utiliser PHP ou un autre langage de script côté serveur pour cela, parce que tout pré-générer, bof bof…

La barre de recherche n’est plus commune entre les différents onglets. Par ailleurs, elle change de tête et dispose maintenant d’une petite animation quand elle apparaît ou disparaît.

Précision, il s'agit de la barre de recherche au sein d'une page, pas de la zone d'appel d'un moteur de recherche sur le web.

Oui, évidemment.

Aujourd'hui je cherche tout d'abord à couvrir mes textes, documents, images, photographies, sons, musiques et clip vidéos. J'envisage de passer le blog sous Creative Commons By, tout simplement car j'ai réalisé que cette licence était contaminante. Ça ne me dérangerait pas d'être publié dans une revue.

Et la clause Share-Alike ne posait pas de problème pour cela. Elle s'applique aux modifications de ton œuvre, pas à l'ensemble d'une œuvre composite telle qu'un journal.

Le contenu d'une <iframe> peut être écrit directement dans la balise au lieu de faire obligatoirement référence à une autre page afin d'être conforme à la norme HTML5.

Quelqu'un aurait-il une idée de ce à quoi cela peut bien servir ? Parce que j'ai beau me creuser la tête, je ne vois pas l'intérêt que peut avoir un cadre HTML avec son contenu directement dans la page où il est défini…

Actuellement, si je comprends bien la situation, aucun projet « n'utilise FFmpeg ou Libav » : ils utilisent des bibliothèques, comme la libavcodec par exemple, qui peut être fournie par FFmpeg ou par Libav. En revanche, s'il commence à y avoir dans ces bibliothèques des fonctions qui n'existent ou qui n'utilisent des options que dans l'une ou l'autre version, là on a un vrai problème.

Pour ceux qui ne connaîtraient pas le mproblème, FFmpeg a été forké par certains de ses contributeurs, sous le nom de Libav. Les deux projets, FFmpeg et Libav, fournissent essentiellement les mêmes bibliothèques, sous les mêmes noms, mais Libav se distingue par le retrait programmé de la commande ffmpeg, remplacée par un outil nommé avconv, avec un message à la limite de la calomnie — c'est à dire que dire que ffmpeg est caduc, c'est faux en général, et vrai uniquement dans le cadre des outils fournis par Libav.

Le mainteneur des paquets relatifs à FFmpeg dans Debian étant un des initiateurs de fork Libav, il est évidemment passé à ce nouveau projet pour ces paquets. Dans Debian, on ne trouve donc pas FFmpeg mais seulement Libav. Quand à l'état de cette guéguerre, à ma connaissance elle continue, mais j'ignore si ça cause de gros problèmes ou non. Si une compatibilité absolue est maintenue, pas de problème à mon avis, mais s'ils s'amusent à jouer avec l'API, le faire sans changer les nom des bibliothèques, ça craint un max.

Ben c'est normal ça : si tu règles OpenSSH pour n'autoriser un utilisateur qu'à faire du SFTP et plus de SSH, il ne peut plus faire de SSH hein.