01. Vision et Spécifications Comparatives

Navigation : Documentation > 01. Vision et Spécifications Comparatives

Sommaire

Principes et Objectifs du Système
Tableau Comparatif des Paradigmes
Fondements Théoriques et Littérature Académique
Immutabilité et Déploiement sans Effets de Bord
Gestion Transactionnelle et Rollback en O(1)
Séparation Code / Données

1. Principes et Objectifs du Système

erable est un gestionnaire de paquets universel, multiplateforme (Windows, Linux, macOS), conçu pour offrir des performances maximales sans nécessiter de privilèges administrateur. Son moteur d'exécution et ses scripts de cycle de vie reposent nativement sur Nushell (nu).

Le système repose sur cinq piliers d'ingénierie fondamentaux :

🚀 1. Routage Haute Performance sans Shims ni Liens Symboliques

Mécanisme : Les commandes applicatives sont exposées via des Trampolines Universels compilés en Rust natif (~25-30 Ko).
Latence quasi-nulle : Remplacement direct d'espace mémoire sous POSIX (execv, 0 ms de latence) et invocation directe Win32 (CreateProcessW, ~1 ms contre plus de 50 ms pour des wrappers shell ou shims PowerShell).
Zéro lien symbolique : Préservation native de %~dp0 pour les outils reposant sur des résolutions relatives (npm, pip, deno).

📦 2. Découplage Binaire / État (Stateless Delivery)

Immutabilité stricte : Les arborescences de paquets installées dans ~/.erable/packages/<nom>/<version>/ sont strictement immuables et préservées de toute altération.
Résilience aux mises à jour : Les configurations et états applicatifs résident dans les répertoires standards natifs de l'OS (~/.config, %APPDATA%), évitant toute rupture lors des écritures atomiques ou purges.

🌐 3. Distribution Légère sans Dépôts Git Locaux

Index ultra-léger : Le client ne clone aucun dépôt Git local lourd de plusieurs centaines de mégaoctets.
Synchronisation sub-seconde : Téléchargement direct d'un index précompilé signé (index.nuon, ~500 Ko) via de simples requêtes HTTP statiques avec vérification d'empreinte Ed25519.

🛡️ 4. Confinement de Sécurité Multi-Niveaux

Zero Egress au runtime : Confinement réseau matériel empêchant les scripts de hooks non surveillés d'exfiltrer des données.
Audit AST automatique : Analyse syntaxique de l'arbre syntaxique abstrait des manifestes et scripts en intégration continue pour détecter toute tentative de manipulation d'environnement.
Vérification multi-sources : Contrôle en temps réel de vulnérabilités et malwares via OSV.dev, CIRCL Hashlookup, MalwareBazaar, Sigstore Rekor et VirusTotal v3.

🏢 5. Intégration Entreprise Native

Postes durcis : Pipeline automatique de re-signature Authenticode locale post-extraction sous politiques de sécurité Windows Defender Application Control (WDAC) et AppLocker.
Environnements fermés (Air-Gap) : Prise en charge des proxies avec inspection TLS (PKI d'entreprise) et réécriture dynamique d'URLs vers des miroirs internes d'artefacts (Nexus, Artifactory).

2. Tableau Comparatif des Paradigmes

Dimension	Scoop (PowerShell)	Chocolatey	Homebrew	Nix	Spécification `erable`
Routage de binaires	Shims `.exe` / scripts `.ps1` (surcoût process 50ms)	`shimgen.exe` propriétaire / installateurs OS	Liens symboliques directs (`bin/`)	Liens symboliques vers `/nix/store`	Trampolines Universels Rust (0ms sur Unix via `exec`, ~1ms sous Windows avec préservation du répertoire réel)
Scripts compagnons (`npm`, `pip`)	Défaillances de résolution relative (`%~dp0`)	Géré par installeur Windows MSI	Géré par symlink Unix	Géré par store isolé	Préservation Native : Le trampoline cale le contexte de travail dans le dossier réel de l'application
Gestion de l'état / Config	`persist/` + jonctions NTFS (rompu par écritures atomiques)	Délégué aux installeurs MSI/InnoSetup (%APPDATA%)	Découplage (standards XDG/macOS)	Découplage (fichiers immuables)	*Découplage Total (Stateless)* : Respect strict et natif des normes XDG et `%APPDATA%`
Multiplateforme	Windows uniquement	Windows uniquement	macOS / Linux	macOS / Linux (Windows exp.)	Multiplateforme natif (Windows, Linux, macOS)
Moteur d'exécution	PowerShell (Windows)	C# / PowerShell	C++ / Bash / Ruby	Nix DSL / C++	Nushell (Bootstrap minimal sh/pwsh puis 100% `nu`)
Structure Manifestes	JSON monolithique	XML / PS1 (erable NuGet)	Nix Expressions / Ruby DSL	Nix Expressions	TOML modulaire (`parts/*.toml`) + scripts Nushell normalisés
Taille Client & Dépôts	Clones Git complets lourds (300 à 800 Mo)	Cache local NuGet	Clones Git complets (~1,2 Go)	Arbre store complet	Client ultra-léger : Index HTTP pré-compilé (~500 Ko) + téléchargement à la demande

3. Fondements Théoriques et Littérature Académique

L'architecture de erable s'appuie sur les principes formels issus de la recherche en systèmes de déploiement logiciel :

3.1 Immutabilité et Déploiement sans Effets de Bord

Référence : Eelco Dolstra (2006) — The Purely Functional Software Deployment Model.

Tout composant logiciel déployé par erable réside dans un répertoire immuable packages/<pkg>/<version>/.
Une mise à jour ne modifie jamais les binaires en place. Elle instancie la nouvelle version en parallèle et bascule atomiquement le pointeur actif dans le trampoline (.target), garantissant l'intégrité du système même en cas d'interruption brutale.

3.2 Gestion Transactionnelle et Rollback en $\mathcal{O}(1)$

Référence : Dolstra, Hemel, & Visser (2004) — Nix: A Safe and Flexible Software Deployment System (LISA '04).

L'activation et la désactivation de versions s'effectuent en temps constant $\mathcal{O}(1)$.
Les tests de validation post-installation (check_version et check_help) garantissent qu'en cas d'anomalie, le système restaure immédiatement la version antérieure sans résidu corrompu.

3.3 Séparation Code / Données

Référence : Alexander Larsson (2016) — Flatpak Architecture & Sandboxing System.

Séparation stricte entre les binaires en lecture seule et les états applicatifs persistants gérés par l'OS hôte selon la spécification XDG Base Directory.