barmic 🦦 a écrit 5976 commentaires

Cette histoire de java pourrit la vie des gens sous mac OS pour diverses raisons et, dans une moindre mesure, celle des gens sous Windows (ce qui est compliqué sous Windows et pour le vulgum pecus, c'est de savoir quelle version de java télécharger et installer, ça m'a toujours plongé dans des abîmes de perplexité).

Pourquoi pas la dernière ? Si c'est la distinction jdk/jre, c'était jre, mais c'est une question qui n'existe plus. L'installeur windows ne gère pas tout ça ? Parce que sur Windows c'est à l'installeur de gérer les dépendances (vérifier ce qui est dispo, installer les dépendances ou indiquer clairement ce dont on a besoin).

Ce qui fait que python est moins embêtant c'est qu'il est embarqué. Ça pose moins de question (c'est aussi faisable pour java), mais c'est bien moins propre.

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

De notre côté, on a décidé d'éviter les comparaisons

Ce qui est bien dommage car il y a pléthore de solutions :

• spring boot
• micronaute
• quarkus
• vertx (utilisable via quarkus fais avec quels changements ? Je sais que Julien Viet et Clément Escofier sonteenthousiastes pour quarkus donc j'imagine qu'il y a surtout des gains)
• ratpak
• lagom
• helidon
• ktor
• grail

Et j'en oublie voir ne connaît pas certains. Il faut bien faire un choix et dire qu'il n'y a qu'à tester c'est rigolo, mais en fait non. Ils seront tous très rapides si on joue leur getting started parce que 3 classes java c'est léger quoiqu'il arrive.

Après je connais quarkus via Emmanuel Bernard et Clément, j'ai des billes pour en comprendre la philosophie, le fonctionnement et donc savoir à quoi m'attendre. Mais pour moi l'argument "on a une boucle de feedback rapide", c'est presque comme dire qu'on peut coder un webservice dans un twitt. Ma prod s'en fout, si c'est pour ne pas tenir les perf dont j'ai besoin, être compliqué à monitorer ou ne pas être perdre tous les avantages dès que j'utilise quelque chose d'un peu exotique, ça m'embête un peu plus.

Sans entrer dans des guerres de bench inutiles, il y a des différences objectives entre tous ces projets et c'est bien d'en parler, sinon c'est que les dev se sont juste dit "et si on écrivait un énième framework comme c'est la mode ? On est meilleur que les autres donc on va faire mieux !".

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

Micronaut enrichi le bytecode pendant l'analyse des sources. Il n'utilise pas de plugin Gradle / Maven et ne connait pas les classes à recharger.

De ne comprends pas cette phrase. Lors de l'analyse des sources il n'y a pas de bytecode à modifier 🤔

Pour jrebel, c'est un outil non libre et payant (et je cris pas donné), ça limite pas mal son utilisation.

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

C'est marrantde faire un laïus sur java pour juste dire : mise à jour de la version minimale de java requise.

Et d'être aussi peu locace sur python qui est intégré. Là où java est une dépendance (je crois optionnelle), LibO est compilé avec une version de cpython (qui j'ai bien compris le commit).

Et autant plus choisissent d'être souple pour java (java 8 est la plus vieille version encore supportée) pour python les sont bien plus strict puisque les branches 3.5 et 3.6 sont toujours d'actualité.

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

Je viens d'installer mon imprimante (je suis sous Mageia) et d'imprimer sans problème et je suis une Mme Michu. Donc je ne comprends pas le problème.

Modératrice sur linuxfr, auteure d'un journal et co-auteure d'une dépêche sur le sujet…. Je vais me permettre de te citer :

C'est un troll ?

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

Ils ne sont pas très bons pour les misesà jour du jdk et je crois qu'ils gardent jshell et javac. J'ai fini par préfèrer créer la mienne. C'est pas plus compliqué et je suis les mises à jour de sécurité d'adoptopenjdk et de la glibc.

Mais avec le passage à buster les mises à jour de sécurité doivent mieux se passer.

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

Ne t'inquiète pas pour mon temps, je peux faire d'autres trucs pendant que mon ordi exécute des tâches.

Tant mieux :)

J'ai surtout l'impression que ça ne vient pas tant du runtime OpenJDK que de ce qu'on en fait. Pour l'avoir utilisé sans framework, avec des petits programmes, ce n'était pas particulièrement lourd, et ça ne fuite pas gratuitement sans raison (par contre, le temps de démarrage peut être long pour des exécutions courtes).

Entièrement d'accord. Le temps de démarrage est long, mais le runtime lui-même est plus tôt rapide à l'exécution. En terme de mémoire il y a un overhead lié au modèle mémoire de java. Mais c'est rarement ce qui est incriminé. Tu peux avoir aussi certaine lenteur dans des cas pathologiques de création d'un grands nombres d'objets d'un coup. Le dernier point qui peut être gênant c'est le GC qui peut faire de stop the world, mais à moins d'utiliser des tailles de heap vraiment grande je n'ai personnellement jamais rencontré de cas où ça posait un problème.

À coté de ça l'écosystème n'a pas que des bonnes pratiques avec l'utilisation de proxy dynamique et de réflexion probablement trop importante. Ce qui n'aide pas toujours. Mais c'est un point qui est entrain d'évoluer j'ai l'impression quand on voit arriver des micronaute, vertx ou quarkus.

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

Après trois quarts d'heure de récupération des sources de LineageOS 17.1 (Android 10) et une heure trois quart de comptage de lignes de code (cloc), voici les résultats

Je suis sincèrement désolé que tu ai perdu autant de temps sur quelque chose d'aussi inutile que futile…

Java c'est 3 choses différentes :

• un langage de programmation : la syntaxe, la grammaire et sa sémantique (entre autre)
• une plateforme : c'est le runtime généralement OpenJDK
• un écosystème : en très gros maven central et quelques outillages

Quand je lis :

Onedev : une alternative légère à GitLab

Au vu des copies d'écran et sachant que c'est du Java, j'ai quand même du mal à voir comment on peut parler de légèreté :p

Pour moi il est question du second, il veut dire qu'à l'exécution java c'est lourd. C'est aussi ce qui ressort des autres commentaires qui suivent.

Android n'utilise pas le runtime de java. Il se sert de certains outils qui font parti d'OpenJDK (comme javac, le compilateur C1 de java), mais à l'exécution le runtime java n'est pas impliqué, il n'y a même plus du bytecode java.

Android lui utilise qu'une vielle version du langage de programmation (java 7 a 9 ans, il y a eu 7 versions depuis) et une partie de l'écosystème.

La comparaison avec C et C++ n'est évidement pas parfaite, mais c'est 2 langages vivent avec une compatibilité partielle et une partie de l'écosystème commun. Maintenant les sémantiques de chacun sont un peu différente, mais ça commence à être le cas aussi entre Java7 d'Android et Java14 qui sort la semaine prochaine. Par exemple avec le switch ou l'ajout de mot clef.

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

C'est presque plus proche d'un fork de l'API. Android supporte l'API de java 7 et une partie de java 8. La comparaison n'est bien sûr pas identique, mais clairement ce sont 2 choses vraiment différentes. Les langages évoluent différemment, le runtime est très différent, l'écosystème est assez différent. Il y a un objectif de garder une certains compatibilité, mais quand on voit les release de guava par exemple on vois bien qu'il y a des différences.

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

Quel est le rapport entre java et android ? Le langage se ressemble ? Il utilise le bytecode java dans l'une de ses étapes de build ?

Android est un écosystème à part entière. Il a peut-être des ponts avec java, mais c'est comme confondre c et c++.

Quant au reste du troll, je te le laisse. On est pas vendredi. Tu lâche un c'est lourd sans la moindre comparaison, expliquer ce que c'est que lourd, chercher comparer les langages eux même. Les bench entre le très aimé python et java pourrais être intéressants pour alimenter la discussion. Mais ça n'est pas l'objectif. Continuer à balancer des poncifs en mode cargo cult (java c'est mal, javascript c'est mal, python c'est bien), c'est devenu une habitude par ici. Ça a remplacé les discussions techniques. Dommage.

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

Là c'est pas une question de java ou de ruby, mais de jruby qui est une mauvaise idée. Elastic a réécri logstash de jruby à java pour ça.

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

Le prix varie 1795$ et 5775$. J'ai l'impression que ce n'est disponible qu'en Amérique du nord.

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

Disons que c'est une popularité artificielle, qui peut avoir tout de même un bénéfice : avec des stats gonflées ainsi artificiellement, cela propulse le paquet dans les hauteurs des classements des "projets les plus utilisés", donc ça incite plus facilement à ceux qui doivent choisir, d'utiliser le projet en question. Ce qui fait encore plus gonfler les stats etc..

C'est le cas de toutes dépendances en fait. En principe ça ne biaise pas les comparaisons. À moins que luaunit soit particulièrement utilisé par ceux qui configurent mal leur CI.

Et il reste l'étoile sur github qui n'est probablement pas ajoutée automatiquement ;)

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

Par défaut tu fais confiance à l'identité du serveur, mais tu peux la valider avec ton contact si tu le souhaite. Soit via un code de 60 chiffres soit un qr code.

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

Espèce de spoiler ! :)

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

Et plus il y a d'utilisateurs plus c'est pentesté.

Par des chapeaux blancs ou des noirs?

Les 2 mon général. Mais c'était surtout pour mettre en avant que c'est pas trivial de dire comme ça sur des critères purement extérieur/quantitatif ce qui est le plus sécurisé ou non. Par contre :

Dans le cas des blancs, les correctifs arrivent-ils réellement rapidement? Sur quelles distro?

Là il y a un glissement. Ce n'est pas une question de sudo ou de la taille de son code. Si ta distribution ne met pas à jour ta bibliothèque TLS ou ton client SSH quand une mise à jour de sécurité apparaît c'est pas la faute des développeurs upstream.

D'ailleurs, si quelqu'un pouvait m'expliquer pourquoi il fait une requête DNS sur le hostname (que contourne Debian en ajoutant 127.0.1.1 dans /etc/hosts) ça m'intéresse, parce que perso, j'ai bien du mal a voir l'intérêt de cette… fonctionnalité.

Tu présente le truc de manière assez biaisée, tu ne trouve pas ? Je suis sur que tu es capable d'aller voir la doc (celle upstream que tu peux retrouver via l'outil man de ton unix-like préféré si tu as installé sudo) de sudo qui explique à quoi ça sert¹ et qui décrit la manip' utilisée par debian → ce n'est pas un contournement de la part de debian c'est une configuration prévue par les développeurs upstream.

Au lieu de commencer par s'offusquer ça pourrait être marrant de se renseigner, c'est comme ça qu'on évite les FUD et autres fausses informations ;)

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

Plus il y a de code, plus il y a de bugs. Mais pour généraliser, plus il y a de code, plus les audits sont compliqués.

Et plus il y a d'utilisateurs plus c'est pentesté.

Mais la diversité améliore la sécurité en soit même si les alternatives à sudo faisaient 1M de lignes ça serait intéressant d'un point de vu sécurité pour qu'une faille n'impacte pas tout le monde.

Après sudo a énormément de fonctionnalités et fait un job cool (même si je trouve dommage de continuer à voir des overflow aujourd'hui…), mais c'est super d'avoir des façons différentes de faire (plus simple comme doas, juste de réimplémentations comme calife ou complètement autrement).

Les projets libres non commercial comme ça ne sont pas des ennemis à la recherche de la plus grande part de marché.

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

Quoi ?! Mais tu peux pas dire ça !

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

Alors, c'est pas ce qu'eux même disent (cf mon commentaire en dessous) et de 2 si c'est le cas il vaut mieux pour eux le retirer plutôt que laisser une fonctionnalité contenant des bugs connus qui leur sont du coup remontés, les utilisateurs non averti que cette fonctionnalité serait dépréciée l'essai et peuvent avoir un très mauvais ressenti de leur usage de l'outil.

Bref soit ça les intéresse pas et il faut qu'ils le déprécient avant suppression, soit ça les intéresse et il faudrait finir le travail.

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

L'idée, qui ne date pas de cette version[…]

Ils en parlent presque depuis la création de LibO j'ai l'impression, mais aucune idée de où est-ce que ça en est. Il en parlent pas dans la note de version. Tu as un lien pour connaître l'état actuel ?

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

Moins de java (exit les versions 6 et 7), un beau python (3.7.6), pas de boa ni de truc en plume par contre, et adieu GTK+ 2 VCL. L’intégration de KDE 5 se poursuit.

Alors Java était utilisé dans LibreOffice (LibO) et avant dans OpenOffice.org (OOo) pour certaines extensions et pour le module Base. Ici il est question de ne plus supporter les versions 6 (2005 → 2013) et 7 (2011 → 2015) de java. Je ne sais pas ce qu'il en est de l'utilisation de java dans le projet. Par contre je ne vois pas d'informations sur une diminution de l'utilisation de java dans la note ?

Python est utilisable pour scripter LibO, de ce que je comprends ils embarquent CPython et l'ont mis à jour vers 3.7.6 (version précédente 3.5.9).

« pas de boa ni de truc en plume par contre » j'ai pas la référence par contre.

VCL était un framework graphique construit pour OOo au dessus de GTK. Il possède différentes implémentations. Ils ont supprimé l'implémentation GTK2 et amélioré la version Qt5 (qui dépend peut être aussi de KDE framework).

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

C'est dommage de parler d'un moteur de jeu sans montrer aucune capture d'écran :)

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

Ça n'a aucun rapport. Mozilla a commencé à travailler sur maildir, mais faute d'investissement il reste de nombreux bugs sur ce sujet. Ça n'a rien à voir avec un autre MUA qui ne s'intéresserait pas au format maildir.

C'est même pas une question de point de vu. Il y a 6 ans Mozilla annonçait le renouveau de Thunderbird (et je m'en faisais l'écho ici même). Certaines choses ont évoluées, mais clairement pas toutes. Donc même Mozilla trouve qu'il y a des choses à faire sur thunderbird. Plus récemment les contributeurs eux-même expliquaient ce qu'ils voulaient faire sur thunderbird.

Que Thunderbird te convienne tel qu'il est, on en est tous très content pour toi. Mais il reste encore un paquet de choses à faire et la dette technique s'accumule avec le maintiens de XUL par exemple.

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

Il y a 2 raisons pour faire ça soit tu es bien installé et tu souhaite grandir, soit ton modèle économique ne fonctionne pas et tu cours vers là où tu espère trouver de l'argent… La première raison marche infiniment mieux, les gens de chez docker ou Mozilla pourront probablement en parler.

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

Peut être parce qu'un simple lien ne suffit pas à déclencher une discussion ? Pour qu'il y ai discussion il peut être pas mal de présenter quelque chose, de donner son point de vue,… Bref d'avoir quelque chose à dire.

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