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.
Surtout qu'on pourrait utiliser une traduction plus appropriée de "fork", comme par exemple "bifurquer" ou "embrancher". Ou alors un mot utilisé dans d'autres contextes pour plus ou moins la même idée, comme "essaimer", "fissionner", "scissionner"… Les choix ne manquent pourtant pas, c'est dommage d'utiliser un mot qui finalement n'est qu'un anglicisme masqué par une mauvaise (volontairement ou pas) traduction littérale?
Et de manière pas tout à fait négligeable, il y a une série de journaux qui auraient toute leur place comme dépêche mais certaines personnes idéalisent à mon sens un peu trop ce que doit être une dépêche.
Les dépêches mettent beaucoup moins en avant l'auteurice (son avatar n'est pas affiché par exemple), et le passage en modération (ou les interventions d'autres contributeurs dans l'espace de rédaction) aboutissent parfois à des modifications relativement importantes.
Le résultat est que les dépêches doivent d'une certaine façon, mieux suivre la ligne éditoriale du site et s'en tenir aux standards existants.
De plus, l'existence d'un espace de rédaction qui permet de stocker un travail en cours, encourage à utiliser cette fonctionnalité, et donc à travailler sur des contenus longs, en y passant plus de temps. Pour les journaux il n'y a rien de tel, ça doit donc être rédigé en cuelques minutes et en une seule fois.
Les journaux permettent un style et des sujets plus personnels. Rien qu'en voyant l'avatar en haut, on sait un peu à quoi s'attendre.
En résumé (le "c'est trop long j'ai pas lu" comme on dit): l'interface utilisateur influe sur l'usage qui est fait du site, et inversement.
Globalement, le système fonctionne bien, la plupart des dépèches finissent quand même par être publiées, même si certaines prennent pas mal de temps.
Certaines sont menées par une seule personne ou un petit groupe. Mais même dans ce cas là, les "petites" contributions et relectures sont bonnes à prendre pour améliorer le contenu avant qu'il arrive entre les mains de la modération (j'espère que vous ne m'en voulez pas trop pour mes textes de 10 kilomètres sur Haiku ou les évolutions du langage C).
Il y a quand même des choses qui ont pas trop mal fonctionné. Récemment j'ai en tête les bonnes résolutions de début d'année, et avant ça, une lecture collective d'un livre sur C++ qui je pense a été enrichissante pour les participants à la rédaction, peut-être plus que pour les lecteurs? Effectivement dans ces cas là, il y a une personne qui a pris les choses en main.
D'autres cas où ça se passe moins bien: les dépêches entamées suite au décès d'une personalité de l'informatique: la meilleure solution serait de préparer ce genre de dépêche à propos de personne encore vivantes. Mais je trouve ça intéressant d'avoir des portraits un peu élaborés et un retour en détail sur l'oeuvre accomplie. C'est incompatible avec la publication dans l'actualitédes évènements.
Enfin je pense à une autre dépêche qui a eu une gestaion difficile, celle sur la voiture qui n'aimait pas la glace à la vanille. Elle a empilé deux problèmes: un abandon par l'initiateur de la dépêche, et l'objectif initial était de faire une traduction d'un texte existant, mais le texte initial s'est avéré mal sourcé et peu fiable. Malgré tout, je crois que le résultat était intéressant.
Il reste le problème des textes abandonnés en cours de route, et de ceux où quelqu'un (je crois que c'st souvent la même personne) dépose trois liens en vrac puis disparaît sans laisser de traces. OsDans ces cas là, je pense effectivement qu'il vaut mieux, soit publier en l'état, soit supprimer le truc si personne ne s'empare du sujet. La prochaine fois, postez un lien ou un journal pour lancer les débats, ce sera plus intéressant.
Voilà, c'était mun retour personnel pour les dépêches auxquelles j'ai plus ou moins participé.
Il semble qu'on peut toujours utiliser Bird.Makeup pour suivre Twitter depuis le Fediverse (bon il faut donc avoir un moyen de consulter du ActivityPub, mais ça peut se faire sans compte je pense?):
Oui, bien sûr, la raison pour utiliser Windows est que j'ai besoin de plein d'autres outils, dont certains non libres.
Par exemple:
atfblast, pour programmer des composants PAL/GAL (ATF22v10 et ATF16v8) dans mon cas (libre mais pas maintenu, disponible uniquement pour Windows, la version qui fonctionne pour Windows 7 est déjà patchée par rapport à l'original qui ne fonctionne que sous Windows 98 et les versions antérieures). Un jour j'en ferai une version pour Haiku, le code est disponible et ça ne devrait pas être trop compliqué à adapter.
L'IDE et la toolchain SunPlus unSP pour compiler des choses pour la console VTech V.Smile (basé sur uen vieille version de GCC, donc en théorie ça devrait être libre, mais SunPlus ne diffuse pas les sources. Je suis en train de porter VBCC pour remplacer tout ça de toutes façons).
Parfois des outils pour débloquer/rooter des téléphones (ça dépend du modèle de téléphone, dans certains cas ça se fait mieux avec des outils pour Linux, parfois pas).
Ça c'est pour mes projets du moment, il y en a quelques autres dans le même style. Et donc je n'ai pas envie d'ajouter encore un système Linux supplémentaire car c'est déjà assez compliqué comme ça avec 2 machines. Ce qui fait que, beaucoup de choses que je pourrais faire sous Linux (mais pas sous Haiku) se retrouvent sur cette même machine avec Windows pour l'instant. Ça m'oblige à utiliser Haiku pour le maximum de choses, avec Linux ça ne marcherait pas aussi bien car il est pas aussi compliqué que ça :)
Le français est un langage compliqué et plein de dette technique, surtout à l'écrit. Il y a des gens pour qui c'est "naturel" ou "logique" et d'autres pas du tout. Ça n'empêche pas d'avoir des compétences dans plein d'autres domaines.
On peut discuter de la pertinence des outils choisis pour améliorer les choses, mais ça ne me semble pas très constructif d'être condescendant comme ça?
J'ai peut-être déjà vu un système de ce type sur un site francophone partageant des informations sur les logiciels libres qui porte le nom d'un noyau de système d'exploitation très connu, mais j'ai oublié de quel site il s'agit.
[^] # Re: Lunduke
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien MS-DOS 4.0 Source Code Fails to Compile. Évalué à 3 (+1/-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 (+10/-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 (+11/-0).
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 (+5/-0).
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 (+2/-0).
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: le titre m'a trompé !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche L’auteur de Nginx enfourche le proprio. Évalué à 6 (+4/-0).
Je crois que "schismer" n'existe pas encore, mais ça peut s'envisager.
Il y a aussi "mitose" si on va chercher du côté de la biologie, mais lui non plus n'a pas de forme verbale à ma connaissance?
[^] # Re: le titre m'a trompé !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche L’auteur de Nginx enfourche le proprio. Évalué à 10 (+10/-0).
Surtout qu'on pourrait utiliser une traduction plus appropriée de "fork", comme par exemple "bifurquer" ou "embrancher". Ou alors un mot utilisé dans d'autres contextes pour plus ou moins la même idée, comme "essaimer", "fissionner", "scissionner"… Les choix ne manquent pourtant pas, c'est dommage d'utiliser un mot qui finalement n'est qu'un anglicisme masqué par une mauvaise (volontairement ou pas) traduction littérale?
[^] # Re: Yacy
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Stract, un moteur de recherche libre codé par un Danois sur son temps libre. Évalué à 3 (+1/-0).
Je rajoute Marginalia à la liste des moteurs de recherche dont le code est libre (AGPL): https://search.marginalia.nu
[^] # Re: Mes 22 centimes...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l’espace de rédaction Linuxfr. Évalué à 7 (+5/-0).
Les dépêches mettent beaucoup moins en avant l'auteurice (son avatar n'est pas affiché par exemple), et le passage en modération (ou les interventions d'autres contributeurs dans l'espace de rédaction) aboutissent parfois à des modifications relativement importantes.
Le résultat est que les dépêches doivent d'une certaine façon, mieux suivre la ligne éditoriale du site et s'en tenir aux standards existants.
De plus, l'existence d'un espace de rédaction qui permet de stocker un travail en cours, encourage à utiliser cette fonctionnalité, et donc à travailler sur des contenus longs, en y passant plus de temps. Pour les journaux il n'y a rien de tel, ça doit donc être rédigé en cuelques minutes et en une seule fois.
Les journaux permettent un style et des sujets plus personnels. Rien qu'en voyant l'avatar en haut, on sait un peu à quoi s'attendre.
En résumé (le "c'est trop long j'ai pas lu" comme on dit): l'interface utilisateur influe sur l'usage qui est fait du site, et inversement.
# Parlons des dépêches qui fonctionnent
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l’espace de rédaction Linuxfr. Évalué à 10 (+9/-0).
Globalement, le système fonctionne bien, la plupart des dépèches finissent quand même par être publiées, même si certaines prennent pas mal de temps.
Certaines sont menées par une seule personne ou un petit groupe. Mais même dans ce cas là, les "petites" contributions et relectures sont bonnes à prendre pour améliorer le contenu avant qu'il arrive entre les mains de la modération (j'espère que vous ne m'en voulez pas trop pour mes textes de 10 kilomètres sur Haiku ou les évolutions du langage C).
Il y a quand même des choses qui ont pas trop mal fonctionné. Récemment j'ai en tête les bonnes résolutions de début d'année, et avant ça, une lecture collective d'un livre sur C++ qui je pense a été enrichissante pour les participants à la rédaction, peut-être plus que pour les lecteurs? Effectivement dans ces cas là, il y a une personne qui a pris les choses en main.
D'autres cas où ça se passe moins bien: les dépêches entamées suite au décès d'une personalité de l'informatique: la meilleure solution serait de préparer ce genre de dépêche à propos de personne encore vivantes. Mais je trouve ça intéressant d'avoir des portraits un peu élaborés et un retour en détail sur l'oeuvre accomplie. C'est incompatible avec la publication dans l'actualitédes évènements.
Enfin je pense à une autre dépêche qui a eu une gestaion difficile, celle sur la voiture qui n'aimait pas la glace à la vanille. Elle a empilé deux problèmes: un abandon par l'initiateur de la dépêche, et l'objectif initial était de faire une traduction d'un texte existant, mais le texte initial s'est avéré mal sourcé et peu fiable. Malgré tout, je crois que le résultat était intéressant.
Il reste le problème des textes abandonnés en cours de route, et de ceux où quelqu'un (je crois que c'st souvent la même personne) dépose trois liens en vrac puis disparaît sans laisser de traces. OsDans ces cas là, je pense effectivement qu'il vaut mieux, soit publier en l'état, soit supprimer le truc si personne ne s'empare du sujet. La prochaine fois, postez un lien ou un journal pour lancer les débats, ce sera plus intéressant.
Voilà, c'était mun retour personnel pour les dépêches auxquelles j'ai plus ou moins participé.
[^] # Re: Terrible Maps
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Making a PDF that’s larger than Germany. Évalué à 2 (+0/-0).
Il semble qu'on peut toujours utiliser Bird.Makeup pour suivre Twitter depuis le Fediverse (bon il faut donc avoir un moyen de consulter du ActivityPub, mais ça peut se faire sans compte je pense?):
https://bird.makeup/@TerribleMaps
# Problème connu depuis longtemps
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment compromettre Bitlocker sur TPM en 43 secondes avec un Raspberry Pi à moins de 10$ 😇. Évalué à 9.
Une page détaillée expliquant le fonctionnement de cette attaque, qui date de 2021:
https://blog.scrt.ch/2021/11/15/tpm-sniffing/
Mais bon, c'est un blog avec des photos et plein de détails, pas une vidéo youtube, alors c'est moins impressionnant, je suppose?
[^] # Re: Windows 7 vs Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faire fonctionner sous Windows 7 les applications utilisant Python 3.9. Évalué à 2.
La dernière chose dont j'ai envie, c'est de me retrouver à corriger des bugs dans un deuxième OS libre en plus de Haiku.
[^] # Re: Windows 7 vs Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faire fonctionner sous Windows 7 les applications utilisant Python 3.9. Évalué à 3.
Il y a qemu mais sans accélération. Et puis, lancer Windows en natif ou en virtualisé, ça ne change pas grand chose à mon problème.
On devrait pouvoir sans trop de difficulté porter nvmm depuis netbsd. Il faut "juste" que quelqu'un prenne le temps de s'y mettre.
[^] # Re: Windows 7 vs Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faire fonctionner sous Windows 7 les applications utilisant Python 3.9. Évalué à 6.
Oui, bien sûr, la raison pour utiliser Windows est que j'ai besoin de plein d'autres outils, dont certains non libres.
Par exemple:
Ça c'est pour mes projets du moment, il y en a quelques autres dans le même style. Et donc je n'ai pas envie d'ajouter encore un système Linux supplémentaire car c'est déjà assez compliqué comme ça avec 2 machines. Ce qui fait que, beaucoup de choses que je pourrais faire sous Linux (mais pas sous Haiku) se retrouvent sur cette même machine avec Windows pour l'instant. Ça m'oblige à utiliser Haiku pour le maximum de choses, avec Linux ça ne marcherait pas aussi bien car il est pas aussi compliqué que ça :)
[^] # Re: les ia ont massacré une partie de mon journal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Panne de l'ordinateur interne d'un Surface Allen & Heath I-live T112. Évalué à 7.
Le français est un langage compliqué et plein de dette technique, surtout à l'écrit. Il y a des gens pour qui c'est "naturel" ou "logique" et d'autres pas du tout. Ça n'empêche pas d'avoir des compétences dans plein d'autres domaines.
On peut discuter de la pertinence des outils choisis pour améliorer les choses, mais ça ne me semble pas très constructif d'être condescendant comme ça?
[^] # Re: Pourquoi pas une rubrique HS ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Quel futur vous paraît pertinent pour la rubrique « Liens » de Linuxfr ? . Évalué à 3.
J'ai peut-être déjà vu un système de ce type sur un site francophone partageant des informations sur les logiciels libres qui porte le nom d'un noyau de système d'exploitation très connu, mais j'ai oublié de quel site il s'agit.