J'ai noté Modoboa dans ma liste de projets à suivre, je pense que je m'en servirai quand je referai mon serveur perso (j'en profiterai pour m'occuper de mes mails). En attendant, j'ai quelques questions :
comment est géré la configuration ? Je sais que django utilise généralement un fichier settings.py, mais personnellement je n'aime pas trop cette méthode (c'est peu pratique pour les mises à jour). Pour mes propres projets, je me suis fait un wrapper qui me permet de fusionner plusieurs settings.py (l'application fournit un settings.py et le fusionne intelligemment avec /etc/application/settings.py). Comme ça, on peut avoir un fichier de conf fonctionnel par défaut, on peut mettre à jour facilement et l'utilisateur peut modifier les paramètres.
pour le webmail, comment est gérée l'authentification ? J'avoue ne pas avoir bien suivi cette partie-là. J'aimerais bien me débarrasser complètement des mots de passe chez moi, et malheureusement plein d'applications ne prennent pas ça en compte :(
Mais c'est déjà le cas, non ? Je pense que n'importe quel logiciel de bibliothèque musical permet de faire ça.
Et si on veut la même chose directement dans des dossiers, c'est relativement facile de faire ça en tout cas sur OS X : on peut créer des dossiers dits « intelligents » qui contiennent les éléments répondant à certains critères (j'ai ainsi un dossier qui contient les fichiers téléchargés durant les 10 derniers jours). Il suffit de coupler ça à l'événement « nouveau fichier » pour créer un dossier de recherche manquant (par exemple un dossier par décennie pour les films, quand je rajoute un film dans une décennie qui n'existait pas encore).
Potentiellement, il s'agit d'acheter plusieurs ARM pour remplacer un seul Xeon.
Supposons que deux ARM consomment moins qu'un seul Xeon (et qu'ils soient aussi puissants, ce dont je doute) : ça pourrait être rentable d'un point de vue écolo de remplacer les Xeon, mais ça va dépendre du prix écologique de production des processeurs (et du recyclage des anciens).
De son point de vue, la meilleure solution est peut-être de sélectionner un hébergeur qui n'a que de vieux processeurs (qui ont été les mieux rentabilisés de ce point de vue).
Autre chose qui serait intéressante à prendre en compte : le reste du cycle de vie du matériel (je ne suis pas sûr que l'électricité consommée, surtout nucléaire, soit la partie la plus polluante).
Passer à du 4096 bits est en effet coûteux : pour s'en rendre compte, il suffit de faire le test avec un serveur web et quelques tailles de clefs jusqu'à 8192 bits. J'avais fait le test (avec des requêtes « vides »), et tu peux diviser par deux les performances (de mémoire, j'avais fait ce test rapide il y a deux ans).
C'est un test très empirique et critiquable, mais qui permet au moins de se rendre compte qu'utiliser des clefs de taille importante peut avoir un coût non négligeable.
Tout à fait d'accord ! Et tu oublies le mélange TeX et LaTeX, au passage :D Ce n'est pas facile de distinguer les deux types de commandes. Il y a également le fait de devoir recompiler le texte à chaque modification, également.
Mais c'est vrai qu'il n'y a rien de mieux pour faire certaines choses…
J'ai tendance à être comme toi, mais parfois faire du typage dynamique (voire générer des classes à la volée) est parfois bien pratique. Ça permet (parfois) de beaucoup simplifier le code. Personnellement (mais je ne prétends pas que ça soit LA méthode à suivre), j'essaie de faire comme si Python avait un typage statique fort (90% du temps, à la louche), mais je n'hésite pas à faire du duck-typing et autres joyeusetés quand ça aide vraiment à avoir un code plus concis et plus lisible.
Pendant ma thèse, ceux qui tapaient leurs manuscrits sous Word s'arrachaient les cheveux à chaque modification pour cause de déplacement intempestif des images lors des ajouts/suppressions de paragraphes: toute la mise en page foutue en l'air.
Ça m'est pourtant souvent arrivé en LaTeX. Tu rajoutes une petite phrase (ou un mot), et ton document prend une page de plus… ou le contraire : tu rajoutes un mot, et ton article perd une page.
Pour mon boulot, je dois reprendre des documents tapés avec Word par d'anciens collègues. Entre ceux qui utilisaient MathType, ceux qui foutent des line break (shift+enter) parce qu'ils veulent sauter des lignes sans faire apparaître l'espacement inter-paragraphe (ce qui donne des situations cocasses en justifié), ceux qui changent le formatage des titres 1 par 1 sans définir correctement le style, je n'ai pas l'impression de gagner en productivité avec Word…
Tu compares du Word tapé par des personnes qui ne savent pas se servir de Word à du LaTeX tapé par quelqu'un qui sait se servir de LaTeX. La comparaison est subtilement biaisée, non ?
J'ai déjà généré via des scripts des documents pour Word : il suffit de générer du HTML, et Word saura parfaitement l'ouvrir et l'éditer (pour l'enregistrer dans du .docx).
D'ailleurs, j'ai eu à générer le même document pour Word (donc via HTML) et pour LaTeX : j'ai eu beaucoup plus de mal à avoir un rendu correct sur LaTeX, notamment pour les caractères spéciaux et pour une mise en forme automatique.
Pourquoi attendre un test alors qu'on peut avoir l'information dès qu'on écrit la ligne de code ?
Personnellement, ajouter l'info de type m'a permis plus d'une fois de corriger un bug avant même de faire le moindre test.
Ça ne remplace pas la doc, les deux informations sont complémentaires (d'autant que la documentation fait apparaître le type, et permet d'avoir un lien vers le type attendu).
Après, le système de types a deux intérêts (à mes yeux) : le premier est pour le programmeur vu que ça l'aide à ne pas faire d'erreurs, le second est pour le compilateur qui permet de faire un code bien plus optimisé.
Le second n'est pas trop utile pour Python même si c'est toujours bon à prendre : la vitesse n'est de toute façon pas le premier critère de choix quand on fait du Python.
Le premier peut être mis en place différemment, et peut n'être utilisé que dans l'IDE. Quand je code en Java/Scala ou en Python, la vérification des types se fait de toute façon avant la compilation (et je m'en moque un peu qu'ils soient écrits dans des commentaires ou dans le code). Par contre, ça impose d'utiliser un IDE correct (et tout le monde n'aime pas ça).
Il parle de l'obligation de filtrer pour distinguer les cas licites des cas invalides, pas pour différencier les différents cas valides (enfin, c'est ce que j'ai compris). L'idée est que si le cas est invalide, bah tant pis, le développeur n'avait qu'à mieux lire la doc :)
Python n'a pas que le typage dynamique comme avantage ;-) (syntaxe concise, écosystème très vaste, …) Accessoirement, j'utilise toujours le typage dynamique, mais uniquement quand j'en ai réellement besoin.
Par expérience, je gagne du temps en codant quelques lignes de plus grâce à l'aide supplémentaire offerte par les informations de type.
Personnellement, j'utilise PyCharm, qui tente de faire de l'inférence de type, et je l'aide en rajoutant les commentaires comme conseillés par Guido.
J'essaie de typer toutes mes variables et fonctions, ça me permet d'avoir d'avoir des alertes dans le code à peu près comme en Java ou dans n'importe quel autre langage typé statiquement. Je utilise le moins possible le typage dynamique.
En pratique, ça ne marche pas bien.
J'ai une classe A définie dans un module a.py, et une classe B définie dans b.py.
Comment puis-je faire pour que A ait une méthode qui prenne un B en argument, et que B ait une méthode qui prenne un A en argument ?
(vu que ça nécessite que a.py import b.py, et que b.py importe a.py…)
De plus, c'est mal pratique pour définir des types un peu complexes (une liste avec différents types, un dictionnaire de dictionnaires de AxB, …)
Je ne vois pas trop ce que ça change : ça relancera peut-être le worker, mais il aura toujours des arguments incorrects donc ça ne fonctionnera pas plus (sauf que tu ne te rendras pas compte qu'il y a un bug, ce n'est pas vraiment sain comme méthode).
À ce propos : avec Linux, le chemin n'est qu'une suite d'octets. C'est à l'application de savoir quel est l'encodage utilisé, et tu peux tout à fait avoir dans le même dossier des fichiers avec différents encodages.
Avec OS X, le système de fichiers (ou le noyau ?) impose l'utilisation d'un encodage (et d'une normalisation Unicode) bien précis.
Je crois que Windows est comme Linux, mais s'attend à ce que ça soit de l'UTF-16 (sans normalisation précise).
Merci pour l'info, ça a l'air vraiment pas mal !
Je souffre à chaque fois que je dois faire du JS, et il y a des chances que je doive recoder une appli en Python + Qt (avec PySide) en JS…
Je me demande si je ne vais pas essayer avec Brython.
Ce qui te dérange, c'est surtout que des gens se sont mis ensemble et ont eu du succès.
C'est pratique, tu sais mieux que moi ce qui me dérange ou pas. Je me demande comment tu fais…
Au passage, non, ce sont les méthodes employées et les conditions de travail de leurs employés qui me dérange ; si les libraires s'unissent et qu'ils utilisent les mêmes méthodes, ça ne m'intéresse pas ; je pensais avoir été suffisamment clair en disant que les mauvaises conditions de travail me dérangent, mais manifestement non. Je ne comprends pas trop ce qu'il y a de compliqué là-dedans, pourtant.
Oui, en effet, j'ai mis UTF-8 au lieu d'Unicode, simplement parce que ça reste vrai : l'utilisateur tape un caractère « è », il est représenté dans le système de fichiers par de l'UTF-8 (ou de l'UTF-16/-32), même si la normalisation qui pose problème se fait au niveau de l'Unicode. Le conflit n'existe pas en Latin-1, parce qu'il n'y a qu'une seule façon de représenter le « è » (et qu'il n'y a pas d'histoire de normalisation NFKD/NFKC en amont).
De plus, tant qu'on parle d'Unicode, les deux versions (« è » et « e + ` ») doivent être comparées comme étant égales par le logiciel. Par contre, quand elles sont encodées (en UTF-8) et que ça devient des séries d'octets, les deux versions sont différentes (Linux ne considère que des séries d'octets, sans prendre en compte que c'est de l'Unicode) et à ce moment là, on a un souci (deux fichiers avec un nom identique).
Mais bon, c'est vrai que c'est totalement hors-sujet de parler UTF-8 au lieu d'Unicode, il n'y a strictement aucun lien entre les deux. Mea Culpa.
Personnellement, je connais des libraires, et leurs conditions de travail sont quand même bien meilleures que celles des employés de base d'Amazon (qui ne gagnent pas 100k$/an, mais bon, c'est tellement pertinent de se concentrer sur les quelques ingés en ignorant le reste des employés…).
C'est tout de même totalement idiot (ou de mauvaise foi, au choix) de dire qu'une boîte comme Amazon a les mêmes armes qu'un libraire classique :
* pas le même pouvoir de négociation avec les éditeurs (certains doivent vendre à perte à Amazon sous peine d'être exclus et donc de perdre toute visibilité),
* pas le même pouvoir de négociation avec les transporteurs (plus le volume est important, moins tu paies),
* pas le même pouvoir de négociation avec les États pour les impôts,
* pas le nombre d'avocats pour trouver la meilleure optimisation fiscale,
* pas le même pouvoir de négociation avec les États pour avoir des subventions quand ils s'installent quelque part,
* possibilité de pressurer les employés au maximum en les payant un minimum.
Plus il y aura de grosses boîtes comme Amazon, moins les conditions de travail (pour les employés de base) seront bonnes. Je ne pense pas que ça te dérange plus que ça, mais personnellement ça m'empêche de faire la moindre commande à Amazon ; je ne veux pas subventionner un système que je n'aime pas.
3/ les Américains n'étaient pas au courant de leur existence et ils les ont trouvées bien trop tard et par hasard vu que les preuves qu'ils ont présentées étaient bidon. Ce n'est pas la seule fois où ils ont données de fausses preuves : ils avaient déjà essayé de montrer sur des images satellites un mouvement de troupes irakiennes allant vers l'Arabie Saoudite (de mémoire), alors qu'elles allaient dans la direction opposée…
Ce n'est pas pour rien que la France a décidé en 1995 de se doter de satellites d'observation : c'est parce que les images américaines n'étaient pas fiables.
Ça ne m'étonne pas que Mercurial ait vu le souci : ils ont l'air de se poser beaucoup de questions sur le sujet, tout comme les problèmes de collisions avec les fichiers qui ont des noms UTF-8 : il faut savoir qu'en UTF-8, un même caractère peut être représenté de plusieurs façons (« è » peut être stocké comme un « è » ou comme un « e + ` »). Sur Linux, on aura donc plusieurs fichiers avec exactement le même nom (et de façon indiscernable pour l'application), alors que sur OS X le système de fichiers est normalisé (NFKD de mémoire) et il y aura un seul fichier (Windows est comme Linux, je crois).
# Quelques questions
Posté par flan (site web personnel) . En réponse à la dépêche Sortie de Modoboa 1.2.0. Évalué à 3.
J'ai noté Modoboa dans ma liste de projets à suivre, je pense que je m'en servirai quand je referai mon serveur perso (j'en profiterai pour m'occuper de mes mails). En attendant, j'ai quelques questions :
[^] # Re: Pour être plus clair
Posté par flan (site web personnel) . En réponse au journal Méfiez-vous des applications de courriel sur mobile. Évalué à 1.
C'est bien joli d'avoir les sources, mais qu'est-ce qui te garantit qu'elles sont exemptes de failles plus ou moins volontaires ?
[^] # Re: Métaphore du bureau
Posté par flan (site web personnel) . En réponse au journal Pourquoi on est bloqué, vers où on va peut-être pas. Évalué à 2.
Mais c'est déjà le cas, non ? Je pense que n'importe quel logiciel de bibliothèque musical permet de faire ça.
Et si on veut la même chose directement dans des dossiers, c'est relativement facile de faire ça en tout cas sur OS X : on peut créer des dossiers dits « intelligents » qui contiennent les éléments répondant à certains critères (j'ai ainsi un dossier qui contient les fichiers téléchargés durant les 10 derniers jours). Il suffit de coupler ça à l'événement « nouveau fichier » pour créer un dossier de recherche manquant (par exemple un dossier par décennie pour les films, quand je rajoute un film dans une décennie qui n'existait pas encore).
[^] # Re: Mme Michu
Posté par flan (site web personnel) . En réponse au journal Pourquoi on est bloqué, vers où on va peut-être pas. Évalué à 9.
Mme michud, qui seraient subdivisée en tout plein de personnalités interagissant entre elles ?
[^] # Re: Non
Posté par flan (site web personnel) . En réponse au journal I had a dream : des pingouins verts !. Évalué à 6.
Potentiellement, il s'agit d'acheter plusieurs ARM pour remplacer un seul Xeon.
Supposons que deux ARM consomment moins qu'un seul Xeon (et qu'ils soient aussi puissants, ce dont je doute) : ça pourrait être rentable d'un point de vue écolo de remplacer les Xeon, mais ça va dépendre du prix écologique de production des processeurs (et du recyclage des anciens).
De son point de vue, la meilleure solution est peut-être de sélectionner un hébergeur qui n'a que de vieux processeurs (qui ont été les mieux rentabilisés de ce point de vue).
[^] # Re: Non
Posté par flan (site web personnel) . En réponse au journal I had a dream : des pingouins verts !. Évalué à 4.
Autre chose qui serait intéressante à prendre en compte : le reste du cycle de vie du matériel (je ne suis pas sûr que l'électricité consommée, surtout nucléaire, soit la partie la plus polluante).
[^] # Re: Taille des clés RSA
Posté par flan (site web personnel) . En réponse au journal tor et la nsa. Évalué à 3.
Passer à du 4096 bits est en effet coûteux : pour s'en rendre compte, il suffit de faire le test avec un serveur web et quelques tailles de clefs jusqu'à 8192 bits. J'avais fait le test (avec des requêtes « vides »), et tu peux diviser par deux les performances (de mémoire, j'avais fait ce test rapide il y a deux ans).
C'est un test très empirique et critiquable, mais qui permet au moins de se rendre compte qu'utiliser des clefs de taille importante peut avoir un coût non négligeable.
[^] # Re: Et si on prenait ça comme un retour?
Posté par flan (site web personnel) . En réponse au journal Word vs TeX. Évalué à 2.
Tout à fait d'accord ! Et tu oublies le mélange TeX et LaTeX, au passage :D Ce n'est pas facile de distinguer les deux types de commandes. Il y a également le fait de devoir recompiler le texte à chaque modification, également.
Mais c'est vrai qu'il n'y a rien de mieux pour faire certaines choses…
[^] # Re: méthode
Posté par flan (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 4.
J'ai tendance à être comme toi, mais parfois faire du typage dynamique (voire générer des classes à la volée) est parfois bien pratique. Ça permet (parfois) de beaucoup simplifier le code. Personnellement (mais je ne prétends pas que ça soit LA méthode à suivre), j'essaie de faire comme si Python avait un typage statique fort (90% du temps, à la louche), mais je n'hésite pas à faire du duck-typing et autres joyeusetés quand ça aide vraiment à avoir un code plus concis et plus lisible.
[^] # Re: Pourquoi pas
Posté par flan (site web personnel) . En réponse au journal Word vs TeX. Évalué à 10.
Ça m'est pourtant souvent arrivé en LaTeX. Tu rajoutes une petite phrase (ou un mot), et ton document prend une page de plus… ou le contraire : tu rajoutes un mot, et ton article perd une page.
Tu compares du Word tapé par des personnes qui ne savent pas se servir de Word à du LaTeX tapé par quelqu'un qui sait se servir de LaTeX. La comparaison est subtilement biaisée, non ?
[^] # Re: Pourquoi pas
Posté par flan (site web personnel) . En réponse au journal Word vs TeX. Évalué à 7.
J'ai déjà généré via des scripts des documents pour Word : il suffit de générer du HTML, et Word saura parfaitement l'ouvrir et l'éditer (pour l'enregistrer dans du .docx).
D'ailleurs, j'ai eu à générer le même document pour Word (donc via HTML) et pour LaTeX : j'ai eu beaucoup plus de mal à avoir un rendu correct sur LaTeX, notamment pour les caractères spéciaux et pour une mise en forme automatique.
[^] # Re: méthode
Posté par flan (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 4.
Pourquoi attendre un test alors qu'on peut avoir l'information dès qu'on écrit la ligne de code ?
Personnellement, ajouter l'info de type m'a permis plus d'une fois de corriger un bug avant même de faire le moindre test.
Ça ne remplace pas la doc, les deux informations sont complémentaires (d'autant que la documentation fait apparaître le type, et permet d'avoir un lien vers le type attendu).
[^] # Re: méthode
Posté par flan (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 4.
Après, le système de types a deux intérêts (à mes yeux) : le premier est pour le programmeur vu que ça l'aide à ne pas faire d'erreurs, le second est pour le compilateur qui permet de faire un code bien plus optimisé.
Le second n'est pas trop utile pour Python même si c'est toujours bon à prendre : la vitesse n'est de toute façon pas le premier critère de choix quand on fait du Python.
Le premier peut être mis en place différemment, et peut n'être utilisé que dans l'IDE. Quand je code en Java/Scala ou en Python, la vérification des types se fait de toute façon avant la compilation (et je m'en moque un peu qu'ils soient écrits dans des commentaires ou dans le code). Par contre, ça impose d'utiliser un IDE correct (et tout le monde n'aime pas ça).
[^] # Re: Formulation...
Posté par flan (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 6.
Il parle de l'obligation de filtrer pour distinguer les cas licites des cas invalides, pas pour différencier les différents cas valides (enfin, c'est ce que j'ai compris). L'idée est que si le cas est invalide, bah tant pis, le développeur n'avait qu'à mieux lire la doc :)
[^] # Re: PyCharm + commentaires
Posté par flan (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 5.
Python n'a pas que le typage dynamique comme avantage ;-) (syntaxe concise, écosystème très vaste, …) Accessoirement, j'utilise toujours le typage dynamique, mais uniquement quand j'en ai réellement besoin.
Par expérience, je gagne du temps en codant quelques lignes de plus grâce à l'aide supplémentaire offerte par les informations de type.
# PyCharm + commentaires
Posté par flan (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 6.
Personnellement, j'utilise PyCharm, qui tente de faire de l'inférence de type, et je l'aide en rajoutant les commentaires comme conseillés par Guido.
J'essaie de typer toutes mes variables et fonctions, ça me permet d'avoir d'avoir des alertes dans le code à peu près comme en Java ou dans n'importe quel autre langage typé statiquement. Je utilise le moins possible le typage dynamique.
[^] # Re: Pour compléter...
Posté par flan (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 6.
Ça, c'est la théorie.
En pratique, ça ne marche pas bien.
J'ai une classe A définie dans un module a.py, et une classe B définie dans b.py.
Comment puis-je faire pour que A ait une méthode qui prenne un B en argument, et que B ait une méthode qui prenne un A en argument ?
(vu que ça nécessite que a.py import b.py, et que b.py importe a.py…)
De plus, c'est mal pratique pour définir des types un peu complexes (une liste avec différents types, un dictionnaire de dictionnaires de AxB, …)
[^] # Re: Bonne nouvelle
Posté par flan (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 10.
Je ne vois pas trop ce que ça change : ça relancera peut-être le worker, mais il aura toujours des arguments incorrects donc ça ne fonctionnera pas plus (sauf que tu ne te rendras pas compte qu'il y a un bug, ce n'est pas vraiment sain comme méthode).
[^] # Re: Linux power!
Posté par flan (site web personnel) . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 2.
À ce propos : avec Linux, le chemin n'est qu'une suite d'octets. C'est à l'application de savoir quel est l'encodage utilisé, et tu peux tout à fait avoir dans le même dossier des fichiers avec différents encodages.
Avec OS X, le système de fichiers (ou le noyau ?) impose l'utilisation d'un encodage (et d'une normalisation Unicode) bien précis.
Je crois que Windows est comme Linux, mais s'attend à ce que ça soit de l'UTF-16 (sans normalisation précise).
[^] # Re: Encore, encore !
Posté par flan (site web personnel) . En réponse au journal De l'autre côté. Évalué à 2.
Merci pour l'info, ça a l'air vraiment pas mal !
Je souffre à chaque fois que je dois faire du JS, et il y a des chances que je doive recoder une appli en Python + Qt (avec PySide) en JS…
Je me demande si je ne vais pas essayer avec Brython.
[^] # Re: Et dire qu'il suffirait de réfléchir avant...
Posté par flan (site web personnel) . En réponse au journal Google News quitte l'Espagne. Évalué à 3. Dernière modification le 20 décembre 2014 à 13:24.
C'est pratique, tu sais mieux que moi ce qui me dérange ou pas. Je me demande comment tu fais…
Au passage, non, ce sont les méthodes employées et les conditions de travail de leurs employés qui me dérange ; si les libraires s'unissent et qu'ils utilisent les mêmes méthodes, ça ne m'intéresse pas ; je pensais avoir été suffisamment clair en disant que les mauvaises conditions de travail me dérangent, mais manifestement non. Je ne comprends pas trop ce qu'il y a de compliqué là-dedans, pourtant.
[^] # Re: Pas que Git
Posté par flan (site web personnel) . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 9. Dernière modification le 20 décembre 2014 à 13:07.
Oui, en effet, j'ai mis UTF-8 au lieu d'Unicode, simplement parce que ça reste vrai : l'utilisateur tape un caractère « è », il est représenté dans le système de fichiers par de l'UTF-8 (ou de l'UTF-16/-32), même si la normalisation qui pose problème se fait au niveau de l'Unicode. Le conflit n'existe pas en Latin-1, parce qu'il n'y a qu'une seule façon de représenter le « è » (et qu'il n'y a pas d'histoire de normalisation NFKD/NFKC en amont).
De plus, tant qu'on parle d'Unicode, les deux versions (« è » et « e + ` ») doivent être comparées comme étant égales par le logiciel. Par contre, quand elles sont encodées (en UTF-8) et que ça devient des séries d'octets, les deux versions sont différentes (Linux ne considère que des séries d'octets, sans prendre en compte que c'est de l'Unicode) et à ce moment là, on a un souci (deux fichiers avec un nom identique).
Mais bon, c'est vrai que c'est totalement hors-sujet de parler UTF-8 au lieu d'Unicode, il n'y a strictement aucun lien entre les deux. Mea Culpa.
[^] # Re: Et dire qu'il suffirait de réfléchir avant...
Posté par flan (site web personnel) . En réponse au journal Google News quitte l'Espagne. Évalué à 5.
Personnellement, je connais des libraires, et leurs conditions de travail sont quand même bien meilleures que celles des employés de base d'Amazon (qui ne gagnent pas 100k$/an, mais bon, c'est tellement pertinent de se concentrer sur les quelques ingés en ignorant le reste des employés…).
C'est tout de même totalement idiot (ou de mauvaise foi, au choix) de dire qu'une boîte comme Amazon a les mêmes armes qu'un libraire classique :
* pas le même pouvoir de négociation avec les éditeurs (certains doivent vendre à perte à Amazon sous peine d'être exclus et donc de perdre toute visibilité),
* pas le même pouvoir de négociation avec les transporteurs (plus le volume est important, moins tu paies),
* pas le même pouvoir de négociation avec les États pour les impôts,
* pas le nombre d'avocats pour trouver la meilleure optimisation fiscale,
* pas le même pouvoir de négociation avec les États pour avoir des subventions quand ils s'installent quelque part,
* possibilité de pressurer les employés au maximum en les payant un minimum.
Plus il y aura de grosses boîtes comme Amazon, moins les conditions de travail (pour les employés de base) seront bonnes. Je ne pense pas que ça te dérange plus que ça, mais personnellement ça m'empêche de faire la moindre commande à Amazon ; je ne veux pas subventionner un système que je n'aime pas.
[^] # Re: Manque de preuves, mais les US s'en foutent
Posté par flan (site web personnel) . En réponse au journal Sony pictures et la Corée du Nord. Évalué à 10.
3/ les Américains n'étaient pas au courant de leur existence et ils les ont trouvées bien trop tard et par hasard vu que les preuves qu'ils ont présentées étaient bidon. Ce n'est pas la seule fois où ils ont données de fausses preuves : ils avaient déjà essayé de montrer sur des images satellites un mouvement de troupes irakiennes allant vers l'Arabie Saoudite (de mémoire), alors qu'elles allaient dans la direction opposée…
Ce n'est pas pour rien que la France a décidé en 1995 de se doter de satellites d'observation : c'est parce que les images américaines n'étaient pas fiables.
[^] # Re: Pas que Git
Posté par flan (site web personnel) . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 9.
Ça ne m'étonne pas que Mercurial ait vu le souci : ils ont l'air de se poser beaucoup de questions sur le sujet, tout comme les problèmes de collisions avec les fichiers qui ont des noms UTF-8 : il faut savoir qu'en UTF-8, un même caractère peut être représenté de plusieurs façons (« è » peut être stocké comme un « è » ou comme un « e + ` »). Sur Linux, on aura donc plusieurs fichiers avec exactement le même nom (et de façon indiscernable pour l'application), alors que sur OS X le système de fichiers est normalisé (NFKD de mémoire) et il y aura un seul fichier (Windows est comme Linux, je crois).