🚲 Tanguy Ortolo a écrit 12252 commentaires

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.

Pour les jeux en Java, pas grand chose sinon qu'il faut installer un environnement d'exécution assez lourd, qui peut dissuader certains utilisateurs. La réaction « fait chier, c'est du Java, je vais voir s'il n'y a pas une alternative native à ce logiciel » n'est pas un mythe.

Pour les jeux en Flash, c'est plus ennuyeux : comme Adobe ne distribue pas son lecteur Flash que sous la forme de plugin pour navigateur Web, ces jeux ne sont pas distribués avec l'environnement d'exécution, qu'on doit donc installer soi-même, avec l'effet secondaire d'activer ce lecteur pour tous les sites web qu'on visite, et on doit jouer dans son navigateur web. Bref, ça donne une impression assez désagréable.

Accessoirement, j'ai déjà vu quelques jeux, dont le portage pour GNU/Linux était en fait une winisation du lecteur Flash indépendant. Eh bien, l'impression est meilleure que ces jeux à utiliser dans le navigateur, je trouve.

Une précision, pour la configuration requise pour ces jeux, c'est là.

À noter les mises en œuvre un peu particulières de quelques-uns de ces jeux :

• Ticket to Ride est en Java ;
• Incredipede et Anodyne sont en Flash.

Qui est pourri de brevet donc inutilisable.

Bien entendu, WebP a d'autres avantages sur JPEG. En particulier, WebP offre le support d'un canal alpha, peut aussi servir de format sans perte (comme PNG) et peut contenir une image animée (comme GIF).

Pour moi, le taux de compression n'est qu'un simple avantage concurrentiel de WebP pour des usages déjà pris en charge par JPEG et PNG, alors qu'il surtout l'énorme avantage de venir combler un manque pour lequel il n'a aucun concurrent : la compression avec pertes avec canal alpha. Et de façon intelligente, avec notamment la possibilité d'avoir une compression avec pertes pour les couleurs, et sans perte pour l'alpha, qui est généralement caractérisé par de grands aplats de transparence ou d'opacité totale.

Cas d'usage : photos détourées et dessins sans aplats. Exemples : photos à réutiliser pour des montages, hackergotchis. Aujourd'hui on stocke tout ça en PNG, qui est lamentable pour compresser ce genre de chose, puisque pas fait pour, et on ne peut pas envisager d'utiliser JPEG, qui n'a pas d'alpha.