À noter que le choix gagnant implique un changement du contrat social (SC pour « social contact ») donc il n'est pas exclu qu'il y ait encore des débats pour arriver au résultat attendu.
La proposition contient le changement précis qui doit être appliqué et a obtenu, si je lis bien les résultats détaillés, une majorité qualifiée suffisante (2/3 des votants).
Sur quoi peut-il y avoir encore débat? (vraie question, je ne connaît pas en détail l'organisation du projet Debian).
Il semblerait plutôt (vu la liste d'options de vote possibles d'une part, et le vote très en faveur de ce résultat d'autre part) que les débats ont déjà eu lieu et que ce vote n'était quasiment plus qu'une formalité pour valider la décision déjà prise après cette discussion.
Perso, je prends des cartouches, mais surtout parce que la cartouche me parait plus durable que la carte SD que je vais devoir acheter pour stocker les jeux de 20 gigas qu'on trouve.
ça m'étonnerait, aujourd'hui les jeux sur cartouches (je crois qu'il n'en reste que chez Nintendo?) utilisent de la mémoire flash qui n'a pas une meilleure durée de vie que celle utilisée dans les cartes SD.
La durée de vie de ce type de support est peut-être de 10 ou 20 ans, ensuite il est probable qu'on commence à voir des corruptions sur les cartouches et les cartes SD surtout si elles ne sont pas utilisées.
On est loin des durées de vie des "mask ROMs" utilisées quelques années auparavant qui peuvent conserver leurs données quelques dizaines d'années supplémentaires.
Les deux solutions qui marchent:
Compter sur soi-même pour avoir un plan de backup,
Faire confiance à une plateforme en ligne (Steam, Stadia, ou autre forme) pour gérer ça et pour pouvoir continuer de retélécharger ou d'accéder à ses jeux dans le futur.
Oui je voulais juste dire que ce n'est pas très cher dans les deux cas.
Bref, la licence sur le nom n'est pas le sujet du prix, le sujet est combien tu dois mettre au minimum sur la table pour fabriquer un CPU minimal en production. Je veux 1000 unités d'un CPU qui me fait 100 additions par secondes avec 4 KB de RAM (nombre au pif complet), combien ça me coûte en SPARC et combien en RISC V? Je ne connais pas les prix mais rien qu'à voir la différence de taille entre les intervenants SPARC et ceux RISC V, j'ai une idée que ce n'est pas la même ordre de grandeur au détriment de SPARC.
Probablement, le RISC-V a commencé par se développer sur le marché des microcontrôleurs sur lequel SPARC n'avait pas forcément mis les pieds. Je ne pense pas que ça serait impossible de le faire, mais c'était pas le marché ciblé.
Wikipedia me parle de GPL, d'où ma remarque sur la différence copyleft vs copyfree.
Il s'agir de la license de plusieurs implémentations de SPARC en VHDL, pas de la license de la spécification du jeu d'instructions et de l'architecture.
Le projet GNU ne dit pas que ces systèmes ne sont pas totalement libre. Il dit qu'il ne peut pas soutenir ces projets car ils aident à l'installation de firmware non libres sur ton OS. C'est totalement différent.
Je peux parler pour le cas de Haiku que je connaît bien.
L'installation par défaut de Haiku contient plusieurs logiciels qui ne sont pas libres. À l'époque ou la page de GNU a été écrite, cela comprenait par exemple:
Wonderbrush, un outil de dessin
liblayout, une bibliothèque pour faciliter la réalisation d'interfaces graphiques, utilisée par le lecteur PDF BePDF
Pour ces deux logiciels, nous avons l'autorisation des auteurs pour les inclure dans notre image d'installation et les préinstaller avec Haiku. Cependant, le code n'était absolument pas libre.
Entretemps, Wonderbrush a été re-licensé et le BePDF a été réécrit pour ne plus avoir besoin de la liblayout. Mais Haiku inclus toujours des firmwares wifi non libres (pas juste de l'aide pour les installer, ils sont inclus directement dans le DVD).
Non tu pars d'une interprétation que tu inventes.
Quelle autre définition peut-on prendre? Est-ce que le moindre bout de logiciel non libre inclus dans un système le rend propriétaire? Est-ce que propriétaire est synonyme de "non libre", ou est-ce qu'il y a des nuances entre les deux?
On peut conclure que pour Hare, l'inclusion de firmware wifi et/ou d'autres morceaux non libres dans un système ne semble pas poser problème et qu'ils considèrent que Haiku et FreeBSD ne sont pas des systèmes propriétaires d'après leur définition.
Mais ça ne répond toujours pas entièrement à la question. Qu'est-ce exactement qu'un système propriétaire?
Mon problème avec cette phrase sur le site web est que chaque mot est sujet à interprétation de la même façon:
Qu'est-ce que veut dire "Hare"? Est-ce que c'est le langage de programmation ou est-ce que c'est l'équipe qui le développe? Cela a des conséquences si une autre équipe voulait assurer le support pour des systèmes propriétaires tout de même, est-ce que l'équipe actuelle y serait franchement hostile, ou est-ce qu'ils soutiendraient l'initiative en étant bien content d'être déchargé de ce travail de support?
Qu'est-ce qu'un "système propriétaire"? J'ai tenté de donner une définition qui n'est bien évidement pas la bonne, mais personne n'a su en donner une autre.
Qu'est-ce que "supporter un système" pour un langage de programmation?
Donc, oui, j'essaie de surinterpréter cette phrase parce que, pour moi, elle n'est pas du tout claire et je ne sais pas quoi en penser. Finalement ça peut vouloir dire plein de choses différentes. Si je voulais utiliser Hare, j'aimerais juste savoir à quoi m'attendre.
je peux dire des bêtises la dessus mais RISC-V me semble plus accessible au commun des mortels et répond à des besoins plus spécialisés qu'un CPU généraliste pas cher comparé à faire pareil en libre.
Oui, ce n'est pas la question, c'est super que RISC-V propose une architecture mieux conçue et c'est super que ce soit libre.
Et il était tant de mettre SPARC à la retraite.
C'est juste que je ne vois pas en quoi RISC-V serait "la première architecture libre" dans ce cas (pourtant je vois cet argument répété partout). Je ne vois pas en quoi SPARC n'est pas une architecture libre.
Mais peut-être devrait-on en effet dire que RISC-V est le premier CPU copyfree. Ou le premier libre et utilisable sans trop de fric. Ou le premier libre et utilisable sans réacteur nucléaire. Ou le premier libre et multi-usage.
La license pour avoir le droit d'utiliser le nom "SPARC" coûte 99 dollars (prix inchangé depuis au moins 1997, en tout cas c'est ce que j'ai trouvé sur les versions archivées par archive.org de sparc.org). ça me semble plutôt raisonable.
L'adhésion à RISC-V à un niveau suffisant pour pouvoir faire une utilisation commerciale de la marque RISC-V, c'est 2000$ pour une entreprise créée il y a moins de 2 ans et avec moins de 10 employés, et 15000$ entre 500 et 5000 employés par exemple.
Donc c'est raté pour l'argument "sans trop de fric".
Dans les deux cas, les spécifications sont accessibles sur le site internet des fondations respectives. Celle de RISC-V est sous licence CC-BY, celle de SPARC, il n'y a pas l'air d'avoir d'infos de license (ou j'ai pas cherché au bon endroit). Est-ce que c'est ça qui fait la différence?
On peut re-citer la phrase qui est sur le site de Hare:
Hare does not, and will not, support any proprietary operating systems.
Je traduis:
Hare ne fournit pas et ne fournira pas de support pour aucun système propriétaire.
ça me semble quand même assez fort comme façon de dire les choses. On peut discuter de ce que ça veut vraiment dire:
Quelle est la définition choisie pour "système propriétaire"? Ce n'est pas celle du projet GNU puisque certains systèmes marqués "pas totalement libres" dans la liste du projet GNU sont tout de même listés dans ceux pour lesquels Hare prévoit de fournir du support. Je ne sais pas quelle autre définition utiliser. Donc je ne sais pas dire quel système pourrait recevoir du support ou pas dans le futur.
Qu'est-ce que "Hare" exactement dans cette phrase? Est-ce que c'est le langage de programmation? Ou est-ce que c'est l'équipe derrière le projet? Parce que effectivement ça donne une interprétation assez différente.
Alors, oui, j'ai pris l'interprétation la plus restrictive. Mais si on me demandait de choisir un langage pour écrire un logiciel, c'est comme ça que je m'y prendrais. Peut-être que je suis trop méfiant et prudent. Mais en tout cas ça ne me donne pas confiance.
D'autre part, chacun sa vision des choses, au moins c'est un choix assumé de militer ouvertement contre les "systèmes propriétaires", et on peut être d'accord ou pas. Mais j'aimerais quand même savoir comment ils décident si un système est propriétaire ou pas.
Je ne vois rien qui indique que les processeurs Elbrus sont compatibles SPARC. Il y a bien eu des CPU SPARC fabriqués par le MCST mais on dirait qu'ils sont passé à autre chose avec Elbrus.
Je ne vois toujours pas la différence entre SPARC et RISC-V.
Oui, aujourd'hui SPARC est mort et il n'y a plus d'évolutions dessus, et c'est normal de passer à autre chose pour cette raison et pour d'autres aussi (l'architecture SPARC est loin d'être parfaite). Mais là je trouve qu'on a tendance à l'effacer un peu vite de l'histoire alors que pour moi, ce n'était pas moins ouvert et pas moins collaboratif que RISC-V, à l'époque où il y avait de l'activité dessus.
Il y a eu au moins 4 familles d'implémentations: chez Sun, Fujitsu, ceux du Moscow Center of SPARC Technology, et le LEON de l'ESA.
Il y a eu des processeurs SPARC produits par Sun, Fujitsu, TI, Atmel, Ross, …
Le développement de la version 64 bit a été fait par un commité formé de Amdahl Corporation, Fujitsu, ICL, LSI Logic, Matsushita, Philips, Ross Technology, Sun Microsystems, et Texas Instruments.
Est-ce que ce n'est toujours pas suffisant pour considérer que l'architecture a été conçue de façon collaborative? Il faut combien de douzaines d'entreprises pour que ça soit collaboratif?
Ne pas développer d'implémentation pour un OS privateur est un choix de développement comme un autre. L'équipe de Hare ne doit rien à quiconque (encore moins aux OS privateurs, qui nous pourrissent déjà suffisamment la vie). Ils proposent un travail, dont on fait ce qu'on veut.
C'est vrai, mais choisir de ne pas utiliser un langage ou une bibliothèque parce qu'elle ne fonctionne pas ou que son équipe ne fournit pas de support technique pour certaines configuration, c'est aussi un choix qu'on peut facilement comprendre. Il est probable que ça réduise l'adoption de ce langage. Ce qui fait que ça va être difficile de trouver des développeurs qui l'utilisent et le maîtrisent. Cela constitue un risque pas négligeable et qui peut pousser les gens à choisir un langage plus connu ou plus ouvert à ce genre de choses, ou à n'en avoir rien à faire et choisir quand même de programmer en Hare. Selon le cas et selon le projet, ça peut être un problème ou pas du tout.
La license n'implique rien à propos du support technique. Plutôt au contraire, il y a une clause écrite en majuscule sur l'absence de garanties, etc.
Donc Drew pourrait, par exemple:
- Refuser de fournir du support aux gens essayant de construire une version Windows,
- Fermer tous les rapports de bugs concernant des systèmes non-libres,
- Refuser d'héberger des binaires pour Windows ou d'intégrer le code dans sa version de Hare,
- Faire exprès de changer l'architecture du code pour rendre la vie plus compliquée aux forks qui tenteraient de le faire sans son aide,
- Interdire l'utilisation du nom "Hare" pour toute implémentation autre que la sienne,
- Encourager les gens à écrire du code non portable,
- Concevoir des APIs difficiles à faire fonctionner sur un système non-UNIX.
Sans pouvoir strictement l'interdire, il y a quand même tout un tas de moyen de mettre des bâtons dans les roues à quelqu'un qui se lancerait là-dedans. Même si on peut supposer que ce ne sera pas le cas, on peut considérer ça comme un problème si on veut écrire du code qui pourrait fonctionner sur un système non-libre (et personnellement, je pense que chacun devrait avoir le droit d'écrire du code qui fonctionne où il veut, et qu'on devrait essayer de rendre ça le plus facile possible).
Ça ne serait pas un problème si Drew disait, personellement, "je ne souhaite pas assurer le support pour les systèmes propriétaires". Mais là c'est présenté comme un choix plus global de toute la communauté Hare. Ce qui est surprenant parce que d'un autre côté, un des messages de blog dit qu'ils n'apprécient pas l'évangélisme de la communauté Rust qui veut réécrire et remplacer tout le code C existant. D'une certaine façon, ce choix de ne pas faire fonctionner Hare sur des systèmes non-libres et de s'engager à ne pas le faire ou à empêcher d'autres gens de le faire, relève pourtant un peu de la même attitude qui consiste à imposer ses propres idées là ou ce n'est peut-être pas nécessaire.
Ça pose aussi la question de savoir si le langage est conçu par une communauté, ou par une seule personne qui a tout pouvoir de décision. Les deux choix se défendent, mais là, la présentation qui est faite se retrouve du coup un peu entre les deux, quelque part entre le "c'est un projet personnel pour mes propres besoins, je fais ce que je veux" et le "on va construire une communauté de développeurs avec des objectifs communs". Ce qui donne une position peut être moins facile: "on va construire une communauté de développeurs qui sont d'accord avec mes objectifs". Cela dit, ça a fonctionné pour d'autres projets (Linux, Python, …) donc, ce n'est pas forcément un mauvais modèle en soi.
Autre bizarrerie, Haiku, FreeBSD, OpenBSD et NetBSD ne sont pas totalement libre d'après la FSF, cependant ils sont dans la liste des systèmes que Hare "prévoit" de supporter (et pour FreeBSD c'est même déjà fait). On peut en déduire que la définition de "propriétaire" n'est pas la même que celle de la FSF, mais du coup, quelle est-elle? Est-ce que le support de ReactOS (et par extension de Windows, son clone propriétaire) est prévu? Qui décide quels systèmes sont supportés ou pas? Est-ce que ça peut changer au cours du temps?
Je suis toujours un peu embêté que des articles présentent l'ouverture de RISC-V comme une nouveauté, alors que SPARC est dans la même situation depuis 1989. Toutes les spécifications de l'architecture sont sur le site sparc.org et il existe de nombreuses implémentations.
Certes l'architecture est vieillissante et pas exemptes de défauts. Mais ce serait bien de se souvenir que RISC-V n'est pas la première architecture de CPU ouverte.
Certes, Fujitsu et Sun/Oracle ont arrêté les développements de CPUs utilisant cette architecture, mais l'ESA n'avait de toutes façons jamais utilisé leurs puces (le SPARC LEON a été développé indépendamment). Donc le problème n'est pas vraiment là.
J'avais un prof en école d'ingénieur qui était très énervé par le fait que tout le monde code en C alors que lui, dans sa jeunesse, il avait appris le Simula-67 et c'était vachement plus cool.
Pourquoi est-ce que c'est à ajouter à ton processus de build et pas directement inclut dans ton installation et activé avec un -pdantic ?
-pedantic c'est plutôt pour le code de type "la spécification du langage dit que c'est interdit mais en fait ça marche quand même".
Ce type de chose serait plutôt détecté par les warnings activés par -Wextra, de type "la specification du langage dit que c'est autorisé, mais ça sert à rien à part écrire du code buggé".
Cependant il peut arriver que les warnings rangés dans -Wextra se déclenchent sur du code qui utilise volontairement un des aspects tordus du langage.
(ça n'enlève rien à l'intérêt des analyseurs statiques en plus du compilateur, ou d'utiliser des langages qui ont moins de chausse-trappes lorsque c'est possible)
Le fameux cycle du hype. Je souhaite à Rust d'arriver rapidement à la 4ème puis à la cinquième phase sans trop souffrir des deux précédentes.
Java, Python et C# en sont déjà passé par là, maintenant ils ont trouvé leur place. Ils ont probablement pris une partie de la place qui était occupée il y a 20 ou 30 ans par C ou C++, qui sont maintenant plutôt utilisés dans les applications ou il y a besoin de performance, alors qu'avant ils étaient utilisés vraiment partout (faute d'avoir beaucoup d'autre choix et parce que le matériel disponible à l'époque faisait que toutes les applications avaient un peu plus besoin de faire attention aux performances).
Il semble qu'on aura une phase de "c'est trop génial ça va tout remplacer" à la sortie de chaque nouveau langage.
Je dirais que le langage est encore relativement jeune et qu'on manque un peu de recul sur les choses qui pourraient mal se passer avec.
Et aussi que c'est compliqué pour l'instant de trouver des gens avec un peu d'expérience en Rust pour bien architecturer les nouveaux projets dès le départ.
C'est sympa de la part de Microsoft de prendre les devants et de faire ces expériences pour nous :)
Au niveau OS, les programme en C allouent leur mémoire dans un seul segment appelé le tas, dont la taille est ajustée avec sbrk(2). Cette taille de tas est augmenté lorsque la mémoire libre n'est pas suffisante; a ma connaissance elle n'est jamais diminuée car cela nécessiterait une défragmentation de l'espace mémoire du processus.
Attention à ne pas mélanger 2 choses: sur un système moderne (après 1990) on a de la mémoire virtuelle et une MMU.
Cela veut dire qu'il faut bien distinguer l'allocation d'espace mémoire dans un processus, et l'allocation de mémoire physique pour remplir cet espace.
L'ajustement de taille avec sbrk, ça permet seulement de réserver de l'espace mémoire, qui du coup ne sera plus disponible pour d'autres choses utilisant de la mémoire (mmap, la pile d'exécution, …). L'espace mémoire étant isolé dans chaque processus, ça n'a pas de sens de libérer de l'espace mémoire à l'usage d'un autre processus.
D'autre part, il y a la mémoire physique. Là, on peut allouer et désallouer page par page (4Ko habituellement, mais on commence à voir des "huge pages" de 1Mo pour réduire la charge de travail du MMU) et les pages libérées peuvent être utilisées par d'autres programmes. Il n'y a pas de problème de fragmentation, les pages sont de taille fixe et peuvent être insérées à n'importe quelle adresse dans l'espace mémoire d'un processus.
Même en ayant réservé de l'espace avec sbrk, on est pas obligé de garder cet espace entièrement rempli de pages mémoires disponibles. On peut allouer les pages pour remplir cet espace au moment ou elles sont utilisées, et les libérer lorsque c'est possible ou nécessaire.
La raison pour laquelle on ne le fait pas immédiatement dès qu'une page est disponible, ce sont les performances. Déjà le fait de reconfigurer le MMU pour ajouter ou enlever une page coûte pas mal de temps, mais en plus, il faut effacer le contenu de la page, afin que une autre application ne puisse pas y trouver des traces de l'occupant précédent (ce serait embêtant pour la sécurité du système). Donc ce mécanisme de remise à disposition de page mémoires peut être déclenché seulement lorsque le système commence à être à court de pages à allouer, il va pouvoir demander aux applications de faire du ménage si elles peuvent et de retourner les pages inutilisées à ce moment là.
J'ai fait du dev en Java pour des cibles embarquées avec quelques centaines de kilo-octets de RAM. Avec un garbage collector.
Et ben on était bien content, non pas parce que c'est rapide, mais surtout parce que ça permettait de déplacer les objets en mémoire de façon transparente pour le code. On pouvait donc défragmenter la mémoire et ainsi libérer de grands espaces contigus pour pouvoir allouer de gros objets.
De la même façon, les stacks pour les threads pouvaient être allouées dynamiquement par tout petits blocs (quelques dizaines ou centaines d'octets à la fois) en fonction des besoins de chaque thread.
La consommation mémoire était donc bien inférieure à un code essayant de faire la même chose en C. Et ça justifiait largement de dédier un peu de puissance CPU au garbage collector.
The Perl 5 team have developed an annual release cycle, where a new version is released in about May of every year. Version 5.36 was released in May 2022 and is very different to version 5.6.0, which was current back in the summer of 2000. In this article, we’ll look at some of the new Perl features that you might have missed.
L'article dit aussi comment activer ces fonctionnalités:
use 5.36; # Turns on all new 5.36 (and earlier) features
Il s'agit donc bien d'un article tout récent sur la version 5.36 de Perl?
Je m'attendais donc à un résumé des fonctionnalités ajoutées ces 20 dernières années. Alors, soit l'article est mal fichu (ce qui est possible, je je suis pas Perl de très près), soit il ne s'est vraiment rien passé de plus intéressant pendant 20 ans?
Qu'est-ce qui a conduit l'auteur de l'article à choisir des choses qui auraient du déjà être faites depuis 40 ans pour présenter les nouveautés du langage? Quelles sont les vraies nouveautés intéressantes qu'il a choisi de ne pas présenter?
Est-ce que finalement, le fait qu'il y ait peu de changements n'est pas le meilleur aspect de Perl, enfin un langage stable avec lequel on peut écrire des logiciels qui continueront à fonctionner sans problème pour des dizaines d'années?
On peut nommer les paramètres des fonctions (ça existe en C, Pascal, … depuis le millénaire précédent), les descripteurs de fichiers ne sont pas forcément des variables globales (ça existe en C, Pascal, … depuis le millénaire précédent), et on a une fonction qui affiche des chaînes de caractères avec un retour à la ligne (ça existe en C, Pascal, … depuis le millénaire précédent). Bienvenue dans les années 80, Perl?
Et la prochaine étape c'est les années 90 avec de la programmation orientée objet.
Je te trouves un peu dur. Netsurf a 15ans, le navigateur de SerenityOS n'en a même pas deux.
Je n'ai pas dit que Serenity faisait un mauvais travail côté technique ou sur aucun autre sujet, juste qu'ils etaient meilleurs en communication. Je dirais plutôt qu'on a des choses à apprendre de ce projet
Libre à toi de porter netsurf si ce n'est pas déjà fait.
Je m'occupe déjà de la version de NetSurf pour Haiku (packaging et développement du code du frontend, malheureusement, je ne peux pas tout faire moi-même…
NetSurf est un moteur de rendu portable, et ils fournissent un "frontend" natif différent pour chaque OS. Certains sont plus avancés que d'autres et proposent plus ou moins de fonctionalités.
Le test acid3 original ne passe pas à plus de 97% suraucun navigateur moderne en raison de protections de sécurité.
Soit Ladybird n'est pas sécurisé contre les attaques cross-origin, soit ils ont utilisé une version modifiée du test.
De plus, ce test ne fait pas tout et le rendu sur des "vraies" pages est beaucoup plus décevant. Souvent moins bon que NetSurf qu'il est dommage de voir complètement ignoré alors qu'ils font un très bon travail sur le développement d'un moteur léger et performant depuis plus d'une dizaine d'années… L'équipe autour de Serenity est visiblement plutôt douée en terme de communication, on entend beaucoup parler d'eux :)
Je ne comprend pas bien quelle est la proposition. Est-ce que c'est de dire à Debian, Ubuntu, Arch, etc d'abandonner leurs formats de paquets et de compiler leurs propres Flatpaks? Auquel cas ça ne résoud pas vraiment les problèmes soulevés: on pourra toujours avoir la mauvaise version d'une lib, un exécutable qui a le même nom qu'un autre, etc.
Ou bien est-ce que l'idée c'est de laisser les développeurs d'applications faire leur packaging et de retirer les applis du dépôt des distributions? Auquel cas, qui va s'occuper des mises à jour de sécurité et du support LTS? Bon l'auteur parle de Arch donc je suppose que le support LTS avec une version fixe de tout les paquets et seulement des mises à jour de sécurité ne l'intéresse pas.
Mon expérience là dessus c'est que la seule façon de passer le relais c'est de démissionner et de dire que si personne ne se porte volontaire l'association sera dissoute.
Sous la menace on finit par trouver des volontaires. Et il vaut mieux le faire avant d'être en burn-out. Un truc qui marche pas mal c'est de renouveler une partie du bureau tous les 3 ans: un an pour apprendre, un an pour faire, un an pour transmettre. J'ai fait partie d'associations ou ce mandat de 3 ans éta?t noté dans les statuts justement pour éviter que tout le monde repose sur le bureau existant.
Le passage de relais n'est pas facile et le nouveau bureau ne fera pas forcément les choses comme vous les auriez faites/sera moins impliqué/etc. Si ça ne vous convient pas, acceptez le fait que c'est votre association et que vous êtes président à vie.
[^] # Re: Détails de votes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Debian va inclure des binaires non-libres de firmwares dans ses images d'installation. Évalué à 3.
La proposition contient le changement précis qui doit être appliqué et a obtenu, si je lis bien les résultats détaillés, une majorité qualifiée suffisante (2/3 des votants).
Sur quoi peut-il y avoir encore débat? (vraie question, je ne connaît pas en détail l'organisation du projet Debian).
Il semblerait plutôt (vu la liste d'options de vote possibles d'une part, et le vote très en faveur de ce résultat d'autre part) que les débats ont déjà eu lieu et que ce vote n'était quasiment plus qu'une formalité pour valider la décision déjà prise après cette discussion.
[^] # Re: Jouer en streaming
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Google ferme son service de jeu en streaming Stadia . Évalué à 5.
ça m'étonnerait, aujourd'hui les jeux sur cartouches (je crois qu'il n'en reste que chez Nintendo?) utilisent de la mémoire flash qui n'a pas une meilleure durée de vie que celle utilisée dans les cartes SD.
La durée de vie de ce type de support est peut-être de 10 ou 20 ans, ensuite il est probable qu'on commence à voir des corruptions sur les cartouches et les cartes SD surtout si elles ne sont pas utilisées.
On est loin des durées de vie des "mask ROMs" utilisées quelques années auparavant qui peuvent conserver leurs données quelques dizaines d'années supplémentaires.
Les deux solutions qui marchent:
[^] # Re: Le dernier clou dans le cercueil
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien RISC V pourrait permettre aux deux agences spatiales ESA et NASA et de travailler main dans la main. Évalué à 3.
Oui je voulais juste dire que ce n'est pas très cher dans les deux cas.
Probablement, le RISC-V a commencé par se développer sur le marché des microcontrôleurs sur lequel SPARC n'avait pas forcément mis les pieds. Je ne pense pas que ça serait impossible de le faire, mais c'était pas le marché ciblé.
Il s'agir de la license de plusieurs implémentations de SPARC en VHDL, pas de la license de la spécification du jeu d'instructions et de l'architecture.
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 4.
Je peux parler pour le cas de Haiku que je connaît bien.
L'installation par défaut de Haiku contient plusieurs logiciels qui ne sont pas libres. À l'époque ou la page de GNU a été écrite, cela comprenait par exemple:
Pour ces deux logiciels, nous avons l'autorisation des auteurs pour les inclure dans notre image d'installation et les préinstaller avec Haiku. Cependant, le code n'était absolument pas libre.
Entretemps, Wonderbrush a été re-licensé et le BePDF a été réécrit pour ne plus avoir besoin de la liblayout. Mais Haiku inclus toujours des firmwares wifi non libres (pas juste de l'aide pour les installer, ils sont inclus directement dans le DVD).
Quelle autre définition peut-on prendre? Est-ce que le moindre bout de logiciel non libre inclus dans un système le rend propriétaire? Est-ce que propriétaire est synonyme de "non libre", ou est-ce qu'il y a des nuances entre les deux?
On peut conclure que pour Hare, l'inclusion de firmware wifi et/ou d'autres morceaux non libres dans un système ne semble pas poser problème et qu'ils considèrent que Haiku et FreeBSD ne sont pas des systèmes propriétaires d'après leur définition.
Mais ça ne répond toujours pas entièrement à la question. Qu'est-ce exactement qu'un système propriétaire?
Mon problème avec cette phrase sur le site web est que chaque mot est sujet à interprétation de la même façon:
Donc, oui, j'essaie de surinterpréter cette phrase parce que, pour moi, elle n'est pas du tout claire et je ne sais pas quoi en penser. Finalement ça peut vouloir dire plein de choses différentes. Si je voulais utiliser Hare, j'aimerais juste savoir à quoi m'attendre.
[^] # Re: Le dernier clou dans le cercueil
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien RISC V pourrait permettre aux deux agences spatiales ESA et NASA et de travailler main dans la main. Évalué à 4.
Oui, ce n'est pas la question, c'est super que RISC-V propose une architecture mieux conçue et c'est super que ce soit libre.
Et il était tant de mettre SPARC à la retraite.
C'est juste que je ne vois pas en quoi RISC-V serait "la première architecture libre" dans ce cas (pourtant je vois cet argument répété partout). Je ne vois pas en quoi SPARC n'est pas une architecture libre.
La license pour avoir le droit d'utiliser le nom "SPARC" coûte 99 dollars (prix inchangé depuis au moins 1997, en tout cas c'est ce que j'ai trouvé sur les versions archivées par archive.org de sparc.org). ça me semble plutôt raisonable.
L'adhésion à RISC-V à un niveau suffisant pour pouvoir faire une utilisation commerciale de la marque RISC-V, c'est 2000$ pour une entreprise créée il y a moins de 2 ans et avec moins de 10 employés, et 15000$ entre 500 et 5000 employés par exemple.
Donc c'est raté pour l'argument "sans trop de fric".
Dans les deux cas, les spécifications sont accessibles sur le site internet des fondations respectives. Celle de RISC-V est sous licence CC-BY, celle de SPARC, il n'y a pas l'air d'avoir d'infos de license (ou j'ai pas cherché au bon endroit). Est-ce que c'est ça qui fait la différence?
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 2.
On peut re-citer la phrase qui est sur le site de Hare:
Je traduis:
ça me semble quand même assez fort comme façon de dire les choses. On peut discuter de ce que ça veut vraiment dire:
Quelle est la définition choisie pour "système propriétaire"? Ce n'est pas celle du projet GNU puisque certains systèmes marqués "pas totalement libres" dans la liste du projet GNU sont tout de même listés dans ceux pour lesquels Hare prévoit de fournir du support. Je ne sais pas quelle autre définition utiliser. Donc je ne sais pas dire quel système pourrait recevoir du support ou pas dans le futur.
Qu'est-ce que "Hare" exactement dans cette phrase? Est-ce que c'est le langage de programmation? Ou est-ce que c'est l'équipe derrière le projet? Parce que effectivement ça donne une interprétation assez différente.
Alors, oui, j'ai pris l'interprétation la plus restrictive. Mais si on me demandait de choisir un langage pour écrire un logiciel, c'est comme ça que je m'y prendrais. Peut-être que je suis trop méfiant et prudent. Mais en tout cas ça ne me donne pas confiance.
D'autre part, chacun sa vision des choses, au moins c'est un choix assumé de militer ouvertement contre les "systèmes propriétaires", et on peut être d'accord ou pas. Mais j'aimerais quand même savoir comment ils décident si un système est propriétaire ou pas.
[^] # Re: Le dernier clou dans le cercueil
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien RISC V pourrait permettre aux deux agences spatiales ESA et NASA et de travailler main dans la main. Évalué à 3.
Je ne vois rien qui indique que les processeurs Elbrus sont compatibles SPARC. Il y a bien eu des CPU SPARC fabriqués par le MCST mais on dirait qu'ils sont passé à autre chose avec Elbrus.
En regardant un résumé du jeu d'instruction ça ressemble vaguement à du SPARC mais ce n'est pas compatible.
[^] # Re: Le dernier clou dans le cercueil
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien RISC V pourrait permettre aux deux agences spatiales ESA et NASA et de travailler main dans la main. Évalué à 4.
Je ne vois toujours pas la différence entre SPARC et RISC-V.
Oui, aujourd'hui SPARC est mort et il n'y a plus d'évolutions dessus, et c'est normal de passer à autre chose pour cette raison et pour d'autres aussi (l'architecture SPARC est loin d'être parfaite). Mais là je trouve qu'on a tendance à l'effacer un peu vite de l'histoire alors que pour moi, ce n'était pas moins ouvert et pas moins collaboratif que RISC-V, à l'époque où il y avait de l'activité dessus.
Il y a eu au moins 4 familles d'implémentations: chez Sun, Fujitsu, ceux du Moscow Center of SPARC Technology, et le LEON de l'ESA.
Il y a eu des processeurs SPARC produits par Sun, Fujitsu, TI, Atmel, Ross, …
Le développement de la version 64 bit a été fait par un commité formé de Amdahl Corporation, Fujitsu, ICL, LSI Logic, Matsushita, Philips, Ross Technology, Sun Microsystems, et Texas Instruments.
Est-ce que ce n'est toujours pas suffisant pour considérer que l'architecture a été conçue de façon collaborative? Il faut combien de douzaines d'entreprises pour que ça soit collaboratif?
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 2.
C'est vrai, mais choisir de ne pas utiliser un langage ou une bibliothèque parce qu'elle ne fonctionne pas ou que son équipe ne fournit pas de support technique pour certaines configuration, c'est aussi un choix qu'on peut facilement comprendre. Il est probable que ça réduise l'adoption de ce langage. Ce qui fait que ça va être difficile de trouver des développeurs qui l'utilisent et le maîtrisent. Cela constitue un risque pas négligeable et qui peut pousser les gens à choisir un langage plus connu ou plus ouvert à ce genre de choses, ou à n'en avoir rien à faire et choisir quand même de programmer en Hare. Selon le cas et selon le projet, ça peut être un problème ou pas du tout.
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 7. Dernière modification le 27 septembre 2022 à 16:41.
La license n'implique rien à propos du support technique. Plutôt au contraire, il y a une clause écrite en majuscule sur l'absence de garanties, etc.
Donc Drew pourrait, par exemple:
- Refuser de fournir du support aux gens essayant de construire une version Windows,
- Fermer tous les rapports de bugs concernant des systèmes non-libres,
- Refuser d'héberger des binaires pour Windows ou d'intégrer le code dans sa version de Hare,
- Faire exprès de changer l'architecture du code pour rendre la vie plus compliquée aux forks qui tenteraient de le faire sans son aide,
- Interdire l'utilisation du nom "Hare" pour toute implémentation autre que la sienne,
- Encourager les gens à écrire du code non portable,
- Concevoir des APIs difficiles à faire fonctionner sur un système non-UNIX.
Sans pouvoir strictement l'interdire, il y a quand même tout un tas de moyen de mettre des bâtons dans les roues à quelqu'un qui se lancerait là-dedans. Même si on peut supposer que ce ne sera pas le cas, on peut considérer ça comme un problème si on veut écrire du code qui pourrait fonctionner sur un système non-libre (et personnellement, je pense que chacun devrait avoir le droit d'écrire du code qui fonctionne où il veut, et qu'on devrait essayer de rendre ça le plus facile possible).
Ça ne serait pas un problème si Drew disait, personellement, "je ne souhaite pas assurer le support pour les systèmes propriétaires". Mais là c'est présenté comme un choix plus global de toute la communauté Hare. Ce qui est surprenant parce que d'un autre côté, un des messages de blog dit qu'ils n'apprécient pas l'évangélisme de la communauté Rust qui veut réécrire et remplacer tout le code C existant. D'une certaine façon, ce choix de ne pas faire fonctionner Hare sur des systèmes non-libres et de s'engager à ne pas le faire ou à empêcher d'autres gens de le faire, relève pourtant un peu de la même attitude qui consiste à imposer ses propres idées là ou ce n'est peut-être pas nécessaire.
Ça pose aussi la question de savoir si le langage est conçu par une communauté, ou par une seule personne qui a tout pouvoir de décision. Les deux choix se défendent, mais là, la présentation qui est faite se retrouve du coup un peu entre les deux, quelque part entre le "c'est un projet personnel pour mes propres besoins, je fais ce que je veux" et le "on va construire une communauté de développeurs avec des objectifs communs". Ce qui donne une position peut être moins facile: "on va construire une communauté de développeurs qui sont d'accord avec mes objectifs". Cela dit, ça a fonctionné pour d'autres projets (Linux, Python, …) donc, ce n'est pas forcément un mauvais modèle en soi.
Autre bizarrerie, Haiku, FreeBSD, OpenBSD et NetBSD ne sont pas totalement libre d'après la FSF, cependant ils sont dans la liste des systèmes que Hare "prévoit" de supporter (et pour FreeBSD c'est même déjà fait). On peut en déduire que la définition de "propriétaire" n'est pas la même que celle de la FSF, mais du coup, quelle est-elle? Est-ce que le support de ReactOS (et par extension de Windows, son clone propriétaire) est prévu? Qui décide quels systèmes sont supportés ou pas? Est-ce que ça peut changer au cours du temps?
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 5.
Il est disponible dans le dépôt de paquets de Haiku suite au travail de return0e pendant le Google Summer of Code 2017.
Par contre nous n'avons pas encore de version de Hare disponible.
# Le dernier clou dans le cercueil
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien RISC V pourrait permettre aux deux agences spatiales ESA et NASA et de travailler main dans la main. Évalué à 9.
C'est la fin pour SPARC…
Je suis toujours un peu embêté que des articles présentent l'ouverture de RISC-V comme une nouveauté, alors que SPARC est dans la même situation depuis 1989. Toutes les spécifications de l'architecture sont sur le site sparc.org et il existe de nombreuses implémentations.
Certes l'architecture est vieillissante et pas exemptes de défauts. Mais ce serait bien de se souvenir que RISC-V n'est pas la première architecture de CPU ouverte.
Certes, Fujitsu et Sun/Oracle ont arrêté les développements de CPUs utilisant cette architecture, mais l'ESA n'avait de toutes façons jamais utilisé leurs puces (le SPARC LEON a été développé indépendamment). Donc le problème n'est pas vraiment là.
# Les trucs plus anciens
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 6.
J'avais un prof en école d'ingénieur qui était très énervé par le fait que tout le monde code en C alors que lui, dans sa jeunesse, il avait appris le Simula-67 et c'était vachement plus cool.
C'est un langage objet dérivé de Algol 60, un langage qui ressemble pas mal à Go.
Pourquoi, soixante ans après, on est encore en train d'inventer des nouveaux langages?
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 4.
-pedantic c'est plutôt pour le code de type "la spécification du langage dit que c'est interdit mais en fait ça marche quand même".
Ce type de chose serait plutôt détecté par les warnings activés par -Wextra, de type "la specification du langage dit que c'est autorisé, mais ça sert à rien à part écrire du code buggé".
Cependant il peut arriver que les warnings rangés dans -Wextra se déclenchent sur du code qui utilise volontairement un des aspects tordus du langage.
(ça n'enlève rien à l'intérêt des analyseurs statiques en plus du compilateur, ou d'utiliser des langages qui ont moins de chausse-trappes lorsque c'est possible)
[^] # Re: La fin de la "stabilite" des standards ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 5.
Le fameux cycle du hype. Je souhaite à Rust d'arriver rapidement à la 4ème puis à la cinquième phase sans trop souffrir des deux précédentes.
Java, Python et C# en sont déjà passé par là, maintenant ils ont trouvé leur place. Ils ont probablement pris une partie de la place qui était occupée il y a 20 ou 30 ans par C ou C++, qui sont maintenant plutôt utilisés dans les applications ou il y a besoin de performance, alors qu'avant ils étaient utilisés vraiment partout (faute d'avoir beaucoup d'autre choix et parce que le matériel disponible à l'époque faisait que toutes les applications avaient un peu plus besoin de faire attention aux performances).
Il semble qu'on aura une phase de "c'est trop génial ça va tout remplacer" à la sortie de chaque nouveau langage.
# Est-ce que c'est pas un peu tôt?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 3.
Je dirais que le langage est encore relativement jeune et qu'on manque un peu de recul sur les choses qui pourraient mal se passer avec.
Et aussi que c'est compliqué pour l'instant de trouver des gens avec un peu d'expérience en Rust pour bien architecturer les nouveaux projets dès le départ.
C'est sympa de la part de Microsoft de prendre les devants et de faire ces expériences pour nous :)
[^] # Re: Le but d’un GC n’a jamais été les performances
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 10.
Attention à ne pas mélanger 2 choses: sur un système moderne (après 1990) on a de la mémoire virtuelle et une MMU.
Cela veut dire qu'il faut bien distinguer l'allocation d'espace mémoire dans un processus, et l'allocation de mémoire physique pour remplir cet espace.
L'ajustement de taille avec sbrk, ça permet seulement de réserver de l'espace mémoire, qui du coup ne sera plus disponible pour d'autres choses utilisant de la mémoire (mmap, la pile d'exécution, …). L'espace mémoire étant isolé dans chaque processus, ça n'a pas de sens de libérer de l'espace mémoire à l'usage d'un autre processus.
D'autre part, il y a la mémoire physique. Là, on peut allouer et désallouer page par page (4Ko habituellement, mais on commence à voir des "huge pages" de 1Mo pour réduire la charge de travail du MMU) et les pages libérées peuvent être utilisées par d'autres programmes. Il n'y a pas de problème de fragmentation, les pages sont de taille fixe et peuvent être insérées à n'importe quelle adresse dans l'espace mémoire d'un processus.
Même en ayant réservé de l'espace avec sbrk, on est pas obligé de garder cet espace entièrement rempli de pages mémoires disponibles. On peut allouer les pages pour remplir cet espace au moment ou elles sont utilisées, et les libérer lorsque c'est possible ou nécessaire.
La raison pour laquelle on ne le fait pas immédiatement dès qu'une page est disponible, ce sont les performances. Déjà le fait de reconfigurer le MMU pour ajouter ou enlever une page coûte pas mal de temps, mais en plus, il faut effacer le contenu de la page, afin que une autre application ne puisse pas y trouver des traces de l'occupant précédent (ce serait embêtant pour la sécurité du système). Donc ce mécanisme de remise à disposition de page mémoires peut être déclenché seulement lorsque le système commence à être à court de pages à allouer, il va pouvoir demander aux applications de faire du ménage si elles peuvent et de retourner les pages inutilisées à ce moment là.
# L'abstraction c'est bien
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 10.
J'ai fait du dev en Java pour des cibles embarquées avec quelques centaines de kilo-octets de RAM. Avec un garbage collector.
Et ben on était bien content, non pas parce que c'est rapide, mais surtout parce que ça permettait de déplacer les objets en mémoire de façon transparente pour le code. On pouvait donc défragmenter la mémoire et ainsi libérer de grands espaces contigus pour pouvoir allouer de gros objets.
De la même façon, les stacks pour les threads pouvaient être allouées dynamiquement par tout petits blocs (quelques dizaines ou centaines d'octets à la fois) en fonction des besoins de chaque thread.
La consommation mémoire était donc bien inférieure à un code essayant de faire la même chose en C. Et ça justifiait largement de dédier un peu de puissance CPU au garbage collector.
[^] # Re: Toujours pas convaincu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien This is not your grandfather’s Perl. Évalué à 3.
J'ai lu l'introduction de l'article qui dit ceci:
L'article dit aussi comment activer ces fonctionnalités:
Il s'agit donc bien d'un article tout récent sur la version 5.36 de Perl?
Je m'attendais donc à un résumé des fonctionnalités ajoutées ces 20 dernières années. Alors, soit l'article est mal fichu (ce qui est possible, je je suis pas Perl de très près), soit il ne s'est vraiment rien passé de plus intéressant pendant 20 ans?
Qu'est-ce qui a conduit l'auteur de l'article à choisir des choses qui auraient du déjà être faites depuis 40 ans pour présenter les nouveautés du langage? Quelles sont les vraies nouveautés intéressantes qu'il a choisi de ne pas présenter?
Est-ce que finalement, le fait qu'il y ait peu de changements n'est pas le meilleur aspect de Perl, enfin un langage stable avec lequel on peut écrire des logiciels qui continueront à fonctionner sans problème pour des dizaines d'années?
# Toujours pas convaincu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien This is not your grandfather’s Perl. Évalué à 3.
Pas plus convaincu que après le débat dans le lien précédent à ce sujet.
On peut nommer les paramètres des fonctions (ça existe en C, Pascal, … depuis le millénaire précédent), les descripteurs de fichiers ne sont pas forcément des variables globales (ça existe en C, Pascal, … depuis le millénaire précédent), et on a une fonction qui affiche des chaînes de caractères avec un retour à la ligne (ça existe en C, Pascal, … depuis le millénaire précédent). Bienvenue dans les années 80, Perl?
Et la prochaine étape c'est les années 90 avec de la programmation orientée objet.
[^] # Re: Moteur!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ladybird: un nouveau brouteur multiplateforme. Évalué à 6. Dernière modification le 15 septembre 2022 à 09:00.
Je n'ai pas dit que Serenity faisait un mauvais travail côté technique ou sur aucun autre sujet, juste qu'ils etaient meilleurs en communication. Je dirais plutôt qu'on a des choses à apprendre de ce projet
Je m'occupe déjà de la version de NetSurf pour Haiku (packaging et développement du code du frontend, malheureusement, je ne peux pas tout faire moi-même…
[^] # Re: Moteur!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ladybird: un nouveau brouteur multiplateforme. Évalué à 6.
NetSurf est un moteur de rendu portable, et ils fournissent un "frontend" natif différent pour chaque OS. Certains sont plus avancés que d'autres et proposent plus ou moins de fonctionalités.
[^] # Re: Moteur!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ladybird: un nouveau brouteur multiplateforme. Évalué à 8.
Le test acid3 original ne passe pas à plus de 97% suraucun navigateur moderne en raison de protections de sécurité.
Soit Ladybird n'est pas sécurisé contre les attaques cross-origin, soit ils ont utilisé une version modifiée du test.
De plus, ce test ne fait pas tout et le rendu sur des "vraies" pages est beaucoup plus décevant. Souvent moins bon que NetSurf qu'il est dommage de voir complètement ignoré alors qu'ils font un très bon travail sur le développement d'un moteur léger et performant depuis plus d'une dizaine d'années… L'équipe autour de Serenity est visiblement plutôt douée en terme de communication, on entend beaucoup parler d'eux :)
# Mouais
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Traditional Packaging is not Suitable for Modern Applications. Évalué à 8.
Je ne comprend pas bien quelle est la proposition. Est-ce que c'est de dire à Debian, Ubuntu, Arch, etc d'abandonner leurs formats de paquets et de compiler leurs propres Flatpaks? Auquel cas ça ne résoud pas vraiment les problèmes soulevés: on pourra toujours avoir la mauvaise version d'une lib, un exécutable qui a le même nom qu'un autre, etc.
Ou bien est-ce que l'idée c'est de laisser les développeurs d'applications faire leur packaging et de retirer les applis du dépôt des distributions? Auquel cas, qui va s'occuper des mises à jour de sécurité et du support LTS? Bon l'auteur parle de Arch donc je suppose que le support LTS avec une version fixe de tout les paquets et seulement des mises à jour de sécurité ne l'intéresse pas.
[^] # Re: Idem ici
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la difficulté de faire vivre une association. Évalué à 5.
Mon expérience là dessus c'est que la seule façon de passer le relais c'est de démissionner et de dire que si personne ne se porte volontaire l'association sera dissoute.
Sous la menace on finit par trouver des volontaires. Et il vaut mieux le faire avant d'être en burn-out. Un truc qui marche pas mal c'est de renouveler une partie du bureau tous les 3 ans: un an pour apprendre, un an pour faire, un an pour transmettre. J'ai fait partie d'associations ou ce mandat de 3 ans éta?t noté dans les statuts justement pour éviter que tout le monde repose sur le bureau existant.
Le passage de relais n'est pas facile et le nouveau bureau ne fera pas forcément les choses comme vous les auriez faites/sera moins impliqué/etc. Si ça ne vous convient pas, acceptez le fait que c'est votre association et que vous êtes président à vie.