Sébastien Wilmet a écrit 693 commentaires

Et, maintenant que j'y pense, voir aussi :

https://drewdevault.com/2021/01/04/A-culture-of-stability-and-reliability.html

(qui je pense s'applique en partie à fontconfig).

Et, maintenant que j'y pense, c'est sans doute mieux un modèle comme ça qu'un modèle à la npm.

Effectivement, ça peut poser problème. Heureusement, certaines distributions n'hésitent pas à prendre une version de développement de fontconfig, ou en tout cas faire du cherry-picking de certains commits.

Je vois par exemple du côté de Fedora :
- https://koji.fedoraproject.org/koji/packageinfo?packageID=174
- https://koji.fedoraproject.org/koji/buildinfo?buildID=1786608

Avec dans le Changelog (mais en 2020) :

cherry pick some upstream patches

---

En ce qui concerne le peu de contributions, je pense que c'est pcq les développeurs sont occupés à développer des trucs au-dessus, et comme fontconfig fonctionne bien, qu'il n'y a pas (trop) de bugs, ou des bugs qui ne les concernent pas, alors ils ne pensent pas à améliorer fontconfig.

C'est le problème des logiciels libres qui fonctionnent (trop) bien, où il n'y a quasi aucuns bugs, et qui ont suffisamment de fonctionnalités. C'est à croire qu'il faut faire exprès d'introduire un bug, pour avoir des contributeurs en plus.

Oui, c'est pareil quand on utilise l'option --filter, par exemple :

#!/bin/sh

src='/home/foo'
dest='/run/media/foo/backup/home-foo'

rsync --archive --delete --force --progress --stats \
        --filter '- /foo/.cache/'                   \
        "$src" "$dest"

(version simplifiée d'un de mes scripts de backup).

--filter '- foo/.cache/' ou
--filter '- .cache/' n'ont pas le même effet.

C'est prévu qu'il y ait du développement (par Red Hat) pour mieux intégrer systemd-homed dans GNOME et Fedora, pour que ça Juste Marche™.

Voir cet article du blog de Christian Schaller (comme d'habitude en ce qui concerne GNOME && Fedora).

En attendant, c'est comme au bon vieux temps où il faut bidouiller avec son système Linux :-)

Profil Guided Optimization (PGO) et JIT (compilation Just In Time) ne sont pas la même chose.

Basé sur un profil, ça veut dire que ça se base sur les exécutions précédentes du programme. Il y a des patterns d'exécution qui sont les mêmes d'une exécution à une autre, donc autant optimiser ces parties-là. Surtout pour des programmes batch.

En tout cas c'est comme ça que je le comprends.

Pour WSL (Windows Subsystem for Linux), du PGO est aussi à l'ordre du jour pour le kernel Linux. On verra donc peut-être ça débarquer dans certaines distribs Linux classiques :-) (c'est drôle pcq Microsoft emploie des développeurs pour Linux et la GNU toolchain, chose inimaginable il y a une décennie).

Bien que je ne m'y connaisse pas dans tout ça, je sais juste que le support pour HDR est dans le pipeline de l'équipe desktop de chez Red Hat (de manière générale dans GNOME, pas GIMP en particulier, je présume). Voir cet article de blog et Ctrl+F "HDR".

Sinon lire les 3 pages de la table des matières du PDF, ça résume sans doute bien les fils de discussion twitter (mais c'est de l'anglais juridique).

Et lire les 173 pages du PDF (surtout que c'est du droit américain), ça n'aide sans doute pas pour la décompression.

Il manque un c dans le titre ;-)

GLib fait partie du projet GTK et GNOME.

glibc, ou GNU libc, c'est plus bas niveau, c'est l'implémentation GNU de la bibliothèque standard du langage C.

• Il y a Qt, qui fonctionne du tonnerre de Zeus (le cours de l'action a fort grimpé).
• SUSE qui s'est lancé récemment.
• Red Hat à l'époque qui a fort grimpé, puis racheté par IBM comme vecteur de croissance pour le mastodonte qui stagnait un peu.

J'en connais pas des masses, en connaissez-vous d'autres ? Qui font (principalement) du logiciel libre, bien entendu.

Je vois que je ne suis pas le seul dont ce journal interpelle.

Étant belge (province du Brabant-Wallon), j'ai une envie d'agir au niveau local au sujet du déploiement de LibreOffice et de la bureautique libre au sens plus large.

Pas qu'au sein des écoles et de l'éducation, mais au sein de n'importe quelle organisation qui déploie un parc informatique (à usage bureautique), ainsi que pour les citoyens, etc.

Il y a beaucoup à faire, et je sais qu'il existe déjà les différents LUGs et l'InterLUG belge (regroupement des LUGs). (Je fais partie du LouviLUG, toujours un peu actif).

Il faut selon moi créer une sorte de carrefour, pour mettre en lien différentes organisations et différentes personnes. Créer des ponts, à un niveau plus ou moins local. Entre organisations, entre citoyens, entre informaticiens, vers les politiciens, vers les médias, etc (cibler différents publics).

Par exemple :
- Avoir une liste d'entreprises de consultance belges spécialisées en déploiement de LibreOffice, du desktop Linux, etc. Plus d'autres acteurs européens actifs dans ce secteur (SUSE, Canonical, Collabora, …).
- Poster des annonces d'organisations qui cherchent des informaticiens ayant des compétences en LibreOffice, desktop Linux, etc.

Il y a Collabora Office, qui a des partenaires un peu partout dans le monde. Il y a les différentes certifications LibreOffice. Il y a SUSE, la plus grosse entreprise Linux européenne.

Étant donné que le sujet trotte dans ma tête depuis un certain temps, ce journal LinuxFr a été le coup d'envoi pour que je crée, hier, ce nouveau site web :

https://informatique-libre.be/

(Attention, c'est une ébauche, un prototype, work-in-progress, release early, release often, appelez ça comme vous voulez. Il manque bien évidemment beaucoup beaucoup de choses).

Mon commentaire ici décrit en partie ce dont je souhaite élaborer dans le site web, les idées sont encore vagues. Mais j'ai en ce moment du temps. Le « .be » est volontaire, c'est pour agir au niveau local, comme vous l'aurez compris ;-)

Autre idée, ce que je compte faire prochainement aussi, c'est postuler, envoyer des candidatures spontanées vers des écoles ou autre (pour s'occuper du parc informatique), avec comme titre du mail et du CV « Informaticien - logiciel libre », quelque chose comme ça. Qui sait, on me répondra peut-être un an plus tard, et si je ne suis plus disponible sur le marché de l'emploi à ce moment-là, je peux diffuser l'offre d'emploi autour de moi (sur le site web ci-dessus, ou s'il n'existe plus, vers les LUGs ;-).

Autrement dit, si le marché n'existe pas, s'il y a une ou plusieurs structures manquantes, il faut les créer !

Caml qu'on m'a forcé à apprendre durant mes études

Pour ma part c'était Oz, qui supporte aussi le pattern matching (depuis longtemps).

Super dépêche, bien écrit, pas trop long.

Et moi qui suit sur SLE depuis moins d'un an, j'ai appris des choses. (L'abonnement pour le desktop est abordable, 50€/an, et ça permet de contribuer financièrement au desktop Linux qui en a bien besoin).

L'entreprise SUSE a aussi fait une introduction en bourse récemment.

PipeWire est sûrement déjà dispo et empaqueté dans la plupart des distributions Linux, oui. Mais peut-être pas une version suffisamment récente pour l'audio, pcq PipeWire était déjà utilisé depuis quelques années pour la vidéo (screencast notamment) dans Gnome.

De plus il faut que le paquet à installer en plus (si PipeWire pour l'audio n'est pas la config par défaut) soit correctement empaqueté pour faire le basculement de PulseAudio vers PipeWire (je pense aux services systemd).

Bref, dans tous les cas il faut se référer à la doc de la distrib Linux qu'on utilise. Mais si ça devient un peu galère, autant passer à une distrib ayant déjà sauté le pas pour la config par défaut.

(sans parler de l'éventuelle config d'autres paquets faisant partie de la distrib, peut-être le kernel doit être configuré un peu différemment, etc ;-) ).

Tout est dans le titre ;-) Donc merci pour ces très bonnes explications.

Pour néanmoins trouver une piste de solution :
- Chercher dans les bugtrackers et mailing lists de différents logiciels libres relatifs au scannage de documents (sane et simple-scan me viennent à l'esprit) ou alors les logiciels qui travaillent directement avec le format PDF (donc s'adresser aux développeurs upstream qui connaissent et ont touché à la spec PDF). Si aucune info trouvée, rapporter un bug / demande de fonctionnalité en espérant avoir une réponse (même si la réponse ne vient que 5 ans plus tard, avec la fonctionnalité implémentée dans un autre logiciel 5 ans encore après, c'est mieux que rien (expérience typique)).
- Avec peut-être une chance de trouver un bout de script quelque part bien caché au fin fond du web^W^W de GitHub ;-)

PipeWire est justement la nouvelle technologie sous Linux qui règle tous ces problèmes. Le son "normal" (venant de youtube pour reprendre ton exemple) utilise PulseAudio (plus précisément : ça utilise l'API de PulseAudio, qui est implémenté par le démon PulsoAudio ou le démon PipeWire).

Je ne pense pas que pop os utilise déjà PipeWire pour le son.

Il te faut peut-être une autre distribution Linux. PipeWire a été développé en très grande majorité par un employé de Red Hat, et je sais que la dernière version de Fedora est passée à PipeWire pour l'audio (et Fedora est une distribution Linux faisant partie de la "famille" Red Hat).

Mais il y a sûrement d'autres distributions Linux qui sont aussi passées à PipeWire pour l'audio, il n'y a pas que Fedora (ou alors c'est juste un paquet à installer en plus).

Peut-être que PipeWire (même sur la dernière Fedora) est encore un peu jeune pour l'audio, mais en tout cas c'est à essayer ;-)

Un livre qui explique entre-autres le "Separation of concerns" (et plein d'autres choses intéressantes) :

Feature-Oriented Software Product Lines: Concepts and Implementation

Je recommande vivement ! Ce livre a influencé mes contributions à GNOME il y a quelques années, dans le domaine des éditeurs de texte et outils de développement.

J'ai un mal fou à comprendre pourquoi l'article parle de DNF (le gestionnaire de paquets de Fedora) au lieu de Zypper.

Auto-réponse : https://www.niallkennedy.com/blog/2006/11/feed-publishing-best-practices.html

ça ne doit pas avoir fort changé depuis 2006, ce côté-là du web.

Un peu hors sujet, je profite de l'occasion pour demander lequel est le mieux (le plus simple, le plus moderne, etc) : RSS ou Atom ?

J'avais un vague souvenir qu'on dit toujours "RSS", un peu comme MP3, mais qu'il existe Atom qui est préférable de nos jours (et depuis sans doute déjà une bonne quinzaine d'année).

Me trompe-je ?

Yep, je suis d'accord que d'avoir une application lancée pour le C++, et une autre pour CMake, c'est pas terrible à l'usage.

Imaginons que pour CMake la GUI aurait un intérêt d'être différente (plus simple, sans doute), que pour éditer du C++. C'est bien je trouve d'avoir des GUI spécifiques pour un usage particulier (menu et barre d'outils avec contenu différent selon le contexte).

Le truc c'est que, habituellement, les onglets pour ouvrir plusieurs fichiers dans une même fenêtre se trouvent en-dessous du menu et de la barre d'outils. Et si ces derniers veulent changer selon le contexte, ça peut faire bizarre. Pareil pour ce qui se trouve dans le panneau latéral.

Donc voici mon idée du jour : avoir les onglets au-dessus du menu et de la barre d'outils (et du panneau latéral), pour que tous ces éléments puissent changer selon le contexte. Et certains onglets pourraient d'ailleurs afficher un terminal au lieu d'un éditeur de texte.

Et ces onglets qui se trouvent au-dessus, ça pourrait même s'appeler une barre des tâches. Oh tiens… :-)

Pour le C il y a l'outil Cscope que j'utilise de temps en temps, mais la plupart du temps un petit git grep fait très bien l'affaire, en effet :-)

De manière graphique : GUI, pas en CLI. Mais ça pourrait être en ncurses dans un terminal aussi. Ne pas confondre CLI (lignes de commandes), avec une interface style ncurses.

C'est vrai que de nos jours quand on parle d'un IDE, on a tendance à penser à une seule grosse application GUI qui sait tout faire.

Mais, en GUI, rien n'empêche de développer des applications séparées, mais qui communiquent entre-elles avec un mécanisme d'IPC. L'avantage est que chaque application a une GUI plus simple, et ça fait donc moins « usine à gaz ».

Exemple (dont j'ai participé au développement) : Devhelp (navigateur d'API), qui sait être utilisé séparément, ou alors être lancé par l'éditeur de texte (pour voir la doc d'une fonction ou d'un autre symbole) ou être intégré à un IDE (il y a pour ça la libdevhelp, en GTK).

Perso j'adore le fait d'appuyer sur un raccourcis clavier depuis mon éditeur de texte, pour sauter vers la doc correspondante dans Devhelp (pour le symbole qui se trouve sous le curseur dans l'éditeur de texte). Puis un simple Alt+Tab pour revenir à l'éditeur de texte. Simple mais efficace.

Arduino est un exemple où c'est la même entreprise qui a développé le matériel, la plateforme de développement et l'éditeur de texte. Le tout pour que ça convienne à des débutants (pour commencer et écrire son hello-world avec une led qui clignote, ça fait le job). Mais c'est clair que ce ne sont pas des spécialistes (à la base) pour créer un éditeur de texte.

Autre exemple, la société JetBrains qui a développé IntelliJ Idea (pour Java), CLion (pour le C/C++), etc. Ce sont des IDEs spécialisés. Mais ce n'est pas JetBrains qui a créé Java évidemment. JetBrains s'est spécialisé dans le développement d'outils pour les développeurs, et ça a plutôt bien fonctionné. Ils ont créé une software product line, partageant du code entre leurs différents IDEs et outils.

Donc, je dirais, l'approche LSP est une bonne approche dans un premier temps (pour les concepteurs d'un langage), et si le langage devient suffisamment populaire, d'autres personnes/entreprises s'occupent de créer d'autres outils autours, des plugins additionnels pour certains éditeurs de texte, ou un éditeur de texte spécialisé, etc.

Il en faut donc pour tous les goûts : pour les débutants qui veulent un petit éditeur de texte spécialisé qui fait bien son boulot, out-of-the-box ; des éditeurs multi-usages et hyper-configurables ; etc.

Et si le LSP pour un certain langage est implémenté avec du code réutilisable (en-dehors du protocole LSP), c'est d'autant mieux pour ceux qui ont envie de créer un éditeur spécialisé. Je pense notamment à la libclang (du projet LLVM), qui est une brique de base pour l'implémentation d'outils autours du C et C++ (auto-complétion, refactoring, et bien d'autres). La libclang permet notamment l'implémentation du protocole LSP, mais ça peut être aussi utilisé directement en-dehors de LSP. Bref, la flexibilité à son maximum ;-)

Je vois la différence entre un éditeur de texte et un IDE différemment.

Pour moi un IDE est un éditeur de texte (le composant principal) plus d'autres outils qui ont été intégrés :
- Compiler/faire tourner le code (au lieu de le faire dans un terminal).
- Git/gestionnaire de versions, mais de manière graphique.
- Un navigateur d'API, pour lire la doc.
- Un débogueur.
- Etc.

Mais rien n'empêche à un éditeur de texte d'avoir une auto-complétion intelligente, avec donc une connaissance du langage en question. Pareil évidemment pour la coloration syntaxique, etc.