🚲 Tanguy Ortolo a écrit 12091 commentaires

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.

Pour l'inutilité, c'est justement toute la question. Vu que la plupart des boites achètent leur nom en .com, .net, .fr, .uk, .de, etc., et réservent aussi tout un tas d'indésirables (.xxx), une centralisation de l'ensemble serait au contraire très utile.

Non, absolument pas. Faciliter un usage courant mais inutile n'est pas utile !

Voila, en vrai : qui bénéficie de ce bordel?

Toutes les personnes qui ont le même nom (sas) et les meilleures raisons du mondes d'utiliser un nom de domaine.

Mais quel est le service rendu à l'internaute?

Pouvoir accéder aux services de toutes ces personnes qui ont le même nom.

Dans tous les cas, ton seul serveur DNS fiable c'est Google (ou un autre moteur de recherche),

Ton seul annuaire ou service de recherche du veux dire.

mais tu ne peux faire aucune confiance aux noms de domaines pour 1) éviter de tomber sur une arnaque plus ou moins bien ficelée,

Normal, ce n'est pas le but du DNS. Ceci dit, utiliser le nom de quelqu'un d'autre en se faisant passer pour lui et nuire à d'autres gens, c'est un délit, et on peut lutter contre de façon normale, en attaquant l'arnaqueur en justice.

et 2) tomber sur quelque chose de cohérent avec ta recherche (en terme de notoriété, par exemple)

Normal, le DNS n'est pas fait pour rechercher quoi que ce soit, mais pour fournir un mécanisme de nommage un minimum humain, avec notamment des noms qui peuvent être notés sur papier ou mémorisés sans peine. Le DNS n'est en particulier par un point d'entrée pour accéder à des services, il faut passer par autre chose : carte de visite ou prospectus papier avec un nom de domaine (une adresse électronique, une URL…) écrit dessus, adresse envoyée par quelqu'un d'autre (par courrier électronique, par message instantané, par SMS) ou lien trouvé sur un autre service (page web, avec le cas particulier des moteurs de recherche).

(et pointeraient vers la même IP)

Je vois, mais il n'est pas question d'adresses IP ici. Seraient déléguées aux mêmes serveurs de nom, plutôt. Usine à gaz assez inutile à mon avis, et très complexe à mettre en œuvre.

Désolé, mais je trouve que c'est une remarque superficielle. Il suffirait simplement de rendre homonymes les .com dans les langues différentes

Qu'est-ce que ça veut dire ?

Perso je rajouterais plutôt un // devant chaque ligne, je trouve ça plus lisible.

Si vous n'aimez pas « s'élever dans le domaine public », au minimum utilisez la formulation neutre, que tout le monde comprend et qui ne fait tiquer personne : « entrer dans le domaine public ».

Programmer est un art…

(Geek&Poke, CC-BY 3.0)