barmic 🦦 a écrit 5976 commentaires

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

Mais si ton appli est capable d'avoir des infos, pourquoi elle freeze ? Quand l'appli freeze, c'est qu'elle est en attente sans en savoir plus. Que veux-tu dire à l'utilisateur qui permettra à lui de changer la situation, quand tu es en attente d'une machine à l'autre bout du réseau ?

Ok en fait on ne s'est pas compris.

Le freeze c'est le fait qu'une interface graphique ne réponde plus.

Tu peux très bien organiser ton code pour que le fil d'exécution qui gère l'interface ne fasse que la gestion de l'UI et interactions avec le gros du logiciel. C'est l'architecture qui était généralisée sur BeOS (d'où le commentaire plus bas). C'est ça qui est reproché.

Mon point de vue c'est de vous demander de pousser la réflexion plus loin que la première étape qui est le feedback visuel, en se demandant ce que ça va changer à l'issue de la tâche qu'est en train d'effectuer l'utilisateur.

Déjà avoir systématiquement ce retour ce serait énorme. C'est ce feedback qui permet à l'utilisateur de mieux comprendre ce qui se passe et pourquoi des choses prennent du temps. Et ça lui permet de faire des choix plus éclairé que ce que son imagination va donner.

Ensuite la logique voudrait que tu ne puisse pas modifier un traitement en cours, uniquement l'annuler. Mais c'est un pas bien plus compliqué à mettre en place.

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

Bref, l'idée n'est pas de donner des leçons ou d'arriver avec mes gros sabots

alors que plus haut :

N'as tu pas une petite liste dans un coin des technos/logiciels bien mauvais que tout le monde utilise?
Démontrant ainsi que la popularité n'a rien à voir avec la qualité?

Tu n'a pas l'air d'être particulièrement intéressé parce que je t'explique jugeant que je prends pour exemple de mauvais logiciels sous seul prétexte qu'ils ne suivent pas tes préceptes.

Les choses ne te plaisent pas tant pis pour toi. Ton objectif semble ne pas être d'échanger, mais de te plaindre en multipliant simplement les exemples sans liens (autre que d'être des logiciels) et d'en tirer des conclusions aussi intéressantes que « tout le monde il est méchant, ils ne comprennent pas ce que je leur explique ». Je ne serais pas ton client plus longtemps. Passe un bon week-end.

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

C'est écrit donc c'est vrai?

J'ai pris Redis car c'est LA référence¹ du domaine et qu'il est massivement utilisé. Ils ont considéré que le gain en performance ne valait pas les autres avantages. Il existe des alternatives à redis, qui font des choix différents. Mais force est de constater qu'il reste une place pour redis, malgré l'API ASCII et pendant longtemps l'absence de cluster.

Personne n'est donc plus "au courant" que par exemple le nombre 2 milliards, transféré en ascii va prendre 10 octets, et en binaire seulement 4 octets?
Et que dire du temps CPU pour convertir l'ascii ?

Ce que disent les mainteneur de redis, c'est que ce n'est pas la seule chose qu'il faut regarder et qu'ils sont prêt à payer ce coût face à d'autres avantages. On parle d'un projet qui fonctionne et qui fonctionne très bien depuis longtemps. Il a des challengers qui ont des protocoles binaires, mais ça n'a semble t'il pas suffit à le détrôner. Je veux bien te proposer d'aller en discuter avec eux, mais si tu viens avec tes gros sabots comme ici je doute que tu sois bien accueilli…

Je ne vois pas l’intérêt de Redis pour un seul serveur, une librairie faisant le même boulot, ne suffirait-elle pas?

Intéresse toi au modèle d'exécution de PHP ou des (fast)CGI par exemple. Quand tu fais spawn un process par requête (ou que tu fais un pool de thread) ça va coincer. Si tu n'a pas ou si tu ne veux pas manipuler des threads toi-même comme avec node ça peut être intéressant.

A moins que l'on considère que l'appel d'une fonction est "comparable" à l'appel d'un service réseau.

Ce n'est pas l'appel d'une fonction, c'est un IPC que tu dois utiliser donc tu a ton coût de sérialisation quoi qu'il arrive (sauf éventuellement si tu utilise des threads et pas de process, mais tu as toute la protection à fin d'être thread-safe à gérer. Plus un autre pour nettoyer tes données. Les caches sous forme de bibliothèques ça existe, mais c'est des contextes différents.

Bref, ce que fais Redis en réseau peut très bien être fait par une l'utilisation d'une librairie pour les besoins que tu précises (optimisation pour les gros volumes, fragmentation, …) sans requérir un service.

Ça dépend du contexte. Mon po objectif c'est de te montrer qu'il y a pleins de contexte différents qui amènent à des solutions différentes et donc des solutions différentes. L'exemple de redis n'est là que parce que c'est un exemple réel qui coche toutes tes cases tout en ayant sa place et ses utilisateurs.

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

Et donc, le REPL. Y'a des langages évolués qui émergent, mais aucun n'a un si bon REPL, voir aucun REPL du tout. Le temps écriture -> test -> validation -> je recommence est bien plus rapide et fun avec un REPL.

C'est joueur de dire ça quand il y a ipython en face :)

J'ai dans ma todo list à aller voir du coté de clojure. « Bouh c'est pas bien c'est sur la jvm ! » Moi je m'en sert au quotidien et j'en suis bien content de cette jvm. Clojure a d'intéressant pour moi qu'il a une alternative que je trouve très cool aux fluent API : les transducers. On garde la composabilité, mais on inverse l'application. Le traitement composite est une élément de première classe qui peut être nommé et même composé pour enfin s'appliquer sur de la donnée. Ça évite les compositions fluent qui deviennent lourdingue à cause de leur taille

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

Désolé de la digression, mais t'es tombé pile sur un truc qui m'énerve.

Pourquoi poster un commentaire énervé à 1h du mat' ? (si tu es dans la tz de Paris)

Alors pour le partage réseau, déjà, est-ce que c'est un partage abstrait par le VFS ou alors une API spécifique à Nautilus (ou une lib qu'il utilise spécifiquement) qui lui permet de savoir que c'est un partage réseau ? Dans le premier cas, ça obligerait à complexifier le cas pour tous les accès même locaux, et ça causerait sûrement plein de problèmes de consommation et complexification supplémentaire pour uniquement ce problème particulier. Dans le second, il y a effectivement peut-être des choses à faire, mais il faut essayer de comprendre le besoin : le réseau ajoute intrinsèquement des latences, alors combien de temps il faut attendre avant de dire qu'il est « en carafe » ? Est-ce une erreur transitoire ou permanante (et on démonde le partage) ?

Dans le premier cas ça permet aussi de gérer les disques qui ont des erreurs (physique, mal branchés, autre). C'est une I/O ça peut planter tenter de ne gérer que les cas que tu imagine c'est généralement en oublier un énorme paquet. Et en terme de complexité ça n'est pas forcément si incroyable que ça. Du moins ça peut l'être si ton design a était prévu pour.

Certes, pouvoir fermer la fenêtre devrait être une option accessible, mais si je peux me permettre le tirage de cheveu, la question de l'informatique a toujours été de cacher les modalités, et là donc la modalité du « je suis dans un dossier du partage réseau », que tu la recrées en fermant la fenêtre et en allant en rouvrir une autre pour aller au même endroit et te reprendre la même erreur… quel intérêt ? « Attendre que ça revienne » peut être une solution également valable ! Ça me fait penser à ceux qui rechargent leurs pages pour régler leur problèmes : TCP a été inventé (dans les années 70 !) pour réessayer à votre place, sans que vous ayez besoin de le faire vous-même ! (vous n'êtes pas des machines ! Bien que les devs prennent souvent leurs utilisateurs pour des automates débiles)

Si tu freeze ton application, flinguer ton application est la seule option qui reste à ton utilisateur. Si non tu pourrais lui expliquer ce que tu es entrain de faire, ce qui plante, lui donner des billes pour savoir si c'est transitoire ou non…

Corrigeons d'abord ces conneries afin d'avoir un réseau plus fiable, après on aura moins de problème avec les GUI.

Donc au lieu de faire en sorte que les UI restent réactives donnent des info à leur utilisateurs, il faut qu'ils investiguent eux-même d'où vient ton freeze, qu'ils regardent toutes les I/O de leur machine et potentiellement de leur réseau et corrigent le problème. Tant pis si tu es sur un wifi publique ou si ta connexion est mauvaise (réseau mobile hors jolies 4 ou 5G ou alors ligne physique mais en défaut sur le moment) ?

Les développeurs d'intellij sont entrain de bosser là dessus comme ils l'ont dis au début de l'année (IntelliJ Platform Roadmap for 2020).

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

De ce que je comprend maintenant ton système n'a d'utilité que si il est au centre d'une architecture multi-serveurs (sinon pourquoi ne pas avoir une hashmap/un graphe directement dans l'appli, plus simple et plus rapide). Donc réservé aux gros déploiements.

Redis est massivement utilisé pour un seul serveur (au pif il est préconisé pour l'installation de nextcloud) et il utilise un protocole texte (la doc. Vouloir donner beaucoup de contraintes à ce logiciel pour mettre en défaut ses choix ce n'est pas très aimable je trouve.

sinon pourquoi ne pas avoir une hashmap/un graphe directement dans l'appli, plus simple et plus rapide

Les map de ton langage ne sont pas forcément très fortes pour gérer de gros volumes dans le temps (avec des stratégies pour limiter la fragmentation par exemple), elle ne fournie pas d'expiration, tu peut vouloir accéder à ses données dans ton serveur et dans un p'tit utilitaire installé sur ton serveur par exemple,…

Quand on a ce genre d'architecture, on cherche l'optimum, car perdre 5% de performances c'est payé quelques serveurs de plus pour "rien".

Ce n'est probablement pas le usecase de robert comme ce n'est que difficilement le usecase de redis (le mode cluster - pas master/slave - n'est arrivé que récemment et sans ça ta montée en charge est fortement contrainte).

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