Pinaraf a écrit 3671 commentaires

Je n'ai jamais compris ces critiques récurentes sur les trotinnettes électriques, qui peuvent tenir facilement dans un coffre de voiture et parcourir 10 ou 20 km en ville très facilement.

Il y a trottinette et trottinette. La trottinette en location comme on en trouve (trouvait ? ça fait 2 ans que je n'y suis plus allé) sur Paris est une calamité. Le matériel dure quelques mois seulement pour une recyclabilité minable, toute une infrastructure polluante (camionnettes) est nécessaire pour redistribuer tous les jours les trottinettes aux bons endroits pour assurer une réponse à la demande…
À côté de ça, il y a la cohabitation avec les autres usagers. Si la trottinette roule sur la chaussée, elle est mélangée aux voitures, vélos et motos sans être adaptée : pas de clignotants, vitesse complètement en décalage… Si elle roule sur le trottoir, c'est les piétons qui peuvent être mis en danger.
Dans une ville sans voiture par contre, les problèmes ne sont pas les mêmes…

Le but ne serait pas plutôt de soutenir artificiellement le renouvellement du parc automobile et de détruire le marché de l’occasion au passage ?

Ça fait un peu complot dit comme ça…

Les politiques ont un problème à résoudre : la pollution de l'air.

S'ils décidaient de bannir purement et simplement les voitures, ils auraient l'opposition :
- d'une part massive de la population,
- des commerçants locaux,
- des industriels…

S'ils décidaient de ne rien faire, ils pourraient avoir des conséquences juridiques (obligation de l'État d'agir sur le sujet, avec risques d'amendes par la CJUE de mémoire) et l'opinion s'y opposerait.

À partir du moment où l'on n'éduque pas, où l'on n'informe pas correctement l'ensemble de la population sur le danger, il n'est pas possible de prendre la décision de bannir la voiture. Les ZFE sont alors le seul compromis qui paraisse acceptable, bien qu'il revienne surtout à délocaliser la destruction de l'environnement et à continuer de faire tourner la machine…

Un véhicule qui a 5 ans et 75000km ne pollue t'il pas plus que lorsqu'il est neuf ?

S'il est entretenu correctement (ce que vérifie le contrôle technique), il n'y a pas de raisons. L'usure ne crée pas de gaz. Éventuellement des éléments peuvent s'encrasser, mais c'est pour ça qu'on change les bougies de temps en temps par exemple…

Si vous savez ce que les oxydes d’azote (Nox), le monoxyde de carbone (CO), les hydrocarbures (HC) et les particules (PM) ont comme impact sur la santé, je n'ai pas trouvé d'infos sur le sujet.

Nox => irritation, problème chez les asthmatiques, risques de bronchites chez les enfants (cf https://sante.lefigaro.fr/mieux-etre/environnement/oxydes-dazote/quels-effets-sanitaires)
CO => se fixe sur les globules rouges et empêche le transport d'oxygène. Dans les avions de tourisme et les ULMs, on a dans la cabine une pastille pour détecter le CO, et si la pastille change de couleur on arrête le vol dès que possible…
PM => irritation et cancer, troubles cardiovasculaires… Pour info, les pneus sont de gros émetteurs de PM, ce qui rend le passage à la voiture électrique vachement moins intéressant sur ce point, vu le poids des voitures avec leurs batteries…

On peut changer un pilote (recharger un module) sans redémarrer.

Sur un périphérique actif, non.

[root@peanuts2 ~]# rmmod amdgpu
rmmod: ERROR: Module amdgpu is in use

Et pour que ce périphérique ne soit plus utilisé, avec KMS, c'est vraiment complexe.

Le seul cas où un redémarrage peut être vraiment requis, c'est un changement de pilote, et encore, uniquement sur un périphérique actif (passage du pilote libre au propriétaire pour une carte nVidia par exemple). Ou un changement de système de démarrage, mais installer une application ne doit pas impacter ça…
Donc… Mauvais logiciel, changer le logiciel.

Après faut quand même reconnaître que certains changements modernes sont idiots (et je ne parle pas que de Firefox).

Par exemple l'accès à l'historique.
Si j'accède par le menu traditionnel, j'ai :
(- touche Alt pour afficher le menu si il est caché, ce qui est le cas par défaut)
- appui de bouton sur Historique
- glisser jusqu'à fenêtre fermées récemment (par exemple)
- glisser sur ce que je veux ouvrir, et lâcher le bouton

Avec le menu burger :
- appui sur le menu puis lâcher le bouton
- déplacer la souris jusqu'à historique, puis appuyer/relâcher le bouton
- remonter la souris jusqu'à fenêtres fermées récemment, puis appuyer/relâcher
- aller sur la fenêtre que je veux ouvrir, puis appuyer/relâcher

On est sur quatre clics contre un seul sur un menu traditionnel.
Et je ne parle pas de la distance parcourue par le curseur : un sous-menu est à accès direct, alors que là c'est tout le menu qui est remplacé par le contenu du sous-menu. Donc si le sous-menu est pas très fourni mais que son sélecteur est vers le bas du menu principal (Aide par exemple), on augmente considérablement la distance parcourue.
Au moins le menu burger, à l'inverse de ce que son nom pourrait impliquer, va faire maigrir en forçant à faire plus d'efforts à la souris… :)

• Kate, éditeur de texte du projet KDE
• QtCreator, IDE «officiel» du framework Qt

Dommage de ne jamais (l'article lié n'est pas plus disert) donner un seul exemple de ces "fonctionnalités les plus avancées" que LSP ne permettrait pas, surtout si on perd "énormément"..?

Dans mon cas, j'utilise KDevelop pour du C++.
Des fonctionnalités majeures de cet IDE qui seraient perdues par LSP aujourd'hui :
- coloration sémantique du code : utilisation d'une palette de couleurs pour les variables dans une fonction, qui permet en parcourant rapidement le code d'avoir une lecture plus rapide grâce aux variations de couleur
- expansion des macros : bien que je sois heureux aujourd'hui de ne plus avoir à toucher à un monstre de macros que j'ai affronté dans un emploi précédent, je tombe encore dans des projets sur des usages intensifs des macros, et avoir l'IDE qui affiche la traduction de la macro, ça aide beaucoup
- hiérarchie des classes dans un projet

Demain, LSP pourrait implémenter tout ça je pense, mais avec plusieurs évolutions du protocole, et ça sera avec un coût : soit l'IDE reprend en mémoire l'ensemble des éléments (grosse duplication), soit il va y avoir un ping-pong permanent avec le serveur (latence).

Tout d'abord, une remarque : Microsoft n'utilise pas LSP dans son «vrai» IDE. Ils ne l'utilisent que dans Visual Studio Code, qui reste un jouet comparé aux fonctionnalités de Visual Studio.

Il y a quelques années, une étudiante avait commencé à travailler sur le support de Rust dans KDevelop, et avait étudié la possibilité d'utiliser LSP. Son article était très intéressant là dessus : https://perplexinglyemma.blogspot.com/2017/06/language-servers-and-ides.html
D'autres développeurs se sont penchés dessus depuis, et si rien n'a été fait côté KDevelop (pour les raisons mentionnées avant je suppose) une intégration est désormais possible dans Kate https://kate-editor.org/posts/kate-language-server-protocol-client/

Donc LSP… c'est "bien", mais ça ne fait pas tout. Si tous les IDEs libres se limitaient demain à LSP, on perdrait énormément sur les fonctionnalités les plus avancées nécessitant que l'IDE comprenne le langage de programmation manipulé.

Il s'agirait donc d'un protocole visant à permettre de communiquer en direct des informations sur la coloration syntaxique (et plus) à destination des IDE ?

Nop, pas forcément la coloration syntaxique, plutôt le «et plus» : complétion de code, suivi de symboles… La coloration syntaxique reste l'affaire de l'éditeur, je pense que des aller-retours là dessus seraient très mauvais pour les performances, surtout qu'il existe déjà des formats assez simples pour décrire la coloration syntaxique (https://kate-editor.org/syntax/ pour voir le format utilisé par Kate, implémenté également dans Qt Creator)

Je ne parlais pas de la partie «contribution», je pensais plutôt à ce qui est sur la page d'accueil : « The adjusted deadline to find 10 people is set for the end of Mai 2021. You can find all the details and pictures in the document below. »
Ce sont ces 10 people qui doivent chacun apporter les brouzoufs.

Alors le prix n'est pas affiché sur le site directement, il faut lire la brochure : 30000CHF soit un peu plus de 27000€…
Dix fois moins cher, je pense que je prenais (ok, j'avoue, j'adore les montres mécaniques), mais là c'est pas encore mon budget…

Pourquoi avoir une batterie alors ?
Pour démarrer le moteur !

Pas que.
La voiture est remplie d'accessoires et de moins-accessoires dépendant de l'électrique : essuie-glace (niveau élec c'est minable), phares (déjà un peu moins), vitres électriques, direction assistée (selon les modèles, mais ça c'est pas accessoire)…
Et du coup, petit vécu sur une voiture tchutchutpademarque : de nuit, en prenant un virage, la direction assistée s'est soudain coupée et je me suis en plein virage retrouvé en direction insistée. Après 2 aller-retour au garage où diverses pièces ont été changées, j'ai fini par trouver une solution pour qu'ils puissent reproduire le problème à l'arrêt, et donc je leur ai déposé le véhicule avec comme mission "vous me rendez la voiture sans ce comportement" : à l'arrêt, moteur allumé (mais pas au ralenti, il fallait un certain nombre de tours/min de mémoire), autoradio allumé, mettre le volant en butée, et avec les fenêtres fermées actionner la fermeture des fenêtres. C'est le chemin le plus court pour maximiser la consommation électrique, et ça faisait sauter immédiatement la direction assistée.
Et le coupable était la batterie qui ne faisait plus son taf correctement dans ces conditions.

Depuis, plus de tchutchutpademarque…

Oui mais est-ce-que ntfs-3g est installé sur la majorité des MacOS ? Alors que la majorité des distributions Linux Desktop vont l'intégrer.
Si on compte l'installation de logiciels tiers, non intégrés de base, il faut changer les résultats pour Windows aussi puisque des pilotes pour ext sont disponibles…

Je ne vois pas l'avantage de FAT32 par rapport a exFAT

C'est parce que le tableau tente de rendre binaire ce qui ne l'est pas.
exFAT n'est supporté sous Linux sans FUSE que depuis le noyau 5.4, novembre 2019, donc dans les distributions de 2020 et ultérieur. Avant, il fallait installer un paquet supplémentaire, donc le support n'était pas garanti.
De plus, il ne faut pas oublier tout le matériel à la con qui existe : auto-radios ou lecteurs de musique, imprimantes, appareils divers et variés acceptant des clés USB fonctionnant avec des OS inconnus… Eux ne supporteront en général que le FAT32.

Un pilote NTFS complet avec lecture/écriture est en cours d'intégration dans le noyau.
Il n'a pas passé la fenêtre du 5.12, peut-être en 5.13.
La série de patch en est à la version 27 : https://lore.kernel.org/lkml/20210402155347.64594-1-almaz.alexandrovich@paragon-software.com/

Passons outre le lien quelque peu fumeux avec Richard Stallman et son retour au conseil d'administration de la FSF, et réfléchissons un peu à la définition de «morale».

Imaginons la règle suivante : «ce logiciel ne doit pas être utilisé pour servir à tuer un humain». C'est moral, n'est-ce-pas ? Maintenant, projetons-nous en 1970. Une femme enceinte de deux semaines souhaite interrompre sa grossesse. Est-ce moral de l'aider ? En 2021, un humain en pleine souffrance, incurable, encore lucide et qui demande à terminer sa vie… Est-ce moral de l'aider ?

Donc, c'est déjà limite de vouloir défendre «la» morale, comme s'il en existait une qui soi universelle, mais ce sera encore plus compliqué à définir, et sous une forme qui soit en plus capable de traverser le temps : la GPL2 a 30 ans, la GPL3 en a 14 ans, et même sur des périodes de temps aussi courtes, les sociétés changent, et donc «l'ensemble des règles ou préceptes, obligations ou interdictions relatifs à la conformation de l'action humaine aux mœurs et aux usages» change (et c'est la définition de la morale par Wikipedia.

L'explication est simple : les anti-cheat sous Windows sont devenus particulièrement complexes avec le temps. Les derniers modèles font quelque chose qui jusqu'à présent n'était jamais fait par des applis win32 : des appels système, des vrais, avec syscall.
Wine ne peut pas intercepter ça, et donc l'appli ne peut pas marcher avec Wine…

Heureusement, une fonctionnalité a été intégrée au noyau Linux tout tout récemment pour justement permettre d'intercepter les appels système, dans le but de faire marcher ce genre d'appli Windows… C'est passé dans le noyau 5.11, cf. https://lwn.net/Articles/826313/
Donc le problème devrait au moins s'améliorer prochainement, à défaut évidemment d'une résolution universelle magique…

Quelle serait votre liste de programmes urgents à optimiser ?

L'ensemble des programmes qui tournent sur ma machine ? :)
Plus sérieusement, s'il y avait une urgence sur ma machine, je m'en occuperais. Mais j'aimerais beaucoup que du temps soit consacré à l'optimisation de l'ensemble des programmes qui constituent le bureau Linux, Plasma dans mon cas. J'ai beau avoir une machine puissante, j'aimerais que ma machine démarre plus vite.
Après mon principal reproche aujourd'hui c'est surtout la conso mémoire qui est partie en flèche, en particulier sur les navigateurs web. Firefox consomme moins que Chromium, heureusement, mais ça reste beaucoup trop pour l'usage que j'en ai.

systemtap et bpftrace sont concurrents. Mais ils sont beaucoup plus complets que de la simple analyse de performance. Ils se branchent sur des événements et les interceptent, peuvent inspecter les différents paramètres dans le cas d'appels de fonctions… On peut par exemple regarder l'ensemble des fichiers modifiés en temps réel sur un système , l'ensemble des connexions réseau… des tas d'outils dans le style de top, iftop ou ss peuvent être réimplémentés ainsi.
Ce qui est fait ici serait peut-être faisable avec systemtap et bpftrace, mais ça revient à réimplémenter perf avec ces derniers. C'est du boulot.

Il est vrai que les perspectives d'amélioration des temps d'ouverture et d'enregistrement des documents Libre Office font quand même bien envie.

J'aurais du répondre à ce point tiens…
Où est la démonstration que cet aspect est bien le goulot d'étranglement ?
Dans mon cas, lecture de la norme OpenDocument, la compression Zip est invisible dans hotspot. Évidemment, elle est présente et a un coût, mais ce coût est tellement faible qu'avec la fréquence d'échantillonnage par défaut je n'ai pas su le voir. En augmentant à 8kHz, je commence à l'apercevoir, avec une consommation de moins de 0,01% du CPU…
J'ai du mal à analyser LibreOffice (je n'ai pas les symboles de debug, défaut d'archlinux, et je ne peux pas recompiler LibreOffice, défaut de courage :) ), mais je doute que les chiffres soient si différents de ce que je vois sur un perf rec sur lowriter sur la norme OpenDocument.

Cet article reste très intéressant, mais le prédicat de base (le Zip est un goulot d'étranglement) illustre bien l'intérêt de perf et de l'analyse par rapport au doigt mouillé pour améliorer les performances : ce qui coûte dans l'ouverture d'un fichier OpenDocument, en tout cas dans le cas d'un fichier complexe, ce n'est pas le format Zip.
Dans le cas de la sauvegarde, il faudrait que je creuse sur Calligra, mais dans le cas de LibreOffice cela ne me semble pas non plus être le cas (à nouveau, symboles de debug tout ça)

Les paramètres --aio -z changent ça radicalement. On passe de 700MB à un petit 30MB de mémoire…

D'après les statistiques il y a 12 utilisateurs de la feuille de style contrib/kaiska-short.

Les statistiques, les statistiques…

J'ai vérifié, y'a le même bug avec kaiska-new, donc on passe de 12 à 64 utilisateurs concernés… Ça en impose vachement plus non ?

Bref, j'ai compris, je vais tenter de trouver, mais j'ai «brêlage en CSS» sur ma fiche de perso.

Je connais cet article, qui est très intéressant effectivement, mais reste (et restera sûrement) entièrement théorique. Il m'est difficile de répondre sur l'étude (ou l'absence d'étude) concernant sa réalisation. Par contre les deux autres questions sont plus faciles.

Parce que ce serait trop compliqué de tout changer ?

En mars 2021, j'ai encore reçu un document rédigé avec le format Microsoft Word historique, introduit avec Word 97. En même temps que Clippy, en 1996. 25 ans d'inertie… Donc oui c'est très très très … très très compliqué de tout changer.
Les suites bureautiques ont heureusement toutes un système de filtre pour importer des documents d'autres logiciels, mais encore aujourd'hui la lingua franca des documents éditables reste dans beaucoup d'esprits le format Microsoft Office 97-2003.
Les deux prétendants légitimes au trône sont les formats Microsoft Office Open XML et Open Document. Ce qui me transitionne pour ta deuxième question…

Parce qu'elle n'est pas appropriée (et pourquoi) ?

Tout d'abord, par rapport à l'article, il eut été intéressant que la comparaison ait également lieu avec le format OOXML et pas seulement ODT. L'OOXML répond notamment à la problématique mise en avant ici (comment modifier la diapo 42 sans tout réécrire) avec un découpage en fichiers distincts de chaque diapositive. (ce qui peut compliquer d'autres éléments dans l'implémentation, mais passons)

L'OOXML et l'ODT ont de nombreux points commun. Ils sont normalisés, sous la forme d'une archive zip embarquant des fichiers XML.

Pourquoi zip ? Parce qu'il est ouvert, libre de brevets, dans le domaine public depuis 1989, avec de multiples implémentations, et même normalisé ISO depuis 2015 (en conséquence de son usage dans l'ODT, l'OOXML et l'epub d'ailleurs). SQLite, a contrario, serait là dessus un mauvais choix : il n'existe à ma connaissance qu'une seule implémentation du format de fichier, et le format a largement évolué en 2004 avec l'introduction de SQLite3, avec une rupture de compatibilité.

Et en aparté, pourquoi XML ? Outre le fait que dans les années 2000 c'était le Format à la mode, avec un F majuscule, un point qu'on néglige énormément en ces temps de JSON, YAML et autres TOML, le XML a intégré de base une technologie fantastique : les namespaces. Cela permet d'avoir des dépendances à d'autres normes et donc d'éviter d'avoir à réinventer la roue.
L'en-tête du fichier content.xml d'un fichier ODT généré par LibreOffice Writer contient une quinzaine de namespaces. Plusieurs sont assez intéressants puisqu'ils aboutissent à une réduction de la taille de la norme OpenDocument : les formules mathématiques sont par exemple représentées en MathML, les modèles XForms peuvent être directement intégrés, on utilise RDF… Le point «And so forth» de l'article de SQLite est vite incompatible avec cette approche (découpage du contenu en tables, avec des relations entre les tables et cie), à moins de définir un schéma SQL extrêmement strict et précis, qui à lui seul représentera des milliers de lignes de SQL, et qui remplacerait du coup des morceaux de la norme ODT…

Si l'on s'arrête strictement au concept s/zip/SQLite/, le point qui moi me crispe d'emblée, c'est l'absence d'implémentation alternative du format SQLite 3 (j'ai bien trouvé en grattant 2/3 projets décédés…). Sans ça, on n'a pas de preuve de la qualité de la description du format de fichier.

Pour finir cette bien longue réponse, je pourrais également ajouter ces éléments de la norme OpenDocument :
- un fichier OpenDocument peut être représenté en un fichier XML unique, sans le .zip autour (§3.1.1 de la v1.2-part1)
- le «package» est défini dans la partie 3 de la norme, la partie la plus courte. Rien n'interdit de proposer à l'OASIS une évolution sur du SQLite3…

Toutes mes excuses pour ce 'trou', je craignais que cela ne brouille le message qui vise à montrer perf/hotspot avant tout.

La lenteur majeure identifiée dans Calligra, visible sur la capture d'écran d'hotspot, est la fonction KoTextRangeManager::textRangesChangingWithin. La classe KoTextRangeManager stocke tous les objets KoTextRange, qui servent à représenter notamment les marque-pages, les annotations… Cela correspond donc à un point de départ et un point d'arrivée dans un document. Jusqu'à maintenant, ces éléments étaient stockés non triés. J'ai changé ça pour stocker dans une structure ordonnée afin de pouvoir faire des recherches en O(log(n)) au lieu de O(n) (le problème est similaire au bug sur QTextDocument). La structure est complexe parce que les KoTextRange peuvent correspondre à un point fixe ou à une sélection, et ils peuvent se superposer. J'en ai aussi profité pour stocker par classe de KoTextRange, vu que le code derrière filtrait…
Dans le code de mise en page, la fonction de recherche est appelée à chaque paragraphe. Dans la sauvegarde, elle est appelée encore plus souvent (pour d'autres raisons). Le gain a donc été phénoménal.