Buf a écrit 449 commentaires

On a 3 blocs d'adresses privées définis dans la RFC 1918 :

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

• 10.0.0.0 - 10.255.255.255 (10/8 prefix)
• 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
• 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

127.0.0.0/8, c'est pour le loopback, c'est pas sensé être utilisé pour un réseau, même privé. 0.0.0.0, ce n'est pas une vraie ip, ça sert simplement d'alias pour dire "toutes les ips de la machine". Voir RFC1700

Bref, seuls les 3 premiers choix sont valides, et sont équivalents. La seule différence, c'est la taille du préfixe.

Et plus facile à communiquer et à retenir (surtout pour un non-informaticien)

Le problème de performances, il est au niveau des logiciels (clients et serveurs) qui ne sont pas prévus pour gérer un grand nombre de messages, mais ce n'est pas une fatalité. Imap n'a aucun problème à gérer des boites avec plusieurs milliers de messages, tant que le soft aux deux bouts est capable de gérer ça convenablement.

Mon compte perso doit en être à plus de 6000 messages dans INBOX, je n'efface que le spam et je ne trie ou archive rien. C'est aussi rapide et réactif qu'avec une boite presque vide (après mise en cache des messages par le client, bien sûr)

Le système de fichiers, c'est surtout beaucoup d'emmerdes potentielles au niveau des permissions.

En général, pour des raisons de sécurité, on aime bien faire tourner le serveur web avec un utilisateur le moins privilégié possible (et si possible différent de celui qui possède les fichiers de script). Bref, habituellement, on ne peut écrire nulle part (sauf répertoire temporaire)

Si on gère soi-même le serveur, on peut s'en sortir sans trop de mal, mais sur du mutualisé, c'est très souvent tout simplement impossible d'utiliser le système de fichier pour stocker autre chose que des fichiers statiques et les scripts pour les pages.

Il me semble que le PVC n'est plus utilisé pour faire des bouteilles, on utilise plutôt du PET

Le script JS est pas super intelligent (il faudrait par exemple ajouter une classe CSS sur les images disponibles en haute résolution plutôt que d'y aller aveuglément sur toutes les images). Et effectivement, il y a le problème des images chargées à double. Le problème, c'est que je ne vois pas tellement d'autres moyens de faire ça plus proprement pour les tags img.

Par contre, l'astuce à base de CSS est très bonne, même si elle ne fonctionne que pour les images mises en background.

Une autre piste pour les écrans haute définition : utiliser du svg partout où c'est possible. C'est pas adapté pour les photos, mais pour tout ce qui est icône et pour la plupart des images décoratives, c'est une option intéressante (en gardant un fallback png pour les vieilles versions d'IE)

mode troll=on

En même temps, tout ce qui peut décourager les jeunes de se mettre à PHP, c'est au final une bonne chose, ça les poussera à aller voir du côté des vrais langages de programmation.

Aux négociations protocolaires près, c'est exactement la même chose

Oui, mais c'est exactement à cause de ce "détail" que FTP est un protocole pourri.

le téléchargement : je parle de gros fichiers

C'est quoi le problème d'utiliser HTTP pour ça ? Et tu verrais quoi à la place ?

Pour ftp, je dirais la vitesse (sur les gros fichiers) car le transfert peut être fait directement en binaire

C'est pareil en HTTP. Aucun avantage de FTP à ce niveau-là (et sur les petits fichiers, FTP est beaucoup plus lent que HTTP)

Pas vraiment.

Avec HTTP, le client ouvre la connexion, demande les données, et les reçoit du serveur.

Avec FTP, le client ouvre la connexion, demande les données, puis le serveur ouvre un deuxième socket, envoie son IP et le port au client, qui va ouvrir une deuxième connexion dessus, et finalement recevoir les données.

Conclusion : HTTP > FTP pour le téléchargement de données (car plus simple, moins d'overhead, et qui évite une gymnastique assez pénible pour gérer le routage ou le firewalling)

go fmt ne respect pas la sacro-sainte règle des 80 colonnes

Ça n'a absolument rien de sacré, ça vient d'une limitation matérielle qui n'existe plus depuis longtemps.

Sur mon écran, 80 colonnes de texte avec des caractères d'une taille agréable pour travailler, ça n'occupe même pas la moitié de la largeur de la zone de texte de mon éditeur. J'aurais vraiment pas envie qu'un outil décide de me couper les lignes à 80 colonnes, ce qui aurait pour principal effet de rendre le code moins lisible (et de gaspiller une bonne partie de mon espace d'affichage)

Genre un truc comme Visual Studio ?

La solution à tout, ça serait donc de manger des bébés, mais là aussi, ça a du mal à passer auprès de la plupart des gens.

Au passage, j'ai tenté de voir combien compte une base oracle, et j'ai pas très bien compris. dans la mesure ou c'est visiblement cher ( on me parle de 10 000 euros, mais je sais pas si c'est avec ou sans maintenance, sur combien de core, avec quel features etc )

Oracle doit avoir un des systèmes de tarification les plus opaques qui existe. En gros, le seul moyen d'avoir un prix, c'est de prendre contact avec un vendeur qui fera une offre personnalisée sur la base de critères divers et variés. Le seul truc qu'on sait d'avance, c'est que ça va couter cher… (prix à 5 chiffres minimum)

Exactement. Suffit de lire le premier paragraphe de la RFC :

This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

C'est juste un récapitulatif de ce qui se fait, à aucun moment ça ne prétend définir une norme.

Ta RFC, elle dit exactement pareil que moi : il n'y a pas de spécifications formelles pour le CSV.

Mais je ne vois toujours pas pourquoi ne pas mettre msg en attribut

D'un point de vue pratique, un attribut est pas terrible pour un texte potentiellement assez long. Dès que ça fait plus de 2-3 mots, c'est plus lisible dans un élément séparé.

Norme ISO! 2001-12-31T12:00:00Z
Un caractère de plus… "Il suffit", juste que dans ce cas ce sera "oublié" à un moment… Et on a une norme pour les dates, autant l'utiliser.

Le schéma définit le champ comme étant de type xs:dateTime, qui permet justement de préciser avec la syntaxe ISO dont tu parles. Donc on peut sans problème spécifier explicitement le fuseau horaire (et j'espère qu'en pratique, ça sera le cas), et si c'est pas précisé, je pense que ça doit être l'heure locale.

Ensuite, j'ai l'impression que ceux qui ont pondu le schema, ne connaissent pas vraiment XML (comme beaucoup de développeur d'ailleurs, faut voir les formats xml de certains autres logiciels libres…)

J'ai plutôt l'impression qu'ils ont conçu le truc pour qu'il y ait un mapping 1:1 entre JSON et XML, et que le passage de l'un à l'autre soit trivial.

Après, ok, ça donne du JSON un peu bizarre et du XML sous-optimal, mais ça me semble finalement assez secondaire, le truc important étant qu'on peut travailler indifféremment avec les 2 représentations. Ça me semble être un compromis acceptable.

À mon avis, les raisons de cet état de fait sont assez proches des raisons qui font que Windows a 90% de part de marché : c'est ce que les gens connaissent (ou au moins, ils en ont entendu parler), la plupart des applications sont développées pour, c'est fourni en standard par la plupart des hébergeurs, et ça marche suffisamment bien pour qu'ils ne cherchent pas autre chose.

Tiens, en parlant de la lisibilité du CSV, voici ce que pourrais donné les messages d'exemple une fois passés en CSV :

"2001-12-31T12:00:00","WARN","HTTPD10001","File does not exist: /usr/local/apache/htdocs/favicon.ico"
"2001-12-31T12:00:00",,,,"login","500","/sbin/unix_chkpwd","pts/0","example.com","keith","success"
"2001-12-31T12:00:00",,,,"login",,"/bin/java",,,"keith","success","Tomcat","https://www.example.com/login.do" 

C'est vraiment plus lisible que du XML ou du JSON ? Plus compact, certainement, mais pour ce qui est de la lisibilité, j'ai comme un doute…

On peut carrément se passer de racine aussi, et obtenir un fragment XML (au lieu d'un document). Ça reste tout à fait utilisable, et l'insertion ligne par ligne devient aussi facile qu'avec syslog.

Les entrées de log peuvent être vues comme des objets, les critères auxquels je pense se rapportent aux attributs de ces objets. Des trucs genre "level=WARN" ou "srcIP in 192.168.0.0/16" (j'invente complètement, mais c'est l'idée)

Des trucs de haut niveau quoi, pas un bête pattern matching sur une chaine de caractères. Rien n'empêcherait même d'avoir comme critère une regexp, mais sur un attribut (ou groupe d'attributs) particulier au lieu d'être sur une ligne complète.

J'ajouterais encore que CSV n'a pas la souplesse requise. En CSV, on définit un certain nombre de colonnes, on donne un sens à chacune, et c'est fini. Possibilités d'extensions : proche de zéro.

Dans les exemples donnés, on voit bien qu'on peut définir des schémas pour des données spécifiques à un type d'application. C'est beaucoup plus souple.

Pourquoi ne pas se baser sur le csv et convenir d'un en-tête pour la structure (séparateur de colonne & ligne) à la manière du shebang (#!) des scripts?

1. ça ne sera plus du CSV valable (dans le sens où les outils qui bouffent du CSV vont pas le reconnaitre)
2. pourquoi réinventer un format alors qu'on en a 2 existant qui permettent de faire exactement ce dont on a besoin (JSON et XML) ?

D'autre part comme dit plus loin dans les commentaires, quid de l'écriture dans le cas du xml avec sa balise root?

Voir ma réponse au commentaire en question.