Work Mode
Environnement principal de travail, de fichiers, de développement et d’administration locale.
En développement
ACTIF 03/34 · AJANOS
AjanOS
Le système d’exploitation terrain de JanaCore
Transformer une machine qualifiée par BootHAL en environnement local directement utilisable pour travailler, jouer et isoler des charges expérimentales.
AjanOS réunit sous l’autorité d’un même système un environnement de travail, un profil gaming et une sandbox d’expérimentation. Il exploite le handoff BootHAL pour partir d’une machine déjà découverte, décrite et qualifiée.
Le problème
Travail, jeu et expérimentation ne devraient pas partager les mêmes risques
Les systèmes généralistes font souvent cohabiter les usages quotidiens, les jeux, les outils de développement et les charges expérimentales dans le même environnement principal.
Une expérimentation agressive ou non déterministe peut perturber les fichiers, services et processus utilisés pour travailler.
Les sessions gaming conservent des services et des priorités qui ne correspondent pas toujours aux besoins du premier plan.
Le système redécouvre parfois des informations matérielles déjà établies pendant le démarrage, au risque de multiplier les divergences et les erreurs.
La réponse AjanOSMODE 01 MODE 02 MODE 03
Trois régimes d’usage, un système commun et des frontières explicites
AjanOS organise les usages de la machine autour de trois profils d’exécution gouvernés par le même noyau. Work Mode reste la référence, Game Mode adapte la machine à la session de jeu, et VM Sandbox isole les charges qui ne doivent pas obtenir l’autorité sur le système principal.
Game Mode
Session gaming de premier plan avec contrôles, affichage, audio et ressources adaptées.
VM Sandbox
Espace isolé, borné, observable et réinitialisable pour les charges expérimentales.
Les trois modes ne sont pas trois OS distincts. Work Mode reste prioritaire ; Game Mode ne doit pas altérer les invariants du système ; la VM Sandbox ne doit pas exposer l’état du Work Mode.
Work ModeUSERLAND DÉVELOPPEMENT SYSTÈME
L’environnement principal pour travailler et développer
Un espace utilisateur propre
Bibliothèque système minimale, ABI de syscalls, shell interactif, chargeur ELF64, liaison dynamique et exécution utilisateur séparée du kernel.
Rust et Python
Un environnement local destiné à écrire, compiler, lancer et tester des outils sans dépendre d’un OS hôte tiers pour son identité principale.
Processus et fichiers
Gestion des processus, du stockage, des fichiers de travail, des périphériques et des services nécessaires à un usage quotidien progressif.
Application ou outil
Travail, développement, administration locale
Travail, développement, administration locale
↓
Userland AjanOS
Shell, bibliothèque système, ELF, runtimes
Shell, bibliothèque système, ELF, runtimes
↓
ABI et services
Syscalls, processus, fichiers, affichage, entrées
Syscalls, processus, fichiers, affichage, entrées
↓
Kernel AjanOS
Mémoire, interruptions, scheduling, isolation
Mémoire, interruptions, scheduling, isolation
Game Mode
Une session gaming distincte du système de travail
Game Mode constitue un profil secondaire. Il peut privilégier l’affichage plein écran, les contrôles physiques, l’audio, le rendu graphique et les ressources du premier plan, puis revenir explicitement vers Work Mode.
Transition contrôlée depuis Work Mode et retour explicite après la session.
Prise en charge des gamepads et des contrôles propres aux consoles de jeux portables.
Gestion ciblée de la mémoire graphique partagée des APU.
Politique de scheduling orientée vers la charge de premier plan.
Affichage, audio et ressources adaptés au profil gaming.
Qualification progressive par une charge de jeu réelle, notamment Vanguard-Mobile.
Console de jeux portable
Une première validation sur un facteur de forme exigeant
La plateforme initiale de validation est une console de jeux portable équipée d’un APU, associant processeur, GPU intégré, contrôles physiques et mémoire graphique partagée. Ce facteur de forme permet d’éprouver simultanément le démarrage, les entrées, l’affichage, le stockage, l’audio, la gestion des ressources et les transitions entre travail et jeu.
Le modèle précis de la machine reste documenté dans les dossiers techniques et les preuves internes. La fiche publique présente la catégorie matérielle et les capacités visées, pas une marque commerciale.
VM SandboxISOLATION RÉVERSIBILITÉ AUTORITÉ
Exécuter les charges expérimentales sans leur céder le système
Les agents, fuzzers, runtimes expérimentaux, logiciels non fiables et codes générés doivent pouvoir être testés sans obtenir un accès direct au kernel, aux périphériques physiques ou à l’environnement de travail.
Accès bornés
Mémoire dédiée, périphériques virtualisés, fichiers filtrés et réseau désactivé ou strictement contrôlé.
Environnement jetable
Création, suspension, arrêt, réinitialisation, snapshot, rollback et suppression selon le profil autorisé.
Kernel maître
Le système principal conserve l’autorité sur les quotas, les ressources, les périphériques exposés et la durée d’exécution.
Une charge non déterministe peut proposer, calculer ou expérimenter ; elle ne gouverne ni le kernel, ni les services essentiels, ni les fichiers du Work Mode.
Intégration BootHAL
Une machine déjà découverte, décrite et qualifiée
BootHAL intervient avant AjanOS. Il découvre la plateforme, établit son identité, organise les informations matérielles et transmet un handoff structuré. AjanOS valide ce handoff puis exploite les blocs disponibles pour initialiser le système.
Silicium et plateforme
Machine physique
Machine physique
↓
BootHAL
Découverte, qualification, fingerprint, handoff
Découverte, qualification, fingerprint, handoff
↓
AjanOS
Work Mode, Game Mode, VM Sandbox
Work Mode, Game Mode, VM Sandbox
↓
Applications et charges
Usage local, gaming et expérimentation isolée
Usage local, gaming et expérimentation isolée
Topologie CPU et mémoire.
Tables système et périphériques PCI.
Stockage, USB et contrôleurs disponibles.
Affichage et mémoire graphique.
Fingerprint et profil de machine.
Niveau de qualité et confiance des blocs reçus.
Réutilisation du handoff
Éviter les redécouvertes matérielles inutiles
Lorsqu’une information a déjà été calculée et validée par BootHAL, AjanOS peut la réutiliser directement. Le contexte xHCI, par exemple, peut être construit à partir des bases de registres transmises dans le handoff plutôt que par un nouveau parcours PCI complet.
Moins de logique matérielle dupliquée entre bootloader et OS.
Moins de divergences entre deux interprétations de la même plateforme.
Réduction des erreurs de redécouverte et des heuristiques contradictoires.
Chemin plus direct vers l’initialisation des périphériques.
Portabilité
Étendre le système par qualification des machines
AjanOS n’est pas limité à une console précise. BootHAL fournit la base de connaissance commune, puis chaque nouvelle plateforme fait l’objet d’un bring-up et d’une qualification fonctionnelle.
01
Qualifier la machine
Boot, fingerprint, handoff et blocs matériels nécessaires.
02
Activer le système
Mémoire, affichage, entrées, stockage, USB et userland.
03
Valider les modes
Work Mode, Game Mode, Sandbox et transitions.
04
Fermer le périmètre
Version, fonctions, limites, support et maintenance.
AjanBus et Router
Relier les composants système sans les fusionner
AjanBus et le Router organisent les échanges entre les modules locaux : affichage, entrées, audio, processus, fichiers, services du userland et transitions de mode. Ils structurent la communication système ; ils ne constituent pas une Fabric de calcul distribué.
Display · Input · Audio
Périphériques et interaction utilisateur
Périphériques et interaction utilisateur
↓
AjanBus + Router
Messages, destinations et séparation des responsabilités
Messages, destinations et séparation des responsabilités
↓
Process · Files · Modes
Services, état et transitions contrôlées
Services, état et transitions contrôlées
Fonctions principales01 02 03 04 05 06 07 08 09 10
Du handoff BootHAL à l’environnement utilisateur
Handoff
Vérifier l’intégrité, la qualité et les blocs matériels transmis.
Initialisation
CPU, mémoire, interruptions, timers, affichage, entrées, stockage et USB.
Processus
Création, scheduling, transitions privilégiées, suivi et terminaison.
Userland
ABI, syscalls, bibliothèque minimale, shell, ELF et runtimes compatibles.
Fichiers
Arborescence, volumes, accès utilisateur et filtrage sandbox.
Affichage et entrées
Framebuffer, clavier, gamepad, contrôles spécifiques et compositor.
Ressources graphiques
Mémoire partagée, allocations contrôlées et adaptation au mode actif.
Transitions de mode
Work vers Game, retour Work, création et destruction de Sandbox.
Isolation
Mémoire dédiée, périphériques virtuels, fichiers filtrés et quotas.
Observabilité
État des services, processus, modes, ressources, erreurs et décisions.
Ce que l’utilisateur obtient
Une continuité maîtrisée entre machine, système et usages
Une machine connue avant l’entrée dans le système.
Un environnement principal qui reste la référence stable.
Un passage contrôlé vers le jeu sans second OS.
Une zone d’expérimentation jetable et réversible.
Une continuité entre développement, tests et usage local.
Une adaptation progressive à de nouvelles machines qualifiées.
Une expérience système délivrée avec sa couche d’entrée BootHAL.
Des frontières explicites entre code utilisateur, services et kernel.
Cas d’usage
Où AjanOS apporte de la valeur
| Contexte | Apport d’AjanOS |
|---|---|
| Station de développement | Environnement Rust/Python, shell, fichiers et outils locaux. |
| Console de jeux portable | Work Mode et Game Mode dans le même système. |
| Contrôles gaming intégrés | Gamepad, boutons physiques et gestion des entrées propres au facteur de forme. |
| Expérimentation logicielle | Exécution isolée dans une sandbox jetable. |
| Code généré | Accès bornés, observation et réversibilité. |
| Développement système | Kernel, userland et interfaces maîtrisées. |
| Usage hors ligne | Environnement local sans dépendance à un OS hôte. |
| Matériel qualifié BootHAL | Réutilisation du handoff et du profil machine. |
| Programme matériel dédié | Pile BootHAL × AjanOS qualifiée sur un parc défini. |
| Gaming JanaCore | Qualification progressive par Vanguard-Mobile. |
| Charge non déterministe | Isolation du système principal et contrôle des ressources. |
Ce qu’AjanOS n’est pasDISTRIBUTION AUTORITÉ MUTATION BASE INFRASTRUCTURE FABRIC PRIORITÉ COMPATIBILITÉ
Des frontières fonctionnelles nettes
Pas un OS distribué seul
AjanOS est fourni exclusivement dans la solution BootHAL × AjanOS.
Pas un OS piloté par une IA
Les modèles et agents peuvent être des charges ; ils ne gouvernent ni le kernel ni les services principaux.
Pas un runtime auto-modifiant
Les composants expérimentaux ne peuvent pas réécrire silencieusement l’architecture du système.
Pas une distribution Linux personnalisée
AjanOS possède son propre kernel, son userland et sa chaîne système.
Pas un OS de calcul distribué
AjanOS vise l’usage terrain, le travail local, le gaming et l’isolation d’expérimentations.
Pas NicoFabricOS
NicoFabricOS gouverne une Fabric d’exécution ; AjanOS fournit l’environnement local de la machine.
Pas uniquement un OS gaming
Game Mode reste secondaire ; Work Mode constitue le centre du produit.
Pas une promesse universelle
Chaque machine et chaque fonction doivent être prises en charge et qualifiées.
DistributionUSAGE PRIVÉ ENTREPRISE INSTITUTION
AjanOS est délivré dans la solution BootHAL × AjanOS
La couche d’entrée machine, la qualification matérielle, le système, la documentation, la maintenance et la formation éventuelle forment un ensemble cohérent. Aucune licence autonome AjanOS n’est proposée.
Solution intégrée
Mise à disposition dans le cadre du bundle, sur matériel et fonctions explicitement qualifiés.
Parc et intégration
Diagnostic, qualification matérielle, adaptations, support, maintenance et licence de la solution complète.
Périmètre encadré
Solution associée à une formation complète, des responsabilités identifiées et des conditions d’exploitation définies.
Déploiement
Qualifier la pile de bout en bout
01
Diagnostic matériel
Identifier firmware, CPU, GPU, mémoire, stockage, contrôleurs, affichage, entrées et audio.
02
Qualification BootHAL
Valider le démarrage, le fingerprint, le handoff, son intégrité et sa répétabilité.
03
Bring-up AjanOS
Activer kernel, mémoire, affichage, entrées, stockage, USB, processus et userland.
04
Validation des modes
Tester Work Mode, Game Mode, Sandbox, transitions, stabilité et reprise.
05
Délivrance
Fournir une version et un périmètre matériel explicitement qualifiés.
Questions fréquentes
Comprendre le périmètre d’AjanOS
AjanOS peut-il être installé sans BootHAL ?
AjanOS est conçu comme consommateur natif de BootHAL et n’est pas distribué séparément. La voie normale est la solution BootHAL × AjanOS.
AjanOS est-il réservé à une seule console de jeux portable ?
Non. Une console de jeux portable constitue la première catégorie de plateforme validée, mais la cible est une portabilité progressive vers d’autres machines qualifiées par BootHAL.
Toute machine prise en charge par BootHAL est-elle immédiatement compatible ?
Non. Le handoff facilite l’intégration, mais l’affichage, l’audio, le GPU, les contrôles et les autres fonctions doivent encore être qualifiés pour AjanOS.
Le Game Mode remplace-t-il Work Mode ?
Non. Work Mode demeure le mode principal. Game Mode est un profil secondaire avec une transition et un retour contrôlés.
Faut-il redémarrer pour jouer ?
La cible architecturale est un passage entre Work Mode et Game Mode à l’intérieur d’AjanOS, sans lancer un second OS.
AjanOS peut-il lancer toutes les applications Linux ou Windows ?
La compatibilité générale n’est pas promise. AjanOS possède son propre userland et nécessite des applications compatibles, des ports ou des couches dédiées.
Peut-il exécuter du Rust et Python ?
Work Mode est conçu autour du développement Rust. Une intégration Python est prévue dans l’architecture du userland ; son niveau réel dépend de la version qualifiée livrée.
À quoi sert la VM Sandbox ?
À exécuter des agents, fuzzers, runtimes expérimentaux ou du code potentiellement instable sans leur donner un accès direct au système principal.
Une charge sandbox peut-elle accéder à tous les fichiers ou au réseau ?
Non. Les fichiers doivent être filtrés et le réseau peut être désactivé ou strictement borné selon le profil autorisé.
AjanOS est-il un concurrent de NicoFabricOS ?
Non. AjanOS fournit l’environnement terrain local ; NicoFabricOS gouverne une Fabric d’exécution destinée aux charges de calcul.
AjanOS est-il disponible seul ?
Non. Il est mis à disposition uniquement dans la solution BootHAL × AjanOS.
Positionnement final
AjanOS est le système d’exploitation terrain de JanaCore. Consommateur natif du handoff BootHAL, il transforme une machine qualifiée en environnement local structuré autour de trois régimes complémentaires : Work Mode pour l’usage principal et le développement, Game Mode pour les sessions gaming, et VM Sandbox pour l’exécution isolée de charges expérimentales. Livré exclusivement avec BootHAL, il établit une continuité maîtrisée entre la connaissance de la machine, le système, l’utilisateur et les logiciels exécutés.
Travailler. Jouer. Expérimenter sans exposer le système.
Une machine qualifiée, trois régimes d’usage
La solution BootHAL × AjanOS associe l’entrée machine, le système terrain, le périmètre matériel, la délivrance et le support.
Découvrir la solution BootHAL × AjanOS