Pinaraf a écrit 3674 commentaires

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…

Si tu es maqué avec les technologies Microsoft, c'est un choix très intéressant : intégration avec un active directory, procédures stockées en C#, intégration avec visual studio… Cf. https://en.wikipedia.org/wiki/SQL_CLR pour la partie procédures stockées (et autres joyeusetés) en .net.

Si tu conçois une application distribuée au delà du réseau d'une entreprise, le VPN n'est pas nécessairement une option… À moins d'assimiler, par exemple, du TLS avec authentification du client par certificat à l'équivalent en sécurité du VPN…
Je pointais simplement que l'argument «la base de données doit être planquée sur un réseau privé» est plus proche du dogme que de l'argument étayé.

Ne pas exposer sa BDD en direct sur internet

Quelle est la différence fondamentale entre exposer la BDD et exposer une API type REST qui donne accès à tout le contenu de la BDD ?
Le pilote pour ta BDD sera probablement dispo dans tous les environnements de développement que tu pourras imaginer, sans même avoir besoin d'un générateur de code pour traduire ton API dans le langage ciblé, voire avec des composants avancés déjà disponibles (traduire une requête en modèle directement exploitable avec tes composants graphiques, par exemple).
La BDD peut faire la gestion de l'authentification, en allant jusqu'au niveau de la ligne dans les tables (Row Level Security dans PostgreSQL, je suppose que SQL Server a un équivalent)
La BDD peut faire abstraction des différents changements (vues, procédures stockées et fonctions, schémas séparés…)
Qu'est-ce-qui ferait donc que fondamentalement, exposer une BDD avec un code lu, relu et rerelu, audité moultes fois, soit moins bien qu'exposer un service HTTP maison par dessus un serveur Web (lui aussi lu, relu etc) ?

J'ai déjà vu des applications clientes qui devaient se connecter à un serveur SQL central à déployer «soi-même».
Dans certaines entreprises, si des gens pas assez formés font ce genre de déploiement, cela va aboutir à un serveur SQL directement exposé pour que l'application marche pour tout le monde… Hé oui, tout le monde n'a pas encore compris le VPN. De plus, là c'est SQL Server qui écoute sur toutes les interfaces. Tu peux très bien avoir ton serveur avec eno0 (internet) et un tun0 (vpn), si on n'y prend garde le SQL server qui écoute sur les deux par méprise…

N'empèche, je suis perso impressionné par la quantité d'entreprises qui font confiance à un prestataire unique, j'ai l'impression d'être seul à vouloir 2+ hébergeurs très différents + des backups "froids" encore ailleurs, et ce pour du largement moins critique que les autres qui pluerent. Je paye certes plus cher (les machines un peu, mais surtout l'admin), mais ça me parait normal de sécuriser… suis-je si anormal de considérer mes données comme très importantes à mon business?

Tu es anormal, oui. La norme c'est des dirigeants qui ne comprennent pas, et/ou qui préfèrent payer moins mais risquer plus… et la majeure partie du temps, ça passe.

J'ai été salarié dans 3 boites, la première n'avait même pas de solution de repli fiable en cas de crash d'un serveur de base de données primaire (les réplicats étaient connus pour être corrompus, les sauvegardes étaient une fois par jour et jamais testées), la seconde était réglo (deux hébergeurs, bascule tous les deux ou trois mois…), la troisième dépend d'un unique hébergeur, une unique baie quasiment, avec des sauvegardes à froid ailleurs (et si la baie crame, c'est on ne sait pas combien d'heures pour remonter toute l'infra ailleurs).

Mais est-ce que les gens ayant des datastore nfs ont perdu accès aux backups de ces datastore ?

Le client impacté dont j'ai eu connaissance n'a pas eu de réponse quand il a demandé où étaient ces sauvegardes, indisponibles actuellement…

Le problème ici est qu'une tonne d'admin du dimanche ont pensé qu'OVH avait un engagement de répliquer les données ailleurs dans leur offre de machines (virtuelles ou pas) et qu'ils demandent à OVH leur données. Bref, qu'ils demandent un service qu'il n'ont pas commandé.

Strasbourg n'héberge pas que du serveur dédié ou virtuel. C'est aussi leur produit «Dedicated Cloud», et là… c'est pas forcément ce qui est écrit dans le contrat, mais sur la plaquette le discours est très fragile et difficile à défendre.
Je cite https://www.ovhcloud.com/fr/enterprise/products/hosted-private-cloud/datastores-nfs/ :

«Snapshots automatiques
Toutes les heures, un snapshot de votre plateforme est pris automatiquement. Il s'agit d'images instantanées des informations présentes sur votre partition. À tout moment, vous pouvez accéder à ces snapshots et récupérer vos données à un moment précis. À noter que leur volume n'est pas comptabilisé dans votre capacité de stockage utile.»

«Sauvegardes automatiques
Afin de vous assurer une continuité de service et éviter la perte de données, nous réalisons des sauvegardes de votre partition sur des supports externes à votre infrastructure. Les informations des 24 dernières heures sont ainsi préservées. Pour pouvoir restaurer une sauvegarde plus ancienne, il est nécessaire d’ouvrir un ticket incident (cette opération vous sera facturée).»

Avec cette description, il est logique que des entreprises aient fait confiance et n'aient pas d'autre plan de secours. Et selon la façon dont cela se traduit dans les contrats, la situation pourrait être très tendue, pour OVH, leurs clients ou les deux…

Avec X11, la règle est que le Window Manager gère les fenêtres, les applications leur contenu. Les applications peuvent éventuellement demander à ne pas avoir de décoration (et donc gérer la leur, feu-XMMS par exemple), mais c'est une exception, pas une règle.
Avec Wayland, la règle dépend du compositing manager. KWin garde le modèle des décorations côté «serveur» quand Weston et GNOME imposent les décorations côté application, c'est-à-dire que le gestionnaire de fenêtres donne un cadre dans lequel dessiner aux applications, et n'y touche pas. Libre à elles de dessiner les boutons d'action, le titre, le contour comme elles le veulent.

Est-ce plus clair ?