The First Linux Desktop Written by an AI

SYNTHÈSE STRUCTURÉE

Le projet Starling : une prouesse technique à relativiser

Starling est un environnement de bureau complet pour Linux, sélectionnable depuis l’écran de connexion, capable de faire tourner Chrome, Slack et Zoom. Il a été écrit par une seule personne en six mois, avec 335 000 lignes de code. L’intervenant précise d’emblée : « Je ne juge pas ce projet positivement, mais pas pour la raison que vous attendez. » La prouesse est réelle, mais elle doit être comprise dans ses limites réelles.

Ce qui a réellement été écrit : des traducteurs, pas un compositeur

Contrairement à ce que l’on pourrait penser, Starling n’a pas écrit un compositeur Wayland. L’auteur le dit lui-même : le compositeur est le moteur Flutter. Ce qui a été écrit à la main est un serveur de protocole, quelques milliers de lignes de C qui parlent le protocole filaire Wayland et transmettent les surfaces clientes à l’arbre de widgets de Flutter. L’intervenant insiste : « Ils sont des traducteurs, pas des compositeurs. » Tout le travail lourd — scène graphique, layout, composition GPU, hit testing, animations synchronisées au taux de rafraîchissement, pile de texte — a été hérité, pas écrit.

La répartition réelle des lignes de code

Sur les 335 000 lignes totales, 273 000 sont un port de Flutter de Dart vers Swift, soit 82 % du projet. L’intervenant souligne que cela « réduit la prouesse à sa juste taille, mais explique aussi comment cela a été possible en six mois ». Le bureau lui-même, ses serveurs de protocole et ses applications, ne représentent que 62 000 lignes.

La preuve d’une intervention humaine : le fichier IME_bridge.c

L’intervenant, qui pensait initialement que l’implication humaine était minimale, a été contredit par un fichier précis : IME_bridge.c, un pont vers Fcitx5 (gestion des saisies asiatiques), de 506 lignes. On y trouve trois éléments qui ne sortent pas d’un prompt :

• Un appel système brut fait à la main, avec un commentaire expliquant pourquoi la fonction standard de la bibliothèque propagerait le changement à tous les threads, alors qu’ici il faut baisser les privilèges sur un seul thread (le shell tourne en root pour posséder l’affichage, mais le bus système refuse les connexions entre utilisateurs différents).
• L’envoi asynchrone de l’événement clavier, avec un commentaire explicite : « La boucle d’événements de l’affichage ne doit jamais bloquer. »
• Un commentaire expliquant que la méthode de saisie chinoise Pinyin envoie parfois le texte en composition via un signal et laisse l’autre champ vide, et qu’il ne faut donc pas écraser ce champ en cours de composition.

L’intervenant conclut : « C’est un bug que quelqu’un a vu se produire sur un écran réel, avec un vrai utilisateur qui écrivait en chinois. Ce n’est pas quelque chose qu’un modèle écrit à froid. »

La vision de construction : une idée architecturale réelle

Starling repose sur une idée forte : un environnement de bureau et un framework graphique font structurellement le même travail. Tous deux maintiennent une scène, décident du placement des éléments, routent les entrées, composent sur le GPU et animent. L’auteur du projet le formule ainsi : « Une fenêtre n’est qu’un très grand widget dont les pixels viennent d’un autre processus. » Cette idée a des conséquences élégantes : le tiling devient un layout, Mission Control devient une grille animée, les espaces virtuels deviennent une page view, et le verre du dock devient un shader sur un sous-arbre. Rien de tout cela n’a été implémenté : cela découle de l’architecture.

La vision d’interaction : un vide total

Là où Starling échoue, c’est sur la vision de l’interaction et de la culture. L’intervenant liste : barre de menu en haut, dock en verre en bas, Mission Control, Spaces, un gestionnaire de fichiers entre Finder et Nautilus. Le problème n’est pas la copie, mais le fait que l’auteur l’admet sans s’en rendre compte. La phrase clé du site : « Tout ce que vous voyez découle d’une seule décision sur la façon d’assembler un bureau. » L’intervenant commente : « Toute l’expérience utilisateur est un sous-produit. Personne ne s’est assis pour décider que le dock devait être là. »

L’explication mécanique de la sensation d’uniformité

L’intervenant explique que lorsque l’humain ne prend pas une décision, le modèle la prend à sa place. Et un modèle, sans contrainte forte, produit le mode statistique de ses données d’entraînement. Le médian de l’expression « environnement de bureau » sur 20 ans d’internet, c’est macOS, avec GNOME comme second attracteur. L’intervenant précise : « La sensation d’uniformité que vous ressentez est littéralement la variance qui manque. C’est le son d’un système où personne n’a jamais dit non. »

La contradiction centrale : le projet se réfute lui-même

Le site affirme que « la contrainte du développement de bureau Linux n’a jamais été l’imagination, ni le goût, mais le travail. Et le travail vient de devenir bon marché. » L’intervenant retourne cette phrase : si le goût et l’imagination n’avaient jamais été une contrainte, alors supprimer le travail aurait dû produire quelque chose de jamais vu. Or, le résultat est macOS. « Cette phrase est réfutée par le projet qui la contient. Le travail est devenu bon marché. Le goût, non. »

La résolution de décision : le concept central

L’intervenant introduit une distinction précise entre un compilateur et un modèle : un compilateur est déterministe et préserve le sens, il traduit vos décisions. Un modèle en prend des milliers, en dessous du niveau où vous regardez. La question n’est donc pas « outil ou auteur », mais « à quelle résolution la prise de décision humaine s’arrête-t-elle ? » Dans Starling, cette résolution est très haute en altitude (l’architecture : Flutter comme base, Swift au lieu de Dart pour éviter le garbage collector qui ferait tomber une frame pendant un drag, DRM et KMS directement) mais très grossière en grain. En dessous de ce niveau, le mode statistique prend le relais.

Le coût de maintenance : le vrai problème

L’intervenant souligne que le coût du logiciel n’a jamais été l’écriture, mais la compréhension, la maintenance, la chasse aux bugs, la revue, l’intégration de nouveaux contributeurs. Avec 273 000 lignes de port manuel de Flutter en Swift, il pose des questions légitimes : qui comprend la couche de rendu au bug numéro 500 ? Qui rebase ces lignes quand Flutter upstream bouge ? Un contributeur externe, que peut-il faire ? « Le coût de génération s’est effondré. Le coût de compréhension est identique à ce qu’il était il y a 30 ans. »

Le détail révélateur : la dépendance à systemd

L’intervenant note que le pont de méthode de saisie inclut la bibliothèque systemd. Un bureau neuf de 2026 naît déjà soudé à cette dépendance, parce que c’était le motif le plus représenté dans les données d’entraînement. « Le mode statistique décidant à votre place. »

L’histoire des bureaux Linux : des refus fondateurs

L’intervenant rappelle que chaque environnement Linux majeur est né d’un refus : Enlightenment a refusé la retenue, GNOME est né d’un refus sur une licence, KDE a refusé l’idée qu’Unix devait être laid, les tiling window managers ont