Bonjour tout le monde,
J’ai le plaisir, pour ce premier message sur LinuxFr.org, de vous annoncer un nouveau projet de stockage clé‑valeur en mémoire vive.
« Encore un » vous direz‑vous ? Certes. Voyons si j’arrive à vous convaincre.
N. D. M. : à ne pas confondre avec le protocole ROBERT (ROBust and privacy‐presERving proximity Tracing) qui vient d’être publié par l’INRIA et la Fraunhofer AISEC pour le suivi de contacts dans le cadre de la pandémie de Covid‑19.
Sommaire
- Présentation de « Robert », votre nouvel ami
- Documentation et informations techniques
- Développement et licence
- Intérêts et fonctionnement
- Travaux en cours
- Super, ravi(e) mais à quoi ça sert vraiment ?
Présentation de « Robert », votre nouvel ami
Le projet se nomme ainsi pour plusieurs raisons :
- c’est un projet entièrement francophone (j’y reviendrai) ;
- son fonctionnement s’apparente à celui d’un « Redis‑like » (stockage de valeurs, mécanique de souscription et publication, exportation et importation vers des fichiers, scripting sur la base) ;
- il est écrit en Rust, ce qui lui garantit une qualité minimale (sans être exempt de bogues).
Le (pré)nom « Robert » me semblait donc tout indiqué…
Je suis à l’origine de ce projet, à la suite d’une thèse professionnelle sur le modèle RDF appliqué aux organisations et à l’information, soutenue en décembre dernier.
Robert se veut être un logiciel utilisable par le plus grand nombre (du moins via telnet), de qualité, fiable et léger mais surtout maintenable facilement, même avec peu de connaissances (je ne suis pas un développeur professionnel et j’ai toujours appris le développement seul).
Les professionnels ou personnes averties qui parcourront le code, trouveront probablement des imperfections (ouvert à tous les tickets / propositions).
J’invite à la clémence, c’est ma contribution à la communauté… :)
Documentation et informations techniques
Le dépôt contient la documentation produite à partir du code source, que j’ai laissé sur GitHub. Une fois le dépôt cloné, vous trouverez les informations dans ./target/doc/projet_robert/index.html. La documentation peut être mise à jour localement depuis la commande cargo doc à la racine.
Le projet ne dépend d’aucune « caisse » (module) externe, volontairement, afin d’éviter le serpent des dépendances, qui rend complexe la maintenance (car une dépendance peut en entraîner une autre…). Robert veut en faire moins, mais essayer de faire bien ce qu’il tente de faire ! À terme, il me semble tout de même difficile de faire sans les expressions rationnelles, notamment pour la gestion du texte (mais ce serait là une rare exception confirmant la règle).
Développement et licence
Ce projet est entièrement écrit en Rust (version 1.39.0), depuis Cargo. Lorsque vous avez cloné localement le dépôt, une simple commande cargo run --release à la racine compilera et lancera le programme (testé sous Windows 10 et Linux/Ubuntu). Celui‑ci est accessible par défaut sur le port 8080 en local.
La licence est naturellement ouverte et permissive (Apache 2). L’usage de Robert est donc gratuit (et je n’ai pas de structure pour le support actuellement).
Intérêts et fonctionnement
Les clients peuvent se connecter via un socket TCP et envoyer des commandes (précision utile : les accents sont pris en compte !). Chaque commande se termine par un saut de ligne (\n) et est composée d’une fonction à appeler, puis de zéro, un ou n arguments. Chaque argument est séparé par un espace. Si votre argument contient un espace, il doit être entre guillemets (").
Les fonctions sont découpées en modules (voir la documentation). Toutes les commandes, les messages renvoyés comme l’ensemble de la documentation et du développement sont en français.
La base est constituée de « canaux », qui autorisent à émettre et à souscrire aux messages émis. Dès le lancement, il y a toujours un canal, nommé « défaut », qui ne peut être supprimé et recueille les clients nouvellement arrivés. Les autres canaux peuvent être créés, édités et supprimés librement. Chaque client ne peut être connecté qu’à un canal à la fois, mais peut changer de canal au cours de la connexion.
Certaines opérations sont restreintes aux clients identifiés (il existe une fonction d’authentification, basée sur un fichier CSV ; par défaut "test" / "test").
Dans chaque canal, il existe une arborescence identique : à l’origine de chaque canal, vous pouvez définir des paires clé‑valeur. Une valeur peut être un texte, un entier positif ou négatif, un flottant, un booléen ou un objet qui lui‑même est un dictionnaire de paires clé‑valeur. Il est donc possible de faire des « chemins » amenant à une valeur particulière dans l’arbre du canal (appelé la "liste").
Concernant la diffusion de messages entre clients connectés à un même canal, il s’agit d’une suite binaire quelconque. Il est possible de « capturer » un canal pour soi‑même (avec aucune possibilité pour les autres d’y accéder) afin d’avoir son propre espace de stockage de valeurs, comme de restreindre un canal existant aux clients qui y sont (déréférencement).
Exemple de commandes (à exécuter dans l’ordre, avec entrée à chaque ligne) :
définir mavar 1
obtenir mavar
altérer mavar relatif
obtenir mavar
numérique:incrémenter mavar 2
obtenir mavar
définir obj ~ objet
définir obj/mavar 5 flottant
obtenir obj/mavar
(il y a quelques dizaines de commandes de disponibles au total, couvrant le spectre essentiel des opérations)
Les lignes en retour commencent toujours ainsi :
- [+] : commande terminée et positive ;
- [-] : commande terminée et négative ;
- [@] : commande toujours en cours, message à destination du client ;
- [!] : commande toujours en cours, une erreur est survenue.
Facile à analyser donc.
Travaux en cours
Le programme est opérationnel, fonctionnel, sauf pour la partie script (mais cela n’interfère pas avec le reste). J’ai commencé voilà plusieurs mois ce travail, et depuis quelques semaines le développement actif. Actuellement, j’intègre un outil de script qui ressemble beaucoup aux commandes fournies par les clients : Cerise (et l’implémentation s’appelle Tomate, parce que « tomate‐cerise »… #honte).
C’est un DSL je dirais « hybride », moitié API, moitié DSL classique. En somme, il y a un arbre à résoudre, mais ce dernier est très restreint (volontairement). Le but est de rapprocher l’outil de script dans l’esprit des filtres d’IndexedDB dans Firefox : un même script, rapide et qui n’échoue pas, qui sera exécuté pour chaque valeur dans une partie de l’arbre du canal.
Chaque ligne du script commence par un opérateur « + » (positif), « - » (négatif), « ø » (inconditionnel). Cet opérateur permet au moteur de se baser sur un état pour savoir si la ligne sera exécutée ou non. Cet état est à l’origine à « vrai » et si une ligne échoue ou modifie l’état, la suivante se basera sur celui‑ci pour sa propre exécution.
Il est possiblement de « diverger » un bloc d’instructions avec une condition d’état, puis de faire « converger » de manière conditionnelle ce bloc vers son parent immédiat qui continue alors son exécution. À terme, il sera possible d’avoir des scripts qui seront appelés durant l’exécution, ce qui permettrait des boucles ainsi que la définition de fonctions.
Rappel : un script dans ce contexte, ne gère que la valeur de la base qui lui est soumise, et ses enfants s’il y en a.
Cela ressemble à ça :
+ type:texte
ø état:sauvegarder
ø afficher
ø état:recharger
+ afficher "c'est bien un texte"
- afficher "c'est autre chose"
- ràz
ø diverger
+ afficher "je ne sers à rien"
ø converger
ø afficher "stop"
Sur la filiation de ce DSL, je dirais qu’il se situe entre plusieurs choses que j’aime bien : le café du matin, les bouquins sur (Common) LISP, le lambda‐calcul, ma douche… et TCL.
Les experts classeront mieux que moi. :)
Super, ravi(e) mais à quoi ça sert vraiment ?
Redis sert pour du stockage (très) rapide car en mémoire vive (VoltDB est son équivalent en SQL). Robert s’en inspire : stockage de sessions pour un site Web, de calculs provisoires, etc., peu importe. L’outil ne fait pas le métier (mais l’inverse si).
Ma finalité personnelle était de supporter la récursivité (pour avoir un classement pointu) et surtout l’aspect facile de l’interrogation, afin d’avoir constamment sous la main un petit outil pour injecter un peu de tout, qui communique avec d’autres personnes ou des applicatifs, et ne prenne ni place, ni ressources excessive.
La partie francophone me tient à cœur car beaucoup d’utilisateurs ne sont pas à l’aise avec la langue anglaise. C’est un frein à l’usage d’un outil et à l’informatique de manière générale. Ce n’est pas être particulièrement chauvin (même si je peux l’être parfois), mais apporter une petite pierre à la communauté du Libre qui m’a gâté jusque‑là (Firefox, Ubuntu, LibreOffice et tant d’autres qui sont mon lot quotidien).
Pour ceux qui ont tenu jusque‑là : félicitations ! J’espère qu’il vous servira. Si vous y trouvez votre intérêt, « forkez », partagez, commentez, utilisez !…
Julien.
Aller plus loin
- Robert sur GitHub (242 clics)
# lapin compris
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Je n'ai pas compris la spécificité du truc. As-tu des query performantes bien que très spécifiques ?
Je pense qu'il y aurait de la place pour un cache qui se placerait entre le Redis et l'application et tournerait sur la même machine. Il y a plusieurs endroit où elle aurait sa place avec un paramétrage de la ram consommé (lib pur, exe qui communique par un moyen plus rapide qu'une socket, sidecar de container pour accompagner un applicatif sur la même machine)
"La première sécurité est la liberté"
[^] # Re: lapin compris
Posté par JulienG . Évalué à 2.
Non malheureusement, je n'ai aucun comparatif à te fournir. J'espère pouvoir le faire très bientôt.
# Comparaison ?
Posté par dani . Évalué à 4.
Par rapport à un redis (qui peut faire du RAM only), quel est le gain ? Meilleurs perf ? Pour ce qui est du choix des commandes en français, perso ça me rebute un peu. C'est un logiciel destiné à être mis en place par des tech, pas du grand public. Donc l'anglais ne devrait pas être un frein.
[^] # Re: Comparaison ?
Posté par Bastoon . Évalué à 1.
C'est peut être un prérequis pour une thèse, mais oui clairement : en anglais. J'imagine pas l'état des connaissances si chacun partageait uniquement dans sa langue.
Je n'ai pas bien compris à quel besoin répondait ce logiciel. Si jamais l'auteur veut compléter, j'en serais ravi. En tout cas merci pour l'initiative.
[^] # Re: Comparaison ?
Posté par raphj . Évalué à 5.
Probablement pas. C'est la langue du document lui-même sur laquelle il y a des contraintes sur la langue. Et l'obligation d'écrire en français saute si on sait qu'une personne du jury ne parle pas le français. Ou si une partie de la thèse a été écrite sous forme de papiers en anglais.
Après, l'auteur de la dépêche a certainement de bonnes raisons d'écrire son programme en français, et toi, tes commentaires sur LinuxFR :-)
[^] # Re: Comparaison ?
Posté par fcartegnie . Évalué à 4.
Et surtout memcached qui est justement k/v en RAM
[^] # Re: Comparaison ?
Posté par JulienG . Évalué à 2.
(Pour le point sur le français, j'ai publié un commentaire précédent sur le sujet)
J'espère ne pas dire de bêtise, mais Memcached ne gère pas des objets complexes, permettant la récursivité. Il gère des données binaires et des flags (il """ne comprend pas""" ce qu'il stocke).
Robert peut être considéré comme un gestionnaire de canaux où chacun gère un arbre, doté d'une profondeur qui peut évoluer sans grande limite, sur des types fixés à l'avance.
J'ai essayé de créer un environnement très favorable à l'ajout de nouvelles commandes (on ajoute une fonction avec deux arguments - permettant d'obtenir le contexte d'exécution et les arguments fournis - avec un retour à destination du client, on compile, c'est prêt).
[^] # Re: Comparaison ?
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Je me demande si un exemple d'utilisation ne serait pas plus clair pour expliquer le fonctionnement.
[^] # Re: Comparaison ?
Posté par JulienG . Évalué à 3.
Je regarde pour faire un exemple d'usage.
# Mes deux centimes de vieux francs
Posté par Ruminant . Évalué à 9. Dernière modification le 20 avril 2020 à 15:15.
Pas de souci :)
En dehors de projets éducatifs je ne comprends pas l’intérêt étant donné la masse de documentations et projets existants en anglais.
En rapport avec le choix de la langue, pour moi c’est un frein à l’adoption : on privilégie sa localité au détriment des autres. Ça me rappelle tous ces projets en Chinois dont on ne peut pratiquement rien faire car il n’existe aucune documentation en anglais.
Ça donne aussi un mélange très étrange entre anglais et français, vu que le langage et la lib standard sont en anglais. Ça fait encore plus de gymnastique pour passer de l’un à l’autre.
De plus, au niveau du code, ça n’a amha que peu d’importance : les utilisateurs utilisent un binaire, pas du code source.
Selon les objectifs, tout refaire sois-même peut-être autant sinon plus de code à maintenir, sans parler des problèmes de sécurité/performance résolus par d’autres projets.
Choisir consciencieusement ses dépendances est à mon avis plus intéressant. Tu prends l’exemple de Regex, je pensais aussi à ce genre de chose, mais pas que. Il existe des bibliothèques permettant d’atteindre des performances bien meilleures que les dictionnaires (hashmap/hashset) de la lib standard par exemple.
Pour ce qui est de la traduction des « crate » Rust, je ne pense pas que cela rende les choses plus claires :)
Si je comprends bien c’est à la fois un "pub/sub" et une "base" comme on pourrait en avoir dans redis ?
Quel est l’intérêt par rapport à une modélisation "à plat" clef-valeur toute simple ?
En terme de performance, cela veut dire qu’à chaque fois que l’on veut traverser des objets, il faut charger en cascade des espaces mémoire aléatoirement dans la RAM.
En terme d’usage, je ne vois pas d’avantage à simplement avoir une clef correspondant au chemin complet, et une valeur au bout. Sauf peut-être pour l’expiration d’un groupe de valeurs, éventuellement.
Peux-tu m’éclairer à ce sujet ?
Sur la partie scripting, j’ai pas compris le choix d’un caractère "difficile" à taper, limitant encore plus l’accessibilité :
ø. Si c’était pour désambiguïser l’usage du "o" et du "0", ok, mais alors choisir un caractère facilement accessible me semble judicieux.En terme de code (j’ai largement survolé, de très très haut), je vois que tu te sers de
HashMapprovenant de la lib standard. Les performances de ce type sont vraiment mauvaises : les implémentations de Python et Go font largement mieux par exemple. S’il y a une volonté d’être performant, il faut absolument s’orienter vers d’autres implémentations en attendant.Voilà mon petit retour :) Personnellement je ne vois pas d’intérêt de ce projet par rapport à Redis, ou même memcached si ce n’est l’utilisation d’un langage théoriquement exempt de problèmes de pointeurs null et autres overflows.
Après peu importe, c’est toujours une bonne expérience de faire quelque chose de concret, et j’espère que mon commentaire pourra t’apporter quelque chose.
[^] # Re: Mes deux centimes de vieux francs
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Redis n'est pas trop gros pour simplement avoir une hashmap en RAM de qq Go sur le même nœud que l'application ?
"La première sécurité est la liberté"
[^] # Re: Mes deux centimes de vieux francs
Posté par Ruminant . Évalué à 1. Dernière modification le 20 avril 2020 à 15:26.
Je ne suis pas sûr d’avoir compris ton message.
Si tu veux parler de comment la mémoire est gérée dans Redis, je n’en sais rien. J’imagine cependant qu’il doit y avoir à minima un système de "bucket" en fonction du temps d’expiration des clefs, pour pouvoir les nettoyer plus rapidement.
Pour le reste je n’en sais rien, et je parlais uniquement des objets imbriqués.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à 3.
Ce n'est pas un clone de Redis, et ça n'a pas la vocation de faire exactement ses tâches (autant l'utiliser lui directement).
Il n'y a pas aujourd'hui dans Robert, la possibilité de faire des réseaux interprocessus, où chacun serait soit un maître, soit un esclave (même pourquoi pas à l'avenir avec les fonctions de souscription, j'y ai pensé).
Sur la gestion des valeurs stockées, une base avec des centaines voire des milliers de hashmap et des fonctions de souscription, ça représente vite un projet qui nécessite de se pencher très, très sérieusement sur la gestion des données périmées effectivement, au niveau logique et de l'implémentation précisément. Une fuite de mémoire peut être un catastrophe rapide et sans aller jusque là, c'est juste pénible à suivre en terme de programmation.
Rust a choisi dans son fonctionnement, de se pencher sur les durées de vie et c'est tout l'intérêt d'avoir un garbage collector statique, qui est par nature bien plus sûr que du C et équivalent (de mémoire Redis est en C), tout en offrant des performances plus intéressantes qu'un langage interprété.
Sur la définition d'un délai d'expiration, ce n'est pas propre à un outil ou le choix d'un langage pour moi, mais un attribut d'une implémentation ou d'un usage. Sur Robert, la mise en œuvre me paraît facile : une boucle qui parcourt à un rythme régulier le stockage et lors d'un accès à une valeur, confirmer que son délai est toujours actif. La gestion des accès concurrentiels est réglé via Arc+Mutex, pour tous les canaux.
J'espère avoir répondu à l'interrogation…
Au-delà, sur le choix de Rust, à la différence d'un projet qui aurait été en Java par exemple, il n'y a pas besoin d'avoir une plateforme logicielle sous-jacente lourde. L'emprise mémoire pour la gestion de Robert est très faible. De plus Rust a un niveau de finesse et robustesse natif (refus de compilation sinon), qui est un gage de qualité supplémentaire.
[^] # Re: Mes deux centimes de vieux francs
Posté par barmic 🦦 . Évalué à 2.
Tu utilise des pool d'objets/structures pour éviter la fragmentation mémoire ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à 3.
Sur les structures, il y en a pas mal : les canaux en sont, les clients (stream TCP avec d'autres paramètres), le contexte d'utilisation (qui regroupe l'état du service, du client, les accès mutex, etc.), ainsi que les valeurs.
Chacun a son implémentation propre, avec des traits pour la généricité, notamment pour l'écriture sur le socket du client.
L'ensemble est dans un canevas d'exécution (une fonction, retrouvée lors du traitement d'une commande) qui doit répondre à un type particulier, indépassable.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à 10.
Merci !
Certes. L'anglais est une convention. Une convention est par nature, une convention : ce qui est convenu dans un groupe donné. Aucune langue n'est éternelle, sans évolution. Je ne crois pas que l'anglais le soit pour l'informatique car, comme tu le soulignes, l'indien ou le chinois ont un poil plus d'utilisateurs (surtout réunis) dans les informaticiens que ceux du bloc classique occidental dans un proche avenir (si ce n'est pas déjà le cas).
Le débat sur ce point, fait de ma position une position ultra-minoritaire j'en suis conscient. Mais je crois qu'il faut des projets qui ne soit pas nécessairement en anglais "parce que c'est comme ça". Pour moi, fondamentalement, c'est un rapport d'abord à la communauté que l'on créée, où l'on est, où l'on agit.
Pour la lib standard, justement. Combien - je m'inclue dedans - ont passé parfois des heures à comprendre tel ou tel point, en anglais ? Si la réponse est "Google Translate" alors soit, c'est "Google Translate" - mais ce qui est valable anglais -> français est donc valable français -> anglais.
Pour l'utilisateur lambda, la doc et le code en français peut avoir un sens car le français ne se limite pas à la France et est une communauté parmi les plus nombreuses au monde.
Par contre on est d'accord : en soi du code en français, on s'en fiche, d'autant que ce qui compte c'est que la machine comprenne les instructions…
Non, et Rust est limité en pouvoir descriptif dans ses concepts. Juste le terme "module" reprend parfois des choses différentes, entre une "caisse", un fichier du projet..
Tu as tout à faire raison, c'est un risque. Mais comme c'est sous-entendu, le risque était soit de faire un rassemblement de projets extérieurs avec des dépendances qui, sérieusement, ne seraient relues (et potentiellement seraient abandonnées), soit le refaire et avoir un projet homogène dans sa maturation. J'ai fait le choix de l’homogénéité.
Sur Hashmap, j'ai pris le choix d'aller vers la simplicité conceptuelle : une paire clé/valeur pour chaque entrée, qui sont rassemblées ensemble. Hashset aurait impliqué de faire un travail supplémentaire, car le hash est sur l'objet stocké et non sur la clé. Hashmap a une gestion des clés par hash.
De fait si l'on prend toutes les attendus du projet (intégrité de l'outil ; support natif ; performance ; simplicité conceptuelle et de maintenance), je trouve que c'est un choix raisonnable.
J'entends parfaitement ce que c'est pas le choix le plus performant (encore que), mais c'est un choix qui ne prend pas que la performance.
Pour la comparaison avec Python, compte tenu que Rust est compilé avec des performances très proches du C, j'ai un doute que l'implémentation soit moins bonne. Pour Go, je sais pas trop.
Tu me mets le doute, je vais regarder et tester ça.
Oui je crois.
Bien sûr. L'actualité n'est sûrement pas clair. Le canal dispose d'une hashmap qui est une valeur comme une autre, de type "objet" (qui contient donc d'autres valeurs). Le chemin correspond à tous les objets à traverser pour atteindre la valeur finale (qui est un des 5 types).
Ce n'est donc pas du tout une base "à plat" mais un arbre de hashmap, dont l'origine est le canal lui-même (j'espère que c'est plus clair ?).
Ce n'est pas pour l’ambiguïté, mais au contraire pour être sûr que le scripteur veux bien l'inconditionnalité (c'est-à-dire que la commande sera toujours exécutée).
Ce qui est déjà pas mal tu ne crois pas ? Beaucoup de choses dans la surface d'attaque ou de problématiques portent sur la question des pointeurs et des débordements.
Je te remercie de ton commentaire, qui me permet d'être, j'espère, plus clair et précis, comme d'argumenter sur le projet.
[^] # Re: Mes deux centimes de vieux francs
Posté par barmic 🦦 . Évalué à 4.
Mais moi je suis pas d'accord :) Pour moi on écrit du code pour qu'il soit lu par d'autres développeurs (ou sois-même dans le future).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à 4.
Oui il sera lu, par moi-même et j'espère beaucoup d'autres !, dans le futur. En français, comme des centaines de millions de personnes dans le monde :
https://fr.wikipedia.org/wiki/Francophonie
Quelqu'un qui ne parle pas le français fera comme moi quand je lis le commentaire du code source (en mandarin) de ma box 4G chez Bouygues : il utilisera un outil de traduction.
Si l'on tient à rester sur le cadre purement logique, les noms de variables apportent un sens et facilite la compréhension, mais on peut aussi retrouver le fonctionnement avec la grammaire d'un langage.
Je vois que cette question irrite beaucoup dans les commentaires. Je suis (réellement) surpris.
[^] # Re: Mes deux centimes de vieux francs
Posté par barmic 🦦 . Évalué à 5.
C'est assez clivant, généralement mais personnellement je m'en fou que ce soit en anglais ou autre chose. Il faut que ça ai du sens. Définir un ubiquitus langage pousse souvent à utiliser la langue des utilisateurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mes deux centimes de vieux francs
Posté par Psychofox (Mastodon) . Évalué à 4.
Tu trouves ça satisfaisant de devoir utiliser des outils de traduction pour lire et comprendre du code ?
L'anglais n'est pas la langue la plus parlée au monde, mais c'est la langue comprise par le plus grand nombre et cette proportion doit être encore plus grande dans le monde des développeurs.
Qu'on aime ou pas cette langue, qu'on ait une affection plus importante ou pas pour notre langue maternelle, avoir une langue "standard" pour du développement logiciel est une bonne chose pour une bête question de partage.
[^] # Re: Mes deux centimes de vieux francs
Posté par Tonton Th (Mastodon) . Évalué à 4. Dernière modification le 21 avril 2020 à 12:23.
Sans compter l'accès à distance. J'utilise régulièrement en ssh des Debian récentes (en utf-8) à partir de vieux xterm qui sont plutôt en iso8859-?, et franchement, dès qu'on sort de l'ascii, ça devient vite lourd.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à 1.
Certes c'est problématique dans ce cas-là. J'en suis conscient. Cependant il y a beaucoup de cas où le support de l'UTF-8 n'est pas un problème.
Par ailleurs, compte tenu de l'organisation du projet, il est très facile de modifier les caractères séparateurs. Peut-être faut-il cependant que j'améliore encore ce point, en passant les caractères séparateurs directement en variable globale dans le fichier de configuration. Ainsi la modification serait unique avant la compilation, et obtenu un programme qui répond à un usage plus limité.
Merci de votre retour.
[^] # Re: Mes deux centimes de vieux francs
Posté par Ruminant . Évalué à 1. Dernière modification le 21 avril 2020 à 12:40.
https://fr.wikipedia.org/wiki/%C3%98#Repr%C3%A9sentations_informatiques
Je reste convaincu que c’est une mauvaise idée d’utiliser ce caractère par défaut.
L’accessibilité/utilisabilité, c’est important.
[^] # Re: Mes deux centimes de vieux francs
Posté par Tonton Th (Mastodon) . Évalué à 6.
Parfait, ça nous rappelera le bon vieux temps où les macros VBA d'un Excel en français ne tournaient pas sur un Excel en espagnol. Nostalgie, quand tu nous tiens ;)
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à 1.
Je ne suis pas sûr que ça soit pertinent de faire cette comparaison (enfin si, j'en suis sûr mais je suis trop poli pour le dire).
Je parle d'une modification avant compilation, avec d'autres critères à prendre en compte pour que le programme (celui-ci ou un autre) fasse ce que l'on souhaite.
De plus, c'est la modification d'un type
char: quelque soit sa valeur, il est toujours de typechar… ça ne modifie en RIEN le fonctionnement logique ou interne.[^] # Re: Mes deux centimes de vieux francs
Posté par Ruminant . Évalué à 2.
J’ai l’impression que le propos n’a pas été compris.
Mettons qu’un script ai été écrit avec ce
obarré, et utilisé sous une version du logiciel utilisant ce mêmeobarré, tout va bien.Mais dès lors que le script est utilisé par une autre version compilée avec, disons,
>, boum, le script ne fonctionne plus.Donc oui, ça ne va rien changer dans le logiciel, mais dès qu’on voudra l’utiliser on se retrouvera avec des incompatibilités stupides…
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à -2. Dernière modification le 21 avril 2020 à 16:34.
Effectivement, ta pensée était éloignée de ce que j'avais compris. Cependant si tu as une configuration X, un fichier d'entrée Y et que tu t'attends que ça fonctionne - pour Robert ou un autre -, c'est illusoire.
Soit tu ne changes pas la configuration, soit tu la changes et tu adaptes ton entrée à ton changement.
N'est-ce pas comme ça pour tous les logiciels qui existent ?
Exemple : il attend du TOML, tu lui fournis un JSON, ça coince. L'exemple est caricatural mais la logique suivie est la même. Ton programme a son environnement et ses possibilités. Si tu en sors, tu sors du fonctionnement normal et attendu.
D'autant que tu ne compiles pas non plus ton logiciel tous les 4 matins. Tu peux même automatiser ta compilation pour les nouvelles versions, afin de modifier la valeur configurée pour l'adapter à ce qui existe déjà et que ta version soit adaptée à ton usage.
Bref à mon sens, ça reste hors de propos.
[^] # Re: Mes deux centimes de vieux francs
Posté par Ruminant . Évalué à 3. Dernière modification le 21 avril 2020 à 16:43.
La problématique n’à rien à voir avec "TOML" vs "JSON", qui sont deux formats aux possibilités très différentes.
Là, quelque soit le séparateur, les fonctionnalités sont les mêmes : c’est comme si la configuration de Redis, selon la compilation, pouvait avoir des commentaire avec
#par défaut, mais avec|dans d’autres cas, tout ça parce que la personne veut des|parce que c’est plus simple à écrire dans son cas…Si on commence à devoir changer de disposition clavier pour pouvoir écrire sa conf on est pas sorti d’affaire.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à -1.
En quoi utiliser un séparateur ou un autre - et offrir la possibilité d'en changer -, a une incidence sur le clavier ?
Personnellement, j'en serais très heureux si ça pouvait être le cas.
[^] # Re: Mes deux centimes de vieux francs
Posté par Ruminant . Évalué à 3.
Doit-on vraiment reparler de ce o barré qu’il m’est impossible d’écrire sans devoir changer de disposition ?
On ne doit pas vivre dans la même réalité.
[^] # Re: Mes deux centimes de vieux francs
Posté par Psychofox (Mastodon) . Évalué à 3.
Supporté ou pas c'est merdique. Dans la grande communauté francophone dont tu parles prédemment, un grand nombre d'entre eux n'utilisent pas une disposition des touches azerty FR mais du qwerty international ou autre pour lequel accéder aux accents impose d'utiliser une combinaison de touche pour obtenir l'accent.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à 0.
Et donc ? Ils ont arrêté les accents ? Non, ils tapent les touches nécessaires. Incroyable. Il faut taper sur un clavier, c'est exceptionnel.
Leur clavier est Qwerty pour des raisons économiques très largement (rapports francophonie). Pas besoin d'être devin pour imaginer qu'ils utiliseraient un clavier adapté à leur langue s'ils avaient le choix.
J'ai bien compris que la question des accents et de la francophonie hérissent le poil, et que c'est pas la peine d'argumenter : bien, oubliez ma contribution.
Franchement je regrette !
[^] # Re: Mes deux centimes de vieux francs
Posté par Ruminant . Évalué à -2. Dernière modification le 22 avril 2020 à 20:34.
Ou alors ils n’ecrivent pas les accents, parce que ce n’est pas franchement necessaire, dans le fond : sur ce meme site nous avons eu droit a quelques journaux et commentaires ecrits sans accents, car la personne utilisait alors une disposition qwerty. Ca n’a pas empeche la communication.
Ici il s’agit d’un langage qui oblige a utiliser un caractere specifique, particulierement difficile d’acces, alors qu’il y a beaucoup d'autres caracteres immediatement disponibles et qui feront aussi bien l’affaire.
Bienvenue dans la realite, ou le plus grand nombre choisira autre chose parce, vu que ce qui est propose par defaut n’est pas accessible, en plus de ne proposer aucun avantage par rapport aux produits existants.
[^] # Re: Mes deux centimes de vieux francs
Posté par Lutin . Évalué à 6.
Non ne pas écrire les accents quand on écrit du texte en français, comme ton commentaire, c'est de la mauvaise volonté et de la flemme, même avec un clavier qwerty. Sur les navigateurs modernes tu as des dictionnaires pour quasiment toutes les langues, et ça te souligne en rouge les fautes d'orthographe basiques, en deux clics tu peux ajouter la plupart des accents manquant.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à 2.
Effectivement.
Au-delà, ça pose la question de la frontière entre sciences informatiques et de l'information. Un clavier n'est pas quelque chose de si naturel pour l'écriture, car ça limite le nombre de signes utilisables directement. Mécaniquement : on imagine difficilement un clavier avec des centaines voire des milliers de touches.
J'en rajoute une couche, mais tant pis.
Un exemple qui me tient à cœur: ASCII prévoit ainsi des caractères pas particulièrement spéciaux pour le coup, mais qui n'ont pas de "matérialité" sur un clavier : GROUP / RECORD / UNIT SEPARATOR (29-31). L'intérêt c'était alors de faire la distinction entre ce qui tient des signes d'imprimerie classiques (lisibles, visibles) de ce qui tient des caractères de séparation propre à un système informatique (fin de ligne, de fichier, etc.). J'imagine que je n'apprends rien à personne. Ainsi pas besoin de gérer les séparateurs type tabulation dans le texte, car il y a des séparateurs pour ça (exemple de CSV).
Si les claviers avaient ces touches, le format fréquent des fichiers aurait été peut-être différent. Mais probablement aussi plus simple. L'histoire fourmille de (bons) standards qui n'ont pas ou mal été utilisés, face à des arguments fallacieux (la disposition du clavier en est une).
Enfin pour les langues qui n'utilisent pas un alphabet mais un logogramme (permettant de former des idéogrammes), un clavier est dans toutes les situations, quelque chose de relativement fastidieux. Il faut une combinaison de touches pour former un mot, correspondant donc pour nous à un "caractère"… En soi c'est bien "pire" à retenir et à utiliser que n'importe quelle disposition classique AZERTY / QZERTY face à notre propre langue.
[^] # Re: Mes deux centimes de vieux francs
Posté par Storm . Évalué à 3.
J'ai jamais compris cette "excuse". Je suis moi aussi sur un clavier qwerty (et même si j'étais sur un clavier azerty, je garderais une disposition qwerty car, opinion personnelle, je trouve cela plus facile pour programmer) et ça ne me gène pas pour faire des accents…
[^] # Re: Mes deux centimes de vieux francs
Posté par Ruminant . Évalué à 1.
Pourquoi ne pas utiliser urxvt ?
[^] # Re: Mes deux centimes de vieux francs
Posté par Tonton Th (Mastodon) . Évalué à 0.
Parce que ça ne fera que masquer le vrai souci.
[^] # Re: Mes deux centimes de vieux francs
Posté par Ruminant . Évalué à 3.
Quel souci ? Je suis perdu :)
Je ne suggérais pas d’utiliser urxvt pour pouvoir taper et lire des caractères "bizarres", mais à un moment faudrait peut-être aussi en finir avec l’ISO, non ?
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . Évalué à 3.
Je suis d'accord. C'est un nouveau projet : l'UTF-8 est LE standard, il convient de l'utiliser le plus possible (tout le temps).
Qu'un programme nécessite des impératifs particuliers dans un environnement complexe (embarqué, industriel, etc.) ou alors pour des questions de compatibilité avec des versions antérieures, ça s'entend.
Mais là… ? Je suis perplexe.
[^] # Re: Mes deux centimes de vieux francs
Posté par barmic 🦦 . Évalué à 4.
Le vrai souci ce n'est pas de ne pas pouvoir afficher des caractères autres que quelques uns de l'alphabet latin ? Parce que ça va poser un problème aussi si tu a un fichier avec un caractère hors ASCII, si tu affiche quoi que ce soit qui depuis le réseau (via curl par exemple).
Je ne milite pas pour utiliser l'ensemble d'unicode pour écrire du code. Mais si tu te place dans un mode aussi compliqué que possible pour nous montrer que oui quand on se crée un environnement d'il y a plus de X années, on a les problèmes qu'on avait il y a X années tu enfonce des portes ouvertes. C'est un argument assez faible. Pleins de choses n'existait pas à l'époque de potato, ça n'est pas pour ça qu'il faut s'en passer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Supports téléchargeables ?
Posté par aplc (site web personnel, Mastodon) . Évalué à 3.
Un peu hors-sujet (quoique) : Est-ce qu'il serait possible d'obtenir un lien pour télécharger le document de thèse et la présentation ? Le sujet m'intéresse et je n'ai pas vraiment envie de créer un compte slideshare.
Merci
[^] # Re: Supports téléchargeables ?
Posté par JulienG . Évalué à 4.
Voici un lien pour télécharger directement le PDF :
https://drive.google.com/file/d/1_YyU2jGJn4-4Iu8c25n1VeSU0jRcwgYx/view?usp=sharing
J'attire votre attention que la transposition professionnelle de la thèse n'est pas publique et n'est donc pas présent dans le document (seulement la partie sur le modèle RDF appliquée aux entreprises et l'intérêt du fonctionnel dans le développement moderne).
[^] # Re: Supports téléchargeables ?
Posté par aplc (site web personnel, Mastodon) . Évalué à 1.
C'est déjà très instructif pour comme ça. Je m'intéresse (depuis pas longtemps) à l'approche sémantique de la gestion des données et essaie de voir un peu des applications pour en mesurer les contours.
Merci
# Conflit sur le nom «Robert»
Posté par Mimoza . Évalué à 3.
Salut,
Un grand merci pour ta contribution !
Je te fait juste remarqué que l'INRIA vient tout juste de publier son protocole «Robert» (ROBust and privacy-presERving proximity Tracing)
https://github.com/ROBERT-proximity-tracing/documents
Il est peut être encore temps de changer ça, non ?
[^] # Re: Conflit sur le nom «Robert»
Posté par JulienG . Évalué à 1.
Heureusement nous ne sommes pas au même niveau de visibilité (loin, très très loin), aussi je doute leur faire de l'ombre :)
Il y a une indication en début d'article sur ce sujet.
[^] # Re: Conflit sur le nom «Robert»
Posté par polosson . Évalué à 3.
Bonjour !
Je viens de voir cet article, c'est intéressant, bravo pour la contribution open-source !
Cependant, concernant le choix du nom, j'aimerai signaler l’existence d'un autre Robert, et qui n'a encore rien à voir, ni avec votre logiciel, ni avec le protocole de l'INRIA (que je découvre aussi ici).
Il s'agit d'une application web open-source de gestion de parc de matériel destiné à la location ou au prêt. Ce début d'année, une seconde version est sortie, et le nom a été changé pour « Robert2 ».
Site web de l'application : https://robertmanager.org.
Discussion du forum qui parle de votre logiciel : forum.robertmanager.org/d/120-trop-de-robert.
Il ne s'agit pas vraiment d'un acronyme (quoique j'aime bien celui, récursif, de « Robert Organise Bien Et Range Tout »), mais plutôt d'un choix arbitraire, fait en… 2011, année de création de l'application !
Voilà, c'était juste pour signaler la chose, merci et encore bravo pour votre logiciel !
Cheers
[^] # Re: Conflit sur le nom «Robert»
Posté par JulienG . Évalué à 1.
J'y réfléchis… Cerise serait pas mal mais Google me retourne le résultat d'un éditeur de base de données (Cerise Assemple).
"Bertro" ? Moche mais sans aucune autre occurrence semble t-il ?
# Hautement escaladable?
Posté par devnewton 🍺 (site web personnel) . Évalué à 9. Dernière modification le 20 avril 2020 à 22:41.
Est-ce que l'on peut mettre plusieurs instances volumineuses de Robert en grappe?
J'ai un projet digital qui aurait besoin de gros Roberts.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Hautement escaladable?
Posté par JulienG . Évalué à 3.
Seulement si vous êtes gentil avec lui et ses frères. Le petit Robert est plus casanier, toujours plongé dans un grand nombre de pages… ;)
Plus sérieusement : oui, avec des modifications, car aujourd'hui l'outil de diffusion des messages porte sur les messages des clients entre eux.
La souscription devrait être modifiée comme suit :
- soit message entre clients ;
- soit le suivi des valeurs (modifiées / ajoutées / supprimées) - ce qui permettrait de créer une instance maîtresse et des instances enfantes.
Pour "clusterister" un gros volume de données entre plusieurs instances, tout dépend du projet et de la formalisation derrière. Je n'ai pas vraiment de réponse. En soi ça me semble tout à fait possible, mais je n'ai pas réfléchi à une mise à mettre en œuvre.
# Formatage automatique
Posté par faelar . Évalué à 5.
Bonjour,
Je suis en phase (douloureuse) d'apprentissage de rust, donc tout mon respect et mes remerciements pour cette contribution.
Je note que le code est formaté avec soin, mais à la main. Il existe pourtant l'outil
rustfmtqui permet d'avoir un style uniforme sur l'ensemble de l'écosystème. Est-ce un choix volontaire de ne pas l'avoir utilisé ?[^] # Re: Formatage automatique
Posté par Ruminant . Évalué à 3.
Ou même la commande
cargo fmt, qui utilise rustfmt bien entendu, mais qui a l’avantage de passer sur tout le projet d’un coup.[^] # Re: Formatage automatique
Posté par JulienG . Évalué à 3.
Franchement j'ai pas de raison… Je ne l'ai pas fait même pas par flemme, mais parce que j'ai pas mal travaillé dessus en linéaire (sans vraiment de pause dans mes pensées) et comme j'étais seul, ça ne m'est pas venu en réflexe. Au prochain "push", je fais le nécessaire.
[^] # Re: Formatage automatique
Posté par JulienG . Évalué à 3.
Pour la phase douloureuse, je suis ENTIÈREMENT (d'accord et) conscient de la courbe d'apprentissage (moi aussi seul, il m'a fallu 2 bons mois plusieurs heures par jour, pour arriver à un résultat vraiment correct et en écrire sans regarder la doc).
Tout ce que je peux te dire, c'est de t'essayer à OCAML et Haskell avant de continuer, si ce n'est pas le cas. Ce sont tous deux des langages fonctionnels puissants, très puissants et certaines pratiques du développement fonctionnel comme une partie de la gestion des types, sont intégrés à Rust. En testant les deux (dans l'ordre indiqué), j'ai trouvé Rust étonnament beaucoup plus facile, notamment Haskell qui est un langage aux fonctions pures, ce qui est déroutant.
Finalement c'est logique : Rust c'est "rouillé", voire les autres langages, c'est voir les bonnes pratiques qui en ont été extraites.
Autre piège que j'ai personnellement rencontré : le C et l'impératif plus généralement…
1. Trop souvent on peut lire que Rust c'est un C "évolué" - ou alternativement "limité". Personnellement je trouve ça dingue (et faux). Rust a un garbage collector statique, ce qui élimine 99% des "bugs" (oubli, maladresse, etc.) dans la gestion de la mémoire. Juste pour cela, la comparaison ne tient pas. Je ne parle même pas d'une gestion moderne des chaînes de caractères ! De plus il y a considérablement plus d'aspects à prendre en compte avant même d'écrire la première ligne, comme les durées de vie et la gestion des emprunts, ce qui oblige à réfléchir vraiment.
2. Il y a comme tous les langages, souvent plusieurs moyens d'arriver au même résultat mais tous, tant qu'ils compilent, sont bons. La gestion par trait, la composition, renforcent la qualité globale sans qu'on s'en rende compte. Rust est un excellent moyen d'écrire du code à plusieurs. C'est un signe si Microsoft et d'autres, dont l'orientation est à l'opposé de Mozilla, s'intéresse de plus en plus à ce bijou.
A ce sujet, certains commentaires de cet article, me laissent à penser que ces points ont négligés notamment sur la question de la performance et de la robustesse qui sont procurés justement par les qualités intrinsèques du langage. Bref.
Pour la question des durées de vie qui semble empoisonner le langage (au début), n'oublie pas que c'est un prix à payer pour avoir un résultat d'une qualité "minimale" déjà importante. Et c'est une question d'habitude. Tu peux contourner la plupart des explicitations nécessaires en passant par des structures et des énumérations (abuse-en. Si si, encore). Lorsque tu ne peux pas faire autrement, raisonne en terme de "séquences" de traitement (puis en faire une fonction ?) : cela t'évite certains des problèmes de partage mutable et non-mutable, en définissant une clôture ou un bloc, ou simplement repenser ton organisation.
"Dialogue" avec le compilateur. D'ailleurs les bouquins sur le sujet rust-lang pousse à cela. J'ai pas de scruJ'utilise énormément https://play.rust-lang.org/ pour tester des portions, des organisations d'un code plus vaste. C'est rapide et facile. D'ailleurs pas besoin de
cargoou du site :rustcet c'est parti ! Mon environnement de dév. pour des bouts de code, c'est la commande suivante (sans honte) :Enfin et j'arrête là mon lirisme : pour moi, un développeur contemporain, c'est - au moins - Python + Rust + Common LISP.
* Python par sa grande popularité, sa présence quasi par défaut dans les environnement Linux, sa souplesse et sa rapidité à concevoir des traitements, la clarté du code et sa puissance / richesse dans le traitement moderne des données (via Jupyter ou autre) ;
* Rust car il produit un code compilé ainsi que les qualités évoquées plus haut ;
* Common LISP (je pense notamment à l'implémentation SBCL), parce que c'est LISP, parce que c'est normalisé, parce que tu prends un claque quand tu comprends le vrai sens de "macro", parce que c'est la puissance grammaticale, la facilité de résolution des AST et la beauté des lambdas. Bref CL lorsque tu dois aller vers des aspects de programmation que les deux autres langages ne supportent pas ou mal. Et d'ailleurs que parfois, seul CL supporte (plus de possibilités que Scheme, même si le débat est ouvert à ce propos).
Bref je pourrais passer des heures, j'adore ça et si je peux aider, ce sera avec plaisir :)
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 2.
Je m'étais dit de ne pas rajouter d'huile sur le feu vu le nombre de détracteurs ci-dessus… mais bon… j'ai un peu de temps à perdre.
Normal donc de se faire incendier quand on arrive avec une description longue d'un projet, qui au final, n'explique pas vraiment son intérêt puis assène post après post un discours idéologique en mode 'je sais tout'.
Pas la peine d'en remettre une couche sur le français, les explications ont étés claires:
l'ascii est à préféré car évite les problème de clavier, d'encodage, est plus compacte et rapide à traiter (1 octet = 1 caractère).
le français n'est pas universel en informatique
En revanche le coup du "développeur contemporain", c'est d'un non-sens terrible.
"développeur à la mode" ou "développeur inexpérimenté", pourquoi pas.
Python n'a rien d'un langage performant, voir https://github.com/kostya/benchmarks pour s'en convaincre. Pour la clarté du code, vu que les "espaces" ont une significations, on repassera.
Rust produit du code compilé comme des centaines de langages, le fait qu'il soit à la mode et que MS l'utilise ne prouve rien ( argumentum ad populum ), sauf qu'il est à la mode dans son petit monde. La dernière fois que j'ai regardé Rust, il n'existait pas de spécification formelle du langage. On est loin de la maturité des C/C++/Java/etc…
LISP est langage de niche qui permet de faire des choses extrêmement avancé en quelques lignes, mais dès que l'on veut faire des choses 'communes' avec d'autre environnements comme : du réseau, une interface graphique, charger une image, jouer un son, on est content de ne pas s'en servir.
Le choix d'un langage devrait dépendre du besoin et d'une réflexion technique, pas de la mode.
Bref, avant de s'extasier devant tel ou tel langage, je serais déjà content qu'un développeur "contemporain" maîtrise les aspects bas niveau (architecture, gestion des caches, latence..) des entités avec lesquels il interagit…afin de comprendre que parser du JSON à 2Go/s n'est pas de la science fiction.
[^] # Re: Formatage automatique
Posté par JulienG . Évalué à 2.
Moi aussi.
Pour la description du projet, il débute juste, il correspond à un projet de stockage de données en RAM. Désolé si je n'arrive pas à 15 tonnes de documentation, d'exemples, je suis tout seul.
Ce stockage permet de gérer des valeurs, des entrées typées, sous la forme d'un arbre qui peut grandir et se déployer suivant ce que veulent les clients. Dit autrement : une valeur peut en stocker d'autres, elles-même d'autres…
On parcours cet arbre (un par canal), grâce à un chemin, qui est une chaîne comme le serait le chemin dans une navigateur de fichiers.
Et ? Ta seule logique c'est l'efficacité brute ? On doit tous envoyer que de l'ASCII car c'est plus simple ? Tu parles de réalité dans ton post : soit, la réalité c'est qu'on utilise plein de signes différents, pour plein de langues, pour davantage de sens différents.
Il y a toujours un arbitrage entre performance et usage. L'arbitrage que j'ai pris ici, c'est d'avoir un système qui gère de l'UTF-8 de bout en bout et donc, qui n'avait aucune raison de pas supporter du français, des accents.
On est d'accord. Mais en faire un caractère d'exclusion définitif est risible. J'ai hâte de voir les commentaires lorsque de plus en plus de sources ne seront pas en anglais, ni en français… parce que l'évolution du monde agira sur l'évolution des conventions en informatique.
J'ai marqué plus haut dans les commentaires la même chose (cf. les implémentations de Hashmap). Je parle de puissance au global, en terme conceptuel. A moins que je sois particulièrement abruti (ce n'est pas exclu), il y a une place de choix du langage dans la "science des données", peut-être parce qu'il est souple, rapide en développement, avec des bibliothèque de qualité en d'autres langages parfois, qui en font un langage de "colle". La puissance ne se limite pas à un nombre d'opérations par seconde pour un langage (à la rigueur, son implémentation pourquoi pas).
Effectivement il manque de maturité mais il est (très) prometteur et gère très bien la mémoire. Deux qualités qui me semblent intéressantes pour une informatique moderne dans ce type de langage. Le ramener à un effet de mode, c'est tout de même faire peu de cas des articles de comparaison et d'études à son sujet.
Sur LISP, c'est gentil de relever la même chose que moi : il est dans des cas particuliers, mais souvent le seul vraiment pertinent dans ces cas-là. Et les implémentations gèrent là encore des imports d'autres langages pour dépasser le nombre limité de bibliothèques.
J'ai passé des mois à attendre ça, de quelques dév. De la perf pour de la perf. Super. Mais le monde du développement et heureusement, ne se limite pas à ça. Attention, je ne dis pas que ça n'a pas d'intérêt, mais tu es aussi dans des bornes limitées que les miennes : elles sont juste différentes.
Les interfaces au sens large, les modalisations de processus organisationnels, des modèles de données type RDF, l'intérêt des systèmes experts ou des procédures de qualité, d'audit et de contrôle légaux sur les SI, etc. nécessitent aussi des compétences, d'autres, qui font des personnes dont c'est le métier des personnes pas moins capables de produire des logiciels. J'imagine que ça te coûte de lire ça mais oui, tu as des personnes moins expérimentées que toi, qui sont capables de faire des logiciels qui fonctionnent, et pas trop mal.
Cela fait déjà quelques années que les conceptions logique et logicielle ne se bornent plus aux seules questions de performance et aux limites matérielles à contourner.
Finalement et j'arrête moi aussi là :
Tu me dis que je fais "M. je sais tout" ? Mais quelle est ta posture face à moi, sinon dire "j'ai tellement du temps à perdre que je vais m'abaisser à lui répondre, ce pauvre crétin ignorant" ? A ce point affreux d'avoir un avis qui ne soit pas le tien : ton avis qui serait donc la vérité vraie et révélée ?
Ne crois-tu pas que ta morne ne vaut pas la mienne lorsque tu écris ça ?
Je ne cherche pas le concours du mérite. J'ai bossé des années sur ce sujet des liaisons sciences de l'information et de l'informatique, alors oui, j'ai une opinion, que j'essaie d'éclairer autant que je peux, qui ne se limite à la taille de mon JSON et qui s'essaye à d'autres choses.
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 1.
Je vais tenter de faire court. Dans mon post précédent, je n'ai fait que parler d'informatique (dont la définition est : théorie et traitement de l'information à l'aide de programmes mis en œuvre sur ordinateurs). En bifurquant vers les processus organisationnels, les aspects légaux,… et autres choses qui n'ont de rapport avec l'informatique que par la magie des discours commerciaux, on s'éloigne du sujet.
Je n'ai aucun doute sur le fait que tu fais cela avec beaucoup d'intelligence, mais ce n'est pas une raison pour chercher par tous les moyens à justifier des choix à l'encontre d'une bonne pratique de l'informatique (genre on s'en fout : des performances, de la bande passante utilisée, de l'accessibilité…).
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.
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".
En pratique, un protocole non binaire, et qui cause en français c'est un magnifique gâchis de bande passante et de CPU.
[^] # Re: Formatage automatique
Posté par JulienG . Évalué à 2.
[ante scriptum : mon dernier commentaire]
En faisant court : tu as défini un périmètre, mais c'est une des visions qui existent du logiciel, propre à l'ingénierie informatique mais certainement pas à "l'informatique" dans toutes ses ramifications et branches. Encore moins de ce qui est attendu aujourd'hui dans les organisations. J'insiste là-dessus.
Amha, ça mérite d'avoir un débat plus large, de qui (me) semble intéressant sur la définition finalement, de ce que c'est le développement et son attendu. Mon propos n'est pas de dire que tu as tort (tu n'as pas tort), mais que ta position ne me semble pas tenir lieu d'une généralité.
En faisant long : Si tu ne veux pas bouger de ton périmètre alors soit, mais ne me dit pas que je cherche "par tous les moyens" de mon côté. Que tu déjuges ou déconsidères un argument, ne le rend pas inopérant pour autant, parce que tu restes sur le pas de ta porte.
Le projet que j'ai soumis est "parfaitement imparfait" : une proposition sur des travaux perso., toujours en cours pour la meilleure approche.
Sur la question de l'orientation attendue sur la performance, le sujet a été débattu dès 1958/59, où les travaux plus universitaires ont accentué leur séparation avec l'ingénierie informatique pure émergente. L'histoire est connue :
- la branche "proche système" (au démarrage impérative, avec Fortran, C, etc.) ;
- (vs) la branche "abstractive" (Lisp et dérivés, les AST, le fonctionnel).
… Entre ceux qui vont exploiter complètement la puissance de calcul de la machine (qui iront très vite dans les entreprises, désireuses d'investir à moindre coût dans une informatisation extrêmement coûteuse), et ceux qui en veulent d'abord un usage généraliste, une "intelligence artificielle" - nb : le terme a l'époque porte sur les systèmes expert, la faculté de décision et de raisonnement pour une machine ; rien à avoir avec notre acceptation moderne : on est alors sur des systèmes de résolution d'assertions.
Notre débat est une ramification grossière de ces deux visions, qui se sont affrontées, avant de devenir plus complémentaires et de concert.
On avait encore à l'époque une grande diversité d'architectures matérielles et parfois, même pas de distinction dans les types de "mémoire" (je pense aux premières machines LISP, avec quelques parallèles que l'on peut faire avec l'approche choisie par Intel sur Optane Memory).
Avec en toile de fonds, la prise de possession par les sciences de gestion d'une partie des sciences informatiques avant qu'elles ne deviennent, au sein des organisations durant le milieu / fin des années 70, une entité de recherche et d'application indépendante.
Dit autrement : le logiciel est bien plus que qu'un assemblage applicatif, de scripts ou de codes divers. Il n'est pas éthéré et vient dans un SI qui est l'organisation elle-même. Il répond à un besoin (métier) et n'y a aucun autre intérêt, aucun but, aucun moyen à dépenser qui n'y soit pas rattaché. L'optimum d'un traitement strictement machine dont tu parles, était vrai il y a longtemps, où l'octet coûtait cher et les machines """rares""" (fin des années 90/début 2000). Cela reste largement enseigné dans les études informatiques, notamment celles où l'ingénierie est reine. Cependant ce n'est pas forcément une attente économique.
Désormais l'optimum est à chercher entre le coût de développement et de maintenance (ton salaire et celui de tes homologues n'est pas gratuit : optimiser un programme n'est pas toujours financièrement intéressant) ; la rentabilité d'un processus organisationnel qui l'utilisera (un logiciel très performant mais que personne ne maîtrise est détourné, abandonné ou pire pas maintenu par de futures équipes) ; la capacité à en extraire de l'information utile et à se justifier (audit, suivi et maîtrise, etc.) ; dernièrement les questions de sécurité et de sûreté, comme de la tolérance du SI aux pannes et à la gestion de la redondance.
Perdre 5% ou 10% de performance d'un logiciel n'est pas toujours un drame, même en augmentant les charges d'infras derrière. Parce que tes choix comme DSI ou proche de la DSI, sont contraints par des aspects sociaux, légaux, métiers - tout ce que tu veux.
Je ne parle même pas de la dette technique, qui pour le coup, parfois, oblige à des recherches très pointues sur l'optimisation "du 2Go/s pour un JSON" parce que l'architecture globale est déficiente, ou simplement n'est plus adaptée, ou face à un soucis hors norme de masse (tout le monde n'est pas Netflix, Facebook… !). Dans la quasi-totalité des organisations, on cherche donc moins à dépasser la dette que la contourner à moindre coût (souvent, cela revient à ne pas arrêter la production, ni modifier trop en profondeur un équilibre logiciel fragile, non-documenté, bloquant des refontes plus larges). Là effectivement, l'impératif d'efficacité peut se faire jour avec force. La fréquence de cette recherche d'efficacité en fait une généralité, mais pas un fait systématique et encore moins un but. Je tente de ne pas mélanger la cause et la conséquence.
Pour la maîtrise de l'architecture, encore faut-il avoir donc pensé aux points de la scalabilité et de la redondance - et là où nous pouvons nous rejoindre, c'est que Robert n'a certainement pas atteint l'objectif (mais après tout, c'est une proposition initiale, personne n'est contraint d'en faire usage…).
Ce n'est pas un effet de style si on est passé d'une qualification de "système informatique" (et donc de direction informatique) à "système d'information" (et donc de "direction des systèmes d'information"). Il y a une logique derrière. Personnellement ça ne me dérange pas qu'on considère que l'informatique n'est qu'elle-même, un concept un peu "indépassable", mais c'est un signe si les "cellules de gestion de projets" et autres modalités d'organisations se multiplient dans les DSI pour modifier les habitudes et les approches.
Je n'ai rien, absolument rien à te vendre : je ne te rapporte pas un propos commercial, je ne te vends pas du rêve ; je te donne mon opinion de ce que j'ai pu trouvé après des heures à la bibliothèque universitaire ou en entretien. Tu ne prendras certainement pas les arguments, mais toi comme moi, nous nous ne nous adressons pas à l'autre mais aux lecteurs qui nous ont le mérite de nous lire.
Et je t'assure, évoquer les sciences de gestion dans les années 70 ou l'intérêt d'un travail ontologique au sein d'une organisation pour piloter le schéma de données et le développement applicatif d'une DSI n'a rien de bandant ! Au contraire, ça provoque le rejet et l'impatience (voire une pointe de mépris…).
Anecdote : lors de ma soutenance, mon jury me dit "propos passionnant, innovant [en réalité pas tant que ça, je fais une synthèse de travaux d'autres horizons pas encore rapprochés]. Comment voulez-vous vendre ça à une entreprise ?!" -> Je ne peux pas. L'historique culturel est en défaveur de l'approche "organisationnelle" des SI… mais des signes commencent à émerger.
Illustrons le propos. Un exemple que je suis attentivement : la ré-émergence du "no-/low-code", les services Amazon Lambda (idem chez Microsoft, IBM, Google… ces 3 dernières années), l'approche "fonctionnelle" sur tout un tas de langages très différents et une logique événementielle. Le schéma global de ces services :
1. un événement quelconque
2. un filtre
3. une fonction déclenchée, éventuellement avec la notion de grappes de travail derrière
4. une réponse renvoyée et/ou stockée.
Plutôt que d'agir sur l'efficacité d'une fonction, on dimensionne sa réplication (maîtrise des coûts : arbitrage sur le temps de calcul global plutôt que l'efficacité unitaire). L'orchestration des fonctions entre elles, créée l'applicatif. En gros tu as un stock de fonctions (ou de fonctionnalités, c'est-à-dire de sous-applicatifs), qui tu lies entre elles, de manière arbitraire, possiblement sans ligne de code pour l'utilisateur final.
Présentation ici (la vidéo explicite bien) :
https://aws.amazon.com/fr/lambda/
Ces services cherchent justement à minimiser les coûts globaux pour les clients. Ils reprennent de vieilles théories, qui ont facilement 30 ans, avec les systèmes experts, qui eux-même n'avaient aucunement besoin de personnes ayant des talents de codeurs pour faire des logiciels (je pense à CLips par exemple*), en l'adaptant à ce qui est possible aujourd'hui.
Réellement, ce n'est ni plus ni moins que la ré-invention un poil modernisé des systèmes experts.
(* : L'expression choisie était celle des maths en inspiration, car il n'y avait pas guère de possibilités d'une interface évoluée. Ce n'est plus le cas aujourd'hui et je serais heureux le jour où une personne qui n'a pas de compétence informatique, sera capable de faire un logiciel convenable, avec un code généré propre et relativement bien pensé, parce qu'il se sera concentré sur les besoins de son métier et pas plus. On y arrive, doucement.)
Le but est de moins chercher cette partie d'optimisation purement mixte logicielle/matérielle, mais d'aller vers une meilleure applicabilité du logiciel au global et pour répondre aux exigences des procédures. C'est le sens de l'histoire : sinon autant rester à l'assembleur (zéro abstraction, tu n'auras pas mieux en terme de performance).
Deux des exemples qui allient beaucoup de facettes que j'évoque :
- le projet européen SPECIAL (l'application d'une politique de sécurité à maillage très fin sur n'importe quel d'objets)
https://www.specialprivacy.eu/
- la thèse doctorale de Jérémy Lhez sur le "Filtrage, stockage et raisonnement sur de grands volumes de triplets RDF ordonnancés"
https://pastel.archives-ouvertes.fr/tel-02084022/document
Comme je l'ai indiqué auparavant dans les commentaires, c'est bien le métier qui fait l'outil et pas l'outil qui fait le métier. Il doit donc être efficient et après, éventuellement, performant.
Les grandes boîtes ont un temps d'avance du fait de leurs moyens justement, et elles ne sont déjà plus sur la question de la numérisation (terminée) mais de l'abstraction de leurs outils numériques (SAAS, "cloudification" et autres) :
- elles ne veulent plus piloter du code mais une interface et un traitement logique (interface + traitement = logiciel) ;
- elles veulent davantage de développements rapides (c-à-d écrits vite) et efficients ;
- elles ne veulent plus gérer de la dette technique ni de contraintes organisationnelles trop fortes à cause de problématiques informatiques.
L'efficacité (en octets traités/seconde), les profils techniques pointus, arrivent après, en support pour rester dans du temps de calcul raisonnable mais pas en chef orchestre ni en finalité (exemple des "product owners" qui ne sont plus plus des pilotes techniques et couvres d'abord les attentes fonctionnels).
Pour le reste :
- tu es probablement un très bon programmeur et je ne doute pas une seconde que tu aies une meilleure connaissance que moi, notamment pour la gestion fine stack ou heap. Pour Robert, ma priorité est davantage la mise en grappe du processus que l'usage de la mémoire, tout en continuant à assurer la possibilité de soutenir un modèle RDF ;
- tu as entièrement raison un protocole binaire est plus efficace qu'un protocole qui se lit humainement. Mais j'ai préféré qu'il soit lisible par le plus grand nombre (dans l'espace francophone). Sur le sujet nos positions sont irrésolubles.
Enfin et pour conclure là, les hypothèses sur lesquelles j'ai travaillé ces dernières années et qui me motivent encore aujourd'hui. Elles n'ont aucune force de lois. Je les donne ici, pour parfaire le contexte de mon propos.
A. HYPOTHÈSE N°1 – « IL EXISTE UN ‘AUTRE CHEMIN’ POUR LES SI. »
B. HYPOTHÈSE N°2 – « LE SI EXISTE DANS DES CADRES HUMAINS TRÈS CONTRAINTS. »
C. HYPOTHÈSE N°3 – « LA DIRECTION DES SI DOIT DÉSORMAIS ÉVOLUER FORTEMENT. »
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 3.
Merci pour cette réponse bien détaillée et étayée sur… la gestion des systèmes d'information.
Ce qui, pour moi et pour le Larousse, n'a RIEN à voir avec l'informatique.
C'est avec ce melimelo que l'on se retrouve avec tout un tas de gens qui pense faire de l'informatique quand ils utilisent Excel. Au final, le DSI c'est celui qui a su dépanner un PC et réinstaller le Windows sur le PC du patron.
Le même DSI qui va monter en "compétences" abreuvé de stratégie "isomorphe à l’organisation et aux circuits d’information formalisés et non-formalisés".
C'est encore pire dans les grosses boîtes, car ils sont formés à l'école pour cela.
J'ai pas mal d'exemples de clients, de conseils régionaux, banques, société du CAC40 et multinationales (dans lesquels j'ai bossé ou ai des amis dans ces structures); dans les faits on y trouve la pire informatique du monde, certains quittent à peine Windows XP, d'autres se font hacker dans les grandes largeurs, d'autres ont quasiment un serveur pour 10 employés (car le cloud c'est cool, les micro-services aussi…)
La crise sanitaire actuelle a aussi démontrée que les "grandes" DSI se montrent incapables de gérer le télétravail.
Je nuancerais aussi ton constat sur le besoin de performances, car sauf erreurs, Google, Amazon et Microsoft ont au total des millions de serveurs, ceux sont les plus gros consommateurs de bande passante et de CPU au monde.
Bref, ils ont la plus grande partie des serveurs produits, leur faire gagner 1% de performance ou diminuer la bande passante, c'est toucher le jackpot.
Tu comprends donc pourquoi je tique fortement sur le fait de recommander Python, qui peut être 30x plus lent que le C/C++/Rust/Java/C#… cf les benchmarks cités plus haut.
De plus, accepter de perdre 5% de performance ici et la, fait qu'au final (à force d'empiler les services, frameworks, librairies,…) on accepte que l'utilisation des ordinateurs se dégrade non-stop, alors que les performances du matériel soient en constante progression.
Pour la petite histoire, aujourd'hui un collègue a utilisé l'éditeur de texte par défaut de son Ubuntu (19.10) pour modifier un fichier SQL de 20Mo (sur un PC i5 gen9, 32 Go de RAM, SSD nVme), 40 secondes pour sauvegarder le fichier modifié de 10 caractères.
Je trouve cela lamentable, un PC d'il y a 20 ans permettait de modifier ce genre de minuscule fichier et de le sauvegarder en moins d'une seconde.
Les arguments de maintenabilité, d'adaptabilité et "d’orthogonalité avec la stratégie de déploiement des projets de diversité d'hyper-structurabilité homomorphe aux besoins opérationnels dans le cadre de la démarche qualité et d'adéquation du besoin intrinseque du profil utilisateur" (oui, je sais… c'est cadeau :) )… sont des inepties de ceux qui ne veulent pas admettre que c'est codé/designé par des quiches.
Un éditeur de texte correcte peut très bien être écrit avec un langage objet, être testé, avoir un code simple à comprendre et courte… ET sauvegarder un fichier de 20Mo en moins de quelques microseconde sur un SSD qui peut encaisser 2Go/s en écriture.
Concernant Robert, je ne peux que te souhaiter de prendre note des avis que tu as eu ici (documentation, performance, anglais…), ça ne nécessite qu'un peu d'investissement mais engendrera beaucoup de satisfaction (pour tous).
[^] # Re: Formatage automatique
Posté par barmic 🦦 . Évalué à 3.
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.
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,…
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
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 1.
Le cas de Redis est intéressant, la page doc se termine par :
"While comparable in performance to a binary protocol the Redis protocol is significantly simpler to implement in most very high level languages, reducing the number of bugs in client software."
C'est écrit donc c'est vrai?
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 ?
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?
A moins que l'on considère que l'appel d'une fonction est "comparable" à l'appel d'un service réseau.
Apres je conçois très bien que l'on puisse avoir différents processus souhaitant discuter avec une "map" unique. Mais autant minimiser le coût des 'appels'.
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.
libRobert.so ? ;)
[^] # Re: Formatage automatique
Posté par barmic 🦦 . Évalué à 1.
J'ai pris Redis car c'est LA référence1 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.
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…
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.
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.
Ça dépend du contexte. Mon
poobjectif 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.par là il faut comprendre que ce n'est pas le meilleur dans tous les use case, mais que tous doivent se comparer à ce dernier et c'est largement le plus utilisé. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à -1.
Si je comprend bien, une application avec des threads et faire attention à la consommation en bande passante et CPU, c'est considéré comme difficile à faire correctement ou long à écrire.
Du coup, est utilisée la solution la moins mauvaise, et tout le monde s'en félicite car c'est la plus utilisée ("auto congratulation" garantie).
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é?
Concernant Redis, les avantages présentés sont "la facilité d'implémentation par les clients qui résulte d'une diminution de bugs".
Dans le même genre, on a MySQL, LA base de données qui par défaut ne détectait pas d'erreur de type… si on insérait un entier dans un champs "VARCHAR", sans la moindre difficulté. Surement aussi "par facilité d'usage". A priori, toujours n°1 : https://www.eversql.com/most-popular-databases-in-2018-according-to-stackoverflow-survey/
Bref, l'idée n'est pas de donner des leçons ou d'arriver avec mes gros sabots; j'en ai juste un peu marre de voir l'informatique partir en vrille année après année, conséquence d'un "jenfoutisme" global, ou tout est histoire de mode, ou tout est recrée sans cesse en moins bien.
Aujourd'hui je peste parce que l'éditeur de texte par défaut d'Ubuntu prend 30 secondes pour enregistrer 20Mo, dans 5 ans, ça sera peut être en 5 secondes. Restons "optimistes".
Dans le genre, petite dédicace à Sage, éditeur à 1Md de CA, qui ne voit pas non plus le problème quand son logiciel phare de gestion prend 3 jours (oui, 3 jours) pour exporter une liste d'article de 3Mo.
"Ils ont considéré que le gain en performance ne valait pas les autres avantages" ?
[^] # Re: Formatage automatique
Posté par barmic 🦦 . Évalué à 3.
alors que plus haut :
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
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 3.
Non, ce n'est pas ce que je voulais dire, dit autrement : l'argument de popularité pour justifier que quelque chose est bien ou bon, n'est pas un bon argument (mais un biais courant, cf https://fr.wikipedia.org/wiki/Argumentum_ad_populum).
C'est un peu brutal, de résumer par "les choses ne te plaisent pas tant pis pour toi",
quand aux problèmes précis de bande passante et processeur utilisées,
tu bifurques par "face à d'autres avantages", sans les mentionner ni les évaluer.
Idem pour la non difficulté de multi-thread'er et de gérer la concurrence d'une "map" dans le contexte d'un seul serveur.
Est ce que qu'on parle toujours informatique avec quelque chose d'aussi flou que :
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).
[^] # Re: Formatage automatique
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 01 mai 2020 à 21:18.
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 :
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
[^] # Re: Formatage automatique
Posté par JulienG . Évalué à 1.
Peut-être parce que l'informatique ce n'est pas qu'une unique question de logiciels justement ? Mais d'infrastructure, d'organisation, etc. - et que c'est l'architecture globale autour d'un besoin et du possible qui importe.
Un exemple qui me vient : la mise en place d'un bastion d'administration (je pense par exemple aux contraintes des normes voulues dans les OIV… mais ça semble se généraliser grâce à l'action de l'ANSSI) dans une "vieille" architecture, figée et difficile à bouger, comme on en trouve beaucoup dans les PME françaises : l'éditeur peut ne plus exister ; les sources non-documentées ; les personnes qui ont pensé certaines parties ou certaines organisations des traitements ne sont plus là: ce qu'elles ont pu faire avait peut-être du sens à leur époque, …
Face au décideur, bon courage si tu penses seulement "logiciel" comme un tout unique et cohérent dans ta réponse, qui évolue forcément bien et uniformément.
Car il y a le logiciel, mais aussi le réseau à gérer. Les traitements métiers, qui ont pu évolué, qui peuvent être en partie analogiques voire physiques. Du SCADA. Certains applicatifs ne supportent pas tel ou tel protocole (pas de TLS/SSL, etc.). Il faut des proxy partout, des routes à ne plus en finir, être capable de faire dialoguer des choses qui n'ont pas été forcément prévues pour communiquer vers l'extérieur.
Rajouter les contraintes de redondance, de sécurité, logger pour motifs légaux. C'est une réalité. Pas juste un discours de "marketeux". Et avant de parler de la seule performance, on parle de viabilité, d'intérêts, de conditions préalables.
Bref tu te retrouves avec une évolution "organique" d'un logiciel ou d'un ensemble applicatif, qui peut être monolithique ou pas, avec des blocs qui ont été faits à des périodes différentes, des besoins différents - dont un contexte qui évolue.
Tu pars du principe que forcément personne ne remet en question une "mauvaise" architecture. Je ne crois pas que ça soit blanc ou noir. Tu peux être conscient d'une situation et devoir gérer une basse réalité qui soit complexe à gérer et faire évoluer.
+1 : un "cache" (amélioré) peut servir aussi à vérifier les droits, servir d'intermédiation au sens large, accélérer un accès, etc. Ou comme indiqué juste avant, servir d'agent nécessaire pour la mise en place d'un bastion d'administration qui ceinture un applicatif pas nécessaire sûr ou éditable, pour faire remonter des informations sur le fonctionnement de l'ensemble.
Voire dans certains cas, c'est même plus ou moins lui qui sera le co-pilote, si tu as du batch processing qui peut planter, se séquencer sans lien entre les opérations, etc. Le cache devient la clé de voûte, évolue et sert à maintenir des connexions à des bases de données, à alerter sur une situation anormale autant qu'à faire réellement du cache de requêtes.
Oui, mille fois oui.
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 2.
Oui, assurément mais, à mon humble avis, tu vas un peu loin sur les aspects de gestion de la vieillesse des systèmes, des aspects légaux,… tu as le même problème avec une automobile, un jour tu ne trouves plus les pièces, elle doit respecter des contraintes légales de sécurité…
Et vu le nombre de logiciels dans ma voitures, dois-je conclure que je fais de l'informatique en l'utilisant?
N'est ce pas dangereux si ce cache n'est pas persistent?
N'est ce pas dangereux si ce cache n'est pas transactionnel?
Tu parles toujours d'un service de cache comme Robert/Redis ?
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 3.
Oups, encore quelques nouveaux points que je ne comprend pas:
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?
A quoi fais tu référence? Les performances sont meilleures si l'on utilise les processus à la place des threads, où de stabilité, de consommation mémoire ?
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.
Il est possible de le faire en PHP, voir https://www.php.net/manual/en/book.shmop.php
Pourquoi pas, en effet (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).
Oui, mais on sort du cas "1 serveur", mes remarques n'étaient que sur ce cas d'utilisation.
On est bien d'accord qu'un cluster, Redis/Robert ont leur utilité.
Ce "problème" (ou "faux problème"), 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.
[^] # Re: Formatage automatique
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 04 mai 2020 à 09:48.
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.
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 ».
S'il est activé et que tu utilise fpm ou en module de ton serveur web.
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.
Et hop ! On file dans la rhétorique. C'est toi qui te demandais si on est toujours dans l'informatique ?
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 :
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-il1 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.
il serait possible de regarder le nombre d'implémentation quelque soit le langage, mais j'ai la flemme. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 2.
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).
Pour la fragmentation, au contraire, plus l'espace mémoire disponible est grand, moins elle est un problème puisque mécaniquement les espaces contigus libre sont importants.
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.
Encore une fois, écrire un driver pour un protocole binaire n'a rien de difficile (par rapport à un protocole ascii) si le protocole est documenté.
De plus tu n'as (quasiment) jamais à le faire car les principaux langages ont tous leurs drivers officiels.
J'avais envie de te dire que le fait que le driver VB n'existe pas pour MongoDB, n'est un manque pour personne, mais en fait, ce driver existe (https://consulity.net/content/consulity-InstallMongoDB.aspx), idem pour Cassandra. Les chiffres sont donc à ajuster.
De plus, sachant qu'il n'y a pas de driver pour COBOL pour ces bases NoSQL, quelle corrélation y vois tu?
[^] # Re: Formatage automatique
Posté par barmic 🦦 . Évalué à 2.
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é.
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 :
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
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 2.
Contrairement à ce que tu penses, il est très facile de me convaincre, mais seulement avec des faits, des choses vérifiables.
En informatique on a la chance de pouvoir expérimenter à peu de frais et surtout d'avoir des systèmes complètements déterministes.
Bref, une explication technique, un bout de code, un résultat de benchmark, je suis preneur.
Un discours marketing ou un truc tiré de la "doc" d'un vendeur, non merci.
Quand Hazelcast dit que pour éviter d'avoir à utiliser plusieurs JVM (qui selon eux est un moyen d'éviter les problèmes de lags liés aux GC), ils préconisent leur solution "Hazelcast IMDG Enterprise HD", tu devrais te poser des questions.
Manque de bol, le Java et les performances, je peux t'en parler des heures (et te sourcer ou montrer par du code, tout ce que je j'avance).
En 2001 j'ai commencé à faire du Java sérieusement avec la version 1.1.8 sur de l'embarqué (settopbox) avec 8Mo de mémoire et un processeur à 50MHz (et ca tournait nickel), je n'ai jamais arrêté de faire du Java depuis (en plus de bien d'autres langages).
Hazelcast fait références aux premiers GCs qui mettaient en pause la JVM, d'où un "lag" (voir https://www.baeldung.com/jvm-garbage-collectors pour les différents GC). Le problème est réglé depuis des années, avec par exemple le GC "G1". Aujourd'hui une application qui est ralentie par un GC est une application qui alloue à tout va avec une gestion de la mémoire mal ou pas pensée du tout.
Pour les protocoles texte vs binaire, effectivement je ne pense pas être convaincu que tout un tas de projets utilisent un protocole binaire et pas texte, car ils leurs développeurs aiment la complexité et introduire des bugs dans les "clients" (argument Redis).
Pour moi, il n'y a pas difficulté à utiliser un protocole binaire, et le gain en bande passante (entre x2 et x4) et en performance est tellement important que cela permet d'en faire plus avec un même matériel ou quantité d'énergie.
[^] # Re: Formatage automatique
Posté par barmic 🦦 . Évalué à 2.
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
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . Évalué à 2.
G1 a encore quelques parties du GC qui requièrent de tout stopper, mais rien à voir avec les premiers GC où tout était fait pendant la pause.
G1 : 128 Go de Heap, en moyenne 250ms
(faut tout de même y aller fort pour allouer 128Go non stop :) )
Les GC ZGC et Shenandoah font encore mieux.
ZGC : moins d'une milliseconde pour 2To…
(Voir https://archive.fosdem.org/2018/schedule/event/zgc/attachments/slides/2211/export/events/attachments/zgc/slides/2211/ZGC_FOSDEM_2018.pdf )
(on peut donc donner raison à Hazelcast pour ceux qui n'utilisent pas ZGC, et remplissent la mémoire vive leur serveur avec 2To de heap)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.