flan a écrit 1865 commentaires

Si je ne m'abuse, tu auras toujours un problème avec Python 3.3, vu que le « yield from X » est une nouveauté de Python 3.4.

J'ai un peu regardé la doc (l'idée me paraît intéressante), et j'ai quelques remarques :

• au niveau de l'installation, pourquoi passer par le .tar.gz directement ? uploader un package sur pypi est super facile et simplifie beaucoup la vie
• je pense que la méthode choisie mériterait d'être rapidement expliquée dans l'intro, ce n'est pas très clair :D

http://www.easy2boot.com

Le site web fleure bon les années 90, mais ça marche super bien :)

Pas besoin de ça, il y a des clefs USB qui permettent de simplement copier des .iso dans le bon dossier, et d'avoir un menu de boot qui détecte automatiquement tous les .iso présents.

Tu proposes tout de même de faire payer quelque chose de gratuit pour donner de l'argent à des gens qui n'en demandent pas (s'ils choisissent explicitement de le distribuer gratuitement, c'est parce qu'ils ne tiennent pas spécialement à être payés… ou alors quelque chose m'échappe).

Je trouve ça quand même dur à justifier.

Ah si, j'avais oublié : c'est indolore. Trouves-tu sincèrement qu'on n'a pas assez d'impôts et de taxes en tout genre ?

Je pense que la moitié de ces taxes devraient aller vers le logiciel libre et les données libres.

pourquoi donc ? je préférerais largement diminuer de moitié ces taxes…

Figure-toi qu'avec Jenkins ou TeamCity, tu peux tout à fait lancer n'importe quel script en ligne de commande.

Travis-CI te permet de prendre un fichier de conf' simple et de lancer les scripts bien plus facilement, avec des configurations toutes faites pour les principaux langages.
Voilà un exemple pour du Python :

language: python
python:
- "2.6"
- "2.7"
- "3.2"
- "3.3"
- "3.4"
# command to install dependencies
install: "pip install -r requirements.txt"
# command to run tests
script: nosetests

Ça lance les scripts dans 5 versions différentes de Python, ça installe les dépendances et ça lance le test.
Oui, on pourrait faire un script, mais ça prendrait plus de temps (surtout à débugguer, parce que ton script va planter lors du pip install à cause de variables d'environnement mal mises, par exemple).

Je trouve Gitlab vraiment bien fichu, mais en revanche Gitlab-CI est assez limité, je trouve. On peut lancer un script, et c'est à peu près tout. On est assez loin de Travis-CI en terme de simplicité (ou alors ça aa bien changé depuis la dernière fois que j'ai regardé).

Mais heureusement, tu as Scala ! Comme ça, tu dois vérifier que tu as les paquets pour la bonne version de Scala ET pour la bonne version de Java ! :)

Ton livre parle d'algo de chiffrement (et un chiffrement faible est cassé avec des méthodes totalement différentes de la recherche de failles classiques). Le journal parle de l'intégralité du code (et oui, les failles peuvent se trouver partout), et de codes extrêmement spécialisés (industrie de défense).

En pratique, on constate que
* un code open-source utilisé par beaucoup de monde peut contenir des failles graves et très vieilles (heartbleed, shellshock, debian+ssh, …), donc soit il n'y a pas de relecture, soit elle est inutile,
* les failles sont dans leur très grande majorité trouvées sans utiliser le code source.

Maintenant, prenons un code utilisé dans une centrale nucléaire ou un avion de combat.
Qui ira relire bénévolement des milliers de lignes de code qu'il ne pourra pas réutiliser, à part les services de renseignement étrangers ?
Pourquoi cette relecture serait-elle magiquement plus efficacement que sur les codes classiques ?

Réponse donnée par Scoubidou : des gens qu'on paierait pour relire le code… bon, bah pour ça, il n'y a pas besoin de donner le code aux services étrangers, et de toute façon c'est probablement déjà fait (ça s'appelle des audits et c'est très classique).
Dans beaucoup de cas, dévoiler le code revient à dévoiler nos capacités, sans même parler des failles potentielles que les services étrangers garderaient pour eux…

Je vois bien ce qu'on peut y perdre, mais je ne vois pas trop ce qu'on y gagne.

Mais il n'y aucune notion de préférence ou de morale dans les arguments exposés, simplement des faits concrets.

Si tu as des arguments montrant qu'un code aussi spécialisé serait plus sûr en étant libre, donne-les.

Source ? Ça arrive tout le temps à MS de trouver des failles et de les corriger. Pourquoi pas celles-ci ?

Depuis quand signe-t-on une clef privée ?

Une clef privée sert à signer la demande de certificat puis le certificat lui-même (enfin, ce n'est pas la même clef privée utilisée, évidemment), mais jamais la clef elle-même n'est signée.

Euh, non. Il n'y a qu'en celui qui a généré la clef et l'a mise sur la carte-à-puce qu'il doit faire confiance (et qui de toute façon, peut tout signer, donc on s'en moque un peu qu'il ait accès à la clef privée). Le nombre d'intermédiaires qui ont accès à la carte n'a aucune importance.
C'est un peu le principe d'une carte-à-puce : une fois que la clef privée est injectée dedans, tu ne peux pas l'en retirer (si la carte-à-puce est de bonne qualité).

Et heureusement que la clef privée n'est pas générée par le citoyen directement, ça serait le meilleur moyen d'avoir de mauvaises clefs (presque personne ne sait correctement générer une clef et faire en sorte qu'il n'en reste aucune trace). Si c'est pour avoir une clef de 512 bits qui est en plus stockée sur une clef USB abandonnée, ce n'est pas la peine de se casser la tête :D

On parle de pilote automatique avec des temps de réaction très faible par rapport à un événement imprévu => on sait faire depuis un certain nombre d'années (on se moque un peu du cadre d'emploi).

et pas la peine d'être désagréable comme ça…

Qui a parlé d'avions de ligne ?

Ça dépend de l'avion : un pilote auto peut également être utilisé à 1 000 km/h à moins de cents mètres du sol, et là l'ordinateur n'a vraiment pas beaucoup de temps pour réagir en cas de perturbation violente comme un gros trou d'air.

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 :(

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 ?

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).

Mme michud, qui seraient subdivisée en tout plein de personnalités interagissant entre elles ?

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…