Avec la recharge rapide et une pause environ toutes les deux heures (ce qui est une obligation légale, certains semblent l'oublier)
S’arrêter toutes les deux heures c’est une recommandation, pas une obligation légale. Par ailleurs avec deux détenteurs du permis à bord (le cas le plus courant lors des grands départs en vacances) changer de conducteur n’implique pas un arrêt de plus de quelques secondes ou alors il est lié à un autre motif (pour manger, dérouler les jambes ou attacher mamie à un arbre).
J'ai commencé par GWBasic (parce que c'était livré en standard avec MS/DOS) et j'ai adoré le passage au Pascal. D'abord sans un vrai IDE avec Turbo Pascal 3, puis l'arrivée d'un vrai IDE avec Turbo Pascal 5.5. Et tout ce que je vois aujourd'hui (dans Eclipse/Netbeans/Intellij/VisualStudio/…) reste totalement basé sur les mêmes principes qui sont apparus à cette époque là.
Le passage au C puis au C++ s'est fait sur les outils Borland, et ça m'a bien facilité la vie. Le passage au Java a été plus douloureux.
Le pascal était une bonne transition entre le Basic et le C. On commence à voir un peu plus ce qui se passe sous le capot, sans pour autant y passer sa vie.
Je regrette surtout la gestion des chaînes de caractères, et la longueur stockée au début du tableau - au lieu de l'infâme "\0" à scanner…
Bien sûr il y a des contre exemples et GIT est un très bon cas. C’est pour ça que j’ai dit “souvent” et pas “toujours” :-).
Dans les trucs qui n’ont fait que grimper progressivement sans suivre cette fameuse courbe : Python et d’autres langages, SQL justement, …
Et il y a un autre point : quand on est dans la vague, on ne s’en rend pas forcément compte, aveuglé par l’enthousiasme. J’ai vu beaucoup d’égarement “de bonne foi”. Les routes de l’enfer sont pavées de bonnes intentions. Personne ne peut se targuer de n’avoir jamais été du mauvais côté.
Quand le DLT (Distributed Ledger Technology) avait le vent en poupe, les évangélistes étaient très nombreux, et on pouvait se sentir limite con de ne pas en être.
Ce qui sauve, c’est de se poser les bonnes questions. Mais on passe, comme toi, pour le rabat-joie de service (au mieux) ou pour le vieux con (au pire).
Le sujet pour lequel je me fais beaucoup de soucis et je suis ultra-perplexe, c’est les LLM. J’ai été le vieux con jusqu’à l’an dernier, et là je ne sais plus sur quel pied danser. Les phénomènes d’hallucination sont encore là, empêchant les scénarios les plus interessants d’être réalisables sans intervention/validation humaine, mais y a un vrai potentiel et c’est difficile de tempérer les ardeurs.
OK, OK. Je vais pas répondre à tout, mais dans le désordre…
Je n'ai pas parlé d'absence de schéma, mais d'absence de structure. Par structure, j'entends notamment voire surtout l'intégrité référentielle. Clé primaire, clé étrangère. Des concepts qui sont effectivement absents très souvent (je ne les ai pas toutes utilisées) des bases NoSQL. Et c'est bien le problème que je levais dans mon message initial, puisque c'est bien cette lacune qui fait qu'on s'est retrouvé avec beaucoup d'applications bien pourries.
Or, si il y a bien des cas particuliers où on peut s'en affranchir, c'est loin d'être un cas général. Ce qui n'a pas empêché bien des personnes de se précipiter.
Dans les orientées colonnes, les times series et les bases de données graphes, tu as un travail de modélisation de tes données au moins aussi important qu'en SQL parce que les techno t'y obligent
Si le fait de devoir déclarer les colonnes tu trouves que ça implique "un travail de modélisation au moins aussi important", je suis en total désaccord. Un modèle entité/relation c'est pas que les tables et les colonnes, leur type et basta. Bis repetitum : clé primaire, clé secondaire, mais aussi contraintes d'unicité, clauses de contrôles, gestion des suppressions en cascade, etc.
Les outils NoSQL que j'ai utilisé sont effectivement très orientés montée à l'échelle horizontale. Ils sont pensés pour répondre à une problématique de volumétrie. Problématique qui est extrêmement rare en dehors de cas d'usages peu courants.
Petit partage d'expérience : dans le domaine bancaire, entre grosso modo 2010 et 2018, tout le monde a été vers les distributions Hadoop, et tout particulièrement MapR et HortonWorks. A partir de 2018, elles ont réalisées que "ah ben oups mais en fait on a pas besoin de ces monstres". Aujourd'hui, on décommissionne à tour de bras pour :
- remettre de la base relationnelle classique
- compléter avec du stockage brut (compatible S3)
C'est un mouvement général, et d'ailleurs ces deux sociétés ont connu des difficultés financières majeures et ont été rachetées par des spécialistes du "cimetière logiciel", qui consiste surtout à récupérer la base client et non pas le produit.
Avant cette mort lente, on a investi des dizaines de millions d'euros, on a pondu des monstres (et je pèse mes mots) où pour gérer quelques millions d'enregistrement qui auraient fait l'objet d'un pauvre SELECT/UPDATE, il fallait écrire des traitements à base de Spark ou de Map/Reduce. Et par dessus tout ça, on disait "oui, mais regarde : on peut quand même faire du SQL avec Drill". Sauf que sous le capot, c'était une usine à gaz sans nom, et on a vu revenir les batchs qui prennent 8 heures (véridique). Une fois remigré sur du Oracle ou du Postgre, pif paf on revenait à quelques secondes voire minutes au pire. En 10 fois moins de lignes de code.
J'ai entendu dire plein de fois : "c'est parce qu'on a pas les bonnes ressources". Mais on a JAMAIS réussi à avoir les bonnes ressources, la plateforme n'a jamais été stabilisée, et aujourd'hui, c'est encore un nid à bug. Dès que quelque chose déconne, on a de fortes chances de devoir s'en remettre à l'éditeur, seul à pouvoir nous débloquer. Le genre de situation qu'on croisait une fois tous les 5 ans sur les bases relationnelles, avec pourtant une base applicative 100 fois supérieure.
Tu mélange beaucoup de choses… NoSQL c'est des technologies de base de données, BigData c'est mot-valise qui a était bien trop marketé pour garder encore sont sens de jeu de données trop gros pour entrer dans les bases de données standards
Cet amalgame, il est le résultat de la stratégie de communication des sociétés qui ont poussé les moteurs NoSQL. Pour avoir eu pas mal d'interactions avec des commerciaux (notamment MongoDB), c'était un peu le premier truc qui sortait de leur bouche.
D'ailleurs petite anecdote : à l'époque de mes premières rencontres (vers 2017 je pense), j'ai naïvement demandé : "mais comment on fait pour pouvoir utiliser nos outils existants de reporting/dataviz ?". Réponse : "facile : il suffit de créer une base PostgreSQL en frontal et de définir des foreign tables". Véridique… Aujourd'hui, y'a un peu plus de connecteurs natifs, mais c'est pas encore la joie.
(depuis 20 l'évolution étant ce qu'elle est les bases de données classiques ont considérablement augmentée leur capacité et une partie des techniques BigData sont devenues classiques comme le partitionnement).
Alors, là, je m'étouffe. Le partitionnement, c'est un concept qui existait déjà sur Mainframe IBM dans les années 70. Sur Oracle, j'arrive même pas à me souvenir depuis quand ça existe. Sur PostgreSQL, c'est effectivement récent, mais il y avait déjà des solutions de contournement.
Par contre, ce n'est pas le même partitionnement. C'est uniquement orienté stockage, et pas répartition de l'exécution des requêtes. Mais encore une fois… quand est-ce que c'est vraiment nécessaire ? Et quand ça l'est, je suis le premier à promouvoir d'autres solutions que de la base relationnelle.
C'est très discuté parce que relativement peu de techno suivent véritablement cette courbe et quand elles le suivent on parle de période allant de quelques années à 10 ans. Relancer continuellement dessus 20 ans après n'a pas de sens.
Là désolé, je comprends pas. "Relancer continuellement dessus 20 ans après n'a pas de ses" ? De quoi parles-tu ? "Peu de techno suivent véritablement cette courbe" ? On vit pas dans le même monde. Blockchain et Smartcontracts, ça te parle ? Microservices ? On peut lister les frameworks Web ?
Cette manière de tout amalgamer pour rejeter c'est un peu comme si je disais que SQL c'était vraiment nul parce que les ORM c'est de la merde.
Tiens, juste histoire de prendre le contre pied. Les ORMs j'ai beaucoup lutté (avec moi-même autant qu'avec les autres) pour en obtenir un usage raisonné. Très bien pour le CRUD, très dangereux pour des process complexes où une gestion de la transaction "à la main" s'avère moins casse-gueule.
Et bien c'est la même chose pour le NoSQL. Aujourd'hui je lutte contre le réflexe "on va tout mettre dans MongoDB / Cassandra / ". Mais j'hésite pas une seconde si je pense que c'est le bon outil. Mais je vais y réfléchir vraiment longtemps. Parce que souvent les équipes se trompent sur leur besoin en terme volumétries.
On pourrait parler aussi de dette/avoir, en plus du classique passif/actif. C'est également dans le sens comptable cela dit.
Dette dans le sens où le fait d'avoir mis en place de l'IA dans une voiture rend la compagnie (potentiellement) redevable auprès de ses clients, dès lors qu'il faut procéder régulièrement à des campagnes de rappel coûteuses, ou faire face à des procès.
Tu remarqueras que je n'ai pas "disqualifié" la technologie. Mais le fait est que durant plusieurs années, ça a été utilisé par défaut juste parce que c'était neuf, c'était beau, c'était forcément bien. Et oui, ça correspond parfaitement au "Hype Cycle" décrit par Gartner ou Forrester. Mais c'est bien à ça qu'on pense quand on parle d'effet de mode en informatique.
Pour ceux qui ne connaissent pas, c'est une théorie (souvent vérifiée par la réalité) qui dit que pour toute nouvelle technologie, il y a d'abord une phase ascendante (dans l'usage/engouement) très importante (l'effet "hype") puis une phase de descente ("la désillusion") tout aussi raide, puis à nouveau une courbe ascendante beaucoup plus douce - l'âge de raison pourrait-on dire.
C'est exactement ce qu'on a observé avec NoSQL. Pour une raison simple : ça correspond à la psychologie humaine et l'effet boule de neige. Y'a un gars qui a une bonne idée (on va dire un mec chez Google qui pond une lib). Ca se répand assez rapidement ("si Google utilise ça, il faut faire pareil !"). Ensuite, les gens se rendent compte que "ben non, en fait j'ai pas besoin de ça, c'est juste ultra compliqué pour rien dans mon cas". Puis finalement les personnes qui en ont vraiment l'usage rendent la techno pérenne.
Et oui aussi, je mélange NoSQL et BigData. C'est vrai que ce sont deux technos bien différentes, et avec des objectifs différents, mais avec la même approche "fuck the structure, on verra plus tard".
en éliminant la rigidité des bases de données relationnelles, permettant de livrer plus rapidement en s'économisant des contraintes liées aux bases relationnelles
Les bases relationnelles et leurs "contraintes", leur "rigidité", ont fait suite au stockage fichier simple (type VSAM), pour répondre à une problématique récurrente : on se retrouvait systématiquement dans des situations d'incohérence, parce que le code au-dessus des données ne gérait pas bien l'intégrité.
Donc, pouf, on crée les bases relationnelles et le SQL.
Et 20/30 ans plus tard, des p'tits malins se disent "ouais, trop pénible les contraintes de structure, nous on va tout péter, pas de règle, liberté totale".
Alors, c'est venu de vrais besoins dans des situations bien particulières. Mais comme tout effet de mode, on s'est retrouvé à voir du MongoDB ou du Cassandra ou du Hadoop pour gérer des bases ultra classiques, bien structurées. Mais au lieu que cette structure soit garantie par le moteur de stockage, tout s'est retrouvé déporté dans le code applicatif, qui évidemment ne fait pas le taf, laisse passer plein de merdes, et on se retrouve avec des données vérolées jusqu'à l'os.
"Ouiiiii, mais c'est pour faire du prototypage". Mais bien sûr. Et le prototype, y'a toujours un gars qui va dire qu'il fait le taf, donc faut le pousser jusqu'à la prod. Pourquoi réécrire quelque chose qui marche après tout ? Et hop, une appli moisie en production. Le stagiaire est content, mais le mainteneur qui reprend l'appli 4 ans plus tard pleure toutes les larmes de son corps.
Bref : NoSQL <==> Prudence, et bien y réfléchir à 2 fois, à 3 fois, à 4 fois.
Et comme dit plus haut, les serveurs SQL ont bien évolué. Ils permettent de gérer le meilleur des 2 mondes, ont une connectivité largement supérieure (merci odbc/jdbc/…), ne sont jamais limités à "JSON only".
C'est rigolo, dans son README.md, à la question "est-ce que ça facilite la migration de Linux vers Windows ?", il répond par la négative parce que "ça reste Linux en dessous".
Je pense que ça facilite quand même la transition en rendant l'interface plus familière.
Par contre, le fait que ce soit une vieille interface (celle de Windows 7 donc), ça doit sonner comme un retour arrière, et peut-être renvoyer une mauvaise image de notre OS favori.
Posté par Dring .
En réponse au journal J'ai une idée de cadeau....
Évalué à 2.
Dernière modification le 19 décembre 2023 à 07:09.
Ok le smartphone c’est trop petit. Mais une tablette ? Si le destinataire n’arrive pas à lire dessus même paramétrée avec des gros caractères, elle arrivera quand même à distinguer l’image de la photo, et ce quel que soit le support ?
Sinon j’aime bien le truc e-ink mentionné au dessous mais j’ai jamais trop regardé le côté écologique de l’e-ink. Peu de conso électrique à l’usage, donc a priori c’est cool ; quid de la fabrication et du recyclage ?
Quand c’était la mode des cadres photo numérique, j’en ai vu fleurir un peu partout.
Aujourd’hui ils sont tous dans des placards :-(. Voire à la benne.
Le mieux à mon avis c’est d’envoyer une photo par mail/whatsapp. Et les destinataires la regarde sur leur mobile/tablette/PC. Ça marche très bien avec les grands parents.
Il y a 20 ans (déjà !) quand le promoteur avec lequel j'avais signé sur plan pour un appartement a livré l'immeuble avec plusieurs mois de retard, il a invoqué la force majeure liée aux intempéries.
J'avais galéré pour retrouver des données prouvant que "non, il n'y a pas eu d'intempéries imprévisibles justifiant un tel retard", et j'avais dû payer pour avoir le nécessaire.
Là j'ai l'impression qu'avec ce que Météo France publie j'aurai pu me débrouiller sans monnaie débourser. Donc c'est déjà un pas.
Après, j'ai quand même l'impression de financer Météo France avec mes impôts et donc je ne comprends pas que les données de prévision ne soient pas également disponibles via API sans coût, mais je dois passer à côté de quelque chose quand j'entends parler de "business model" dans d'autres commentaires.
Donc, avec un jeu de données aléatoire, on voit que la courbe d’auto-évaluation est pratiquement plate.
Ce qui est normal, et est induit par l’algo de génération des valeurs aléatoires qui va chercher à faire une répartition statistique équilibrée. C’est le but de la plupart de ces algos.
Du coup le graphique se lit comme suit : quel que soit leur résultat réel, pour chaque quartile on va se retrouver à la même auto-évaluation moyenne.
Ce qui en soit dans la vraie vie serait une découverte incroyable. La courbe de l’étude initiale elle dit autre chose : elle suit la courbe initiale en s’en éloignant aux deux extrémités.
Bref à mon sens c’est la critique qui est à côté de la plaque, pas l’étude initiale à qui on peut seulement reprocher de s’appuyer sur un graphique peu lisible.
L’erreur principale étant de penser que des données « aléatoires » (qui donc ne le sont jamais vraiment) étaient forcément neutres en terme de signification.
Je me demande si je suis le seul à aller encore plus loin dans le détournement de raclette :
inclusion de fromages non réglementaires (camembert, voire une larme de chèvre sur le fromage à raclette)
inclusion de légumes (bon, de fruits si vous préférez), là aussi directement dans le poêlon (tomate, courgette)
crème fraîche powa! Bien épaisse, genre d'Isigny
La seule règle étant : si ça fait plaisir, pourquoi pas ? On essaye de pas tout faire en même temps, sinon on a plus l'impression de manger une raclette, mais ça fait partie des variations qu'on s'autorise.
J'ai un oncle qui mange du pain avec sa raclette (et non, sans salade). Ca fait bizarre, mais là encore si il aime, pourquoi pas ? Il est devenu savoyard il y a près de 40 ans - et malgré cet écart il semble s'être bien fait accepté par les autochtones ; je n'ai vu personne lui jeter des cailloux dans son petit village de montagne.
Je ne sais pas ce que c’est « du web un peu sérieux », mais je sais que :
- derrière de la souscription de crédit avec virement instantanée, front-end mobile, middle qui attaque le site central en API REST, ça tourne comme un moulin 24/7 ;
On parle de mainframe IBM ? Avec du zOS/Connect derrière ou autre chose ? Sans contrainte sur la taille maximum de la réponse (limite à 64KB - oui c'est déjà gros mais des fois c'est pas assez - Bill Gates peut en témoigner).
Le problème d'un curseur, c'est forcément que tout le monde ne va pas le mettre au même endroit et qu'il y a une grosse part de sensibilité dans les choix qui seront faits. Que celui qui prétend être objectif prenne un peu de recul, ou regarde 3/4 ans après le résultat de ses choix… et si il n'a pas de doutes, c'est que c'est un crétin aveugle.
Personnellement, je me suis souvent battu contre l'écriture de script en Perl, parce que j'avais personne sous la main pour les maintenir, et que les besoins étaient ultra rudimentaires, donc on privilégiait Shell + AWK. Cette partie, je l'ai rarement regrettée.
Et quand c'était plus compliqué, effectivement on poussait vers java, parce que toute notre équipe codait en java. Parfois, ça s'est avéré être un poison.
Sur les arguments autour du Mainframe, c'est à double tranchant. On repousse continuellement les migrations, mais IBM se goinfre de plus en plus sur les factures. Et trouver de la compétence est de plus en plus dur. Personne ne peut contester la fiabilité du bouzin, mais on se retrouve avec de plus en plus de surcouches. Quelqu'un a essayé de faire communiquer du Mainframe avec autre chose que du transfert de fichier ou du messaging ? De faire du reporting évolué et personnalisable par le end-user ? Du web un peu sérieux ?
Et pourtant, je suis le premier à dire qu'une interface texte, même pour des utilisateurs lambda, et du code backend en Cobol, c'est le truc qui marche pendant 20 ans avec pratiquement que des évolutions fonctionnelles, pas de la maintenance de framework à la mords-moi-le-noeud ou du contournement de bug mystérieux.
Mais tout ça, c'est des détails. Plein de détails, dans un océan de merdes. Une autre merde, c'est que quand on prévoit un budget pour une refonte de plateforme, on prévoit la migration initiale (je vais passer de Cobol à Java/Angular), mais on oublie de prévoir les 2/3 ETPs sur les 20 ans à venir qui ne vont faire que la mise à jour des cadriciels… Du coup, c'est pas fait, et au bout de 3 ans, parfois avant la fin du projet de migration, tu as déjà une pile logicielle obsolète… Et si tu arrives avec 2/3 ETPs, on te retoque en t'expliquant que la plateforme actuelle est très stable, et fonctionne avec moins de personnes… Le chien qui se mord la queue…
Et comme dit par ailleurs, les choix pris "par projet" dans une organisation qui compte des milliers de plateformes, ça va 5 minutes ; la cohérence est également importante au niveau global. Mais ne doit pas empêcher de basculer de techno quand ça a du sens. Sans basculer trop vite pour ne pas se retrouver dans des impasses.
Si quelqu'un a la formule magique, je suis preneur.
Toujours très content de voir le projet progresser. J'ai une tablette wacom, et j'ai jamais constaté de soucis ; j'ai dû passer entre les gouttes. Après, la tablette en ce qui me concerne c'est plus pour Inkscape que pour Gimp.
Est-ce qu'après la 2.10, ce sera un 2.12, ou est-ce qu'on va passer à la 3.0 ? Est-ce que cette version 3.0 (enfin, 2.99.xx) est considérée comme suffisamment stable pour un usage régulier (par un non professionnel qui réalise des tâches basiques) ?
Et si la 3.0 s'avère encore loin, est-ce qu'il y a quand même moyen d'en avoir une sans devoir faire de compilation, idéalement avec un .rpm officiel, et à défaut un snap ou équivalent ? (en étant conscient des risques bien sûr)
Parce qu'un être humain lambda, ça envoie des fois plus de 35 emails par jour. C'est vrai que dans un cadre perso, ça fait beaucoup, mais "y'a des pics". Est-ce que ce serait pas plus pertinent de faire dans ce cas une limite par semaine ou par mois ?
Je veux dire : une personne qui pour une activité non pro qui envoie 35*30 emails par mois, ça n'est pas réaliste. Le mec est clairement en train d'utiliser un service perso pour une activité pro. Mais avoir un pic à 45 mails sur une journée parce qu'il a 3 conversations un peu agitées avec son avocat ou ce genre de truc un peu merdique qui implique plein d'allers/retours, c'est pas anormal.
Et le jour où ça m'arrive, je peux pas me dire "merde, j'ai atteint les 35 mails ! Je pourrais répondre que demain, ou je repasse sur mon compte GMail".
Très rigolo. J'en n'ai personnellement pas l'usage, mais c'est vraiment toujours épatant de voir ce genre de projet. Surtout quand on se souvient des années de douleurs qu'on a pu connaître à essayer de faire cohabiter Windows/Linux/DOS dans les années 90 (ah les joies du multi-boot et de la guerre du MBR).
[^] # Re: Évolution de l'aviation
Posté par Dring . En réponse au journal L'aviation a-t-elle un avenir ?. Évalué à 8.
S’arrêter toutes les deux heures c’est une recommandation, pas une obligation légale. Par ailleurs avec deux détenteurs du permis à bord (le cas le plus courant lors des grands départs en vacances) changer de conducteur n’implique pas un arrêt de plus de quelques secondes ou alors il est lié à un autre motif (pour manger, dérouler les jambes ou attacher mamie à un arbre).
[^] # Re: prends soin de toi.
Posté par Dring . En réponse au journal J’ai fait fuir les voleurs (trop forte !?). Évalué à 3.
<mode mauvais_gout="on">
Ah oui, je vois le genre : "oh tu as l'air traumatisée ; pas de soucis je vais dormir dans ton lit cette nuit si ça peut te rassurer".
Et quand ça finit par passer, tu réenfiles ta cagoule de cambrioleur ?
[^] # Re: Un petit hommage mastonodique (en anglais)
Posté par Dring . En réponse à la dépêche Décès de Niklaus Wirth, auteur de nombreux langages de programmation. Évalué à 4.
J'ai commencé par GWBasic (parce que c'était livré en standard avec MS/DOS) et j'ai adoré le passage au Pascal. D'abord sans un vrai IDE avec Turbo Pascal 3, puis l'arrivée d'un vrai IDE avec Turbo Pascal 5.5. Et tout ce que je vois aujourd'hui (dans Eclipse/Netbeans/Intellij/VisualStudio/…) reste totalement basé sur les mêmes principes qui sont apparus à cette époque là.
Le passage au C puis au C++ s'est fait sur les outils Borland, et ça m'a bien facilité la vie. Le passage au Java a été plus douloureux.
Le pascal était une bonne transition entre le Basic et le C. On commence à voir un peu plus ce qui se passe sous le capot, sans pour autant y passer sa vie.
Je regrette surtout la gestion des chaînes de caractères, et la longueur stockée au début du tableau - au lieu de l'infâme "\0" à scanner…
[^] # Re: Tout se paye un jour ou l'autre
Posté par Dring . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 6.
Bien sûr il y a des contre exemples et GIT est un très bon cas. C’est pour ça que j’ai dit “souvent” et pas “toujours” :-).
Dans les trucs qui n’ont fait que grimper progressivement sans suivre cette fameuse courbe : Python et d’autres langages, SQL justement, …
Et il y a un autre point : quand on est dans la vague, on ne s’en rend pas forcément compte, aveuglé par l’enthousiasme. J’ai vu beaucoup d’égarement “de bonne foi”. Les routes de l’enfer sont pavées de bonnes intentions. Personne ne peut se targuer de n’avoir jamais été du mauvais côté.
Quand le DLT (Distributed Ledger Technology) avait le vent en poupe, les évangélistes étaient très nombreux, et on pouvait se sentir limite con de ne pas en être.
Ce qui sauve, c’est de se poser les bonnes questions. Mais on passe, comme toi, pour le rabat-joie de service (au mieux) ou pour le vieux con (au pire).
Le sujet pour lequel je me fais beaucoup de soucis et je suis ultra-perplexe, c’est les LLM. J’ai été le vieux con jusqu’à l’an dernier, et là je ne sais plus sur quel pied danser. Les phénomènes d’hallucination sont encore là, empêchant les scénarios les plus interessants d’être réalisables sans intervention/validation humaine, mais y a un vrai potentiel et c’est difficile de tempérer les ardeurs.
[^] # Re: Tout se paye un jour ou l'autre
Posté par Dring . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 5.
OK, OK. Je vais pas répondre à tout, mais dans le désordre…
Je n'ai pas parlé d'absence de schéma, mais d'absence de structure. Par structure, j'entends notamment voire surtout l'intégrité référentielle. Clé primaire, clé étrangère. Des concepts qui sont effectivement absents très souvent (je ne les ai pas toutes utilisées) des bases NoSQL. Et c'est bien le problème que je levais dans mon message initial, puisque c'est bien cette lacune qui fait qu'on s'est retrouvé avec beaucoup d'applications bien pourries.
Or, si il y a bien des cas particuliers où on peut s'en affranchir, c'est loin d'être un cas général. Ce qui n'a pas empêché bien des personnes de se précipiter.
Si le fait de devoir déclarer les colonnes tu trouves que ça implique "un travail de modélisation au moins aussi important", je suis en total désaccord. Un modèle entité/relation c'est pas que les tables et les colonnes, leur type et basta. Bis repetitum : clé primaire, clé secondaire, mais aussi contraintes d'unicité, clauses de contrôles, gestion des suppressions en cascade, etc.
Les outils NoSQL que j'ai utilisé sont effectivement très orientés montée à l'échelle horizontale. Ils sont pensés pour répondre à une problématique de volumétrie. Problématique qui est extrêmement rare en dehors de cas d'usages peu courants.
Petit partage d'expérience : dans le domaine bancaire, entre grosso modo 2010 et 2018, tout le monde a été vers les distributions Hadoop, et tout particulièrement MapR et HortonWorks. A partir de 2018, elles ont réalisées que "ah ben oups mais en fait on a pas besoin de ces monstres". Aujourd'hui, on décommissionne à tour de bras pour :
- remettre de la base relationnelle classique
- compléter avec du stockage brut (compatible S3)
C'est un mouvement général, et d'ailleurs ces deux sociétés ont connu des difficultés financières majeures et ont été rachetées par des spécialistes du "cimetière logiciel", qui consiste surtout à récupérer la base client et non pas le produit.
Avant cette mort lente, on a investi des dizaines de millions d'euros, on a pondu des monstres (et je pèse mes mots) où pour gérer quelques millions d'enregistrement qui auraient fait l'objet d'un pauvre SELECT/UPDATE, il fallait écrire des traitements à base de Spark ou de Map/Reduce. Et par dessus tout ça, on disait "oui, mais regarde : on peut quand même faire du SQL avec Drill". Sauf que sous le capot, c'était une usine à gaz sans nom, et on a vu revenir les batchs qui prennent 8 heures (véridique). Une fois remigré sur du Oracle ou du Postgre, pif paf on revenait à quelques secondes voire minutes au pire. En 10 fois moins de lignes de code.
J'ai entendu dire plein de fois : "c'est parce qu'on a pas les bonnes ressources". Mais on a JAMAIS réussi à avoir les bonnes ressources, la plateforme n'a jamais été stabilisée, et aujourd'hui, c'est encore un nid à bug. Dès que quelque chose déconne, on a de fortes chances de devoir s'en remettre à l'éditeur, seul à pouvoir nous débloquer. Le genre de situation qu'on croisait une fois tous les 5 ans sur les bases relationnelles, avec pourtant une base applicative 100 fois supérieure.
Cet amalgame, il est le résultat de la stratégie de communication des sociétés qui ont poussé les moteurs NoSQL. Pour avoir eu pas mal d'interactions avec des commerciaux (notamment MongoDB), c'était un peu le premier truc qui sortait de leur bouche.
D'ailleurs petite anecdote : à l'époque de mes premières rencontres (vers 2017 je pense), j'ai naïvement demandé : "mais comment on fait pour pouvoir utiliser nos outils existants de reporting/dataviz ?". Réponse : "facile : il suffit de créer une base PostgreSQL en frontal et de définir des foreign tables". Véridique… Aujourd'hui, y'a un peu plus de connecteurs natifs, mais c'est pas encore la joie.
Alors, là, je m'étouffe. Le partitionnement, c'est un concept qui existait déjà sur Mainframe IBM dans les années 70. Sur Oracle, j'arrive même pas à me souvenir depuis quand ça existe. Sur PostgreSQL, c'est effectivement récent, mais il y avait déjà des solutions de contournement.
Par contre, ce n'est pas le même partitionnement. C'est uniquement orienté stockage, et pas répartition de l'exécution des requêtes. Mais encore une fois… quand est-ce que c'est vraiment nécessaire ? Et quand ça l'est, je suis le premier à promouvoir d'autres solutions que de la base relationnelle.
Là désolé, je comprends pas. "Relancer continuellement dessus 20 ans après n'a pas de ses" ? De quoi parles-tu ? "Peu de techno suivent véritablement cette courbe" ? On vit pas dans le même monde. Blockchain et Smartcontracts, ça te parle ? Microservices ? On peut lister les frameworks Web ?
Tiens, juste histoire de prendre le contre pied. Les ORMs j'ai beaucoup lutté (avec moi-même autant qu'avec les autres) pour en obtenir un usage raisonné. Très bien pour le CRUD, très dangereux pour des process complexes où une gestion de la transaction "à la main" s'avère moins casse-gueule.
Et bien c'est la même chose pour le NoSQL. Aujourd'hui je lutte contre le réflexe "on va tout mettre dans MongoDB / Cassandra / ". Mais j'hésite pas une seconde si je pense que c'est le bon outil. Mais je vais y réfléchir vraiment longtemps. Parce que souvent les équipes se trompent sur leur besoin en terme volumétries.
[^] # Re: Mauvaise traduction
Posté par Dring . En réponse au lien L'intelligence artificielle est un passif. Évalué à 2.
On pourrait parler aussi de dette/avoir, en plus du classique passif/actif. C'est également dans le sens comptable cela dit.
Dette dans le sens où le fait d'avoir mis en place de l'IA dans une voiture rend la compagnie (potentiellement) redevable auprès de ses clients, dès lors qu'il faut procéder régulièrement à des campagnes de rappel coûteuses, ou faire face à des procès.
[^] # Re: Tout se paye un jour ou l'autre
Posté par Dring . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4.
Tu remarqueras que je n'ai pas "disqualifié" la technologie. Mais le fait est que durant plusieurs années, ça a été utilisé par défaut juste parce que c'était neuf, c'était beau, c'était forcément bien. Et oui, ça correspond parfaitement au "Hype Cycle" décrit par Gartner ou Forrester. Mais c'est bien à ça qu'on pense quand on parle d'effet de mode en informatique.
Pour ceux qui ne connaissent pas, c'est une théorie (souvent vérifiée par la réalité) qui dit que pour toute nouvelle technologie, il y a d'abord une phase ascendante (dans l'usage/engouement) très importante (l'effet "hype") puis une phase de descente ("la désillusion") tout aussi raide, puis à nouveau une courbe ascendante beaucoup plus douce - l'âge de raison pourrait-on dire.
C'est exactement ce qu'on a observé avec NoSQL. Pour une raison simple : ça correspond à la psychologie humaine et l'effet boule de neige. Y'a un gars qui a une bonne idée (on va dire un mec chez Google qui pond une lib). Ca se répand assez rapidement ("si Google utilise ça, il faut faire pareil !"). Ensuite, les gens se rendent compte que "ben non, en fait j'ai pas besoin de ça, c'est juste ultra compliqué pour rien dans mon cas". Puis finalement les personnes qui en ont vraiment l'usage rendent la techno pérenne.
Et oui aussi, je mélange NoSQL et BigData. C'est vrai que ce sont deux technos bien différentes, et avec des objectifs différents, mais avec la même approche "fuck the structure, on verra plus tard".
# Tout se paye un jour ou l'autre
Posté par Dring . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 10.
Les bases relationnelles et leurs "contraintes", leur "rigidité", ont fait suite au stockage fichier simple (type VSAM), pour répondre à une problématique récurrente : on se retrouvait systématiquement dans des situations d'incohérence, parce que le code au-dessus des données ne gérait pas bien l'intégrité.
Donc, pouf, on crée les bases relationnelles et le SQL.
Et 20/30 ans plus tard, des p'tits malins se disent "ouais, trop pénible les contraintes de structure, nous on va tout péter, pas de règle, liberté totale".
Alors, c'est venu de vrais besoins dans des situations bien particulières. Mais comme tout effet de mode, on s'est retrouvé à voir du MongoDB ou du Cassandra ou du Hadoop pour gérer des bases ultra classiques, bien structurées. Mais au lieu que cette structure soit garantie par le moteur de stockage, tout s'est retrouvé déporté dans le code applicatif, qui évidemment ne fait pas le taf, laisse passer plein de merdes, et on se retrouve avec des données vérolées jusqu'à l'os.
"Ouiiiii, mais c'est pour faire du prototypage". Mais bien sûr. Et le prototype, y'a toujours un gars qui va dire qu'il fait le taf, donc faut le pousser jusqu'à la prod. Pourquoi réécrire quelque chose qui marche après tout ? Et hop, une appli moisie en production. Le stagiaire est content, mais le mainteneur qui reprend l'appli 4 ans plus tard pleure toutes les larmes de son corps.
Bref : NoSQL <==> Prudence, et bien y réfléchir à 2 fois, à 3 fois, à 4 fois.
Et comme dit plus haut, les serveurs SQL ont bien évolué. Ils permettent de gérer le meilleur des 2 mondes, ont une connectivité largement supérieure (merci odbc/jdbc/…), ne sont jamais limités à "JSON only".
[^] # Re: Facilite la transition
Posté par Dring . En réponse au lien Thème pour KDE Plasma pour reproduire look et feel de Windows 7. Évalué à 3.
Mea maxima culpa ! Windows vers Linux biens sûr.
# Facilite la transition
Posté par Dring . En réponse au lien Thème pour KDE Plasma pour reproduire look et feel de Windows 7. Évalué à 5.
C'est rigolo, dans son README.md, à la question "est-ce que ça facilite la migration de Linux vers Windows ?", il répond par la négative parce que "ça reste Linux en dessous".
Je pense que ça facilite quand même la transition en rendant l'interface plus familière.
Par contre, le fait que ce soit une vieille interface (celle de Windows 7 donc), ça doit sonner comme un retour arrière, et peut-être renvoyer une mauvaise image de notre OS favori.
[^] # Re: Pas pérenne…
Posté par Dring . En réponse au journal J'ai une idée de cadeau.... Évalué à 2. Dernière modification le 19 décembre 2023 à 07:09.
Ok le smartphone c’est trop petit. Mais une tablette ? Si le destinataire n’arrive pas à lire dessus même paramétrée avec des gros caractères, elle arrivera quand même à distinguer l’image de la photo, et ce quel que soit le support ?
Sinon j’aime bien le truc e-ink mentionné au dessous mais j’ai jamais trop regardé le côté écologique de l’e-ink. Peu de conso électrique à l’usage, donc a priori c’est cool ; quid de la fabrication et du recyclage ?
[^] # Re: Lol
Posté par Dring . En réponse au journal le plus grand scandale sanitaire de tous les temps, c'est maintenant !. Évalué à 10.
Donc…
- tu ne donnes pas les sources pour les protéger
- mais tout le monde peut les trouver en cherchant
Euh…
# Pas pérenne…
Posté par Dring . En réponse au journal J'ai une idée de cadeau.... Évalué à 3.
Quand c’était la mode des cadres photo numérique, j’en ai vu fleurir un peu partout.
Aujourd’hui ils sont tous dans des placards :-(. Voire à la benne.
Le mieux à mon avis c’est d’envoyer une photo par mail/whatsapp. Et les destinataires la regarde sur leur mobile/tablette/PC. Ça marche très bien avec les grands parents.
[^] # Re: Cette recette est naze !
Posté par Dring . En réponse au journal recette de mousse au chocolat. Évalué à 2.
Il va me falloir un cobaye. Tu es volontaire ? :-)
# C'est déjà utile
Posté par Dring . En réponse au lien La météo de Méteo France en open data !. Évalué à 7.
Il y a 20 ans (déjà !) quand le promoteur avec lequel j'avais signé sur plan pour un appartement a livré l'immeuble avec plusieurs mois de retard, il a invoqué la force majeure liée aux intempéries.
J'avais galéré pour retrouver des données prouvant que "non, il n'y a pas eu d'intempéries imprévisibles justifiant un tel retard", et j'avais dû payer pour avoir le nécessaire.
Là j'ai l'impression qu'avec ce que Météo France publie j'aurai pu me débrouiller sans monnaie débourser. Donc c'est déjà un pas.
Après, j'ai quand même l'impression de financer Météo France avec mes impôts et donc je ne comprends pas que les données de prévision ne soient pas également disponibles via API sans coût, mais je dois passer à côté de quelque chose quand j'entends parler de "business model" dans d'autres commentaires.
# Cette recette est naze !
Posté par Dring . En réponse au journal recette de mousse au chocolat. Évalué à 3.
Il n'y a ni fromage, ni pommes de terre, ni charcuterie ! LinuxFR, ça devient vraiment n'importe quoi !
[^] # Re: La malédiction des JO
Posté par Dring . En réponse au journal Non mais MERDE !. Évalué à 10.
Ils ont eu lieu quand les JOs en Palestine ?
[^] # Re: Total manque de respect
Posté par Dring . En réponse au journal Il est temps que la communauté internationale fasse un choix. Évalué à 2.
Belle découverte ; merci !
# Interessant mais ne remet pas en cause le papier initial
Posté par Dring . En réponse au lien The Dunning-Kruger Effect is Autocorrelation. Évalué à 2.
Donc, avec un jeu de données aléatoire, on voit que la courbe d’auto-évaluation est pratiquement plate.
Ce qui est normal, et est induit par l’algo de génération des valeurs aléatoires qui va chercher à faire une répartition statistique équilibrée. C’est le but de la plupart de ces algos.
Du coup le graphique se lit comme suit : quel que soit leur résultat réel, pour chaque quartile on va se retrouver à la même auto-évaluation moyenne.
Ce qui en soit dans la vraie vie serait une découverte incroyable. La courbe de l’étude initiale elle dit autre chose : elle suit la courbe initiale en s’en éloignant aux deux extrémités.
Bref à mon sens c’est la critique qui est à côté de la plaque, pas l’étude initiale à qui on peut seulement reprocher de s’appuyer sur un graphique peu lisible.
L’erreur principale étant de penser que des données « aléatoires » (qui donc ne le sont jamais vraiment) étaient forcément neutres en terme de signification.
# Total manque de respect
Posté par Dring . En réponse au journal Il est temps que la communauté internationale fasse un choix. Évalué à 4.
Je me demande si je suis le seul à aller encore plus loin dans le détournement de raclette :
La seule règle étant : si ça fait plaisir, pourquoi pas ? On essaye de pas tout faire en même temps, sinon on a plus l'impression de manger une raclette, mais ça fait partie des variations qu'on s'autorise.
J'ai un oncle qui mange du pain avec sa raclette (et non, sans salade). Ca fait bizarre, mais là encore si il aime, pourquoi pas ? Il est devenu savoyard il y a près de 40 ans - et malgré cet écart il semble s'être bien fait accepté par les autochtones ; je n'ai vu personne lui jeter des cailloux dans son petit village de montagne.
[^] # Re: Curseur à géométrie variable
Posté par Dring . En réponse au journal Le sophisme du meilleur outil. Évalué à 4. Dernière modification le 14 novembre 2023 à 14:27.
On parle de mainframe IBM ? Avec du zOS/Connect derrière ou autre chose ? Sans contrainte sur la taille maximum de la réponse (limite à 64KB - oui c'est déjà gros mais des fois c'est pas assez - Bill Gates peut en témoigner).
# Curseur à géométrie variable
Posté par Dring . En réponse au journal Le sophisme du meilleur outil. Évalué à 5.
Le problème d'un curseur, c'est forcément que tout le monde ne va pas le mettre au même endroit et qu'il y a une grosse part de sensibilité dans les choix qui seront faits. Que celui qui prétend être objectif prenne un peu de recul, ou regarde 3/4 ans après le résultat de ses choix… et si il n'a pas de doutes, c'est que c'est un crétin aveugle.
Personnellement, je me suis souvent battu contre l'écriture de script en Perl, parce que j'avais personne sous la main pour les maintenir, et que les besoins étaient ultra rudimentaires, donc on privilégiait Shell + AWK. Cette partie, je l'ai rarement regrettée.
Et quand c'était plus compliqué, effectivement on poussait vers java, parce que toute notre équipe codait en java. Parfois, ça s'est avéré être un poison.
Sur les arguments autour du Mainframe, c'est à double tranchant. On repousse continuellement les migrations, mais IBM se goinfre de plus en plus sur les factures. Et trouver de la compétence est de plus en plus dur. Personne ne peut contester la fiabilité du bouzin, mais on se retrouve avec de plus en plus de surcouches. Quelqu'un a essayé de faire communiquer du Mainframe avec autre chose que du transfert de fichier ou du messaging ? De faire du reporting évolué et personnalisable par le end-user ? Du web un peu sérieux ?
Et pourtant, je suis le premier à dire qu'une interface texte, même pour des utilisateurs lambda, et du code backend en Cobol, c'est le truc qui marche pendant 20 ans avec pratiquement que des évolutions fonctionnelles, pas de la maintenance de framework à la mords-moi-le-noeud ou du contournement de bug mystérieux.
Mais tout ça, c'est des détails. Plein de détails, dans un océan de merdes. Une autre merde, c'est que quand on prévoit un budget pour une refonte de plateforme, on prévoit la migration initiale (je vais passer de Cobol à Java/Angular), mais on oublie de prévoir les 2/3 ETPs sur les 20 ans à venir qui ne vont faire que la mise à jour des cadriciels… Du coup, c'est pas fait, et au bout de 3 ans, parfois avant la fin du projet de migration, tu as déjà une pile logicielle obsolète… Et si tu arrives avec 2/3 ETPs, on te retoque en t'expliquant que la plateforme actuelle est très stable, et fonctionne avec moins de personnes… Le chien qui se mord la queue…
Et comme dit par ailleurs, les choix pris "par projet" dans une organisation qui compte des milliers de plateformes, ça va 5 minutes ; la cohérence est également importante au niveau global. Mais ne doit pas empêcher de basculer de techno quand ça a du sens. Sans basculer trop vite pour ne pas se retrouver dans des impasses.
Si quelqu'un a la formule magique, je suis preneur.
# 2.12 ou 3.0 ?
Posté par Dring . En réponse à la dépêche Sortie de GIMP 2.10.36. Évalué à 3.
Toujours très content de voir le projet progresser. J'ai une tablette wacom, et j'ai jamais constaté de soucis ; j'ai dû passer entre les gouttes. Après, la tablette en ce qui me concerne c'est plus pour Inkscape que pour Gimp.
Est-ce qu'après la 2.10, ce sera un 2.12, ou est-ce qu'on va passer à la 3.0 ? Est-ce que cette version 3.0 (enfin, 2.99.xx) est considérée comme suffisamment stable pour un usage régulier (par un non professionnel qui réalise des tâches basiques) ?
Et si la 3.0 s'avère encore loin, est-ce qu'il y a quand même moyen d'en avoir une sans devoir faire de compilation, idéalement avec un .rpm officiel, et à défaut un snap ou équivalent ? (en étant conscient des risques bien sûr)
[^] # Re: Paliers
Posté par Dring . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 10.
Parce qu'un être humain lambda, ça envoie des fois plus de 35 emails par jour. C'est vrai que dans un cadre perso, ça fait beaucoup, mais "y'a des pics". Est-ce que ce serait pas plus pertinent de faire dans ce cas une limite par semaine ou par mois ?
Je veux dire : une personne qui pour une activité non pro qui envoie 35*30 emails par mois, ça n'est pas réaliste. Le mec est clairement en train d'utiliser un service perso pour une activité pro. Mais avoir un pic à 45 mails sur une journée parce qu'il a 3 conversations un peu agitées avec son avocat ou ce genre de truc un peu merdique qui implique plein d'allers/retours, c'est pas anormal.
Et le jour où ça m'arrive, je peux pas me dire "merde, j'ai atteint les 35 mails ! Je pourrais répondre que demain, ou je repasse sur mon compte GMail".
# Très rigolo
Posté par Dring . En réponse au lien DOS Subsystem for Linux: allowing users to make use of both DOS and Linux applications from DOS. Évalué à 7.
Très rigolo. J'en n'ai personnellement pas l'usage, mais c'est vraiment toujours épatant de voir ce genre de projet. Surtout quand on se souvient des années de douleurs qu'on a pu connaître à essayer de faire cohabiter Windows/Linux/DOS dans les années 90 (ah les joies du multi-boot et de la guerre du MBR).