barmic 🦦 a écrit 5782 commentaires

J'espère que tu ne va pas me trouver trop relou :)

Il pourrait y avoir des notifications aux outils en cli. Si tu veux les utiliser dans des scripts automatisés libre à toi d'avoir valider leurs autorisations avant.

Mais surtout c'est quoi un outil cli par rapport à un outil graphique ? network-manager est dans une sandbox, mais pas nm-cli ? Il y a un paquet d'outils comme ça, c'est bizarre de considérer que ça doit s'installer différemment et avoir des droits différents alors qu'ils font la même chose voir qu'ils collaborent.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si la métaphore a bien sûr des limites, elle me semble quand même plus joli que la notion de clientèle que transmet la notion de librairie et puis ça reste la traduction correcte au lieu d'utiliser un faux ami.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

un librairie modulaire pour construire un compositeur Wayland.

Je me permet une petite remarque sur la traduction library est un faux ami. Sa traduction française est « bibliothèque ». Bien sûr tout le monde comprends « librairie », mais je trouve dommage d'utiliser librairie plutôt que bibliothèque particulièrement dans un contexte d'une bibliothèque libre. En effet si le résultat est le même (de prendre quelque chose « sur étagère »), le modèle de partage des bibliothèques n'est pas le même que pour les librairies.

Conférences à distance

Covid-19 oblige, de nombreuses conférences ont du être annulées ou transformées en conférences online. Cela s’est-il bien passé ? Quelles conséquences à court et long termes ? Quelques éléments de réponses dans ces deux articles en anglais. Le premier au sujet de la conférence de Red Hat et le second au sujet de la PyCon US.

Je suis dans l'organisation d'une conférence orientée développement. Le snowcamp est un évènement qui se déroule fin janvier chaque année. Cette année nous n'avons donc pas eu de problème. On va voir comment ça se passe pour l'an prochain.

Les conférences en lignes sont un moyen de subsister, c'est utile quand tu es Google ou RedHat parce que la conférence est pour beaucoup une vitrine de ce que tu as à proposer, mais pour des conférences moins teintées d'entreprise c'est assez moyen. Pour les organisateurs comme pour une partie des plus habitués une conférence est un lieu social, une opportunité de rencontrer et de discuter avec des gens du même domaine mais beaucoup plus loin que ton cercle de contact habituel. Les conférences en lignes ça revient à publier des vidéos de présentation avec un direct au départ. Il n'y a pas besoin d'organisateurs pour faire ça twitch et youtube seront heureux d'accueillir toutes les personnes qui auraient quelque chose à dire. C'est gratuit pour les spectateurs et ça peut potentiellement rémunérer un peu l'orateur.

Les annulations ont poussé à améliorer la communication entre certaines conférences (devoxx, alpescraft, snowcamp, blendwebmix, afup, agile grenoble, lehack, riviera dev, voxxed luxembourg, devfest paris, MixIT, tourainetech, devfest nantes,…). C'est super pour améliorer l'entraide et la co-organisation.

La plupart des conférences sont organisées par de petites associations. Souvent il s'agit surtout de s'adosser à un lieu qui fourni plus ou moins de service et impose plus ou moins de règles. Ce sont ces lieux qui vont définir la gueule qu'auront les prochaines conférences (et bien sûr ils ne vont faire qu'appliquer les règles qui seront mises en vigueurs à ce moment là). La densité de personnes, l'obligation de port de masque, la mise à disposition de gel hydroalcoolique,… Tout ça ce sont des inconnues totales.

Tu peux voir un inventaire qui tente d'être à jour de conférence ici : https://github.com/scraly/developers-conferences-agenda (si tu en a d'autres Aurélie sera heureuse d'accepter des PR).

Il y a aussi pas mal d'inconnues lors de la reprise des conférences. Est-ce que les gens voudront venir ? Est-ce que les sponsors continueront à sponsoriser ? Est-ce qu'il y aura toujours des orateurs ? Avant le confinement les entreprises se montraient de plus en plus frileuses à ce sujet (conseillant à leurs employer d'éviter de venir par exemple). Des conférences comme le devoxx qui ont un rayon de diffusion international peuvent se retrouver à redevenir locale. Hors du débat si c'est bien ou pas ça demande un certain nombre de changement organisationnel.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Personnellement ça m'amuse un peu les positions extrêmes car elles renient souvent le droit de faire des compromis, ou de le faire de manière différente. Même si tu mets de l'eau dans ton vin par après, cette partie reste assez typique.

Il ne s'agit pas d'une position extrême, juste de pointer une limite. C'est dommage de tenter de mettre du personnel dans la discussion. Comme tu le dis c'est un compromis et c'est ce que j'ai voulu exprimer en parlant d'assumer.

J'utilise avec parcimonie flatpak. Paspparce que je ne veux pas m'en servir plus mais parce que j'en ai pas besoin de plus. Si un logiciel n'est pas dispo dans ma distribution ou pas dans la version qui me convient je suis là procédure du site officiel etje ne me plain pas.

Il est là ton extrémiste qui exige quelque chose.

Dans mon travail quand je prends une décision, je produit architecture decision record qui décrit le choix et sa raison d'être et pointe les limites connues. Tu aura remarqué que cette question n'est pas dans les 2 points que je trouvais dommage dans flatpak un peu plus haut.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Donc il n'y a pas de raison qu'une mise à jour du runtime casse l'application qui en dépendait.

Ça c'est en théorie. L'ABI ne fait pas tout et les problème sus-nomé de pitivi ne sont pas au niveau de l'ABI je présume.

Si l'ABI est mis à jour ou que le correctif est plus important, le runtime change de version. Les applications maintenues utiliseront la nouvelle version dès qu'ils seront compatibles avec celui-ci et les non maintenus pourront utiliser l'ancien.

C'est là dessus que travaillent les distributions stables.

Les distributions font d'ailleurs beaucoup de travail, parfois bancal pour s'assurer que l'ensemble fonctionne. Car à quelques exceptions près, toute application doit utiliser la même version d'une bibliothèque alors qu'elles ont rarement été développées pour ces versions.

C'est exactement ce que tu décris, ils restent sur la même ABI donc comme tu le dis plus haut il n'y a pas de raison que ça ne marche pas hors effectivement ça ne marche pas.

Donc cela requiert beaucoup de tests, de correctifs manuels dans tous les sens pour s'assurer qu'elles seront fonctionnelles.

Beaucoup de tests oui bien sûr si tu prend debian tu ne peux pas envisager 60k paquets et un logiciel de la même façon c'est évident. Mais en terme de correctifs manuels, je ne crois pas qu'il y en ai tant que ça (je serais intéressé de regarder). Debian s'est fait connaître à cause de plusieurs histoires là dessus, mais cet éclairage important sur quelques cas donne une fausse impression qu'il y a beaucoup de modifications.

Flatpak apporte la possibilité de le faire en plusieurs étapes. Les applications très maintenues peuvent bénéficier très vite des derniers correctifs, les applications qui le sont moins en profiteront quand elles seront prêtes. Et entre temps, l'utilisateur peut profiter de toutes ses applications.

Il peut profiter de ces vielles applications des failles de sécurité qui vont avec, de l'occupation disque des runtime devenu obsolètes,… En soit cette flexibilité a un coût avec ou sans flatpak, c'est quelque chose à assumer.

Comme je l'ai précisé dans l'article, le fonctionnement traditionnelle d'une distribution n'est pas magique. Elle fait un compromis qui a ses avantages et inconvénients pour l'utilisateur comme les mainteneurs. Flatpak propose un autre modèle, avec aussi ses avantages et inconvénients. Aucune solution n'est parfaite et universelle. Il est bon de le reconnaître.

On est tout à fait d'accord. Je ne viens pas dire que les distributions sont la solution. Flatpak est une brique très intéressante, il faut tout de même être conscient de ses limites et que c'est une solution encore jeune qui va encore évoluer en fonction de son usage et des problèmes rencontrés (la création de paquet ne semble pas toujours aisée d'après devnewton - ça fait aussi parti de ce qui me donne l'impression que la démarche loin d'être universelle a était de remplir les besoins des application Gnome et KDE -).

Je ne suis moi même pas sur une distribution vanilla et utilise une distribution stable pour l'énorme majorité de ce que j'utilise et installe moi-même les quelques logiciels dont j'ai besoin qu'il soit à jour. C'est ma façon de faire et je ne doute pas qu'elle ne convienne pas à tout le monde.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est un avis tout à fait personnel, mais je trouve que les runtimes standards/classiques/supportés son beaucoup trop gros.

Pour info n'importe qui peut créer ou maintenir un runtime pour en avoir des plus petits s'il le juge nécessaire.

C'est pour ça que je parle des classiques/standards/supportés et oui je ne l'ai pas dis mais ce n'est pas forcément un problème systémique, ça peut évoluer.

Mais si tu utilises beaucoup de ces applications ensemble, finalement tu seras proche de la taille d'installation qu'avec ta distribution préférée aujourd'hui.

Je sais bien et je me doute que le choix est fait pour simplifier la vie des développeurs qui ont moins de question à se poser. C'est important quand comme c'est le cas de flatpak tu es bon dernier arrivé. Si tu embête les développeurs, ton store restera vide et ne servira à rien.

Mais malgré ça cette taille pose des problèmes. Par essence flatpak est fait pour gérer de la profusion et de la simplicité pour l'utilisateur. Avoir plusieurs versions d'une même application, installer la petite application Qt alors que ton bureau est gtk,… Ce sont des comportements explicitement encouragés par flatpak (ce qui est bien), mais les runtimes vont se multiplier. L'espace disque c'est pas chère, mais tu le vois à l'usage. Télécharger et installer en 3s ou en 30s ça n'a rien à voir en terme de ressenti pour l'utilisateur que celui-ci soit un utilisateur final ou un développeur.

Et si je parle de Qt ce n'est pas pour rien. Il existe des applications juste Qt, est-ce qu'il vaut mieux qu'elles utilisent KDE qui est immense pour elles, mais qui augmente la potentielle réutilisation ou bien une plus petite qui va tuer la réutilisation mais être plus légère pour ceux qui n'utilisent pas KDE.

Donc oui pour installer une application en Flatpak seulement, ce sera un gros poids en plus. Mais si ton système repose dessus (comme c'est le cas avec Silverblue) finalement ça devient intéressant.

Je ne parle que flatpak en soit et pas de silverblue, mais même lui est sujet à ce problème il l'est juste moins.

Aucune solution existante ne permettait de gérer tout ça à la fois.

Ce n'est pas ce que j'ai dit. J'ai dit que je vois les même travers que les débuts de docker en particulier et que je ne serait pas surpris que dans les prochaines années on voit les même mouvements. Le contexte est différent et on peut imaginer que ça n'arrivera pas et c'est tout ce que je leur souhaite, mais j'en serais surpris.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ensuite si je prends l'exemple de Pitivi, celui-ci nécessite souvent des versions assez précises de bibliothèques. C'est totalement trivial et transparent en flatpak. Avec des dépendances aur, deb ou rpm, c'est très souvent cassé.

Le problème n'est pas le système de paquet et flatpak ne sera pas une solution. Si le runtime sur le quel s'appuie Pitivi est mis à jour avec une version d'une dépendance qui le casse tu ne pourra pas le mettre à jour (même si ce nouveau runtime fixe des CVE ou apporte une version d'une autre dépendance qui elle t'apporterait quelque chose). Ça n'est qu'à peine plus enviable et c'est la situation que tu as déjà en moins bien avec une distribution stable.

En utilisation flatpak ça fonctionne très bien depuis bien 2-3 ans. Les snap la dernière fois que j'ai essayé, c'était encore bien laborieux, en termes de rapidité de lancement, homogénéité des thèmes, qualité, suivi des versions des logiciels …

Ce que t'es entrain de dire c'est que les distributions font mal leur travail. C'est possible, mais je pense que si on envisageait sous ce biais là on pourrait parler de solutions très différentes et potentiellement bien différentes.

Donc en temps qu'utilisateur c'est vraiment bien plus simple et souple qu'un système de paquets à l'ancienne.

Tu apprends dans les journaux qu'il y a une CVE critique sur libBiduleTruc. Ils viennent de sortir les versions 1.2.123, 1.4.3 et 2.0.4 qui corrige la faille. Comment tu t'assure de ne pas l'avoir ? Qu'est-ce que tu fais de pitivi qui va planter avec la dernière version des runtimes ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Une application est liée à un ou plusieurs runtimes (contextes d'exécution en français dans la dépêche).

C'est un avis tout à fait personnel, mais je trouve que les runtimes standards/classiques/supportés son beaucoup trop gros. Grosso modo quand on en voit la taille et comment ça a était fait, c'est fait pour avoir des distributions linux relativement complète (c'est presque l'équivalent de kde-plasma-desktop). Ça donne l'impression que c'est avec des œillères, il y a d'autres solutions qui existent depuis plus longtemps ça aurait était intéressant de faire un état de l'art avant de pondre quelque chose et pas que d'un point de vu technique mais aussi d'un point de vu écosystème. Et ailleurs on voit que la taille de ces choses là est importantes.

L'autre point qui est dommageable amha c'est le fait de complètement orienté la techno pour les bureaux. Ça complexifie le travail des distributions qui ne sont pas particulièrement orientée bureau. Elles doivent jongler avec ces 2 profiles qui sont tout à fait arbitraires.

Pour un travail qui se veut standard et issu d'un consensus (contrairement à snap par exemple), je trouve que ça aurait pu être bien mieux.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Par exemple, les environnement virtuels Python ont réglé de nombreux problèmes, mais quand on analyse, on a simplement transféré un fardeau sur l'utilisateur.

Hum ? virtualenv n'est pas fait pour l'utilisateur de ce que je crois en savoir. Donc rien est transféré à l'utilisateur.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai toujours utilisé dia personnellement. Il fait pas des schémas très sexy, mais il fait le taff et permet de faire des liens fléchés qui sont maintenu et ça c'est vraiment cool. LibO peut faire ce genre de choses, mais le logiciel est bien plus lourd et un résultat plus sexy mais pas tant suffisamment pour que ça me fasse y passer.

C'est cool qu'il garde un développement actif, il est presque resté le même depuis que j'ai commencé à l'utilisé il y a plus de 10 ans maintenant.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Hazelcast fait références aux premiers GCs qui mettaient en pause la JVM

Tu parle du stop the world que G1 a encore ? (Doc Oracle de G1)

@+

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il se place comment par à rapport à d'autres solutions ? Je connais surtout Zenitram qui est très réputé en terme d'alerte par exemple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Concernant le profiling, c'est un peu plus gris, en Java je vais préférer que tout soit dans une même JVM pour avoir une vision globale et juste (historique des threads et lock dans JProfiler par exemple).

He ben ce n'est pas l'avis de certains développeurs de base de données clef-valeur en mémoire pour java qui préconisent d'avoir plusieurs JVM de tailles réduites et expliquent qu'on a de meilleures performance en lui dédiant du matériel (page 28). À savoir qu'hazelcast possède les 2 modes il peut être utilisé comme bibliothèque et comme cluster à coté.

Pour les statistiques NoSQL que tu présentes, se pose en effet la question de savoir si le nombre de drivers est lié à la simplicité du protocole.
Autre réflexion :
plus une base de données est populaire,
plus le nombre d'utilisateurs est grand,
plus le nombre d'utilisateurs de langages peu utilisés est important,
plus la probabilité qu'un développeur/utilisateur se colle à la création du driver est importante.

Tu en raconte des trucs, mais en l'état tu remet en cause ce qu'avance les développeurs de redis avec uniquement des « bouts de réflexions ». Pour le reste du commentaire je ne vois qu'à moitié où tu veux en venir et tu t'es amha perdu dans la conversation.

Bref :

• là où la question des drivers peut être critique pour une base de données qui se crée, ils sont parti avec cette idée et ça a semble-t'il marché. Ça ne veut pas dire que c'est l'unique solution, c'est celle qu'ils ont choisi et tu peu difficilement avancer qu'ils ne sont pas arrivé à leurs fins
• pas mal de base de données utilisent ou proposent des protocoles textes sans que ça ne semble les rendre inutilisables (redis donc, mais aussi elasticsearch, couchdb, hazelcast a une API rest,…) comme quoi ça ne doit pas être aussi bloquant que cela
• tu sors des arguments qui se mordent la queue, tu n'a pas a le faire car des gens l'ont fais, merci, mais si tu regarde de plus prêt des langages relativement récents tu va voir que, le choix de base de données va d'un coup se limiter, tu as le droit de dire que tu t'en fout, mais c'est pas la question

Bon du coup j'en était à ma seconde tentative. La discussion n'est pas plus intéressante qu'auparavant. Si tu n'a rien de plus concret que ça a avancé je vais t'abandonner ici. Le fait qu'il ai débat et que je puisse te pointer des développeurs de différents projets qui ont un avis différents du tiens pourraient te montrer que, les choses ne sont pas aussi simples que tu l’avançais au départ (les protocoles textes et l'utilisation d'un serveur unique de base de données clef-valeur sont mauvais, avancé avec une certaines véhémence et aplomb), si ça n'a pas suffit je ne serais pas en mesure de te convaincre. Bref restons-en là.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

AMHA le point le plus essentiel c'est pas une question d'init uniquement ou pas. C'est des approches différentes.

Quand tu conçois un système tu peux avoir 2 approches différentes (c'est une dichotomie il y en a d'autres) :

• la méthode sysv : tu est simple et basique et tu expose la complexité à tes utilisateurs
• la méthode systemd : tu prend pour toi la complexité, les utilisateurs ne l'ont pas

Tu retrouve ce découpage dans pleins de choses : pour le web en python les micro framework face à django par exemple. Les outils de builds à la maven face à make ou ant.

Ces dernière années on a tendance à décrire les simples comme non-opiniated et les autres comme opiniated. On parle aussi du principe de convention over configuration pour les second.

Comprendre cette différence c'est à mon avis important pour comprendre la démarche à adopter face à chacun d'eux.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le message initial de questionne pas l'utilité, il demande autre chose. Tu va voir le 5ème boulanger et tu lui dis qu'il aurait été judicieux d'ouvrir une pâtisserie.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si ce n'est que ça :)

perl -ne'while(/O/g){print chr(65+$-[0])}' input.carte

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Waow vous utilisez des tellement concis !

perl -ne'while(/O/g){print chr(97+$-[0])}' < input.carte

:p

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Du coup, dans ce cas, les performances apportées par le service de cache ne serviront à rien car un cache local ferra le boulot, non?

Quel cache ? Par défaut tu as un cache en lecture sur le système de fichier et tu peux avoir quelque chose au niveau de ton driver de base de données. Ce sont des caches pour les quels tu as très peu de contrôle (politique d'éviction par exemple, politique d'insertion,…). Imaginons un cas tu accède à une API qui est payante ou qui limite ton débit (elle te demande à ne pas lui envoyer plus de N requêtes par seconde), tu va trouver dommage de te contenter d'un cache local.

Je loupe surement quelques choses, car il "semble" (https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/) que les threads sont plus rapides à démarrer que les processus, et le temps de "context switch" est plus court pour les threads.

Tout à fait, si tu fait du calcul intensif. Et tu as même la possibilité de partager de la donnée entre tes threads sans sérialisation. Mais tu as pleins d'autres paramètres que ça à prendre en compte. Le plus classique c'est que si tu as un gc tu veux des processus les plus petit possibles. Au niveau du système d'exploitation, tu perds toute flexibilité de monitoring et d'administration. Si tu veux privilégier les réponses aux requêtes (qui ne sont pas forcément toute en lien avec ton cache), tu va peut être demander à ton OS de privilégier l'un sur l'autre. Ton process va aussi être une cible de choix pour l'OOM killer. De manière moins précise je n'ai toujours eu que du positif à découper ce genre de chose mais là je n'ai rien de plus à présenter que ça donne l'impression que la machine « respire mieux ».

Il est possible de le faire en PHP, voir https://www.php.net/manual/en/book.shmop.php

S'il est activé et que tu utilise fpm ou en module de ton serveur web.

souvent les caches c'est le premier truc que tu veux virer au démarrage d'une appli pour être dans un état connu,donc à priori, stable

Alors si tu es instable à cause de ton cache le problème c'est pas le cache :) Ce comportement vient surtout du fait qu'on veut mettre à jour le cache au démarrage on est pas sûr qu'il soit à jour et on préfère le détruire (c'est l'équivalent du shift+F5 sur ton navigateur). Si tu as la possibilité de savoir qu'il est à jour, il n'y a pas de raison de le détruire.

Ce "problème" (ou "faux problème"), […]

Et hop ! On file dans la rhétorique. C'est toi qui te demandais si on est toujours dans l'informatique ?

[…] tu l'as pour les bases de données sous le nom de "driver" JDBC/ODBC/etc… développés et fournis par les développeurs des bases de données.

Alors ODBC c'est du "système" et l'idée c'est d'implémenter sous forme d'une bibliothèque partagée et que les langages puisse juste s'interfacer à un driver ODBC sans avoir à réimplémenter le driver… Comme quoi c'est un problème qui n'existe tellement pas que des gens essaient de le résoudre.

Tu trouvera JDBC et DBI qui sont des API respectivement en java et en perl qui définissent un driver standard (en natif dans leur langage ou ODBC) et proposent une API dessus. C'est la même idée.

Bon toutes ses API sont liées à SQL quand tu es un NoSQL tu peut abandonner l'idée de ce type de partage. Il y a quelques tentatives, mais c'est pas tr_s développé et plutôt compliqué.

Maintenant, si on regarde plutôt que de juger. Prenons quelques base de données NoSQL :

• MongoDB : supporte 39 langages (officiel + communauté)
• Apache Cassandra : supporte 16 langages
• CouchDB : 23 langages
• redis : supporte 50 langages

C'est une corrélation et pas forcément une causalité, mais disons que si des développeurs disent « on fait ça pour simplifier, la vie des développeurs de drivers » et ils ont semble-t-il¹ plus de driver que les autres. C'est peut être un faux problème, hein ? Mais bon, il va falloir des arguments en plus pour me faire remettre en cause leur dire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais je peux me tromper…

D'après toi pourquoi ils ont appelé ça un fairphone ?

Ce sont les tenants du système ; et dans la mesure où ils ont un impératif : maximiser leurs revenus (via leurs volumes) et minimiser leurs coûts (via nos salaires), j'ai comme l'impression qu'il y a une incompatibilité quelque part…

Le « système » ? C'est quoi ? Ici la société qui vend le fairphone explique travailler pour que les ouvriers de productions soient mieux payé, limiter autant que possible les matériaux à problème et faire attention aux importations de terres rares entre autre. Ils ne disent clairement pas que c'est parfait, mais qu'ils travaillent en ce sens.

Il est possible de remettre en cause ce qu'ils font. Mais on est dans une démarche bien plus concrète que « le système il est pas bien, on peut rien faire ».

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pardon je ne suis pas allé jusqu'à lire vraiment le fameux main.rs. Je ne lis pas encore couramment le rust. C'est la référence à dwm qui m'a trompée.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je me suis même dit : « Encore un journal bookmark ! ».

Pétard ça va vite ! Il a codé un truc il le partage avec nous, c'est loin d'être un journal bookmark (quelque soit sa forme).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça c'est parce que tu fais un procès d'intention. Tu peux penser qu'une 2ème distribution Linux c'est utile, mais qu'une 2563254ème ne l'est peut être pas autant.

1. Qui est juge de l'utilité ?
2. Pourquoi ça devrait être utile ?

Ou dis autrement pourquoi est-ce que le fait que ça ne soit pas utile à une ou plusieurs personnes ici devrait remettre en cause ce projet/code/partage ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bravo ! Et merci de partager :)

DWM au niveau de la configuration (fondée sur du code).

J'ai utilisé un temps tout ce que fais suckless, mais au final je suis pas super fan de cette manière là. Je préfère xmonad.

• dwm on fork le code pour le modifier et se faire notre propre build.
• xmonad est une bibliothèque haskel, tu récupère la bibliothèque et tu écris la fonction main qui lance cette bibliothèque.

Cette seconde solution est bien plus simple à appréhender. Elle est aussi plus élégante je trouve. Enfin on est moins sujet, comme c'est le cas avec dwm à avoir des séries de patch à appliquer potentiellement dans un ordre donné et qui sont très sensibles aux mises à jour du code upstream.

Voila c'était juste au cas où ça te donne l'idée.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ah ! Ah ! Ça fais des années que j'utilise xournal, mais jamais que pour éditer des PDF. Je ne savais qu'il pouvait servir à autre chose :) Bon je n'ai pas besoin des autres usages, mais c'est quand même bon à savoir .

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Contrairement à ce que tu penses, cela m’intéresse de comprendre pourquoi on a arrive à des architectures logicielles compliquées pour des résultats catastrophiques sans que personne ne se remette en question (d'où les quelques exemples cités).

Je vais réessayer alors. J'ai du mal à construire un fil conducteur donc ça va être une série de remarques et il faudra probablement que tu veuille faire l'effort de comprendre pour… comprendre.

Pour une utilisation comme cache (c'est la première idée qui vient en tête). Un cache ça sert à stocker le résultat d'un traitement pour y accéder plus rapidement. Tant que le traitement en question est significativement plus long que la lecture depuis cette base de données, ça peut rester pertinent.

Le fait de séparer les processus qui servent au cache plutôt que de l'intégrer dans ton logiciel peut avoir pleins d'intérêts différents :

• d'une part un système d'exploitation préfère avoir 2 processus de 4Gio qu'un seul de 8, mais là tu n'es même pas symétrique tu peut avoir une partie applicative peut être bien plus petite en déléguant tout le stockage de grande quantité de données en mémoire à quelque chose d'autre. Si tu sais que tu n'en manipule qu'une quantité faible, ça peut être intéressant ;
• tu peux ne pas avoir le choix, comme je le disais plus haut avec PHP et du cgi tu ne peux pas faire autrement (de même avec du serverless) ;
• tu peux vouloir que ton cache survive à un redémarrage de ton applicatif ;
• tu peux vouloir que ton applicatif scale horizontalement et ne pas en avoir besoin pour ton cache. Tu peux lancer autant de fois ton appli la faire pointer vers ton serveur de cache et ton cache n'est pas limité à chaque instance. Bien sûr avec une solution comme robert pour le moment ça t'empêche de le faire coté cache, mais il n'y en a pas forcément besoin. Tu pourrais aussi imaginer faire interagir tes applicatifs pour qu'ils fassent les échangent eux-même :
  • ça complexifie l'auto scaling (il faut du service discovery, du graceful shutdown, etc)
  • cette complexité peut être très dommageable, la vitesse de démarrage et d'arrêt peut être un enjeu important pour limiter les coûts de ton infra si tu es dans cloud par exemple
  • ça augmente la complexité de ton application, elle fait pleins de choses différentes ça multiplie les droits que tu va devoir lui donner et rends son observation plus compliquée

Il y a probablement pleins d'autres points.

Pour ce qui est du protocole texte, je ne peux que paraphraser ce que dis redis. Ça simplifie le développement des bibliothèques et simplifier la vie des développeurs pour ne pas avoir toi même à créer un client pour chaque langage de l'univers c'est plutôt sympa. Ça simplifie aussi le debug parce que tu peux facilement voir sur le réseau ce qui se passe sans avoir à implémenter sur wireshark et éventuellement d'autre logiciel, le décodage de ton protocole.

Voila c'est quelques points lancés comme ça, juste pour avoir quelques critères qui peuvent remplacer ta dichotomie cluster de cache/dictionnaire dans ton langage.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll