pulkomandy a écrit 1698 commentaires

  • # Payback

    Posté par  (site web personnel, Mastodon) . En réponse au lien vieux (2008) mais amusant : « Ma vraie histoire de Grand Theft Auto ». Évalué à 4.

    Ça me rapelle qu'il existe un clone de GTA pour Amiga: Payback. Mais ça ne tourne pas sur un Amiga en configuration de base.

  • # Censure?

    Posté par  (site web personnel, Mastodon) . En réponse au lien Nouveau cas de censure de Facebook: le journal en ligne Rapport de forces en est totalement évincé. Évalué à 8.

    On peut arrêter de parler de censure pour n'importe quoi? Facebook n'est pas un service public. Ils peuvent très bien décider ce qu'ils font apparaître sur leur site web ou pas.

    Qu'ils fassent leur modération et leur sélection n'importe comment (de façon opaque et arbitraire), soit. Mais ce n'est pas de la censure.

  • [^] # Re: Combien de bits?

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Construisez et programmez votre console de jeux open source. Évalué à 5.

    Il y a la bitbox avec un CPU ARM à environ 130MHz (ça change en fonction du mode vidéo choisi) et des capacités graphiques quelque part entre l'Atari VCS 2600 et la MegaCD (beaucoup de choses étant faites en logiciel dans la bitbox, elle peut donc se programmer de plein de façons différentes selon les besoins).

    Le matériel est relativement simple (il n'y a pas grand chose sur la carte à part le CPU et les connecteurs audio/video/usb) mais pas évident à assembler soi même si on a pas l'habitude de manipuler un fer à souder (composants montés en surface et de petite taille).

    Le projet semble ne plus trop évoluer ces derniers temps. Peut être que je me remettrai un jour à programmer des choses pour la bitbox.

  • [^] # Re: Alternatives ?

    Posté par  (site web personnel, Mastodon) . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 4. Dernière modification le 25 octobre 2020 à 23:17.

    Oui, je n'ai pas précisé mais ce message était dans un esprit de "il faut connaîtreses ennemis". C'est pas parce que c'est pas libre qu'il n'y a que des mauvaises idées dedans, et, à défaut de pouvoir réutiliser le code, on peut au moins récupérer les idées.

    Enfin bref, je ne comprend pas que ça ne soit pas une fonctionnalité par défaut de n'importe quel navigateur et qu'il soit nécessaire de jongler avec des outils comme youtube-dl ou des extensions.

  • [^] # Re: Alternatives ?

    Posté par  (site web personnel, Mastodon) . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 2.

    Le navigateur web Vivaldi a un menu clic droit->enregistrer la vidéo (comme pour les images dans les autres navigateurs). Pourquoi faire simple quand on peut faire compliqué?

  • [^] # Re: N'ont-ils pas donné à la RIAA tout ce qu'il faut?

    Posté par  (site web personnel, Mastodon) . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 4.

    A priori, les tests unitaires utilisent des vidéos de test de ce type: https://www.youtube.com/watch?v=BaW_jenozKc et de même pour les exemples dans la documentation.

    Difficile de voir ce à quoi la lettre fait références pour ces 3 vidéos, il est question d'un "exhibit A" mais je ne vois pas de lien ou de pièce jointe.

  • [^] # Re: Ras le bol de ces noms de langage de merde!

    Posté par  (site web personnel, Mastodon) . En réponse au journal Ras le bol de ces moteurs de merde!. Évalué à 4.

    D'un autre côté… faire des trucs impossible à retrouver via un moteur de rechercqe, ça oblige les gens à savoir utiliser les URLs et les bookmarks :o)

  • [^] # Re: C'est foutu !

    Posté par  (site web personnel, Mastodon) . En réponse au lien No, Microsoft is not rebasing Windows to Linux. Évalué à 4.

    C'est mal connaître le travail que font les gens de CentOS, sans support de RedHat, pour arriver à tout compiler. Plusieurs mois de travail à chaque nouvelle version de RedHat.

    Donc, certes, Microsoft a publié seulement une petite partie de son code, et RedHat a publié seulement une grande partie de son code. Mais le principe est le même, et d'un point de vue légal et droits de distribution, c'est pareil.

    La question est juste: combien de temps avant que Microsoft ne rattrape RedHat? On a vu avec une récente fuite du code de Windows XP que des gens étaient capables de le recompiler sans trop de problèmes. Peut être que c'est moins loin qu'on le pense pour les versions suivantes…

  • [^] # Re: Plus de Firefox pour moi

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Histoire des systèmes d’extensions de Firefox. Évalué à 3.

    Tu ne peux pas comparer le marché des navigateurs en 2004, où Microsoft avait abandonné le développement d'Internet Explorer et que Firefox n'avait pas vraiment de concurrents

    Ça m'étonne toujours le silence sur Safari dans ces discussions (apparu en 2003, version Windows de 2007 à 2012). Pourtant il a aussi bien fait bouger les choses.

  • [^] # Re: C'est foutu !

    Posté par  (site web personnel, Mastodon) . En réponse au lien No, Microsoft is not rebasing Windows to Linux. Évalué à 5.

    D'ailleurs tout le monde sait que Wine n'existe pas, ce qui démontre bien que lancer les applications Windows sous Linux est impossible.

  • [^] # Re: Comment ça perdu?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 5.

    La compression c'est tout le contraire du bas niveau. C'est justement un truc purement algorithmique et indépendant du matériel.

    Si le problème était résolu, on aurait un algo super efficace de la mort qui tue et il serait implémenté par le premier disque dur/ssd/carte sd venue (qui ne voudrait pas faire x2 sur sa capacité de stockage affichée?). A priori ce n'est pas le cas.

    En télécom, on utilise la compression (et ça fait partie de la formation, en tout cas y'a 10 ans quand j'étais étudiant?) mais on a des problématiques qui font qu'on ne peut pas forcément atteindre les limites théoriques: contraintes de temps réel, de limitations matérielles (taille de la mémoire disponible) et de latence. En gros, on ne peut pas attendre d'avoir 4Go de données à envoyer pour les compresser de façon optimale, on est obligés de traiter ça en flux au fur et à mesure que les données arrivent.

    Après, oui, y'a plein de cas ou il n'y a pas besoin de compression à proprement parler (ça peut être suffisant d'utiliser un format approprié pour les données, ou il y aura déjà peu de redondance), ou alors, on peut utiliser un algorithme existant qui fonctionnera très bien pour les besoins identifiés. Ou bien on peut tomber sur des cas tordus, par exemple dans Haiku on a un gestionnaire de paquets qui a besoin de faire des accès aléatoires au contenu du paquet. Actuellement l'approche utilisée est de découper le paquet en blocs de 4K et de compresser chaque bloc séparément, et c'est pas hyper efficace. Y'a probablement mieux comme algo de compression qui permet de décompresser une partie aléatoire du flux (sans décompresser tout ce qu'il y a avant), non? Des suggestions?

  • [^] # Re: Et du coup, pour remplacer Whatsapp & autres

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche XMPP croque la pomme !. Évalué à 7.

    Un des gros problème d'Apple que j'ai pu rencontrer est sa gestion du maintien d'une connexion permanente qui nécessite un serveur de push et des contorsions complexes pour passer par dessus les barrières mises en place par cet écosystème privateur.

    Le problème est lié à l'utilisation de connexions persistantes TCP en général sur les terminaux mobiles.

    En gros, avoir une connection TCP qui reste ouverte en permanence, ça oblige à envoyer des données et à rester tout le temps à l'écoute, ça empêche l'appareil de se mettre en veille, et donc ça vide la batterie.

    Le problème est le même avec n'importe quel OS.

    La solution proposée (aussi bien pour Apple que Android) ce sont effectivement les "push notifications" qui évitent d'avoir une connexion ouverte en permanence pour chaque application. La XSF se penche sur le sujet, a priori le point d'entrée est https://xmpp.org/extensions/xep-0286.html avec des liens vers plusieurs autres XEP donnant les bonnes pratiques pour un client fonctionnant sur ce type de réseau.

    En particulier pour les push notifications: https://xmpp.org/extensions/xep-0357.html

  • [^] # Re: Divorce et margarine

    Posté par  (site web personnel, Mastodon) . En réponse au lien Manger du chocolat rapporte des prix Nobel. Évalué à 2.

    Prenons-en quelques unes qui rentrent dans le sujet:
    - Manger du poulet augmente les importations de pétrole brut
    - La production d'énergie nucléaire augmente le risque de mort par noyade dans une piscine
    - Stocker de l'uranium dans les centrales nucléaires augmente le nombre de doctorats en mathématiques

    (et inversement, bien sûr, puisque la corrélation n'implique pas la causation, ni dans un sens, ni dans l'autre)

  • [^] # Re: Précision

    Posté par  (site web personnel, Mastodon) . En réponse au lien Énergies renouvelables - Une centrale solaire aussi puissante (2.2 GW) que 2 réacteurs nucléaires. Évalué à 3.

    Çadépend des endroits. Chez moi il y a des heures creuses la nuit (de 4h à 7h, je crois) mais aussi dans l'après-midi (14h30-16h30).

    C'est ajusté en fonction de la consommation électrique locale, le but étant de lisser la consommation sur la journée.

    Il est possible pour enedis (ou edf, j'ai du mal à suivre qui fait quoi) de changer les horaires et techniquement ils pourraient le faire de façon dynamique, le compteur électrique signale le passage en heures creuses et les appareils ménagers le détectent pour se déclencher.

    C'est donc envisageable de le faire en fonction de la consommation effective plutôt que d'horaires fixes.

  • [^] # Re: ...

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 10.

    En tout cas il y a toujours autant de grincheux qui pensent que c'était mieux avant!

  • [^] # Re: Travaux

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 2.

    La compression consiste à supprimer ou réduire la redondance des données.

    • Ne pas stocker/transmettre 2 fois la même chose
    • Ne pas stocker/tranmettre ce qui n'a pasbesoin de l'être

    On peut regarder du côté de la théorie de l'information et la façon dont on peut définir la quantité d'information présente dans une donnée quelconque, en étudiant la probabilité dechaque bit d'être un 0 ou un 1, en fonction des bits précédents et de toute autre connaissance du récepteur de la donnée. Ce qui donne une limite théorique à la réduction de taillle qu'on peut obtenir, si on atteint le fomat de compression idéal ou chaque bit a exactement une probabilité de 0.5 d'être un 0 ou un 1.

  • [^] # Re: Comment ça perdu?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 2.

    Euh, Zstd, développé par Facebook pour avoir un truc plus rapide et plus efficace que la zlib?

    Alors oui si on regarde le web frontend, le desktop et les applis mobiles, en ce moment, c'est pas trop l'aspect privilégié. Mais ça ne veut pas dire que les compétences sont perdues, seulement qu'il y a des endroits ou ça n'est pas justifié/pas rentable de le faire.

    Le logiciel embarqué a toujours des contraintes, mais pas forcément les mêmes. Pour gagner en durée de batterie sur un téléphone, il vaut mieux avoir des données moins compressées mais accessibles sans faire plein de calculs cpu pour les décoder, par exemple.

  • [^] # Re: ça n'avance pas tellement

    Posté par  (site web personnel, Mastodon) . En réponse au lien Darling, Lamulateur de MacOS X pour linux. Évalué à 5.

    Ou peut-être que le code fonctionne parfaitement et qu'il n'y a pas besoin de faire de changements.

    Personellement, voir des douzaines de commits par jour sur un projet ne me rassure pas quant à sa maturité et stabilité :)

  • # Comment ça perdu?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 10.

    Pendant le mois de septembre 2020, près d'une vingtaine de nouvelles oeuvres de la demoscene dans les catégories <= 4Ko (je ne sais pas d'ou sort cette histoire de 5Ko, ça fonctionne par multiples de 2 bien sûr).

    La page de LZSA donne une comparaison des différents outils souvent utilisés, en terme d'efficacité de la compression ainsi que du temps de décompression.

    Dire que "cet art noble du hacker s'est perdu", ça me semble… quelque peu exagéré, au moins.

    (ce ne sont pas forcément les algorithmes les plus efficaces en terme de taille économisée, il y a des compromis pour garder une vitesse de décompression acceptable y compris pour des CPUs peu performants).

  • # Ça peut arriver à tout le monde

    Posté par  (site web personnel, Mastodon) . En réponse au journal Le câblage enterré innovant. Évalué à 10.

    Il est enterré à -30cm de profondeur, ça peut arriver à tout le monde une erreur de signe sur ce genre de chose.

  • [^] # Re: objectif de l'hacktober feast

    Posté par  (site web personnel, Mastodon) . En réponse au lien pull request «DDoS» par DO sur github?. Évalué à 5.

    De ce que j'ai compris ça partait d'une bonne intention. Un développeur chez eux s'est dit "hey on devrait faire un truc pour remercier les contributeurs aux logiciels open source pour leur travail". Visiblement c'était plus facile d'avoir un budget auprès du département marketing de la boîte pour imprimer et expédier des T-Shirts et des stickers, que de verser des sous directement aux gens (je suis pas surpris).

    Une page web pour annoncer le truc, on se branche sur les APIs de Github pour compter les pull requests, et c'est parti. Le développeur est content et passe à autre chose.

    Quelques années plus tard, ça a pris de l'ampleur, d'autres boîtes ont trouvé que l'idée était cool et ont décidé de sponsoriser le truc (70000 T-Shirts ça finit par faire un budget pas négligeable finalement). Hacktoberfest est devenu un moyen pour pas mal de gens de se lancer dans les contributions.

    Apparament, certaines écoles d'informatique en Inde se sont dit "hé mais c'est cool ça, on va en faire la promotion à nos étudiants et les encourager à participer à des projets opensource" (ou bien certains étudiants ont commencé à participer, puis avec leurs T-Shirts, fait de la publicité à leur collègues).

    Voilà. Personne là dedans n'avait de mauvaises intentions.

    Seulement, ils n'ont pas pensé au départ que des gens voudraient tricher (pour gagner un T-Shirt? en effet ça paraît improbable). Ils n'ont pas pensé non plus que tous les projets sur github ne souhaitaient peut-être pas accepter des contributions de n'importe qui (par exemple un des projets victime de spam cette année est le whatwg qui travaille sur les spécifications du html5, pas vraiement le genre de trucs ou n'importe qui envoie des pull requests en général…). Ils n'ont pas anticipé que accueillir et former des dizaines de milliers de contributeurs, ça demande du temps et de la préparation. Là aussi on peut les comprendre, au départ l'idée était plutôt de récompenser des contributeurs existants, que d'encourager les gens à se lancer pour faire leur première contribution.

    Bref, le succès du truc les a complètement dépassés, mais je pense que ça peut se comprendre, je ne pense pas qu'ils auraient pu le voir venir.

    Quant à savoir s'il y aurait une façon plus efficace d'utiliser ce budget, oui, probablement. Et vous, que faites-vous dans vos entreprises respectives pour contribuer au logiciel libre?

  • # L'enquête continue

    Posté par  (site web personnel, Mastodon) . En réponse au lien pull request «DDoS» par DO sur github?. Évalué à 8.

    A priori cela viendrait d'un youtubeur qui a montré un exemple de pull request qui aurqit été suivi un peu trop littéralement par les gens qui ont vu sa vidéo.

    Source: https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama

  • # Je confirme

    Posté par  (site web personnel, Mastodon) . En réponse au lien pull request «DDoS» par DO sur github?. Évalué à 10.

    Pour la première fois cette année nous sommes chez Haiku victime de ce "spam". C'est d'autant plus ridicule que notre dépôt principal n'est pas sur github, c'est le dépôt contenant notre site web qui est visé. Avec des changements du genre rajouter "an amazing project" n'importe où dans le titre d'une page.

    Ça partait d'une bonne intention, pourtant, encourager les contributions à l'open source. Mais rien ne va dans la façon dont c'est mis en place:

    • Il est obligatoire pour participer, d'être sur Github. Le truc qui n'est même pas open source, là.
    • Tout github est ouvert à la participation, a priori y compris les projets qui n'ont pas une license libre.
    • Les gens qui ont mis leurs sources sur github reçoivent ces contributions sans savoir de quoi il s'agit. Rien n'indique que c'est pour hacktoberfest dans les pull requests.
    • Hacktoberfest demande aux mainteneurs de dépôts de fermer les merge requests et de leur appliquer un label pour les exclure de hacktoberfest, si ce n'est pas fait, la pull request est automatiquement validée. Donc il suffit de trouver un dépôt inactif et de faire une pull request dessus, personne ne pourra la fermer.
    • Les mainteneurs qui participent (contre leur gré, donc) ne sont même pas rémunérés.
    • Il n'y a aucun encadrement des participants pour leur expliquer comment ça fonctionne. Hacktoberfest part du principe que tout le monde sait déjà comment fonctionne Github, alors même que le but est d'encourager les nouveaux contributeurs à se lancer.

    Pourtant, il y avait une solution qui marchait bien. Google, entre 2010 et 2019, organisait le Google Code-In, qui fonctionnait de la façon suivante:

    • Limité à un petit nombre de projets volontaires (une dizaine au départ, puis cela a augmenté petit à petit)
    • Des tâches spécifiques et adaptées pour des contributeurs débutants (d'autant plus que seuls les 13-17ans pouvaient participer)
    • Un site web dédié permettant de ne pas innonder les moyens de communication normaux des projets avec les participants au concours
    • Une compensation financière pour les projets participants, étant donné la charge de travail que cela représente
    • Il n'était pas nécessaire d'être sur github, chaque projet participant pouvait donc héberger son code comme il le souhaitait,
    • Un choix des gagnants, pas seulement en fonction du nombre de pull requests complétées, mais par une revue des tâches par les membres des projets participants, afin de privilégier la qualité du travail.

    Voilà, ça semble pourtant pas compliqué de faire les choses correctement. Mais Google a décidé que cela ne les intéressait plus. Probablement parce que la charge de travail pour faire fonctionner tout ça était trop importante et qu'ils ont mieux à faire ailleurs. Dommage.

  • [^] # Re: Ha...

    Posté par  (site web personnel, Mastodon) . En réponse au journal Cyclimse en Anjou. Évalué à 0.

    En assumant du genre "moi je suis riche donc j'ai le droit d'avoir un gros SUV polluant"? Mouais, je suis moyennement convaincu par cette approche.

  • # CoAP

    Posté par  (site web personnel, Mastodon) . En réponse au journal Mozilla abandonne le web des objets. Évalué à 5.

    Pourquoi vouloir mettre du HTTP partout alors que pour les objets connectés il y a CoAP? Avec tout plein de RFCs, on ne pourra pas dire que c'est pas standard.