On a donc une association qui s'approche du demi million de dollars en réserves, et qui paie un seul ingénieur à $25000 par an, ce qui est non seulement loin d'être compétitif, mais même loin d'être la moitié d'un salaire compétitif pour un ingénieur aux USA.
Alors, on peut faire du marketing en disant que c'est mieux que Mozilla qui paie un CEO à plusieurs fois le budget annuel de Haiku, mais d'un autre côté, peut-être ce serait bien de dépenser un peu plus de sous pour que le projet avance un peu plus vite?
Cela dit, les dépenses sont raisonnables par rapport aux recettes. Il y aurait une possibilité d'embaucher une deuxième personne en dépensant les sous en réserves pendant quelques temps, et en espérant que cela donne une grosse impulsion au projet pour multiplier les dons (par 2 ou 3) et que l'opération soit équilibrée sur le moyen terme. Donc on peut voir ça comme une gestion saine et prudente?
Il y a aussi le fait que l'association Haiku inc est conçue pour avoir un rôle "passif" dans le financement: elle reçoit les dons, et elle les distribue à la demande des développeurs du projet (avec un peu de contrôle pour ne pas payer n'importe quoi). Ce sont les contributeurs du projet qui doivent prendre l'initiative de demander des sous. Il y a donc peu d'initiatives pour développer des choses qui n'existent pas ou peu (comme le marketing).
Enfin, le projet étant loin d'être abouti, je n'ai pas encore bien réfléchi à l'archivage de ces fichiers pour les siècles des siècles. Faut-il faire un dépôt sur une forge comme Codeberg ? Ou les déposer sur un site comme Wikimedia Commons ? Un par un :-( ? Quelle est votre opinion ? Avez-vous d'autres idées ?
C'est le genre de chose qui a tout à fait sa place chez https://archive.org, je pense?
La situation est toujours la même à ma connaissance: les bitcoins sont toujours chez Coinbase, et comme les dons et réserves en vrai argent sont suffisants, ce n'est pas vraiment la priorité du moment de gérer ça.
On pourra en rediscuter lors de la puplication du prochain rapport financier de Haiku inc en début d'année prochaine. Pour l'instant il est plus intéressant de regarder le compteur de dons de cette année qui n'a pas encore dépassé les 20000$ sur un objectif de 30000$ (on sent l'effet de l'absence de release ainsi que le fait qu'on a pas été retenu pour le Google summer of code). La générosité de fin d'année permettra-t-elle d'atteindre tout de même l'objectif, et ce malgré l'absence complète de communication pour lancer une campagne de dons? (Pour être tout à fait honnête, il y a sunrement d'autres projets qui sauront dépenser votre argent mieux et plus vite que Haiku)
Probablement, car ce sont les mêmes technologies, et les cartes SD aussi.
Cependant, la densité de données est moindre sauf si la clé USB en question fait 1To), les transistors sont plus gros, et ils utilisent moins de niveaux de chare (un transistor va stocker 2 bits avec 4 valeurs de charge différentes, mais pas 3 bits avec 8 valeurs de charge). Ce qui laisse un peu plus de marge.
Sur les SSD les plus modernes, la différence entre un bit à 0 ou à 1 c'est un assez petit nombre d'électrons.
Pour les cartes SD au moins, il existe des cartes "industrielles" avec de la flash SLC (un seul bit par transistor) qui devraient mieux résister que les autres.
Donc oui, sur les versions 32 bit (x86 gcc2) il n'y a pas de navigateur "moderne" maintenu à cause des problèmes d'allocation mémoire mentionnés, et ce sera réparé dans la phase de préparation de la beta 6 au moins pour WebPositive (je ne maintiens pas les porages de Iceweasel, donc je ne sais pas si ils pourront aussi être mis à jour).
De toutes façons, même si Haiku lui-même continue le support 32-bit, on est en train de voir apparaître de plus en plus d'applications qui refusent de le faire (pour des raisons valables parfois). Ce qui va forcément réduire l'intérêt de cette version 32bit.
Iceweasel est disponible dans HaikuDepot depuis quelques mois et relatiâement à jour. Il ne s'appelle ps Firefox parce qu'il n'est pas compilé par Mozilla, mais c'est le même code. Il y a également plusieurs forks (waterfox et librewolf, il me semble).
Pour WebPositive, le moteur WebKit est maintenu régulièrement à jour avec ce qui est utilisé par Apple, GTK et Sony. Par contre, toutes les fonctionalités qui demandent du code spécifiques (gestion des gamepads, géolocalisation, lecture de vidéos, …) ne sont pas toutes activées, il faut le faire au cas par cas et actuellement j'ai pas trop le temps de m'en charger (et les contributions se bousculent pas).
Le tout n'est actuellement pas disponible sur en 32bit parce que l'allocateur mémoire utilisé dans haiku r1beta5 est trop innefficace (ça plante pendant la compilation). Il a été remplacé entretemps donc on pourra reprendre les mises à jour avec la sortie de la beta 6. Pas de problèmes pour l'instant pour la version 64 bits…
J'ai mal posé une question : ton rapport trimestriel liste les travaux de ce trimestre, mais est-ce que certains de ces travaux ont par exemple duré 10 mois ?
Je ne crois pas pour ce trimestre, ça arrive parfois et dans ce cas j'essaie de le mentionner (j'espère qu'on pourra bientôt parler du redimensionneur de partitions BFS, pour lequel le travail a commencé en 2014 pendant le Google Summer of Code mais n'a pas pu être terminé à l'époque).
Au fait où en sont les travaux sur le portage RiscV ?
Il n'y a plus de travaux puisque c'est fini :)
Une machine RISC-V tourne en continu pour compiler les paquets de Haikuports pour RISC-V. Il est possible qu'on l'ajoute à la liste des architectures supportées pour la beta 6 ou la 7.
Vu que vos versions Alphas étaient déjà stables et qu'après bientôt 30 ans plus personne ne comprend la numérotation de BeOS, vous pourriez aussi bien nommer les prochaines Bétas en v1, v2, etc.
Je ne sais pas si je suis trop exigeant avec mon système ou si les autres personnes sont beaucoup trop tolérantes aux pannes.
Sur ma machine, les kernel panics sont relativement fréquents (disons entre une fois par semaine et une fois par mois). Les retours de personnes qui essaient vraiment sérieusement d'utiliser Haiku (pas juste pour s'amuser) sont similaires: par exemple les développeurs de NetSurf qui essaient de l'intégrer dans leur système d'intégration continue ont remonté plusieurs problèmes, certains que l'on a pu corriger, d'autres pas encore.
Changer la numérotation des versions ne règlera pas ces problèmes. Ce serait donc malhonnête envers les utilisateurs et un risque de se prendre une volée de bad buzz.
De plus, nous sommes actuellement incapables de livrer des versions au moins tous les ans comme ça devrait être le cas (pour des problèmes de process de développement, de changements qui causent des régressions, d'absence de tests automatisés, …). Souvent, les logiciels en cours de développement utilisent des fonctionnalités disponibles uniquement dans les versions "nightly build" et sont donc en incapacité de livrer des versions fonctionnant sur la dernière release publiée. On peut se permettre ce genre de fantaisie pour un système en beta, mais pas pour quelque chose qu'on encourage les gens à utiliser comme leur système principal auquel confier tout leur travail. Il faut donc au moins qu'on travaille sur ce process de livraison, notre façon de gérer les branches de développement, et tout ça. Des choses qui prendraient du temps et ralentiraient encore le développement. On a pas vraiment les ressources pour se le permettre.
En gros, pour moi, la version 1 de Haiku, ce sera quand je me sentirai prêt à l'installer par exemple chez mes parents (qui ne sont pas de grand spécialistes de l'informatique) et à ne pas avoir à intervenir pour réparer des choses. On est loin du compte, mais en attendant, ça n'empêche pas de l'utiliser pour des personnes avec un profil un peu plus "bricoleur" ou habitués à se débrouiller avec un ordinateur un peu déréglé. Ce que je fais d'ailleurs moi-même. Ce n'est donc pas important que cette version arrive un jour ou pas. L'important c'est que chaque version soit mieux que la précédente, que les quelques utilisateurs existants soient satisfaits, et qu'on en récupère quelques nouveaux de temps en temps.
On peut lancer un terminal sans serveur graphique via le pilote consoled, qui utilise la même méthode d'affichage que le debugger noyau et le debugger de l'espace utilisateur quand un service plante.
Cette console est lente, très incomplète, et globalement inutilisable à part pour dire "oui, techniquement c'est possible".
Ce qui fait le succès de Arduino, ce n'est pas la vente de matériel, c'est l'écosystème logiciel autour: une bibliothèqe standard facile à utiliser et portableur de nombreux modèles de cartes et de microcontrôleurs, un IDE pratique avec de la programmation facile (on branche un port usb et ça juste marche). Ça permet d'aller assez loin dans lwélectronique sans jamais toucher un fer à souder ou un datasheet de composant.
il y a une dizaine d'années, beaucoup de cartes et de microcontrôleurs étaient vendus sans un tel support, les fabricants vendaient juste le matériel et laissaient le soin à d'autres (Keil, IAR, …) de fournir les compilateurs et environnements de développement, et aux acheteurs des composants de se développer leurs propres bibliothèques. Maintenant ils ont pour la plupart compris l'intérêt de proposer une olution complète et des outils de développement accessibles gratuitement (ou encore mieux, libres). Et c'est un peu cette partie là qui fait toute la valeur d'un microcontrôleur aujourd'hui, alors que c'est celle qui n'est pas vendue (on paie le matériel, mais le choix d'un composant plutont qu'un autre va se faire surtout sur le logiciel disponible)
Il n'y a pas forcément de ligne directrice. Du point de vue de la qualité du code, un processus de revue existe depuis très longtemps, au départ c'était fait via une mailing list et après l'envoi de commits (c'était la façon la plus simple de procéder avec SVN), aujourd'hui, cela passe par Gerrit avec une revue avant commit. L'inconvénient est que parfois c'est un peu trop exigeant et c'est difficile d'intégrer un changement qui n'est pas parfait, cela peut décourager certains contributeurs.
Du côté de l'interface graphique, il y a un document "Haiku interface guidelines", mais c'est vrai qu'il y a une attention aux détails. C'est peut-être plus facile de se consacrer à ça quand le gros de l'interface a très peu changé depuis 25 ans, que pour d'autres projets qui sont un peu dans un changement continu de technologie ou de thèmes ou d'objectifs?
La roadmap avance doucement. Pour s'en rendre compte on peut regarder année par année:
Il faut noter que les tickets résolus sont déplacés vers la beta "en cours" au moment de la résolution. Chaque version beta reçoit plusieurs centaines de corrections, mais de nouveaux problèmes sont également découverts. Donc le nombre de tickets dans l'objectif "R1" baisse beaucoup plus doucement (mais ça baisse quand même). Si on garde le même rythme de -120 tickets tous les 4 ans (environ 30 par ans), on devrait voir la version R1 d'ici environ 18 ans.
Il s'agit d'un rapport trimestriel qui liste les avancées de ces 3 derniers mois uniquement. Pour les 3 mois précédents il faut regarder le rapport précédent, et ainsi de suite. L'équipe est toujours assez réduite (un développeur salarié, une grosse poignée de contributeurs sur leur temps libre, et quelques personnes qui participent de façon plus occasionelle). Cette année, on a entre 7 et 22 contributeurs chaque mois avec un total de 44 personnes différentes sur l'année (la dernière année où il y a eu aussi peu de monde, c'était en 2010, et les chiffres pour 2010 et avant sont faussés parce que on utilisait encore SVN qui ne préservait pas l'auteur pour les contributions externes). On est donc plutôt en effectif réduit par rapport à d'habitude, avec un seul contributeur qui réalise a lui tout seul plus de la moitié des commits (c'était le cas l'an dernier pour la première fois, jusque là, les choses étaient beaucoup plus réparties, mais il n'y avait pas un contributeur salarié à plein temps). Avec environ 1000 à 1500 commits par an, on est loin du record de 2009 ou on avait dépassé 5500 commits. Cependant, les changements de mode de revue du code font que les changements ont tendance à apparaître sous forme d'un seul commit bien testé et finalisé, au lieu de multiples petits changements et correctifs.
On peut aussi regarder du côté de Haikuports, les courbes se sont croisées avec l'introduction en 2012 du gestionnaire de paquets, et on voit beaucoup d'activité sur le portage et le développement de logiciels, plutôt que sur le système lui-même.
Ça fait longtemps que ce n'est plus du tout rentable de miner du bitcoin avec une carte graphique, il existe maintenant des puces dédiées exclusivement à cet usage qui sont (un peu) moins gourmandes en énergie
(c'était une plaisanterie, plus personne n'a de chaîne hifi ni de CD à écouter avec, et je suis prêt à parier qu'on pourra très facilement envoyer le son de Spotify en MP3 compressé vers une enceinte Bluetooth avec un protocol de compression audio avec perte, en utilisant la Steam Machine).
Peut-être que j'aurais plutôt du parler d'une sortie péritel pour éviter tout risque d'être pris au sérieux?
Ça veut aussi dire que le mot de passe se retrouve dans le buffer du terminal, qui potentiellement se retrouve swappé et donc enregistré sur le disque dur, où on peut le récupérer une fois la machine éteinte (ou de façon sûre, en mettant la machine en hibernation prolongée). Normalement on fait attention que les mots de passe ne soient stockés que dans des zones non enregistrables sur disque et de bien l'effacer avant de libérer la mémoire en question.
Tu noteras que les problèmes du C sont connus, bien documentés et malgré tout avec les années on a toujours un taux de faille élevé dans un domaine qui pourrait être réduit à presque zéro dans d'autres langages.
Il peut être réduit à strictement zéro, en fait, avec des environnements à machine virtuelle comme LISP (dont les supporters ralaient dans le;années 60 sur les développeurs utilisant des langages compilés unsafe avec exactement les mêmes arguments que les supportes de Rust utilisent aujourd'hui) ou SmallTalk. La raison pour laquelle ça n'a pas pris, c'est qu'il y avait un coût en performances relativement important. Rust a fait tomber cette limite (et encore, je vais faire grincer des dents des développears Ada en disant ça).
Je développe moi aussi beaucoup de C++, mais il faut arrêter d'essayer de présenter les inconvénients du langage (pas memory safe, pas de système de build standardisé, pas d'outil de gestion des dépendances, par de règle de formattage et de nommage standardisées) comme des avantages.
Avec Cargo, on peut récupérer plein de bibliothèques bien implémentées pour tout un tas de trucs,et personellement j'ai tendance à avoir plus confiance dans ces bibliothèques oue dans ma capacité (ou celle de mes collègues) à réimplémenter les choses de façon sécurisée et avec de bonnes performances. Et puis en plus, j'ai autre chose à faire que développer pour la 72000ème fois un arbre binaire ou une autre structure de base…
mise-a-jour par les mainteneurs de ta distribution Linux,
Je ne vois pas trop bien pourquoi on fait une confiance aveugle aux distributions Linux mais pas à Cargo. Par exemple, Arch avec AUR ne fait pas mieux d'un point de vue validation de la sécurité des dépendences incluses? Qu'en est-il de Debian par exemple? Si Debian package une bibliothèque avec des failles de sécurité, volontairement ou non, qu'est-ce que ça change par rapport à une vulnérabilité arrivée par Cargo? Est-ce que Debian a un process de relecture complète du code de chaque version des logiciels qu'ils packagent pour que tu n'aies pas besoin de le faire? Je ne crois pas. Tout ça repose sur de la confiance.
Surtout que les dépendances dans les projets Rust ne se mettent pas à jour toutes seules dans le dos des développeurs, il faut faire soi-même la montée en version (et vérifier au moins que cela fonctionne bien).
Et puis quand ta distribution ne package pas le logiciel dont tu as besoin, en C ou C++, tu te retrouves avec… ben rien du tout pour faire le suivi, il faut gérer ça soi-même. Et de mon expérience, ça arrive relativement souvent.
Je ne comprend pas pourquoi le débat est parti sur l'authentification pour grosboobs.com et parissportifs.fr. Le texte de départ parle de fournisseurs de mail, chat, et services de messagerie (d'ailleurs, le projet s'appelle ChatControl).
Ce qui pose d'autres problèmes, par exemple si vous hébergez un serveur IRC, est-ce que c'est à vous de vérifier l'identité des personnes se connectant à ce serveur, et comment ça se met en place dans ce cas où le protocole n'est pas vraiment prévu pour?
Je confirme: on a beau mettre en places tous ces trucs, le nombre de bugs causés par une mauvaise gestion de la mémoire reste important (sans forcément parler de failles de sécurité, à ma connaissance personne n'en a trouvé dans le projet). On a plutôt de bêtes déréférences de pointeurs null, des use after free, ou des hroblèmes de partage de données entre threads.
Je ne suis pas développeur dans le noyau Linux et si je peux éviter de faire du C, j'en suis très content. Je n'ai donc pas de "il faudrait" à leur donner ou personne à convaincre. Siequelqu'un proposait l'intégrationde code Rust dans un projet auquel je participe (disons: Haiku), ça ferait par contre partie des questions que je vais poser afin de me faire un avis sur la question [il y en aurait plein d'autre, par exemple dans le cas de Haiku ce serait un problème pour le portage motorola 68000 qu'il faudrait officiellement abandonner dans l'état actuel des toolchains Rust). J'ai juste posé une question: quels sont les motifs utilisés dans le code du noyau Linux qui ne se prêteraient pas à un interfaçage avec Rust?
Avec une réponse à cette question, je pourrais apprendre des choses sur les limites de Rust et sur d'autres façons de gérer la mémoire, ou juste redécouvrir des façons de faire auxquelles je n'ai pas pensé. Ou peut-être que ce sema l'occasion de découvrir une interface qui est, en fait, mal définie. Je sais que dans Haiku, on a plein d'endroits où la resposabilité de libérer de la mémoire pointée par un pointeur est implicite et pas documentée, et il faut aller lire le code source pour vérifier, et en plus ce n'est pas forcément cohérent d'un objet à l'autre. Bien sûr c'est un problème qui peut être résolu oe plein de façons: avec du C++ "moderne" et des smart pointers, avec de la documentation, avec des outils d'analyse statique, … mais l'approche de Rust de vérifier ça à la compilation semble quand même être une très bonne idée?
La différence est entre "on peut avoir des interfaces bien définies" dans un autre langage et Rust oblige à avoir des interfaces bien définies (par exemple pour indiquer qui est propriétaire de la mémoire et responsable de la libération, ou assurer la synchronisation entre threads). Oui bien sûr c'est contraignant et parfois ça empêche de faire des choses qui pourraient très bien |onctionner par ailleurs. De la même façon que le C n'a pas de coroutines (alors que c'est facile en assembleur) ou que le C++ ne permet pas de modifier la vtable d'un objet à la volée pendant l'exécution (alors que c'est tout à fait possible en smalltalk, ou si on implémente des vtables en C à la main). Ce sont bien évidement des choix pour contraindre les choses à fonctionner d'une certaine façon: une exécutioneavec une pile d'appel unique par thread, des possibilités d'optimisation des appels de méthodes, par exemple.
La qaestion oevient donc: en pratique, quelles sont les fonctions du noyau Linux qui ont une interface bien définie (en terme de gestion de la mémoire et des threads), mais une approche "inhabituelle" qui fait que ça ne peut pas s'interfacer avec du Rust?
Il me semble que la difficulté de sudo est que cwst un hrogramme complexe avec beaucoup de fonctionnalités (pas forcément souvent utilisées). Par exemple on peut autoriser un utilisateur à lancer seulement certaines commandes avec sudo.
L'outil concurrent doas prend le parti de retirer certaines fonctionnalités pour que le code critique exécuté avec des privilèges élevé reste le plus simple possible. Alors que sudo-rs semble vouloir conserver toute les fonctionnalités.
Moi j'ai mis un 429 (too many requests) qui m'a semblé approprié (IA ou pas, je surveille les statistiques du site une fois de temps en temps et je bannis des range d'IP à la main si ils génèrent trop de requêtes).
Si on veut conserver la version original, alors il garder les couleurs d'origine mais en les considérant dans l'espace de couleurs imposé par les films de l'époque.
La difficulté est surtout de savoir quelles étaient les couleurs originales lors de la sortie du film. Si toutes les copies originales en 35mm avaient été détruites, comment ferait-on pour le savoir? Et ces copies se dégradent avec le temps, bien sûr.
Il y a donc plusieurs questions:
Comment conserver une trace de quelles étaient les couleurs que les gens ont vu lors de la sortie au cinéma,
Comment reproduire au mieux ces couleurs sur une copie numérique moderne,
Pourquoi Disney+ a choisi de ne pas le faire et de sortir une version visuellement très différente
Et c'est important parce que ces couleurs peuvent complètement changer la perception du film. On passe d'un truc qui peut avoir l'air presque réaliste à une copie numérique en HD où on se rend beaucoup plus compte que les modèles 3D sont relativement simples et peu texturés, par exemple. La version en film 35mm permettait de gommer plein de choses et de faire en sorte que la magie opère et qu'on oublie un peu le rendu 3D finalement pas si bon que ça. Et c'est quelque chose auquel l'équipe qui a réalisé le film a réfléchi, c'est donc un choix de leur part qu'il convient de préserver dans certains cas.
C'est loin d'être la seule oeuvre pour laquelle c'est le cas. Par exemple, la série originale Star Trek a été filmée et montée en 35mm, mais en ayant en tête que ce serait diffusé à la télévision, avec une définition d'image assez faible. Les trucages qui fonctionnaient relativement bien à l'époque ne fonctionnent donc pas du tout pour une version en haute définition (on voit toutes les ficelles). Le choix qui a été fait dans ce cas, c'est de refaire tous les effets spéciaux en images de synthèse pour la sortie en Blueray de la série (et autres canaux de diffusion en HD). Mais c'est important de préserver aussi la version originale qui a été diffusée, sinon, on pourrait croire en voyant la nouvelle version, que les trucages étaient à des années-lumières devant les possibilités de l'époque où la série a été réalisée!
Et d'autre part, on sait que les grosses entreprises exploitants ces médias ne sont pas forcément les mieux placées pour assurer cette préservation historique et s'assurer que les versions originales restent facilement disponibles.
[^] # Re: Arrêter de nous gaver avec de l'IA
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Arrêter de nous gaver avec de l'IA 🤮. Évalué à 5 (+2/-0).
Ah non pas question! Quand je trolle, je le fais à la main, sinon quel est l'intérêt?
[^] # Re: Des nouvelles de vos bitcoins ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 4 (+1/-0).
L'état des finances en 2024:
On a donc une association qui s'approche du demi million de dollars en réserves, et qui paie un seul ingénieur à $25000 par an, ce qui est non seulement loin d'être compétitif, mais même loin d'être la moitié d'un salaire compétitif pour un ingénieur aux USA.
Alors, on peut faire du marketing en disant que c'est mieux que Mozilla qui paie un CEO à plusieurs fois le budget annuel de Haiku, mais d'un autre côté, peut-être ce serait bien de dépenser un peu plus de sous pour que le projet avance un peu plus vite?
Cela dit, les dépenses sont raisonnables par rapport aux recettes. Il y aurait une possibilité d'embaucher une deuxième personne en dépensant les sous en réserves pendant quelques temps, et en espérant que cela donne une grosse impulsion au projet pour multiplier les dons (par 2 ou 3) et que l'opération soit équilibrée sur le moyen terme. Donc on peut voir ça comme une gestion saine et prudente?
Il y a aussi le fait que l'association Haiku inc est conçue pour avoir un rôle "passif" dans le financement: elle reçoit les dons, et elle les distribue à la demande des développeurs du projet (avec un peu de contrôle pour ne pas payer n'importe quoi). Ce sont les contributeurs du projet qui doivent prendre l'initiative de demander des sous. Il y a donc peu d'initiatives pour développer des choses qui n'existent pas ou peu (comme le marketing).
# Internet archive
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Réanimation des tuxeries. Évalué à 6 (+3/-0).
C'est le genre de chose qui a tout à fait sa place chez https://archive.org, je pense?
[^] # Re: Des nouvelles de vos bitcoins ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 3 (+0/-0).
La situation est toujours la même à ma connaissance: les bitcoins sont toujours chez Coinbase, et comme les dons et réserves en vrai argent sont suffisants, ce n'est pas vraiment la priorité du moment de gérer ça.
On pourra en rediscuter lors de la puplication du prochain rapport financier de Haiku inc en début d'année prochaine. Pour l'instant il est plus intéressant de regarder le compteur de dons de cette année qui n'a pas encore dépassé les 20000$ sur un objectif de 30000$ (on sent l'effet de l'absence de release ainsi que le fait qu'on a pas été retenu pour le Google summer of code). La générosité de fin d'année permettra-t-elle d'atteindre tout de même l'objectif, et ce malgré l'absence complète de communication pour lancer une campagne de dons? (Pour être tout à fait honnête, il y a sunrement d'autres projets qui sauront dépenser votre argent mieux et plus vite que Haiku)
[^] # Re: Clés USB
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les SSD non alimentés dans votre tiroir perdent lentement leurs données. Évalué à 7 (+4/-0).
Probablement, car ce sont les mêmes technologies, et les cartes SD aussi.
Cependant, la densité de données est moindre sauf si la clé USB en question fait 1To), les transistors sont plus gros, et ils utilisent moins de niveaux de chare (un transistor va stocker 2 bits avec 4 valeurs de charge différentes, mais pas 3 bits avec 8 valeurs de charge). Ce qui laisse un peu plus de marge.
Sur les SSD les plus modernes, la différence entre un bit à 0 ou à 1 c'est un assez petit nombre d'électrons.
Pour les cartes SD au moins, il existe des cartes "industrielles" avec de la flash SLC (un seul bit par transistor) qui devraient mieux résister que les autres.
[^] # Re: plein de questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 5 (+2/-0).
Donc oui, sur les versions 32 bit (x86 gcc2) il n'y a pas de navigateur "moderne" maintenu à cause des problèmes d'allocation mémoire mentionnés, et ce sera réparé dans la phase de préparation de la beta 6 au moins pour WebPositive (je ne maintiens pas les porages de Iceweasel, donc je ne sais pas si ils pourront aussi être mis à jour).
De toutes façons, même si Haiku lui-même continue le support 32-bit, on est en train de voir apparaître de plus en plus d'applications qui refusent de le faire (pour des raisons valables parfois). Ce qui va forcément réduire l'intérêt de cette version 32bit.
[^] # Re: plein de questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 5 (+2/-0).
Iceweasel est disponible dans HaikuDepot depuis quelques mois et relatiâement à jour. Il ne s'appelle ps Firefox parce qu'il n'est pas compilé par Mozilla, mais c'est le même code. Il y a également plusieurs forks (waterfox et librewolf, il me semble).
Pour WebPositive, le moteur WebKit est maintenu régulièrement à jour avec ce qui est utilisé par Apple, GTK et Sony. Par contre, toutes les fonctionalités qui demandent du code spécifiques (gestion des gamepads, géolocalisation, lecture de vidéos, …) ne sont pas toutes activées, il faut le faire au cas par cas et actuellement j'ai pas trop le temps de m'en charger (et les contributions se bousculent pas).
Le tout n'est actuellement pas disponible sur en 32bit parce que l'allocateur mémoire utilisé dans haiku r1beta5 est trop innefficace (ça plante pendant la compilation). Il a été remplacé entretemps donc on pourra reprendre les mises à jour avec la sortie de la beta 6. Pas de problèmes pour l'instant pour la version 64 bits…
[^] # Re: plein de questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 10 (+7/-0).
Je ne crois pas pour ce trimestre, ça arrive parfois et dans ce cas j'essaie de le mentionner (j'espère qu'on pourra bientôt parler du redimensionneur de partitions BFS, pour lequel le travail a commencé en 2014 pendant le Google Summer of Code mais n'a pas pu être terminé à l'époque).
Il n'y a plus de travaux puisque c'est fini :)
Une machine RISC-V tourne en continu pour compiler les paquets de Haikuports pour RISC-V. Il est possible qu'on l'ajoute à la liste des architectures supportées pour la beta 6 ou la 7.
Je ne sais pas si je suis trop exigeant avec mon système ou si les autres personnes sont beaucoup trop tolérantes aux pannes.
Sur ma machine, les kernel panics sont relativement fréquents (disons entre une fois par semaine et une fois par mois). Les retours de personnes qui essaient vraiment sérieusement d'utiliser Haiku (pas juste pour s'amuser) sont similaires: par exemple les développeurs de NetSurf qui essaient de l'intégrer dans leur système d'intégration continue ont remonté plusieurs problèmes, certains que l'on a pu corriger, d'autres pas encore.
Changer la numérotation des versions ne règlera pas ces problèmes. Ce serait donc malhonnête envers les utilisateurs et un risque de se prendre une volée de bad buzz.
De plus, nous sommes actuellement incapables de livrer des versions au moins tous les ans comme ça devrait être le cas (pour des problèmes de process de développement, de changements qui causent des régressions, d'absence de tests automatisés, …). Souvent, les logiciels en cours de développement utilisent des fonctionnalités disponibles uniquement dans les versions "nightly build" et sont donc en incapacité de livrer des versions fonctionnant sur la dernière release publiée. On peut se permettre ce genre de fantaisie pour un système en beta, mais pas pour quelque chose qu'on encourage les gens à utiliser comme leur système principal auquel confier tout leur travail. Il faut donc au moins qu'on travaille sur ce process de livraison, notre façon de gérer les branches de développement, et tout ça. Des choses qui prendraient du temps et ralentiraient encore le développement. On a pas vraiment les ressources pour se le permettre.
En gros, pour moi, la version 1 de Haiku, ce sera quand je me sentirai prêt à l'installer par exemple chez mes parents (qui ne sont pas de grand spécialistes de l'informatique) et à ne pas avoir à intervenir pour réparer des choses. On est loin du compte, mais en attendant, ça n'empêche pas de l'utiliser pour des personnes avec un profil un peu plus "bricoleur" ou habitués à se débrouiller avec un ordinateur un peu déréglé. Ce que je fais d'ailleurs moi-même. Ce n'est donc pas important que cette version arrive un jour ou pas. L'important c'est que chaque version soit mieux que la précédente, que les quelques utilisateurs existants soient satisfaits, et qu'on en récupère quelques nouveaux de temps en temps.
[^] # Re: Haiku : toujours incroyable
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 6 (+3/-0).
On peut lancer un terminal sans serveur graphique via le pilote consoled, qui utilise la même méthode d'affichage que le debugger noyau et le debugger de l'espace utilisateur quand un service plante.
Cette console est lente, très incomplète, et globalement inutilisable à part pour dire "oui, techniquement c'est possible".
[^] # Re: fourche ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Qualcomm tire le frein à main sur l’Open Source d’Arduino. Évalué à 6 (+3/-0).
Ce qui fait le succès de Arduino, ce n'est pas la vente de matériel, c'est l'écosystème logiciel autour: une bibliothèqe standard facile à utiliser et portableur de nombreux modèles de cartes et de microcontrôleurs, un IDE pratique avec de la programmation facile (on branche un port usb et ça juste marche). Ça permet d'aller assez loin dans lwélectronique sans jamais toucher un fer à souder ou un datasheet de composant.
il y a une dizaine d'années, beaucoup de cartes et de microcontrôleurs étaient vendus sans un tel support, les fabricants vendaient juste le matériel et laissaient le soin à d'autres (Keil, IAR, …) de fournir les compilateurs et environnements de développement, et aux acheteurs des composants de se développer leurs propres bibliothèques. Maintenant ils ont pour la plupart compris l'intérêt de proposer une olution complète et des outils de développement accessibles gratuitement (ou encore mieux, libres). Et c'est un peu cette partie là qui fait toute la valeur d'un microcontrôleur aujourd'hui, alors que c'est celle qui n'est pas vendue (on paie le matériel, mais le choix d'un composant plutont qu'un autre va se faire surtout sur le logiciel disponible)
[^] # Re: plein de questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Automne 2025. Évalué à 8 (+5/-0).
Il n'y a pas forcément de ligne directrice. Du point de vue de la qualité du code, un processus de revue existe depuis très longtemps, au départ c'était fait via une mailing list et après l'envoi de commits (c'était la façon la plus simple de procéder avec SVN), aujourd'hui, cela passe par Gerrit avec une revue avant commit. L'inconvénient est que parfois c'est un peu trop exigeant et c'est difficile d'intégrer un changement qui n'est pas parfait, cela peut décourager certains contributeurs.
Du côté de l'interface graphique, il y a un document "Haiku interface guidelines", mais c'est vrai qu'il y a une attention aux détails. C'est peut-être plus facile de se consacrer à ça quand le gros de l'interface a très peu changé depuis 25 ans, que pour d'autres projets qui sont un peu dans un changement continu de technologie ou de thèmes ou d'objectifs?
La roadmap avance doucement. Pour s'en rendre compte on peut regarder année par année:
Il faut noter que les tickets résolus sont déplacés vers la beta "en cours" au moment de la résolution. Chaque version beta reçoit plusieurs centaines de corrections, mais de nouveaux problèmes sont également découverts. Donc le nombre de tickets dans l'objectif "R1" baisse beaucoup plus doucement (mais ça baisse quand même). Si on garde le même rythme de -120 tickets tous les 4 ans (environ 30 par ans), on devrait voir la version R1 d'ici environ 18 ans.
Il s'agit d'un rapport trimestriel qui liste les avancées de ces 3 derniers mois uniquement. Pour les 3 mois précédents il faut regarder le rapport précédent, et ainsi de suite. L'équipe est toujours assez réduite (un développeur salarié, une grosse poignée de contributeurs sur leur temps libre, et quelques personnes qui participent de façon plus occasionelle). Cette année, on a entre 7 et 22 contributeurs chaque mois avec un total de 44 personnes différentes sur l'année (la dernière année où il y a eu aussi peu de monde, c'était en 2010, et les chiffres pour 2010 et avant sont faussés parce que on utilisait encore SVN qui ne préservait pas l'auteur pour les contributions externes). On est donc plutôt en effectif réduit par rapport à d'habitude, avec un seul contributeur qui réalise a lui tout seul plus de la moitié des commits (c'était le cas l'an dernier pour la première fois, jusque là, les choses étaient beaucoup plus réparties, mais il n'y avait pas un contributeur salarié à plein temps). Avec environ 1000 à 1500 commits par an, on est loin du record de 2009 ou on avait dépassé 5500 commits. Cependant, les changements de mode de revue du code font que les changements ont tendance à apparaître sous forme d'un seul commit bien testé et finalisé, au lieu de multiples petits changements et correctifs.
On peut aussi regarder du côté de Haikuports, les courbes se sont croisées avec l'introduction en 2012 du gestionnaire de paquets, et on voit beaucoup d'activité sur le portage et le développement de logiciels, plutôt que sur le système lui-même.
[^] # Re: Nvidia
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Chute du Bitcoin : plus d’un milliard de dollars s’est évaporé du marché crypto en l’espace de 24 h. Évalué à 8 (+5/-0).
Ça fait longtemps que ce n'est plus du tout rentable de miner du bitcoin avec une carte graphique, il existe maintenant des puces dédiées exclusivement à cet usage qui sont (un peu) moins gourmandes en énergie
[^] # Re: Usage multimedia
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Valve annonce la Steam Machine, sa minimachine de jeu. Évalué à 8 (+5/-0).
(c'était une plaisanterie, plus personne n'a de chaîne hifi ni de CD à écouter avec, et je suis prêt à parier qu'on pourra très facilement envoyer le son de Spotify en MP3 compressé vers une enceinte Bluetooth avec un protocol de compression audio avec perte, en utilisant la Steam Machine).
Peut-être que j'aurais plutôt du parler d'une sortie péritel pour éviter tout risque d'être pris au sérieux?
[^] # Re: Usage multimedia
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Valve annonce la Steam Machine, sa minimachine de jeu. Évalué à 3 (+0/-0).
Par contre ça manque d'un lecteur CD alors qu'il y aurait pile la place vu les dimensions de la machine. J'espère que ce sera un add-on plus tard.
[^] # Re: DDOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Incident Cloudfare ou la centralisation c’est le mal, la preuve. Évalué à 7 (+4/-0).
C'est la nouvelle définition du DDOS, le déni de service distribué, qui permet de faire tomber la roitié de l'internet en cassant un seul site!
[^] # Re: "Vulnérabilités"
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 3 (+0/-0).
Ça veut aussi dire que le mot de passe se retrouve dans le buffer du terminal, qui potentiellement se retrouve swappé et donc enregistré sur le disque dur, où on peut le récupérer une fois la machine éteinte (ou de façon sûre, en mettant la machine en hibernation prolongée). Normalement on fait attention que les mots de passe ne soient stockés que dans des zones non enregistrables sur disque et de bien l'effacer avant de libérer la mémoire en question.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 7 (+4/-0).
Il peut être réduit à strictement zéro, en fait, avec des environnements à machine virtuelle comme LISP (dont les supporters ralaient dans le;années 60 sur les développeurs utilisant des langages compilés unsafe avec exactement les mêmes arguments que les supportes de Rust utilisent aujourd'hui) ou SmallTalk. La raison pour laquelle ça n'a pas pris, c'est qu'il y avait un coût en performances relativement important. Rust a fait tomber cette limite (et encore, je vais faire grincer des dents des développears Ada en disant ça).
Je développe moi aussi beaucoup de C++, mais il faut arrêter d'essayer de présenter les inconvénients du langage (pas memory safe, pas de système de build standardisé, pas d'outil de gestion des dépendances, par de règle de formattage et de nommage standardisées) comme des avantages.
Avec Cargo, on peut récupérer plein de bibliothèques bien implémentées pour tout un tas de trucs,et personellement j'ai tendance à avoir plus confiance dans ces bibliothèques oue dans ma capacité (ou celle de mes collègues) à réimplémenter les choses de façon sécurisée et avec de bonnes performances. Et puis en plus, j'ai autre chose à faire que développer pour la 72000ème fois un arbre binaire ou une autre structure de base…
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 3 (+1/-1). Dernière modification le 14 novembre 2025 à 17:05.
Je ne vois pas trop bien pourquoi on fait une confiance aveugle aux distributions Linux mais pas à Cargo. Par exemple, Arch avec AUR ne fait pas mieux d'un point de vue validation de la sécurité des dépendences incluses? Qu'en est-il de Debian par exemple? Si Debian package une bibliothèque avec des failles de sécurité, volontairement ou non, qu'est-ce que ça change par rapport à une vulnérabilité arrivée par Cargo? Est-ce que Debian a un process de relecture complète du code de chaque version des logiciels qu'ils packagent pour que tu n'aies pas besoin de le faire? Je ne crois pas. Tout ça repose sur de la confiance.
Surtout que les dépendances dans les projets Rust ne se mettent pas à jour toutes seules dans le dos des développeurs, il faut faire soi-même la montée en version (et vérifier au moins que cela fonctionne bien).
Et puis quand ta distribution ne package pas le logiciel dont tu as besoin, en C ou C++, tu te retrouves avec… ben rien du tout pour faire le suivi, il faut gérer ça soi-même. Et de mon expérience, ça arrive relativement souvent.
[^] # Re: Esprit critique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Finalement, Chat Control va passer en trilogue. Évalué à 5 (+2/-0).
Je ne comprend pas pourquoi le débat est parti sur l'authentification pour
grosboobs.cometparissportifs.fr. Le texte de départ parle de fournisseurs de mail, chat, et services de messagerie (d'ailleurs, le projet s'appelle ChatControl).Ce qui pose d'autres problèmes, par exemple si vous hébergez un serveur IRC, est-ce que c'est à vous de vérifier l'identité des personnes se connectant à ce serveur, et comment ça se met en place dans ce cas où le protocole n'est pas vraiment prévu pour?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 3 (+0/-0).
Je confirme: on a beau mettre en places tous ces trucs, le nombre de bugs causés par une mauvaise gestion de la mémoire reste important (sans forcément parler de failles de sécurité, à ma connaissance personne n'en a trouvé dans le projet). On a plutôt de bêtes déréférences de pointeurs null, des use after free, ou des hroblèmes de partage de données entre threads.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 10 (+7/-0).
Je ne suis pas développeur dans le noyau Linux et si je peux éviter de faire du C, j'en suis très content. Je n'ai donc pas de "il faudrait" à leur donner ou personne à convaincre. Siequelqu'un proposait l'intégrationde code Rust dans un projet auquel je participe (disons: Haiku), ça ferait par contre partie des questions que je vais poser afin de me faire un avis sur la question [il y en aurait plein d'autre, par exemple dans le cas de Haiku ce serait un problème pour le portage motorola 68000 qu'il faudrait officiellement abandonner dans l'état actuel des toolchains Rust). J'ai juste posé une question: quels sont les motifs utilisés dans le code du noyau Linux qui ne se prêteraient pas à un interfaçage avec Rust?
Avec une réponse à cette question, je pourrais apprendre des choses sur les limites de Rust et sur d'autres façons de gérer la mémoire, ou juste redécouvrir des façons de faire auxquelles je n'ai pas pensé. Ou peut-être que ce sema l'occasion de découvrir une interface qui est, en fait, mal définie. Je sais que dans Haiku, on a plein d'endroits où la resposabilité de libérer de la mémoire pointée par un pointeur est implicite et pas documentée, et il faut aller lire le code source pour vérifier, et en plus ce n'est pas forcément cohérent d'un objet à l'autre. Bien sûr c'est un problème qui peut être résolu oe plein de façons: avec du C++ "moderne" et des smart pointers, avec de la documentation, avec des outils d'analyse statique, … mais l'approche de Rust de vérifier ça à la compilation semble quand même être une très bonne idée?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 6 (+3/-0).
La différence est entre "on peut avoir des interfaces bien définies" dans un autre langage et Rust oblige à avoir des interfaces bien définies (par exemple pour indiquer qui est propriétaire de la mémoire et responsable de la libération, ou assurer la synchronisation entre threads). Oui bien sûr c'est contraignant et parfois ça empêche de faire des choses qui pourraient très bien |onctionner par ailleurs. De la même façon que le C n'a pas de coroutines (alors que c'est facile en assembleur) ou que le C++ ne permet pas de modifier la vtable d'un objet à la volée pendant l'exécution (alors que c'est tout à fait possible en smalltalk, ou si on implémente des vtables en C à la main). Ce sont bien évidement des choix pour contraindre les choses à fonctionner d'une certaine façon: une exécutioneavec une pile d'appel unique par thread, des possibilités d'optimisation des appels de méthodes, par exemple.
La qaestion oevient donc: en pratique, quelles sont les fonctions du noyau Linux qui ont une interface bien définie (en terme de gestion de la mémoire et des threads), mais une approche "inhabituelle" qui fait que ça ne peut pas s'interfacer avec du Rust?
[^] # Re: Go brrrrrrrr
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 7 (+5/-1).
Il me semble que la difficulté de sudo est que cwst un hrogramme complexe avec beaucoup de fonctionnalités (pas forcément souvent utilisées). Par exemple on peut autoriser un utilisateur à lancer seulement certaines commandes avec sudo.
L'outil concurrent doas prend le parti de retirer certaines fonctionnalités pour que le code critique exécuté avec des privilèges élevé reste le plus simple possible. Alors que sudo-rs semble vouloir conserver toute les fonctionnalités.
[^] # Re: code erreur HTTP
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Tenter de limiter les nuisances liées aux robots d'IA. Évalué à 8 (+5/-0).
Moi j'ai mis un 429 (too many requests) qui m'a semblé approprié (IA ou pas, je surveille les statistiques du site une fois de temps en temps et je bannis des range d'IP à la main si ils génèrent trop de requêtes).
[^] # Re: Étalonnage des couleurs
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le "Toy Story" de vos souvenirs. Évalué à 5 (+2/-0).
La difficulté est surtout de savoir quelles étaient les couleurs originales lors de la sortie du film. Si toutes les copies originales en 35mm avaient été détruites, comment ferait-on pour le savoir? Et ces copies se dégradent avec le temps, bien sûr.
Il y a donc plusieurs questions:
Et c'est important parce que ces couleurs peuvent complètement changer la perception du film. On passe d'un truc qui peut avoir l'air presque réaliste à une copie numérique en HD où on se rend beaucoup plus compte que les modèles 3D sont relativement simples et peu texturés, par exemple. La version en film 35mm permettait de gommer plein de choses et de faire en sorte que la magie opère et qu'on oublie un peu le rendu 3D finalement pas si bon que ça. Et c'est quelque chose auquel l'équipe qui a réalisé le film a réfléchi, c'est donc un choix de leur part qu'il convient de préserver dans certains cas.
C'est loin d'être la seule oeuvre pour laquelle c'est le cas. Par exemple, la série originale Star Trek a été filmée et montée en 35mm, mais en ayant en tête que ce serait diffusé à la télévision, avec une définition d'image assez faible. Les trucages qui fonctionnaient relativement bien à l'époque ne fonctionnent donc pas du tout pour une version en haute définition (on voit toutes les ficelles). Le choix qui a été fait dans ce cas, c'est de refaire tous les effets spéciaux en images de synthèse pour la sortie en Blueray de la série (et autres canaux de diffusion en HD). Mais c'est important de préserver aussi la version originale qui a été diffusée, sinon, on pourrait croire en voyant la nouvelle version, que les trucages étaient à des années-lumières devant les possibilités de l'époque où la série a été réalisée!
Et d'autre part, on sait que les grosses entreprises exploitants ces médias ne sont pas forcément les mieux placées pour assurer cette préservation historique et s'assurer que les versions originales restent facilement disponibles.