pulkomandy a écrit 1927 commentaires

Je ne sais pas si on peut tout mettre sur le dos de l'incompétence. Certains de ces bots font des efforts pour utiliser plusieurs user agents imitant de vraies machines pour essayer de passer innaperçus, ce qui suppose un minimum de compréhension de comment ça marche et une volonté d, rendre le truc difficile à bloquer par les méthodes habituelles.

Il y a donc au moins une part de malveillance. D'habitude je suis le premier à envisager l'incompétence, mais là il y a des gens qui le font exprès.

Même chose chez Facebook avec un bot qui fait des milliers de requêtes et dont la documentation dit explicitement qu'ils ont choisi de ne pas respecter le crawl-delay du robots.txt. Il n'y a pas de "oups on a pas fait attention, désolé" là dedans cette fois ci.

Oui, ça coùte moins cher de retélécharger les choses que de faire un mirroir de tout l'internet.

Et même sur une "petite" forge, un crawler un peu stupide qui suit tous les liens, il va scanner tout l'historique git du projet si c'est accessible via une interface web, et probablement dans tous les formats possibnes (log, diff, blame, en html, en texte, …). Ça fa?t assez vite un gros volume de données, Multipilié par quelques dizaines d'entreprises qui entraìnent des modèles, chacune travaillant probablementsur plusieurs modèles différents en parallèle, ça fait un très gros volume.

J'utilise également un clone saleae (pour mes bricolages personnels). Plutôt pas mal pour les choses simples en effet. Le matériel est très simple, basé sur un composant standard, et la vraie valeur de ces outils est dans le logiciel. Pour ma part je ne vois pas de problème à utiliser un clone avec un logiciel libre. Les problèmes de Saleae viennent plutôt de leur choix de faire payer assez cher le matériel pour financer le logiciel (logiciel dont on a pas vraiment besoin si on utilise Sigrok).

Les systèmes professionnels vont se dif#érencier soit par la gestion de protocoles plus exotiques, soit par du matériel capable de capturer plus de signaux, à une fréquence plus élevée.

Si on veut par exemple tracer un bus adresse et données d'un CPU, ce genre de choses peut être utile. Certains proposent même des modules logiciels pour désassembler le code exécuté à la volée.

Il peat aussi y avoir des besoins particuliers si on veut scanner des protocoles qui ont des spécificités au niveau électronique (usb, sata, hdmi qui utilisent des paires différentielles par exemple).

Mais si on a pas ces besoins, un analyseur DIY simple fera très bien l'affaire, avec un logiciel comme Sigrok par exemple.

ça dépend ce que tu veux faire.

Par exemple sur mon site web, le robots.txt met un crawl-delay de 5 minutes pour tout le monde par défaut. Je n'ai pas besoin que les robots indexent mon site plusieurs dizaines de fois par jour, le contenu change assez peu.

Si les robots LLM respectaient ce réglage, je n'aurait pas de problème de charge CPU ou de bande passante (j'ai d'autres problèmes personnels avec les LLM mais c'est une autre histoire). ça règle le deuxième problème: ce réglage étant valide pour tout le monde, il n'y a pas de "course".

Il en est de même pour les liens avec rel="nofollow" que les robots ne devraient normalement pas utiliser (et je suppose que les gens qui se plaignent de problème de charge CPU sur leurs applis web sont un minimum compétents et ont déjà mis en place ce type de mesures pour éviter que les robot scannent des choses qui n'ont pas besoin de l'être).

Sauf que non: certains de ces robots ignorent complètement le robots.txt, d'autres ignorent le crawl-delay, d'autres refusent un crawl-delay supérieur à 10 secondes. Donc je les ai exclus par d'autres moyens, parce que ce mois ci c'était 2 adresses IP qui représentaient plus de 50% du traffic arrivant chez moi.

Je pense que tous les employés de Cloudflare ne sont pas des milliardaires de la tech, et j'espère que la mise en place du nouveau régime technofasciste américain ne va pas se faire sans un minimum de résistance.

Quelle autre raison pourraient-ils avoir pour faire un message de blog dont le but principal est de dire "coucou, on voit vos mots de passe"? Le risque de "bad buzz" me semble assez évident avec un tel message, non?

Moi, si j'étais Cloudflare et que le gouvernement me demandait ça, je ferais un article de blog disant HÉ VOUS AVEZ VU? ON A ACCÈS À VOS MOT DE PASSES IL FAUDRAIT PAS QUE ÇA TOMBE ENTRE DE MAUVAISES MAINS. À défaut de pouvoir être plus explicite…

Au doigt mouillé, je dirais que 49% des fois où on nous demande "M." ou "Mme" c'est uniquement pour pouvoir le mettre dans un courrier (ce qui en soit ne sert strictement à rien)

Il ms emble que Voyages SNCF s'est fait taper sur les doigts à ce sujet il y a quelques semaines: effectivement, c'est excessif, et ils n'ont pas à te demander ça pour te vendre un billet de train.

J’apporte un complément à mon message précédent.

Dans votre article sur les circuits EF9364 et suivants, à un moment vous vous posez la question suivante :

« Comment et pourquoi la SESCOSEM a eu l'idée de se lancer dans ce projet? »

Cette idée ne vient pas de la Sescosem, mais de Jean Gastinel.
Sur le site de Grenoble, il y avait de bonnes interactions entre les universitaires et l’industriel Sescosem (puis EFCIS). Jean Gastinel, fils de Noël prof de fac, était bricoleur en électronique et avions radio-commandés. Il rentre à l’ENS et a envie de construire un ordinateur, il demande à son père comment faire. Celui-ci lui conseille d'en parler à François Anceau, enseignant-chercheur à la fac de Grenoble. Ce dernier lui conseille d’aller voir à Paris Gérard Noguez, enseignant-chercheur à l’Université Paris 6, sur le campus de Jussieu.

Jean Gastinel entraîne ses copains de promotion ENS dans l’aventure. Le petit groupe construit un ordinateur 12 bits. Ensuite, Jean définit la fonction de son circuit alphanumérique pour sa thèse, et créé une maquette de simulation en circuits MSI. À l’époque, il n’y avait pas de logiciels de CAO (de toutes façons, il n’y avait pas d’écrans interactifs !), et nous faisions la conception logique en câblant des circuits existants et en contrôlant avec un oscilloscope. Les fréquences dépassaient rarement 10 MHz.

Pour faire exister le circuit, il s’adresse tout naturellement aux connaissances chez Sescosem-EFCIS. Une personne importante dans le lancement du projet chez EFCIS a été M. Joumard qui s’est passionné tout de suite, puis ensuite M. Moreau pour le suivi de la réalisation.

À l’époque, Efcis a suivi, sans objectif précis, si ce n’est de mettre ces circuits à son catalogue. De même ensuite pour mes circuits graphiques.

EFCIS signifie "Etude et Fabrication de Circuits Intégrés Spéciaux". Ils étaient orientés vers la réalisation de circuits à la demande, mais faisaient aussi des circuits standards. C’était une filiale de THOMSON. Dans ce monde industriel, les conceptions ne sont pas publiques. Or, pour ma thèse, j’avais insisté pour pouvoir tout publier. EFCIS a déposé 4 demandes de brevets en mon nom, avec Thomson comme propriétaire, la veille de ma soutenance de thèse. (En accord avec le contrat que l’ENS avait signé.)

C’est le fait que la structure de mes blocs de base était publique qui a permis à EFCIS de les réutiliser ensuite pour les circuits du minitel. En effet, si cela avait été propriété d’un de leur client, ils n’auraient pas pu les ré-utiliser.

Dans les années qui ont suivi, la stratégie marketing de Efcis n’était plus compatible avec la relation avec les élèves de l’ENS et la collaboration s’est arrêtée. Dans une période transitoire (vers 1982), nous avions conçu, toujours en relation avec EFCIS, un ordinateur basé sur un microprocesseur 8 bits, qui a été commercialisé par EFCIS sous le nom de Monocarte-THEMIS. Il a été candidat pour équiper les lycées, mais il était un peu plus haut de gamme que ses concurrents et donc plus cher à produire.

Cordialement,
Philippe Matherat

Je vous partage un message de Philippe Matherat, qui a été contacté par un lecteur de cette dépêche (bublbobl) et qui a donné son accord pour la publication de ce message.

Je vous remercie de votre message, et de votre intérêt pour ces circuits et cette époque.

En effet, je suis le concepteur du premier GPU, au niveau mondial !
Ce sont les circuits EF9365 et EF9366.

Nous étions une bande de copains, élèves de l’Ecole normale Supérieure, de la promotion 1973.

L’informatique était balbutiante, les ordinateurs étaient gigantesques (un bâtiment), très rares et très chers. Personne n’envisageait qu’ils puissent être répandus et bon marché. Les seuls écrans connus étaient ceux de la télévision. Les terminaux informatiques étaient des machines à écrire mécaniques actionnés par des relais électromécaniques. Ces terminaux étaient reliés à des gros ordinateurs distants, par une ligne téléphonique à 300 bits/s.

Jean Gastinel était le seul de notre promotion qui connaissait un peu ce qui se passait aux Etats-Unis, grâce à son père : Noël Gastinel, qui était professeur à Grenoble et qui avait fait des voyages dans les universités américaines et chez IBM. Il avait fait équiper l’université de Grenoble d’un ordinateur IBM 370.

Il nous a sensibilisé aux circuits intégrés. Les premières mémoires MOS de taille correcte sont apparues dans ces années-là chez Intel (1 K bits en 1971, 4 K bits en 1974, 64 K bits en 1978).

Jean Gastinel, avec Jean-Marc Frailong et Jean-Luc Richier, ont réalisé un ordinateur 12 bits, à base de circuits MSI de Texas-Instruments, dans les années 1973-1975. Puis Jean-Gastinel s’est lancé dans la conception du circuit d’affichage alpha-numérique, qui a été commercialisé sous le nom de SFF364 puis EF9364 (le changement de nom correspond au changement de nom de la société Sescosem en EFCIS). Cette conception a fait l’objet de sa thèse de 3è cycle.

À la suite, j’ai pensé qu’on pouvait faire du graphique. Il faut bien voir que ceci n’est devenu possible que grâce aux nouvelles mémoires de 4 K bits, car un affichage 512 x 512 à 1 bit/pixel nécessite 64 boitiers mémoires de 4 K bits. En fait cela ne devient raisonnable qu’avec 16 boîtiers de 64 K bits. Il n’était donc pas possible de faire un GPU avant ces années-là. Mon mérite a été d’avoir le flair de voir qu’une période nouvelle pouvait s’ouvrir, et que les écrans graphiques pouvaient se démocratiser.

Nous avons bénéficié d’une période magique, dans laquelle une bande de jeunes étudiants pouvaient passer un contrat d’industrialisation avec une entreprise de semi-conducteurs française. Nos intentions n’étaient pas du tout de gagner de l’argent en créant une start-up. Nous avons tout donné au public, les contrats ont été passés entre Efcis et l’Ecole normale supérieure. L’argent rapporté a servi à créer le Laboratoire d’informatique de l’Ecole normale supérieure, qui n’existait pas auparavant.

D’après ce que je crois savoir, les circuits du Minitel ont été conçus par Efcis, à partir des briques de base de ma thèse de 3è cycle.

Après cela, nous avons été recrutés comme chercheurs au CNRS, installés dans le nouveau laboratoire que nous avions créé à l'ENS. Jean Gastinel et quelques autres sont ensuite partis en 1986 dans la Silicon Valley, chez Xerox-Park. Je suis resté à Paris, chercheur CNRS. J’ai travaillé sur la dissipation du calcul, puis sur les circuits asynchrones.

Dans les années 70, nous faisions la même chose que les créateurs d’Apple, eux dans un garage, nous dans les caves de l’ENS. Mais nous n’avions pas du tout la même mentalité. Notre idéal était de créer des choses qui profiteraient au grand public, avec l’idée que notre rôle était de concevoir, puis de passer à l’industrie qui réaliserait et commercialiserait. Nous avions un dédain pour la fonction commerciale et la finance. Nous avons mis longtemps à comprendre que cela ne pouvait réussir que si les créateurs étaient les mêmes que ceux qui géraient l’industrialisation et la montée en puissance financière.
Cette différence de mentalité explique la différence de succès entre la Silicon Valley et la France.

Cordialement,
Philippe Matherat

J'ai rajouté les 2 images manquantes.

Il y a probablement quelques autres coquilles dans ma recopie (mais aussi plusieurs dans l'original que j'ai corrigées, la technologie de correction orthographique sur les machines à écrire de l'époque n'était pas ce qu'elle est aujourd'hui).

J'essaierai peut-être de vectoriser proprement tous les schémas un de ces jours, mais ça ne sera pas pour tout de suite. Et puis peut être qu'on perd la mise en contraste entre le travail réalisé, moderne pour l'époque, et la mise en page à la machine à écrire avec les images insérées à la main (et pas toujours bien droit).

Il me manque également quelques références que je n'ai pas réussi à identifier ou à trouver sur internet (j'ai peu d'espoir pour certaines qui sont probablement des documents internes de la SESCOSEM, mais au moins pour les articles publiés dans Electronics, ça devrait être possible). Les titres et auteurs des articles ne semblent pas toujours très rigoureusement retranscrits, ça ne facilite pas les recherches.

Pour ceux qui voudraient lire la suite (en quelque sorte), la thèse de troisième cycle de Philippe Matherat se trouve sur sa page personnelle

C’est une énorme source de financement qui disparaît mais ce n’est pas la seule et des scientifiques qui ont fuis leur pays on en a un certain nombre d’exemple.

Chaque scientifique qui passe du temps à chercher des financements ou à quitter son pays, c'est un scientifique qui ne passe pas du temps à faire des recherches sur le changement climatique. Et ça marche de façon plus globale. Pas mal de monde doit déjà être occupé à gérer le grand n'importe quoi (annuler des licensiements de fonctionnaires clairement abusifs, etc), mais quand on est face à un tel torrent de caca, c'est difficile de suivre le rythme et ça va pas être le moment propice pour des enquètes de fond ou quoi que ce soit d'autre qui fasse avancer les choses.

Je ne comprend pas de quoi tu parles quand il s'agit de "contourner des niveaux de sécurité"?

On parle de commandes de debug qui permettent au logicieltournant sur la puce de manipuler le composant bluetooth présent également sur la puce.

Si le code n'utilisepas ces commandes (ce qui est probable, puisqu'elles ne sont pas documentées), il ne se passe rien.

Espressif utilisent probablement ces commandes dans leurs développements internes et ça pourrait être pratique de les avoir sous la main hour déployer un patch depuis un driver, un jour.

Dans le cadre d'un scénario d'attaque: pour exploiter ces commundes, il faut déjà être en mesure d'exécuter du code sur la puce. D'où le fait que ça ne soit pas vraiment une backdoor, ça en serait une si on pouvait accéder à ces commandes directement depuis le bluetooth par exemple et dire à la puce "hey donne moi un dump de ton firmware qui est censé être protégé"

Maintenant, dans le cadre d'une attaque sur du matériel utilisant un ESP32, ces commandes pourraient être utilisées pour faire une "escalation de privilèges" comme on dit: une fois que l'attaquant a réussi à exécuter du code pouvant communiquer avec le composant bluetooth, il pourrait trouver un moyen d'exploiter ces commandes pour, peut-être, réussir à injecter du code quelque part (dans le noyau? Dans le firmware bluetooth?) Et ainsi gagner des permissions supplémentaires. Mais ça, c'est le cas de n'importe quel bout de logiciel.

La chose un peu dommage, c'est que ça ne soit pas documenté. Quelqu'un qui aurait tenté de sécuriser par tous les moyens son matériel, pourrait donc être surpris de découvrir ce possible vecteur d'attaque auquel il n'aurait pas pensé.

Il faut être un peu large sur les bans. Pour ma part j'ai fini par exclure toutes les IP de Meta, de Alibaba Cloud, et de Huawei par exemple.

Cela ne va probablement pas perturber les utilisateurs normaux de mon site.

En complément, j'ai aussi un système de ban à partir du user agent:

• Le robot fait une ou plusieurs requêtes sur le serveur HTTP
• Le serveur répond avec une erreur spécifique (erreur 403 indiquant un accès refusé) pour les user agent que j'ai bloqués (principalement ceux qui ne respectent pas le Crawl-Delay du robots.txt et génèrent plus de traffic que tous les visiteurs non-robotiques combinés).
• Fail2ban surveille les logs du serveur HTTP, toute IP qui déclenche des erreurs 403 va assez rapidement être bannie au niveau du pare-feu.

Cette deuxième protection prend un peu de temps à faire effet, mais déjà le fait de retourner une erreur 403 au lieu d'une vraie page au niveau du serveur web, ça réduit considérablement la charge CPU.

Ensuite on peut consulter la liste d'IP bannies par fail2ban, trouver les plages d'IP correspondantes à l'aide d'un whois IP, et décider s'il s'agit d'un range à bloquer manuellement ou pas.

Pas de problème, mon message écrit un peu vite n'était pas très clair, c'est mieux avec un vrai clavier et le temps pour mettre les liens vers les choses auxquelles je voulais faire référence. Comme ça les gens qui n'ont pas déjà lu cette page (ou vécu cette époque sur IRC) comprendront mieux ce que je voulais dire :)

Le cas IRC est un peu différent: Freenode a explosé à cause de la gestion catastrophique de son admin. Les gens sont parti vers LiberaChat (en majorité) ou vers OFTC (qui existait déjà avant, mais moins connu), mais ce sont les deux principaux réseaux. Je n'ai plus aucun contact sur Freenode.

Je ne parlais pas de ça, je parlais du netsplit à l'époque où IRC n'était vraiment qu'un seul réseau fédéré à ses débuts.

À cette époque là il y avait beaucoup plus de conflits entre les opérateurs de différents serveurs qui avaient des règles et pratiques de modération très différentes. La solution a été d'arrêter la fédération globale et d'avoir à la place plusieurs réseaux. Voir cette page qui résume cette histoire.

Freenode est arrivé un peu plus tard.

ce vieux réseau, passé de mode, attire surtout des devs pour des projets libres

Il existe plein d'autres communautés IRC toujours plus ou moins actives. Et qui, même avec beaucoup moins d'utilisateurs, demandent beaucoup plus de modération qu'un canal IRC de projet opensource. La relativé anonymité des utilisateurs (pas de création de compte) fait que c'est un endroit où certaines personnes se croient tout permis. La liste des canaux les plus fréquentés sur Europnet par exemple est assez révéltatrice.

J'ai appris à passer du QWERTY (espagnol) à l'AZERTY sur différentes machines, et ça fonctionne assez bien (avec un petit temps d'adaptation quand je n'ai pas utilisé une disposition depuis quelques temps).

Je ne sais pas si c'est plus ou moins facile quand ce sont deux dispositions très différentes. Il faudra demander aux bilingues bépo-azerty, s'il y en a parmi nous.

On a un petit peu d'expérience sur les trop gros services fédérés avec IRC (la fédération initiale a fini par exploser, il y a plein de "réseaux" indépendants maintenant) et avec Usenet (décentralisé pour la distribution des messages, mais hiérarchisé avec une organisation assez stricte pour la création des groupes, et des possibilités de modération adaptée au sein de chaque groupe de discussion).

C'est vrai que le fédiverse, ou en tout cas Mastodon, passe un peu à côté de tout ça[je ne saurais pas dire si c'est inhérent au protocole ActivityPub ou plutôt de la façon dont il est utilisé par les applications).

Le clavier Frogpad est prévu pour l'utilisation à une main. Cela repose sur l'utnlisation de combinaisons de touches (modifieurs sous le pouce) pour taper toutes les lettres et symboles avec relativement peu de touches.

Il est parfait soit pour le combiner avec une souris, soit pour le porter en (gros) bracelet en combinaison avec un téléphone.

Problème: il n'est plus fabriqué depuis longtemps. Il faudra donc choisir soit une réalisation DIY (on trouve des modèles pour cela), soit une keymap qui s'en rapproche sur un clavier classique.

ça dépend de quelles consoles on parle.

Pour les plus anciennes, ça peut être très compliqué parce que les jeux exploitent le matériel de façon assez directe.

La N64 est la première où le matériel était assez complexe et les jeux (au moins les premiers sortis) se sont contentés d'exploiter une bibliothèque de fonctions standard.

C'est ce qui a permis une émulation plutôt efficace de certains jeux peu après la sortie de la console avec UltraHLE. Le processeur MIPS de la console était émulé mais tous les appels à l'OS / la bibliothèque standard étaient interceptés et redirigés vers une réimplémentation vers la machine hôte.

Par contre sur d'autres machines (et pour d'autres jeux sur cette console), les choses sont beacoup moins standardisées.

Sur les jeux et consoles modernes, par contre, on retrouve les mêmes technologies un peu partout. Il est donc plus facile d'intercepter, disons, les shaders et les appels à OpenGL.

La dernière console à disposer d'un matériel vraiment spécifique doit être la PS3 avec ses processeurs "cells"?

Il s'agit uniquement du circuit imprimé de la carte mère. Il faut fournir tous les composants à souder dessus, que vous pourrez difficilement trouver à moins de les dé-souder d'une console existante pour les plus importants (conçus spécifiquement pour Nintendo et pas commercialisés par ailleurs).

En revanche la compatibilité avec la console originale devrait être de 100%, pas d'émulation douteuse ici!

Je crois qu'on peut facilement remplacer "l'IA" par "internet" dans cet article pour avoir la version d'il y a 20 ans. Ou alors par "langage de programmation structuré" pour avoir la version d'il y a 40 ans quand les gens pensaient que comprendre et maîtriser son code, ça voulait dire tout écrire en assembleur.

Aujourd'hui beaucoup de mes collègues seraient bien en difficulté pour travailler sans internet, et moi-même je serai beaucoup moins efficace s'il fallait tout faire en assembleur.

Mais au final, le gros du travail, ce n'est pas d'écrire le code. C'est surtout de comprendre ce qu'il faut que le code fasse, vérifier qu'il n'y a pas d'incohérences, essayer de penser à tous les cas imprévus, et structurer tout ça de façon à ce que ça puisse être calculé efficacement par un ordinateur. Il se trouve que l'écriture sous forme de code m'aide à réfléchir à ces problèmes et à structurer les choses. Je ne pense pas pouvoir y parvenir en discutant avec une IA. Peut-être que d'autres personnes y parviendront mieux de cette façon. Peut-être que ça remplacera les développeurs, mais plus probablement qu'avant ça, ça remplacera ou complétera les applications no-code et les tableurs Excel avec des macros compliquées?

Et, comme beaucoup de choses en informatique, on en est à l'étape où tout le monde essaie d'en mettre partout, il faut attendre un peu que ça se décante et voir ce qui est utile ou pas, avec un peu de recul. Et aussi ce qui est économiquement rentable et écologiquement viable. Moi, c'est surtout ce dernier point qui m'inquiète, parce qu'avant d'être un développeur, je suis d'abord un être vivant organique qui a besoin d'une planète et de son écosystème en bon état de fonctionnement. Sinon, l'IA devra se débrouiller sans moi.

Le risque principal à mon avis, c'est le vol ou la suppression des données de l'utilisateur. Le système étant pensé pour un seul utilisateur, il n'y a pas vraiment les problématiques que se pose unix, qui consistent à protéger les utilisateurs les uns des autres.

Il faudrait surtout protéger les applications les unes des autres, ce qui est un problème assez différent et pour lequel Haiku dispose déjà des protections les plus classiques (mémoire virtuelle, etc) même s'il y a royen de faire beaucoup mieux.

J'utilise Haiku comme système principal sur mes machines depuis au moins 10 ans. Il est fonctionnel, et je ne suis pas le seul à faire ça, certains utilisateurs ont même migré directement depuis BeOS ce qui doit donc leur faire une trentaine d'années d'utilisation au total.

Personellement c'est mon système d'exploitation principal et je n'en voudrais aucun autre à la place.

Mais sinon, en effet cela n'a aucun rapport avec le fait que le code soit sous license libre. Il me semble que MorphOS, un système hropriétaire et commercial avec une popularité comparable, ne fait pas mieux. Il me semble aussi que des projets libres comme Mozilla dépensent des millions dans des sujets douteux ou simplement dans la rémunération de leurs directeurs.

Dans le cas de Haiku, ce budget réduit est un peu volontaire: c'est lié au fait que le système ne soit toujours qu'en version beta au bout de 25 ans. On est bien en dehors des normes de productivité habituelles du monde moderne, et il y a peu de publicité pour attirer des utilistaeurs pour l'instant (on cherche plutôt des développeurs). Et peut-être qu'un projet open source, ou plutôt sans vocation commerciale (ce qui n'est pas lié), est une bonne façon de se permettre une telle folie. Le tout sans trop de pression et de responsabilités ou de comptes à rendre à qui que ce soit.

Ça dépend comment le contrat est négocié.

Ceux de Haiku inc sont assez peu ciblés avec des buts comme "améliorer fonctionner le navigateur web" ou "travailler sur tous les problèmes qui sont dans la feuille de route pour la version 1". Comme les personnes employées ont toute la confiance du reste de l'équipe, cela fonctionne assez bien.

Par contre, c'est vrai que certaines des idées les plus innovantes (voir presque farfelues) dans Haiku sont venues de personnes qui n'étaient pas payées pour cela. Ce n'est pas forcément une fatalité, mais plutôt que Haiku inc va avoir tendance à établir des contrats pour les tâches que personne ne veut faire.

Pourquoi personne ne veut faire une tâche? Soit parce qu'elle est ennuyeuse et avec peu de retours (refactorisation d'une partie du code qui ne va pas immédiatement apporter de nouvelles fonctionalités), soit parce qu'elle demande un investissement de temps trop important (il y a certains problèmes que je ne parviens pas à corriger simplement parce qu'il me faut 2 jours pour me remémorer toutes les discussions, relire le code, me souvenir comment ça fonctionne et ce qu'il faut changer, et après le week-end est fini).

D'autre part, il me semble que Waddlesplash développe certains projets pour ou avec Haiku qui ne sont pas financés par Haiku inc, et c'était également mon cas lorsque j'étais employé par Haiku. Si le contrat ne définit pas un nombre d'heures fixe par mois, c'est donc tout à fait modulable en fonction de la motivation et/ou du besoin de gagner des sous.