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é.
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).
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é.
«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.
En tant que dev, j’ai des ressources limitées et je peux pas garantir que mon code est compatible avec toutes les versions d’une bibliothèque externe.
Donc… si dans tes dépendances, ou les dépendances de tes dépendances, il y a une dépendance stricte à la version 1.2.3 d'une libfoo qui a un trou de sécurité, alors qu'une libfoo 1.2.4 est dispo… tout le monde doit attendre que l'info de la faille remonte toute la chaîne de dépendance jusqu'à ce que tu mettes en ligne une nouvelle version ?
Mettons que cela ne prenne que 2 jours par dépendance. Si ton appli marcel dépend de libbar qui dépend de libfoo, on est déjà à 4 jours d'une faille béante, possiblement exploitée…
Je conçois que l'on mette une dépendance sur une version minimale d'une dépendance, mais une version stricte, j'ai beaucoup plus de mal. Par ailleurs, comment garantis-tu que ton code soit pleinement compatible avec la version X, puis quand une X+1 est disponible, compatible avec cette X+1 ? Un ensemble de tests unitaires ?
Et du coup, question bonus : si libfoo 1.2.4 casse un programme conçu avec libfoo 1.2.3, n'est-ce-pas la faute de libfoo d'avoir rompu une règle élémentaire de compatibilité entre les versions mineures ?
Pas que je sache, mais j'avoue que je n'ai jamais cherché.
Sur une debian c'est aussi simple que apt build-dep calligra et dans le dépôt faire mkdir build && cd build && cmake .. && make -j 42 (en très court, et je déconseille de mettre 42 sauf si tu sais ce que tu fais :) )
Et kdevelop marche très bien sur le projet, ça donne un environnement de travail très agréable.
Ils sortent beaucoup d'appli qui font un peu doublon et qui ne sont pas au niveau :
Konqueror/Firefox
Quand tu vois l'effort sur l'intégration entre Plasma et les navigateurs web (extension «Plasma integration» sur Firefox et Chrome/Chromium), tu ne peux pas dire que tout KDE ignore que les navigateurs web utilisés ne sont pas les navigateurs historiques du projet…
Quand GNOME a annoncé les décoration côté application, KDE a dit que c'était de la merde (je caricature presque pas) et qu'ils allaient proposer mieux. Le soit disant mieux a été proposé mais toujours pas implémenter (la migration vers Wayland prenant du temps à mon avis).
Mais les décorations côté application sont à mon goût la pire connerie qu'il soit. Ça produit un environnement complètement désordonné, dans la mouvance actuelle où le «design» l'emporte sur tout, y compris sur l'utilisabilité.
Je suis encore en X11 actuellement (l'absence de support du protocole de buffer souris par les applications GTK me rend fou), et pour les applis qui demandent au gestionnaire de fenêtre de désactiver les décorations, elles se prennent un changement de config quand c'est possible, une règle KWin sinon.
Ne pas confondre la situation de Konqueror et la situation de Calligra.
Konqueror fait partie de la suite historique d'applications de base de KDE. Calligra, ex-KOffice, n'en a jamais fait partie. Et il n'y a pas d'organe décisionnel au sein du projet KDE qui va dire «ce projet ne sert pas, abandonnez le !». De toute façon… quel intérêt ? Calligra ne coûte au projet KDE que l'espace pris sur le serveur git, un nom de domaine, un peu d'espace sur un serveur web…
Aujourd'hui, il y a à peu près 0.1 personne qui travaille sur Calligra (j'ai recommencé à contribuer y'a ~10 jours après plusieurs années d'absence). Par contre le projet reste fondamentalement différent de LibreOffice et utile par ses différences, en particulier sur l'adaptation aux smartphones/tablettes. L'afficheur de documents de Jolla est basé sur Calligra, Okular a un plugin Calligra, et je compte bien m'assurer que Plasma Mobile soit capable d'afficher des documents également.
LibreOfficeKit pourrait être intéressant à exploiter pour ça, mais ça reste LibreOffice qui aurait besoin d'un énorme travail de nettoyage pour être vraiment pratique sur cet usage, en particulier son temps de démarrage.
Et pas plus tard que ce mardi, j'ai reçu un fichier word (format historique qui plus est) qui s'affichait passablement sur un Google Doc, était illisible sur LibreOffice mais quasi parfait sur Calligra (j'ai eu à faire un patch pour atteindre le parfait à mes yeux, un vieux bug que je n'avais jamais pris le temps de creuser). Rien que pour ça, je veux continuer de coder sur Calligra.
Konqueror est avant tout la victime du web. Maintenir un navigateur web pleinement fonctionnel et utilisable est un boulot devenu colossal et réservé à quelques entreprises. KHTML ne pouvait plus être maintenu par l'équipe KDE à un niveau suffisant, et même WebKit/WebEngine sont limites aujourd'hui pour construire un navigateur web (il faut gérer les webextensions notamment).
Et pour ma part, je n'ai 2 applis GTK : Gimp et Firefox (et aucune application web, non merci)
D'ailleurs, je crois que libreoffice en a même profité en mettant la tête d'openoffice sous l'eau.
C'est ne pas connaître l'histoire que de reprocher la situation à LibreOffice.
LibreOffice est né de go-oo, un fork amical d'OpenOffice maintenu par les distributeurs Linux (Novell, Debian…) afin d'y intégrer divers patchs et outils qui simplifiaient la compilation et la contribution. OpenOffice était alors très très fermé aux contributions externes.
Lors du rachat de Sun par Oracle, go-oo a été transformé en LibreOffice, par crainte des comportements d'Oracle. Craintes justifiées puisqu'oracle a licencié toute l'équipe et choisi de donner OpenOffice à la fondation Apache plutôt que de le donner à la Document Foundation. OpenOffice était encore soumis à un accord de copyright pour toute contribution externe. Du coup on s'est retrouvé avec OpenOffice qui ne pouvait pas reprendre les fonctionnalités de LibreOffice et avec un gros retard en nombre de contributeurs, et de l'autre LibreOffice qui pouvait reprendre les fonctionnalités d'OpenOffice tout en ayant plus de contributeurs.
Aujourd'hui, OpenOffice est dans le coma. Il y a très peu de contributeurs, seul le nom persiste finalement. Et c'est ce que la document foundation reproche : il serait plus sain d'arrêter le projet et de re-fusionner, surtout en l'absence d'élément en faveur d'OpenOffice. Ce n'est pas comme si ils avaient une super interface révolutionnaire, ou une meilleure compatibilité avec tel format ou que sais-je…
Le CSS permet ça sans problème depuis longtemps. Ça n'existe à ma connaissance pas sous Microsoft Word, ni sous LibreOffice Writer.
La norme OpenDocument permet des tailles de caractères relatives y compris dans les styles de caractère, mais relatives au style parent (attribut XSL fo:font-size). Or entre un style de caractère et un style de paragraphe, il n'y a pas cette relation.
Du coup ce que tu demandes ici ne peut se faire sans une modification de la norme OpenDocument, ou l'utilisation d'attributs propriétaires aux logiciels (le temps de faire évoluer la norme), et bien sûr avec quelqu'un qui fasse le développement correspondant et arrive à le pousser.
Je ne dis pas que c'est impossible bien sûr, mais c'est assez compliqué à mettre en place…
Alors, je ne connais pas OnlyOffice. Je rate peut-être un monument, mais il n'est pas dans mes paquets, et comme je ne trouve pas de belles instructions de compilation, je vais pas trop me fatiguer.
Mais allons sur la page ouikipedia et lisons: https://en.wikipedia.org/wiki/OnlyOffice
«As of January 2021, ONLYOFFICE does not support RTL Languages (such as Hebrew and Arabic), and there's no plan to support RTL in the nearest future.»
Bon ben je vais m'arrêter là, je pense que LibreOffice a encore de beaux jours devant lui en seule grande alternative libre et compatible Linux pour Microsoft Office.
Sur ce, je retourne faire du code, je parle pas le russe mais on m'a signalé sur un logiciel un problème de compatibilité avec les encodages pré-unicode pour le russe…
tu te soignes, c'est fini en 7 jours
tu fous rien, c'est terminé en une semaine
Heu… Sans déc, tu l'as déjà chopée ?
Perso je l'ai eu y'a deux ans. J'ai déliré pendant plusieurs jours à cause de la fièvre, j'ai contaminé des gens que j'ai vu la veille du pic de fièvre… Une fois le traitement commencé, ça s'est amélioré assez vite, mais je suis resté épuisé pendant une bonne quinzaine de jours…
Donc «c'est fini en 7 jours» / «c'est terminé en une semaine», ça dépend de ta chance à la loterie.
😳 la vache, tu fais quoi avec ta machine pour remplir 16Gb?
Du dev embarqué notamment, et cross-compiler tout un système du noyau jusqu'à l'espace utilisateur, avec un QtWebEngine dans le lot parce que le client veut pouvoir afficher une page web… Ben avec 16GB j'étais très court. Je ne dis pas que ça ne passait pas, mais je devais fermer pas mal d'applis (IDE, navigateurs web…)
Le debug de gros binaires (pas embarqués pour le coup) est aussi assez délicat et peut consommer pas mal de RAM.
Et je ne parle pas de la virtualisation, quand tu as une VM qui a besoin de 8GB de RAM pour tourner et que tu cumules avec quelques trucs gourmand en local, tu t'approches bien plus vite des 16GB que tu ne l'espères…
Évidemment, je pourrais passer du temps sur tous les outils que j'utilise pour que tel ou tel outil d'analyse de perf soit moins gourmand en RAM, que tel programme soit plus économe… Mais je ne l'ai pas toujours donc j'ai du suivre le mouvement (par contre sur mon nouveau serveur perso j'ai 2GB de RAM et je ne compte pas passer à 4, donc les trucs pas optimisés seront rejetés ou corrigés… faut pas déconner)
Pour être tout à fait franc, mon laptop à bientôt 5 ans, je pourrais pas te dire si j’ai 8 ou 16gb de ram, et j’ai jamais eu de problèmes de ram
Pour ma part, j'ai déjà eu des problèmes avec 16GB où je n'arrivais pas à alimenter suffisamment en tâches mon CPU parce que je tombais à court de RAM… Du coup maintenant je suis passé à 32.
Par contre dans le cas de gens lambda, j'ai déjà vu des machines saturées parce qu'elles n'avaient que 4GB, ce qui était encore fréquent il y a 5 ans, et carrément insuffisant avec un navigateur web moderne et quelques onglets d'applications web ouverts. L'ordinateur de ma compagne était dans ce cas…
après, c’est un peu dommage de tester x86 vs x86, plutôt que le sujet du moment, x86 vs m1.
Si on pouvait coupler des cœurs x86 avec la même archi mémoire que le M1, le résultat serait intéressant je pense. (Bon, et il faut avoir accès à la gravure 5nm de TSMC)
Le M1 met la tannée aux machines x86, tant mieux, mais au prix d'une interdiction d'évolution du matériel. Cf par exemple https://www.theregister.com/2020/11/19/apple_m1_high_bandwidth_memory_performance/
Et entre les performances immédiates et la possibilité d'évoluer mon matériel au fil des ans, je préfère le second. J'ai déjà «prolongé» beaucoup de machines, même portables, avec un changement de stockage ou de RAM. Apple a choisi de mettre le curseur ailleurs, grand bien leur fasse, mais il faudrait clairement l'indiquer quand on clame qu'on a la plus grosse :)
macOS n'est pas un bon système à virtualiser, d'ailleurs il n'y a même pas de moyen officiel de faire une VM macOS même sous mac. macOS est performant sur sa plateforme cible, un mac physique.
Apple autorise la virtualisation de MacOS sur MacOS, ce qui a été testé ici.
J'aimerais bien voir ce test sous un vrai mac avec la puce M1, sans virtualisation (qui à priori est plus performante que certains i5 et i7).
Et dans ce cas ce sera biaisé dans l'autre sens puisqu'aucun OS tiers ne peut tourner sur ces machines pour le moment.
mes projets compilent à quelques secondes près sur chacun d'eux.
Ce n'est pas comparable à la compilation d'un navigateur web ou d'un noyau de système d'exploitation. L'écart qui peut paraître insignifiant (mettons par exemple 0,5s sur un petit projet) va devenir conséquent sur un gros projet, il suffit qu'il soit linéaire avec le nombre de fichiers à compiler.
Mais justement. "master" était un terme parfaitement adapté, sans aucun rapport avec l'esclavagisme.
Je n'ai également jamais vu le "master" de git comme le "maître" d'un esclave mais comme le "master" d'un disque, ou le "maître" que l'on suit, qui nous inspire dans notre travail ou notre formation.
Mes dépôts sont bien maîtres à leur tour. S'ils étaient appelés esclaves d'un maître, ce ne serait pas la même chose.
Tu t'emballes un peu je pense, relis bien son message.
Aujourd'hui, dans le monde, il y a des centaines de milliers, probablement des millions d'esclaves. Fouettés, travaillant jusqu'à la mort dès leur plus jeune âge. Leur sang fabrique les vêtements, chaussures et autres biens à la con vendus à 5 balles nécessaire à la sainte consommation. Pareil pour l'industrie du numérique qui dépend de l'extraction par des esclaves de terres rares en afrique. Ou pour préparer la prochaine coupe du monde au Qatar.
Donc aujourd'hui, oui, les "afro-américains ultra-consuméristes" sont tout autant responsables de l'esclavagisme que les "WASP" et en son temps le "petit bourgeois parisien du XIXè siècle qui voulait sucrer son café". Mais c'est loin l'esclavagisme, on respire tellement mieux comme ça plutôt qu'en ayant nos esclaves à côté de chez nous capables de se révolter ou de nous indigner…
Par contre, quand un flic blanc tire dans le dos d'un afro-américain… je doute que mettre un masque sur la mémoire aide quoi que ce soit fasse à la bêtise crasse et au racisme dégueulasse en jeu ici.
[^] # Re: pourquoi SQL server
Posté par Pinaraf . En réponse au journal SQL Server sous Linux : enjeux de sécurité. Évalué à 3.
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.
[^] # Re: Dans quel cas ?
Posté par Pinaraf . En réponse au journal SQL Server sous Linux : enjeux de sécurité. Évalué à 6.
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é.
[^] # Re: Dans quel cas ?
Posté par Pinaraf . En réponse au journal SQL Server sous Linux : enjeux de sécurité. Évalué à 10.
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) ?
[^] # Re: Dans quel cas ?
Posté par Pinaraf . En réponse au journal SQL Server sous Linux : enjeux de sécurité. Évalué à 8.
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…
[^] # Re: Froid dans le dos
Posté par Pinaraf . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 7.
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).
[^] # Re: Froid dans le dos
Posté par Pinaraf . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 2.
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…
[^] # Re: Froid dans le dos
Posté par Pinaraf . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 9.
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/ :
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…
[^] # Re: Toujours mieux ?
Posté par Pinaraf . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à 3.
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 ?
[^] # Re: Pinning
Posté par Pinaraf . En réponse au lien Le cauchemar de l'empaquetage: côté distrib. Évalué à 6.
Donc… si dans tes dépendances, ou les dépendances de tes dépendances, il y a une dépendance stricte à la version 1.2.3 d'une libfoo qui a un trou de sécurité, alors qu'une libfoo 1.2.4 est dispo… tout le monde doit attendre que l'info de la faille remonte toute la chaîne de dépendance jusqu'à ce que tu mettes en ligne une nouvelle version ?
Mettons que cela ne prenne que 2 jours par dépendance. Si ton appli marcel dépend de libbar qui dépend de libfoo, on est déjà à 4 jours d'une faille béante, possiblement exploitée…
Je conçois que l'on mette une dépendance sur une version minimale d'une dépendance, mais une version stricte, j'ai beaucoup plus de mal. Par ailleurs, comment garantis-tu que ton code soit pleinement compatible avec la version X, puis quand une X+1 est disponible, compatible avec cette X+1 ? Un ensemble de tests unitaires ?
Et du coup, question bonus : si libfoo 1.2.4 casse un programme conçu avec libfoo 1.2.3, n'est-ce-pas la faute de libfoo d'avoir rompu une règle élémentaire de compatibilité entre les versions mineures ?
[^] # Re: Toujours mieux ?
Posté par Pinaraf . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à 6.
Pas que je sache, mais j'avoue que je n'ai jamais cherché.
Sur une debian c'est aussi simple que
apt build-dep calligraet dans le dépôt fairemkdir build && cd build && cmake .. && make -j 42(en très court, et je déconseille de mettre 42 sauf si tu sais ce que tu fais :) )Et kdevelop marche très bien sur le projet, ça donne un environnement de travail très agréable.
[^] # Re: Toujours mieux ?
Posté par Pinaraf . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à 6.
N'hésite pas à me joindre sur IRC (Freenode, pseudo pinaraf) ou mail ou XMPP (pseudo @ pseudo . info) si tu as besoin d'un coup de main…
[^] # Re: Toujours mieux ?
Posté par Pinaraf . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à 10.
Quand tu vois l'effort sur l'intégration entre Plasma et les navigateurs web (extension «Plasma integration» sur Firefox et Chrome/Chromium), tu ne peux pas dire que tout KDE ignore que les navigateurs web utilisés ne sont pas les navigateurs historiques du projet…
[^] # Re: Toujours mieux ?
Posté par Pinaraf . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à 8.
https://invent.kde.org/libraries/plasma-wayland-protocols/-/blob/master/src/protocols/server-decoration.xml ?
Mais les décorations côté application sont à mon goût la pire connerie qu'il soit. Ça produit un environnement complètement désordonné, dans la mouvance actuelle où le «design» l'emporte sur tout, y compris sur l'utilisabilité.
Je suis encore en X11 actuellement (l'absence de support du protocole de buffer souris par les applications GTK me rend fou), et pour les applis qui demandent au gestionnaire de fenêtre de désactiver les décorations, elles se prennent un changement de config quand c'est possible, une règle KWin sinon.
[^] # Re: Toujours mieux ?
Posté par Pinaraf . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à 10.
Ne pas confondre la situation de Konqueror et la situation de Calligra.
Konqueror fait partie de la suite historique d'applications de base de KDE. Calligra, ex-KOffice, n'en a jamais fait partie. Et il n'y a pas d'organe décisionnel au sein du projet KDE qui va dire «ce projet ne sert pas, abandonnez le !». De toute façon… quel intérêt ? Calligra ne coûte au projet KDE que l'espace pris sur le serveur git, un nom de domaine, un peu d'espace sur un serveur web…
Aujourd'hui, il y a à peu près 0.1 personne qui travaille sur Calligra (j'ai recommencé à contribuer y'a ~10 jours après plusieurs années d'absence). Par contre le projet reste fondamentalement différent de LibreOffice et utile par ses différences, en particulier sur l'adaptation aux smartphones/tablettes. L'afficheur de documents de Jolla est basé sur Calligra, Okular a un plugin Calligra, et je compte bien m'assurer que Plasma Mobile soit capable d'afficher des documents également.
LibreOfficeKit pourrait être intéressant à exploiter pour ça, mais ça reste LibreOffice qui aurait besoin d'un énorme travail de nettoyage pour être vraiment pratique sur cet usage, en particulier son temps de démarrage.
Et pas plus tard que ce mardi, j'ai reçu un fichier word (format historique qui plus est) qui s'affichait passablement sur un Google Doc, était illisible sur LibreOffice mais quasi parfait sur Calligra (j'ai eu à faire un patch pour atteindre le parfait à mes yeux, un vieux bug que je n'avais jamais pris le temps de creuser). Rien que pour ça, je veux continuer de coder sur Calligra.
[^] # Re: Toujours mieux ?
Posté par Pinaraf . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à 10.
Konqueror est avant tout la victime du web. Maintenir un navigateur web pleinement fonctionnel et utilisable est un boulot devenu colossal et réservé à quelques entreprises. KHTML ne pouvait plus être maintenu par l'équipe KDE à un niveau suffisant, et même WebKit/WebEngine sont limites aujourd'hui pour construire un navigateur web (il faut gérer les webextensions notamment).
Et pour ma part, je n'ai 2 applis GTK : Gimp et Firefox (et aucune application web, non merci)
[^] # Re: libre ou pas
Posté par Pinaraf . En réponse au journal C'est foutu pour LibreOffice. Évalué à 10.
C'est ne pas connaître l'histoire que de reprocher la situation à LibreOffice.
LibreOffice est né de go-oo, un fork amical d'OpenOffice maintenu par les distributeurs Linux (Novell, Debian…) afin d'y intégrer divers patchs et outils qui simplifiaient la compilation et la contribution. OpenOffice était alors très très fermé aux contributions externes.
Lors du rachat de Sun par Oracle, go-oo a été transformé en LibreOffice, par crainte des comportements d'Oracle. Craintes justifiées puisqu'oracle a licencié toute l'équipe et choisi de donner OpenOffice à la fondation Apache plutôt que de le donner à la Document Foundation. OpenOffice était encore soumis à un accord de copyright pour toute contribution externe. Du coup on s'est retrouvé avec OpenOffice qui ne pouvait pas reprendre les fonctionnalités de LibreOffice et avec un gros retard en nombre de contributeurs, et de l'autre LibreOffice qui pouvait reprendre les fonctionnalités d'OpenOffice tout en ayant plus de contributeurs.
Aujourd'hui, OpenOffice est dans le coma. Il y a très peu de contributeurs, seul le nom persiste finalement. Et c'est ce que la document foundation reproche : il serait plus sain d'arrêter le projet et de re-fusionner, surtout en l'absence d'élément en faveur d'OpenOffice. Ce n'est pas comme si ils avaient une super interface révolutionnaire, ou une meilleure compatibilité avec tel format ou que sais-je…
[^] # Re: Élément qui fait rêver
Posté par Pinaraf . En réponse au journal C'est foutu pour LibreOffice. Évalué à 8.
La norme OpenDocument permet des tailles de caractères relatives y compris dans les styles de caractère, mais relatives au style parent (attribut XSL fo:font-size). Or entre un style de caractère et un style de paragraphe, il n'y a pas cette relation.
Du coup ce que tu demandes ici ne peut se faire sans une modification de la norme OpenDocument, ou l'utilisation d'attributs propriétaires aux logiciels (le temps de faire évoluer la norme), et bien sûr avec quelqu'un qui fasse le développement correspondant et arrive à le pousser.
Je ne dis pas que c'est impossible bien sûr, mais c'est assez compliqué à mettre en place…
# Ou pas
Posté par Pinaraf . En réponse au journal C'est foutu pour LibreOffice. Évalué à 10.
Alors, je ne connais pas OnlyOffice. Je rate peut-être un monument, mais il n'est pas dans mes paquets, et comme je ne trouve pas de belles instructions de compilation, je vais pas trop me fatiguer.
Mais allons sur la page ouikipedia et lisons: https://en.wikipedia.org/wiki/OnlyOffice
«As of January 2021, ONLYOFFICE does not support RTL Languages (such as Hebrew and Arabic), and there's no plan to support RTL in the nearest future.»
Bon ben je vais m'arrêter là, je pense que LibreOffice a encore de beaux jours devant lui en seule grande alternative libre et compatible Linux pour Microsoft Office.
Sur ce, je retourne faire du code, je parle pas le russe mais on m'a signalé sur un logiciel un problème de compatibilité avec les encodages pré-unicode pour le russe…
# T'as déjà eu la grippe ?
Posté par Pinaraf . En réponse au journal genre, ils nous prendraient pour des neuneux ?. Évalué à 10.
Heu… Sans déc, tu l'as déjà chopée ?
Perso je l'ai eu y'a deux ans. J'ai déliré pendant plusieurs jours à cause de la fièvre, j'ai contaminé des gens que j'ai vu la veille du pic de fièvre… Une fois le traitement commencé, ça s'est amélioré assez vite, mais je suis resté épuisé pendant une bonne quinzaine de jours…
Donc «c'est fini en 7 jours» / «c'est terminé en une semaine», ça dépend de ta chance à la loterie.
[^] # Re: Pertinence ?
Posté par Pinaraf . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 3.
Du dev embarqué notamment, et cross-compiler tout un système du noyau jusqu'à l'espace utilisateur, avec un QtWebEngine dans le lot parce que le client veut pouvoir afficher une page web… Ben avec 16GB j'étais très court. Je ne dis pas que ça ne passait pas, mais je devais fermer pas mal d'applis (IDE, navigateurs web…)
Le debug de gros binaires (pas embarqués pour le coup) est aussi assez délicat et peut consommer pas mal de RAM.
Et je ne parle pas de la virtualisation, quand tu as une VM qui a besoin de 8GB de RAM pour tourner et que tu cumules avec quelques trucs gourmand en local, tu t'approches bien plus vite des 16GB que tu ne l'espères…
Évidemment, je pourrais passer du temps sur tous les outils que j'utilise pour que tel ou tel outil d'analyse de perf soit moins gourmand en RAM, que tel programme soit plus économe… Mais je ne l'ai pas toujours donc j'ai du suivre le mouvement (par contre sur mon nouveau serveur perso j'ai 2GB de RAM et je ne compte pas passer à 4, donc les trucs pas optimisés seront rejetés ou corrigés… faut pas déconner)
[^] # Re: Pertinence ?
Posté par Pinaraf . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 2.
On ne parle pas de RAM soudée là mais de RAM dans le SoC. Ce qui est, pour un ordinateur grand public, une nouveauté. D'ailleurs même sur des (grosses) cartes embarquées ce n'est pas systématique, cf. par exemple https://wiki.pine64.org/index.php?title=ROCKPro64#Board_layout ou la Raspberry Pi 4 (https://blog.seeedstudio.com/wp-content/uploads/2020/05/raspberry-Pi-4-8G-update2-.jpg) où les puces de RAM sont à côté du SoC.
Pour ma part, j'ai déjà eu des problèmes avec 16GB où je n'arrivais pas à alimenter suffisamment en tâches mon CPU parce que je tombais à court de RAM… Du coup maintenant je suis passé à 32.
Par contre dans le cas de gens lambda, j'ai déjà vu des machines saturées parce qu'elles n'avaient que 4GB, ce qui était encore fréquent il y a 5 ans, et carrément insuffisant avec un navigateur web moderne et quelques onglets d'applications web ouverts. L'ordinateur de ma compagne était dans ce cas…
[^] # Re: Pertinence ?
Posté par Pinaraf . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 4.
Si on pouvait coupler des cœurs x86 avec la même archi mémoire que le M1, le résultat serait intéressant je pense. (Bon, et il faut avoir accès à la gravure 5nm de TSMC)
Le M1 met la tannée aux machines x86, tant mieux, mais au prix d'une interdiction d'évolution du matériel. Cf par exemple https://www.theregister.com/2020/11/19/apple_m1_high_bandwidth_memory_performance/
Et entre les performances immédiates et la possibilité d'évoluer mon matériel au fil des ans, je préfère le second. J'ai déjà «prolongé» beaucoup de machines, même portables, avec un changement de stockage ou de RAM. Apple a choisi de mettre le curseur ailleurs, grand bien leur fasse, mais il faudrait clairement l'indiquer quand on clame qu'on a la plus grosse :)
[^] # Re: Pertinence ?
Posté par Pinaraf . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 4. Dernière modification le 23 novembre 2020 à 14:25.
Apple autorise la virtualisation de MacOS sur MacOS, ce qui a été testé ici.
Et dans ce cas ce sera biaisé dans l'autre sens puisqu'aucun OS tiers ne peut tourner sur ces machines pour le moment.
Ce n'est pas comparable à la compilation d'un navigateur web ou d'un noyau de système d'exploitation. L'écart qui peut paraître insignifiant (mettons par exemple 0,5s sur un petit projet) va devenir conséquent sur un gros projet, il suffit qu'il soit linéaire avec le nombre de fichiers à compiler.
[^] # Re: Et pour les diplômes ?
Posté par Pinaraf . En réponse au journal GitHub remplace la branche master par main. Évalué à 10.
Mais justement. "master" était un terme parfaitement adapté, sans aucun rapport avec l'esclavagisme.
Je n'ai également jamais vu le "master" de git comme le "maître" d'un esclave mais comme le "master" d'un disque, ou le "maître" que l'on suit, qui nous inspire dans notre travail ou notre formation.
Mes dépôts sont bien maîtres à leur tour. S'ils étaient appelés esclaves d'un maître, ce ne serait pas la même chose.
[^] # Re: linux
Posté par Pinaraf . En réponse au journal GitHub remplace la branche master par main. Évalué à 10.
Tu t'emballes un peu je pense, relis bien son message.
Aujourd'hui, dans le monde, il y a des centaines de milliers, probablement des millions d'esclaves. Fouettés, travaillant jusqu'à la mort dès leur plus jeune âge. Leur sang fabrique les vêtements, chaussures et autres biens à la con vendus à 5 balles nécessaire à la sainte consommation. Pareil pour l'industrie du numérique qui dépend de l'extraction par des esclaves de terres rares en afrique. Ou pour préparer la prochaine coupe du monde au Qatar.
Donc aujourd'hui, oui, les "afro-américains ultra-consuméristes" sont tout autant responsables de l'esclavagisme que les "WASP" et en son temps le "petit bourgeois parisien du XIXè siècle qui voulait sucrer son café". Mais c'est loin l'esclavagisme, on respire tellement mieux comme ça plutôt qu'en ayant nos esclaves à côté de chez nous capables de se révolter ou de nous indigner…
Par contre, quand un flic blanc tire dans le dos d'un afro-américain… je doute que mettre un masque sur la mémoire aide quoi que ce soit fasse à la bêtise crasse et au racisme dégueulasse en jeu ici.