Aller au contenu
Produits / Système d'exploitation

Un système d'exploitation contre lequel vous n'avez pas à lutter.

Un système fondé sur Linux, conçu pour les développeurs et les organisations qui veulent un environnement léger, transparent et très personnalisable, plutôt qu'un système généraliste chargé de décennies de réglages par défaut. Il est en conception et en développement initial, et il n'y a rien à télécharger pour l'instant.

01 : Le pari

Ubuntu a rendu Linux facile pour tout le monde. Nous faisons l'inverse.

Le Linux graphique est un problème déjà résolu. Ubuntu, Fedora, Mint, Zorin et Pop!_OS l'ont rendu accessible, ils l'ont bien fait, et il n'y a plus rien à gagner à le refaire. 0dyssey ne court pas après cette moitié du problème, et la concéder est ce qui fait du reste de cette page une affirmation plutôt qu'une vantardise.

La moitié que personne n'a prise, c'est la mise en place. Un environnement en mosaïque léger, avec l'outillage déjà choisi, doit encore être assemblé à la main, à partir de fichiers de configuration et d'une expérience Linux accumulée, par chaque personne qui en veut un. Ce coût est la cible. Supprimer la taxe de mise en place, pas la puissance.

Le terminal reste. C'est une fonctionnalité, pas l'ennemi, et un système conçu pour vous en tenir éloigné résout un autre problème pour une autre personne. Ce qui se trouve au-dessus de la base est construit à la main plutôt qu'hérité comme les réglages par défaut de quelqu'un d'autre avec un thème par-dessus.

02 : L'argument

Pourquoi en construire un.

Les systèmes d'exploitation modernes sont conçus pour le grand public, et ce n'est pas une insulte, c'est une contrainte de conception. Servir tout le monde, c'est livrer des réglages par défaut qui ne conviennent exactement à personne, traîner des décennies de compatibilité et cacher la machine derrière des couches difficiles à inspecter et plus difficiles encore à modifier.

Le résultat est familier à quiconque travaille au plus près de la machine : on passe son temps à s'adapter au système plutôt que l'inverse, et quand quelque chose se comporte étrangement, la réponse honnête est souvent qu'aucune des personnes qui y travaillent aujourd'hui ne sait pourquoi ce code est là.

Nous voulons les propriétés inverses. Un système où ce qui s'exécute au démarrage est une décision que quelqu'un a prise et peut expliquer, où les éléments dont vous ne voulez pas sont absents plutôt que désactivés, et où changer un comportement signifie changer un composant plutôt que le contourner de force.

Ce n'est pas un système d'exploitation généraliste, et il n'essaie pas de l'être. C'est un système pour celles et ceux qui préfèrent maîtriser la couche du dessous plutôt que négocier avec elle.

03 : Engagements de conception

Des décisions déjà prises.

Ce sont les contraintes auxquelles la construction est tenue. Elles sont énoncées au présent parce que les décisions sont réelles, même si le logiciel en est à ses débuts.

  • Modulaire dès la conception

    Les composants sont séparables, et ceux dont vous ne voulez pas sont absents plutôt qu'installés puis désactivés. Un système auquel on peut retirer des éléments est un système sur lequel on peut raisonner.

  • Transparent par défaut

    Ce qui se passe entre la mise sous tension et un shell utilisable est inspectable et documenté. Aucun comportement qui n'existe que comme folklore dans un fil de forum d'il y a six ans.

  • Sûr dès la conception

    La sécurité est traitée comme une propriété de construction : une surface plus réduite, des privilèges explicites, des réglages par défaut raisonnables. Pas un guide de durcissement publié après coup, que l'utilisateur devrait appliquer.

  • La performance comme contrainte

    Le poids est un échec de conception, pas une taxe à accepter. Ce qui est livré est ce qui est nécessaire, ce qui est le seul moyen fiable de rester rapide plutôt que de ne l'être que dans un benchmark.

  • Personnalisable sans lutte

    Changer le comportement du système, c'est modifier un composant par une voie prévue à cet effet, pas contourner un réglage par défaut qui supposait que vous n'en auriez jamais envie.

  • Pensé pour celles et ceux qui travaillent près de la machine

    Développeurs, spécialistes systèmes et organisations qui exploitent leur propre infrastructure. L'environnement est réglé pour ce travail, plutôt que rendu assez convivial pour tout le monde à son détriment.

04 : La pile

Ce qui est réellement construit, de la machine vers le haut.

Un système d'exploitation est un problème d'intégration avant d'être un problème de code. Voici l'ordre dans lequel l'intégration doit se faire.

C'est le plan de travail, pas un journal des modifications. Aucune de ces couches n'est terminée, et celles qui se trouvent plus bas dans la liste n'ont pas été commencées.

  1. Système de base

    La configuration du noyau, le chemin de démarrage et le plus petit ensemble d'espace utilisateur qui constitue une machine à laquelle on peut se connecter et se fier.

  2. Init et services

    Ce qui démarre, dans quel ordre et sous quelle autorité. La partie d'une distribution qui détermine si le système est lisible ou magique.

  3. Modèle de paquets et de mises à jour

    Comment les logiciels arrivent, comment ils sont vérifiés et comment une machine passe d'un état connu au suivant sans devenir un cas unique.

  4. Modèle de sécurité

    Les frontières de privilèges, les réglages par défaut et ce qu'expose une installation standard. Décidé en même temps que la base plutôt qu'ajouté par-dessus.

  5. Environnement de développement

    Chaînes d'outils, conteneurs et surface de travail quotidienne, traités comme une partie à part entière du système plutôt que comme quelque chose que l'utilisateur assemble ensuite.

  6. Intégration et ingénierie des versions

    Des builds reproductibles, des images, et la mécanique qui transforme un répertoire de décisions en quelque chose qu'une autre personne peut installer.

05 : La composition

Des couches éprouvées, composées.

Chaque couche sous la couche supérieure est un logiciel existant, choisi sur ses mérites et utilisé tel quel. La seule chose nouvelle est la couche du dessus, et c'est le périmètre honnête du travail.

Pas un fork, mais une composition soignée de couches éprouvées sur une base Void Linux. Chacune fait son travail et passe proprement la main à la suivante. Nommer un composant est une décision prise, pas l'affirmation que les pièces sont déjà assemblées.

base void linux, du noyau à l'expérience utilisateur
  • L4

    0dyssey

    la couche d'expérience utilisateur

    La seule couche à écrire ici plutôt qu'à adopter : des réglages par défaut choisis, une surface de contrôle pour les paramètres qui comptent, et la documentation qui transforme les quatre couches du dessous en un système qu'une autre personne peut prendre en main. Elle ne s'exécute pas encore, et c'est le seul palier de la liste qui n'existe pas déjà.

  • L3

    i3

    gestion des fenêtres

    En mosaïque, piloté au clavier, configuré dans un seul fichier lisible. Il reste un gestionnaire de fenêtres au lieu de devenir un environnement de bureau.

  • L2

    xbps

    paquets et mises à jour

    Comment les logiciels arrivent, et comment une machine passe d'un état connu au suivant, avec le même outillage pour un seul paquet et pour un système entier.

  • L1

    runit

    init et supervision

    Ce qui démarre, dans quel ordre, et ce qui le relance quand il s'arrête. Assez petit pour être lu de bout en bout, ce qui explique sa présence ici plutôt que celle d'un init plus volumineux.

  • L0

    Noyau Linux

    matériel et ordonnancement

    Pilotes, mémoire et ordonnancement des processus sous une seule autorité. Choisi pour des raisons banales : un large support matériel et un comportement déjà documenté en profondeur.

chaque couche passe proprement la main
06 : La fiche technique

La fiche technique.

Chaque ligne est une décision déjà prise, écrite simplement pour qu'on puisse en débattre plutôt que la deviner.

Cette fiche consigne des décisions, pas des mesures. Rien n'y a fait l'objet d'un benchmark, parce qu'il n'y a pas de build assez stable pour cela, et un chiffre publié maintenant serait un chiffre inventé maintenant. La ligne qui porterait normalement les chiffres dit précisément cela à la place.

  • Télémétrie

    Aucune, par décision

    Aucun chemin de remontée de données n'est intégré. Il n'y a rien à désactiver plus tard, parce que rien n'y entre au départ.

  • Source

    Open core

    Chaque couche dont il est composé est déjà ouverte, et la couche propre à ce projet est destinée à être publiée de la même façon. Le fonctionnement de la machine n'a pas vocation à être un secret commercial.

  • Lisibilité

    Une exigence, pas une préférence

    Ce qui démarre au démarrage de la machine, ce qu'un paquet installe et ce qu'un réglage par défaut suppose doivent pouvoir être lus par la personne qui utilise la machine. Un comportement dont personne ne peut rendre compte est un défaut, pas une bizarrerie.

Base
Void Linux
Noyau
Linux
Init
runit
Paquets
xbps
Gestionnaire de fenêtres
i3, en mosaïque
Couche UX
Sur mesure, non adoptée
Utilisateur visé
Développeurs et spécialistes systèmes
Télémétrie
Aucune
Chiffres mesurés
Pas encore mesurés
Build téléchargeable
Aucun pour l'instant
Statut
En développement
07 : Ce que ce n'est pas

Ce que nous ne construisons délibérément pas.

Un périmètre énoncé seulement en ambitions n'est pas un périmètre. Ce sont les lectures que nous voulons écarter dès maintenant plutôt que décevoir plus tard.

  • Pas un bureau généraliste qui prétend remplacer ce que la plupart des gens utilisent déjà sans souci.
  • Pas une reprise thématique d'une distribution existante avec notre nom sur le fond d'écran.
  • Pas un produit dont on tairait la date de lancement. Il n'y a pas de date à taire.
  • Pas un projet communautaire qui cherche des contributeurs alors qu'il n'a pas encore la capacité de les encadrer.
  • Pas quelque chose autour de quoi bâtir une infrastructure de production aujourd'hui, et nous dirons clairement quand cela changera.
08 : Ce qui existe aujourd'hui

Conception, décisions et code initial.

Cette section changera dès qu'il y aura quelque chose de réel à vous remettre.

Aucun build à télécharger

Il n'y a ni ISO, ni installateur, ni miroir de paquets, ni canal de publication, ni liste de préinscription. Ce qui existe, c'est l'architecture, les décisions ci-dessus et un développement initial mené sur cette base. Le travail est consigné au fil de l'eau, et cette écriture est la façon honnête de le suivre jusqu'à ce qu'il y ait un build.

Suivre les journaux de construction
09 : Journal de construction

Une entrée par période de travail, tenue à une forme fixe.

Le standard auquel le journal est écrit, arrêté avant qu'il ne contienne quoi que ce soit. La numérotation commencera à 001, chaque entrée portera le jour où le travail a eu lieu, et rien ne sera antidaté.

La numérotation est la garantie. Elle commence à 001 sans rien derrière, de sorte que ce journal ne peut pas se donner discrètement un passé qu'il n'a pas.

Aucune entrée publiée

Le journal n'a pas commencé. Il n'y a pas encore d'entrée 001, rien n'a été antidaté et aucune entrée d'exemple n'en tient lieu. 0dyssey est en développement, et la première entrée sera écrite quand un travail sera assez abouti pour être décrit avec exactitude, pas quand cette page aura besoin d'avoir quelque chose dedans.

Lire ce qui est publié

La forme d'une entrée

Fixée à l'avance, pour que le format soit arrêté avant que la première entrée ne le définisse discrètement. Chaque entrée répondra à ces quatre questions, dans cet ordre.

  1. Quel était l'objectif

    La chose précise que cette période de travail devait atteindre, énoncée avant que quoi que ce soit en soit revendiqué. Un objectif écrit après coup est un objectif toujours atteint.

  2. Ce qui est construit

    Uniquement ce qui fonctionne aujourd'hui, au passé, sans rien affirmer qu'un lecteur ne puisse vérifier à partir du travail lui-même. Pas de captures de maquettes, pas de théâtre de feuille de route.

  3. Ce qui est à moitié construit

    Les parties réellement inachevées, nommées plutôt que laissées pour acquises. Si deux choses sont à moitié construites, les deux sont nommées.

  4. Ce qui suit

    Le prochain travail concret et la raison pour laquelle il passe avant les autres. Aucune date n'y est attachée, car il n'y a pas de date à attacher.

10 : Séquence

Comment on arrive à un build que vous pouvez exécuter.

Des phases, pas des dates. Le repère se trouve sur la phase où le travail en est réellement aujourd'hui.

Aucune entrée ci-dessous ne porte de trimestre, parce qu'aucune n'en a. Quand une vraie date existera, elle sera imprimée ici et nulle part ailleurs avant.

  1. Fait

    L'architecture et les décisions ci-dessus

    Les engagements de conception, le modèle de modules et le périmètre, refus compris. De quoi construire dessus et de quoi en débattre.

  2. Maintenant

    Système de base et chemin de démarrage

    Le bas de la pile : configuration du noyau, démarrage et espace utilisateur minimal qui fait une machine sur laquelle on peut se connecter. C'est là que se trouve le travail.

  3. Ensuite

    Init, services, paquets et mises à jour

    Les couches qui décident si le système est lisible : ce qui démarre et pourquoi, comment les logiciels arrivent et comment une machine passe d'un état connu à un autre.

  4. Plus tard

    Une image qu'une autre personne peut installer

    Builds reproductibles et ingénierie des versions, le point où cette page cesse d'être un plan pour devenir un téléchargement.

11 : Le long terme

Le long terme.Un horizon, pas une capacité actuelle.

Aucune des trois n'existe, aucune n'a de date, et aucune n'est une phase ultérieure de la feuille de route ci-dessus. C'est la direction à laquelle la conception est tenue, imprimée ici pour que la feuille de route ne soit pas prise pour l'ensemble de l'ambition, ni l'ambition pour l'état du logiciel.

  1. Un système d'exploitation de développeur, pas un système généraliste

    Un système assez petit pour que la vitesse soit une propriété de sa taille plutôt qu'un exercice de réglage, avec la chaîne d'outils et la surface de travail quotidienne traitées comme faisant partie de lui plutôt que comme quelque chose que l'utilisateur assemble ensuite. Un outillage choisi pour la façon dont les développeurs travaillent réellement, et qui grandit avec le système au lieu de s'y accumuler.

  2. L'IA native, au niveau du système

    Intégrée au niveau du système plutôt que greffée comme une application : une machine qui automatise ce qu'elle peut, agit en votre nom et vous parle, en vous sollicitant, en expliquant et en posant des questions, au lieu de vous faire piloter chaque commande à la main. C'est le seul palier où le système d'exploitation et le reste de l'ingénierie forment un même problème. C'est aussi un sujet de recherche difficile, c'est pourquoi il est énoncé comme un cap à tenir, et rien de plus.

  3. Le pari fou : partir de zéro

    Construire le système à partir de zéro, et à terme jusqu'au noyau. Nommé à part à dessein : c'est une entreprise de plusieurs décennies plutôt que le prochain élément après les précédents, et la classer comme une entrée de feuille de route serait un mensonge sur son ampleur.

12 : Questions

Les questions que cette page soulève.

Les réponses sont données ici et dans la FAQ à partir d'une seule source, de sorte que les deux ne peuvent jamais se contredire. Quand la réponse honnête est que rien n'existe encore, c'est la réponse donnée.

Chaque réponse ci-dessous est écrite par rapport à l'état du travail aujourd'hui. Rien n'y décrit un logiciel que vous puissiez exécuter.

0dyssey est-il open source, et sous quelle licence ?

Les couches qu'il compose sont des logiciels libres existants et gardent leurs propres licences, quoi qu'on décide ici. La licence des parties écrites pour ce projet n'a pas été décidée : il n'y a donc rien à annoncer et rien à laisser entendre. Elle sera indiquée ici une fois choisie. Une licence citée aujourd'hui serait une position prise pour un site web, et non une décision prise sur le logiciel.

À qui s'adresse-t-il ?

Aux développeurs, aux spécialistes systèmes et aux organisations qui exploitent leur propre infrastructure : les personnes qui travaillent près de la machine et préfèrent maîtriser la couche du dessous plutôt que négocier avec elle. La moitié la plus utile de la réponse est à qui il ne s'adresse pas. Il ne s'agit pas de rendre Linux convivial pour des gens qui ne veulent pas d'un terminal. Ce problème est résolu, et d'autres distributions l'ont résolu : un bureau Linux graphique est réellement bon aujourd'hui, et en construire une version moins bonne ne servirait à personne. Le public visé ici a déjà choisi le terminal et veut que l'environnement autour cesse de coûter des jours d'assemblage.

Faut-il de l'expérience avec Linux ?

L'intention de conception est que la ligne de commande soit toujours là sans jamais être la seule porte d'entrée. L'aisance avec un terminal doit rendre le système plus rapide à utiliser, pas être le prix pour y entrer. Voyez-y un engagement auquel tenir le projet plutôt qu'une fonctionnalité sur laquelle planifier : la surface qui le rendrait vrai est conçue et non construite, et il n'y a aujourd'hui rien devant quoi s'asseoir pour tester cette affirmation.

Est-ce un simple habillage d'une distribution existante ?

Non. Void Linux en est la base, avec le noyau Linux en dessous, runit comme init, xbps pour les paquets et i3 comme gestionnaire de fenêtres en mosaïque. Ce sont des couches éprouvées, et les réécrire mal serait une perte de temps pour tout le monde. Ce n'est pas un fork, c'est une composition soignée : chaque couche fait son travail et passe proprement la main à la suivante. Ce qui est construit pour ce projet, c'est tout ce qui se trouve au-dessus : l'outillage, les réglages par défaut et la surface de travail, et c'est cette partie qui mérite d'être jugée. Les réglages d'un autre avec un thème par-dessus ne mériteraient pas d'être livrés.

De quel matériel aura-t-il besoin ?

Il n'y a pas encore de réponse, et tout chiffre imprimé ici serait inventé plutôt que mesuré. Bien fonctionner sur des machines modestes et anciennes est un objectif de conception, et il découle des mêmes décisions que le reste : ce qui est absent ne peut rien vous coûter. Mais une configuration requise est une mesure, rien n'est assez stable pour être mesuré, et un chiffre publié maintenant est un chiffre auquel un futur build serait tenu sans raison. Les configurations requises seront publiées une fois mesurées, et pas avant.

Quand puis-je l'essayer ?

Vous ne le pouvez pas. Il n'y a pas de build : ni ISO, ni installateur, ni miroir de paquets, ni canal de publication, ni numéro de version, ni liste de préinscription à rejoindre. Il n'y a pas non plus de date, ce qui signifie qu'aucune date n'est tenue secrète. Le travail est consigné au fil de l'eau, et suivre ces écrits est la façon honnête de suivre l'avancement réel plutôt qu'un compte à rebours marketing.

Qu'advient-il de mon installation actuelle ?

Rien, puisqu'il n'y a rien à installer. Quand il y aura une image, l'intention est qu'elle se comporte comme n'importe quelle autre installation Linux : un partitionnement ordinaire, un chargeur de démarrage ordinaire, un double démarrage ordinaire, et une documentation pour les configurations courantes plutôt qu'un chemin spécial que nous seuls comprenons. Rien de cela n'est une promesse sur laquelle planifier tant qu'une image n'existe pas et n'a pas été testée sur de vraies machines. Personne ne devrait repartitionner une machine qui fonctionne pour un logiciel sans build.

14 : Pour aller plus loin

Le raisonnement, en détail.

Les décisions ci-dessus sont énoncées ici et argumentées ailleurs. Ces textes montrent le travail.

15 : Suivre le projet

Regardez un système d'exploitation se construire à ciel ouvert.

Les décisions, les impasses et les réécritures sont consignées pendant qu'elles sont encore fraîches. Si vous voulez savoir quand il y aura quelque chose à exécuter, c'est là que ce sera dit en premier.

Lire les journaux de constructionNous parler de travaux système