Critiquer aujourd'hui un logiciel si vieux, dans un domaine qui évolue autant (postgresql ne supporte pas de versions aussi vielles). C'est à minima non pertinent.
Le truc c'est que tu ne critiques pas le logiciel mais l'entité qui est derrière et son fonctionnement. Mongo a bâti sa place en mentant ouvertement (au minimum par omission délibérée et répétée).
Qu'un produit ait des limites annoncées ou quelques bugs est dans l'ordre des choses. Mais quand quelqu'un a passé au minimum 5 ans à mentir sur ses garanties (on parle d'une DB), ça ne me choque pas que quelqu'un puisse ne pas vouloir s'en approcher pour des raisons éthiques ou techniques. D'autres diront que les choses ont changées ces derniers temps et ne verront aucun problème à récompenser ce comportement. Je peux comprendre les deux points de vue.
Ensuite le marketing, je comprends et en même temps je ne comprends pas pourquoi débrancher son cerveau. Sur un sujet dont c'est ton domaine s'appuyer sur les discours marketing, plus que sur l'architecture ça ne me parait pas être une bonne idée et c'est pas comme si mongo inc étaient les seuls à parler de mongo
On ne parle pas de marketing. On parle de mentir sur les garantie offertes dans les documentations techniques, d'avoir des configurations volontairement dangereuses par défaut pour faire croire qu'on est pas si lent que ca, et d'oublier de parler de comment tu as obtenu tes chiffres.
Personnellement, je trouve triste d'être OK avec ça.
Je n'ai malheureusement pas bookmarké à l'époque :(
Tu avais des trucs genre "Je mets à un jour champ avec une virgule dedans" ça t'éclate 1 ou 4 documents en les remplissant de merde, mutant les types ou autre. Je n'ai plus les détails, mais je fouillai le bug tracker pour identifier mes problèmes et était effaré de voir sur le nombre de connerie du genre. C´était systémique.
C'est moi où tu reproche à une base de données NoSQL de ne pas être ACID ?
Non; je pense qu'il reproche à MongoDB d'avoir fait des choix de design et marketing très douteux ainsi que d'avoir réussi à violer presque systématiquement les maigres garanties annoncées dans leur doc pendant ses 5+ premières années d'existence. Ce qui est fondamentalement un problème différent que de trouver que les garanties offertes par un outil ne sont pas adaptés à son besoin.
Ça a commencé par publier des benchmarks montrant à quel point ils étaient "rapides" alors que la configuration par défaut de Mongo était de ne pas garantir la durabilité des écritures acceptés (ie. non persisté dans un WAL).
Ça a continué avec des tonnes de bugs tous plus hallucinants les un que les autres. Si tu as des soirées de libre, remonte le bug tracker jusqu'à la version 3 et tu y trouveras les trucs les plus hallucinants que j'ai pu voir dans ma carrière.
Côté garanties documentées, garanties réellement implémentées et configuration par défaut, on est passé par toutes les étapes possibles de WTF.
Il me semble qu'un changement significatif a eu lieu vers la version 3 et au moment où Aphyr les a mis en pièce. Ils ont commencé à chercher à afficher des garanties raisonnables et à les implémenter correctement. Le surnom snapshat for database de mongo ne vient pas de nul part; et tu peux aisément comprendre que suite à cet historique des gens s'en tiennent le plus loin possible.
Ça parle de Xorg. Sauf si tu link un commentaire particulier.
La commentaires étaient globalement sur Wayland que j'ai lu. C'est plus pour prise de température sur la perception de Wayland par diverse personnes.
Pourtant, au début, il apportait plus de problème que de progrès.
Perso, jamais eu de problème avec Pulseaudio.
L'exemple était simplement pour souligner que globalement systemd et pulseaudio ont été accueilli avec beaucoup d'hostilité. À l'inverse Wayland était plutôt attendu et a été bien accueilli lors de son annonce, mais cela ne semble plus aussi net.
Ça tombe bien, je veux partager […] Bon, c'est loin d'être sec, mais ça arrive
Merci pour le lien. J'irais regarder du côté de xdg-desktop-portal et pipewire, mais d'un point de vu utilisateur ne pas avoir cette possibilité 10 ans après le début du projet et 4 ans après que Wayland soit par défaut sur Fedora ca fait tout de même mal
Il me semble y avoir le sentiment qu'après toutes ces années Wayland n'a pas apporté grand chose alors que l’accueil initial était très favorable. Ca fait la même chose qu'avant, en dehors d'un nombre encore significatif de régressions. Les performances sont globalement les mêmes (j'ai un utilisateur sous Wayland et un autre sous XOrg sur la même machine et je suis incapable de dire la différence). Ca fait 10 ans que c'est en chantier et qu'on a demandé à tout le reste de la pile graphique de refaire dans son coin ce qui a été viré du serveur.
Je suis totalement incompétent pour juger des choix, de l'architecture et de la pertinence de ma perception. En tant qu'utilisateur le constat ne me semble pas fou.
À côté, Pulseaudio marche sans problème depuis des années, fait ce que je lui demande et le progrès par rapport à avant est sans appel.
Le gros avantage pour l’utilisateur, c’est la sécurité. Une application ne peut plus espionner une autre
C'est tellement sécurisé et qu'il est impossible de partager ton écran en appel slack / teams / tout ce que tu veux. Donc professionnellement la première chose que font les gens c'est se virer wayland et de remettre XOrg. Gros pas en avant :(
Wayland semble stagner fortement depuis des années. Peut être que l'approche était finalement trop "simpliste" et montre maintenant ses limites ?
Ça ne pose aucun problème a spécifier et a implémenter. Il faut juste faire son travail correctement.
Le coût de la rentabilité est une grosse blague. En 7 ans ou j'ai bossé sur des data pipeline je peux compter en années ETP le temps passer sur des incidents CSV. On a littéralement claquer des centaines de milliers d'euros là dessus.
Spécifier systématiquement et correctement le format de donnée ça prend 1H par cas (3mn a écrire et le reste en overhead). Écrire de zéro un parser correct c'est une demi journée (on parle d'une bête machine a état hein) et bien sûr ça existe sur étagère, il suffit de configurer correctement les libs. Faire le boulot d'explication ça prend plus de temps mais ça paie toujours rapidement.
En faisant simplement ce travail, mon équipe est arrivée à 0 incidents en manipulant des fichiers venant de dizaines de sources quand les incidents étaient business a usual dans d'autres.
Après dans la vraie vie les séparateurs c'est qu'une petite partie. Encoding, BOM, charset supportés font partie du jeu mais ce n'est pas plus compliqué.
Faire le boulot de spec et savoir écrire des lecteurs stricts ou tolérant selon les cas, c'est juste faire son travail correctement. Si on considère que c'est trop difficile c'est absolument terrifiant sur notre industrie.
J'ai rien contre ces codes ascii. Par contre les utiliser comme séparateurs en supposant qu'ils n'apparaissent pas dans les données c'est une connerie. Si tu fais du CSV tu dois gérer correctement échappement et protection. Il est possible que les séparateurs apparaissent dans les données c'est non négociable et non discutable.
Laisser entendre qu'il y aurait des séparateurs qui évitent les problèmes 95% du temps c'est empirer le problème alors que la solution est simple et connue depuis 40+ ans.
J'ai tellement d anecdotes sur "nan mais ça apparaîtra pas dans les données" que ça en ait déprimant sur la médiocrité ambiante.
Firefox a besoin de fonctionnalités intéressantes pour l'essentiel des utilisateurs que Chrome ne propose pas pour revenir dans la course. Cela
Pour la plupart des usages n'est-on pas arrivé à un point où rien ou presque ne distingue un navigateur d'un autre ? Ils ont tous des performances acceptables (être le premier c'est super mais on s'en fou grave en fait si ca fait ce dont j'ai besoin), la même base de fonctionnalités et un look proche.
Une minorité de power user va vouloir précisément un ou deux trucs qui lui feront préférer ça ou ça. Mais autrement ?
C'est peut être un bon signe, celui qu'on arrive à maturité.
il doit avoir un emplacement pour une carte mémoire amovible. Pas question que j'achète un téléphone sans cela, parce que d'une part, ça permet de ne pas être limité par la mémoire interne si je m'y retrouve à l'étroit, et d'autre part, c'est récupérable même si la carte mère du téléphone tombe en panne. Certes, il y a moyen de bousiller à la fois la carte mère et la carte mémoire, mais c'est rare, tout de même.
Comme indiqué dans un autre commentaire, normalement les SD sont maintenant chiffrées et donc tu ne récupéras rien et tant mieux. Mais aussi le taux de panne des SD dans un téléphone est loin d'être nul. J'ai du cramer 3 sandisk en quelques années qui m'ont été reprise en SAV sandisk sans aucun soucis.
Si tu tiens à quelque chose dans ton téléphone, une sauvegarde semble beaucoup beaucoup plus malin qu'une carte SD. Si tu te fiches d'où vont tes données tu utilises le grand cloud, sinon ton petit cloud, du partage de fichier etc. La seule approche raisonnable avec un téléphone portable est de considérer qu'il peut disparaître du jour au lendemain et que ça ne devrait te poser aucun problème de mettre un coup de marteau dessus maintenant.
qui ont presque tous un autre navigateur plus populaire à côté pour justement ce genre de site?
C'est certainement vrai. Mais les problèmes sont-ils si fréquents que ça ? Je n'ai que FF depuis des années sur desktop et mobile et sauf pour le support chromecast, qui est un sujet différent, je n'ai jamais été bloqué ni ressenti d'avoir un autre navigateur au cas ou.
J'utilise syncthing à la fois pour synchroniser les photos vers mon portable quand le téléphone est sur le bon wifi mais aussi pour synchroniser les photos entre mes téléphones (je garde un vieux tout pourri pour les activités risquées).
En gros ils se positionnent sur une VM un poil plus adaptée aux microservice (footprint un poil plus bas cas et démarrage plus rapide au détriment d'un poil moins de perf en régime de croisière). On reste sur des écarts de quelques pourcents. J'ai pas testé sur des charges réelles.
Le problème, c'est que docker-compose fait monter le dossier public et upload, mais comme les fichiers ont mon UID (genre 20000 sur mon poste), et bien l'utilisateur du container est incapable de créer le dossier public/tmp/upload et ensuite de faire les dossiers dans upload.
Pour les problèmes liés au non alignement des UID dans le container et sur l'host avec les bind mount, une solution est d'utiliser https://github.com/boxboat/fixuid. Basiquement c'est un entrypoint qui aligne l'UID utilisé dans le container par celui que tu passes à docker run.
C'est bien plus compliqué que ce que n'importe qui voudrait. Mais pour les workflows de dev où tu as besoin de bind mount c'est la seule solution que je connaisse.
Posté par ckyl .
En réponse à la dépêche Java 15 est sorti.
Évalué à 6.
Dernière modification le 24 septembre 2020 à 19:12.
Dire que trouver un openjdk 8 est simple est faux. Il n'est disponible que dans les vieilles distro ou sur https://adoptopenjdk.net/
Petit résumé de comment fonctionne l'écosystème Java:
OpenJDK est un projet de développement, ie. un dépôt de code. Il ne fournit pas et n'a jamais fourni de binaires.
La maintenance des branches LTS d'OpenJDK est a la charge d'un maintainer. Historiquement Oracle faisait le taff très longtemps, maintenant il passe la main à quelqu'un d'autre 6 mois après la release. En pratique on va dire qu'on s'en fiche, tout ce qu'il se passe c'est qu'il y a une branche dans le dépôt qui correspond à "Java 8 LTS" avec des tags qui sont posés régulièrement dessus.
Les fournisseurs de JDK basés sur OpenJDK prennent le code de cette branche, peuvent y apporter des correctifs supplémentaire si ils le souhaitent, le compile, le test, passe le TCK et te donnent la possibilité de le télécharger.
Les fournisseurs qui prennent l'upstream sans changement fournissent généralement des binaires jusqu'à la mort de la branche LTS, ca ne leur coûte virtuellement rien le taff de maintenance est fait par OpenJDK. La plupart des fournisseurs sont dans ce cas.
Les fournisseurs qui maintiennent des correctifs supplémentaires, générallement liés à des contrats de support qui te garantissent qu'ils te fournissent les correctifs avant que ca soit intégré upstream choisissent d'arrêter le support d'une version quand ils veulent. C'est juste un cycle commercial.
Oracle JDK correspond à ce dernier cas. Pour Java 8 ils ont arrêtez de filer gratuitement un JDK 8 et n'en fournissent plus qu'à leur client.
Si tu veux un JDK 8 open source gratuit, il suffit de choisir ton fournisseur:
Je crois que tu n'as juste pas compris comment ça fonctionne et que tu fais beaucoup de vagues pour un petit changement de stratégie de la part d'Oracle JDK.
Ça fait hurler les puristes des langages et les chercheurs, mais à l’usage dans l’industrie c’est infiniment plus agréable à utiliser que, par exemple, Scala qui lui a une conception orientée par la théorie.
Si tu as un peu de bouteille dans l'industrie et que tu n'écris pas des applications jetables à court terme, la stratégie payante c'est:
tu regardes passer les langages alternatifs de la JVM
tu joues avec par interet et pour les trucs mineurs
tu attends qu'une partie des trucs intéressant atterrissent Java pour les choses sérieuses.
C'est long, trèès long mais moins que d'avoir du réécrire sa base de code en 5 langages en 15 ans ou de se retrouver avec un mélange de 3 ou 4 :)
Kotlin ne sera pas différent, dans 2..5 ans il n'aura plus d'avantage très significatif et tu te retrouveras avec une base de code dont tu ne sauras pas quoi faire par ce qu'autant l'interop Java <-> autre c'est pas toujours fou mais l'interop autre1 <-> autre2 c'est la déprime totale.
Bref plus tu fais du back / infra plus le ROI est discutable. Après ça ne semble pas poser de problème fondamental à l'écosystème JS de réécrire 100 fois même chose…
Si tu perds patience, autant partir de la JVM. Android c'est différent, il n'y a pas de choix.
J'avais Valhalla en tête qui n'est clairement pas dans le périmètre des record et des JEP actuelles mais qui introduit pour contrainte:
Inline classes are heterogeneous aggregates that explicitly disavow object identity. As a result, they must be immutable, and cannot be layout-polymorphic;
Après avoir relu le state of Valhalla, la dépendance record / inline est faible, techniquement inexistante, mais "tire dans la bonne direction".
Posté par ckyl .
En réponse à la dépêche Java 15 est sorti.
Évalué à 5.
Dernière modification le 15 septembre 2020 à 17:22.
Records […] Cela devrait réduire l’intérêt de lombok ou immutables.
Oui est non. Non pour la partie construction d'objets immutables complexes. Dès que tu sors des cas d'exemple à 4 attributs, en l'absence de paramètres nommés, on n'a toujours pas d'autre solution que le builder pattern pour avoir quelque chose de vaguement lisible et maintenable. Cette partie a été délibérément mise hors périmètre des records, donc leur principal intérêt c'est côté mémoire & perf et boilerplate.
Même l'une des partie les plus fermées, JavaEE s'est organisé au sein d'Apache et est aujourd'hui émancipé d'Oracle.
Eclipse pas Oracle.
mais il le fait au même titre que RedHat, Google ou IBM pour parler de très grosses boite
Je ne vois pas comment on peut sous-entendre que Java prend le même chemin que MySQL si on s'est un peu intéressé au sujet.
Tant que Java reste sur HotSpot, il y a effectivement peu de chances que les choses bougent. La dynamique introduit par Sun que quasiment tout le monde utilise gratuitement la plateforme Java est difficile à remettre en cause. Ce qui explique la passage progressif vers la situation actuelle d'OpenJDK.
Par contre HotSpot est plutôt en fin de vie. Oracle a clairement fait le choix de basculer ses effectifs vers les étapes futures plutôt que vers la maintenance. C'est pour ça qu'ils ont refourgué la gestion des LTS à la communauté depuis Java 11 (le travail de backport sur Java 8 avait été monstrueux par exemple). Si Graal est techniquement extrêmement intéressant, Oracle semble aussi profiter du mouvement pour casser le statuquo du tout libre & gratuit. Une partie sera open source et utilisable gratuitement. Mais les fonctionnalités d'entreprise / performance ne le seront sûrement pas. Pour moi le risque est là. Soit un gros pivot de stratégie si Graal prend, soit que Graal ne prenne pas et que la plateforme ait perdue beaucoup d'efforts.
Java n'est pas plus fais pour durer qu'un autre, il est régulièrement incompatible ce qui fais que quand tu reprends un projet tu dois réécrire une partie.
C'est factuellement faux. Au niveau langage la comptabilité source et binaire sur les 15+ dernières années est limite irréprochable. Tu prends un JAR compilé il y a 15 ans en Java 1.3 ou 1.4, il tourne toujours avec un JRE 15. Tu recompiles, il compile et tourne. Et au passage il tourne plus vite grâce aux amélioration du JIT.
Il existe quelque cas marginaux qui posent des problèmes (coucou bridge method, changement de comportement de substring & cie) et quelques rares nettoyages qui ont été fait en Java 9 sur des API peu utilisées, coûteuses à maintenir ou dangereuses. Ce sont de rares exceptions. Ce sont de rares exceptions. Beaucoup d'évolutions niveau JVM ont été coûteuses pour préserver cet attribut.
Si tu as des problèmes, c'est que les libs que tu utilises elles ne sont pas aussi disciplinées et que les nouvelles versions que tu choisies d'utiliser ont cassées la compatibilité source ou binaire. Ou que tu as choisi de changer de libs car tes besoins ont changés. C'est autre chose que la question d'origine car tu peux toujours utiliser les JAR d'avant, ça tournera.
Donc oui maintenir un projet dans le temps demande de l'effort de maintenance. Il est juste grandement facilité par le fait qu'un binaire qui tourne continuera à tourner. Ça permet de ne pas avoir d'écosystème qui éclate à cause de chaîne de dépendance brisé (ie. pas besoin de recompiler la veille lib stable dont tout le monde dépend sans le savoir et qui n'a pas eu de release depuis 8 ans). Ca permet de continuer à faire tourner le binaire d'un projet arrêté il y 6 ans sans avoir à géler le hard & soft d'un serveur etc. D'autres langages n'ont pas cette culture et le coût à terme n'est vraiment pas le même. Dans la vraie vie, c'est plutôt pratique.
Peut-être que changer radicalement de métier irait mieux ? Mais encore une fois je me retrouve à penser que je perds 71,4% de ma vie.
Même si tu considères que tu perds ton temps à travailler, tu es dans une branche qui paie très bien et qui cherche des gens depuis des années. Tu es un privilégié qui es en position de force pour:
Bien gagner ta vie et y trouver une satisfaction matérielle.
Bien gagner ta vie et récupérer ton temps de vie par bloc (ex. tu peux régulièrement faire de longues pauses en ayant économisé).
Choisir de travailler moins en gagnant normalement sa vie (ex. 4/5, 3/5, sans solde négocié).
Extrêmement bien gagner ta vie en allant là où ça paie, le monde entier ou presque t'offre un visa et avoir encore plus de levier pour les autres stratégies.
Aller vivre dans un endroit qui te conviens en bossant en remote en étant payé comme un roi ou au contrainte un revenu normal.
Rien n'est tout rose loin d elà mais vous habitez quand même dans un pays riche, à faire un métier bien payé où il existe des conditions de travail vraiment pas dégueulasses. Il y a pire pour réussir à trouver son bonheur. C'est le luxe d'avoir des "problèmes de riche".
Peut-être une piste pour certains. Je suis indépendant après avoir été salarié et j'ai l'impression que le salariat biaise le mode de pensée de nombre de personnes:
On attend des choses des autres en étant frustré.
On vit dans un monde normalisé en développant une relation de type parent-enfant avec manager-RH.
L'indépendance force à prendre du recul la dessus. Les relations sont à la fois plus franches, directe et violentes ce que je trouve plus intéressant. Le fait que les deux parties puisse rompre les forcent à se poser de meilleures questions: Est-ce que je fais est satisfaisant pour celui qui me paie ? Est-ce que je continue ? Est-ce que je pousse le bouchon trop loin en faisant ca et l'autre partie va se barrer ? Est-ce que je travail 250 jours par an ou 180 ? Qu'est ce qui est important pour moi et que je veux négocier ?
En salariat, la couche RH rend les choses plus compliquée mais on peut avoir la même démarche. C'est le luxe de l'informatique, les personnes compétentes techniquement et organisationnellement sont suffisamment rares pour que beaucoup plus de choses soit négociables qu'on ne l'imagine.
La question de comment s'épanouir qui était le sujet du journal est différente et intéressante. Mais si tu n'es pas content de la situation, comment peux-tu changer quelque chose ?
Ce n'est pas compliqué, il suffit d'une ou deux seringues. 4 mains et un carton au sol sont utiles si tu n'as pas l'habitude. Si t'as le choix prend du Shimano qui tourne à l'huile minérale plutôt que tout le reste qui tourne au DOT (plus stable dans le temps et pas corrosif).
Pragmatiquement, sur un vélo taf des disques mécanique sont la solution. Tu n'es pas emmerdé par tous les problèmes des v-brake / cantilever qui demandent d'avoir une jante nickel, ça ne coûte rien et l'entretient est inexistant.
[^] # Re: Scylla/MongoDB
Posté par ckyl . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à 10. Dernière modification le 06 août 2021 à 19:10.
Le truc c'est que tu ne critiques pas le logiciel mais l'entité qui est derrière et son fonctionnement. Mongo a bâti sa place en mentant ouvertement (au minimum par omission délibérée et répétée).
Qu'un produit ait des limites annoncées ou quelques bugs est dans l'ordre des choses. Mais quand quelqu'un a passé au minimum 5 ans à mentir sur ses garanties (on parle d'une DB), ça ne me choque pas que quelqu'un puisse ne pas vouloir s'en approcher pour des raisons éthiques ou techniques. D'autres diront que les choses ont changées ces derniers temps et ne verront aucun problème à récompenser ce comportement. Je peux comprendre les deux points de vue.
On ne parle pas de marketing. On parle de mentir sur les garantie offertes dans les documentations techniques, d'avoir des configurations volontairement dangereuses par défaut pour faire croire qu'on est pas si lent que ca, et d'oublier de parler de comment tu as obtenu tes chiffres.
Personnellement, je trouve triste d'être OK avec ça.
[^] # Re: Scylla/MongoDB
Posté par ckyl . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à 5. Dernière modification le 06 août 2021 à 19:01.
Je n'ai malheureusement pas bookmarké à l'époque :(
Tu avais des trucs genre "Je mets à un jour champ avec une virgule dedans" ça t'éclate 1 ou 4 documents en les remplissant de merde, mutant les types ou autre. Je n'ai plus les détails, mais je fouillai le bug tracker pour identifier mes problèmes et était effaré de voir sur le nombre de connerie du genre. C´était systémique.
[^] # Re: Scylla/MongoDB
Posté par ckyl . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à 10. Dernière modification le 06 août 2021 à 13:43.
Non; je pense qu'il reproche à MongoDB d'avoir fait des choix de design et marketing très douteux ainsi que d'avoir réussi à violer presque systématiquement les maigres garanties annoncées dans leur doc pendant ses 5+ premières années d'existence. Ce qui est fondamentalement un problème différent que de trouver que les garanties offertes par un outil ne sont pas adaptés à son besoin.
Ça a commencé par publier des benchmarks montrant à quel point ils étaient "rapides" alors que la configuration par défaut de Mongo était de ne pas garantir la durabilité des écritures acceptés (ie. non persisté dans un WAL).
Ça a continué avec des tonnes de bugs tous plus hallucinants les un que les autres. Si tu as des soirées de libre, remonte le bug tracker jusqu'à la version 3 et tu y trouveras les trucs les plus hallucinants que j'ai pu voir dans ma carrière.
Côté garanties documentées, garanties réellement implémentées et configuration par défaut, on est passé par toutes les étapes possibles de WTF.
Il me semble qu'un changement significatif a eu lieu vers la version 3 et au moment où Aphyr les a mis en pièce. Ils ont commencé à chercher à afficher des garanties raisonnables et à les implémenter correctement. Le surnom snapshat for database de mongo ne vient pas de nul part; et tu peux aisément comprendre que suite à cet historique des gens s'en tiennent le plus loin possible.
[^] # Re: état de Wayland ?
Posté par ckyl . En réponse à la dépêche Nouvelle version de Fedora dite 33. Évalué à 2.
La commentaires étaient globalement sur Wayland que j'ai lu. C'est plus pour prise de température sur la perception de Wayland par diverse personnes.
Perso, jamais eu de problème avec Pulseaudio.
L'exemple était simplement pour souligner que globalement systemd et pulseaudio ont été accueilli avec beaucoup d'hostilité. À l'inverse Wayland était plutôt attendu et a été bien accueilli lors de son annonce, mais cela ne semble plus aussi net.
[^] # Re: état de Wayland ?
Posté par ckyl . En réponse à la dépêche Nouvelle version de Fedora dite 33. Évalué à 6.
Merci pour le lien. J'irais regarder du côté de xdg-desktop-portal et pipewire, mais d'un point de vu utilisateur ne pas avoir cette possibilité 10 ans après le début du projet et 4 ans après que Wayland soit par défaut sur Fedora ca fait tout de même mal
Ex. https://news.ycombinator.com/item?id=24884988
Il me semble y avoir le sentiment qu'après toutes ces années Wayland n'a pas apporté grand chose alors que l’accueil initial était très favorable. Ca fait la même chose qu'avant, en dehors d'un nombre encore significatif de régressions. Les performances sont globalement les mêmes (j'ai un utilisateur sous Wayland et un autre sous XOrg sur la même machine et je suis incapable de dire la différence). Ca fait 10 ans que c'est en chantier et qu'on a demandé à tout le reste de la pile graphique de refaire dans son coin ce qui a été viré du serveur.
Je suis totalement incompétent pour juger des choix, de l'architecture et de la pertinence de ma perception. En tant qu'utilisateur le constat ne me semble pas fou.
À côté, Pulseaudio marche sans problème depuis des années, fait ce que je lui demande et le progrès par rapport à avant est sans appel.
[^] # Re: état de Wayland ?
Posté par ckyl . En réponse à la dépêche Nouvelle version de Fedora dite 33. Évalué à 1.
C'est tellement sécurisé et qu'il est impossible de partager ton écran en appel slack / teams / tout ce que tu veux. Donc professionnellement la première chose que font les gens c'est se virer wayland et de remettre XOrg. Gros pas en avant :(
Wayland semble stagner fortement depuis des années. Peut être que l'approche était finalement trop "simpliste" et montre maintenant ses limites ?
[^] # Re: Mal
Posté par ckyl . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 10.
Ça ne pose aucun problème a spécifier et a implémenter. Il faut juste faire son travail correctement.
Le coût de la rentabilité est une grosse blague. En 7 ans ou j'ai bossé sur des data pipeline je peux compter en années ETP le temps passer sur des incidents CSV. On a littéralement claquer des centaines de milliers d'euros là dessus.
Spécifier systématiquement et correctement le format de donnée ça prend 1H par cas (3mn a écrire et le reste en overhead). Écrire de zéro un parser correct c'est une demi journée (on parle d'une bête machine a état hein) et bien sûr ça existe sur étagère, il suffit de configurer correctement les libs. Faire le boulot d'explication ça prend plus de temps mais ça paie toujours rapidement.
En faisant simplement ce travail, mon équipe est arrivée à 0 incidents en manipulant des fichiers venant de dizaines de sources quand les incidents étaient business a usual dans d'autres.
Après dans la vraie vie les séparateurs c'est qu'une petite partie. Encoding, BOM, charset supportés font partie du jeu mais ce n'est pas plus compliqué.
Faire le boulot de spec et savoir écrire des lecteurs stricts ou tolérant selon les cas, c'est juste faire son travail correctement. Si on considère que c'est trop difficile c'est absolument terrifiant sur notre industrie.
[^] # Re: Mal
Posté par ckyl . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 8. Dernière modification le 07 octobre 2020 à 08:09.
J'ai rien contre ces codes ascii. Par contre les utiliser comme séparateurs en supposant qu'ils n'apparaissent pas dans les données c'est une connerie. Si tu fais du CSV tu dois gérer correctement échappement et protection. Il est possible que les séparateurs apparaissent dans les données c'est non négociable et non discutable.
Laisser entendre qu'il y aurait des séparateurs qui évitent les problèmes 95% du temps c'est empirer le problème alors que la solution est simple et connue depuis 40+ ans.
J'ai tellement d anecdotes sur "nan mais ça apparaîtra pas dans les données" que ça en ait déprimant sur la médiocrité ambiante.
[^] # Re: Firefox a eu sa chance par le public
Posté par ckyl . En réponse au journal Hégémonie et navigateurs. Évalué à 4.
Pour la plupart des usages n'est-on pas arrivé à un point où rien ou presque ne distingue un navigateur d'un autre ? Ils ont tous des performances acceptables (être le premier c'est super mais on s'en fou grave en fait si ca fait ce dont j'ai besoin), la même base de fonctionnalités et un look proche.
Une minorité de power user va vouloir précisément un ou deux trucs qui lui feront préférer ça ou ça. Mais autrement ?
C'est peut être un bon signe, celui qu'on arrive à maturité.
[^] # Re: Critères d'achat
Posté par ckyl . En réponse au journal Une histoire de smartphones. Évalué à 6.
Comme indiqué dans un autre commentaire, normalement les SD sont maintenant chiffrées et donc tu ne récupéras rien et tant mieux. Mais aussi le taux de panne des SD dans un téléphone est loin d'être nul. J'ai du cramer 3 sandisk en quelques années qui m'ont été reprise en SAV sandisk sans aucun soucis.
Si tu tiens à quelque chose dans ton téléphone, une sauvegarde semble beaucoup beaucoup plus malin qu'une carte SD. Si tu te fiches d'où vont tes données tu utilises le grand cloud, sinon ton petit cloud, du partage de fichier etc. La seule approche raisonnable avec un téléphone portable est de considérer qu'il peut disparaître du jour au lendemain et que ça ne devrait te poser aucun problème de mettre un coup de marteau dessus maintenant.
[^] # Re: Firefox a eu sa chance par le public
Posté par ckyl . En réponse au journal Hégémonie et navigateurs. Évalué à 4.
C'est certainement vrai. Mais les problèmes sont-ils si fréquents que ça ? Je n'ai que FF depuis des années sur desktop et mobile et sauf pour le support chromecast, qui est un sujet différent, je n'ai jamais été bloqué ni ressenti d'avoir un autre navigateur au cas ou.
[^] # Re: Nextcloud pour la sauvegarde des photos
Posté par ckyl . En réponse au journal Une histoire de smartphones. Évalué à 7.
J'utilise syncthing à la fois pour synchroniser les photos vers mon portable quand le téléphone est sur le bon wifi mais aussi pour synchroniser les photos entre mes téléphones (je garde un vieux tout pourri pour les activités risquées).
[^] # Re: C'est pas pour casser l'ambiance
Posté par ckyl . En réponse à la dépêche Java 15 est sorti. Évalué à 4.
La plaquette commerciale: https://www.eclipse.org/openj9/performance/
En gros ils se positionnent sur une VM un poil plus adaptée aux microservice (footprint un poil plus bas cas et démarrage plus rapide au détriment d'un poil moins de perf en régime de croisière). On reste sur des écarts de quelques pourcents. J'ai pas testé sur des charges réelles.
[^] # Re: Root
Posté par ckyl . En réponse au journal LinuxFr avec Docker. Évalué à 6.
Pour les problèmes liés au non alignement des UID dans le container et sur l'host avec les bind mount, une solution est d'utiliser https://github.com/boxboat/fixuid. Basiquement c'est un entrypoint qui aligne l'UID utilisé dans le container par celui que tu passes à docker run.
C'est bien plus compliqué que ce que n'importe qui voudrait. Mais pour les workflows de dev où tu as besoin de bind mount c'est la seule solution que je connaisse.
[^] # Re: C'est pas pour casser l'ambiance
Posté par ckyl . En réponse à la dépêche Java 15 est sorti. Évalué à 6. Dernière modification le 24 septembre 2020 à 19:12.
Petit résumé de comment fonctionne l'écosystème Java:
Oracle JDK correspond à ce dernier cas. Pour Java 8 ils ont arrêtez de filer gratuitement un JDK 8 et n'en fournissent plus qu'à leur client.
Si tu veux un JDK 8 open source gratuit, il suffit de choisir ton fournisseur:
Je crois que tu n'as juste pas compris comment ça fonctionne et que tu fais beaucoup de vagues pour un petit changement de stratégie de la part d'Oracle JDK.
Pour plus de détails: https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjpAVwv5DEdnaBr_5pKuHo/edit
Si tu veux essayez différent JDK il existe l'excellent SDKMAN, https://sdkman.io/jdks
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand même)
Posté par ckyl . En réponse à la dépêche Java 15 est sorti. Évalué à 8.
Si tu as un peu de bouteille dans l'industrie et que tu n'écris pas des applications jetables à court terme, la stratégie payante c'est:
C'est long, trèès long mais moins que d'avoir du réécrire sa base de code en 5 langages en 15 ans ou de se retrouver avec un mélange de 3 ou 4 :)
Kotlin ne sera pas différent, dans 2..5 ans il n'aura plus d'avantage très significatif et tu te retrouveras avec une base de code dont tu ne sauras pas quoi faire par ce qu'autant l'interop Java <-> autre c'est pas toujours fou mais l'interop autre1 <-> autre2 c'est la déprime totale.
Bref plus tu fais du back / infra plus le ROI est discutable. Après ça ne semble pas poser de problème fondamental à l'écosystème JS de réécrire 100 fois même chose…
Si tu perds patience, autant partir de la JVM. Android c'est différent, il n'y a pas de choix.
[^] # Re: Immutables
Posté par ckyl . En réponse à la dépêche Java 15 est sorti. Évalué à 3.
J'avais Valhalla en tête qui n'est clairement pas dans le périmètre des record et des JEP actuelles mais qui introduit pour contrainte:
Après avoir relu le state of Valhalla, la dépendance record / inline est faible, techniquement inexistante, mais "tire dans la bonne direction".
Tu as parfaitement raison sur la déconstruction.
# Immutables
Posté par ckyl . En réponse à la dépêche Java 15 est sorti. Évalué à 5. Dernière modification le 15 septembre 2020 à 17:22.
Oui est non. Non pour la partie construction d'objets immutables complexes. Dès que tu sors des cas d'exemple à 4 attributs, en l'absence de paramètres nommés, on n'a toujours pas d'autre solution que le builder pattern pour avoir quelque chose de vaguement lisible et maintenable. Cette partie a été délibérément mise hors périmètre des records, donc leur principal intérêt c'est côté mémoire & perf et boilerplate.
[^] # Re: le meilleur langage pour les projets d'entreprise
Posté par ckyl . En réponse au journal Toileharicot 12 est dehors. Évalué à 2.
Eclipse pas Oracle.
Tant que Java reste sur HotSpot, il y a effectivement peu de chances que les choses bougent. La dynamique introduit par Sun que quasiment tout le monde utilise gratuitement la plateforme Java est difficile à remettre en cause. Ce qui explique la passage progressif vers la situation actuelle d'OpenJDK.
Par contre HotSpot est plutôt en fin de vie. Oracle a clairement fait le choix de basculer ses effectifs vers les étapes futures plutôt que vers la maintenance. C'est pour ça qu'ils ont refourgué la gestion des LTS à la communauté depuis Java 11 (le travail de backport sur Java 8 avait été monstrueux par exemple). Si Graal est techniquement extrêmement intéressant, Oracle semble aussi profiter du mouvement pour casser le statuquo du tout libre & gratuit. Une partie sera open source et utilisable gratuitement. Mais les fonctionnalités d'entreprise / performance ne le seront sûrement pas. Pour moi le risque est là. Soit un gros pivot de stratégie si Graal prend, soit que Graal ne prenne pas et que la plateforme ait perdue beaucoup d'efforts.
[^] # Re: le meilleur langage pour les projets d'entreprise
Posté par ckyl . En réponse au journal Toileharicot 12 est dehors. Évalué à 3.
Peux-tu expliciter ? Quelle évolution à cassé quel code ?
[^] # Re: le meilleur langage pour les projets d'entreprise
Posté par ckyl . En réponse au journal Toileharicot 12 est dehors. Évalué à 1.
Adopt OpenJDK est "juste" un système de packaging d'OpenJDK. Il participe à l'écosystème mais ne peut être le future.
[^] # Re: le meilleur langage pour les projets d'entreprise
Posté par ckyl . En réponse au journal Toileharicot 12 est dehors. Évalué à 3.
C'est factuellement faux. Au niveau langage la comptabilité source et binaire sur les 15+ dernières années est limite irréprochable. Tu prends un JAR compilé il y a 15 ans en Java 1.3 ou 1.4, il tourne toujours avec un JRE 15. Tu recompiles, il compile et tourne. Et au passage il tourne plus vite grâce aux amélioration du JIT.
Il existe quelque cas marginaux qui posent des problèmes (coucou bridge method, changement de comportement de substring & cie) et quelques rares nettoyages qui ont été fait en Java 9 sur des API peu utilisées, coûteuses à maintenir ou dangereuses. Ce sont de rares exceptions. Ce sont de rares exceptions. Beaucoup d'évolutions niveau JVM ont été coûteuses pour préserver cet attribut.
Si tu as des problèmes, c'est que les libs que tu utilises elles ne sont pas aussi disciplinées et que les nouvelles versions que tu choisies d'utiliser ont cassées la compatibilité source ou binaire. Ou que tu as choisi de changer de libs car tes besoins ont changés. C'est autre chose que la question d'origine car tu peux toujours utiliser les JAR d'avant, ça tournera.
Donc oui maintenir un projet dans le temps demande de l'effort de maintenance. Il est juste grandement facilité par le fait qu'un binaire qui tourne continuera à tourner. Ça permet de ne pas avoir d'écosystème qui éclate à cause de chaîne de dépendance brisé (ie. pas besoin de recompiler la veille lib stable dont tout le monde dépend sans le savoir et qui n'a pas eu de release depuis 8 ans). Ca permet de continuer à faire tourner le binaire d'un projet arrêté il y 6 ans sans avoir à géler le hard & soft d'un serveur etc. D'autres langages n'ont pas cette culture et le coût à terme n'est vraiment pas le même. Dans la vraie vie, c'est plutôt pratique.
[^] # Re: Partagé
Posté par ckyl . En réponse au journal Epic poursuit Apple en justice pour le monopole AppStore. Évalué à 3.
Une analyse super intéressante du sujet: https://capiche.com/e/ecommerce-and-app-store-fees-compared
[^] # Re: Motivation quasi nulle
Posté par ckyl . En réponse au journal Quelles sont vos motivations au travail ?. Évalué à 8.
Même si tu considères que tu perds ton temps à travailler, tu es dans une branche qui paie très bien et qui cherche des gens depuis des années. Tu es un privilégié qui es en position de force pour:
Rien n'est tout rose loin d elà mais vous habitez quand même dans un pays riche, à faire un métier bien payé où il existe des conditions de travail vraiment pas dégueulasses. Il y a pire pour réussir à trouver son bonheur. C'est le luxe d'avoir des "problèmes de riche".
Peut-être une piste pour certains. Je suis indépendant après avoir été salarié et j'ai l'impression que le salariat biaise le mode de pensée de nombre de personnes:
L'indépendance force à prendre du recul la dessus. Les relations sont à la fois plus franches, directe et violentes ce que je trouve plus intéressant. Le fait que les deux parties puisse rompre les forcent à se poser de meilleures questions: Est-ce que je fais est satisfaisant pour celui qui me paie ? Est-ce que je continue ? Est-ce que je pousse le bouchon trop loin en faisant ca et l'autre partie va se barrer ? Est-ce que je travail 250 jours par an ou 180 ? Qu'est ce qui est important pour moi et que je veux négocier ?
En salariat, la couche RH rend les choses plus compliquée mais on peut avoir la même démarche. C'est le luxe de l'informatique, les personnes compétentes techniquement et organisationnellement sont suffisamment rares pour que beaucoup plus de choses soit négociables qu'on ne l'imagine.
La question de comment s'épanouir qui était le sujet du journal est différente et intéressante. Mais si tu n'es pas content de la situation, comment peux-tu changer quelque chose ?
[^] # Re: Non
Posté par ckyl . En réponse au journal Prime réparation vélo. Évalué à 4.
Ce n'est pas compliqué, il suffit d'une ou deux seringues. 4 mains et un carton au sol sont utiles si tu n'as pas l'habitude. Si t'as le choix prend du Shimano qui tourne à l'huile minérale plutôt que tout le reste qui tourne au DOT (plus stable dans le temps et pas corrosif).
Pragmatiquement, sur un vélo taf des disques mécanique sont la solution. Tu n'es pas emmerdé par tous les problèmes des v-brake / cantilever qui demandent d'avoir une jante nickel, ça ne coûte rien et l'entretient est inexistant.