Je te propose de regarder les précédentes dépêches au sujet de weboob qui ont amené différents point de vu à ce sujet.
Pour faire simple, le projet à commencé comme une blague (outre le nom les premières icônes étaient assez graveleuses) et le fait d'avoir ce genre de polémique a braquée la communauté weboob qui ne veut pas plier face au puritanisme/bien séance/féminisme/SJW (choisissez votre dénomination).
Aujourd'hui je pense que le nom fait parti de l'identité du projet.
Voilà pourquoi j'ai mis un "probablement" dans ma phrase, je me doutais qu'il existe des exceptions, chanceux va !
Je pense que tu a raté ma remarque. J'ai râlé sur les même personnes, mais je considère que le problème n'est pas tant leur code que le fait qu'ils n'ont pas écrit de test.
Après, il existe bien entendu des cas spéciaux où l'optimisation pure est LA priorité, mais c'est marginal.
Non, c'est une question de domaine. L'optimisation CPU de code n'est pas majoritaire, mais on peut difficilement dire que c'est marginal, mais la gestion de la performance (ce qui peut être très différent) n'est pas marginale du tout.
On a probablement tous haï des gars qui ont fait des codes trop tarabiscotés dans le but de gagner un pouillème.
Jamais. J'ai haï les gens qui n'ont pas couverts leur code par des tests. J'ai aucun problème pour que quelqu'un ai pensé faire quelque chose d'un peu complexe, mais :
il faut que ce soit limité : tu cache ça dans une unité de code limité ça ne doit pas fuir dans le reste du code
il faut avoir tester ce code : je vois pas comment on peut optimiser du code sans avoir de tests unitaire pour s'assurer que l'optimisation ne pète pas le fonctionnel
Si tu as ça, il n'y a aucun problème à déployer des trésors de subtilité.
Après oui la lisibilité est importante1 et il faut voir si optimiser est intéressant. Mais là il s'agit d'un exercice d'optimisation donc on va considérer que c'est utile ;)
par exemple je vais préférer utiliser 0xff_ff_ff_ff ou ~0 plutôt que -1 comme valeur d'entier quand il est utiliser comme bit patterns. ↩
C'est ce que tu fais. debootstrap (ou cdebootstrap) ne sait pas que tu as monté /mnt d'une façon ou d'une autre son boulot c'est uniquement de construire l'arborescence minimale d'une debian. Tu peux t'en servir pour faire simplement des chroot sans docker ni lxc par exemple.
Ok après avoir relu plusieurs fois tes 2 liens je viens de comprendre ce que tu entends. Essaie de ne pas considérer que les autres sont de mauvaises fois quand tu t'exprime avec ironie. C'est quelque chose qui se c'est une tournure qui marche bien à l'oral pas à l'écrit.
Bref.
Ce que tu cherche c'est à nettoyer les fils correctement. Ça peut être utile quand tu as une hiérarchie de processus d'une profondeur d'au moins 2, car dans ce cas là si un processus fils du premier meurt avant son fils. Le PID1 va le récupérer et doit le nettoyer. Dans les autres cas il faut juste nettoyer ses propres fils ne pas le faire est un bug (avec ou sans docker).
Du coup je comprends si comme dans les exemples donnés tu fais du nginx + cgi + grep depuis ton code PHP c'est utile. Ce genre d'architecture a tendance à disparaître je pense (au profit des solutions type php-fpm).
AMHA ce n'est pas un problème suffisamment présent, c'est juste un problème qui peut exister et qui n'est pas chère à assurer.
Ça m'intéresse ce genre de choses, j'ai pas mal de photos sur un serveur que je parcourt en ssh. Pouvoir avoir un minimum de visualisation sans avoir à télécharger est bien pratique. Pour le moment j'utilise un outil qui s'appelle img2txt, mais il laisse une grosse part à l'imagination on va dire :)
Faut que je test si blockish ou sixel peuvent marcher dans mon contexte.
Personnellement j'utilise un petit wrapper autour du binaire java pour certains paramètre que je veux gérer dynamiquement (en particulier donner un nom qui suit une nomenclature donnée à l'éventuel memory dump. Mais je n'ai jamais eu besoin de gérer des processus par exemple.
(probablement des Mo d'ailleurs, ça a dû être défini plus tard les Mio)
La notation Mio a juste était créé pour rendre compréhensible les puissances d'unité de stockage en base 2. Les notations étaient probablement en MB (mais en comptant en base 2) ou Mb (en base 10 le plus souvent). Ouais ils étaient tout de même de 20 Mio ou moins. Tout comme l'atmosphère terrestre n'a pas changée quand on est passé des bar aux Pa ;-)
C'est un chouia plus. Tu fais une première étape pour le contenu du système de fichier avec docker import, puis tu pars de cette dernière pour construire ton master initial dans le quel tu ajoute les meta données. À minima pour définir l'entrypoint.
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.
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 !".
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é.
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.
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.
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.
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.
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.
[^] # Re: PAF !!!!!!!!!
Posté par barmic 🦦 . En réponse à la dépêche Weboob a dix ans !. Évalué à 10.
Je te propose de regarder les précédentes dépêches au sujet de weboob qui ont amené différents point de vu à ce sujet.
Pour faire simple, le projet à commencé comme une blague (outre le nom les premières icônes étaient assez graveleuses) et le fait d'avoir ce genre de polémique a braquée la communauté weboob qui ne veut pas plier face au puritanisme/bien séance/féminisme/SJW (choisissez votre dénomination).
Aujourd'hui je pense que le nom fait parti de l'identité du projet.
Pour ce qui est de la sortie de Debian et de la création d'un dépôt séparé, ça me semble être une très bonne chose car de toute manière ils ont un problème de cycle de vie. Les modules weboob doivent suivre la mise à jour des sites et c'est un peu compliqué pour faire remonter ça dans Debian stable (il y a du travail chez Debian pour gérer ce genre de choses, mais je ne crois pas que ce soit encore assez souple). Et il est logique que des projets comme Debian cherchent à être consensuel (ils peuvent déjà avoir assez de polémiques internes pour ne pas s'en ajouter d'avantage).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: PAF !!!!!!!!!
Posté par barmic 🦦 . En réponse à la dépêche Weboob a dix ans !. Évalué à 10.
Les débats autour du nom ne sont pas arrivés "d'un coup", ils existent depuis le commencement du projet.
Pour ce qui est de Debian ça a toujours été très clivant au sein de la communauté. Ce qui est dommage car ils n'ont pas besoin de ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Lisibilité
Posté par barmic 🦦 . En réponse au journal Exercices de programmation et benchmarks. Évalué à 1. Dernière modification le 12 février 2020 à 11:50.
Je pense que tu a raté ma remarque. J'ai râlé sur les même personnes, mais je considère que le problème n'est pas tant leur code que le fait qu'ils n'ont pas écrit de test.
Non, c'est une question de domaine. L'optimisation CPU de code n'est pas majoritaire, mais on peut difficilement dire que c'est marginal, mais la gestion de la performance (ce qui peut être très différent) n'est pas marginale du tout.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Lisibilité
Posté par barmic 🦦 . En réponse au journal Exercices de programmation et benchmarks. Évalué à 5.
Jamais. J'ai haï les gens qui n'ont pas couverts leur code par des tests. J'ai aucun problème pour que quelqu'un ai pensé faire quelque chose d'un peu complexe, mais :
Si tu as ça, il n'y a aucun problème à déployer des trésors de subtilité.
Après oui la lisibilité est importante1 et il faut voir si optimiser est intéressant. Mais là il s'agit d'un exercice d'optimisation donc on va considérer que c'est utile ;)
par exemple je vais préférer utiliser
0xff_ff_ff_ffou~0plutôt que -1 comme valeur d'entier quand il est utiliser comme bit patterns. ↩https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: distroless
Posté par barmic 🦦 . En réponse au journal docker multi-stage build. Évalué à 2.
C'est ce que tu fais.
debootstrap(oucdebootstrap) ne sait pas que tu as monté/mntd'une façon ou d'une autre son boulot c'est uniquement de construire l'arborescence minimale d'une debian. Tu peux t'en servir pour faire simplement deschrootsans docker ni lxc par exemple.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: up
Posté par barmic 🦦 . En réponse au journal docker multi-stage build. Évalué à 0.
Ok après avoir relu plusieurs fois tes 2 liens je viens de comprendre ce que tu entends. Essaie de ne pas considérer que les autres sont de mauvaises fois quand tu t'exprime avec ironie. C'est quelque chose qui se c'est une tournure qui marche bien à l'oral pas à l'écrit.
Bref.
Ce que tu cherche c'est à nettoyer les fils correctement. Ça peut être utile quand tu as une hiérarchie de processus d'une profondeur d'au moins 2, car dans ce cas là si un processus fils du premier meurt avant son fils. Le PID1 va le récupérer et doit le nettoyer. Dans les autres cas il faut juste nettoyer ses propres fils ne pas le faire est un bug (avec ou sans docker).
Du coup je comprends si comme dans les exemples donnés tu fais du nginx + cgi + grep depuis ton code PHP c'est utile. Ce genre d'architecture a tendance à disparaître je pense (au profit des solutions type
php-fpm).AMHA ce n'est pas un problème suffisamment présent, c'est juste un problème qui peut exister et qui n'est pas chère à assurer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: up
Posté par barmic 🦦 . En réponse au journal docker multi-stage build. Évalué à 1.
signal(7)
Je comprends pas bien ce que tu veux dire ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Intéressant
Posté par barmic 🦦 . En réponse au journal Des images (et des vidéos) dans le terminal avec des caractères Unicode. Évalué à 5.
Ça m'intéresse ce genre de choses, j'ai pas mal de photos sur un serveur que je parcourt en ssh. Pouvoir avoir un minimum de visualisation sans avoir à télécharger est bien pratique. Pour le moment j'utilise un outil qui s'appelle img2txt, mais il laisse une grosse part à l'imagination on va dire :)
Faut que je test si blockish ou sixel peuvent marcher dans mon contexte.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: distroless
Posté par barmic 🦦 . En réponse au journal docker multi-stage build. Évalué à 3. Dernière modification le 10 février 2020 à 23:00.
Les 3 premières lignes sont inutiles.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: up
Posté par barmic 🦦 . En réponse au journal docker multi-stage build. Évalué à 1.
Personnellement j'utilise un petit wrapper autour du binaire java pour certains paramètre que je veux gérer dynamiquement (en particulier donner un nom qui suit une nomenclature donnée à l'éventuel memory dump. Mais je n'ai jamais eu besoin de gérer des processus par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une partition pour les gouverner tous
Posté par barmic 🦦 . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 1.
Tu as des infos là dessus, parce que je l'ai beaucoup entendu mais rarement vu et ça a tellement une tête de légende urbaine que j'ai un doute.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une partition pour les gouverner tous
Posté par barmic 🦦 . En réponse au journal installation d'une debian chiffrée via LUKS sur un VPS. Évalué à 2. Dernière modification le 09 février 2020 à 23:11.
La notation Mio a juste était créé pour rendre compréhensible les puissances d'unité de stockage en base 2. Les notations étaient probablement en MB (mais en comptant en base 2) ou Mb (en base 10 le plus souvent). Ouais ils étaient tout de même de 20 Mio ou moins. Tout comme l'atmosphère terrestre n'a pas changée quand on est passé des bar aux Pa ;-)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: distroless
Posté par barmic 🦦 . En réponse au journal docker multi-stage build. Évalué à 1.
C'est un chouia plus. Tu fais une première étape pour le contenu du système de fichier avec
docker import, puis tu pars de cette dernière pour construire ton master initial dans le quel tu ajoute les meta données. À minima pour définir l'entrypoint.Rien de sorcier et c'est assez rapide au final.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Programmation
Posté par barmic 🦦 . En réponse à la dépêche LibreOffice, 10 ans, version 6.4. Évalué à 6.
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
[^] # Re: Différences entre Micronaut et Quarkus
Posté par barmic 🦦 . En réponse au journal Sorties de Micronaut 1.3.0 et Micronaut Data 1.0. Évalué à 3.
Ce qui est bien dommage car il y a pléthore de solutions :
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
[^] # Re: Différences entre Micronaut et Quarkus
Posté par barmic 🦦 . En réponse au journal Sorties de Micronaut 1.3.0 et Micronaut Data 1.0. Évalué à 1.
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
# Programmation
Posté par barmic 🦦 . En réponse à la dépêche LibreOffice, 10 ans, version 6.4. Évalué à 3.
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
[^] # Re: tout ça c'est super mais...
Posté par barmic 🦦 . En réponse à la dépêche LibreOffice, 10 ans, version 6.4. Évalué à 10.
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 :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: distroless
Posté par barmic 🦦 . En réponse au journal docker multi-stage build. Évalué à 4.
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
[^] # Re: Hmm
Posté par barmic 🦦 . En réponse à la dépêche Onedev : une alternative légère à GitLab. Évalué à 3.
Tant mieux :)
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
[^] # Re: Hmm
Posté par barmic 🦦 . En réponse à la dépêche Onedev : une alternative légère à GitLab. Évalué à 3.
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 :
Quand je lis :
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
switchou l'ajout de mot clef.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Hmm
Posté par barmic 🦦 . En réponse à la dépêche Onedev : une alternative légère à GitLab. Évalué à 3.
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
[^] # Re: Hmm
Posté par barmic 🦦 . En réponse à la dépêche Onedev : une alternative légère à GitLab. Évalué à 4.
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
[^] # Re: Hmm
Posté par barmic 🦦 . En réponse à la dépêche Onedev : une alternative légère à GitLab. Évalué à 5.
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
# Prix
Posté par barmic 🦦 . En réponse à la dépêche Kubuntu Focus : un portable optimisé. Évalué à 8.
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