Styles

dimanche 15 mars 2015

Quand Facebook réinvente le minitel

Facebook vient de réinventer internet sur le modèle économique du minitel où le prix est fonction du site Web que vous visitez. Vous imaginez bien la menace que cela représente pour la neutralité d'internet. Heureusement, vous savez très bien que ce genre de modèle économique ne marchera pas, ne serait-ce que par l'ingéniosité des internautes ainsi muselés.

vendredi 13 mars 2015

Substitution de processus

Je viens de créer l'article Wikipedia Substitution de processus pour décrire ce magnifique mécanisme :


En informatique, la substitution de processus est une forme de communication inter-processus permettant à l'entrée ou à la sortie d'une commande d’apparaître sous la forme d'un fichier. L'interface système substitue la commande en ligne par un nom d'un fichier. Cela permet aux programmes qui n'acceptent normalement que des des fichiers de lire directement à partir ou vers un autre programme.




Exemple

Les exemples suivants utilisent la syntaxe Bash.

La commande diff de Unix accepte normalement les noms de deux fichiers à comparer, ou un nom de fichier et l'entrée standard. La substitution de processus vous permet de comparer directement la sortie de deux programmes :

$ diff <(sort fichier1) <(sort fichier2)

L'expression <(commande) dit à l'interpréteur d'exécuter commande et fait apparaitre sa sortie sous la forme d'un fichier. La commande peut être n'importe quelle commande complexe de l'interface système.

Sans la substitution, les alternatives sont:

1. Sauvegarder la sortie de la commande(s) vers un fichier temporaire, puis lire le(s) fichier(s) temporaire(s).

$ sort fichier2 > /tmp/fichier2.trie
$ sort fichier1 | diff - /tmp/fichier2.trie
$ rm /tmp/fichier2.trie

2. Créer un tube nommé (aussi connu sous le nom de FIFO), démarrez une commande écrivant vers le tube nommé en tâche de fond, puis exécutez l'autre commande avec le tube nommé en tant qu'entrée.

$ mkfifo /tmp/tri2.fifo
$ sort fichier2 > /tmp/tri2.fifo &
$ sort fichier1 | diff - /tmp/tri2.fifo
$ rm /tmp/tri2.fifo

Les deux alternatives sont plus lourdes.

La substitution de processus peut aussi être utilisée pour capturer la sortie qui est normalement destinée à aller vers un fichier, et la rediriger vers l'entrée d'un processus. La syntaxe Bash pour écrire vers un processus est >(commande). Voici un exemple utilisant les commandes tee, wc et gzip pour compter les lignes d'un fichier avec wc -l et les compresser avec gzip en une seule passe:

$ tee >(wc -l >&2) < grosfichier | gzip > grosfichier.gz


Avantages

Les avantages principaux de la substitution de processus sur ses alternatives sont :

  • sa simplicité : les commandes peuvent être saisies en ligne; il n'y a pas besoin avant cela de sauvegarder des fichiers temporaires ou créer des tubes nommés.
  • sa performance : lire directement d'un autre processus est souvent plus rapide que de devoir écrire dans un fichier temporaire sur disque, puis de le lire. Cela permet aussi d'économiser de l'espace disque.
  • son parallélisme: le processus substitué peut s'exécuter concurremment avec la commande lisant sa sortie ou écrivant sur son entrée, tirant avantage du traitement multiple pour réduire le temps total de traitement.


Mécanisme

Sous le capot, la substitution de processus fonctionne en créant un tube nommé, puis en substituant son nom sur la ligne de commande (la substitution de processus est ainsi parfois appelée "tube nommé anonyme"). Pour illustrer les étapes en jeu, considérez la substitution simple de commande suivante :

diff fichier1 <(sort fichier2)

Les étapes entreprises par l'interface système sont:

  1. Création d'un nouveau tube nommé. Ce fichier spécial est souvent nommé sur le modèle /dev/fd/63 sur les sytèmes de style Unix; vous pouvez le voir avec une commande comme echo <(true).
  2. Exécution de la commande substituée en arrière plan (sort fichier2 dans notre cas), tubant sa sortie sur le tube nommé.
  3. Exécution de la commande primaire, en remplaçant la commande substituée par le nom du tube nommé. Dans notre cas, la commande entière peut se développer en diff fichier1 /dev/fd/63.
  4. Quand l'exécution est terminée, suppression du tube nommé.


Limitations

La substitution de processus a quelques limitations: les "fichiers" créés ne peut pas être recherchés (fseek), ce qui veut dire que le processus lisant ou écrivant vers le fichier ne peut pas réaliser un accès direct; il doit seulement lire ou écrire du début à la fin. Les programmes qui vérifient explicitement le type de fichier avant de l'ouvrir pourrait refuser de fonctionner avec le substitution de processus, car le "fichier" résultant de la substitution de processus n'est pas un fichier normal. "Il n'est pas possible d'obtenir un code de sortie d'une commande de substitution de processus à partir de l’interface système ayant créé la substitution de processus.

Voir aussi

vendredi 6 mars 2015

Histoire de la réplication dans PostgreSQL

Cet article est une traduction par mes soins de l'article de Peter Eisentraut : The history of replication in PostgreSQL, publiée avec son autorisation.

2001: PostgreSQL 7.1: le journal à écriture anticipée

PostgreSQL 7.1 a lancé le Journal à Ecriture Anticipée (Write-ahead log : WAL). Avant cette version, tous les fichiers de données ouverts devaient être fsyncés sur chaque commit, ce qui était très lent. La lenteur du fsync est encore un problème aujourd'hui, mais maintenant nous sommes seulement préoccupés par le fsyncage du WAL et le fsyncage des fichiers de données au cours du processus de point de contrôle (checkpoint). À l'époque, nous avions à fsyncer tout, tout le temps.

Dans la conception originale de POSTGRES universitaire, l'absence d'un journal était intentionnel, et se démarquait des architectures largement basées sur la journalisation comme Oracle. Dans Oracle, vous avez besoin de faire un retour arrière sur les modifications dans le journal. Dans PostgreSQL, le système de stockage sans écrasement prend soin de cela. Mais, probablement, personne n'a pensé aux implications de fsync à l'époque.

Notez que le WAL était vraiment juste un détail d'implémentation à ce stade. Vous ne pouviez pas le lire ou l'archiver.

2004: Slony

Juste pour le contexte: Slony-I 1.0 est sorti en Juillet 2004.

2005: PostgreSQL 8.0: récupération à un point donné

PostgreSQL 8.0 a ajouté la possibilité de copier le WAL ailleurs, et plus tard le lire à nouveau, soit en entier soit jusqu'à un point donné dans le temps, d'où le nom de récupération à un point donné (Point-In-Time Recovery : PITR) pour cette fonctionnalité. Cette fonctionnalité était principalement destinée à laisser tomber pg_dump comme méthode de sauvegarde. Jusque-là, la seule méthode de sauvegarde existante était un vidage complet (dump), qui devenait malaisé plus les bases de données augmentaient. D'où cette méthode consistant à prendre occasionnellement une sauvegarde de base, qui est la partie coûteuse, puis à ajouter les parties du WAL, ce qui est moins coûteux.

Les mécanismes de configuration de base que nous utilisons encore aujourd'hui, par exemple, le fichier recovery.conf, ont été introduits dans le cadre de cette fonctionnalité.

Mais toujours pas de réplication ici.

2008: PostgreSQL 8.3: pg_standby

Des malins ont fini par comprendre que si vous archiviez le WAL sur un serveur et en même temps vous le récupériez (recover) à l'infini sur un autre, vous aviez une configuration de réplication. Vous pouviez probablement le faire avec vos propres scripts dès là 8.0, mais PostgreSQL 8.3 a ajouté le programme pg_standby dans contrib, ce qui donna à chacun un outil standard. Ainsi, on peut dire sans doute que la 8.3 fut la première version qui contint un semblant de solution de réplication intégré.

Le serveur de secours effectuait une récupération permanente jusqu'à sa promotion, de sorte qu'il ne pouvait être lu pendant qu'il répliquait. C'est ce que maintenant nous appelons un secours semi-automatique (warm standby).

Je pense que beaucoup d'installations PostgreSQL 8.3 refusent de mourir parce que c'est la première version où vous pouviez facilement avoir un serveur de réserve assez à jour, sans avoir recours à des outils complexes et parfois problématiques comme Slony ou DRBD.

2010: PostgreSQL 9.0: secours automatique, réplication par flux

Dans PostgreSQL 9.0, deux fonctions de réplication importantes sont arrivés indépendamment l'une de l'autre. Tout d'abord, la possibilité de se connecter à un serveur de secours en mode lecture seule, ce qui s'appelle un secours automatique (hot standby). Alors qu'auparavant, un serveur de secours était principalement utile uniquement comme réserve au cas où le serveur primaire tombait, avec le secours automatique, vous pouvez utiliser les serveurs secondaires pour y répartir la charge de lecture seule.

Deuxièmement, au lieu de s'en remettre uniquement aux archives WAL et aux fonctionnalités de récupération pour transporter les données du WAL, un serveur de secours peut se connecter directement au serveur principal via le protocole libpq existant et obtenir les données du WAL de cette manière, ce qu'on appelle la réplication par flux (streaming replication). Son utilisation principale dans cette version permettait au secours d'être plus à jour, peut-être de l'ordre de quelques secondes, plutôt que de quelques minutes avec l'approche basée sur l'archivage. Pour une configuration robuste, vous aviez encore besoin de mettre en place un archivage. Mais la réplication par flux était également une fonctionnalité tournée vers l'avenir qui finirais par faciliter la mise en place de véritables configurations de réplication, en réduisant la dépendance envers l'ancien mécanisme d'archivage.

PostgreSQL 9.0 fut la première version où l'on put prétendre que PostgreSQL "supporte la réplication" sans avoir à évoquer de restrictions ou s'excuser. Même s'il est prévu qu'elle atteigne sa fin de vie (End of Life : EOF) cette année, je me attends à ce que cette version continue à vivre pendant un bon moment.

2011: PostgreSQL 9.1: pg_basebackup, la réplication synchrone

pg_basebackup a été l'une des fonctionnalités permise par la réplication par flux qui rendit les choses plus facile. Au lieu d'avoir à utiliser des outils externes comme rsync pour les sauvegardes de base, pg_basebackup utilise une connexion libpq normale pour sortir une sauvegarde de base, évitant ainsi des configurations compliquées de connexion et d'authentification pour les outils externes. (Certaines personnes continuent de préférer rsync car il est plus rapide pour eux.)

PostgreSQL 9.1 a également ajouté la réplication synchrone, qui s'assure que les données sont répliquées sur le serveur de secours désigné avant que le COMMIT indique un succès. Cette fonctionnalité est souvent mal comprise par les utilisateurs. Bien qu'elle vous assure que vos données soient sur au moins deux serveurs à tout moment, elle pourrait en fait réduire la disponibilité de votre système, parce que si le serveur de secours tombe, le serveur primaire tombera aussi, sauf si vous avez un troisième serveur disponible pour prendre en charge la tâche synchrone de secours.

C'est peut-être moins largement connu mais PostgreSQL 9.1 a également ajouté la fonction pg_last_xact_replay_timestamp pour surveiller facilement le décalage du secours.

D'après mon expérience, la mise à disposition de pg_basebackup et pg_last_xact_replay_timestamp a fait de PostgreSQL 9.1 la première version où gérer la réplication était relativement facile. Remonter plus loin, et vous pourriez vous sentir contraint par les outils disponibles. Mais en 9.1, ce ne est pas très différent de ce qui est disponible dans les versions les plus récentes.

Cette photo est © Malcolm Cerfonteyn - CC BY 2.0

2012: PostgreSQL 9.2: réplication en cascade

Pas aussi largement acclamé, plus pour les amateurs de Slony peut-être, PostgreSQL 9.2 permis aux serveurs de secours d'aller chercher leurs données de réplication par flux à partir d'autres serveurs de secours. Une conséquence notamment de cela est que pg_basebackup pouvait récupérer les données à partir d'un serveur de secours, laissant ainsi la charge hors du serveur principal, pour la mise en place d'un nouveau serveur de secours ou une copie autonome.

2013: PostgreSQL 9.3: le serveur de secours peut suivre le changement de chronologie

Cela n'a même pas été relevé dans les faits marquants de la version. Dans PostgreSQL 9.3, lorsqu'un primaire a deux secours, et l'un des secours est promu, l'autre secours peut continuer à suivre le nouveau primaire. Dans les versions précédentes, le deuxième secours devait être reconstruit. Cette amélioration rend les changements dynamiques d'infrastructure beaucoup plus simples. Non seulement elle élimine le temps, les soucis, et l'impact sur les performances de la mise en place d'un nouveau secours, plus important encore, elle évite la situation, après une promotion, de n'avoir aucun serveur de secours à jour pendant un certain temps.

2014: PostgreSQL 9.4: emplacements de réplication, décodage logique

Le décodage logique est ce qui a retenu le plus l'attention pour la nouvelle version PostgreSQL 9.4, mais je pense que les emplacements de réplication (replication slots) représentent la fonctionnalité majeure, peut-être la plus grande fonctionnalité de réplication depuis PostgreSQL 9.0. Notez que pendant que la réplication par flux est devenu de plus en plus sophistiquée au fil des ans, vous avez toujours besoin d'archiver le WAL pour la robustesse complète. C'est parce que le serveur primaire ne garde pas de liste de ses serveurs de secours supposés, il ne fait que transférer le flux WAL à qui que ce soit le demande, s'il se trouve l'avoir à disposition. Si le serveur de secours était suffisamment en retard, la réplication par flux échouait, et la récupération par le recours à l'archive devenait nécessaire. Si vous n'aviez pas d'archive, le serveur de secours n'était alors plus en mesure de rattraper son retard et devait être reconstruit. Et ce mécanisme d'archivage n'a essentiellement jamais changé depuis la version 8.0, quand il avait été conçu pour un but totalement différent. Ainsi, une configuration de réplication est en fait assez compliqué: Vous devez configurer un chemin d'accès du primaire au secours (pour l'archivage) et un chemin d'accès du secours au primaire (pour le flux). Et si vous vouliez mettre plusieurs secours, en cascade, le maintien de l'archive pouvais devenir vraiment compliqué. En outre, je pense que beaucoup de configurations d'archivage ont un paramétrage problématique de archive_command. Par exemple, est-ce que votre archive_command réalise un fsync du fichier du côté le recevant ? Probablement pas.

Plus maintenant : Dans PostgreSQL 9.4, vous pouvez configurer ces fameux emplacements de réplication, ce qui signifie concrètement que vous enregistrez sur le primaire la présence d'un secours, et le primaire garde le WAL pour chaque secours jusqu'à ce qu'ils l'aient tous récupéré. Avec cela, vous pouvez vous débarrasser complètement de l'archivage, à moins que vous en ayez besoin pour faire une véritable sauvegarde.

2015? PostgreSQL 9.5? pg_rewind?

Un des problèmes restants est que la promotion d'un secours rend l'ancien primaire incapable de changer de cap et de suivre le nouveau primaire. Si vous basculez parce que l'ancien primaire est mort, alors ce n'est pas un problème. Mais si vous voulez juste échanger le primaire et le secours, peut-être parce que le secours dispose d'un matériel plus puissant, l'ancien primaire, désormais un secours, doit être reconstruit entièrement à partir de zéro. Transformer un ancien primaire en un nouveau secours sans une nouvelle sauvegarde complète de base est un problème assez complexe, mais un outil qui peut le faire (actuellement nommé pg_rewind ) est proposé pour inclusion dans la prochaine version de PostgreSQL.

Au-delà

Un des problèmes que cette évolution de la réplication a créés est que la configuration est plutôt idiosyncratique, assez compliquée à mettre en place correctement, et presque impossible à généraliser suffisamment pour la documentation, les tutoriels,... Supprimer l'archivage avec 9.4 pourrait résoudre certains de ces points, mais configurer rien que la réplication par flux est toujours étrange, et encore plus étrange si vous ne savez pas comment tout cela est arrivé jusqu'ici. Vous devez modifier plusieurs paramètres obscurs de configuration, certains sur le primaire, certains sur le secours, dont certains nécessitent un redémarrage complet du serveur primaire. Et ensuite vous avez besoin de créer un nouveau fichier de configuration recovery.conf, même si vous ne voulez pas de récupérer quoi que ce soit. Apporter des changements dans ce domaine est essentiellement un processus politique complexe, parce que le système actuel a bien servi les gens pendant de nombreuses années, et arriver avec un nouveau système qui est objectivement meilleur et adresse tous les cas d'utilisation existants est lourd.

Un autre problème est que toutes ces fonctionnalités se basent fortement sur le mécanisme de WAL, et cela contraint tous les usages du WAL de diverses manières. Par exemple, il y a des optimisations qui ne passent pas par la journalisation WAL dans certaines circonstances, mais si vous voulez de la réplication, vous ne pouvez pas les utiliser. Qui ne veut pas faire de la réplication ? En plus, le WAL couvre un système de base de données complet et marche en tout ou rien. Vous ne pouvez pas répliquer seulement certaines tables, par exemple, ou consolider les journaux provenant de deux sources différentes.

Que diriez-vous de ne pas tout baser sur le WAL? Avoir deux journaux différents pour deux objectifs différents. Cela a été discuté, en particulier au moment où la réplication par flux a été construite. Mais alors vous avez besoin de deux journaux qui sont quasiment identiques. Et le WAL est par conception un goulot d'étranglement, alors créer un autre journal créerait probablement des problèmes de performance.

Le décodage logique brise nombre de ces restrictions et sera probablement la fondation pour le prochain tour des fonctionnalités majeures de réplication. Par exemple, la réplication partielle et la réplication multi-maître, certaines étant déjà en cours d'élaboration.

Que pouvons-nous attendre de la journalisation WAL pure et simple en attendant ? Une configuration plus facile est demandée fréquemment. Mais peut-on s'attendre à des sauts importants en terme de fonctionnalité? Qui sait. Il fut un temps, quelque chose comme la secours automatique était vu comme presque impossible. Donc il pourrait encore y avoir des surprises.

vendredi 7 mars 2014

PostgreSQL : configuration de l'environnement psql

Quand il s'agit de configurer et manipuler une base de données, rien de mieux que d'utiliser le client sql en mode texte qui permet de manipuler directement les objets de la base dans tous les sens. Concernant PostgreSQL, le client psql est aussi complet qu'un client SQL*Plus pour Oracle Database par exemple.

Il s'agit de configurer correctement psql pour être plus productif. Pour cela, on stockera dans ~/.psqlrc la configuration de base qui sera chargée à chaque lancement de psql.

Voici mon fichier de configuration ~/.psqlrc que j'utilise tous les jours:

\set QUIET ON

\set PROMPT1 '%n@%M %~%R%# '
\set PAGER OFF
\set HISTFILE ~/.psql_history- :HOST - :DBNAME
\set HISTSIZE 2000
\set ECHO_HIDDEN ON
\set COMP_KEYWORD_CASE upper
\timing on
\encoding unicode
\pset null 'NULL'
\pset border 1

\set QUIET OFF

\echo 'Predefined queries:\n'
\echo '\t\t\t:settings\t-- Server Settings'
\echo '\t\t\t:dbsize\t\t-- Database Size'
\echo '\t\t\t:tablesize\t-- Tables Size'
\echo '\t\t\t:uptime\t\t-- Server uptime'

\set settings 'select name, setting,unit,context from pg_settings;'

\set dbsize 'SELECT datname, pg_size_pretty(pg_database_size(datname)) db_size FROM pg_database ORDER BY db_size;'

\set tablesize 'SELECT nspname || \'.\' || relname AS \"relation\", pg_size_pretty(pg_relation_size(C.oid)) AS "size" FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN (\'pg_catalog\', \'information_schema\') ORDER BY pg_relation_size(C.oid) DESC LIMIT 40;'

\set uptime 'select now() - pg_postmaster_start_time() AS uptime;'


Faites \? sous psql pour voir quel est le sens de chaque instruction. A noter le moyen bien pratique pour enregistrer des requêtes prédéfinies dans des variables.

Sous windows, ce fichier n'est pas dans %HOME%\.psqlrc mais à %APPDATA%\postgresql\psqlrc.conf On peut aussi indiquer explicitement où se trouve le fichier .psqlrc en mettant son chemin complet dans la variable d'environnement PSQLRC.

Une autre configuration intéressante est l'instruction \x qui permet d'indiquer vouloir afficher les lignes de données en colonne plutôt qu'en ligne : pratique quand on est en présence de lignes assez longues.

samedi 21 septembre 2013

Blender : mes débuts dans le monde de la 3D

La 3D, pour un informaticien, a toujours quelque chose d'attirant en soi : produire des images virtuelle par la simple entremise de la puissance de calcul d'un ordinateur et des algorithmes de rendu de plus en plus réalistes.

Quand j'étais un gamin, je jouais avec Sculpt4D sur Amiga, et je trouvais vraiment génial de pouvoir produire des images à partir d'une modélisation d'une scène.

Dans le monde de la source ouverte, un logiciel tient la dragée haute à nombre d'autres produits commerciaux. Il s'agit de Blender. Cet outil est magnifique pour créer des modèles en trois dimensions, créer des rendus de toute beauté, et va même jusqu'à permettre de faire de l'animation et du montage vidéo, et ce, avec une qualité digne de tous les autres produits professionnels.

Entrer dans le monde de Blender n'est pas chose aisée. L'interface utilisateur est très riche, et s'organise en fenêtres qui ne se chevauchent pas. De nombreuses touches de raccourcie existent et permettent d'être productif. Blender offre en standard, la capacité d'enregistrer des "screencasts", des enregistrements vidéos de ce que vous faites dans Blender. Grâce à ça, de nombreux tutoriels vidéos existent et sont maintenant la manière privilégiée d'apprendre à utiliser Blender.


Je viens de finir un tutoriel du site suisse kopilot.ch : Faire une pile de DVD avec projection d'ombre sur fond transparent et canal alpha de l'ombrage.

 

Voici le rendu que j'ai réalisé en suivant ce tutoriel :


Blender est un monde à lui tout seul et vaut vraiment le coup qu'on s'y attache.

samedi 6 juillet 2013

Mort de Douglas Engelbart, l’inventeur de la souris d’ordinateur

"Le monde virtuel pleure Doug Engelbart, l’inventeur de la souris d’ordinateur décédé mardi à son domicile de la Silicon Valley. A l’origine, la souris était une boîte en bois avec deux roues de métal. Ce dispositif de pointage pour ordinateur a été amélioré par l’informaticien suisse Jean-Daniel Nicoud de l’École polytechnique fédérale de Lausanne (EPFL)." [...]


La première souris au monde !

CI News


The Mother of all Demos

samedi 8 juin 2013

Rich Hickey, créateur de Clojure : l'orienté objet est très surfait

Écoutons ce que Rich Hickey, créateur du langage Clojure nous dit de l'orienté objet dans un article donnant les raisons qui l'ont poussées à construire Clojure:

L'orienté objet est surfait:
  • né de la simulation : maintenant utilisé pour tout, même quand cela est inapproprié : cela est encouragé par Java/C# dans toutes les situations du à leur manque de support (idiomatic) pour n'importe quoi d'autre
  • Les objets à état mutables sont maintenant les nouveaux codes spaghetti: difficiles à comprendre, tester et à raisonner dessus, un désastre pour gérer la concurrence.
  • L'héritage n'est pas la seule manière de faire du polymorphisme,
  • "C'est mieux d'avoir 100 fonctions autour d'une seule structure de données que 10 fonctions opérant autour de 10 structures de données", Alan J. Perlis
  • Clojure modèle ses structures de données autour d'objets immutables représentés par des interfaces, et pas son propre système de classes
  • Plusieurs fonctions définies sur peu de structures de données (seq, map, vector, set)
  • Ecrivez du Java avec Java, consommez et étendez Java à partir de Clojure.

Pour un besoin de programmation concurrente, clojure a de nombreux atouts, mais combien de programmeurs sont capable de produire du lisp aujourd'hui ? Le Lisp est pourtant une très bonne école pour comprendre l'ensemble des paradigmes de programmation, comme on peut le lire dans le magnifique livre Structure and Interpretation of Computer Programs.

L'emacsien codant déjà avec un dialecte de lisp (Emacs Lisp) ira plus facilement vers clojure. Et puis, ce n'est pas un certain Gosling qui a créé une première version de Emacs, et plus tard un autre language ... appelé Java ? Le monde est petit...

mardi 4 juin 2013

Nous entrons dans une nouvelle ère dont la sécurité sera l'enjeu

Nous entrons définitivement dans une nouvelle ère car des ordinateurs quantiques sont maintenant disponibles à l'achat (pas pour tout le monde quand même, prix d'entrée : 10M$). Cela va rendre complètement obsolète toutes nos technologies de cryptage et sécurité associées que nous utilisons aujourd'hui. Bien que tout cela soit "en cours" de déploiement chez Google et à la Nasa, cela augure de nouvelles menaces et failles de sécurité si nous ne prenons pas pleinement conscience du saut technologique que représente un ordinateur quantique (suite).