Les questions à poser en premier.

Des ingénieurs, directement. La personne du premier appel est celle qui écrit l'architecture, livre le code et remet le système. Un responsable unique : pas de chargé de compte qui relaie les messages, et rien de perdu dans la traduction entre la personne qui a compris le problème et celle qui a écrit le code. Quand une partie de la réalisation demande réellement un spécialiste, cette personne est nommée pendant le cadrage et travaille sur cette partie, le même responsable restant garant du résultat.

Oui, et le mécanisme est précis plutôt qu'un espoir. Pour les réalisations plus importantes, des ingénieurs rejoignent le projet : nommés pendant le cadrage, limités à ses exigences, et soumis au même accord de confidentialité et aux mêmes règles d'accès que tous les autres. Ils ne sont pas tirés d'un vivier permanent et ne sont pas conservés ensuite. Une seule personne reste responsable de l'architecture et du résultat tout du long : le travail passe donc à l'échelle sans la taxe de coordination ni la perte à la traduction qu'introduit une équipe permanente.

La réponse est une mesure d'atténuation, pas une promesse rassurante. L'infrastructure tourne dans vos comptes. Le code source vit dans vos dépôts. Les décisions sont consignées à mesure qu'elles sont prises, ce qui est l'un des huit principes de fonctionnement précisément pour cette raison. Rien d'essentiel ne repose dans une seule tête : un autre ingénieur peut donc reprendre le système sans négociation de passation.

Parfois, et jamais discrètement. Il n'y a ni externalisation, ni passage de relais à une agence, ni intermédiation de place de marché. Quand une réalisation demande réellement un spécialiste, cette personne est nommée pendant le cadrage, approuvée par vous avant de commencer, et limitée à cette partie du projet, sous le même accord de confidentialité et les mêmes règles d'accès que tous les autres. Un responsable unique reste garant de l'architecture, de l'intégration et du résultat : vous savez donc toujours qui fait quoi et qui en répond.

L'accès suit le moindre privilège et est limité au travail en cours. Les identifiants restent dans votre coffre de secrets, jamais dans le code source ni dans un fil de discussion. La sécurité est le point de départ, pas une étape de durcissement ajoutée à la fin. Vous êtes propriétaire du code et de la propriété intellectuelle produits dans le cadre de la mission, et un accord de confidentialité peut être signé avant que le moindre détail soit discuté.

Le problème tel qu'il est compris, les contraintes dans lesquelles il doit fonctionner, ce qui sera construit et ce qui ne le sera pas, la séquence des étapes et ce qui compte comme terminé pour chacune. Il nomme les hypothèses dont il dépend, car une hypothèse que personne n'a écrite est ce qui fait changer le chiffre plus tard. Rien n'est facturé tant que ce document n'est pas convenu, et si le travail de cadrage montre que ce n'est pas la bonne entreprise qui le tient, c'est ce que dit le document.

Oui, avant que le moindre détail soit discuté. Envoyez le vôtre : il est relu et signé, ou demandez-en un réciproque et il vous est fourni. Rien concernant une mission, un système ou une entreprise n'est publié, cité par écrit ou utilisé comme exemple sans autorisation écrite, et cela vaut qu'un accord de confidentialité existe ou non.

Au moindre privilège, limités au travail en cours et bornés dans le temps quand la plateforme le permet. Les identifiants restent dans votre coffre de secrets : jamais dans le code source, jamais dans un fil de discussion, jamais dans un ticket. L'accès est demandé système par système plutôt qu'accordé largement au départ, et il est rendu à la fin de la mission. L'infrastructure tourne dans vos comptes tout du long : révoquer l'accès est donc quelque chose que vous pouvez faire sans demander.

Le code source dans vos dépôts, l'infrastructure dans vos comptes, et le raisonnement consigné au fil du travail plutôt que reconstitué à la fin. Cela signifie des notes d'architecture, les décisions et les alternatives écartées, des runbooks pour ce qui doit être exploité, et les limites connues. Le critère est de savoir si un ingénieur qui n'a pas participé à la réalisation peut reprendre le système sans négociation de passation.

Oui, et c'est souvent la meilleure forme. Cela peut vouloir dire prendre en charge un composant de bout en bout pendant que votre équipe garde le reste, travailler dans vos dépôts et votre processus de revue, ou prendre la partie de la pile que votre équipe n'a pas la disponibilité d'aborder. Le document de cadrage précise quelle frontière s'applique, car une frontière floue entre deux équipes est la façon la plus sûre de perdre un mois.

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.

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.

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.

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.

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.

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.

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.