pulkomandy a écrit 1698 commentaires

  • [^] # Re: La mienne marche encore

    Posté par  (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  (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  (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  (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  (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:

    • 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

    Posté par  (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  (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  (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  (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  (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  (site web personnel, Mastodon) . En réponse au journal De l’espace de rédaction Linuxfr. Évalué à 7 (+5/-0).

    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.

  • # Parlons des dépêches qui fonctionnent

    Posté par  (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  (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  (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 (+7/-0).

    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  (site web personnel, Mastodon) . En réponse au journal Faire fonctionner sous Windows 7 les applications utilisant Python 3.9. Évalué à 2 (+1/-1).

    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  (site web personnel, Mastodon) . En réponse au journal Faire fonctionner sous Windows 7 les applications utilisant Python 3.9. Évalué à 3 (+1/-0).

    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  (site web personnel, Mastodon) . En réponse au journal Faire fonctionner sous Windows 7 les applications utilisant Python 3.9. Évalué à 6 (+4/-0).

    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 :)

  • [^] # Re: les ia ont massacré une partie de mon journal

    Posté par  (site web personnel, Mastodon) . En réponse au journal Panne de l'ordinateur interne d'un Surface Allen & Heath I-live T112. Évalué à 7 (+5/-0).

    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  (site web personnel, Mastodon) . En réponse au sondage Quel futur vous paraît pertinent pour la rubrique « Liens » de Linuxfr ? . Évalué à 3 (+1/-0).

    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: Futur de Subversion

    Posté par  (site web personnel, Mastodon) . En réponse au journal github et subversion c'est fini (ou de l'importance d'une bonne communication). Évalué à 5 (+3/-0).

    --depth permet de ne pas récupérer l'historique. Svn permet en plus de ne pas récupérer tous les dossiers du dépôt mais seulement une sous-arborsescence. Ce qui pourrait régler tous les débats sur les "monorepos contre submodules" dans git et les outils comme google repo pourgérer ces problématiques

  • [^] # Re: Futur de Subversion

    Posté par  (site web personnel, Mastodon) . En réponse au journal github et subversion c'est fini (ou de l'importance d'une bonne communication). Évalué à 6 (+4/-0).

    J'ai vu des entreprises ou svn était utilisé pour gérer une base de documents (pas du code). En gros ça permettait de facilement synchroniser un dossier avec tous les documents sur son PC pour l'avoir sous la main, et de signaler (mais pas de résoudre) les conflits d'édition.

    C'était utilisé par des gens pas forcément très techniques, via une interface graphique (tortoisesvn par exemple).

    Au delà des fonctions manquantes dans git (par exemple: la possibilité de "verrouiller" un fichier pendant qu'on l'édite), le problème avec git serait surtout qu'il est trop compliqué: branches locales et distantes et plein d'autres concepts, qui en plas ne sont pas forcément bien exposés dans les interfaces graphiques. Ça ne marcherait donc pas du tout aussi bien dans cet usage.

  • [^] # Re: Pourquoi pas une rubrique HS ?

    Posté par  (site web personnel, Mastodon) . En réponse au sondage Quel futur vous paraît pertinent pour la rubrique « Liens » de Linuxfr ? . Évalué à 6 (+5/-1).

    ça fera probablement plus de boulot en modération, notamment pour déplacer des journaux et des liens vers la rubrique HS. Mais vu que cette rubrique sera un fourre-tout, donc un appeau à trolls, nul doute qu'il y aura beaucoup de dérapages, dont certains relevant du pénal

    faut des volontaires pour mettre la main à la pâte. Tout dépend du niveau de complexité de la modification, du nombre de doigts et du temps de cerveaux disponibles pour taper du code

    Maissoyons sérieux, personne ne vient sur Linuxfr en se disant "tiens, et si j'allais chercher des liens qui ne parlent surtout pas de Linux et encore moins de logiciels libres?"

    Non, ce qu'il faudrait c'est un moyen de masquer les contenus pas intéressants, parce cu'ils sont hors sujet, ou de mauvaise qualité (c'est à dire, par exemple, tellement mal rédigés qu'on y comprend rien). On pourrait mettre en place quelque chose pour indiquer si un contenu est pertinent, et qu'on veut en lire plus, ou inutile, et on voudrait que l'auteur perde son temps d'une autre façon. Et on pourrait faire confiance à l'intelligence gollective des visiteurs du site pour utiliser ce système à bon escient et ainsi avoir une sorte de ligne éditoriale qui émerge par elle-même et qui peut évoluer au cours du temps, le tout, sans donner de travail supplémentaire à l'équipe de modération.

    Je suis sûr que cette idée va déclencher beaucoup de débats, mais il faudrait au moins essayer pour voir ce qui en ressort?

  • [^] # Re: Edge vs Chrome

    Posté par  (site web personnel, Mastodon) . En réponse au lien Terrible Maps : The most popular browser 2012 vs 2022. Évalué à 5 (+3/-0).

    Que la plupart des gens n'ont pas vu la différence une fois mis devant le fait accompli

    C'est probablement ça, la plupart des gens ne font pas trop la différence entre "internet", "web", "navigateur" et "moteur de recherche". Donc, un navigateur qui s'installe tout seul, il va rester chez eux sans problème.

    Mozilla avait réussi à contrer ça avec de l'innovation (pas des trucs forcément très compliqués, par exemple, des onglets, un système de restauration de session, …) qui apportaient une grosse plus-value par rapport à la concurrence. Actuellement ce n'est plus trop le cas. Mais ça peut rechanger si Chrome se met trop sérieusement à empêcher les bloqueurs de publicités, par exemple.

  • [^] # Re: L'informatique c'est vaste

    Posté par  (site web personnel, Mastodon) . En réponse au journal [Trolldi] La Big Tech vous souhaite une très belle réflexion existentielle. Évalué à 9 (+7/-0).

    au final il y a eu plus de gain que de perte au niveau des employés.

    Au niveau financier, peut-être, mais démarrer un nouveau job dans l'informatique ça demande un investissement mental qui n'est pas remboursable. Et perdre ce job vec un préavis court àun moment ou plusieurs milliers d'autres personnes sont en même temps remise sur le marché du travail, c'est pas beaucoup mieux.

  • [^] # Re: garder la rubrique, imposer une petite description

    Posté par  (site web personnel, Mastodon) . En réponse au sondage Quel futur vous paraît pertinent pour la rubrique « Liens » de Linuxfr ? . Évalué à 8 (+7/-1).

    Je trouve ça pas plus mal que le commentaire de la personne ayant posté le lien soit séparé du lien lui-même. On peut en conséquence commenter et pertinenter/inutiler l'un indépendament de l'autre.

    On peut aussi ne pas lire les commentaires quand on a pas le temps.

    Ça habitue/encourage aussi les gens à mettre des étiquettes plutôt qu'un commentaire et on a donc une belle base de liens organisés parcatégories et qu'on peut retrouver si besoin sans trop de mal. C'est malheureusement beaucoup moins le cas pour les autres contenus. Vu l'état actuel des moteurs de recherche dont on dépend beaucoup (résultats pleins de pages inutiles générées par des LLMs), c'est peut-être dommage que les autres contenus ne soient pas aussi bien rangés.