🚲 Tanguy Ortolo a écrit 12648 commentaires

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.

Ca serait pas plus simple pour eux d'avoir une page vrack.ovh plutôt que :
ovh.com/fr/serveurs_dedies/baie_virtuelle.xml pour FR
ovh.co.uk/dedicated_servers/virtual_rack.xml pour UK
ovh.de/dedicated_server/virtuelles_rack.xml pour DE
etc… ?

Je ne comprends pas. En quoi un nouveau nom de domaine est-il nécessaire pour avoir des URL courtes ? Ils peuvent déjà définir ce qu'ils veulent, genre, selon leurs préférences et contraintes :

http://ovh.com/vrack (avec détection automatique de la langue préférée de l'utilisateur)
http://ovh.com/vrack.fr (forçage de la langue)

D'ailleurs ça me rappelle un argument débile que j'avais lu à propos de ces TLD privés : c'est jaynial, ça va permettre de tout simplifier, par exemple Canon, au lieu d'utiliser http://www.canon.com/en/digital_cameras.html, va pouvoir utiliser http://cameras.canon/. Ben, les mecs, je vais vous donner l'astuce du siècle : si vous voulez utiliser des URL simples, vous pouvez le faire avec le nom de domaine que vous avez déjà : http://cameras.canon.com/ ! Pas besoin d'acheter un nouveau nom de domaine à un gazillion de dollars, elle n'est pas belle la vie ?

Accessoirement, c'est ce que je leur reproche dès le début. Chaque fois que je lis des conneries du genre :

On va avoir un .paris, c'est supaire et vachement utile parce qu'on va pouvoir vous vendre proposer des noms de domaines truc.paris.

je rétorque :

Youh ouh les gars, rien de nouveau, vous pouviez déjà faire ça avec paris.fr… Si vous ne vendiez pas déjà de truc.paris.fr, c'est parce que vous avez choisi de ne pas le faire, techniquement ce que vous allez proposer là, vous l'aviez déjà hein… (seulement vous êtes trop incompétents pour vous en être rendu compte évidemment)

Tout à fait ! Je ne comprends toujours pas pourquoi Paris est allé se faire chier dans des procédures administratives et (un peu) coûteuse pour avoir son .paris alors qu'il suffisait de vendre des .paris.fr et de réserver mairie.paris.fr pour les services municipaux…

Ça c'est tout vu : inculture des marketeux, pour qui vendre des noms de domaines implique d'avoir un nom de domaine de niveau supérieur, ou plutôt un suffixe parce qu'ils ne comprennent même pas la notion de hiérarchie et donc a fortiori de niveau supérieur. Pour eux, un domaine est un truc magique qui s'écrit bidule.tld, où tld n'a pas de point, sauf dans le cas baroque des .co.uk et autres .org.jp dont l'explication, qui ne les intéresse pas du tout, relève de la compétence inintéressante du boutonneux qui bosse au sous-sol. Donc, si on veut vendre des domaines liés à Paris, il faut avoir un .paris.

Cherchez pas, ce n'est pas rationnel, c'est marketeux.

Le but du DNS c'est de te permettre de taper un truc qu'un humain peut se rappeler. "Google" on peut s'en rappeler. google.skcjizrx , ça ne marche pas.

Évidemment, c'est pour ça que les TLD sont plus simples que cette très artificielle horreur de skcjizrx que tu as inventé pour l'occasion. google.com, ça se retient très bien.

Le système actuel permet d'avoir des différences sémantiques entre toto.com, toto.net, toto.fr, et bientôt toto.paris et toto.portnawak . Or, ce qui a du sens dans ces noms de domaine, c'est toto, c'est pas le suffixe. Le suffixe n'est qu'une suite de lettres arbitraires, comme le 3615 pour le minitel.

Non, dans le DNS, chaque niveau peut avoir une sémantique, et les TLD en ont une, en désignant les pays ou les activités concernées. Il n'y a rien d'arbitraire là-dedans, mais évidemment les utilisateurs sont libres d'en abuser pour créer artificiellement une confusion inutile. Genre acheter example.dk quand on est français.