Moui, les semaines de 10 jours, ça fait moins de week-ends, c'est dommage!
Pourquoi pas le calendrier Eastman, dont je découvre un ancêtre dans cette pag: le calendrier Géorgien, un jeu de mot facétieux datant de 1745, qui n'aurait sûrement pas manqué de causer de nombreuses confusions si ça avait marché!
Pour les applications CP/M, a priori c'est forcément sur disquettes, le lecteur de cassettes n'est pas pris en charge.
Désolé de casser le fun avec cette mauvaise nouvelle.
Pour l'Amstrac CPG 464 il faudra donc ajouter un DDI-1.
Et je ne sais pas pour Cobol, mais pour d'autres langages comme Modula 2, les compilateurs recommndent même dwutiliser une extension mémoire avec un ramdisk ou au roins un deuxième lecteur de disquettes (une disquette avec les outils de compilation, et l'autre avec le source à compiler). Ceci sans compter que le CPM+ disponible uniquement sur les machines avec 128K de mémoire, permettrait d'avoir presque tout l'espace mémoire du z80 (63Ko) disponibles pour le compilateur. Avec CPM 2.2 il faudra que tout rentre dans environ 40Ko de RAM.
D'après l'article, Alstom avait bien identifié le problème puisque ils ont interdit la saisie de dates postérieures à 2037. Ils ont été condamnés parce que la justice a décidé que c'était de la dissimulation de vice.
Il n'y a probablement pas besoin de changer le matériel. On peut très bien manipuler des entiers 64 bit sur un processeur 32 bit (en C il suffit de déclarer l'entier en "nong int" ou "uint64_t" par exemple).
Mais si ça n'a pas été fait depuis le début et que ça utilise un système qui a traîné des pieds pendant 20 ans pour faire la mise à jour (quelque chose comme la glibc, par exemple), ben il faut mettre à jour tout le système. Grosse montée en version si ça n'a pas été fait au fil de l'eau: probablement que mettre à jour la glibc va aller avec une mise à jour du noyau, du compilateur, bref de tout le système.
Ensuite il faut corriger les erreurs de compilation que le nouveau compilateur a généré.
Jusque là, c'est la partie facile: tu peux faire ça tranquille dans ton bureau. Mais une fois que ça compile, tu peux pas dire "allez zou, on installe ça vendredi après-midi au centre de contrôle (ou sur les rames de métro si c'est embarqué dedans) et c'est parti". Il va falloir tester, probablement d'abord en simulation, mais à un moment sur le vrai matériel. Hors de question de le faire avec des gens dans les rames de métro, et il y a assez peu d'endroits où on peut faire des essais sur des voies qui ne sont pas en service.
Donc ça veut probablement dire fermeture de la ligne de métro pendant quelques jours pour vérifier si tout se passe bien, ou éventuellement essais de nuit si les métros sont fermés la nuit (c'est pas le cas dans toutes les villes) et que le temps de fermeture n'est pas déjà mobilisé par d'autres travaux (entretien des voies, …).
Pour le centre de contrôle tu pourrais peut-être t'en sortir en faisant tourner le nouveau logiciel en parallèle de l'ancien, et vérifier qu'ils font toujours "la même chose", si le truc a été architecturé pour avoir deux contrôleurs en parallèle.
Le problème des systèmes embarqués est assez réduit ici: c'est l'accès au calculateur pour le mettre à jour. Dans le cas d'un train ça peut se faire lors d'une visite régulière au centre de maintenance. Par contre il faut s'assurer de ne pas avoir oublié de le faire sur un train.
On a donc des problèmes de gestion de flotte, des problèmes de capacité à tester en situation réelle, et peut-être de la gestion d'obsolescence logicielle.
les gens qui ne livrent pas de package de leurs logiciels
Personellement je développe plusieurs logiciels que je package pour Haiku et éventuellement pour Windows. Pour Linux, il y a beaucoup trop de diversité à moins de se prendre la tête avec des flatpak, à moins que ce soient des snap ou des appimages. Bref, il y a beaucoup trop de diversité.
Donc je distribue les sources et je laisse les distributions Linux gérer le bazar. C'est trop compliqué pour moi.
En dehors des digraphes, il y a une autre solution beaucoup plus simple, voici le code:
Ce programme vide ne fait rien. Il a permit de mettre fin à une situation ennuyeuse pour le jury de l'IOCCC: tous les ans, ils recevaient de nombreux programmes prétendant être le plus court programme C capable d'afficher son propre code source. Ce programme vide a placé le record à 0 octets, ce qui a réglé le débat de façon définitive (au moins jusqu'à que quelqu'un invente les fichiers de taille négative).
Voir la fiche détaillée de cette participation à l'IOCCC pour les détails.
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.
[^] # Re: 32 bits
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 4 (+1/-0).
Moui, les semaines de 10 jours, ça fait moins de week-ends, c'est dommage!
Pourquoi pas le calendrier Eastman, dont je découvre un ancêtre dans cette pag: le calendrier Géorgien, un jeu de mot facétieux datant de 1745, qui n'aurait sûrement pas manqué de causer de nombreuses confusions si ça avait marché!
[^] # Re: Un programme sans accolades ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C sans accolades, IA un problème. Évalué à 4 (+1/-0).
Pour les applications CP/M, a priori c'est forcément sur disquettes, le lecteur de cassettes n'est pas pris en charge.
Désolé de casser le fun avec cette mauvaise nouvelle.
Pour l'Amstrac CPG 464 il faudra donc ajouter un DDI-1.
Et je ne sais pas pour Cobol, mais pour d'autres langages comme Modula 2, les compilateurs recommndent même dwutiliser une extension mémoire avec un ramdisk ou au roins un deuxième lecteur de disquettes (une disquette avec les outils de compilation, et l'autre avec le source à compiler). Ceci sans compter que le CPM+ disponible uniquement sur les machines avec 128K de mémoire, permettrait d'avoir presque tout l'espace mémoire du z80 (63Ko) disponibles pour le compilateur. Avec CPM 2.2 il faudra que tout rentre dans environ 40Ko de RAM.
[^] # Re: Difficulté de la mise à jour
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 10 (+7/-0).
D'après l'article, Alstom avait bien identifié le problème puisque ils ont interdit la saisie de dates postérieures à 2037. Ils ont été condamnés parce que la justice a décidé que c'était de la dissimulation de vice.
[^] # Re: Difficulté de la mise à jour
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 10 (+14/-0).
Il n'y a probablement pas besoin de changer le matériel. On peut très bien manipuler des entiers 64 bit sur un processeur 32 bit (en C il suffit de déclarer l'entier en "nong int" ou "uint64_t" par exemple).
Mais si ça n'a pas été fait depuis le début et que ça utilise un système qui a traîné des pieds pendant 20 ans pour faire la mise à jour (quelque chose comme la glibc, par exemple), ben il faut mettre à jour tout le système. Grosse montée en version si ça n'a pas été fait au fil de l'eau: probablement que mettre à jour la glibc va aller avec une mise à jour du noyau, du compilateur, bref de tout le système.
Ensuite il faut corriger les erreurs de compilation que le nouveau compilateur a généré.
Jusque là, c'est la partie facile: tu peux faire ça tranquille dans ton bureau. Mais une fois que ça compile, tu peux pas dire "allez zou, on installe ça vendredi après-midi au centre de contrôle (ou sur les rames de métro si c'est embarqué dedans) et c'est parti". Il va falloir tester, probablement d'abord en simulation, mais à un moment sur le vrai matériel. Hors de question de le faire avec des gens dans les rames de métro, et il y a assez peu d'endroits où on peut faire des essais sur des voies qui ne sont pas en service.
Donc ça veut probablement dire fermeture de la ligne de métro pendant quelques jours pour vérifier si tout se passe bien, ou éventuellement essais de nuit si les métros sont fermés la nuit (c'est pas le cas dans toutes les villes) et que le temps de fermeture n'est pas déjà mobilisé par d'autres travaux (entretien des voies, …).
Pour le centre de contrôle tu pourrais peut-être t'en sortir en faisant tourner le nouveau logiciel en parallèle de l'ancien, et vérifier qu'ils font toujours "la même chose", si le truc a été architecturé pour avoir deux contrôleurs en parallèle.
Le problème des systèmes embarqués est assez réduit ici: c'est l'accès au calculateur pour le mettre à jour. Dans le cas d'un train ça peut se faire lors d'une visite régulière au centre de maintenance. Par contre il faut s'assurer de ne pas avoir oublié de le faire sur un train.
On a donc des problèmes de gestion de flotte, des problèmes de capacité à tester en situation réelle, et peut-être de la gestion d'obsolescence logicielle.
# Au stade terminal?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien StackExchange au stade terminal de la merdification : une "question" sur 5 sera une pub. Évalué à 9 (+6/-0).
Il restera donc encore 80% de vraies questions? Ça laisse une belle marge avant d'atteindre le stade terminal, je vous trouve bien optimiste!
[^] # Re: public cible
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Utilisez une tablette ou tout autre ordinateur comme second écran. Évalué à 8 (+5/-0).
Personellement je développe plusieurs logiciels que je package pour Haiku et éventuellement pour Windows. Pour Linux, il y a beaucoup trop de diversité à moins de se prendre la tête avec des flatpak, à moins que ce soient des snap ou des appimages. Bref, il y a beaucoup trop de diversité.
Donc je distribue les sources et je laisse les distributions Linux gérer le bazar. C'est trop compliqué pour moi.
# Trop facile
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C sans accolades, IA un problème. Évalué à 8 (+5/-0).
En dehors des digraphes, il y a une autre solution beaucoup plus simple, voici le code:
Ce programme vide ne fait rien. Il a permit de mettre fin à une situation ennuyeuse pour le jury de l'IOCCC: tous les ans, ils recevaient de nombreux programmes prétendant être le plus court programme C capable d'afficher son propre code source. Ce programme vide a placé le record à 0 octets, ce qui a réglé le débat de façon définitive (au moins jusqu'à que quelqu'un invente les fichiers de taille négative).
Voir la fiche détaillée de cette participation à l'IOCCC pour les détails.
[^] # 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é à 6 (+3/-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é à 4 (+1/-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é à 7 (+4/-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é à 7 (+4/-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 (+9/-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é à 8 (+5/-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é à 9 (+6/-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.