barmic 🦦 a écrit 5783 commentaires

De même, éviter de dépendre de projets stockés sur gitlab.com, et qui pourraient être trop peu actifs.

Le gestionnaire de version utilisé par tes dépendances, c'est pas vraiment ton sujet. Tous les services de dépôt se réservent le droit de wipe ton projet à leur discrétion et en auto hébergé tu n'a aucune idée de la qualité de l'hébergement et de si celui qui gère ça pas péter une durit demain. Seul les organisations comme Apache, Eclipse et peut-être GNU font quelque chose pour ça.

Le problème en question c'est amha de dépendre d'un code peu ou pas supporté, est que si tu a personne pour s'assurer que le dépôt soit up, tu as probablement pas plus de bras pour renouveler les noms de domaine, mettre à jour les certificats, vérifier les failles des dépendances,…

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

plus de temps à les patcher pour la sécurité, à les superviser, à les opérer en général (tout avoir automatiser ne change rien au fait que ça prend plus de temps que sur peu de serveurs).

De mon expérience quand tu as peu de serveur, tu procrastine l'automatisation ça prend donc au final plus de temps et c'est sujet à plus d'erreur du coup. Et tu as des temps de disponibilité bien plus allongé parce que tu dois attendre que l'admin prenne en compte ta demande.

Parce que oui l'automatisation n'est pas gratuite, mais plus on s'y prend tard plus c'est compliqué. Mais ça permet d'y passer du temps quand tu le souhaites et pas d'y passer du temps quand tu as une demande avec de la pression ou autre chose à faire.

il faut avoir suffisamment de services pour les remplir d'un point de vue économique

C'est bien plus simple de dimensionner des petites machines que des grosses.

Des petites machines tu peux aussi les allumer/éteindre au besoin. Sans aller jusqu'à de l'élasticité où tu allume ou éteint en fonction de la charge, tu peux éteindre des machines les week-ends déjà.

Les petites machines sont bien plus souples aussi. Si tu as plusieurs réseaux physiques et que finalement tu veux une machine de plus d'un côté et une de moins de l'autre c'est faisable. Tu peux faire la même chose si tu veux finalement déployer sur plusieurs sites sans augmenter la capacité totale (tu veux juste gagner en résilience).

Les grosses machines viennent aussi avec des contrats constructeurs très chère et bloquant par exemple avec un DRM pour n'utiliser que des disques du constructeur.

Les petites machines te permettent d'utiliser des vlans pour segmenter ton usage.

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

Tu peux le tourner comme tu veux, mais la croissance économique est en effet indispensable, rien que pour maintenir le niveau de vie moyen dans une population croissante.

Comment est-ce que tu rationalise ça avec par exemple le fait que le jour du dépassement approche de la moitié de l'année ?

Au passage, ta phrase présente un biais. La population qui croie c'est dans le monde. En France notre population se stabilise (la population continue de croitre, mais la vitesse de cette croissance diminue), généralement quand on parle de croissance de population comme un problème on pense aux pays très peuplés comme l'Inde ou la Chine ou les pays en voie de développement qui n'ont pas encore fait leur transition démographique. Tout en parlant de maintenir le niveau de vie de la population française. Parce que pour une bonne partie de la population mondiale il serait indécent d'avoir comme objectif d'uniquement maintenir leur niveau de vie. Je vois ta question comme « Comment dans un monde où il va y avoir de plus en plus de monde, nous, pays riches, pourront-nous garder notre niveau de vie ? ».

Et par dessus tout, il n'est pas du tout sûr qu'on sache organiser la décroissance sans sombrer dans une dépression inédite, et on ne sait encore moins comment ne faire décroitre qu'une partie de la population (ceux qui ont déja beaucoup et qui justement ne veulent surtout pas décroitre) sans faire décroitre ceux qui n'ont pas grand chose.

Mais il y a des choses qui sont sûres si on se cache les yeux, on ne l'organisera pas mieux et moins on a de temps pour l'organiser moins bien ça se passera. Ah et si ça arrive de manière contrainte, pas contrainte par un choix de gouvernement mais par les faits, ça se fera dans la douleur la plus totale et oui ça risque de déprimer pas mal de gens. Tous le temps que l'on passe à négocier c'est contribue à aggravation les problèmes à l'avenir.

Si on veut maintenir au mieux le niveau de vie des gens, c'est en se demandant comment on construit une société qui consomme moins pas en multipliant les stratégies d'évitement.

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

Tu semble n'utiliser aucunes des définitions du Larousse du mot capitalisme. Ce n'est pas l'existence de la propriété privée, mais celle du capital dont il est question.

Même la notion de propriété privée a pas mal évolué dans le temps. La propriété intellectuelle n'a pas toujours existé par exemple et la mise en commun fut quelque chose de bien plus commun à d'autres époques.

Si je me souviens bien des explications du guide en visitant le site de fouille d'Akrotiri : les familles ne possèdent pas de maison tout les lieux sont partagé par usage et pas par propriété. Tout n'était peut être pas en commun (quoique), mais la norme était le commun puisque tu n'avais même pas d'endroit où placer ta possession. Je parle là du début de la ville 5 millénaire avant JC donc bien le néolithique.

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

Je ne comprends pas le principe. Une css et les classes sont faites pour modifier la présentation du contenu alors que les micro formats sont là pour formaliser du contenu. Ça n'a pas grand chose à voir.

L'un sera très spécifique à un site qui choisi de présenter en vert ou rouge par exemple en fonction de divers critères, l'autre sert à l'échange et à la manipulation automatisée.

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

C'est pourtant bien toi qui ose cette comparaison

Non J'ai comparé 5G et FM :

Tu parles de ces radios qui émettent en fm (qui consomme plus que la 5G il me semble)

Et oui je l'ai dis, mais répète le une fois de plus ça me paraît pertinent.

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

Je serais curieux des bilans énergétiques comparés entre émetteurs Hertziens et transmission ADSL/Fibre.

Je suis loin d'être un connaisseur. Suffisamment pour ne pas l'aventurer dans une comparaison entre 2 technologies qui n'ont rien à voir. Et je me suis planté entre consommation et émission les FM émettent entre 10W et 10kW (c'est une question de portée) quand une antenne 5G plafonne à 200W.

Mes sources :

• la FM
• la 5G

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

Je ne sais pas combien de place ça prends (je n'ai pas envie de rajouter ne serait-ce qu'une seule vue à ces aberrations), mais j'imagine que ça se compte en gigaoctets à multiplier par le nombre de vue qui si ça se trouve se font sur des écrans en définition full-HD voire moindre.

Intuitivement c'est ni la place ni le réseau qui me semblent les plus consommateurs mais les encodages et décodages.

Mais si on veut essentialiser et pointer toujours l'autre qui fait pire (et à qui on demande d'agir avant nous), on peut parler du déploiement en triple de la fibre ce qui consomme énormément de ressources (déplacer des gens et faire des trous en triple).

Les podcasts de certaines radios qui pourraient juste fournir un flux audio, se sentent obligés d'avoir un support vidéo qui consiste uniquement à un égaliseur et va prendre bien plus de bande passante que s'ils diffusaient juste la bande son.

Tu parles de ces radios qui émettent en fm (qui consomme plus que la 5G il me semble), qui ont des podcasts audio (sur les plate-forme et via leurs appli à minima) et qui vont aussi sur youtube parce que hors fm c'est là qu'ils ont le plus d'audience ?

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

C'est le rôle de McKinsey

Je doute que McKinsey s'abaisse à ça. Les licences de trucs et de machin c'est assez prosaïque pour eux. Par contre tu as des VRP Microsoft, Apple, Oracle, SAP,… Qui vont t'offrir le plus beau restau de ta vie (quand ils peuvent) et t'expliquer à quel point c'est trop bien chez eux, qu'ils savent tout faire, que la concurrence c'est des bricolos et que si tout le monde vient chez eux c'est bien que c'est les meilleurs du monde et peut être bien de l'univers ! Le prix des licences pour t'offrir les services des plus forts de l'univers c'est que dalle ! De l'univers tu te rends compte ?! Ah par contre non ce VRP ne sera pas là quand ça merdera.

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

J'ai plus simple de faire crontab -e qui est installé et fonctionne par défaut et de supprimer la ligne après l'opération que de devoir activer un daemon supplémentaire pour une action qui se passe très rarement.

shutdown -h 18:00

Est très pratique à l'occasion.

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

Le temps d'une version ou deux. Et c'est justement le souci avec Ubuntu : ça lance des trucs mais pas vraiment de suivi sur le long, ça girouette d'une version à une autre :s

Tu as des éléments pour dire ça ou c'est juste du pif ? Parce que canonical reste principal développeur d'apparmor (donc ils continuent de payer des gens pour travailler dessus) et la dernière version et sortie avant hier et la précédente 5 mois avant. Pourtant quand Canonical abandonne quelque chose ils ne semblent pas faire dans la demi mesure comme avec upstart.

https://gitlab.com/apparmor

Je crois bien que la communauté n'est pas si motivée que ça.

Encore une fois tu as des éléments ? Après que l'impossibilité viennent d'une question technique ou de l'impossibilité pour la communauté de s'y mettre, ça ne change pas le problème.

Euh… y a que les versions vraiment requises dans mon souvenir. Si t'as 5 logiciels qui ont besoin de 3 versions différentes d'une bibliothèque tu te retrouve avec trois version et non cinq !

Ça dépend de comment c'est fait, mais comme pour snap/flatpack ça demande de tout rebuild il me semble. Mais tout est fait pour te permettre de ne pas respecter ça. Et certaines descriptions (comme on peut en trouver ici même vont préconiser d'au contraire verrouiller tes dépendances et c'est logique c'est l'une des raisons d'être de nix).

SELinux tout en trouvant que c'est bien que ce ne soit pas activé par défaut dans les distros grand public (c'est pas top en terme de sécu mais c'est plus simple pour la cible)

C'est bien pour ça que certains tentent d'autres approches fournissant plus de sécurité tout en restant plus simples.

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

Oui, on pourrait améliorer AppArmor (pas taper) ou intégrer Nix par exemple

Parce que personne n'y a pensé ? C'est justement Canonical qui a mis pas mal de billes dans AppArmor depuis pas mal de temps, ils ont peut être une idée de ce qu'on peut arriver à faire ou non avec ? C'est peut être un choix stratégique de leur par, mais bon des LSM on en a 4 ou 5 (apparmor donc mais aussi selinux, smack, tomoy et le plus récemment mergé au noyau landlock). À ma connaissance malgré les années (SELinux a 22 ans), seul selinux est véritablement démarré en mode actif uniquement sur rhel et consort… AppArmor a lui même était créé pour simplifier SELinux. Je ne sais pas si c'est possible ou pas d'améliorer AppArmor, mais je suis certains que si quelqu'un a une idée la communauté et preneuse parce qu'elle n'a pas l'air de s'en sortir (pour le déployer sur du grand publique donc hors de machines à usage plus ou moins dédiées administré par quelqu'un de motivé pour activer et configurer les règles). Perso j'apprécie les principe je suis pas contre les LSM ni un en particulier, mais ça semble complexe de le déployer en grand publique (et j'entends par là qu'il soit lancé en mode restrictif).

Quant à nix, ça fais exactement ce que tu ne veux pas, c'est à dire avoir 37,972 versions de la même bibliothèques pour que chaque logiciel puisse linker avec celle dont il a envie, le tout en prenant un max de place.

Au passage, existe-t-il une étude qui corrobore l'aspect sécurité quand on multiplie les même bibliothèques avec des mises à jour réparties au petit bonheur ?

Et est-ce qu'il en existe une qui corrobore que le principe de moindre privilège n'est pas prépondérant aux mises à jour ?

Tu trouvera rien pour ça amha et d'autant plus quand c'est pour des machines de bureaux.

Mais bon en soit l'un empêche pas l'autre, il n'y a pas de raison de les mettre en opposition. D'autant que si j'ai bien compris ubuntu se dirige vers la fourniture de snap comme d'autres fournissent des rpm et donc de reconstruire et mettre à jour tous leur snap quand ils veulent mettre à jour une bibliothèque.

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

De ce qu'on m'avais expliqué.

Car si on les diluent, elle sont en quelques sortes toujours ajoutées et il y'a forcément des systèmes plus critiques où le mensonge n'est pas envisageable et donc qui devraient continuer à la gérer comme actuellement (donc je pense que ce n'est pas le sens de la proposition).

Les systèmes les plus critiques ne font jamais aucun changement d'heure ni ralentissement ni accélération. Ils gèrent une heure interne qui est stable et qui garde continuellement les propriétés dont ils ont besoin et convertissent l'heure quand il faut "sortir" cette heure.

C'est un peu comme changer ou non l'heure du bios quand tu change l'heure de ton OS.

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

Bof, hein. Il y a aussi un tas de projets totalement open source qui marchent.

Pour un qui marche combien échouent ?

Les 3 projets que tu cite, en étant pas très sympa Mongo et elastic ayant quitté les licences licences libres alors que docker propose simplement un outil et des services à côté qui sont payants, sont dans un domaine où ils ont en face d'énormes prédateurs qui sont en position de monopoles ou quasi monopoles.

Mongo et ES ont essayé et ont échouer à suivre leur développement en libre. C'est tout aussi intéressant que de regarder ceux qui marchent, mais il faut replacer les projets dans leur contexte pour comprendre comment est ce que ça peut marcher ou pas.

Le succès n'est pas une question d'être le meilleur, mais une question de positionnement, de chance, d'opportunités,… La qualité intrinsèque joue mais ce n'est qu'un élément parmi d'autres.

Pour moi, L'open source ne devrait pas se limiter au confort des développeurs, mais s'adresser avant tout aux utilisateurs finaux, parce c'est pour elles et eux qu'on bosse au final.

Alors si déjà personne n'a de devoir comme ça surtout à ses dépend (consommer de son temps, de son énergie et de son argent), mais en plus si les développeurs ne peuvent pas vivre de leur projet ça ne va pas donner le même résultat final.

Vivre du libre n'est pas impossible mais est compliqué. Pour un certain nombre qui réussissent voir qui réussissent très bien un paquet échouent. La faute à pas de chance pour une partie, mais aussi du fait que le succès ne dépend pas que du code, mais aussi de sa communication¹, de son positionnement,… Monter un projet dont on veut vivre n'est pas très différent de monter une entreprises sur bon nombre de sujets.

Faire culpabiliser ceux qui essaient et tenter de leur faire de grandes leçons de morale n'aide pas à mon avis.

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

Il dit que des classes clairement annoncées comme ne faisant pas partie du standard avec 0 garanties de maintenance ne peuvent pas être utilisée comme exemple de cassage d’api/abi.

Oui mais c'est ce que je dis tu ne peut pas les ignorer pour autant parce que ce sont des fonctionnalités qui constituent dans les faits une partie de la plateforme. Quelqu'un qui bosse là dedans qui construit un projet qu'il fourni gratuitement et dont l'écosystème bénéficie très clairement lui. Venir avec de gros sabot en disant « c'est pas dans notre contrat d'interface, donc va falloir vivre sans à partir de maintenant ». C'est non seulement arrêter net une dizaine de projets parmi les plus populaires de la plateforme, mais aussi donner un grand signal à toute la communauté que quelque soit ce que tu aura apporté, tu peux te faire dégager ton projet si tu ne rentre pas tout à fait dans ce qui a était contractualisé.

Encore une fois, les contributeurs d'OpenJDK ont tout à fait acté ce fait et ont abandonné leur objectif de retirer Unsafe tant qu'ils n'auront pas d'alternatives.

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

Si tu veux un programme en mode graphique… Tu connais beaucoup de bibliothèques graphiques C ① multi-plateformes et ② qui n’ont pas cassé leur API au moins une fois au cours des vingt dernières années ?

C n'était qu'un exemple, mais des bibliothèques qui n'ont pas cassées ça se trouve oui, la première qui me vient à l'esprit c'est évidement Tcl/Tk. Mais c'est vraiment des gens qui ont choisi java pour swing ?

Si le prix à payer pour ça est de devoir continuer à utiliser Java8 (par ailleurs toujours officiellement maintenu, contrairement à Python2 par exemple) le temps de trouver les ressources pour porter ce qui doit l’être vers une version plus moderne, ben ça me semble un prix bien modique.

Pas moi adoptium fourni le JDK8 jusqu'en 2026, le JDK11 jusqu'en 2024, le JDK17 jusqu'en 2027, le prochain JDK en LTS sera le JDK21 qui sortira en 2023 et dont le support ira jusqu'à 2028.

L'absence de mise à jour de la plateforme c'est à minima plus de mise à jour de LTS comme du reste de la partie crypto. Et je ne te parle pas du support de plateforme comme les nouvelles d'Apple.

Donc ils vont faire quoi ? Attendre 2026 pour tenter tant bien que mal de faire une migration 13 versions ? Et c'est à ce moment là qu'ils vont rugir que vraiment la compatibilité de java c'est pas top ? À partir de là ils n'auront plus que des version dont le support restera 4 ans.

Si comme tu le dis c'est compliqué structurellement de faire des mises à jours de java ces 8 dernières années, ils vont vivre un enfer tout en sortant des versions potentiellement buguées et relativement loin de l'état de l'art de la plateforme qu'ils utilisent (parce que ça prends du temps d'utiliser correction les records, de profiter des threads légers, etc).

Ils font bien ce qu'ils veulent (d'autant que les perspectives en 2000 n'étaient pas celles d'aujourd'hui), je n'utilise pas leur logiciel, je ne connaît pas toute leur problématique et je serait très content pour eux si tout marche comme sur des roulettes, mais à mon humble avis la vie d'apparente insouciance risque fort dans une certaine douleur.

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

Pour le coup java souffre plus d'une image que de faits.

Alors pour le coup, quand je lance un programme et qu’il crashe au démarrage, pour moi c’est un fait et pas une image. :p

Ça ne veut pas dire que c'est compliqué à corriger.

Bienvenue dans le monde des projets académiques. Votre première mission, si vous l’acceptez, sera d’obtenir des financemements pour tenir ce programme à jour, en justifiant auprès des organismes de tutelles que vous n’allez ajouter aucune fonctionnalité, juste permettre au programme de continuer à fonctionner comme avant.

C'est un mauvais choix de plateforme. Tu as des tas de plateformes largement plus stable. Si tu écris ton projet en C89 tu pourra ne rien toucher tant que gcc/clang supporteront ce standard et il n'y a aucune planification à ma connaissance pour le retirer. C'est quelque chose à prendre en compte.

Mais du coup, quand j’entends quelqu’un vanter la rétro-compatibilité de Java en disant qu’un programme écrit il y a vingt ans peut toujours tourner sur un JRE moderne, on est d’accord que j’ai le droit de rire jaune ?

Oui (d'autant que du coup j'ai pas compris ce qu'il voulait dire par "saint"), je dis tout de même que ce n'est pas soit tout noir soit tout blanc.

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

Dans ce cas pour moi on ne parle pas de la même chose. Je parle de la rétrocompatibilité des ABI et API uniquement, pas de la plateforme en entier.

C'est un déplacement du problème pas une correction.

Pour les sealed, tous les enum sont sealed. J'ai découvert pour l'occasion que tu pouvais mock un enum avant (et qu'on avait un test qui s'en servait), c'est une (très) mauvaise idée amha, mais tu ne peux plus à partir de java17.

On a jamais pu étendre un enum. Si un outil de test se servait d'une bidouille pour forcer quelque chose de normalement impossible (ici : créer une classe de mock qui étends l'enum) et que ça finit par péter, c'est pas de chance, mais pour moi c'est pas un problème de rétrocompatibilité : le comportement n'avait jamais été prévu ni officialisé.

Parce que non seulement ils cassent la compatibilité, mais en plus ils déprécient des parties (le plus connu c'est quand ils ont souhaité déprécier sun.misc.Unsafe).

Pour moi déprécier sun.** n'est pas « casser la rétrocompatibilité », puisque Sun puis Oracle ont toujours dit que ces packages étaient à usage interne, ne faisaient pas partie de l'API et ne devaient pas être utilisés. D'ailleurs des programmes qui utilisaient ces classes ne fonctionnaient pas sur des JVM non-Sun/Oracle, à commencer par la JVM d'IBM.

Sun comme Oracle ont très largement profité du fait que les gens avaient ces possibilités. Le succès de la plateforme n'aurait pas du tout était la même sans ça. Je trouve que prendre tous ces gens qui ont largement contribué à la plateforme de haut en leur disant que leurs usages "bof OSEF lol" est un manque de respect total.

Oui la plateforme a besoin pour évoluer de trancher certains usages, mais ça n'empêche pas de prendre en compte l'état réel de la plateforme et pas ce que ce serait dans un état imaginaire qui ne prendrait en compte que ce qui est spécifié/contractualisé.

Très basiquement retire toutes les bases de données de java (cassandra, elasticsearch, neo4j,…) ça va nettement impacter la plateforme. Même les membres d'OpenJDK l'ont entendu.

Le fait que Java n'hésite pas à faire des doublons d'API, mais surtout des montages compliqués, des tonnes de sucre syntaxique qui masquent des pièges et finissent par aboutir à des demi-solutions bancales et peu pratiques.

swing/awt était une fierté fut un temps (pas si lointain).

Par exemple et sans réfléchir : tout le système de boxing/unboxing, le type erasure dans les generics, la (non) gestion des checked exceptions dans les lambda – qui en plus n'a pas de solution élégante dans l'API standard.

Les exceptions checkeds sont gérées d'une manière cohérente dans les lambdas et heureusement. Il y a déjà largement suffisamment de cas particulier lié aux lambdas pour ne pas ajouter ça. Une partie du reste est entrain d'être traités par différents sous projets d'OpenJDK.

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

[…] mais à quel point c'est imputable à une non rétrocompatibilité de l'ABI ou de l'API de Java ?

Virer une partie de la bibliothèque standard c'est clairement une rupture de rétrocompatibilité de l'API.

Pour ImageJ, ils utilisent assez massivement le moteur JS intégré à Java… qui a changé et finalement été supprimé. Là effectivement, c'est dommage, ils ont parié sur une solution non pérenne pour leur outil.

Le retrait de nashorn est une bonne nouvelle. Il était pas très à jour sur l'implémentation emscscript et on a aujourd'hui des solutions bien plus performantes comme graalvm polyglot

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

Les ruptures de compatibilités n'ont rien d'incroyables non plus. Pour le coup java souffre plus d'une image que de faits. Même si tes projets l'affirme. Annoncer la bouche en fleur rester compatible uniquement avec java8 8 ans après c'est comme un projet qui te dit qu'il n'est compatible qu'avec python2.7 sauf qu'avec java tu n'a pas d'opérateur qui claque silencieusement, tu n'a pas tes chaines de caractères/tableaux d'octets qui changent de comportement silencieusement.

Pour être du sujet, je considère ça comme de la pure dette technique qu'y est procrastinées à outrance. Le monde n'est pas binaire entre soit c'est parfaitement compatible soit c'est infernal et les ruptures ne sont pas très douloureuses. Et oui mettre à jour sa version de java fait parti du langage comme quand tu choisi python ou lua et les choses ne vont pas s'améliorer avec le temps. release early, release often s/release/update/g

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

Même question que ci-dessus : est-ce que tu as des exemples ?

Pour les modules et les sealed, je vois bien les problèmes de compatibilité mais je n'ai pas entendu parler de problèmes de _rétro_compatiblité au sens ci-dessus.

Ah non je n'ai pas dis que c'était en particulier des problèmes d'ABI.

Pour les modules, à partir de java11, tu dois déclarer tes modules à ouvrir à ouvrir tout puis à partir de java17 tu ne peux plus tout ouvrir il faut lister tous les modules au quel tu souhaite accéder. Pour moi si tu faisais :

java -jar appli.jar

avec java8 et qu'en mettant à jour java la commande tel quelle ne fonctionne plus c'est un problème de rétrocompatibilité. Que tu ajoute cette liste de modules dans le module info dans le jar ou via la ligne de commande ne change rien.

Pour les sealed, tous les enum sont sealed. J'ai découvert pour l'occasion que tu pouvais mock un enum avant (et qu'on avait un test qui s'en servait), c'est une (très) mauvaise idée amha, mais tu ne peux plus à partir de java17. Moi j'en ai aucun usage, mais je serais pas vraiment surpris qu'un outil s'en serve pour une raison ou une autre (même un spoke par exemple).

Je retrouve plus la référence mais en ajoutant une méthode sur une interface des collections ils ont cassé la compatibilité d'eclipse-collections. Je présume que ça n'est pas le seul cas où c'est arrivé (pour eclipse ou autre).

Enfin et surtout, « sainte » ≠ « absolue » hein.

Mais du coup tu entends quoi par « sainte » ? Parce que non seulement ils cassent la compatibilité, mais en plus ils déprécient des parties (le plus connu c'est quand ils ont souhaité déprécier sun.misc.Unsafe). Probablement pas autant que tu le souhaiterais, mais du coup je ne vois pas ce que tu entends par « sainte compatibilité ».

Aujourd'hui, mi-2022, tu peux écrire du code complet à base de Vector, HashMap, Date et autres objets qui ont des remplacements bien plus pratiques sans que le langage ne te sorte le moindre avertissement.

Quel est le remplacement de HashMap ? Je viens de vérifier je ne vois pas dans le standard ce qui ces dernières versions auraient donné de quoi le déprécier.

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

Présenté comme ça je dirais que tout langage qui permet l'introspection a ce problème. Si je compte le nombre de méthodes d'un objet python, j'ai strictement le même problème.

Mais ça me gratte un peu parce que c'est pour moi un bug de l'utilisateur pas du langage ou de la bibliothèque.

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

Elle n'est pas si sainte que ça. Tu as eu plusieurs changements de compatibilité ces dernières années.

• les modules ont eu des effets
• le passage de java ee à jakarta
• les sealeds ont eu des effets de bords
• le retrait de nashorn
• d'autres trucs dont j'ai plus le souvenir exact

Rien de très méchant et tu as des discussions pour être encore plus disruptif.

Java n'est pas si rigoriste que ça

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

De ce que j’en voit, sortis de languages récents et relativement peu répandu, une abi stable est un peu la base de la base.

Go s'en affranchi et la plus part des langages de scripts je présume, je ne sais pas ce qu'il en est des langages à machines virtuelle comme java. Je sais que le format de la représentation binaire est versionné, mais je ne suis pas assez familiarisé avec ce qu'est l'abi pour savoir. Si je peux changer ma représentation interne d'une classe, ne pas recompiler ceux qui utilisent cette classe et tout de même linker avec c'est qu'il n'y a pas de problème d'abi ?

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

[Tu parle donc d'une replay attaque ce qui n'a rien avoir avec le vol de ton téléphone et toutes les 2FA ne sont pas protégées contre ça effectivement parmi les 3 facteurs possibles seul celui qui prouve que tu possède quelque chose (avec TOTP par exemple) interdit le rejeu.]'https://linuxfr.org/news/pypi-deploie-le-systeme-2fa-pour-les-projets-critiques-ecrits-en-python#comment-1896446)

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