Pinaraf a écrit 3682 commentaires

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.

Merci d'être venu répondre ici :)

C'est un nouveau public avec de nouvelles habitudes de visionnages, tout comme l'est le streaming.

Super, je me sens pas du tout vieux/marginalisé :)

En enfin, j'aurais envie de dire que les live, c'est surtout interessant en live justement, pour profiter des interactions avec le chat et le streamer :)

Je suppose, oui, mais ça implique d'avoir connaissance des heures de diffusion et être présent devant la vidéo en live… J'ai l'impression d'un retour 20 ans en arrière où il fallait être devant le téléviseur au bon moment si tu voulais assister à une émission sans avoir à enregistrer sur une cassette (et programmer le magnétoscope éventuellement), avec le minitel ou le téléphone pour interagir avec l'émission en direct…

L'histoire est un éternel recommencement :)

Mais que vous soyez plusieurs à ne pas comprendre le concept, ça me dépasse.

Peut-être que tu n'admets pas le concept qu'un lecteur de PDF qui ne gère pas les formulaires soit inacceptable pour 99,99% des gens.
Peut-être que tu n'admets pas le concept qu'un lecteur de documents qui ne gère pas l'impression soit inacceptable pour 99,99% des gens.

Et pour autant, tu noteras que personne ne te juge, alors que tu te permets des qualificatifs blessants pour le travail des développeurs, de surcroît le tout basé sur la configuration de ta distribution qui par défaut ne va pas aller dans ton sens et ajouter de nombreuses dépendances inutiles (je suis allé vérifier, pour avoir eu ces dépendances à l'installation d'Okular, ta Debian n'est définitivement pas configurée pour une installation légère).

Et je tiens à préciser que l'ajout de l'impression dans un «visualiseur» de documents, ça sera quelques kB de code. Mais pardon, c'est une usine à gaz, méchants développeurs…

Je comprends que le montage de vidéos prenne beaucoup de temps et que ce soit donc difficile de fournir du contenu avec des durées adaptées… mais je ne comprends pas comment visionner les vidéos sur twitch ou les vidéos prises directement de twitch et mises à disposition sur youtube ou autre.
La dépêche parle de Barbatronic qui a fait une vidéo où il partage son avis sur FreeCAD. J'ai voulu la visionner : 1H26… Sur la chaine twitch que tu indiques, il y a des vidéos de 50 minutes, 2H, 3H40, 5H14 (!)…
Comment aborder ces contenus ?
Cette remarque n'est d'ailleurs pas spécifique au contenu relatif à FreeCAD, j'ai le même problème avec des créateurs de contenus sur Youtube qui se mettent de plus en plus à produire du contenu sur Twitch puis à le recopier sur Youtube, créant des mastodontes de plusieurs heures dont 90% du contenu aurait été coupé au montage…

Et ça correspond exactement aux critiques que je fais à ces logiciels : pourquoi je me retrouve à devoir installer un lecteur audio pour visualiser des documents .odt ? Lecteur audio qui même si je ne l’utilise pas va ensuite devoir être maintenu à jour, et est une excellente source de nouveaux bugs.

Parce qu'un document peut embarquer du contenu multimédia… Et au passage c'est un choix de Debian, tu pourrais avoir 'juste' gstreamer comme dépendance.

Et ce souci avec VLC se reproduit avec d’autres dépendances, qui vont donc m’amener un serveur de gestion d’imprimantes (CUPS)

Tu ne veux pas pouvoir imprimer le document ?

un système de correction orthographique (aspell)

Même quand on affiche un document, on peut saisir des formulaires, et donc vouloir la correction orthographique

des nouvelles collections de fontes

Ben là c'est normal, surtout qu'un .odt n'embarque pas les polices de caractères…

un éditeur de marque-pages (KEditBookMarks)…

Ça c'est un choix de debian

On arrive vite à 400 Mio ;)

Et là je ne te comprends pas. Si ton but c'est d'avoir le système le plus minimaliste possible, surtout sur l'espace disque, pourquoi utilises-tu une distribution généraliste qui au contraire va vouloir satisfaire un maximum de personnes ? Tu ne veux pas d'impression ni de correction orthographique, ok (ce sont des dépendances optionnelles), mais penses-tu que c'est le cas de la majorité des utilisateurs ?
Au passage, vu les dépendances que tu cites, tu ne serais pas avec la configuration par défaut qui en sus des dépendances va installer les recommandations ?

On en revient donc à la question des usines à gaz, terme que j’explicite un peu plus haut.

Il faudrait regarder le détail des paquets qui justifie la consommation des 400Mio, ça me surprend un peu aussi.
Par contre le nombre de paquet est assez logique quand tu cherches justement à faire des logiciels plus légers. Lors du passage de kdelibs4 à KDE Frameworks 5, tout a été découpé en plein de morceaux réutilisables.
Après… comment comptabiliser l'espace utilisé par un logiciel ? Quand on prend une application Windows ou MacOS, on ne compte pas le poids des bibliothèques système dans le poids de l'application… Quand on installe une application GNOME et qu'on utilise ce dernier, on ne voit pas le poids des bibliothèques GNOME utilisées… Et de même pour une application KDE…

Alors il faut absolument que je sorte une nouvelle version de Calligra, les versions ≤3.2 sont inutilisables pour ça, mais on a un plugin Okular qui permet de faire de ce dernier Okular un afficheur odt et odp…

Après je ne comprends pas spécialement l'intérêt de déléguer ça à Systemd. Quels sont les usages ?

Le bureau est constitué d'un ensemble d'applications et de démons, avec des dépendances entre eux, une activation possible par DBus…
Systemd gère le démarrage d'un ensemble d'applications et de démons, avec des dépendances entre eux, une activation possible par DBus…

Hum… je crois que c'est clair ? :)

Plus sérieusement, ça simplifie le démarrage en déléguant un travail pénible à systemd, la session peut démarrer plus rapidement, le noyau ne voit plus la session comme un unique cgroup mais comme des cgroup séparés. Par exemple un navigateur web et ses sous-processus seront regroupés. Ça peut simplifier le boulot pour l'ordonnancement et donner des priorités plus saines. Tu as également journalctl pour accéder aux logs de chaque élément séparément…

Merci bien. C'est en bonne partie grâce à Nokia qu'on a cette qualité dans le support des formats microsoft.
N'hésite pas à faire un rapport de bug si les documents sont partageables…

Si tu es maqué il faut essayer de te libérer plutôt que de t'enfermer encore plus non ?

Évidemment, mais la questions était bien «SQL server a-t-il un quelconque avantage ?», pas «produire un comparatif détaillé des avantages et inconvénients de SQL server» :)

Globalement, si tu veux vraiment exploiter toutes les performances de ta base de données, tu seras très liée à elle. Dans le cas de SQL Server tu utiliseras les fonctionnalités comme .Net intégré, pour PostgreSQL ce sera le système de typage avancé type hstore/jsonb/ltree, les index gin/gist ou encore les trigrammes… (je suis DBA PostgreSQL, pas SQL Server, donc dur pour moi de faire une comparaison).

Tout à fait, par contre dans le cas de Calligra il va d'abord falloir que l'on modernise nos dépendances, pour le moment on reste sur des vieilles versions ce qui pose problème… Là on est encore en C++11, donc on n'a pas par exemple std::make_unique<T>(…), on doit faire unique_ptr(new T(…)).

Effectivement, bonne idée. Je l'ai contacté, merci à toi

avec ton niveau technique as-tu imaginé un jour contribuer à libreoffice pour l'aider à devenir maître du monde bureautique ?

Oui je l'ai imaginé. Mais LibreOffice est un projet plus difficile à «valoriser», les compétences qu'on va y acquérir sont plus spécifiques.

L'architecture de Calligra est résolument basée sur les technologies KDE et Qt. Quand tu contribues, tu apprends ces technologies. Je pourrais aisément lister des tonnes de projets utilisant également ces briques, et donc auxquels tu peux plus facilement contribuer une fois que tu les as découvertes et que tu les maîtrises. Par exemple sur un projet pro, en Qt, j'ai eu à faire de la mise en forme de texte… les compétences acquises avec Calligra ont été très utiles.

L'architecture de LibreOffice trouve son origine dans StarOffice. Elle est très «années 90», le modèle de composant UNO (Universal Network Objects) par exemple. LibreOffice a également sa propre abstraction pour l'ensemble des plateformes (la VCL). Mais à ma connaissance personne d'autre n'utilise ces technologies. Donc quand tu vas contribuer à LibreOffice, tu vas vite apprendre à connaître puis maîtriser ces dernières, mais jamais tu ne pourras les réutiliser…

Je ne dis pas que je ne contribuerais pas à LibreOffice si on me le proposait comme boulot (si vous lisez ces lignes et êtes en mesure de me le proposer, n'hésitez pas) ou si j'en ressentais le besoin ou l'envie… Mais là, présentement, la balance penche plus en faveur de Calligra.

Et je me pose la question : c'est comment avec les autres SGBDR ? Oracle ? PostgreSQL ? MySQL/MariaDB ?

Casquette de DBA PostgreSQL !

Par défaut, les paramètres suivants sont appliqués dans PostgreSQL

1) L'écoute par PG pour les connexions

Il s'agit du paramètre listen_addresses, valorisé par défaut à localhost.
Donc quand tu installes un PostgreSQL, sans opération volontaire ou altération par ton distributeur, il est impossible de s'y connecter depuis un autre endroit que la machine elle-même.
https://www.postgresql.org/docs/current/runtime-config-connection.html

2) L'authentification

L'authentification est gérée par le fichier pg_hba.conf de PostgreSQL.
https://www.postgresql.org/docs/13/auth-pg-hba-conf.html
Le fichier par défaut est comme suit:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     peer
host    all             all             127.0.0.1/32            md5
host    all             all             ::1/128                 md5

local   replication     all                                     peer
host    replication     all             127.0.0.1/32            md5
host    replication     all             ::1/128                 md5

En français :
- les connexions classiques sont autorisées sur la socket UNIX pour les utilisateurs dont le login correspond à un utilisateur dans la base de données
- les connexions classiques sont autorisées sur la loopback pour les utilisateurs identifiés par login/mot de passe dans la base de données
- les connexions pour réplication sont autorisées de la même manière que les connexions classiques.

Je ne répondrai pas pour les autres SGBDR, je laisse des spécialistes de ces derniers s'en charger.

Je prêche certainement des convaincus ici, mais en allant jeter un oeil à ton commit sur le mémory leak (cas 3), je me rends compte que c'est un code signalé par le compilateur par un warning.

Alors oui mais non :(
Ni GCC 10, ni Clang 11, ni clang-analyzer, ni clazy n'ont signalé cette fuite.

        KWPage page = pageManager->page(request->pageNumber()+1);

        pix = new QPixmap(request->width(), request->height());
        QPainter painter(pix);

        QSize rSize(request->width(), request->height());

        pix = new QPixmap();

L'objet alloué inutilement ligne 3 est donné à un objet sur la pile ligne 4. Ce second objet n'est pas utilisé et est détruit ultérieurement.
Mais le compilateur n'a aucune information sur les effets de bord possibles de la ligne 4. Ce serait une mauvaise conception, mais l'objet créé sur la pile pourrait prendre «possession» du pointeur et le détruire à sa libération. Ce pourrait être l'équivalent d'un std::unique_ptr…

Mais je suis parfaitement d'accord, moins de warning est souvent synonyme de moins de bugs. J'ai par exemple trouvé dans Calligra un code qui fonctionnait en 32 bits mais pas en 64 bits grâce à un warning…