barmic 🦦 a écrit 6259 commentaires

Tu fais bien d'indiquer la langue parce qu'avec un nom comme ça on pourrait se tromper

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

il produit des diffs bruités

Ce n'est pas ce que j'ai observé (du peu que je m'en suis servi) et c'est l'un des principaux objectifs du projets. Tu aurais un exemple en tête ?

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

Eclipse pas Oracle.

Tout à fait Jarkata EE c'est eclipse.

Si Graal est techniquement extrêmement intéressant, Oracle semble aussi profiter du mouvement pour casser le statuquo du tout libre & gratuit.

En créant un projet libre & gratuit ? Aujourd'hui graal est microscopique et ne pourra jamais se faire une place sans quarkus de Red Hat. Je ne suis pas sûr qu'il supporte un jour l'ensemble de java et a 1 ans et demi de retard sur son support de java. C'est vraiment s'embêter beaucoup pour pas grand chose. D'autant qu'ils continuent de libérer leurs outils maisons inclus dans leur distribution de java.

Pour moi le risque est là.

Hotspot est effectivement en fin de course, mais OpenJ9 est là et a l'avantage d'être accessible en remplacement directe. Graal n'est intéressant pour le CPU bound et est moins bon que hotspot en mémoire. Il est très peu probable que Java passe à graal.

Ce ne serait même pas intéressant pour Oracle qui ne pourrait plus vendre ses licences OSB, weblogic, etc et ça c'est du cash qu'ils font aujourd'hui pas de l'hypothétique dans 5 ans.

[...] soit que Graal ne prenne pas et que la plateforme ait perdue beaucoup d'efforts.

Dans le monde des techno (voir scientifique) un travail n'est jamais perdu. Le truc qui arrivera après pourra s'appuyer de l'expérience en question (si c'est un échec). PHP6 n'a pas tué PHP par exemple alors qu'il a consommé en proportion beaucoup plus d'énergie.

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

Tout le monde se fout du besoin réel, [...]

J'adore cette hypothèse. C'est un joli exemple de doublepensée 🙂

Sérieusement CSS 3 apporte beaucoup de de choses très utiles par exemple pour le positionnement ou les web components.

Tu parles de problème de support de standard. Vous en voyez encore ? C'est vraiment minime pour ce que je vois sur les navigateurs qui représentent plus de 90% du marché. On peut voir des problèmes sur les fonctionnalités récentes et pointues comme récemment pour Firefox avec jitsi, mais c'est plus un temps de prise en compte qu'un mauvais support comme on a pu le connaître à une époque.

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

Par ailleurs Oracle ayant un passif sur la segmentation/fermeture de trucs ouvert (coucou MySql), java est désormais un langage appartenant au passé.

Ils ont passé la main au projet OpenJDK ce qui met le JDK Oracle sur un pied d'égalité (organisationnel en tout cas) avec tout ceux qui veulent fournir un JDK que ce soit ta distribution, adopt openjdk, amzon ou autre.

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.

Oracle reste un très gros acteur de Java (il fourni de l'infra, de la main d'œuvre, ils ont sorti des projets comme graal,...), mais il le fait au même titre que RedHat, Google ou IBM pour parler de très grosses boites.

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.

Bien sûr on peut parler du procès Oracle/Google, c'est pas le premier et ce ne sera pas le dernier procès du genre, on a eu AT&T, on à celui-ci, on en aura d'autres.

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

j'ai largement modifié le xmx; par contre je suis intéressé pour savoir si y'a d'autre paramètres existants;

Les gc java ont des quantités folles d'options ! Le problème va plus être dans le temps que tu veux y accorder. Il faut regarder quel GC est utiliser et chercher ses options (voir activer les logs du gc). À minima jouer sur les tailles des générations peut pas mal jouer.

car y a des fois il le blo (en même temps l'antivirus à tendance à me geler les IHM de manière complètement aléatoire, et de me faire un segfault avec dump de ram (c'est ça qui gèle tout j'imagine));

Pourquoi ne pas désactiver les coredump ? Je crois qu'il est possible de les désactiver de manière général et ne les activier que ponctuellement.

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

Je doute que des utilisateurs qui gardent des semaines des logiciels ouverts en préférant se plaindre plutôt que se demander si le logiciel qu'ils utilisent est fait pour être utilisé comme ça et est-ce qu'il y a des configuration à appliquer pour cet usage, ils seront malheureux quelque soit le logiciel que tu leur met entre les mains.

En théorie, pour que ce soit rapide je suis d'accord qu'il faudrait tout écrire en C++ ou mieux en Rust mais ce n'est pas le même taf...

On parle de consommation mémoire (comme ça avait l'air d'être question plus haut) ou de vitesse ? Faut se demander ce qu'il fait et voir comment le configurer peut être (les historiques, le filewatch, les indexes,...), il y a même de quoi surveiller ce qui consomme au sein de vscode.

Pour être économe en mémoire avec des langages comme C++ ou rust¹ , il va falloir éviter de fragmenter la mémoire et je ne crois pas que soit inclus dans ces langages et cette gestion va aussi avoir un overhead mémoire (probablement inférieur à celle d'un gc je suis d'accord).

Si on ne connaît pas la cause du problème, comment proposer une solution ?

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

C'est probablement pas à europython qu'il aurait fallu en parler. Il n'existe pas de gestionnaire de paquets pour les 2 langages qui s'interfacent avec le reste du mondeC et C++. C'est probablement par là qu'il faudrait commencer. La communauté python n'a probablement pas envie de se convertir à la maintenance de paquets systèmes.

Ça tombe bien, des gens qui font de l'empaquetage de ce type de bibliothèque, il y en a pleins. Le seul problème c'est qu'ils sont tellement qu'ils n'arrivent pas à se mettre d'accord sur un format de paquet... pkgsrc, nix et guix comme ils sont utilisables par un simple utilisateur peuvent probablement faire le travail.

Mais la plupart des utilisateurs d'un langage s'en foutent. Ils regroupent ça dans les prérequis systèmes qui inclus aussi la présent de telle base de données par exemple et vont gérer ça avec soit les de l'infra automation (ansible, salt, puppet,...) ou des images systèmes prêtes et réutilisables (vagrant ou docker).

Du coup le problème est adressé autrement.

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

Quasiment tous les projets java utilisent ce principe.

Et python et les projets qui utilisent doxygen et julia et ocaml et golang...

Cela dit, avec asciidoctor par exemple, on devrait pouvoir externaliser cette documentation.

Ça ne fais pas la même chose. Tu ne peux associer cette documentation à ton code. Donc aucun éditeur ne pourra t'aider. C'est pas inutile pour autant, mais ce n'est pas la même chose.

Ça fait sens si on veut la traduire et même documenter à partir des tests, des exemples de code tiré du git, présent dans d'autres fichiers.

Tout à fait beaucoup font vraiment leur tambouille pour ça que ce soit avec de la doc inline ou des trucs comme asciidoctor. Il y a même un langage dont la doc inline peut contenir une portion de code qui sera exécutable, mais j'ai pas pu retrouver où j'avais vu ça.

Je veux bien documenter une classe, au dessus du code de celle-ci, car ça ne gêne pas la lecture du code.

La plupart des éditeurs permettent de la cacher et les linters te fournissent un minimum de vérification de la correspondance.

Par contre documenter toutes les méthodes est une perte de temps, surtout lorsque ça paraît triviale.

Je n'ai pas dû être claire. Il s'agit de documenter l'API. La complexité du code sous-jacent n'a rien à voir. Si ça peut être plus clair, imagine le cas d'une bibliothèque C ou C++ qui décrit ça avec doxygen dans ses entêtes. L'écriture de cette documentation peut être antérieure à l'écriture du code qui l'implémente. Par exemple tu peut aller jusqu'à indiquer la complexité de l'implémentation et c'est alors judicieux de documenter aussi ce qui te paraît trivial. C'est un contrat de l'API.

Ah et ça ça concerne l'API et non tout le code (à moins que tout ton code soit une API). Généralement une faible portion du code d'une bibliothèque fait partie de l'API, sinon ça devient complexe à maintenir. On peut voir un exemple avec rxjava pour une classe qui fait partie de l'API et une qui n'en fait pas parti.

La doc inline qui explique un passage complexe est bien sûr primordial.

Encore une fois ça n'a rien à voir. Documenter une API et commenter un code sont 2 choses qui n'ont rien à voir et sont régulièrement faites par des personnes différentes (c'est celui qui implémente qui documente son code alors que rien ne l'oblige pour la documentation d'une API).

Je trouve important de la doc non associée à l'API qui décrit plus les concepts et qui ne soit pas organisée par rapport au code, mais l'un empêche pas l'autre et ils ont des objectifs bien différents.

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

Là il s'agit de créer une fondation ce qui n'est pas la même chose.

Clairement l'objectif est de se sortir de l'organisation de Mozilla, mais je pense que rust a passé le cap du langage de niche et peut effectivement voler de ses propres ailes, même si Mozilla laisse tomber.

Par contre j'aime beaucoup le premier draft : https://smallcultfollowing.com/babysteps/blog/2020/01/09/towards-a-rust-foundation/

Perso je suis pas fan de l'idée de créer des fondations à tour de bras. Peut être que les US n'ont pas d'équivalent de nos associations de loi de 1901. Mais quitte à je trouve bien plus sain de s'intégrer dans des fondations comme Apache, Eclipse ou Linux qui ont des moyens bien plus important pour fournir un cadre juridique, organisationnel, une visibilité et une série de garanties bien plus claires au près des contributeurs.

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

Ce n'est pas du commentaire de code, mais de la documentation d'API.

Un commentaire de code est là pour aider à celui qui lis le code. Il lui indique pourquoi les choses sont faites de cette façon (quand le code ne peux pas l'indiquer de lui même).

La documentation d'une API décris ce que fait l'API sans avoir besoin d'aller en lire le code. Pas mal d'éditeurs ter permettent d'y accéder sans aller voir le code. Très pratique quand tu veux entrer les paramètres d'une méthode en gardant la doc sous les yeux (ça évite les sauts qui, aussi rapides et efficaces qu'ils soient, obliger à repositionner ton regard.

Donc moi ça me choc pas.

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

Un serveur Web n’est donc plus nécessaire. De plus, vous pourrez bénéficier des mises à jour automatiques via votre navigateur.

Il en faut bien un pour l'autre coté de la websocket, non ?

Quand tu parle d'instance tu fais référence à quoi ? Tu peux avoir une grappe de serveur et balancer une tâche sur la grappe sans te soucier de qui la lance ?

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

Tu dira ça à Tux qui s'est honteusement fait voler la vedette par Tuz ! :)

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

Dans ce cas-là, je ne vois pas de lien de soutien entre l'utilisation du logiciel et le soutien aux idées de l'auteur.

Pourquoi est-ce qu'on entends parler de lui à chaque fois qu'il poste un tweet colérique ? C'est la popularité de son logiciel qui lui donne cette tribune. Donc oui en utilisant son logiciel tu contribue à sa tribune. Même si tu n'est pas au courant de ses positions d'ailleurs.

On peut dire la même chose de Linus Torvalds dont on reprend tous ses coups de gueules. On parle moins de ceux de Theo De Raadt par exemple.

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

Moi je pense que c'est tout l'inverse. On l'a vu avec le débat du retrait de la blague sur l'avortement de la fonction C abort sur la mailing list de glibc. On créé de la polémique, du débat et des flamewars inutiles.

Je vois tout de même une grande différence entre tenter de pousser ses idées via son logiciel (si vous votez FN, désinstallez mon logiciel) et ce qui relève de la politique interne d'un logiciel. À partir du moment où tu collabore au sein d'un projet tu as de la politique par construction et affirmer que c'est inutile est une position politique. On ne peux pas vouloir travailler ensemble et chercher à occulter tout ce qui concerne le vivre ensemble.

Je comprends que comme ce n'est pas directement du code/test/documentation ça paraît de la perte de temps, mais c'est comme les tests, on perds plus de temps en essayant de faire diversion qu'en faisant un choix et en avançant. Même si évidement un choix peut avoir des conséquences et doit être assumé. Mais c'est aussi le cas avec des choix techniques comme quand Debian a choisi systemd et que Devuan a était créé pour l'occasion.

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

Ah bien vu. Je ne l'avais pas vu comme ça.

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

Tu décris un objectif de non-neutralité. Pour rappel :

le droit des utilisateurs « d’accéder aux informations et aux contenus et de les diffuser, d’utiliser et de fournir des applications et des services et d’utiliser les équipements terminaux de leur choix, quel que soit le lieu où se trouve l’utilisateur final ou le fournisseur, et quels que soient le lieu, l’origine ou la destination de l’information, du contenu, de l’application ou du service, par l’intermédiaire de leur service d’accès à l’internet ».

C'est moi qui graisse. Tiré de l'arcep.

Je suis d'accord qu'on peut trouver des raisons de le mettre en place.

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

Et c'est pas du profilage ?

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

au revenu moyen des habitants du code postal associé. Parfait pour les publicités ciblées.

En même temps ça sert à quoi ce genre de trucs à part :

• profilage des utilisateurs
• créer des services non-neutres

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

C'est une bibliothèque écrite en C sous licence GPLv2

J'étais surpris et en vérifiant c'est du LGPLv2.1.

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

Je pense que c'est le plus pertinent oui[...]

Il faut pouvoir désactiver les envoies de mails par les utilisateurs. Ces solutions sont généralement faites pour servir de "forum mail" (type LKML par exemple).

Si tu envoies trop de mails avec un compte "normal" ça risque bien d'arriver.

De ce que je vois du blog de ploum ou parle ~20 mails/an, je ne sais pas combien de destinataire il espère.

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

J'oubliais, une particularité, le hook est ici sur le dépot bare[...]

Oui oui, mon exemple c'est surtout parce que si tu utilise un server git hébergé tu n'a pas le loisir d'ajouter un hook sur le serveur, il faut passer par des CI. Ce n'est pas impossible, mais c'est différent.

Je rejoins les avis du dessous pour garder les choses séparées et donc d'avoir une mailing-list à part.

La plupart des solutions de mailing présentées sont faites pour gérer des mailinglist complète qui servent à échanger (des forum en mail). Ce qui me semble gros pour un usage simple.

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

Tu veux publier via un git push, donc envoie tes mails via un git push :)

• solution tu pauvre : crée toi un hook dans ton dossier de travail
• solution plus pérenne : voit comment ton serveur git peut réagir (ça peut être facilité par une force qui tu en utilise)

Il y a juste à gérer l'inscription. Selon le trafic tu peux gérer ça manuellement sinon ça dépend de ce que tu as comme serveur (si tu es root ou si c'est un lamp par exempl).

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

Une partie non négligeables des sites n'envoient pas de contenu avec le html, c'est le js qui va chercher le contenu recherché dans des webservices. Au final un proxy voit passer des "trucs", mais la notion de page il ne la vois pas. Bien sûr ça reste du contenu indexable, mais dans ta recherche, tu va tomber sur du json (voir sur du js...) pas forcément très digeste, tu n'aura pas forcément le contexte qui va avec.

C'est une problématique avec la quelle on doit vivre pour les moteurs de recherche classiques (voir cette page d'explication de google).

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

ça fonctionne pour autre chose que les pages générées côté serveur?

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