flan a écrit 1865 commentaires

Je ne recommandes pas du conservatisme pour Python, je trouve simplement qu'on se retrouve avec deux classes qui font doublon, ou alors j'ai raté quelque chose sur la différence entre dict et OrderedDict.

Et je ne recommande pas non plus du conservatisme pour les outils de packaging, je pense au contraire qu'il aurait fallu finir la transition (actuellement, on a un mélange de pip et de setuptools largement incompréhensible quand on n'est pas connaisseur des subtilités de Python) pour n'avoir qu'un seul outil de gestion de package.
Accessoirement, rajouter twine rajoute un nouvel outil à installer et à découvrir. Il aurait peut-être été plus intéressant de l'intégrer dans pip, ou simplement moderniser setuptools.

Personnellement, j'ai eu des soucis avec pip et des Ubuntu 16.04, avec une méthode super propre qui consiste à faire du curl … | bash (pénible à faire quand tu es dans un réseau sans accès direct à internet et que rajouter un package en dehors des quelques technos de miroir maîtrisées est coûteux).

Je trouve qu'officialiser l'ordre conservé dans les dict est une mauvaise idée, alors qu'on a les OrderedDict pour ça.

Je sais que c'était à la base un peu par hasard (l'implémentation des OrderedDict s'est trouvée être plus efficace que l'implémentation des dict et donc a été reprise telle quelle pour les dict), mais que se passera-t-il quand on trouvera une implémentation encore plus efficace mais qui ne respecte pas l'ordre ? Fera-t-on des dict, des OrderedDict et des UnorderedDict ?

Sinon, il y a eu quelques autres petits changements dans l'écosystème : les vieilles versions de pip sont cassées (algos TLS qui ne sont plus acceptés, si je ne me trompe pas), et python setup.py sdist upload va disparaître.

Du coup, parfois un pip install pip --upgrade ne passe plus alors qu'un python3 -m pip install passe…

Je trouve franchement dommage d'introduire de nouvelles incompatibilités dans un écosystème déjà compliqué. Il aurait été bien plus utile de dégager setuptools/easy_install qui n'utilise pas la même configuration que pip. Par exemple, quand j'installe A qui dépend de B avec pip install A, B sera probablement installé via setuptools et non pip.
On ne voit pas la différence, sauf quand on utilise uniquement un miroir privé. Parfois l'installation fonctionnera, parfois non…

L'option choisie par l'équipe est clairement d'introduire les incompatibilités peu à peu, sûrement par peur de recommencer l'épopée Python 3, qui a mis plus de 10 ans à être réellement adopté à cause d'un trop grand nombre d'incompatibilités.

Même si ce sont des threads distincts, j'imagine que ça lance le calcul sur le fichier complet fraîchement enregistré sur disque à chaque modification. Ça doit se ressentir sur des fichiers un peu longs.

Ou comme si c'était simplement lourd et pénible.

C'est peut-être de la simple optimisation tout à fait objective.

Tu as un montant X (en euros) à dépenser, et un paquet d'étudiants E.

Tu as une fonction f(x, e), qui correspond au niveau de l'étudiant à la fin de ses études, en fonction de son niveau évalué à l'entrée et de la somme investie pour lui.

Bien sûr, tu n'auras jamais de valeur précise ou fiable, mais globalement on peut espérer que f sera croissante en x et e (plus t'investis, ou meilleur est l'étudiant au départ, meilleur il sera à la fin — ça semble raisonnable).

Ensuite, il faut déterminer ce qu'on veut optimiser (ce qui n'est malheureusement jamais dit dans les programmes politiques, alors que c'est le plus important) :
- le niveau moyen ou médian ?
- le niveau des 5% meilleurs ?
- le niveau des 95% meilleurs (en gros on aide presque tout le monde mais on abandonne les cas désespérés) ?
- le niveau des moins bons ?

Dans ce qui suit, les chiffres sont donnés au pifomètre, bien sûr.
Si on consacre 5% de son budget pour 1% des élèves (c'est un peu le principe des ENS), ça permet de doubler leur niveau en sortie et ils pourront servir de « locomotive intellectuelle » (pour doper l'innovation, la recherche, former des disciples, …).
Si on fait ce que tu proposes (répartition parfaitement égale entre les étudiants), on va avoir un gain négligeable (5,2%) pour 99% des élèves et une énorme perte (80%) pour le 1% qui devait tirer tout le monde vers le haut. Je ne suis pas sûr que la société en sorte gagnante…

En tout cas, dire que la société irait mieux en donnant la même chose à tout le monde est loin d'être évident, surtout sans aucune donnée un peu chiffrée.

Pour moi, il est très utile d'avoir une adresse différente par service (qui redirigent toutes vers deux ou trois adresses).
Cela permet d'isoler définitivement (rediriger vers la corbeille) une adresse qui est compromise (une fuite de données, par exemple).
De plus, si ton adresse @linuxfr est compromise avec son mot de passe, cela évite que ton compte @linuxorg soit attaqué (même si bien sûr ton mot de passe n'a rien à voir).

Partant de là, le catch-all est utile car tu n'auras peut-être pas la possibilité de créer l'alias au moment de créer un nouveau compte (par exemple si tu es en magasin, ou si tu n'as pas ton keepass avec toi).

En effet, j'ai lu un peu vite ; en cas d'hébergement on fait ce qu'on veut. Il faut accepter les contraintes et risques liés, mais j'imagine que c'est pris en compte.

Le catchall est de moins en moins accepté par les hébergeurs. Gandi et OVH y ont renoncé, par exemple.

Et ce que je reproche c'est que c'est les mêmes qui vont reprocher de payer trop d'impôt, qu'on donne trop d'APL etc. (pour info le président a fait l'une de ces trois écoles)

Bin pour le coup, je me sens un peu concerné, et je trouve un peu facile de dire que ce sont les mêmes qui reprochent de payer trop d'impôts.
J'en connais pas mal qui sont dans le même cas, et je n'ai pas souvenir d'avoir réellement entendu ce discours.
Certes, tu dois certainement trouver du monde qui tient ce discours… mais à nouveau, ta généralisation me semble franchement trop rapide. A priori, quelque soit le discours, tu trouveras du monde qui le tient.

Accessoirement, on peut aussi considérer que l'impôt est mal employé.

Avec Qt tu peux faire une application sur les plateformes que tu cites. Pas sûr que cela demande plus de travail qu'une version full web.

Mais dans ce cas, il ne faut pas être très exigeant sur la qualité de l'intégration à l'OS. Sur macOS, on reconnaît tout de suite les quelques applis codées en Qt…

Dans le cadre d'une formation de développeur, je trouve qu'un des meilleurs langages pour débuter est l'assembleur sur une petite plate-forme (comme les TI-89/92). Il y a la plupart des composants d'un ordi moderne sans avoir une complexité inutile pour la compréhension. C'est assez facile de faire des choses simples (long, peut-être, mais pas très compliqué). Au moins, on est sûr de comprendre qu'il n'y a rien de magique dans un ordinateur.
Le passage au C se fait assez facilement et permet de bien saisir le travail d'un compilateur.

À côté de ça, il est certainement nécessaire d'avoir un langage plus algorithmique, de plus haut niveau.

Bien sûr, ça prend sûrement plus de temps que de commencer avec un langage de plus haut niveau mais à mon avis les bases seraient parfois mieux comprises.

Avoir un « tampon ANSSI » veut tout et rien dire. Il y a différents niveaux d'évaluation, avec des critères très différents (et une implication de l'ANSSI très différente dans le processus).

On peut imaginer sans trop de risque que l'ANSSI va regarder de (beaucoup) plus près un produit qui va être qualifié apte à traiter du Secret Défense qu'un produit pour du grand public (même pas Diffusion Restreinte).

Il me semble compliqué d'exiger des entreprises qu'elles identifient les sites des banques des employés (pour ne parler que de ça).

À mon avis, elle n'a pas le droit de mettre ça en place sans prévenir les employés, mais à partir du moment où ils sont au courant (par exemple en donnant à lire une charte informatique), je ne pense pas qu'il y ait de problème légal.

C'est bien de dire que les certifications sont pour les pigeons, mais quand tu dois choisir une solution en souhaitant quelque chose de sécurisé, comment fais-tu ton choix ?
Prends-tu la première solution libre venue en partant du principe que c'est donc forcément sécurisé ?
Examines-tu le code source de toutes les solutions envisagées (ce qui demande une certaine expertise et beaucoup de temps) ?
Te bases-tu sur l'avis du premier geek venu qui te dit que « sisi c'est sécurisé je l'ai lu sur internet » ?

En fait, le problème se pose surtout quand il y a des problèmes et que tu as des comptes à rendre sur le niveau de sécurité. Dire « j'ai suivi les recommandations de l'ANSSI » passera peut-être mieux que « je ne comprends pas ce qui s'est passé, c'est pourtant un produit libre ! ».

Presque aussi vieux, mais très intéressant également : https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Pourquoi dis-tu que tu souhaites « un outil qui chiffre réellement le contenu » ?
Des outils comme Libre Office chiffrent réellement le contenu ; a priori c'est de l'AES-256 pour les versions un peu modernes d'Office ou de Libre Office, par exemple.

la médecine par les plantes est le meilleur moyen de se tuer (soit par manque de soins, soit par surdosage).

Bof, ça dépend comment c'est utilisé. Bien sûr, cela peut être mortel (coucou la ciguë), mais cela peut être pris pour ce que c'est fréquemment : plus ou moins la même molécule que dans des médicaments plus « sérieux », mais à des doses inférieures et qui peuvent être suffisantes, quitte à ce que ça agisse plus lentement. La plupart des maladies qu'on choppe dans la vie guérissent toutes seules de toute façon, si on peut éviter de prendre des médicaments qui coûtent cher à la sécu (plus que des plantes s'entend) et qui auront potentiellement plus d'effets secondaires (car plus concentrés), autant le faire. Mais bien sûr, d'une part il est illusoire de remplacer une chimio par une infusion de thym, pour prendre des extrêmes, et d'autre part je parle de plantes avec des principes actifs, pas du laboratoire Boiron.

Le cannabis thérapeutique, ça existe et ça commence à être reconnu, mais tant que l'ambiguïté sera cultivée de cette manière, ça va être dur de le considérer comme un médicament…

Suffit de le conditionner sous forme de médicament classique et de ne pas dire ce qu'il y a dedans en lui donnant un nom barbare :)

Ça ne change rien au fond du sujet, bien sûr, mais les OS d'Apple (macOS, iOS, etc.) n'utilisent pas un noyau BSD mais un noyau XNU (en revanche, une bonne partie de ce qui gravite autour du noyau a été pris chez BSD).

Si, ça peut être gênant si tu veux éditer la configuration de façon automatique par un programme externe (par exemple un gestionnaire de conf' qui veut uniquement modifier une seule valeur, sans toucher au reste de la configuration).

Je trouve que le .ini est le plus simple et le plus lisible et le plus intuitif, mais il ne permet pas (de base) les types complexes (listes ou dictionnaires clefs-valeurs) contrairement au JSON ou au Yaml, et n'est pas typé.

Si je ne me trompe pas, Active Directory n'est pas une pré-config LDAP pour Windows. Il s'agirait plutôt d'une présentation des données internes sous la forme d'un annuaire LDAP.

J'aime bien l'idée d'Apple pour les fichiers de configuration (les .plist). Il s'agit un seul format logique qui

• correspond globalement à une table clefs-valeurs (sachant qu'une valeur peut elle-même être une table clef-valeur),
• est utilisé par tous les outils Apple (fantastique : ça évite d'écrire un parseur par application à configurer ! ),
• possède plusieurs représentations en tant que fichier (binaire, XML voire JSON) — mais en vrai, on s'en fout un peu —,
• peut être édité par pas mal d'outils (y compris vim avec un plugin, mais ça donne un fichier XML),
• peut être lu ou écrit partiellement en ligne de commande (on peut modifier la valeur d'une seule clef ou en exporter quelques unes),
• a des bibliothèques utilisables dans pas mal de langages (dans la bibliothèque standard de Python, par exemple).

Il manque la possibilité d'ajouter des commentaires, malheureusement.

Au final, je trouve que JSON, XML ou autre, ça ne change pas grand-chose au final. Au pire, il suffit d'un plugin dans l'éditeur pour le transformer en quelque chose d'utilisable par un être humain le temps de l'édition.

Il manque Simple Build Tool dans ce panorama, qui a été renommé en Scala Build Tool. Bon, ok, ce n'est pas forcément une mauvaise idée de l'oublier, après tout.
J'ai eu le malheur d'utiliser SBT il y a quelques années. Bon, il fallait 2 min montre en main pour le lancer (je parle bien du temps de chargement de SBT avec un fichier .sbt de 20 ou 30 lignes, hein, pas de l'exécution elle-même), certes sur une machine de 2010.
Il réussissait aussi à mourir par manque de RAM (seulement 4 Go de dispo, j'avoue) lors du packaging d'un projet de 10 Mo (concrètement, il s'agit juste de copier quelques fichiers dans un zip, rien de plus).
Bien sûr, il avait aussi besoin de télécharger internet à chaque build (même s'il l'avait téléchargé 5 min avant). Pas pratique quand on n'a pas internet (ce qui est souvent mon cas)…

Ah, et comme les développeurs se sont dit que les classiques points-virgules pour séparer les instructions coûtaient vraiment cher, ils se sont dit qu'il valait mieux les remplacer par une ligne vide, histoire de doubler l'espace vertical occupé à l'écran.

Spark donne (donnait ?) un bon exemple de gestion de versions avec sbt : un fichier .sbt était fourni pour Scala 2.10 mais permettait également de compiler en 2.11, en cherchant d'abord tous les fichiers pom.xml dans le projet pour y appliquer un sed s/2.10/2.11/g (méthode fiable et propre s'il en est).

Applications et pilotes de Windows… XP, qui va fêter ses 17 ans, si je ne me trompe pas.
Malheureusement, à ma connaissance (limitée du monde Windows), Vista a amené en 2006 beaucoup de changements pour les applications et des pilotes (en étant beaucoup notamment plus strict).