flan a écrit 1848 commentaires

Il en a tout à fait le droit, en tout cas.

ce n'est pas évident de faire ça en gardant un maximum de compatibilité.

Personnellement, je me sers pas mal de ces annotations (ou en spécifiant le type dans les docstrings), mon IDE est tout à fait capable de les utiliser pour de la vérification de type. Je limite l'utilisation du typage dynamique de Python aux seuls cas où ça permet de vraiment diminuer la quantité de code. Au final, j'ai très peu de bugs à l'exécution (autres que des vraies erreurs d'algo que j'aurais eues avec n'importe quel langage). Un langage typé statiquement ne m'apporterait pas grand-chose à ce niveau-là, mais c'est fortement lié à l'IDE ET à la documentation.

Mais ça revient à faire de la politique en s'attachant un bras dans le dos, en se privant gratuitement d'un moyen d'agir, qui est peut-être le plus important. Aucune grande politique étatique n'a été faite sans action particulière sur la monnaie pour pouvoir la financer.
Le système européen tombe dans le même travers, en voulant figer dans la Constitution la politique monétaire, alors que la politique monétaire doit par nature s'adapter aux circonstances (parfois en favorisant l'inflation, parfois en la limitant).

Ne me dis pas que tu as d'autres critères que la pile réseau quand tu choisis ton OS !

Un concept puissant qui ruine toute possibilité de construire une politique monétaire, et donc toute politique tout court ?

Je ne comprends toujours pas l'intérêt à ce que tout le monde fasse tous les calculs.

Ce n'est pas le fait qu'il y ait X personnes qui ont trouvé le même résultat qui te garantit la fiabilité de ce dernier, mais le fait que tu calcules toi-même pour vérifier.
Dans ce cas, pourquoi obliger les autres personnes à refaire aussi le calcul, alors qu'il ne les intéresse potentiellement pas ? Si tu es obligé de faire le calcul pour être sûr du résultat, le fait que les autres l'ait également fait (donc ethereum) ne t'apporte rien.

Accessoirement, les nouveaux venus n'auront pas faits tous les calculs de l'historique, donc le fait que tous les calculs auront été faits par 100 000 personnes ou par 5 personnes ne change strictement rien pour eux. Donc autant les faire faire par une seule personne. À nouveau, ethereum n'apporte rien.

Racontons-nous une petite histoire, avec d'un côté ethereum, de l'autre boinc.
À t0 = 0 jour, il y a 10 personnes sur ethereum, qui font un calcul A,
À t1 = 10 jours, il y a 100 personnes sur ethereum, qui font un calcul B,
À t2 = 20 jours, toto rejoint la Communauté et il y a 10 001 personnes sur ethereum pour faire le calcul C.

De l'autre côté, il y a 101 personnes sur boinc de t0 à t2, date à laquelle toto rejoint la communauté boinc.
Ils ont également fait les calculs A', B', et C' aux mêmes moments.

Si je comprends bien la théorie d'ethereum, toto doit considérer que les résultats de A et B sont plus fiables que ceux de A' et B' (alors qu'il y a moins de gens à les avoir calculés ! ), et pour C se moque du nombre de personnes dans la communauté vu que de toute façon il a fait lui-même le calcul.
Franchement, je ne comprends pas.

Le message d'origine parle de la masse totale du drone, pas de son armement ;)

Parce que bon un drone ça peut aussi faire 250kg et avoir une turbine, et pas une lipo et 4 pauv' hélices.

Je ne vois toujours pas ce qu'apporte le fait que tout le monde fasse le même calcul.

À partir de combien de personnes différentes estimes-tu que le calcul est fiable ? 10 000 ? Dans ce cas, si Ethereum ne sert à rien s'il n'y a que 9 999 personnes connectées, et consomme tout à fait inutilement des ressources s'il y a 10 001 personnes connectées par rapport à du BOINC classique.

Là, même si on a 100 000 machines, on n'a pas plus de puissance de calcul qu'avec la plus faible de toutes. J'ai franchement l'impression que c'est tout simplement la pire des méthodes pour résoudre le problème de confiance, ce qui explique au passage l'originalité de la solution ^{^}

1. Je trouve un peu cavalier d'affirmer que tous les passionnés d'informatique sont intéressés par le Bitcoin.
2. Je ne vois absolument pas comment le Bitcoin ou l'Ethereum permet de faire une monnaie viable pour un État, sachant que ça manque par essence beaucoup d'avantages indispensables à une monnaie (ne serait-ce que le manque de contrôle et donc l'impossibilité d'avoir une politique, le fonctionnement intrinsèquement pyramidal qui favorise les premiers arrivés, etc.)

Quel est l'intérêt ? Faire le même calcul plusieurs fois pour avoir quelques garanties sur le résultat, pourquoi pas, mais pourquoi faire exactement le même calcul un nombre arbitraire de fois, sans que ça n'apporte davantage de garanties sur le résultat ?

Tu peux monter à 10 tonnes sans problème, avec 35 m d'envergure.

Vous êtes méchants avec le JS, ils viennent quand même de découvrir que faire des tests unitaires (et de l'intégration continue en générale) était intéressant, et qu'avoir un système de packaging n'était pas forcément une mauvaise idée (du coup, on a un système de packaging par lib).

• tu peux relancer le service via l'interface web (ou socket), donc sans être root
• ne pas avoir à écrire un fichier de conf en bash illisible (si tu n'as pas systemd)
• être indépendant du système d'init

systemd supprime en bonne partie les deux derniers arguments. Perso, je faisais du supervisor, et je passe à systemd.

Malheureusement, je ne comprends pas trop pourquoi :(

du coup, j'hésite à abandonner le Kerberos pour les mails ; je suis surpris de la pauvreté de documentation et de la complexité pour faire un pauvre smtp kerberisé (alors que faire un apache kerberisé est super simple ! ).
Une autre raison pour l'abandon est que mon iPhone va devoir utiliser les différents outils (mails, entre autres), et qu'il n'y a pas de kerberos via certificat sur iPhone :(

C'est dans le message d'origine ^{^} (deux lignes qui disent qu'il y a une erreur GSSAPI, mais pas au point de dire laquelle, ça serait beaucoup trop facile)

si, justement : voilà ce que je fais sur le client uniquement :

kdestroy
kinit flan@test.example.org
klist
Credentials cache: API:2BC7250E-875F-4F48-ABA1-535CFFEAF42F
Principal: flan@TEST.EXAMPLE.ORG
Issued Expires Principal
Sep 2 23:18:37 2015 Sep 3 09:18:44 2015 krbtgt/TEST.EXAMPLE.ORG@TEST.EXAMPLE.ORG
ssh flan@firstcomp.test.example.org echo "COUCOU"
COUCOU
klist
Credentials cache: API:2BC7250E-875F-4F48-ABA1-535CFFEAF42F
Principal: flan@TEST.EXAMPLE.ORG
Issued Expires Principal
Sep 2 23:18:37 2015 Sep 3 09:18:44 2015 krbtgt/TEST.EXAMPLE.ORG@TEST.EXAMPLE.ORG
Sep 2 23:18:39 2015 Sep 3 09:18:44 2015 host/firstcomp.test.example.org@TEST.EXAMPLE.ORG
[lancer thunderbird && essayer d'envoyer un email]
klist
Credentials cache: API:2BC7250E-875F-4F48-ABA1-535CFFEAF42F
Principal: flan@TEST.EXAMPLE.ORG
Issued Expires Principal
Sep 2 23:18:37 2015 Sep 3 09:18:44 2015 krbtgt/TEST.EXAMPLE.ORG@TEST.EXAMPLE.ORG
Sep 2 23:18:39 2015 Sep 3 09:18:44 2015 host/firstcomp.test.example.org@TEST.EXAMPLE.ORG
Sep 2 23:19:55 2015 Sep 3 09:18:44 2015 smtp/firstcomp.test.example.org@TEST.EXAMPLE.ORG

bah non, mais ça ne change rien, d'ailleurs l'échange kerberos se fait bien vu que j'obtiens un TGS pour smtp/firstcomp.test.example.org, que je n'avais pas avant d'avoir utilisé Thunderbird.

Le serveur est dans une VM sur la machine cliente.

Le client fait un kinit (en ligne de commande actuellement) pour obtenir un ticket Kerberos, et peut faire un SSH (authentifié par kerberos) sur le serveur : la config Kerberos (tant cliente que serveur) semble donc bonne à ce niveau.
le dig (et dig -x) fonctionne aussi bien sur le client que sur le serveur.

Si je ne me trompe pas, si une machine est HS, le client piochera au hasard une des 9 autres. Il suffit de ne rien faire pour que ça fonctionne comme tu le veux.

Faire deux ensembles de hostnames (les hostnames valides et ceux qui ont raté leur épreuve du ping), qui seront mis à jour dans chaque thread.
Il y a des structures adaptées pour ça (pour éviter les conflits).

Ensuite, quand tous les thread ont fini, tu fais "UPDATE ping SET dateping=%s,state='1',ispingok='1',compteur=compteur+1 WHERE (netbiosname=%s) or (netbiosname=%s) or …" avec tous les hostnames qui ont réussi, puis une seconde requête avec tous ceux qui ont raté. S'il y a trop de hostnames, tu peux découper pour faire du traitement par lots de 1000 hostnames.

Tu peux également faire plus de 5 threads (100 restent raisonnables).

Autant ça peut se comprendre pour Scala (je veux dire que ce n'est pas gravissime si un compilo est un peu lent, et je comprends que ça soit complexe), mais faire un OOM en créant un zip de 10 Mo ou mettre deux minutes à se lancer pour un truc relativement simple (et qui n'apporte rien par rapport aux autres outils) est franchement incompréhensible :/

J'ai l'impression que ça complique quand même pas mal le cycle de vie pour avoir quelque chose à jour. Il faut reconstruire le conteneur, puis l'envoyer sur le miroir, puis le redéployer partout. Ça fait également un miroir supplémentaire à mettre en place.

Je n'ai jamais utilisé Docker, c'est peut-être pour ça que je suis aussi sceptique, mais je n'ai pas l'impression qu'on y gagne beaucoup par rapport à des technos comme Puppet (sauf quand on a un environnement de prod super hétérogène et qu'on ne maîtrise pas totalement).

Mais avec cette logique, on se retrouve avec des outils magiques comme SBT (le Maven de Scala) : sur ma petite machine, pas loin de deux minutes pour lancer SBT pour quelque secondes de compilation (bah oui, mon fichier de conf' fait 10 lignes, ça prend du temps à parser) et j'ai régulièrement des OOM (Out of Memory Error) quand je veux créer un .jar de classes déjà compilées (donc en gros, faire un fichier zip de 10 Mo) malgré mes 4 Go de RAM.

Merci pour l'info, je ne connaissais pas.

En tout cas, super boulot, merci !

Et oui, à chaque fois que je lis la doc ou une dépêche à son sujet, je vois qu'il y a des milliards de trucs fantastiques fournis par iPython, mais je n'en ai jamais le besoin et je n'utilise que la console « classique » iPython (qui est nickel pour moi, au passage).