flan a écrit 1865 commentaires

J'ai un peu regardé le projet, et j'ai l'impression que le seul transport est via SSH. Est-ce correct ?

Pourquoi ce choix ? Je trouverais dommage d'abandonner HTTP (ou websocket si on veut un mode connecté).

• HTTP permet plein de choses en matière de proxy ou d'authentification
• j'aime bien que SSH ne serve qu'à l'administration (donc ouvert uniquement à un sous-réseau dédié), en ouvrant un serveur HTTP (qui tourne avec un simple utilisateur) pour les services.

Enfin, peut-être que je me trompe complètement :)

Qui sont les experts militaires qui étaient contre ?

J'avais vu que le nombre de morts avait globalement diminué dans les mêmes proportions dans tous les pays, ce qui aurait tendance à éliminer les facteurs géographiques comme l'alcool, les contrôles ou les limitations diverses et variées, renforçant l'argument de l'amélioration des voitures. Mais bon, je n'ai plus la source (c'était il y a 5 ou 10 ans…)

Alors je veux bien croire que dans ce contexte, un casque de vélo ne fait pas trop le poids face à un 4x4 de 1.5 tonnes lance a 70. Ça veut pas dire que le casque ne te servira pas dans un contexte un peu moins vélo-hostile.

Bien sûr qu'on trouvera toujours des cas où le casque sera utile. Maintenant, rendre le casque obligatoire est une certaine dépense d'énergie, énergie dont l'utilité doit être optimisée au maximum.
Il faut donc se demander si :

• le nombre de vies sauvées (morts ou accidents graves) est important (si la plupart des accidents ont lieu contre un 4x4, comme tu dis, l'intérêt du casque est négligeable),
• d'autres mesures plus efficaces ne pourraient pas être mises en œuvre à la place (pour consommer différemment cette énergie),
• s'il est pertinent de n'appliquer le casque qu'aux cyclistes (après tout, les traumas crâniens existent également chez les automobilistes et les piétons).

Que ce sont des revenus générés par des iPhone mais pas par Apple ?

En effet, il y a un mot-clef important : numpy, qui est une bibliothèque de calcul scientifique pour Python, mais qui sous le capot utilise du C.

Du coup, quand on utilise numpy au mieux de ses capacités, le code Python ne sert que de ciment à des appels de code C ; tout le boulot est fait par du C optimisé.

Merci pour le message !

Fait : Les SSD sont infiniment moins gênées par des données non-séquentielles, car ils ne sont pas des disques durs. Ce qui rend la défragmentation inutile.

Ton implication est fausse. La défragmentation est donc moins utile. Tout est de savoir dans quelle mesure !

Fait : Le support de stockage utilisé par les SSD ont un nombre limité d'écritures avant d'être kapout. Ce qui rend la défragmentation dangereuse.

Ton implication est encore fausse : pour ça, il faudrait savoir de combien elle réduit la durée de vie du SSD. Si c'est de 0,001%, on peut la considérer comme indolore.

Fait : Un contrôleur SSD essaie de gérer la durée de vie ses blocs de manière uniforme. Pour éviter que certains deviennent kapout alors que d'autres étaient "comme neufs". Donc évidemment, les données vont être fragmentées.

Ton implication est encore fausse. La fragmentation du SSD n'a pas lieu au même niveau.

De la même façon que beaucoup d'ouvriers ont perdu leur travail avec l'apparition des moissonneuses batteuses

Sur quoi te bases-tu pour dire qu'ils l'ont toujours fait, surtout vis-à-vis de PDG de boîtes aussi énormes ?

Il y a une subtilité : un Byte est la plus petite unité adressable, alors qu'un octet est un groupe de 8 bits. En l'occurrence, ce sont des bytes de 10 bits.

C'est exactement ce que je dis (« soit récupérer un certificat valide »), ce qui peut être compliqué si tu restreints la liste des AC acceptées ;)

À nouveau, tout comme Groumly, je n'ai jamais prétendu que le HTTPS était suffisant en soi ; simplement que ça apporte de la sécurité supplémentaire et qu'à ce titre, c'est une mauvaise idée de s'en passer.

Si, au moins partiellement : si tu as une faille dans la signature GPG (ce qui était justement le cas, cf. le lien supra), il suffit de faire du MITM pour infecter l'ordinateur. Avec du HTTPS, ce n'est plus possible : il faut soit casser le HTTPS, soit récupérer un certificat valide, soit trouer le serveur.

D'où l'idée de multiplier les couches de sécurité : une seule faille dans l'un des composants n'est pas suffisante, il faut une faille dans chaque composant de sécurité simultanément. D'où le principe de défense en profondeur, avec plusieurs lignes de défense concentriques.

Et s'il y a une faille dans la vérification de la signature ?
Le problème est arrivé avec Ubuntu (cf. plus haut), c'est exactement la même chose. C'est un peu le principe de la défense en profondeur…

Tu le dis : HTTPS est plus performant.
Et tous les admin n'ont pas forcément envie d'autoriser du tor.

Sauf que s'il y a une faille dans APT, on pourrait faire installer des paquets APT modifiés.
Bien sûr, c'est impossible… ah bah en fait, si, c'est même déjà arrivé : https://www.ubuntu.com/usn/usn-3156-1/

Bref, ce sont deux sécurité qui sont totalement indépendantes et qui permettent (entre autres) la même chose (empêcher la corruption de paquets lors du transfert) : cela permet de pallier une faille sur l'une des deux sécurités.

sûrement un script pensé pour Python 2 et exécuté avec Python 3.

En Python 2 :
"toto" est une string de bytes (et quand tu la parcours, tu obtiens "t", "o", "t", "o"), avec interdiction d'utiliser des accents
u"toto" est une string de caractères unicode (et quand tu le parcours, tu obtiens u"t", u"o", u"t", u"o") , et tu peux utiliser des accents
Tu peux aussi faire "to" + u"to" == u"toto", "to" + u"tô" == u"totô", mais pas "tô" + u"to" (UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128))

En Python 3 :
"toto" est une string de caractères unicode (et quand tu le parcours, tu obtiens "t", "o", "t", "o") , et tu peux utiliser des accents
b"toto" est une string de bytes (et quand tu la parcours, tu obtiens les codes ASCII : 116, 111, 116, 111), avec interdiction d'utiliser des accents
Tu ne peux pas mixer les deux.

Merci, je me posais sensiblement les mêmes questions que toi. J'y vois beaucoup plus clair maintenant !

non, non, ces bombardements n'étaient pas étalés dans le temps ; par exemple le bombardement sur Tokyo qui a fait plus de 100 000 morts (les chiffres varient) a bien eu lieu en une seule nuit, avec quelques centaines de bombardiers. Parfois, le bombardement pouvait durer plus d'une journée (le temps de faire défiler tous les bombardiers, en gros), mais sans plus.
Ça n'a rien à voir avec les grandes batailles de la Première Guerre Mondiale (comme Verdun), qui ont fait des centaines de milliers de morts, mais sur plusieurs mois.

Les bombardements massifs sont du pipi de chat par rapport à l'arme atomique. Il faut des semaines de bombardements pour un résultat similaire à l'arme atomique, entre temps la population a largement de quoi faire pour fuir ou résister.

Ce n'est pas si évident que ça.
Les bombardements d'Hiroshima et de Nagasaki étaient dans la norme de ce qu'endurait le Japon à peu près tous les jours, et le bombardement le plus meurtrier n'est pas atomique mais classique (Tokyo, 185 000 morts de mémoire). Les gens n'avaient pas spécialement le temps de s'enfuir, vu qu'il s'agit à chaque fois d'un seul raid.
Bien sûr, c'étaient des petites bombes atomiques (15 kT), on ne sait pas ce que donneraient les têtes modernes (qui font généralement dans les 150 kT) des grands pays.

On l'a bien vu avec la Seconde Guerre Mondiale : les premiers à avoir frappé (le Japon en 1931 ou 1937, selon le point de vue, et les Allemands) ont brillamment gagné la guerre :)

Sinon, les Belges n'ont pas encore choisi le F-35 Lightning II (le Raptor est le F-22), même si ça reste possible sinon probable.

Faire partie de l'OTAN oblige à adopter les standards de l'OTAN dans tous les domaines.
Ça peut avoir énormément de conséquences sur la façon de faire la guerre (la guerre à l'américaine est normalement assez différente de la guerre à la française, qui a la tradition de faire avec moins de moyens), mais également beaucoup de conséquences sur l'industrie.

Imaginons un scénario : un industriel américain travaille sur un nouveau protocole de communication radio tactique dans son coin. Hop, le protocole est adopté par l'OTAN. À partir de là, les pays doivent s'équiper, et donc soit demander à leurs propres industriels (quand ils en ont) d'abandonner les travaux en cours et de repartir sur ce nouveau protocole de communication, soit d'acheter le seul qui soit disponible sur le marché…

Non, la capacité de projection française est insuffisante.
D'une part, il manque un porte-avions afin d'assurer un minimum de redondance.
D'autre part, les capacités de transport lourd et de ravitaillement en vol sont vraiment insuffisantes. On est obligé de louer des avions russes (les An-124, et probablement l'An-225) afin de palier notre insuffisance. Sans les ravitailleurs américains, on serait également bien embêtés.

Jusqu'il y a peu, notre action était également limitée par les avions qu'on avait : le Mirage 2000 et le Super Etendard ont des capacités assez faibles à distance (la plus grande partie de leur capacité d'emport est prise par le carburant supplémentaire). Heureusement, c'est beaucoup moins vrai pour le Rafale.

En générale, il n'y a pas autant de fautes dans une brochure promotionnelle.