Linutop OS 25 est basé sur Xubuntu 22.04 pour PC, il est dédié à l'affichage dynamique ou au kiosque sécurisé.

Linutop Kiosk Player d’Affichage Dynamique: permet de configurer simplement une « playlist » pour un affichage en plein écran (image, Gif, PDF, lien URL, page web, vidéo HD, musique), il est compatible avec le système de diffusion Linutop.tv et peut fonctionner avec ou sans réseau.

L’usage en entreprise d’un mini PC avec linutop OS permet de configurer rapidement un affichage dynamique. Il s’appuie sur la version légère Xubuntu sous l’environnement graphique ‘XFCE’, complété par VLC Media player et les outils Linutop.

Linutop Configuration panel: Une interface graphique pour faciliter la configuration du système : langue clavier et fuseau horaire, configuration écran, démarrage d’un VNC ou SSH en un clic, ou la sécurité qui permet de figer le système à chaque redémarrage pour minimiser sa maintenance.

Le système démarre automatiquement sur sa playlist en plein écran et permet de mettre en veille l'écran si nécessaire.

Avantages:

• Panneau de configuration graphique en français
• La version gratuite permet d’utiliser VLC avec les derniers accélérateurs matériel.
• Permet de construire un affichage dynamique local ou distant à moindre coût.
• Permet de configurer une borne sécurisé qui se remet à zéro à chaque redémarrage.

Principaux usages:

• Affichage dynamique : école, musée, hôtel, magasin, restaurants, mairie, usine, bureau.
• Kiosque Internet : Salle d'attente, bureau, école, borne d'accès Internet publique.
• Système pour usage multiple : Media player dédié, un poste en libre service et plus.

note:
Le version free de linutop OS 25 permet d'afficher en plein écran une vidéo de feu de bois ou un aquarium afin d'agrémenter votre confort visuel en fonction de la température.

NdM: le tutoriel ne semble pas encore avoir été mis à jour et mentionne encore les infos de la précédente version basée sur Ubuntu 18.04 (au lieu de Xubuntu 22.04 pour Linutop OS 25 selon l'annonce), cf configuration matérielle ou compatibilité matérielle. Idem pour la FAQ sur les différences entre les versions Free et Pro.

Je travaille depuis quelque temps sur Elpe, un projet qui vise à obtenir les bonnes propriétés de Nix/NixOS (les mises à jour atomiques, la reproductibilité), mais avec des paquets Ubuntu.

Le code : https://nest.pijul.com/pmeunier/elpe

L'idée est de définir des recettes de compilation en OCaml et de les envoyer à un backend Rust, qui se charge de les exécuter dans un conteneur sans réseau, en exposant uniquement le contexte nécessaire à la bonne exécution de la compilation. Les produits du build sont indexés par le contenu de la recette du build, et indexés une deuxième fois par le résultat : c'est ce deuxième hash qui est utilisé dans les dépendants du paquet, ce qui permet de construire un arbre de Merkle du système complet (et non seulement de ses sources), qui rend toute modification ultérieure facilement détectable.

De plus, le système de base provient des dépôts de paquet Debian ou Ubuntu. Cependant, tous les chemins sont hard-codés (comme dans Nix), ce qui permet de garantir la reproductibilité, au détriment toutefois du coût de mise à jour en termes d'espace et opérations disque.

Si le choix de Rust devient relativement consensuel par les temps qui courent, OCaml est plus surprenant. Après divers essais avec plusieurs langages, je l'ai choisi parce que c'est le seul langage avec à la fois :

• Une bonne approximation du système de types dont j'avais besoin: typage nominal et aussi structurel, entre autres.
• Un système de types relativement simple (pas de typeclasses ni de monades comme en Haskell, de borrow checkers comme en Rust ni de types dépendants comme en TypeScript).
• Du late binding, nécessaire pour exprimer des "overrides" et des "hooks", courants quand on veut compiler des choses (autoconf et make ont plein d'options de ce type, par exemple).
• Un compilateur ultra-rapide.
• Un bytecode, pour (dans le futur) contrôler aussi l'isolation du code de build de façon très légère.

La simplicité et l'expressivité d'OCaml sont bien adaptés à ce projet: les fonctions simples à concevoir y sont relativement claires à énoncer.

Pourquoi pas NixOS, me direz-vous ? En tant qu'utilisateur et contributeur depuis environ 10 ans, un certain nombre de problèmes plus ou moins récents m'ont motivé à explorer une alternative:

• En termes de gouvernance, la communauté a traversé dans la dernière année plusieurs crises de différentes tailles (Anduril, Devenv…). On pourrait y voir un signe de maturation ou au moins de croissance du projet, mais plusieurs éléments me permettent d'en douter, dont les réactions répétées de la fondation Nix, qui semble avoir beaucoup de mal à comprendre les messages pourtant clairs des contributeurs.

• Je vois aussi les choix de design imposés par les fondateurs du projet depuis quelques années comme un bien mauvais signe: les flakes (en 2020) étaient une première incarnation de cette tendance, et plus récemment la "distribution propriétaire" de Nix est clairement une mauvaise idée, alors que la qualité de code de Nix n'est pas au niveau où on l'attendrait et que le gros du projet repose depuis plusieurs années sur le travail pharaonique des contributeurs de Nixpkgs.

• On pourrait parler longtemps de la sécurité de Nix, qui me fait de plus en plus peur y compris pour mon usage personnel. Les process de gestion des rapports ne me conviennent pas, de même que l'opacité de certains choix techniques (les flags de compilation désactivés sur certaines plateformes, entre autres), souvent bien cachés dans les entrailles de Nixpkgs.

• Enfin, le langage trop complexe à utiliser (principalement par manque de typage statique et de messages d'erreurs pertinents) rend Nix difficile à utiliser au sein d'une organisation d'une taille importante, et encourage les comportements peu inclusifs (éviter d'écrire de la doc, inventer des casse-têtes pour faire des choses simples…). Je suis bien sûr conscient que des entreprises (comme Anduril) et des ONGs (comme Médecins Sans Frontières) l'utilisent, mais je ne pense pas que ce soit généralisable aux situations où j'aimerais voir ce genre de projet utilisé.