Elfir3 a écrit 1148 commentaires

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 2.

    Dans ce cas, je faisais référence au contenu du lien plus haut :D

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 3.

    Il y a sans doute plus de jeux écrit en Java qu'en Python :-)

    En même temps, vu le matraquage des évangélistes dès qu'on parle de java c'est pas étonnant que beaucoup n'aient pas osé chercher plus loin ;)

    Mais entre Python, C#, Java, Lua et Javascript, ça fait un paquet de jeux qui utilisent un ramasse miette sans souci.

    Oui, et c'est pas pour rien que le jeux qui ont besoin de beaucoup de données se passent de ces langages. Ou alors tu vois apparaître des bugs report avec GC dedans une fois que le jeu commence à avoir une taille conséquente de données à gérer.

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 2.

    C'est le lien que j'ai posté plus haut :-)

    Résumé, si tu dois allouer tout en ayant des perfs stables, mieux vaut virer les GC..

    Note, ceci dit, que python fait vachement mieux que java dans ce domaine.

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 3.

    Après je connais peu de gens qui s'assurent que leur soft ne soient pas préempté par le noyau.

    Pareil, mais ici on est pas du tout à ce niveau. Je reprends le cas de jeux parce que c'est ma seule expérience avec ce genre de soucis. Dans un cas standard avec un ordonnanceur qui fait bien son travail, le GC peut plomber les performance simplement parce que la désallocation se fait quand il l'a décidé, sans se soucier du temps qu'il a de disponible. C'est le cas avec le GC par défaut, les GC alternatifs proposés, et je n'ai pas vu d'alternative dédiée au respect du temps d'une frame quand j'ai fait mes maigres recherches à ce sujet. Mais je ne doute pas qu'il doit exister des GC exotiques que tu peux utiliser en patchant la jvm…

    Et, en particulier dans le cas d'un jeu, avoir des performances généralement moins bonnes, ou d'avoir un gros drop de fps à cause d'une désallocation massive à un moment précis, ben ça fait la différence entre un jeu qui reste jouable ou non. Et c'est au développeur de trouver une parade.

    Bref, pour en revenir sujet du thread, les GC peuvent être un soucis simplement quand le but est d'avoir un minimum de garantie de performances stables et sans que ce soit dans le contexte d'un driver.

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 3.

    Ensuite toujours pour java, tu as du tweak de jvm par rapport à ton code.

    Veux-tu dire par qu'il est possible de s'assurer que le GC n'interrompe pas ou ne ralentisse pas l’exécution d'une portion de code a un moment inopiné ?

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 2.

    On est d'accord que rien n'est simple, mais tu as au moins des outils pour te permettre de jouer finement avec les désallocation pour rester dans une frame de temps spécifique. Ce qui, après une rapide recherche sur les les garbage collectors de java, js et (à moindre mesure ?) python, ne me semble pas être le cas.

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 2.

    Quand la mémoire ne bouge pas et que le GC n'a rien à nettoyer, ça se passe bien.

    je vois qu'on en arrive à la même conclusion :)

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 2.

    C'est le soucis, ça simplifie la vie du développeur dans certains cas. Et ça la rend plus pénible dans d'autres.

    Avec une gestion manuelle tu peux facilement prendre des mesures pour l'évacuer petit à petit, et choisir ce qui est primordial d'évacuer en fonction du contexte, et avoir une garantie de stabilité dans les performances.

    Enfin bon, je sais que je ne t'apprends rien :-)

    Mais je suppose qu'il existe une obscure classe java qui permet de choisir quels types d'objets tu peux libérer et pendant combien de temps, exécuté à la demande.. ?

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 2.

    Tu dois être dans une dimension parallèle parce que je remarque que même des boites qui ont du goulot dans l'utilisation de java on eu récemment des soucis avec. Trois jeux en java que j'ai en tête :
    Minecraft
    Project Zomboid
    Star sector

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1.

    Les ramasses miettes modernes sont plutôt efficaces et simplifient énormément la vie des développeurs.

    Jusqu'au moment où ils la compliquent fortement, et on sait jamais quand ça va arriver.

    A moins d'être en train d'écrire un driver, un langage à GC est un bon choix.

    J'aurais tendance à dire partout où tu veux avoir des performances stables.

  • # Epson ET

    Posté par  . En réponse au message Achat d'imprimante : Laser ou Jet d'encre ?. Évalué à 5.

    J'ai une EcoTank d'Epson depuis pas très longtemps. Ca fonctionne très bien sous linux, et tu remplis tes réservoirs avec des petits bidons. D'après ce que j'ai lu, il y a moyen de les remplir autrement si besoin.

    Je ne peux pas dire sur le long terme, il me semble qu'Epson a déjà été épinglé pour faire des mises à jour douteuses de ses firmwares. Maintenant, je soupçonne que ma précédente HP ait subi ce genre de soucis, du jour au lendemain, plus de couleur.

    Pour la comparaison de prix, dans me souvenirs c'était pas trop loin du coût d'une laser N/B à l'impression, avec la couleur en prime.

  • [^] # Re: Cool ils ont pensé à l'OS/logiciel

    Posté par  . En réponse au lien EU regulators want 5 years of smartphone parts, much better batteries - OSnews. Évalué à 2. Dernière modification le 05 septembre 2022 à 11:30.

    L'essentiel d'un smartphone c'est sa carte mère. J'suis curieux de voir combien partagent la même…

  • # FSF

    Posté par  . En réponse au lien EU regulators want 5 years of smartphone parts, much better batteries - OSnews. Évalué à 6.

  • [^] # Re: Cool ils ont pensé à l'OS/logiciel

    Posté par  . En réponse au lien EU regulators want 5 years of smartphone parts, much better batteries - OSnews. Évalué à 0.

    Résultat, seuls quelques gros fabricants peuvent se permettre de tenir les 5 ans et ainsi éliminer la concurrence montante.

  • [^] # Re: Nan mais...

    Posté par  . En réponse au lien Le retour d'e-penser. Évalué à 2.

    Qualifier tout et n'importe quoi d’extrême est juste une manière de disqualifier des options sans avoir a trop réfléchir.

    Je pense surtout que le curseur de l'extrême est différent chez tout le monde, et fonction du sujets. D'ailleurs, j'aurais ajouté, dans la mesure du possible, l'installation forcée d'une distribution et d'un brouteur libre en utilisant les failles disponibles dans le navigateur et l'os privateur utilisé par l'hérétique qui pointe le bout de son nez.

  • [^] # Re: Nan mais...

    Posté par  . En réponse au lien Le retour d'e-penser. Évalué à 2.

    Merci pour ces infos, la presse people sur les youtubeurs c'est pas trop mon truc.

    Et même s'il m'a bien fatigué sur ses dernières vidéos, j'étais content de venir voir le sujet de celle-ci sans savoir si j'allais regarder jusqu'au bout.

    Niveau contenu, ça valait le détour sur plusieurs angles purement éducatifs et qui méritent à eux seuls ce lien je trouve. Après, si on doit juger une vidéo sur la passé de son concepteur, j'avoue que ce lien mérite cette note.

  • [^] # Re: Nan mais...

    Posté par  . En réponse au lien Le retour d'e-penser. Évalué à 5.

    Je serais plus partisant d'ajouter une icône automatiquement à côté des liens youtube, twitter et cie avec le lien pour pouvoir y accéder via le proxy mais sans changer le lien d'origine.

    Le soucis des proxys, c'est que le jour où ils arrêtent, on perd le lien vers l'information.

    La plupart des utilisateurs du site connaissent bien le soucis de ces plateformes, on pourrais aussi ajouter une information au survol du lien pour expliquer pourquoi on a ajouté des liens alternatifs.

    Maintenant, ça peut faire peur aux nouveaux de voir qu'on est des extrémistes ici…

  • [^] # Re: Nan mais...

    Posté par  . En réponse au lien Le retour d'e-penser. Évalué à 10.

    Je suis surpris qu'un lien qui, certes mériterait un peu plus d'explication mais qui pointe vers de l'information de qualité, obtienne une note aussi négative quand des liens très discutables et avec un lien encore plus étroit avec le logiciel libre (voir sans) sont dans le positif.

    Ici, ça parle quand même de probabilité et d'algorithme des plateformes de média sociaux.
    Si un article sur une hypothétique crise immobilière en chine (sur une plateforme non libre), ou les prix d'une application pour faire du voyage en train (plateforme non libre, tout comme le site sur lequel est l'analyse) ont leur place ici, la sanction pour avoir mis en avant sa réjouissance plutôt qu'une description en guise de titre est sévère quand il est possible de le modifier.

  • [^] # Re: Déjà vu ?

    Posté par  . En réponse au message Google Chrome court circuite la configuration DNS du système (?). Évalué à 3.

    J'ai pu remarquer que seuls Firefox et Safari utilisent OCSP par défaut.

  • [^] # Re: Micro?

    Posté par  . En réponse au journal Le paranormal en informatique. Évalué à 3.

    J'ai souvenir avoir eu des PCs portables avec des accéléromètres dedans qui étaient reconnus comme un gamepad. Pourrait y avoir un lien aussi..

  • [^] # Re: Nope

    Posté par  . En réponse au lien Java est toujours un champion. Évalué à 5.

    Java sur un rpi, si tu cherches la petit bête aussi…

    Tout le monde sait qu'il faut travailler des machines des processeurs un tant soit peu puissants, avec un minimum de ram et des disques potables avec java. Et là, on commence à parler :-)

    Un peu plus sérieusement, chez nous ce sont les containers java qui prennent a peu près une minute pour être fonctionnels quand des applications plus élaborées en python sont dispo quasiment instantanément. Ce sont les même développeurs (java à la base) qui ont fait les deux codes. Et je ne parle pas de la consommation de mémoire …

    Sur certains points, c'est pas encore ça.

    Par contre, point de vue vitesse d’exécution y'a pas photo, java a une longueur d'avance.

  • [^] # Re: Imprimante libre ?

    Posté par  . En réponse au lien Epson boobytrapped its printers (C. Doctorow). Évalué à 7.

    J'ai souvenir d'avoir lu que le soucis principal c'est d'arriver à avoir des buses pour l'encre.

    Pour faire la matrice perforée qui sert à controller le flux, il faut une technologie assez avancée et les sociétés qui ont la technologie ne veulent pas se mettre à dos les constructeurs.

    Bref, pour une version libre…

  • [^] # Re: ClamAV est connu pour ses faux positifs

    Posté par  . En réponse au journal Microsoft Visual C++ 2013 contenait-il un virus ?. Évalué à 3.

    Je pense que c'est surtout synonyme de "j'ai payé pour un un numéro de téléphone/email/… avec peut être quelqu'un de l'autre côté"

  • [^] # Re: L'argent, la solution à tous les problèmes

    Posté par  . En réponse au lien Why I Use the GPL and Not Cuck Licenses. Évalué à 3. Dernière modification le 29 juillet 2022 à 11:15.

    Ils peuvent dans les deux cas..

    Edit: on est d'accord que celui qui n'a pas choisi GPL évitera les dépendances GPL, il n'a pas placé son curseur du côté de l'utilisateur final dès le départ ce qui le contraint à se limiter niveau licence.

  • [^] # Re: L'argent, la solution à tous les problèmes

    Posté par  . En réponse au lien Why I Use the GPL and Not Cuck Licenses. Évalué à 2.

    Comment faire plus fallacieux que l'article…

    si tu veux que ça ne soit utilisé que par des logiciels en GPL, utilise la GPL. Si tu veux des retours sur ton code et que ça puisse être utile à tout le monde, utilise une BSD, MIT ou Apache.

    C'est clair que personne ne donne de retour sur le code de Linux et que c'est utile à moins de monde qu'un Darwin. Et je ne parle pas de la quantité de code en BSD/MIT/Apache2 dont je ne peux rien faire parce que je n'ai reçu que le binaire final.

    Bref, comme d'habitude les histoire de licence libre, le choix est fonction de à qui tu veux donner des libertés, l'utilisateur final ou ceux qui se feront du pognon avec ton code.