si le bicarbonate de soude ménager est légèrement plus agressif que le bicarbonate de soude alimentaire
Et ben bonjour le n'importe quoi…
Le bicarbonate de soude alimentaire est appelé alimentaire parce qu'il a été hroduit avc les précautions nécessaires pour la consommation humaine (mais pas pur hein). Il n'est pas plus ou moins "agressif", c'est toujours du bicarbonate de soude, constitué d'ions bicarbonate et d'ions sodium dans les mêmes proportions (parce que les lois de la chimie sont les mêmes pour tout le monde)
Bref, ça s'enfonce dans le "je comprend rien à ce que je raconte"…
Je ne suis pas bien sûr de ce qu'il y a dans "Web" (je n'ai pas regardé), mais ça ne me semble pas très pertinent de le mettre dans le Compliance.
Il s'agit de la possibilité de se connecter à un serveur XMPP via des requêtes HTTP(S) au lieu d'un socket SSL classique.
Ce n'est pas forcément lié au fait que le client soit un client Web, mais en pratique, comme un client Web ne peut pas ouvrir un socket SSL "normal", ce sera soit ça, soit des WebSocket. Et donc il faut que le serveur soit capable de recevoir des connexions via ces protocoles.
Au final, cette partie sera implémentée par les serveurs, et par les clients Web, et ça n'a pas d'intérêt pour les autres.
De la même façon, la partie "Mobile" n'a pas forcément d'intérêt sur un client qui tourne sur un PC avec une connexion internet stable.
C'est pour cette raison que ce sont des catégories séparées et que ça ne fait pas partie de la suite "instant messaging". Selon le cas, ce n'est pas utile ou pertinent d'implémenter ces spécifications.
On est quand même pas du tout dans le même contexte.
D'ailleurs, je ne suis pas sûr que le matériel utilisé dans les missions spatiales obtiendrait un bon score chez iFixIt: tout est scellé dans de l'epoxy pour éviter que les circuits soient endommagés lors du décollage des fusées.
Les contraintes de coût, de durée de vie, etc ne sont pas du tout les mêmes entre l'électronique grand public et une sonde interstellaire. Et parmi les entreprises actuelles, il y en a qui font très bien leur travail, et qui conçoivent des avions, trains, satellites (par exemple) qui auront aussi une durée de vie de plusieurs dizaines d'années sans problème. Mais ce n'est apparemment pas quelque chose qui justifie suffisamment les coûts (en temps de développement supplémentaire, complexification de la production, …), probablement parce que les acheteurs ne vont pas mettre la réparabilité dans leur liste de critères de choix (pas grand monde vérifie avant d'acheter un téléphone ou un ordinateur s'il y a un guide de démontage, si les pièces détachées sont disponibles, …).
Il y a une XEP appelée "compliance suites" qui définit un ensemble d'extensions qui sont recommandées, et la plupart des gros clients implémentent ou sont en train d'implémenter ces fonctionnalités.
En plus des fonctionnalités du vénérable Google Talk (sans parler de l'autre Talk, le vrai, parce que sinon la liste va être vraiment très longue), on a dans cette liste:
La synchronisation des messages entre plusieurs clients (tous les clients connectés à un même compte reçoivent les messages, pas un seul client)
Les conversations de groupe, avec archivage de l'historique des messages sur le serveur
Les accusés de réception (qui permettent aussi actuellement de synchroniser l'état "non lu" des messages entre plusieurs clients pour le même utilisateur)
La notification d'état "en train d'écrire"
Le partage de fichiers par HTTP ou en P2P
Plusieurs améliorations pour l'utilisation sur téléphone ou autre appareil qui a une connectivité relativement instable et/ou passe beaucoup de temps en veille
Les appels audio et video
Le chiffrement de bout en bout devrait arriver "bientôt" dans cette liste aussi.
La liste des logiciels fournie par la XMPP foundation permet de voir très rapidement si ces fonctionnalités sont disponibles (déplier les détails d'un logiciel pour faire apparaître la partie "compliance"):
Alors, oui, si vous voulez discuter avec une personne qui insiste pour n'utiliser aucun logiciel écrit après 2005 parce que tout ce qui s'est passé ensuite est infiltré par la NSA, ou équipé de micropuces comme les vaccins, ou nécessite un super-ordinateur à 8 coeurs de CPU et des dizaines de gigaoctets de mémoire, c'est vrai, XMPP peut le faire aussi.
Ah oui, et en plus, toutes ces extensions permettent aussi de réaliser des passerelles avec d'autres réseaux de chat en ayant une assez bonne correspondance des fonctionnalités (y compris des trucs comme les réactions aux messages, les messages colorisés de IRC, les fils de discussion, …) tout en gardant une rétro compatibilité avec les clients qui n'implémentent pas toutes ces fonctions. Ce qui fait de XMPP (avec Biboumi) un très bon "bouncer" pour IRC, par exemple. (mais ça permet aussi de se connecter à plein d'autres trucs avec Slidge).
Première définition (qui est raccord avec l'éthymologie et l'origine latine du mot):
Relatif à la racine, à l'essence de quelque chose. Qui concerne le principe premier, fondamental, qui est à l'origine d'une chose, d'un phénomène.
Par extension:
Complet, total, absolu; sans exception ou atténuation
Et donc, en politique, le parti radical a pris ce nom plutôt à partir de la première définition, parce que leurs idées étaient à la racine / proche de l'origine de l'historique du parti (alors que d'autres partis ont plus fait évoluer les choses).
Et il se trouve que ce parti est à l'opposé des conservateurs et des réactionnaires.
Mais quand on parle de radicalisation aujourd'hui, c'est plutôt de la deuxième définition qu'il s'agit, donc une forme d'extrêmisme et de jusqu'au-boutisme. Donc la première définition du mot se perd un peu.
Objectivement, c'est vrai que l'appellation officielle "extrême-droite" est problématique, parce que de nombreux partis d'extrême-droite la refusent.
Mais c'est justement la raison pour laquelle on ne laisse pas les partis s'étiqueter eux-mêmes. Il n'y a qu'à lire les noms des listes dans ce journal pour se rendre compte qu'on n'y comprendrait plus rien.
Cet étiquetage n'est bien sûr pas parfait (sinon, il y aurait beaucoup moins de listes, une seule par couleur politique), mais il donne un premier repère de où se situe chaque parti. On peut ensuite aller voir dans les détails si on le souhaite.
Ouais, comprendre la chaîne de compilation, c’est important. Mais aussi, pas tant que ça. Sur du java/javascript/python, y’a pas forcément grand chose de subtil, et en 20 ans, j’ai jamais eu un seul problème la dessus. Tout est dynamique, on s’en fout du layout en mémoire (sorti de trucs bizarres comme la serialization, mais c’est assez extrême comme example).
J'ai travaillé sur des projets ou la chaîne de compilation sur les serveurs de build était obligée de lancer un Eclipse parce que les développeurs avaient écrits certains de leurs outils de build sous forme de modules Ant qui appelaient des API de Eclipse et ça ne marchait que dans le contexte de l'IDE.
Alors il n'est certainement pas nécessaire que tout le monde dans l'équipe comprenne comment ça fonctionne dans le détail, mais pour ce genre de choses, c'est peut-être pas mal d'avoir au moins une vague idée de ce qu'il se passe.
Exemple de pays et territoires qui consomment une quantité à peu près soutenable de ressources: le Maroc, la Moldavie, la Guyane Française.
Exemple de pays qui épuisent leur quota en 4 mois ou moins: la France, la Belgique, le Luxembourg (deuxième place juste derrière le Qatar, bien joué).
Alors certes, le Maroc et la Moldavie n'ont peut-être pas le niveau de vie et de confort de la France ou du Luxembourg. Mais enfin, on ne parle tout de même pas d'un retour à l'âge de pierre?
Ensuite il faut se poser la question de répartir équitablement ces ressources. Parce que si on met la France au niveau de la Moldavie, on a 2 options: soit les 1% (ou 2, ou 10, ça change pas grand chose) les plus riches ne changent rien et les autres retournent à l'âge de pierre pour équilibrer, soit on trouve quelque chose d'un peu plus égalitaire.
Les commentaires sur plusieurs lignes /* */ quant à eux, semblent provenir de PL/I en 1964: https://pldb.io/concepts/pl-i.html ? (à moins qu'ils existent dans un langage plus ancien, ou bien qu'ils ne soient pas apparus dès le début de l'existence de PL/I).
On en est à 9 milliards avec des prévisions que ça continue d'augmenter encore jusque vers 2050, malgré la chute de la natalité un peu partout. (pour rappel c'était environ 3 milliards vers 1960 et il semble que ça se passait pas si mal que ça)
Pas près de redescendre à 500 millions à court terme, donc.
La "batterie" est un RTG: un bloc de plutonium fortement radioactif qui émet de la chaleur par désintégrations atomiques, chaleur qui est ensuite convertie enélectricité.
Ça marche très bien, mais ça tue les humains à proximité ou alors il faut un bon blindage autour.
On ne trouvera pas cette technologie dans nos ordinateurs et c'est probablement une bonne chose
Le z80 va continuer d'exister sous forme d'un composant intégrable dans un FPGA ou un composant dédié VLSI. Par exemple c'est comme ça qu'on le trouve dans les calculatrices chez Texas Instruments.
Ça n'a plus grand intérêt aujourd'hui d'avoir le CPU "tout seul" dans un composant.
Zilog continue d'ailleurs à produire les eZ80, qui contiennent divers composants (UART, RAM, …) en plus du processeur.
Pour le 68000, il semble être dans une situation similaire au Z80: il est "end of life" mais il est encore possible de passer des commandes. NXP annonce qu'il faut en commander au moins 420 et qu'il y a un temps d'attente de 99 semaines, donc ils ont pas trop envie de relancer la production quand même… De plus, le packaging PDIP (gros composants avec une rangée de pins de chaque côté) n'est plus disponible, il n'y a que du QFP (Quad Flat Package, plus petit, carré, et avec des pattes sur les 4 côtés).
On peut donc avoir un "presque" 68000 avec de l'USB et de l'Ethernet intégré et qui tourne à 250MHz. Et là il n'y a pas de problème, c'est toujours en production.
Ce problème peut donc être réglé pour quelques dizaines d'euros.
Un projet qui a démarré pour faciliter l'utilisation des micro ordinateurs et lancer des jeux vidéos, mais qui a trouvé son marché auprès de nombreux industriels (simulateurs de vols, machines à tisser, CNC, appareils de mesures, …) ainsi que pour des synthétiseurs musicaux, par exemple.
L'article lié mentionne que le backdoor se déclenche seulement si argv[0] (le nom du programme en cours d'exécution) est "/usr/sbin/sshd", et que l'exploit permet de détourner les clés RSA utilisées pour une connexion SSH. Difficile de penser que ça cible autre chose que sshd?
Je sais pas comment ça se passe chez vous, mais sur mon site perso, il y a facilent 1/3 du traffic qui est généré par des bots qui indexent et retéléchargent l'intégralité du site plusieurs fois par jour (y compris tous les gros fichiers liés dans les pages).
J'ai fini par bannir le bot de Amazon Alexa, parce que les gens de Amazon n'ont même pas pris la peine d'implémenter la lecture du robots.txt pour respecter un délai entre les requêtes (ce que les autres robots font, permettant de maîtriser un peu la quantité de traffic qu'on souhaite leur laisser). Il y en a plusieurs autres qui sont bannis ou ralentis via le robot.txt. Sinon, ce serait bien plus que 1/3 du traffic, probablement plus de la moitié.
En conséquence, je suis pour une limitation à 3Go par semaine pour les bots d'indexation. JE ne vois pas de raison de limiter le traffic généré par des humains, par contre. Même si je pense que je pourrais m'adapter sans problème, surtout si on met en place un tarif heures pleines/heures creuses. Comme ça je lance mes téléchargements la nuit?
Un exemple dont je me souviens est le lecteur mp3 Zune de Microsoft (oui, ça nous rajeunit pas). Ils utilisaient une fonction qui calculait, je crois, le "jour julien" (numéro du jour dans l'année). Cette fonction prenait bien sûr en compte le cas du 29 février, mais avec un bug qui faisait qu'elle se retrouvait en boucle infinie.
Le plus triste, c'est qu'ils avaient recopié cette fonction depuis un exemple dans une documentation de Motorola. Et que d'autres logiciels avant ou après s'étaient déjà fait piéger par ce bug en recopiant ce bout de code depuis la même documentation.
Les calculs de jour julien, numéros de semaines, tout ça, j'imagine bien que ça peut être utilisé dans le monde bancaire.
Pour l'éclairage public, je peux imaginer une table "date du jour-> horaires d'allumge" avec un trou le 29 février dans la table harce que ce jour n'était pas affiché pour la personne (ou l'algorithme) qui a rempli la table.
Parce que le projet fonctionne bien. Il y a une nouvelle version tous les 2 ans. Il y a du support LTS et même LTS étendu. La distribution ne s'amuse pas à tout changer à chaque version sans raison. Le fonctionnement des versions unstable, testing et stable est à peu près le même depuis 20 ans ou plus (je sais pas, je ne connaissais pas encore Debian il y a 20 ans).
Bref, y'a rien à dire, c'est un projet qui roule. En parler n'apporterait pas grand chose d'intéressant. Qu'est-ce qu'on pourrait bien raconter?
Les fichiers MOD sont basés sur deux choses: des "samples" (échantillons sonores, qui peuvent être rejoués à différentes fréquences pour jouer des notes différentes), et des "patterns" (qui indiquent quel sample jouer à quel moment, à quelle fréquence, à quel volume, etc).
Sur Amiga, la partie "sample" est gérée par le matériel: on dispose de 4 canaux (2 à droite et 2 à gauche sur la sortie stéréo) alimentés par des DMA, avec un réglage du volume et de la fréquence.
Toute la difficulté est donc la gestion des "patterns". Les fichiers MOD ont un format simple sous forme d'une liste de notes, chacune associée à un numéro de sample, un volume et un effet spécial. Un lecteur de musique MOD classique va directement lire ce format (ou une variante simplifiée ou compressée) et calculer en temps réel les fréquences, volumes, etc correspondants (les "effets" pouvant modifier les valeurs par rapport à ce qui est indiqué dans la liste de départ du pattern).
Ce que fait LSPlayer, c'est de précalculer à l'avance tout ça. Les patterns sont donc remplacés par une liste d'évènements de type:
Temps 0: lancer le sample à l'adresse X, sur le cannal A, avec un volume 7 et une fréquence N
Temps 1: changer le volume du canal A à 6
Temps 10: changer la fréquence du canal A à N+2
…
Ainsi, le player proprement dit n'a plus aucun calcul à faire, seulement à programmer ces valeurs directement dans les canaux DMA et la puce son.
Le compromis est qu'une telle liste va peut-être occuper plus de mémoire que le fichier original. Mais, en pratique, le format MOD n'est déjà pas très compact, et en plus, de toutes façons, la plus grande partie de la mémoire nécessaire est occupée par les samples. C'est donc un tr`s bon compromis finalement.
Leonard n'en est pas à son coup d'essai sur le sujet: cette technique est en fait assez directement inspirée de ce qu'il avait déjà fait il y a plusieurs dizaines d'années avec les fichiers YM permettant de faire la même chose, mais avec la puce son de l'Atari ST: stocker directement la liste des valeurs à programmer dans la puce, plutôt que de les calculer en temps réel à partir de données plus haut niveau.
Reste un dernier problème: la version pour Atari ST du player doit s'adapter à un matériel complètement différent, pas du tout pensé pour jouer des fichiers MOD (ou plutôt, l'inverse: les fichiers MOD ont été conçus en accord avec les spécificités de l'Amiga). Là, je n'ai pas regardé quelles astuces et tours de magie sont exploités pour y parvenir. En principe il faut faire logiciellement le mixage, car il n'y a que 2 canaux DMA au lieu de 4, et si je me souviens bien, en plus, leur fréquence n'est pas configurable (ça c'est pour l'Atari STe et Falcon, pour les machines précédentes, c'est encore pire).
Thumb-Key est fourni avec un layout compatible MessagEase (en plus de son nouveau layout). Il y a encore quelques différences (en particulier, il manque les aller-retours et cercles pour faire les lettres majuscules), mais ça vaut peut-être le coup de l'améliorer plutôt que de développer encore une autre application sur le même principe?
Ce n'est pas très clair dans cet article, mais ce changement consiste pour l'instant à ajouter Skia en parallèle de Cairo mais aussi des autres moteurs disponibles: la version de WebKit utilisée par Safari n'utilise pas Cairo et n'utilisera probablement pas non plus Skia.
Du côté de Haiku, sans accélération OpenGL, il est peut-être peu intéressant pour nous d'utiliser Skia? Pour l'instant, haikuwebkit utilise les APIs de BeOS et le rendu graphique est fait par l'app_server de Haiku.
La situation avant le "schisme" de Blink mentionné dans l'article était similaire: Skia était utilisé uniquement par Google pour Chrome, et les autres versions de WebKit utilisaient d'autres bibliothèques. C'est ce qui explique pourquoi le support de Skia avait été retiré de la base de code de WebKit à l'époque.
[^] # Re: Mise à jour "écologie au centre" ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Élections européennes de juin 2024 et contenu programmatique. Évalué à 3 (+1/-0).
Et ben bonjour le n'importe quoi…
Le bicarbonate de soude alimentaire est appelé alimentaire parce qu'il a été hroduit avc les précautions nécessaires pour la consommation humaine (mais pas pur hein). Il n'est pas plus ou moins "agressif", c'est toujours du bicarbonate de soude, constitué d'ions bicarbonate et d'ions sodium dans les mêmes proportions (parce que les lois de la chimie sont les mêmes pour tout le monde)
Bref, ça s'enfonce dans le "je comprend rien à ce que je raconte"…
[^] # Re: XMPP
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ICQ sera bronsonisé fin juin. Évalué à 6 (+4/-0).
Il s'agit de la possibilité de se connecter à un serveur XMPP via des requêtes HTTP(S) au lieu d'un socket SSL classique.
Ce n'est pas forcément lié au fait que le client soit un client Web, mais en pratique, comme un client Web ne peut pas ouvrir un socket SSL "normal", ce sera soit ça, soit des WebSocket. Et donc il faut que le serveur soit capable de recevoir des connexions via ces protocoles.
Au final, cette partie sera implémentée par les serveurs, et par les clients Web, et ça n'a pas d'intérêt pour les autres.
De la même façon, la partie "Mobile" n'a pas forcément d'intérêt sur un client qui tourne sur un PC avec une connexion internet stable.
C'est pour cette raison que ce sont des catégories séparées et que ça ne fait pas partie de la suite "instant messaging". Selon le cas, ce n'est pas utile ou pertinent d'implémenter ces spécifications.
[^] # Re: Bon voyage vers l'infini et au delà petit robot
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Voyager 1 Resumes Sending Science Data from Two Instruments. Évalué à 2 (+0/-0).
On est quand même pas du tout dans le même contexte.
D'ailleurs, je ne suis pas sûr que le matériel utilisé dans les missions spatiales obtiendrait un bon score chez iFixIt: tout est scellé dans de l'epoxy pour éviter que les circuits soient endommagés lors du décollage des fusées.
Les contraintes de coût, de durée de vie, etc ne sont pas du tout les mêmes entre l'électronique grand public et une sonde interstellaire. Et parmi les entreprises actuelles, il y en a qui font très bien leur travail, et qui conçoivent des avions, trains, satellites (par exemple) qui auront aussi une durée de vie de plusieurs dizaines d'années sans problème. Mais ce n'est apparemment pas quelque chose qui justifie suffisamment les coûts (en temps de développement supplémentaire, complexification de la production, …), probablement parce que les acheteurs ne vont pas mettre la réparabilité dans leur liste de critères de choix (pas grand monde vérifie avant d'acheter un téléphone ou un ordinateur s'il y a un guide de démontage, si les pièces détachées sont disponibles, …).
# XMPP
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ICQ sera bronsonisé fin juin. Évalué à 10 (+13/-0). Dernière modification le 26 mai 2024 à 09:56.
Pour XMPP, c'est un peu plus standardisé que ça.
Il y a une XEP appelée "compliance suites" qui définit un ensemble d'extensions qui sont recommandées, et la plupart des gros clients implémentent ou sont en train d'implémenter ces fonctionnalités.
https://xmpp.org/about/compliance-suites/
En plus des fonctionnalités du vénérable Google Talk (sans parler de l'autre Talk, le vrai, parce que sinon la liste va être vraiment très longue), on a dans cette liste:
Le chiffrement de bout en bout devrait arriver "bientôt" dans cette liste aussi.
La liste des logiciels fournie par la XMPP foundation permet de voir très rapidement si ces fonctionnalités sont disponibles (déplier les détails d'un logiciel pour faire apparaître la partie "compliance"):
https://xmpp.org/software/
Alors, oui, si vous voulez discuter avec une personne qui insiste pour n'utiliser aucun logiciel écrit après 2005 parce que tout ce qui s'est passé ensuite est infiltré par la NSA, ou équipé de micropuces comme les vaccins, ou nécessite un super-ordinateur à 8 coeurs de CPU et des dizaines de gigaoctets de mémoire, c'est vrai, XMPP peut le faire aussi.
Ah oui, et en plus, toutes ces extensions permettent aussi de réaliser des passerelles avec d'autres réseaux de chat en ayant une assez bonne correspondance des fonctionnalités (y compris des trucs comme les réactions aux messages, les messages colorisés de IRC, les fils de discussion, …) tout en gardant une rétro compatibilité avec les clients qui n'implémentent pas toutes ces fonctions. Ce qui fait de XMPP (avec Biboumi) un très bon "bouncer" pour IRC, par exemple. (mais ça permet aussi de se connecter à plein d'autres trucs avec Slidge).
[^] # Re: Gauche "radicale"
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Élections européennes de juin 2024 et contenu programmatique. Évalué à 2 (+0/-0).
Il y a eu un glissement sémantique:
https://www.cnrtl.fr/definition/radical
Première définition (qui est raccord avec l'éthymologie et l'origine latine du mot):
Par extension:
Et donc, en politique, le parti radical a pris ce nom plutôt à partir de la première définition, parce que leurs idées étaient à la racine / proche de l'origine de l'historique du parti (alors que d'autres partis ont plus fait évoluer les choses).
Et il se trouve que ce parti est à l'opposé des conservateurs et des réactionnaires.
Mais quand on parle de radicalisation aujourd'hui, c'est plutôt de la deuxième définition qu'il s'agit, donc une forme d'extrêmisme et de jusqu'au-boutisme. Donc la première définition du mot se perd un peu.
[^] # Re: autres sources d'information
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Élections européennes de juin 2024 et contenu programmatique. Évalué à 5 (+4/-1).
Mais c'est justement la raison pour laquelle on ne laisse pas les partis s'étiqueter eux-mêmes. Il n'y a qu'à lire les noms des listes dans ce journal pour se rendre compte qu'on n'y comprendrait plus rien.
Cet étiquetage n'est bien sûr pas parfait (sinon, il y aurait beaucoup moins de listes, une seule par couleur politique), mais il donne un premier repère de où se situe chaque parti. On peut ensuite aller voir dans les détails si on le souhaite.
# En retard
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Bouygues: d'anciens modems transformés en nouvelles box. Évalué à 4 (+2/-0).
Free l'a fait pendant des années pour ses box Alice il me semble (qui étaient des Freebox V5 dans un nouveau boîtier).
C'est peut-être le cas pour les box RED SFR aussi (qui ont toujours au moins une génération de retard sur les box SFR tout court).
C'est une bonne nouvelle que Bouygues s'y mette aussi, depuis le temps.
[^] # Re: Génération Z
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C11, listes variantes et le turfu. Évalué à 7 (+5/-0).
J'ai travaillé sur des projets ou la chaîne de compilation sur les serveurs de build était obligée de lancer un Eclipse parce que les développeurs avaient écrits certains de leurs outils de build sous forme de modules Ant qui appelaient des API de Eclipse et ça ne marchait que dans le contexte de l'IDE.
Alors il n'est certainement pas nécessaire que tout le monde dans l'équipe comprenne comment ça fonctionne dans le détail, mais pour ce genre de choses, c'est peut-être pas mal d'avoir au moins une vague idée de ce qu'il se passe.
[^] # Re: Panique pour qui ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Panique morale en cours sur la baisse de la natalité ?. Évalué à 3 (+1/-0). Dernière modification le 14 mai 2024 à 16:39.
Une façon un peu plus lissée de voir ça, c'est de regarder le classement du "jour du dépassement" par pays: https://overshoot.footprintnetwork.org/newsroom/country-overshoot-days/
Exemple de pays et territoires qui consomment une quantité à peu près soutenable de ressources: le Maroc, la Moldavie, la Guyane Française.
Exemple de pays qui épuisent leur quota en 4 mois ou moins: la France, la Belgique, le Luxembourg (deuxième place juste derrière le Qatar, bien joué).
Alors certes, le Maroc et la Moldavie n'ont peut-être pas le niveau de vie et de confort de la France ou du Luxembourg. Mais enfin, on ne parle tout de même pas d'un retour à l'âge de pierre?
Ensuite il faut se poser la question de répartir équitablement ces ressources. Parce que si on met la France au niveau de la Moldavie, on a 2 options: soit les 1% (ou 2, ou 10, ça change pas grand chose) les plus riches ne changent rien et les autres retournent à l'âge de pierre pour équilibrer, soit on trouve quelque chose d'un peu plus égalitaire.
[^] # Re: Génération Z
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C11, listes variantes et le turfu. Évalué à 6 (+4/-0).
Il semblerait que les commentaires commençant par
//étaient présents dans BCPL, un des ancêtres du C, dès 1967 au moins: https://retrocomputing.stackexchange.com/questions/27834/which-computer-language-was-the-first-with-two-forward-slashes-for-commenLes commentaires sur plusieurs lignes
/* */quant à eux, semblent provenir de PL/I en 1964: https://pldb.io/concepts/pl-i.html ? (à moins qu'ils existent dans un langage plus ancien, ou bien qu'ils ne soient pas apparus dès le début de l'existence de PL/I).[^] # Re: Bonne nouvelle?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Panique morale en cours sur la baisse de la natalité ?. Évalué à 6 (+4/-0).
On en est à 9 milliards avec des prévisions que ça continue d'augmenter encore jusque vers 2050, malgré la chute de la natalité un peu partout. (pour rappel c'était environ 3 milliards vers 1960 et il semble que ça se passait pas si mal que ça)
Pas près de redescendre à 500 millions à court terme, donc.
# Bonne nouvelle?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Panique morale en cours sur la baisse de la natalité ?. Évalué à 4 (+3/-1). Dernière modification le 13 mai 2024 à 15:02.
Le Mouvement pour l'Extinction Volontaire de l'Humanité a de plus en plus d'adeptes.
C'est plutôt une bonne nouvelle, non?
[^] # Re: Lunduke
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien MS-DOS 4.0 Source Code Fails to Compile. Évalué à 6 (+4/-0).
Les patchs nécessaires n'ont pas l'air bien compliqués: https://virtuallyfun.com/2024/04/28/compiling-ms-dos-4-0-from-dos-4-0-on-a-ps-2/
Je propose donc de renommer ce lien: "Bryan Lunduke n'arrive pas à compiler MS-DOS 4.0"
[^] # Re: Quand on veux...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien NASA’s Voyager 1 Resumes Sending Engineering Updates to Earth . Évalué à 10 (+9/-0). Dernière modification le 23 avril 2024 à 08:31.
La "batterie" est un RTG: un bloc de plutonium fortement radioactif qui émet de la chaleur par désintégrations atomiques, chaleur qui est ensuite convertie enélectricité.
Ça marche très bien, mais ça tue les humains à proximité ou alors il faut un bon blindage autour.
On ne trouvera pas cette technologie dans nos ordinateurs et c'est probablement une bonne chose
[^] # Re: Ça me fait tout drôle
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Zilog met fin à la production des processeurs z80. Évalué à 8 (+6/-0).
Le z80 va continuer d'exister sous forme d'un composant intégrable dans un FPGA ou un composant dédié VLSI. Par exemple c'est comme ça qu'on le trouve dans les calculatrices chez Texas Instruments.
Ça n'a plus grand intérêt aujourd'hui d'avoir le CPU "tout seul" dans un composant.
Zilog continue d'ailleurs à produire les eZ80, qui contiennent divers composants (UART, RAM, …) en plus du processeur.
Pour le 68000, il semble être dans une situation similaire au Z80: il est "end of life" mais il est encore possible de passer des commandes. NXP annonce qu'il faut en commander au moins 420 et qu'il y a un temps d'attente de 99 semaines, donc ils ont pas trop envie de relancer la production quand même… De plus, le packaging PDIP (gros composants avec une rangée de pins de chaque côté) n'est plus disponible, il n'y a que du QFP (Quad Flat Package, plus petit, carré, et avec des pattes sur les 4 côtés).
https://www.nxp.com/products/processors-and-microcontrollers/legacy-mpu-mcus/32-bit-coldfire-mcus-mpus/68k-processors-legacy/m680x0/low-cost-32-bit-microprocessor-including-hc000-hc001-ec000-and-sec000:MC68000?tab=Buy_Parametric_Tab#/
Cependant, la famille de processeurs ColdFire qui est proche du 68000 (bien que pas tout à fait compatible, je crois qu'ils ont supprimé et remplacé quelques instructions) est encore en production: https://www.nxp.com/products/processors-and-microcontrollers/legacy-mpu-mcus/32-bit-coldfire-mcus-mpus/coldfire-processors/coldfire-v4-processors/32-bit-microprocessor:MCF5441X
On peut donc avoir un "presque" 68000 avec de l'USB et de l'Ethernet intégré et qui tourne à 250MHz. Et là il n'y a pas de problème, c'est toujours en production.
[^] # Re: Autre génération
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien 3 disquettes font tourner le métro de cette ville depuis 26 ans, l’inquiétude monte [USA]. Évalué à 5 (+4/-1).
En effet, ce n'est pas bien compliqué de remplacer un lecteur de disquettes par un équipement avec une clé USB ou une carte SD:
https://www.hxc2001.com/floppy_drive_emulator/
Ce problème peut donc être réglé pour quelques dizaines d'euros.
Un projet qui a démarré pour faciliter l'utilisation des micro ordinateurs et lancer des jeux vidéos, mais qui a trouvé son marché auprès de nombreux industriels (simulateurs de vols, machines à tisser, CNC, appareils de mesures, …) ainsi que pour des synthétiseurs musicaux, par exemple.
[^] # Re: pareil pour les villes ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Annuaire des pianos dans les aéroports. Évalué à 3 (+1/-0).
Il y a une liste p/us générale, mais pas open source/open data ici: https://pianos.pub
Je ne sais pas si il y a un tag spécifique dans openstreetmap pour ça?
[^] # Re: Je pense que sshd n'était pas visé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 10 (+12/-0). Dernière modification le 29 mars 2024 à 19:59.
L'article lié mentionne que le backdoor se déclenche seulement si
argv[0](le nom du programme en cours d'exécution) est "/usr/sbin/sshd", et que l'exploit permet de détourner les clés RSA utilisées pour une connexion SSH. Difficile de penser que ça cible autre chose que sshd?[^] # Re: La mienne marche encore
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Webmail + pages perso free aux non abonnés, c'est terminé. Évalué à 4 (+2/-0).
Le lien dit qu'on ne peut plus créer de nouveaux comptes, mais que les comptes existants continuent de fonctionner.
L'hébergement de pages chez chez.com (qui a été racheté par free) semble toujours ouvert, pour l'instant.
[^] # Re: Répartition du trafic LinuxFr.org
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 10 (+9/-0).
Je sais pas comment ça se passe chez vous, mais sur mon site perso, il y a facilent 1/3 du traffic qui est généré par des bots qui indexent et retéléchargent l'intégralité du site plusieurs fois par jour (y compris tous les gros fichiers liés dans les pages).
J'ai fini par bannir le bot de Amazon Alexa, parce que les gens de Amazon n'ont même pas pris la peine d'implémenter la lecture du robots.txt pour respecter un délai entre les requêtes (ce que les autres robots font, permettant de maîtriser un peu la quantité de traffic qu'on souhaite leur laisser). Il y en a plusieurs autres qui sont bannis ou ralentis via le robot.txt. Sinon, ce serait bien plus que 1/3 du traffic, probablement plus de la moitié.
En conséquence, je suis pour une limitation à 3Go par semaine pour les bots d'indexation. JE ne vois pas de raison de limiter le traffic généré par des humains, par contre. Même si je pense que je pourrais m'adapter sans problème, surtout si on met en place un tarif heures pleines/heures creuses. Comme ça je lance mes téléchargements la nuit?
[^] # Re: Comment est-ce possible ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Un 29 février ? C'est quoi ça ? C'est nouveau ?. Évalué à 4 (+2/-0).
Un exemple dont je me souviens est le lecteur mp3 Zune de Microsoft (oui, ça nous rajeunit pas). Ils utilisaient une fonction qui calculait, je crois, le "jour julien" (numéro du jour dans l'année). Cette fonction prenait bien sûr en compte le cas du 29 février, mais avec un bug qui faisait qu'elle se retrouvait en boucle infinie.
Le plus triste, c'est qu'ils avaient recopié cette fonction depuis un exemple dans une documentation de Motorola. Et que d'autres logiciels avant ou après s'étaient déjà fait piéger par ce bug en recopiant ce bout de code depuis la même documentation.
Les calculs de jour julien, numéros de semaines, tout ça, j'imagine bien que ça peut être utilisé dans le monde bancaire.
Pour l'éclairage public, je peux imaginer une table "date du jour-> horaires d'allumge" avec un trou le 29 février dans la table harce que ce jour n'était pas affiché pour la personne (ou l'algorithme) qui a rempli la table.
[^] # Fiabilité des distributions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Les distro pionnières, en recul?. Évalué à 10 (+11/-0).
Pourquoi on entend pas parler de Debian?
Parce que le projet fonctionne bien. Il y a une nouvelle version tous les 2 ans. Il y a du support LTS et même LTS étendu. La distribution ne s'amuse pas à tout changer à chaque version sans raison. Le fonctionnement des versions unstable, testing et stable est à peu près le même depuis 20 ans ou plus (je sais pas, je ne connaissais pas encore Debian il y a 20 ans).
Bref, y'a rien à dire, c'est un projet qui roule. En parler n'apporterait pas grand chose d'intéressant. Qu'est-ce qu'on pourrait bien raconter?
# Détails techniques
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Amiga + Mac + Linux MOD player en ASM !!!. Évalué à 10.
Un résumé rapide du principe de ce player.
Les fichiers MOD sont basés sur deux choses: des "samples" (échantillons sonores, qui peuvent être rejoués à différentes fréquences pour jouer des notes différentes), et des "patterns" (qui indiquent quel sample jouer à quel moment, à quelle fréquence, à quel volume, etc).
Sur Amiga, la partie "sample" est gérée par le matériel: on dispose de 4 canaux (2 à droite et 2 à gauche sur la sortie stéréo) alimentés par des DMA, avec un réglage du volume et de la fréquence.
Toute la difficulté est donc la gestion des "patterns". Les fichiers MOD ont un format simple sous forme d'une liste de notes, chacune associée à un numéro de sample, un volume et un effet spécial. Un lecteur de musique MOD classique va directement lire ce format (ou une variante simplifiée ou compressée) et calculer en temps réel les fréquences, volumes, etc correspondants (les "effets" pouvant modifier les valeurs par rapport à ce qui est indiqué dans la liste de départ du pattern).
Ce que fait LSPlayer, c'est de précalculer à l'avance tout ça. Les patterns sont donc remplacés par une liste d'évènements de type:
Ainsi, le player proprement dit n'a plus aucun calcul à faire, seulement à programmer ces valeurs directement dans les canaux DMA et la puce son.
Le compromis est qu'une telle liste va peut-être occuper plus de mémoire que le fichier original. Mais, en pratique, le format MOD n'est déjà pas très compact, et en plus, de toutes façons, la plus grande partie de la mémoire nécessaire est occupée par les samples. C'est donc un tr`s bon compromis finalement.
Leonard n'en est pas à son coup d'essai sur le sujet: cette technique est en fait assez directement inspirée de ce qu'il avait déjà fait il y a plusieurs dizaines d'années avec les fichiers YM permettant de faire la même chose, mais avec la puce son de l'Atari ST: stocker directement la liste des valeurs à programmer dans la puce, plutôt que de les calculer en temps réel à partir de données plus haut niveau.
Reste un dernier problème: la version pour Atari ST du player doit s'adapter à un matériel complètement différent, pas du tout pensé pour jouer des fichiers MOD (ou plutôt, l'inverse: les fichiers MOD ont été conçus en accord avec les spécificités de l'Amiga). Là, je n'ai pas regardé quelles astuces et tours de magie sont exploités pour y parvenir. En principe il faut faire logiciellement le mixage, car il n'y a que 2 canaux DMA au lieu de 4, et si je me souviens bien, en plus, leur fréquence n'est pas configurable (ça c'est pour l'Atari STe et Falcon, pour les machines précédentes, c'est encore pire).
# Thumb-Key
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal MessagEase passe en mode abonement.. Évalué à 7.
Thumb-Key est fourni avec un layout compatible MessagEase (en plus de son nouveau layout). Il y a encore quelques différences (en particulier, il manque les aller-retours et cercles pour faire les lettres majuscules), mais ça vaut peut-être le coup de l'améliorer plutôt que de développer encore une autre application sur le même principe?
# Précision
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comme tous les autres moteurs de rendu, WebKit (ré)adopte la bibliothèque graphique Skia. Évalué à 4.
Ce n'est pas très clair dans cet article, mais ce changement consiste pour l'instant à ajouter Skia en parallèle de Cairo mais aussi des autres moteurs disponibles: la version de WebKit utilisée par Safari n'utilise pas Cairo et n'utilisera probablement pas non plus Skia.
Du côté de Haiku, sans accélération OpenGL, il est peut-être peu intéressant pour nous d'utiliser Skia? Pour l'instant, haikuwebkit utilise les APIs de BeOS et le rendu graphique est fait par l'app_server de Haiku.
La situation avant le "schisme" de Blink mentionné dans l'article était similaire: Skia était utilisé uniquement par Google pour Chrome, et les autres versions de WebKit utilisaient d'autres bibliothèques. C'est ce qui explique pourquoi le support de Skia avait été retiré de la base de code de WebKit à l'époque.