| okhin | Ou pas...
Bref, après avoir potassé et un peu plus assimilé les règles d'Unwired, j'en revient toujours au fait que les agents sont fumés et pas assez cher (si leur cargaison est variable) ou complètement handicapé et trop lourd et trop cher (si leur cargaison est fixe). Même si ils sont limités par leur intelligence, et par la complexité des scripts qui y sont associés, un agent ne reste qu'une coquille vide intelligente bien trop monstrueuse pour ce que c'est, et pas forcément représentative de ce que c'est "réellement", du moins, de mon point de vue.
Déjà, je n'arrive pas à déterminer si la cargaison d'un agent est fixe ou pas, c'est à dire si l'agent est vendu avec des softs inclus, et que ceux-ci ne peuvent pas changer (auquel cas, un agent reste très cher) ou si il se sert dans la bibliothèque du hacker (ce qui est possible si les softs sont piratés, en OSS ou autre). ET puis les IC et les agents sont identiques au malwares, ils peuvent utiliser les mêmes programmes qu'un hacker (y compris avec des options telles que "ergonomie" ou autre. bref, ça ne me convaincs pas.
J'avait fait une tentative pré-Unwired qui me paraît une bonne base, à savoir que les agents nécessite d'être "compilés" pour être opérationnel.
Ensuite, je me pose la question des programmes. Un agent utilise-t-il les mêmes softs qu'un hacker? Même en mode hot-SIM? L'agent n'est pas limité par un corps ou la perception qu'il a de son corps. Il a été conçu pour pouvoir piloter efficacement une suite d'instructions. Utiliser un programme d'agent lorsqu'on n'en est pas un, c'ets un peu comme demander à mon grand père de lire le dump hexadécimal d'un fichier word avec vi afin de savoir le contenu du document. C'est faisable de façon très efficace par un agent, mais mon grand père n'a aucune chance d'y arriver dans des temps raisonnables.
Même en 2070, alors que nous pouvons utiliser des utilitaires à la vitesse de la pensée, on passe par une interface (il faut bien représenter les données dans un format que peut comprendre notre cerveau et vis versa, interface qui n'est pas, pour moi, nécessaire à un agent. Disons qu'il possède des accès à une API dans le meilleur des cas, il ne dispose d'aucun périphérique de pointage ou autre.
Et pour moi, les agents ont un côté "virus chinois" du Neuromancien de Gibson. C'est efficace, mais faut attendre huit heures qu'il se déploie, de plus une IC, un malware ou un "moteur de script" ne fonctionnent pas du tout de la même façon ni dans la même optique. Une IC aura tendance à être optimisée et rapide pour ne pas pénaliser le node sur lequel elle tourne, mais elle n'aura pas énormément d'intelligence et prendra ses ordres auprès d'un ssystème de défense généralisé par exemple, un malware sera pareil très petit, léger, mais pas ou peu adaptable, nécessitant d'être configuré entre deux attaques. Enfin, le moteur de script, l'agent classique quoi, peu être lourdingue à souhait et chapottes en général plusieurs agents plus petits. Bref, je reprendrai les grandes idées dans le post ici.
Tout est icône
Tout est icône dans la matrice. C'est à dire que n'importe quel élément peut être représenté par une icône. En gros, un nœud est une icône. Les fichiers de ce noeud sont aussi des icônes, un persona est une icône, un agent est une icône et un programme est aussi une icône.
Perméabilité et Hiérarchie
Pour que tout cela soit exploitable, et afin que la matrice ne soit par perçue comme un ensemble tendant vers l'infini d'icône, deux notions ont été mises en place: la Perméabilité et la Hiérarchisation. La Hiérarchisation permet de dire que telle icône dépend de telle autre, et de les organiser en arbre fonctionnels (les fichiers dépendent de répertoire ou de node, les programmes dépendant de personna, les personna dépendent des nodes sur lesquelles elles sont chargés, etc). La Perméabilité rend les icône étanches les unes aux autres. C'est à dire qu'une icône peut voir toutes celles qui sont à son niveau. Elle ne peut pas voir son "père" en tant qu'icône, ni voir le contenu de ses "sœurs", sans analyse attentive du moins (soit l'icône publie du contenu et l'affiche en public, auquel cas une simpel demande de lecture peut suffire, soit elle caches es donénes, et il faudra en lister le contenu avec Analyse). Elle peut par contre accéder librement à tout ses "fils".
La conjonction de ces deux principes donne l'aspect en arbre de la matrice, et permets aux architectes de décorer l'intérieur des icônes. En gros, si je suis dans un nœud, je ne perçoit pas son icône, mais je subit son environnement, et je peux voir toutes les icônes situées directement le nœud, sans voir leur contenu. Je peux librement me déconnecter du nœud, auquel cas je verrait son icône, mais je ne verrait plus son contenu. Je verrai par contre les autres nœuds auquel il est rattaché et la structure de l'ensemble (du moment que j'arrive à faire mon jet d'Analyse et à vaincre la Furtivité des icônes qui en possèdent éventuellement).
Cette vision apporte deux choses. Déjà, je peux planter un node comme on plante une icône, sans passer par l'intérieur. En gros, je vais surcharger ses entrées et il finira par planter. Il est également possible d'utiliser Stealth pour cacher un node, etc. Ensuite, ce qui est dans le nœud ne peut pas interagir avec ce qui est hors du nœud, et vice-versa. Je ne peux voir un fichier que si je suis à son niveau (donc dans le nœud de stockage), mais une IC ne peut pas m'attaquer en étant planquée dans son node.
Association
Chaque agent est une suite de script, de réseaux de neurones et d'algorithme de calculs qui permettent de créer quelque chose d'approchant d'un circuit logique de pensée. Ces suites sont généralisées et doivent donc apprendre à se servir des utilitaires qu'on leur fournit. Ces phases sont généralement déjà effectuée sur les agents "du commerce", mais sont nécessaire lorsque la cargaison d'un agent doit être effectuée.
Une fois la phase d'Association effectuée, l'agent et ses programmes comptent comme une seule entité. Il est toujours possible de cibler le contenu de l'agent car les routines restent identifiables, pour des raisons de communication inter agent, mais on ne peut pas "retirer" un programme d'un agent, sans passer par une phase de désassociation, qui se fait généralement agent au repos.
Fetch
Chaque agent peut posséder une fetch. Une "personnalité" (généralement codée sur l'interprétation des signaux simsens d'une persona fix, ou équivalent) qui lui fournira des "compétences" sectorielles, agissant comme des compétences de connaissances (et non pas comme des Autosofts) permettant à l'Agent d'améliorer ses performances. Les fetchs sont souvent utilisés pour les IC (qui usent et abusent des fetchs avec un background militaire) et les agents de data-mining (recherche et analyse de donnée, utilisant des fetchs de banquiers par exemple ou autre).
Les fetch ne sont absolument pas obligatoire, mais très répandus car l'amélioration est significative lorsque l'agent est dans son domaine. Elles permettent également de s'affranchir des scripts de comportement, se basant pour cela sur les heuristiques de personnalité implémentées dans les fetchs pour pouvoir résoudre les paradoxes logiques et autres choix multi-critères insoluble par logique pure. Les fetchs ont cependant tendance à pénaliser les agents les utilisant lorsqu'ils sortent de leur contexte (le général Lee, même si il fiat un trés bon stratège militaire, reste un piètre analyste économique).
[SUITE]
Okhin |