flan a écrit 1848 commentaires

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.

Merci, j'allais poster sensiblement la même chose, mais en moins bien :)

Un vote qui n'est pas fait dans l'isoloir ne peut aucunement garantir cette absence de pression.

Par contre, je ne suis pas d'accord avec ta première remarque : peut-être que l'informatique est maintenant comprise par pas mal de personnes, mais qui est capable de garantir que le programme qui est réellement exécuté par une machine correspond bien au code source fourni ?
Qui est capable de garantir qu'un code source (un poil complexe) n'a aucun bug ?

Un vote par urne classique (et bien fait, évidemment) reste le seul moyen de garantir les propriétés requises.

merci pour l'info

graphite (et ses sous-projets) me semble un peu abandonné, malheureusement. Il reste notamment planté en Python 2 (dont j'aimerais bien me débarrasser définitivement).

Oui, sauf qu'une bonne partie de l'installation d'un des est faite par l'OS (copie des fichiers, par exemple) : les scripts seront donc plus courts et généralement limités à quelques opérations simples (création d'utilisateur, par exemple).

Autre point : un paquet peut être signé et on peut noter sa signature. Si on l'installe plus tard, on peut vérifier la signature (ou le hash) du .deb pour vérifier qu'il n'a pas été modifié.
Avec un script bash, on peut vérifier que le script n'a pas été modifié, mais on ne sait pas si le script vérifie la signature de ce qu'il télécharge…

C'est bien dommage.
* on n'a aucune idée de ce que fait le bash en question (un .deb est plus facile à évaluer),
* on n'a aucune garantie de pouvoir réinstaller le logiciel en question deux jours après (si le miroir est tombé, si le lien change, etc.),
* on ne pas installer sur un réseau déconnecté,
* souvent rien n'est fourni pour désinstaller le logiciel,
* on ne sait pas comment se passent les mises à jours,
* le système est incapable de lister ce qui a été installé à la sauvage,
…

j'oublie certainement beaucoup d'autres problèmes éventuels.

(tu peux entrer au Ministère de la Défense après avoir fait des études dans le civil, tu peux y entrer en restant civil, tu peux également bosser pour eux sans en faire partie, …)

Si ton emploi d'un portable ne résiste pas à un problème de chiffrement de disque, c'est qu'il y a de toute façon un énorme problème : que fais-tu si tu perds l'ordi ? si tu te le fais voler ? si le disque meurt sans prévenir ?

Avant de déconseiller le chiffrement intégral (toujours une bonne idée, surtout pour un portable), il vaudrait mieux résoudre le vrai problème : l'absence de sauvegarde pour pallier un souci matériel sur l'ordinateur.

Ceux qui ne font pas n’importe quoi, en général : 1) ne croient pas en la sécurité par l’obscurité

Cela veut dire que la protection ne doit pas se baser le secret de la méthode employée. Mais maintenir le secret de la méthode employée ne nuit pas forcément, et ça ne veut pas dire que le logiciel n'a pas été revu (s'il est qualifié par l'ANSSI, c'est qu'il a été revu par cette institution, par exemple).

Si je stocke un fichier non-chiffré sur un support hors-ligne, il sera aussi bien protégé que s’il était chiffré avec ACID Cryptofiler.

Bien sûr que non. Va dire ça aux Iraniens, dont les machines (centrifugeuses nucléaires) ont été infectées alors qu'elles étaient hors-ligne… Croire qu'il suffit que ton réseau soit hors-ligne pour qu'il soit protégé est une grosse erreur.

En gros, tu veux faire une nation européenne, parce que tu n'aimes pas l'idée de nation.

C'est un peu étrange, comme façon de penser…

J'ai toujours entendu de snake_case plutôt que de lowercase_with_underscore.

mais ça arrive vraiment ce genre de cas ? je tiens mes ordis à jour, je n'utilise quasiment que la ligne de commande, et pourtant je n'ai pas souvenir avoir dû récupérer un OS si souvent que ça. Je n'ai jamais essayé avec Linux, mais sous macOS (et Windows, me semble-t-il mais je connais beaucoup moins), c'est assez trivial de réinstaller tout l'OS sans écraser les données utilisateur (au point de se retrouver après la réinstallation avec les derniers documents ouverts d'avant la réinstallation). Je suis surpris qu'on ne puisse pas faire la même chose avec Linux (au moins les grandes distribs).
Mais bon, comme je l'ai dit, je ne prends aucune mesure pour protéger mon /home lors d'une réinstallation vu qu'une reconfiguration ne me coûte presque rien.

Est-ce nouveau ? Mon portable (Apple, avec la dernière version de macOS) permet de l'éteindre complètement (même si c'est rarissime, je n'ai aucune raison de le faire).

Sinon, je ne comprends pas l'intérêt de partitionner les disques. De toute façon, il vaut mieux partir du principe que le disque peut être perdu (disque mort, ordi perdu ou volé par exemple) et être capable de réinstaller l'ensemble. Si ce n'est pas le cas, c'est qu'il y a un risque peu acceptable de mon point de vue.

Il faut surtout voir jusqu'à quelle date il a été vendu… S'il a été vendu jusqu'en 2016, ça n'a rien d'extraordinaire de fournir des mises à jour pour un téléphone qui a un an.

Il y a une énorme différence entre affirmer comme tu le fais qu'il y a des backdoor (action volontaire de Google) et ce qui est dit dans tes sources, c'est-à-dire qu'il y a des failles (qui sont involontaires).

Normal : c'est compilé sur la machine.

Les distribs doivent compiler la version avec et la version sans PA à partir d'un seul paquet source. Avec Arch, tu refais ce boulot de la distrib et tu ne compiles que la version choisie.

Oui, je sais tout ça… et alors ? En quoi, pour l'humain, est-ce plus facile de manipuler des Ko de 1024 octets ?

Parler de disquettes de 1,44 Mo ne me semble pas franchement plus facile que de parler de disquettes de 1,47Mo (voire 1,5 Mo si on arrondit, parce que dans 99,9% — valeur particulièrement précise, évidemment — des cas on se moque d'avoir la valeur précise).
Pour la RAM, quand on a 512 Mo de RAM, est-ce réellement plus simple que d'avoir 536 Mo de RAM ? Ou encore, plus simplement, 0,5 Go de RAM ? Je suis prêt à parier qu'un processeur à 3 GHz ne fonctionne pas à 3 000 000 000 Hz très exactement, et pourtant cet arrondi ne fait de mal à personne (bien sûr, je ne parle pas des variations permanentes de fréquences des processeurs actuels).

Un Byte n'est pas toujours égal à un octet.
Un octet vaut 8 bits, alors qu'un byte est la plus petite unité adressable (souvent 8 bits, mais pas toujours). On peut avoir des bytes de 10 bits, par exemple.