Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Sortie de OpenProject 17.0

OpenProject est un outil de collaboration et de gestion de projet polyvalent. Il est axé sur la souveraineté et la confidentialité des données. La version 17.0 apporte notamment l'édition collaborative de documents en temps réel.

Logo OpenProject

Sommaire

Côté produit

OpenProject est une plateforme depuis laquelle les parties tenantes d'un projet peuvent se coordonner et collaborer. Les projets sont découpés en tâches appelées lots de travaux et organisées hiérarchiquement ou en séquence, puis planifiées. Le suivi se fait par la mise à jour du statut et des propriétés de chaque lot de travaux, de sa création jusqu'à sa réalisation.

De nombreux modules destinés à la collaboration et au suivi sont disponibles :

  • diagramme de Gantt : visualiser et organiser les lots de travaux chronologiquement ;
  • tableaux : créer des tableaux Kanban ou Scrum pour gérer et visualiser les lots de travaux ;
  • gestion des réunions : planifier des réunions et leur contenu et enregistrer les résultats ;
  • temps et de coûts : faire le suivi du temps passé sur chaque lot de travaux et des coûts associés ;
  • wiki et documents : gérer sa base de connaissance ;
  • etc…

Il peut aussi s'interfacer avec d'autres logiciels :

  • GitLab et GitHub pour lier Merge Requests et Pull Requests aux lots de travaux associées ;
  • Nextcloud pour stocker et éditer les documents liés au projet ;
  • authentification unifiée (OAuth, OpenID, LDAP, SAML, SCIM).

Côté technique

OpenProject est développé en Ruby et JavaScript en utilisant Ruby on Rails. Il est sous licence GPLv3. Il est basé sur un fork de Redmine.

Les sorties se font en général au rythme d'une par mois.

Deux options sont possibles pour utiliser OpenProject :

  • l'héberger sur site, grâce à une installation via paquets DEB/RPM, images Docker ou Helm Charts ;
  • utiliser le service Cloud fourni par OpenProject, le produit est alors hébergé en Europe chez Scaleway (Paris) ou Amazon (Francfort).

Le prix et les fonctionnalités sont les mêmes, et il est possible de passer d'un type d'hébergement à l'autre facilement.

Modèle économique

OpenProject propose plusieurs éditions :

  • L'édition community est gratuite et le support se fait via des remontées de bugs ou des demandes de fonctionnalité directement sur notre instance OpenProject. L'hébergement est alors sur site.
  • Les éditions Enterprise (Basic, Professional, Premium et Corporate) sont payantes via un abonnement récurrent et offrent un support plus étendu et des fonctionnalités supplémentaires. L'hébergement est au choix sur site ou sur nos serveurs.

Il est possible de tester la version Enterprise Premium pendant 14 jours.

Apports de la version 17.0

La version 17.0.0 a été publiée mercredi 14 janvier 2026.

Collaboration en temps réel

Le module Documents a été repensé pour inclure de la collaboration en temps réel. Les équipes peuvent maintenant éditer des documents en même temps et voir les changements de chacun au fur et à mesure, directement dans OpenProject.

capture d'écran montrant un document édité par 3 utilisateurs en même temps

Cela facilite l'écriture à plusieurs de concepts, de spécifications, de contrats ou de documents de planification tout en restant étroitement connectés au projet. Les documents peuvent référencer et lier des lots de travaux existants.

Ce nouveau module Documents se base sur BlockNote, un éditeur de texte open source moderne aussi utilisé dans d'autres initiatives comme openDesk et LaSuite.

Améliorations du module Réunions

Ces fonctionnalités ont été ajoutées :

  • mode brouillon pour préparer collaborativement l'ordre du jour avant de le communiquer aux participants ;
  • mode présentation pour dérouler la réunion point par point ;
  • possibilité d'ajouter plusieurs résultat à un même point, pour clarifier les décisions prises et les prochaines étapes ;
  • abonnements iCal pour voir les réunions dans les calendriers personnels.

capture d'écran d'une réunion avec un lot de travaux à l'ordre du jour et deux résultats associés

Page d'accueil du projet repensée et sélection de modèle améliorée

L'interface de la page d'accueil d'un projet est désormais divisée en deux parties : « Vue d'ensemble ( Overview ) » et « Tableau de bord ( Dashboard ) ». Les équipes peuvent ainsi appréhender rapidement les informations générales sur le projet ainsi que les détails opérationnels.

deux captures d'écran de la page d'accueil d'un projet. Celle de gauche montre l'onglet vue d'ensemble, celle de droite l'onglet tableau de bord

La création de projet bénéficie d'une sélection de modèle améliorée rendant la création de nouveaux projets plus facile, notamment pour les utilisateurs sans connaissances techniques approfondies. Ces modifications préparent le terrain pour un futur assistant de création de projet en plusieurs étapes.

capture d'écran de la création d'un nouveau projet à l'étape du choix du modèle de projet à utiliser

Gestion des projets aux niveaux programmes et portefeuilles

Les projets peuvent être regroupés en programmes, tandis que les portefeuilles offrent une vue d'ensemble de toutes les initiatives en cours. Ceci est particulièrement précieux pour les bureaux de gestion de projet (PMO), les organisations du secteur public et les équipes travaillant avec des méthodologies telles que PM² ou PMflex.

capture d'écran de la page des portefeuilles de projets avec une mise en surbrillance de l'entrée de menu associée

Développements futurs

Pour 2026, les développements vont s'orienter vers l'amélioration de l'existant bien sûr, mais aussi :

  • faciliter la migration depuis Jira avec le développement d'un outil de migration et de nouvelles fonctionnalités comme l'ajout de Sprints, le dépoussiérage du module « Backlogs », ou l'implémentation d'identifiants courts pour les lots de travaux ;
  • intégrer XWiki pour pouvoir remplacer le duo Jira et Confluence par de l'open source avec OpenProject et XWiki ;
  • mieux gérer des programmes et portefeuilles de projets : apporter une vue d'ensemble de plusieurs projets, pouvoir définir des critères sur chaque projet, par exemple l'urgence et l'importance, et obtenir ainsi une matrice de priorisation, avoir un processus d'approbation lors de la création de nouveaux projets, etc…
  • édition collaborative de contenu : généraliser l'édition collaborative apparue dans le module « Documents » ;
  • de l'IA : assistance à l'écriture, recherche sémantique, serveur MCP, etc…

N'hésitez pas à tester OpenProject en l'essayant en ligne pendant 14 jours ou en l'installant vous même. Si vous avez des retours ou des demandes de fonctionnalités, vous pouvez vous inscrire sur notre instance community.openproject.org et contribuer à améliorer OpenProject.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Interminable liste de terminaux

Ah, la ligne de pêche Maginot commande ! Que ce soit pour gérer ses fichiers, récupérer des commits, lancer une compilation, se connecter à un serveur, redémarrer un service, consulter les logs, voire contrôler la musique, afficher des images, cette interface reste en 2025 exceptionnellement boomer rapide et même parfois confortable.

Sans compter que le terminal est l'endroit où lancer des applications dédiées, pour lire ses mails ou un million d'autres choses.

Bref rappel avant se lancer dans de longues comparaisons

  • TTY vient de teletypewriter. Si vous tapez (Xorg comme Wayland) Control + Alt + F3 par exemple, vous vous retrouverez devant une invite de commande.
  • pts/pty : quand vous ouvrez un terminal

L'invite de commande pourra bénéficier d'un shell personnalisé. Le bureau permettra l'usage d'un terminal.

    Sommaire

    Le jeu de les shells

    Le shell est un interpréteur de commande. On peut simplement lancer une commande pour consulter l'état du système (top, ps), déplacer un fichier (mv), … Ou combiner des commandes, écrire des scripts basés sur des conditions et des variables, … Donc comme l'explicite le manuel GNU, un shell unix est la fois un interpréteur de commande et un langage de programmation.

    La plupart des distributions utilisent par défaut "Bash", mais il est possible de changer de shell, par exemple interactivement en utilisant la commande chsh ("change shell"), ou en modifiant les paramètres d'un terminal en particulier, ou d'un multiplexeur, ou encore plus globalement en modifiant le shell par défaut d'un user (faites un peu attention dans ce cas — les shells ne sont pas tous compatibles, ne tombez pas !).

    Les shells tombent

    Les scripts précisent aussi quel shell invoquer… Si je prends un tuto sur un shell au hasard, voici ce que je vais trouver

    #!/bin/bash
    # This script will take an animated GIF and delete every other frame
    # Accepts two parameters: input file and output file
    # Usage: ./<scriptfilename> input.gif output.gif

    Attention : ce script référence explicitement /bin . Pas 100% sûr que bash y soit installé. Une solution peut être d'utiliser env.

    #!/usr/bin/env bash

    Hormis interpréter les commandes tapées, le shell affiche également un prompt invitant à taper une commande. Quelque chose comme cela :

    [goat@arch:~]$ 
    

    Pour la partie prompt, certains shells vont autoriser un peu de paramétrage, ou l'on peut même installer des plugins pour enrichir les possibilités, comme avec powerline ou même le liquid prompt présenté ici même par son auteur Dolmden.

    On peut aussi trouver un prompt comme starship qui est utilisable avec les différents shells.

    De la préhistoire au Bash

    Pour l'histoire, le premier shell Unix date de 1971, puis le Bourne Shell (sh), du nom de son auteur, apparait en 1977. Beaucoup de fonctionnalités sont déjà présentes : il est scriptable (on peut définir un script avec des conditions dont la si laide esac, définir des boucles, …), les processus peuvent être contrôlés, il est possible de définir des alias, …

    Bourne Shell implémente la norme POSIX que d'autres shells respectent. La licence du Bourne Shell est débatue (avec une certaine vigueur sur Wikipédia!) , en tout cas son code est ici.

    KORN shell n'était, au départ, pas open source - le code n'est libéré que dans les années 2000. Korn Shell implémente les fonctionnalités du Bourne Shell mais ajoutera d'autres éléments, comme des raccourcis vi/emacs, ou comme les tableaux

    $ typeset -A age
    $ age[bob]=42
    $ age[alice]=31
    $ print ${age[bob]}
    42
    

    GNU BASH : /bin/bash

    GNU Bash

    B.A.S.H. = Bourne Again Shell (superbe jeu de mots avec Born Again Shell). Bash implémente la norme POSIX… et un peu plus.

    GNU bash connait une première release en 1989. Il reprendra à son compte des fonctionnalités trouvées jusqu'ici dans de précédents shells, y compris Korn Shell. Bash reste le shell interactif par défaut sur de nombreuses distributions. Il fut le shell sous MacOS.

    Anecdote - quel est le plus gros programme bash que vous connaissiez ? nb, qui propose de gérer vos notes en mode texte (org, markdown, etc), est principalement composé d'un script .sh de … 26736 lignes. Je vous laisse partager vos trouvailles en commentaire !

    DASH : le Debian Almquist shell est renommé ainsi en 1997. Debian l'adopte par défaut pour les scripts, tandis que le shell interactif des utilisateurs reste bash. Ubuntu y passe par défaut sur la 6.10. Dash est léger et performant. Moins de dépendances égal plus de sécurité.

    ZSH

    ZSH ZSH sort en 1990. Toujours compatible avec la norme POSIX, Zsh va améliorer de bien pratiques fonctionnalités d'auto-complétion : appuyez sur <TAB> et Zsh complète pour vous.

    Mais bien plus largement, Zsh va atteindre le paroxysme en terme de fonctionnalités. Tout existe dans Zsh.

    Zsh est connu pour proposer de très nombreuses possibilités de configuration. Ses plugins se comptent par centaine — y compris plusieurs gestionnaires de plugins… Mais un outil très utilisé pour le configurer sort du lot : Oh my zsh, qui permet de gérer plus de 300 plugins ainsi que de nombreux thèmes.

    FISH

    Fish

    Fish pour "Friendly Interactive Shell", date de 2005. C'est un shell non POSIX - certaines fonctionnalités ne seront pas compatibles. Un script bash ne marchera pas forcément.

    Ce shell se veut demander peu de configuration - il est prêt à l'emploi. Choix appréciable quand on peut déjà passer tant de temps à configurer d'autres choses (distro, bureaux, nano, terminaux..)  !

    Il suffit de l'installer pour avoir

    • une coloration syntaxique indiquant quelle commande est valide
    • suggestions : en tapant, on obtient des candidats que l'on peut auto-compléter

    Fish est également scriptable et se veut proposer un syntaxe plus saine. À vous de tester (mais vous ne codez qu'en Rust, n'est-ce pas ?)

    Le gros point de Fish à mon sens, c'est de proposer une configuration par défaut déjà utilisable, comme le fait de se baser sur les pages man ainsi que sur l'historique pour proposer l'auto-complétion. Oubliez les heures passées à configurer - je ne sais pas si Fish a le plus de chevaux dans le moteur, mais avec lui vous êtes déjà prêts à partir.

    Petite fonctionnalité sympa, taper fish_config ouvre une page ouaibe. On peut alors prévisualiser les thèmes, personnaliser le prompt, visualiser les fonctions et variables, consulter l'historique et les raccourcis claviers. Fish a un mode vi.

    Fish a été réécrit en Rust entre 2022 et 2024.

    Ravissant multiplex, 200 mètres carrés

    Gnu Screen

    Ok donc nous avons un shell à choisir, y compris le prompt et il faudra le lancer dans un terminal, mais avant ça, si on avait un gestionnaire de fenêtre dans le gestionnaire de fenêtre ? C'est bien comme cela qu'est présenté GNU Screen, qui gère des fenêtres, typiquement de terminaux. C'est un multiplexeur, en français : la possibilité d'ouvrir plusieurs terminaux dans un seul terminal. GNU Screen sait lister les terminaux ouverts, passer de l'un à l'autre, en tuer… Comme souvent, le wiki arch détaille bien notre affaire concernant screen. Mais GNU Screen est un vieux de la vieille, qui date de 1987.

    Tmux

    Plus souvent cité de nos jours, Tmux (2007) propose des raccourcis à la Emacs ou à la Vim, un menu graphique, des splits verticaux ou horizontaux.

    Zellij

    Il existe d'autres multiplexeurs. On peut citer par ex. Zellij, orienté développeurs, qui affiche une barre de statut, peut afficher les raccourcis claviers…

    Envolez-vous vers un nouveau terminal

    Le choix d'un terminal pourra définir l'apparence de votre interface, comment vous gérez le multi-fenêtre et/ou multi-onglet, la capacité à rechercher, copier-coller, les raccourcis clavier, peut être même comment accéder aux emplacements, vous connecter en ssh.

    Certains terminaux proposent un mode inspiré de Guake (première release 2007), lui même inspiré du terminal dans Quake : le terminal est toujours ouvert et dispo, mais caché et l'appui d'un raccourci clavier le fera apparaître. Le temps de taper trois commandes et le même raccourci le fera disparaître. À voir ce qui se fait encore sous Wayland, je vois par ex. qu'il y a encore une extension GNOME.

    La console sur le bureau

    Première piste : tout simplement utiliser la terminal qui vient avec son bureau, si l'on en utilise un. Évidemment le premier avantage sera une bonne intégration, mais en pratique ?

    Nous verrons aussi plus bas certains terminaux qui sont le terminal par défaut de gestionnaires de fenêtre, mais il s'agit simplement d'un choix par défaut et pas d'une affiliation ni d'une intégration particulière, donc pas de raison de les mentionner ici.

    Console (GNOME)

    Le terminal par défaut a changé sous GNOME 42 (euh bah oui c'était y'a un moment), pour devenir GNOME Console (anciennement Kings Cross Station d'où kgx — j'ai cherché l’exécutable un moment…). Assez peu de fonctions particulières mais : devient rouge lorsqu'on est connecté en root ou violet en ssh, envoie une notif quand une longue commande se termine, sympa. Un bouton de recherche un peu étonnant peut s'avérer pratique. Clairement la logique est d'afficher peu de boutons, peu de choix, et d'investir sur des options par défaut qui fonctionnent. Je ne vais pas retenir Console pour mon usage mais je trouve qu'effectivement c'est un terminal élégant.

    Pour changer le shell de Console, il faudra passer par l'éditeur dconf et modifier l'option org.gnome.Console.shell.

    Certaines distributions ont préféré maintenir gnome-terminal, plus complet, mais gnome-terminal est resté Gtk3 (alors que kgx est bien Gtk4).

    Petite note sur kgx et gnome-terminal : ces terminaux sont basés sur la libvte dont dépendent d'autres terminaux GTK. Voici quelques exemple cités par une page du wiki gnome :

    On pourrait y ajouter Lxterminal (merci à Impromptux).

    Konsole

    Konsole

    Le choix logique pour le bureau KDE. En termes de fonctionnalités, c'est l'artillerie lourde. Multi-profils, signets, multiplexeur, prévisualisation d'images. Konsole est intégrée dans plusieurs applications KDE.

    Pour changer le shell de Konsole, vous pouvez passer par le menu Settings > Configure Konsole > Profiles .

    C'est le moment de mentionner Qtermwidget : ce widget fut originellement basé sur Konsole et servit à développer Qterminal.

    xfce-terminal

    Terminal par défaut du bureau Xfce. Il dépend et hérite de libvte. Il est en Gtk3.

    • Permet plusieurs onglets
    • Intégration avec un gestionnaire de fichiers (ouverture dans le répertoire courant du terminal)
    • Prévention de collage dangereux : quand ça contient un retour chariot, ouvre une popup qui permet d’inspecter et modifier le contenu dangereux.
    • Permet d’envoyer un signal au processus en cours
    • Permet d’avoir une console rapide à la Guake
    • Permet de colorer les onglets manuellement.

    Il est possible de changer le shell dans les préférences.

    Terminology

    Terminology

    Ce terminal sort en 2013, il fait partie du bureau Enlightenment Je pense que c'est le premier terminal à pouvoir afficher des images. Il est possible d'avoir des informations en survolant une URL. Une barre de progression s'affiche durant l’exécution de commandes. Les performances sont au rendez-vous. (Subjectif - serait-ce tout simplement la meilleure appli e17?)

    Emacs et (Neo)Vim

    Mais plutôt que d'utiliser le terminal intégré à son environnement de bureau, pourquoi ne pas utiliser directement celui intégré à son éditeur de texte? Un bon éditeur de texte en effet a forcément son bon terminal. Même Vim? Et oui. C'est donc une solution de lancer le terminal depuis l'éditeur de texte, par exemple pour reproduire les fonctionnalité d'une IME vivre sa vie entière en mode texte.

    Emacs

    Démarrons tout de même par Emacs, où la prise en charge du terminal est plus ancienne.

    Emacs a… 4 terminaux, pourquoi faire simple. 4 terminaux ? Non pas vraiment : 2 shell et 2 terminaux. Il peut y en avoir plus.
    En fait, puisqu'on peut, malgré la rumeur, bel et bien éditer du texte dans emacs, pourquoi ne pas gérer ses commandes au même endroit ? On peut même s'amuser à gérer ses fichiers dans dired, ses processus, finalement un peu tout l'aspect système.

    Mastering Emacs le développe mieux que moi mais vous aurez donc plusieurs possibilités sous Emacs :

    2 SHELLS

    • eshell, le plus emacsien des 2 : un shell 100% implémenté en elisp (!!!). On peut faire beaucoup de emacs dedans , mais tout ne fonctionnera pas. Ne lancez pas journalctl dedans ^^
    • shell. Même chose, ne lancez pas journalctl

    2 TERMINAUX

    • term / ansi-term. Cette fois c'est vraiment un terminal, mais… lent.
    • vterm. Ok cette fois c'est vraiment un terminal, et ça utilise une bibliothèque en C derrière, donc ouf un vrai terminal Emacs existe bel et bien. Attention vterm a besoin d'une bibliothèque.

    Oui je pense qu'il y a vraiment des utilisateurs du terminal sous Emacs. Et il est possible de trouver de petits benchmarks sur les réseaux comme par exemple reddit.

    Vim

    Qui a dit que vim n'était pas bloated et ne pouvait pas gérer cela? (À sa défense vim ne gère pas encore l'email.. ) Vim prend en charge le terminal depuis la version 8.1. Pour changer le shell dans vim, ajouter cette commande dans le fichier de config

    :set shell=/usr/bin/zsh
    

    Les indies

    Pourquoi utiliser le terminal de son bureau, ou de son éditeur de texte, alors que l'on peut utiliser un million d'autres ? Bienvenue dans la jungle. Ne m'en voulez pas si votre petit favori n'est pas listé ici, mais rajoutez sa description en commentaire - il a existé de bien trop nombreux concurrents, et même en se limitant aux projets actifs la liste est bien trop longue. La liste ici pourrait compléter cette dépêche.

    Je rappelle que sont listés ici les terminaux qui sont proposés par défaut sous certains gestionnaires de fenêtre, le parti pris étant que dans ce cas il n'y ait pas d'intégration particulière, contrairement par exemple au terminal KDE.

    Enfin la liste se veut à moitié lister les terminaux populaires actuels, à moitié lister quelques terminaux plus pour un intérêt historique, mais cette dépêche n'étant pas une thèse cette volonté sera assez peu rigoureuse.

    Blackbox

    Blackbox terminal n'est pas affilié à GNOME ni un terminal officiel mais est développé avec cet environnement en tête. Il utilise Gtk4.

    Ptyxis

    Là c'est un cas à part : pour reprendre sans recul le readme.md :

    A modern terminal emulator built for the container era.
    Seamlessly navigate between your host system and local containers like Podman,
    Toolbox, and Distrobox with intelligent detection and a beautiful, responsive
    GNOME interface.

    L'intérêt est donc d'intégrer les conteneurs de toutes sortes pour y accéder rapidement (et les définir rapidement).

    Ptyxis

    Il semblerait qu'il puisse devenir le terminal par défaut sous Ubuntu (25.10?).

    St

    La philosophie de st, dont la première release, 0.1, est de 2017, c'est de rester simple et léger - le point que son site discute, c'est le nombre de lignes de codes limité que devrait avoir un terminal. Son auteur serait fainéant ? Ce terminal sous licence MIT/X Consortium s'apparente à mon sens à un reliquat du passé : il tourne sur X et uniquement sur X (oui, oui je sais pour Xwayland). Néanmoins il m'a paru logique de le citer ici.

    Kitty

    Kitty a une place importante car il a légué quelque chose aux successeurs… Il implémente en effet des extensions venant étendre le protocole historique.

    Ce terminal tourne sous Python et requiert OpenGL. Malgré son âge (première release 2017), c'est le choix par défaut pour Hyprland.

    Kitty offre une tonne de raccourcis claviers, gère les onglets/fenêtres, peut afficher des images, sait afficher des notifications et bien d'autres choses. En terme de philosophie, il se veut orienté power-user.

    Alacritty

    Alacritty se veut un terminal simple et est écrit en Rust. Il est sortit en 2017. Alacritty respecte XDG en cherchant en priorité un fichier de config $XDG_CONFIG_HOME/alacritty/alacritty.toml.

    C'est le terminal par défaut pour au moins deux gestionnaires de fenêtre Wayland très différents l'un de l'autre : Wayfire et Niri.

    • vi mode : appuyez sur control + shift + space et vous passez dans le mode "normal" de vi (par opposition au mode insertion). Les touches au lieu de permettre de taper du texte, permettront alors de se déplacer, sélectionner du texte, le copier…
    • ctrl shift o pour afficher des "hint" sur les URL, ce qui permet de les activer en 1 touche
    • recherche normal (ctrl shift f ) , recherche vi
    • multi fenêtre (spawn new instance)
    • theme https://github.com/alacritty/alacritty-theme

    Pas d'onglet, pas de split — utiliser un multiplexeur au besoin.

    Foot

    Ce serait un peu le successeur de St, au sens où il est codé en C et les premières fonctionnalités mises en avant sont la légèreté et la performance, mais en natif Wayland. Pour autant Foot n'est pas avare sur certaines fonctionnalité. Sa première release est de 2019. C'est le terminal par défaut pour Sway, Dwl.

    Il faudra le configurer à l'aide d'un fichier texte, et foot respectant XDG, ce sera ici $XDG_CONFIG_HOME/foot/foot.ini. Foot propose pas mal de raccourcis claviers, dont le même Hint mode que Alacritty : taper Ctrl Shift O .

    Au cas où il ne serait pas assez léger, Foot propose un mode serveur.

    Wezterm

    De nouveau un terminal en Rust. Wezterm se veut complet, et cross-platform. Il affiche des images, gère les hyperliens, la connexion en SSH avec un client intégré, fait office de multiplexeur.

    Il se configure en Lua.

    Ghostty

    Ghostty

    Ghostty est sous licence MIT. LWN l'a présenté. Il s'agit d'une application récente, début en 2022, v1.0 fin 2024.

    Une barre gtk4 permet d'afficher les onglets, d'en créer un nouveau. Sympatique fonction, ghostty +list-keybinds --default montre toutes les options (et un raccourci permet d'éditer le fichier de config). On peut aussi lister les thèmes avec ghostty +list-themes.

    Peut afficher des gifs, comme Kitty.

    Ghostty se veut un compromis entre la vitesse, les fonctionnalités, l'interface, et cross-platform. Il se veut agréable sans avoir besoin de modifier le paramétrage par défaut. Et il est petit, le paquet Debian par exemple fait 113 Ko.

    Vous pouvez changer le shell sous Ghostty :

    ~/.config/ghostty/config:
    command = /usr/local/bin/fish --login --interactive
    
    

    De plus Ghostty intègre des fonctionnalités "Shell-integration".

    Rio

    (2022)
    https://github.com/raphamorim/rio
    vi mode, hyperlinks, images,

    Le shell peut être modifié dans la config, plusieurs exemples sont fournis

    [shell]
    program = "pwsh"
    args = ["-l"]

    Warp

    Alors là on bascule du côté obscur de l'IA !… et du proprio. Warp est d'abord une entreprise, qui a souhaité réimaginer un outil des développeurs - le terminal. Ce terminal, écrit en Rust, ne sera pas open source : https://github.com/warpdotdev/Warp/discussions/400

    À la première ouverture, Warp suggère d'ouvrir un compte « pour bénéficier de toutes les fonctionnalités ». Ensuite, on ne se trouve pas directement dans une console mais Warp propose plutôt d'ouvrir / cloner un projet. Un raccourci permet cependant de lancer une session normale…
    … Si ce n'est qu'outre des commandes, on peut taper des phrases ! En passant par Claude pour les interpréter… L'IA peut également suggérer des commandes en se basant sur votre historique. Tout ceci peut être désactivé dans les paramètres. Les fonctionnalités IA requièrent une connexion Internet.

    J'ai par exemple testé "Install Wave term from the internet". Warp a commencé par vérifier s'il y avait une commande de disponible "yay", mais cette commande n'était pas dispo sur mon système. Il a alors intelligemment testé d'autres gestionnaires de AUR et a trouvé que paru était installé. De là, il a découvert waveterm dans les dépôts AUR et m'a suggéré d'utiliser paru -S waveterm-bin (control+entrée pour valider, et gogogo). Une fois ces folies passées, on revient à une expérience normale où la commande se déroule (pensez à lire les AUR avant d'installer aveuglément !)

    Quand vous parcourez un projet, Warp peut indexer ces projets pour améliorer les suggestions.

    Au lieu d'utiliser votre clavier pour taper, Warp peut reconnaître votre voix. Outre des commandes ou des phrases, il est possible de commencer par un "/" pour taper une "slash command".

    Il y a également des fonctionnalités d'équipe, notamment une fonctionnalité de collaboration en temps réel. Certaines fonctionnalités sont payantes.

    Warp propose un certain nombre de fonctionnalités classiques : personnalisation du prompt, apparence, raccourcis claviers, …

    L'entreprise fournit un benchmark où Warp s'en sortirait aussi bien que Kitty ou Alacritty sur vtebench

    WaveTerm

    Waveterm est un peu la réponse open source à Warp (Apache 2.0).

    Quand on l'ouvre la première fois, c'est la foire ! à gauche, le panneau invite de commande qui occupe un tiers de l'écran.
    Tiers du milieu : en haut la consommation du CPU (hein?). Au milieu, un bout de page internet (hein?). En bas, un explorateur de projet. Tiers à droite : en haut, des raccourcis clavier qui s'affichent. Au milieu, un bout de doc sur Wave. En bas, une invite pour Wave IA. Bien sûr il s'agit d'une démo et il sera possible de personnaliser ce qui est visible au démarrage. Il est également possible lorsqu'on utilise un des "blocs" de le passer en mode "pleine fenêtre" puis le réduire par la suite.

    Bon, testons l'invite IA en demandant d'installer… Warp! Il commence par m'expliquer les différentes méthodes d'install en fonction de l'OS (ah ! il n'a pas détecté…). J'explique que j'utilise Arch et il me dit d'utiliser un AUR helper ou de cloner le dépôt du AUR. Mais il ne détecte pas si j'ai paru ou yay ou autre.

    On peut utiliser d'autres modules IA. Wave inclut également un explorateur de fichiers.
    Les paramètres se gèrent bloc par bloc - on paramètre d'un côté les blocs que l'on souhaite au démarrage, de l'autre pour un bloc donnée, par exemple les préférences.

    3. Liens

    Norme POSIX sur le shell

    https://linuxfr.org/news/gameshell-apprendre-les-rudiments-du-shell-en-s-amusant

    Bref cours sur le shell

    Cours plus complet sur le Bourne Shell

    Revue de fish :

    Autre revue de Fish

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Raspberry Pi 5, évolution ou révolution ?

    Les méandres de l'espace de rédaction sont parfois mystérieux. La rédaction de certaines dépêches s'étalent parfois sur de long mois, parfois sans même comprendre pourquoi la dépêche ne part pas vers le stade de la publication. C'est ce qui est arrivé à cette dépêche qui ne suit donc pas autant qu'elle aurait pu l'actualité de la sortie de la nouvelle mouture de la microcarte de la Fondation Raspberry Pi, qui porte le nom très original de Raspberry Pi 5. Cette dépêche - qui nous offre une comparaison de cette nouvelle édition avec son illustre ancêtre ainsi qu'une investigation de ses nouveautés - reste substantielle et il nous a semblé qu'il valait mieux la publier même tardivement plutôt que de la plonger dans l'oubli éternel.

      Sommaire

      Cette dépêche ne traitera pas de l’ensemble de ce que l’on peut faire, la précédente dépêche sur les SoC faite pour la sortie de la Raspberry Pi 4 est toujours d’actualité en ce qui concerne ces sujets.

      Comparaison entre Raspberry Pi 4 et Raspberry Pi 5

      Sorti en 2019, le RPi4 avait fait forte impression—mais quasiment en constante pénurie entre 2020 et 2023, il commençait par accuser le coup par rapport à la concurrence du Rockchip RK3588 (Quad-core Cortex-A76 + Quad-core Cortex-A55).

      Aussi, la Raspberry Pi 5 introduit des avancées significatives par rapport à la Raspberry Pi 4, dont le Tableau 1 présente une synthèse des différences.

      Composants Raspberry Pi 4 Raspberry Pi 5
      SoC Broadcom BCM2711 Broadcom BCM2712
      CPU Quad-core Cortex-A72 (1.8 GHz) Quad-core Cortex-A76 (2.4 GHz)
      GPU VideoCore VI (500 MHz) VideoCore VII (800 MHz)
      Mémoire 1, 2, 4, 8 GB LPDDR4-3200 SDRAM 4, 8 GB LPDDR4X-4267 SDRAM
      Wi-Fi Dual-band 802.11ac Dual-band 802.11ac
      Bluetooth 5.0, BLE 5.0, BLE
      USB 2 USB 3.0, 2 USB 2.0, 1 Type-C port 2 USB 3.0, 2 USB 2.0, 1 Type-C port
      Stockage MicroSD MicroSD (SDR104⟹R/W↗ˣ²) + ligne PCIe pour NVME M.2 SSD
      Ethernet Gigabit Ethernet Gigabit Ethernet
      Puissance Jusqu’à 7.5 W 2 modes : jusqu’à 15 W et jusqu’à 25 W
      Gestion HDMI 2 HDMI 2.0 (1 gérant 4k@60 Hz) 2 HDMI 2.0 (tous les deux gérant 4k@60 Hz)
      Format vidéo H.264 (AVC) H.265 (HEVC)
      PCIe Non 1 lane PCIe pour périphériques haute performance
      Bouton d’alimentation Non Oui

      Tableau 1 : comparatif des Raspberry Pi 4 et 5

      Détail des améliorations de la Raspberry Pi 5

      La Raspberry Pi 5 introduit des avancées significatives par rapport à la Raspberry Pi 4, en particulier avec l’introduction du southbridge RP1. Voici une comparaison détaillée mettant en évidence les principales différences et l’impact du RP1 :

      • Processeur : La Raspberry Pi 5 est équipée d’un CPU ARM Cortex-A76, une amélioration substantielle par rapport au Cortex-A72 trouvé dans la Raspberry Pi 4. Cette mise à niveau fait que la Pi 5 est deux à trois fois plus rapide que son prédécesseur.
      • RAM : La Raspberry Pi 5 utilise de la LPDDR4X-4267 SDRAM, nettement plus rapide que la LPDDR4-3200 SDRAM utilisée dans la Pi 4. Cette amélioration offre plus de bande passante, contribuant à des performances globalement plus rapides.
      • Puissance graphique : La Raspberry Pi 5 dispose d’un GPU VideoCore VII plus puissant, cadencé à 800 MHz et prenant en charge OpenGL ES 3.1 et Vulkan 1.2. C’est une avancée par rapport au GPU VideoCore VI de la Raspberry Pi 4, qui prend en charge OpenGL ES 3.1 et Vulkan 1.0. Le GPU de la Pi 5 comprend également un nouveau processeur de signal d’image pour la gestion des données des caméras.
      • Chip RP1 Southbridge : La puce RP1 est une innovation majeure dans la Raspberry Pi 5. Elle agit comme un southbridge, gérant la plupart des fonctions I/O (entrée/sortie), réduisant ainsi la charge sur le CPU. Cela permet une augmentation de la bande passante I/O, bénéficiant aux dispositifs de stockage, USB et autres périphériques.
      • Vitesse des cartes MicroSD : Le port microSD de la Pi 5 prend en charge le mode haute vitesse HDR 104 avec les cartes microSD UHS-1, offrant des vitesses de lecture de 80-90 Mbps, soit le double de la vitesse de 40-50 Mbps de la Pi 4.
      • Ports USB : Dans la Raspberry Pi 5, chacun des deux ports USB 3.0 dispose d’une bande passante dédiée de 5 Gbps, grâce à la puce RP1. C’est une amélioration par rapport à la Pi 4, où les deux ports USB 3.0 partageaient la bande passante de 5 Gbps.
      • Connecteur PCIe : La Pi 5 inclut un connecteur PCIe (PCI Express), une nouvelle addition répondant à la demande pour des interfaces plus rapides. Cependant, l’interface PCIe de la Pi 5 n’est pas un connecteur M.2 standard ; elle nécessite un câble ruban pour se connecter à un HAT, et le dispositif M.2 se connectera au HAT. Caractéristiques
      • Un bouton marche/arrêt : Eh oui, on est quand même dans le 3ᵉ millénaire ;-)
      • Alimentation : Tout comme la Raspberry Pi 4, la Raspberry Pi 5 utilise un connecteur d’alimentation au format USB Type-C. En revanche, doublement de la puissance oblige, la puissance nécessaire à son fonctionnement passe de 7.5 W à 15 W, il faudra donc une alimentation en 3A minimum pour être tranquille. À noter que si vous souhaitez utiliser des périphériques externes qui consomment beaucoup comme des disques durs ou SSD, il est conseillé d’avoir une alimentation de 25 W (5A). La Raspberry Pi détecte si l’alimentation fournit plus de puissance et passe la limite de consommation USB à 1,6A au lieu de 1,2A.

      Raspberry Pi 5 : Nouveau South Bridge RP1 vs Raspberry Pi 4

      Le RP1 est un contrôleur d’entrée/sortie (I/O) conçu pour le Raspberry Pi 5, représentant le programme d’ingénierie le plus complexe et coûteux entrepris par Raspberry Pi, avec un développement s’étendant sur plus de sept ans et ayant coûté environ 25 millions de dollars. Ce contrôleur est le premier produit phare de Raspberry Pi à utiliser une puce conçue en interne​.

      Architecture du South Bridge RP1

      — Description : Le RP1 est un southbridge de 12×12 mm avec un pas de 0.65 mm en BGA (Ball Grid Array), fournissant la majorité des capacités d’E/S pour la Raspberry Pi 5.
      — Caractéristiques : Il comprend un point de terminaison PCIe 2.0 à 4 voies, un contrôleur Ethernet MAC Gigabit et deux contrôleurs hôtes USB 3.
      — Améliorations : Plus du double de la bande passante USB utilisable par rapport à la Raspberry Pi 4.
      — Documentation RP1 : RP1 Datasheet

      Sources des informations sur le RP1

      — L’article d’Eben Upton pour annoncer le RP1 : RP1 : the silicon controlling Raspberry Pi 5 (ce court article est accompagné d’une vidéo YT de 35 minutes à ce sujet, mais dont le contenu est reproduit textuellement en suivant un lien)
      — Lien direct vers la vidéo YT : RP1 : the silicon controlling Raspberry Pi 5

      Impacts du RP1

      Le RP1 constitue une avancée importante, puisque les GPIOs “physiques” de la carte ne sont plus directement reliées aux GPIOs du microprocesseur et de leurs fonctions possibles (SPI/I2C/UART/I2S) attribuées par le fondeur dans le silicium.

      1. Connectivité principale : Le RP1 se connecte à un processeur d’application (AP) via un bus PCIe 2.0 x4, consolidant de nombreux contrôleurs numériques et PHYs analogiques pour les interfaces externes du Raspberry Pi 5​​.
      2. Contrôle du trafic : Le tissu interne du RP1 permet de prioriser le trafic en temps réel de la caméra et de l’affichage sur le trafic non en temps réel de l’USB et de l’Ethernet. Des signaux de qualité de service (QoS) sur le lien PCI Express soutiennent la priorisation dynamique entre le trafic provenant du RP1 et le trafic des maîtres de bus en temps réel et non en temps réel au sein de l’AP​​.
      3. Fonctionnalités supplémentaires : Pour une flexibilité maximale des cas d’utilisation, le RP1 dispose de plusieurs fonctionnalités telles qu’un contrôleur DMA à huit canaux pour les périphériques à basse vitesse, trois PLL intégrées pour la génération d’horloges vidéo et audio indépendantes, un convertisseur analogique-numérique à cinq entrées, 64kB de SRAM partagée, et des générateurs de base temporelle pour le rythme de la DMA ou pour le debouncing des événements GPIO​​​​.
      4. Gestion des contrôleurs de bus : Les modules de régulation intégrés à chaque port de contrôleur de bus permettent de surveiller ou de limiter leur comportement. Ces modules régulent le flux de données selon le nombre de transactions en attente, assurent le respect des limites d’adresses AXI et PCIe, et disposent de compteurs statistiques pour évaluer la qualité de service ou les performances.
      5. Interfaces clés externes : Le RP1 fournit des interfaces externes clés telles que deux contrôleurs XHCI indépendants connectés à un seul PHY USB 3.0 et un seul PHY USB 2.0, deux contrôleurs de caméra MIPI CSI-2 et deux contrôleurs d’affichage MIPI DSI connectés à deux PHY transceivers MIPI DPHY à 4 voies partagées, et un contrôleur d’accès média (MAC) intégré pour l’Ethernet Gigabit​​​​.
      6. Compatibilité et évolution : Le RP1 maintient la compatibilité avec la gamme de fonctions offerte sur le Raspberry Pi 4 Model B, tout en permettant une évolution vers des processus de géométrie réduite, sans avoir à reproduire tous les éléments analogiques du système. Cela pourrait permettre à changer plus facilement de fournisseur de SoC.

      Évolution des performances

      Afin de permettre de mieux visualiser les évolutions des performances Alasdair Allan a fait un benchmark complet dont certains éléments sont repris ici.

      Tout d’abord une analyse des performances du CPU avec geekbench. Les Figures 1 et 2 montrent une augmentation des performances en single core d’approximativement 2.2x,
      performances single core

      Figure 1. : Comparaison des performances single core entre RPi4 et 5
      performances multi core

      Figure 2. : Comparaison des performances multi core entre RPi4 et 5

      Compilation de différents benchmarks entre RPi 4 et 5

      Benchmark Unités Raspberry Pi 4 Raspberry Pi 5 Augmentation de Performance
      Sysbench Mono-Thread MBps 699 1041 x1,49
      Sysbench Multi-Thread MBps 2794 4165 x1,49
      Stress-ng Mono-Thread op/s 104,78 182,68 x1,74
      Stress-ng Multi-Thread op/s 413,12 737,21 x1,78
      Bzip Mono-Thread secondes 44,98 20,53 x2,19
      Bzip Multi-Thread secondes 28,59 14,36 x1,99
      Gimp Redimensionner secondes 67,01 29,95 x2,24
      Gimp Rotation secondes 77,24 32,77 x2,36
      Gimp Niveaux Auto secondes 80,52 34,64 x2,32
      Gimp Masque Flou secondes 115,16 49,71 x2,32
      Speedometer 2.1 score 20,5 62,5 x3,05
      Glmark2 score 97 202 x2,08
      Openarena Timedemo FPS 8,77 27,05 x3,08
      RAMspeed Écriture MBps 4391 29355 x6,69
      RAMspeed Lecture MBps 5902 27931 x4,73
      HDparm Lecture MBps 43,81 90,05 x2,06
      dd Écriture MBps 34,49 61,23 x1,78
      Iozone 4 K Écriture RAND MBps 9,38 15,22 x1,62
      Iozone 4 K Lecture RAND MBps 4,71 4,6 x0,98
      Temps de démarrage secondes 33,4 19,1 x1,74

      performances des I/O

      La Figure 3. issue du travail d’Adafruit permet de mettre à jour le graphique sur la vitesse performance de la commutation des I/O proposé dans la dépêche sur la RPi4. La Figure 4. quant à elle montre une légère amélioration de la performance par Watt sur le nouveau modèle.

      Titre de l’image
      Figure 3. Évolution de la vitesse de commutation d’une sortie numérique

      Titre de l’image
      Figure 4. Évolution de la performance en fonction de la puissance électrique

      Interfaces USB et Ethernet

      — Interfaces: Le RP1 fournit deux interfaces USB 3.0 et deux interfaces USB 2.0, ainsi qu’un contrôleur Ethernet Gigabit.
      — Source: Circuit Digest – The New Raspberry Pi 5 is here

      Le Gigabit Ethernet fourni par le RP1 est en tout point semblable à celui du RBPi4 (voir : RP1 : the silicon controlling Raspberry Pi 5:

      Liam 13:21: So we’ve got the Ethernet MAC but not the PHY. So the Ethernet’s brought out to an RGMII interface, which then connects to an on-board Ethernet PHY.

      Eben 13:35: And this is a fairly similar architecture to Raspberry Pi 4, except that in that case, the MAC was in the Broadcom device, but there was still an external – in fact exactly the same external – PHY, [BCM]54213. Cool. So that’s the overall structure of the design.

      Interfaces MIPI CSI/DSI

      Ces interfaces d’entrée/sortie vidéo peuvent être qualifiées d’historiques dans l’écosystème RaspberryPi puisqu’elles sont présentes depuis la version 1. Le RBPi5 apporte toutefois une nouveauté assez remarquable par rapport à ses prédécesseurs : au lieu d’avoir un port CSI (pour une caméra) et un port DSI (pour un écran), les ports du RBPi5 peuvent être configurés pour l’une ou l’autre fonction. Malheureusement, cela s’est traduit par des changements notables au niveau de la disposition des composants sur la carte, qui ne sont pas sans susciter quelques grincements de dents parmi les utilisateurs.

      Les points discutables/discutés

      Le réarrangement de la carte

      — Le port audio a disparu, pour laisser sa place au port MIPI DSI (qui peut faire CSI à présent), lui-même remplacé, au-dessus du lecteur de carte microSD, par un connecteur FPC exposant les lignes PCIe.
      — le port DSI est passé de 15 pins à 22 pins (comme sur la carte CMIo4)
      — Et, encore une fois, les ports Ethernet et USB ont été inversés.

      Si cela ne pose pas de problèmes particuliers pour un utilisateur lambda, de nombreux projets basés sur les cartes RasperryPi à la recherche de performance de calcul (et donc potentiellement intéressés par ce nouveau RBPi5) doivent entièrement revoir la conception de leur matériel.

      Le non réarrangement de la carte

      C’est un reproche que l’on peut trouver dans de nombreux témoignages : mettre un HAT (carte d’extension) sur un RBPi, juste au dessus du CPU, c’est un non-sens en termes de refroidissement (et ce, quelle que soit la version du RBPi).
      Mais, pour relativiser, on peut dire la même chose de quasiment toutes les autres solutions alternatives au RBPi.

      Les limites du format carte de crédit

      Ce format (86x56 mm) est devenu une référence pour presque tous les acteurs du monde des SBC. Et donc, il s’agit là aussi d’un constat plus général, non spécifiquement adressé à RaspberryPi. Mais sachant que ce sont les locomotives du marché, peut être pourraient-ils initier une nouvelle approche…
      Certes, ce format permet d’élaborer des solutions compactes, mais l’on peut constater :

      — qu’augmenter la puissance et les fonctionnalités des puces embarquées tout en restant sur ce format conduit à un gaspillage inutile de ressources : il est en effet impossible d’implémenter toutes les fonctionnalités matérielles proposées par les puces sur une si petite surface, et par ailleurs il devient difficile de refroidir efficacement le système.
      — pour exposer le port PCIe, RaspberryPi a supprimé le port audio, déplacé le port DSI ; mais pour alimenter le bouzin, il vous faut du 5V 4A. Ensuite un peu tout le monde se trouve planté là : débrouillez-vous.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      Publication du guide pratique « Tout savoir sur la licence ODbL » par la Fédération des pros d’OSM

      La licence ODbL (Open Database License) est notamment celle choisie par la communauté OpenStreetMap. Il s’agit d’une licence copyleft spécialement conçue pour les bases de données.

      Jean-Christophe BECQUET, membre du bureau de la Fédération des pros d’OSM, se dit fier de cette publication du guide pratique « Tout savoir sur la licence ODbL ». Il s’agit d’un remarquable effort de pédagogie pour bien comprendre les droits et les devoirs inscrits dans cette licence libre.

      « ODbL = le cercle vertueux du partage ».

      Couverture du livret papier

      ODbL est aussi la licence retenue par Open Food Facts et plus de 4700 jeux de données en opendata sur le portail data.gouv.fr.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      Pass the SALT 2024 : 21 conférences et 9 ateliers sur la Sécurité et les Logiciels Libres

      Pass the SALT est une conférence gratuite se déroulant à Lille sur deux jours et demi début juillet. Elle est dédiée à la Sécurité et aux Logiciels Libres.

      Coding under trees at PTS2018

      Cette 6ᵉ édition se déroulera :
      📅 du 3 au 5 juillet 2024
      📍 à l’école de Polytech à Lille.

      Venez profiter de la présence d’expert·e·s très accessibles dans une ambiance conviviale d’une conférence à taille humaine 🥰

      👉 Les inscriptions sont ouvertes et sont gratuites. Le nombre de places disponibles diminue rapidement, ne tardez pas :)

      Cette année, elle accueillera des expert·e·s venant du monde entier pour couvrir dix sessions différentes parmi lesquelles on peut citer :

      • la session WebPKI avec notamment Aaron Gabble, tech lead de Let's Encrypt, et Philippe Boneff tech lead de l’équipe Certificate Transparency de Google ,
      • la session Host protection : présentation des outils Kunaï, PyRASP et oletools par leurs développeurs respectifs Quentin JEROME, Renaud Bidou et Philippe Laguadec,
      • ou deux sessions dédiées à la crypto : une sur le registre de la vie privée via les outils Cryptpad et Sufflecake et une autre dédiée aux développeurs et parlant d’agilité cryptographique et de tests de primitives ,
      • 6 autres sessions dédiées au bas niveau et au reverse, à la détection réseau, à la sécurité offensive, à la réponse à incident et à la threatintel, et au phishing.

      🛠️ Vous pourrez aussi apprendre par la pratique au cours de 9 ateliers (2 ateliers en permanence en parallèle des conférences).

      🇬🇧 Les interventions sont données en langue anglaise afin que la conférence soit la plus accueillante possible pour les conférencier·e·s et les membres du public qui sont non francophones.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      Sortie de LuneOS « Eiskaffee »

      Tentés par un café glacé ? LuneOS « Eiskaffee » vient de sortir !

      LuneOS est une distribution GNU/Linux pour téléphones mobiles et tablettes, héritière de feu webOS. Le projet est porté par l’équipe webOS-Ports, dont le but est de faire revivre webOS sur les matériels contemporains.

      logo de LuneOS

      Sommaire

      Voici bien longtemps que l’équipe de webOS-ports n’avait fait de nouvelle version de LuneOS. De nombreux changements de fond, de nouveaux téléphones et tablettes, des difficultés techniques mais aussi une équipe développement modeste expliquent ce rythme un peu lent qui avance selon le temps libre de chacun.

      Pendant ce temps, des versions de test de LuneOS ont été régulièrement mises à disposition sur Github, dans le dépôt « luneos-testing ». Cela permet aux personnes intéressées d’essayer LuneOS, tout en gardant à l’esprit que ce ne sont que des versions intermédiaires.

      Petits rappels et lexique

      Le projet s’appuie sur Yocto, webOS-OSE, Halium et SHR. Il utilise OpenEmbedded comme environnement de compilation. Cette dernière version de LuneOS se base sur la version « Kirkstone » de Yocto. Ces projets ne vous disent rien ? Voici un rapide lexique :

      • OpenEmbedded est un environnement de compilation, qui utilise un ensemble de « recettes » pour décrire les composants à compiler et installer.
      • Yocto est un ensemble de recettes prêtes à l’emploi qu’on peut utiliser pour se construire une distribution Linux personnalisée. Les recettes mises à disposition vont du noyau Linux à Firefox, et forment un ensemble déjà assez complet.
      • SHR est un système d’exploitation GNU/Linux s’appuyant aussi sur Yocto et OpenEmbedded, et orienté téléphones. Il a connu son heure de gloire à l’époque des téléphones Openmoko comme le FreeRunner. Seule une petite partie est maintenant réutilisée pour les besoins de LuneOS.
      • Halium est un ensemble d’utilitaires et d’images Android permettant de faire tourner un Android minimaliste dans un container dédié sur la distribution hôte. Cela permet d’exploiter les pilotes et firmwares disponibles seulement pour Android, tout en gardant le reste de l’OS sur une pile GNU/Linux/systemd/Wayland classique.
      • webOS-OSE est une distribution Linux maintenue par LG, héritière du code de webOS, et dont LuneOS reprend maintenant beaucoup de composants logiciels.

      À l’exception des blobs utilisés pour faire tourner les pilotes Android, l’ensemble de la distribution est libre : tout le monde peut, s’il le veut, recompiler sa propre image chez soi.

      Fin du forum webOS Nation et autres tracasseries techniques

      Le forum « webOS Nation », qui regroupe des discussions autour de webOS au sens large (vieilles versions de webOS, mods, LuneOS…) a connu quelques turbulences ces dernières années. Devant une fermeture imminente du site web, un nouveau site webOS Archive a été mis en place, avec notamment la majorité des archives des forums de webOS Nation. Un nouveau forum a été mis en place, reprenant globalement le style de webOS Nation.

      Sans avoir une activité folle, la communauté autour de webOS reste présente, notamment grâce à la présence aujourd’hui de webOS sur les téléviseurs.

      Mort du « builder » dédié à LuneOS

      Suite à plusieurs avaries, le builder « Jenkins » a dû prendre une retraite bien méritée. Malheureusement cela implique pour l’équipe de webOS-ports de compiler les différentes images de LuneOS chez soi, ce qui n’est pas très pratique (sans être une catastrophe). Sur une machine raisonnablement puissante, la création d’une image de LuneOS depuis zéro demande plusieurs heures, il faut donc parfois s’armer de patience. Heureusement Yocto permet de mutualiser les résultats de compilation pour les architectures semblables, ce qui fait gagner beaucoup de temps.

      Les changements majeurs

      Depuis la dernière version publique de LuneOS, beaucoup de changements de fond ont eu lieu. On retrouve entre autres:

      Passage de Qt 5 à Qt 6

      LuneOS utilise maintenant Qt 6.5.2, l’une des dernières disponibles.

      Utilisation du compositeur Wayland de webOS OSE

      Le compositeur Wayland propre à LuneOS luna-next a été abandonné, au profit du compositeur Wayland de webOS OSE surface-manager. Cependant la partie graphique (codée en QML) a été conservée, et l’expérience utilisateur reste donc très similaire.
      Cela permet de se concentrer sur la partie GUI du compositeur, tout en bénéficiant des mises à jour venant de OSE relatives au cœur même du compositeur.

      Changement de moteur Chromium

      Les apps webOS utilisant intensivement HTML/Javascript/CSS, l’affichage nécessite un moteur web bien à jour et optimisé. Jusqu’à la dernière version, LuneOS utilisait QtWebEngine, fourni par Qt, pour faire tourner les applications.
      Cependant webOS-OSE fournit son propre moteur basé sur chromium, indépendant de Qt et optimisé pour une utilisation embarquée. LuneOS a donc également migré vers cette nouvelle infrastructure logicielle, adoptant ce composant WebAppManager.

      Migration générale vers les composants de webOS-OSE

      Plus généralement, les composants hérités de feu Open WebOS ont été remplacés par leur équivalent dans webOS-OSE, plus récents et encore maintenus par LG. Pour cette version de LuneOS, la version 2.23.0 de webOS-OSE est utilisée comme base.
      Cette migration inclut notamment l’utilisation des « Enhanced ACG », un modèle de sécurité plus efficace utilisé pour la communication entre les services de webOS et les apps.

      Ces changements, qui pour la plupart ne sont pas visibles à l’utilisation, apportent de multiples bénéfices pour LuneOS :

      • une réutilisation plus large du code de webOS-OSE (maintenu par LG), ce qui implique moins de maintenance côté webOS-ports
      • meilleure stabilité des composants, qui sont utilisés depuis des années dans les téléviseurs et appareils LG
      • la rétro-compatibilité a tout de même pu être assurée pour les vieilles apps webOS, grâce à des modifications mineures dans certains composants
      • plus de facilité pour mettre à jour les composants venant de webOS-OSE

      Téléphones et tablettes: vers plus de Linux « mainline »

      Dans le domaine des distributions Linux pour téléphones et tablettes, on parle de noyau « mainline » pour désigner l’utilisation directe du code source venant du noyau Linux, par opposition à l’utilisation d’un code source dérivé et proposé par un constructeur. Ce dernier est souvent proposé dans une vieille version, avec une maintenance très limitée dans le temps.

      Cependant, utiliser un noyau « mainline » est à double tranchant : d’un côté, on bénéficie des dernières avancées du noyau, et des dernières versions des pilotes libres. Mais de l’autre, cela signifie devoir se passer des pilotes proposés par le constructeur (pour le son, le GPS, le modem…), qui souvent n’ont jamais été proposés à l’inclusion dans le code source principal de Linux.

      Au final, dans le cas de LuneOS, trois voies se dessinent lorsqu’il s’agit de faire tourner l’OS sur un téléphone ou une tablette :

      1. Le constructeur remonte ses changements dans le noyau Linux, et s’appuie sur un développement open-source: Pine64 et Purism sont deux exemples récents de cette approche. C’est le cas idéal pour LuneOS, où des pilotes open-source bien intégrés peuvent être utilisées pour faire fonctionner les composants matériels.
      2. Le constructeur ne propose qu’une version Android de ses pilotes et du noyau; ce dernier reste figé dans une même version, relativement récente, avec une maintenance minimale. LuneOS va alors utiliser Halium pour profiter des pilotes faits pour Android, tout en gardant le reste du système sur une pile logicielle « systemd/glibc » classique. Cette situation reste très présente, car l’immense majorité des téléphones et tablettes du marché tournent sur Android.
      3. Le constructeur propose une vieille version du noyau, non maintenue, et dont les limitations deviennent problématiques pour LuneOS. Dans ce cas, LuneOS va tenter d’utiliser un noyau plus récent, mais qui a un support partiel du matériel. Cette stratégie a souvent un résultat très mitigé, avec de gros manques fonctionnels. En gros, c’est la tentative de la dernière chance avant l’abandon du support de ce matériel.

      Le matériel Pine64

      Une tablette PineTab2 avec LuneOS

      Comme évoqué plus haut, Pine64 cultive ses liens avec la communauté open-source, et incite celle-ci à proposer leurs OS sur leur matériel. On retrouve ainsi de nombreux OS comme PostmarketOS, Plasma Mobile ou encore Ubuntu Touch. LuneOS a pris le train en marche très tôt, et peut aujourd’hui s’installer sur le Pinephone, le Pinephone Pro ainsi que sur la tablette PineTab 2.

      Pour le Pinephone et le Pinephone Pro, LuneOS nécessite maintenant l’installation préalable de Tow-boot sur le téléphone. Ce dernier est un dérivé de U-Boot, qui vise à standardiser et faciliter le démarrage des OS sur du matériel embarqué.

      Comme ce matériel tourne avec une version très récente du noyau Linux, il est possible pour LuneOS de lancer Waydroid; cependant cette fonctionnalité est jeune et nécessite encore beaucoup de travail.

      Le matériel Android

      LuneOS peut s’installer sur de nombreux autres téléphones (et sur la vénérable tablette HP Touchpad), grâce à l’utilisation de Halium (ici en version 9.0).

      Cependant, même s’il n’est pas prévu d’abandonner les téléphones et tablettes Android, les efforts se concentrent de plus en plus sur le matériel pour lequel un noyau « mainline » existe.

      Plans pour la prochaine version

      Continuer la migration vers l’infrastructure de webOS-OSE

      Mettre à jour les composants vers la dernière version de webOS-OSE, et finir la migration:

      • mettre à jour le moteur web vers Chromium 108 (tout juste sorti du four chez LG)
      • re-baser l’infrastructure audio et multimédia de LuneOS sur les composants fournis par webOS-OSE
      • travailler également sur le support des caméras

      Continuer le travail sur le matériel supporté

      • Avoir un noyau « mainline » fonctionnel pour Tenderloin, Hammerhead, Mido and Tissot.
      • Fournir une image GSI unique pour les téléphones Android, permettant de faciliter grandement le support d’autres téléphones

      Compléter l’espace applicatif

      • Améliorer ou ajouter des apps de base comme Camera, Flashlight, Audio Player ou Video Player, et améliorer les composants QML.
      • Essayer de profiter du travail fait par la communauté sur les TVs LG « homebrew » : webOS Brew

      Envie d’essayer ?

      Pour le téléchargement et l’installation, c’est par ici. Il existe notamment une image pour émulateur x86-64, utilisable directement dans VirtualBox.

      L’équipe webOS-ports est présente sur IRC (Libera:#webos-ports) ou encore Telegram.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      ❌