ufoot a écrit 738 commentaires

<i>> En clair, tu compiles ton kernel avec le support USB/AUDIO/OSS et le driver son sur USB standard
Merci pour l'info, j'avais pas percuté qu'il y a une interface usb-audio standard (*). C'est cool en fait! Du coup je vais peut-être l'acheter ma carte USB qui numérise tout bien comme il faut, une fois que j'aurai les sous 8-) Merci pour les conseils en tous cas. M'enfin je vais déjà essayer de m'installer alsa avec ma carte PCI "de base" actuelle. Si j'y arrive pas faudra que je potasse encore un poil avant de me faire vraiment plaisir en achetant un monstre qui fait du 96KHz. Sinon je suis d'accord avec toi, la table de mixage ça fait faire des économies pour mixer, par rapport à une carte multipiste. Par contre ça peut être utile dans certains cas d'enregistrer certaines pistes indépendemment et de mixer après coup, bien tranquillement.

(*) http://www.alsa-project.org/alsa-doc/doc-php/template.php3?company=(...)

Ou bien peut-être: http://www.mobil.com/(...)

<i>> DirectX, 1er layer standardise
DirectX, exemple typique de layer ultra-propriétaire dont il n'exite qu'une seule implémentation (*) pour un seul OS pour une seule architecture matérielle (Microsoft/Windows/i386). Ah oui, j'oubliais, l'API change tous les ans (et encore je suis gentil car entre 1995 et aujourd'hui y'a pas tout à fait 9 ans...) comme ça c'est plus pratique tu dois changer ton code tous les 10 mois pour rester au goût du jour. Evidemment tu peux faire tourner ton code DirectX 3 sur un DirectX 9. Le problème, c'est que pour déboguer un code DirectX 3 aujourd'hui, c'est pas pratique de trouver de la doc...

Pour ne rien gacher, quand tu développes avec DX tu es obligé d'accepter tout un tas de clauses plus ou moins désagréables, et tu n'as aucune garantie que le toolkit restera disponible. Comme d'hab, confiance aveugle à l'éditeur, aucune garantie en terme de perennité etc.

(*) bon, là-dessus je suis un poil de mauvaise foi car il existe Wine et MacDX qui permettent de développer en DirectX sur autre chose que du Window/i386 et ne sont pas édités par MS. Ceci dit ces produits, malgré tous les efforts fournis, ne font pas de DX une véritable outil multi plate-forme. Au mieux ils permettent de bidouiller pour faire marcher tant bien que mal des jeux existants.

> Gestion des cartes multi-sorties
Je me suis renseigné sur la question récemment car j'ai envie à terme de pouvoir faire de l'audio de manière intensive sous Linux, et je suis tombé sur ces cartes:
http://www.midiman.com/products/m-audio/delta.php(...)
Il semble que les delta 44 et 66 soient supportées sous Linux, au moins par Alsa. En tous cas le constructeur mentionne Linux dans la liste des OS supportés par ces cartes. Si la carte USB était supportée sous Linux j'en aurais acheté une direct, mais bon apparemment c'est pas encore le cas. En tous cas le matos a l'air correct. Après, savoir quels sont les logiciels sous Linux qui permettent de gérer plusieurs périphs /dev/dspX de manière efficace, c'est un autre problème je pense.

Quelqu'un aurait-il une expérience concrête d'une de ces cartes? D'avance merci.

Effectivement, cette annonce renforce l'effet "guerre propre" - forcément une cyber-attaque c'est pas très meurtrier - alors que la réalité risque bien d'être différente, à savoir une bonne vieille guerre comme savent faire nos belles démocraties modernes: bombardement aérien des zones civiles, on massacre allégrement tout ce qui est en dessous (femmes, enfants, vieillards...). Par contre c'est vrai que c'est propre, les pilotes d'avion n'ont pas de sang sur les mains, à moins de se blesser avec leur manche à balai.

C'est assez désolant de voir que les américains n'ont pas su tirer les leçons du 11 sept, ils n'ont manifestement toujours pas compris que pour avoir des renseignements et une action efficace dans ce genre de pays, ce qu'il faut c'est des informateurs et des hommes de terrain. Ils pourront sniffer tous les réseaux IP irakiens qu'ils veulent, il n'apprendront pas le quart du centième de ce qu'ils apprendraient en écoutant les conversations à la sortie d'une mosquée. Ceci-dit des agents irako-américains ça doit pas courrir les rues. Pensez-vous, ils sont tous arabes, donc louches! Dur dur d'être à la CIA...

Je vote pour! 8-)

Il est clair qu'aujourd'hui à un moment ou à un autre (par exemple à l'installation) tout ordi a besoin d'une personne compétente pour s'occuper de lui, indépendemment de l'OS.

Pour ce qui est d'installer GNU/Linux chez un particulier - un ami par exemple - on se retrouve vite devant le problème: il faut quelqu'un qui s'y connaisse pour pouvoir maintenir/faire évoluer la machine, typiquement lors d'installation de logiciels. Il se trouve que certains tiennent comme acquis qu'un ordinateur devrait être simple et facile à utiliser/administrer, et que même quelqu'un dôté du QI d'une huitre devrait pouvoir manipuler le bidule.

Pourquoi?

Il y a plein d'outils qui ne sont pas faciles à manipuler, et on apprend à le faire. Par exemple, on passe son permis pour conduire. Autre exemple, avant d'écrire, il faut savoir se servir d'un stylo. Ca a l'air de rien, mais c'est super technique de se servir d'un stylo. Essayez de la main gauche (droite pour les gauchers) et vous mesurerez l'ampleur de l'apprentissage.

Alors certes, ce "serait bien" si on pouvait écrire, conduire sans danger, et installer un serveur IMAP sans avoir à rien apprendre. Mais bon, l'informatique reste pour moi un domaine comme les autres, à la différence près que certains commerciaux ont réussi à faire rentrer dans la tête des gens que c'était simple comme chou.

Je reste convaincu que le progrès passe par un certain apprentissage. Sans aller jusqu'à savoir comment administrer un système UNIX, je pense qu'on gagnerait à ce que les gens apprennent à cerner le fonctionnement global de leur ordi. Simplement pour éviter le "ça marche pas mon ordi est planté j'ai tout cassé" alors que c'est juste le câble réseau qui est débranché... Mais évidemment c'est pas facile quand on entend tous les jours qu'avec un Pentium IV on surfe plus vite sur le grand Ternet. En fait, pour peu que l'on ait un minimum de connaissances théoriques sur le fonctionnement d'un ordinateur, l'installation d'un OS (genre une Mandrake avec sa boiboite et son bouquin) devient AMHA abordable. Il faut faire la différence entre les mémoires permanentes, celles qui sont volatiles, et dépasser le cap de "c'est dans l'ordinateur". Sans vouloir faire de tout le monde des informaticiens - il y a plus urgent, par exemple réduire l'analphabétisme - je trouve qu'à notre époque ce n'est pas idiot de se dire que tous ceux qui utilisent des ordinateurs sachent un peu comment ça marche.

Entendons-nous bien, je ne veux pas bombarder tout le monde gourou Unix, simplement se dire que si quelqu'un se sert d'un ordinateur toute la journée - et c'est le cas de pas mal de monde - ça ne peut pas faire de mal à sa culture générale d'apprendre un peu les concepts liés au bidule. Une secrétaire qui tape toute la journée des documents qui sont stockés sur un serveur réseau gagnerait AMHA à savoir un peu comment ça marche. Mais on peut se contenter de lui dire: tu fous les documents là-dedans! C'est sûr, ça marche. On peut pas dire le contraire.

Maintenant, ce n'est pas dans l'air du temps, on vit à une époque où il faut tout pouvoir utiliser tout de suite sans effort sans investissement sans rien. A ce jeu là on se fait pourrir sa boîte mail Outlook par un vilain virus et on devient à terme dépendant soit du geek du coin de la rue soit de Microsoft, mais dans tous les cas je suis pas sûr qu'on y gagne... Cette culture de l'utile et de l'efficace et du rapide a le don de m'agacer. A ce train là, bientôt on arretera d'enseigner l'Histoire à l'école car ça n'a pas d'application concrête en entreprise sauf dans certains métiers précis.

C'est aussi un peu parce que les gens ne comprennent pas comment leur ordinateur fonctionnent qu'ils n'arrivent pas à voir le danger et la portée d'initiatives comme DRM.

> les CMS font partie des choses à éviter…

Bah euh oui mais le linuxfr actuel est bien un CMS, templeet ou pas templeet… Concrêtement il rend les mêmes services (dans l'esprit au moins, pas dans le détail) que le bon vieux daCode d'antant. AMHA http://templeet.org (NdM: remplacé en 2021 par un lien vers archive.org) + http://linuxfr.org/template/ => un CMS.

C'est vrai que templeet est plus générique mais le site sur lequel nous sommes en train de discuter est bien un CMS, tu pourrais en théorie le décliner pour un autre site de news.

Ceci dit c'est vrai que daCode me semble plus immédiat et simple à mettre en place, c'est la solution du feignant… …donc celle que j'ai choisie 8-)

> quand verra-t-on enfin de nouvelles fonctionnalité dans le langage java? Je suis dans l'ensemble d'accord avec toi, mais je ne suis pas d'accord sur le fait que le changement est vraiment positif en soi. Le changement est positif quand il est vraiment nécessaire. Typiquement, passer du modèle de programmation structurée à celui de programmation objet nécessitait une mise à jour des langages de programmation ainsi que des techniques de développement en général. Maintenant, tant qu'il n'y a pas de concept révolutionnaire, je ne vois pas l'intérêt - hormis un intérêt purement intellectuel qui se conçoit bien en recherche ou en enseignement par exemple - de chercher à changer à tout prix. Le langage qui ferait économiser des sous à l'industrie aujourd'hui c'est un langage qui serait stable dans le temps, un langage où quand tu a un source il se recompile/s'interprète sans problème 10 ou 20 ans plus tard. Et y'en n'a pas beaucoup des langages comme ça... Dans cette catégorie, C est encore un des moins mauvais, même s'il triche un peu en venant avec une bibliothèque standard ridiculement petite par rapport à d'autres langages.

Oui mais les entreprises profitent des étudiants produits par les universités...

> La surcharge d'opérateur Ca ça existe en C++ non? Bon, sinon, OK, C# vient avec quelques améliorations, mais pas vraiment de "concepts" nouveaux. Pour moi Java et C# sont très voisins, ils jouent dans la même catégorie. Ce sont des langages objets, compilés, avec une VM, etc. Des langages différents sont par exemple: Python et Cobol => rien à voir. Ou bien, Matlab et Prolog. Ou encore, l'Assembleur et les scripts Bash. La tu tapes vraiment des concepts différents. Mais Java et C# ça rentre dans le même moule. C# est une amélioration de concepts pré-existants, pas une innovation radicale. En cela il est le digne représentant des produits Microsoft. Avec tout ce que cela comporte de bien (produit qui arrive sur le tard donc bénéficie de l'expériences des pionniers), et de mal (produit qui arrive à la bourre sur le marché et d'une perennité plus que douteuse).

Je pense qu'en fait on est d'accord sur l'état d'avancement de Mono: Release 0.19 Jan 20th, 2003 Ca confirme (je pense) mon affirmation (peut-être mal formulée): ça avance (il y a des releases régulières/récentes, disponibles en téléchargement) mais c'est pas fini (version 0.19). Je ne pense pas qu'il soit raisonnable aujourd'hui de faire tourner un serveur de production sur une architecture Mono. > Le nom du package n'est pas 'C#' mais 'mono' - comme monopole, c'est facile a retenir :-) Désolé pour le "apt-get install C#", je suis d'accord, j'étais un peu de mauvaise foi sur ce coup-là 8-)

> les investissements de recherche sont considérablement plus élevés. Les investissements de recherche plus élevés dans la médecine que dans le logiciel? Dans l'absolu ou par rapport à la taille des marchés respectifs? Est-ce qu'on a vraiment: coût_de_la_recherche_pour_un_médoc/coût_de_fabrication_du_médoc > coût_de_la_recherche_pour_un_logiciel/coût_de_fabrication_du_logiciel Sachant que par coût_de_la_recherche_pour_un_logiciel j'entends l'investissement avant commercialisation représenté par la conception le développement etc. et par coût_de_fabrication_du_logiciel le prix de revient du pressage d'un CD-Rom et de son emballage dans une boîte en carton. Je suis sceptique... > On pourrait imaginer des Open Medocs :) mais je doute que l'infrastructure de recherche nécessaire permette la généralisation d'une telle pratique :) En fait, ce qui bloque entre autres c'est le fait que tout est breveté et verrouillé en médecine. Les activités qu'on ne peut pas faire en environnement "non rémunéré" sont celles qui demandent du matériel. Mais le dépiotage informatique de données relatives par exemple au génôme humain, on pourrait très bien le faire en "amateurs". Sauf que cette possibilité est écartée car des brevets sont déposés dans ces domaines. Les entreprises qui vendent des médocs se sont appropriés cette connaissance et la gardent jalousement, au détriment de tous les autres.

L'exemple du médicament est extrèmement mal choisit, car c'est un exemple typique où "l'énorme investissement de R&D consenti par l'entreprise privée" n'améliore pas toujours le progrès, y compris social. Citons par exemple les médocs pour le SIDA qui sont à des coûts tellement prohibitifs que les africains n'ont aucune chance de pouvoir en profiter. Au nom d'un "manque à gagner" complètement fictif vu que les pays africains n'ont déjà pas un rond, sont endettés jusqu'au cou, et sont donc incapables de payer ces médicaments, on interdit la production de médicaments génériques. Pendant que nos bureaucrates se touchent la nouille pour savoir si oui ou non on autorise la diffusion de médicaments génériques pour les pays qui n'ont pas de quoi acheter les "vrais" médicaments, les africains meurent, par millions. J'ai pas l'impression que ce soit un progrès social fulgurant. Des pays comme le Brésil ont franchi le pas et dit merde aux US. Aujourd'hui ils sauvent des vies humaines, la contrepartie étant un chiffre d'affaire moins élevés pour les grands groupes pharmaceutiques. Pour moi y'a pas photo, le non respect des brevets dans ce cas là est *la* bonne idée. L'idée "oui mais si on supprime les brevets l'innovation va disparaitre" est peut-être bonne mais elle n'est pas prouvée. Elle est à ranger à côté de l'idée "si on supprime la rémunération à la copie des logiciels il n'y aura plus de création de logiciels". On a prouvé que cette dernière était fausse, les LL en sont un bonne exemple. Alors certes je ne peux pas prouver que si on supprime les brevets l'innovation va continuer, encore que je suis pas sur que le concept de brevet soit vieux de 2000 ans... Tu décris le cycle de création d'un médicament comme un cycle impliquant un fort coût de R&D et un coût de production de masse très faible. C'est comme les logiciels alors?

> c'est pas parce qu'il a été créer par microsoft que c'est forcement de la merde.

/home/ufoot# apt-get install "C#"
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package C#

Hum hum, je sens qu'il va falloir que j'attende un peu. Je suis allé voir du côté de Ximian, ça avance mais c'est pas encore fini. Comment on appelle ça les produits qui sont "bientôt près mais pas encore mais vous en faites pas ce sera mieux que le reste"? Ces produits qui sèment le doute, l'incertitude, voire même la peur chez les utilisateurs de produits concurrents, à qui on explique que ce qu'ils utilisent pour l'instant, c'est vraiment pas si terrible que ça et qu'ils vont se mordre les doigts de pas avoir migré. Fear, Uncertainty, Doubt... Je l'ai dit? Bon je l'ai pas dit fort alors.

Bon, sans rire, C# est peut-être un bon langage, mais il arrive trop tard. Il n'a que très peu de différences fondamentales avec Java, et il partage ce gros défaut: il est ultra-dépendant d'un éditeur particulier. Rien que pour cette raison je vais le bouder, NA!

> Le chercheur n'est là que pour fournir un travail, lui est déjà payé, qu'il trouve ou non (et dans la plupart des boites il y a des primes pour les brevets déposés).
Pourtant, c'est bien lui, le chercheur, qui, au bout de la chaîne, est à l'origine très concrête de l'invention.

On pourrait imaginer un modèle où le chercheur est *la* personne à qui le brevet profite. Ou éventuellement à l'équipe de chercheur qui est à l'origine de l'invention. Ce système ne serait d'ailleurs pas sans rappeler l'informatique à ses débuts, où les programmeurs détenaient des droits sur leur code, et ne cédaient pas tout à leur entreprise mais bon... Donc bref, imaginons un tel système: un type invente quelque chose, il dépose un brevet et hop il impose ses conditions. Très rapidement on s'aperçoit que ça va coincer: c'est le bordel! Si un de ces collègues veut utiliser son invention il va devoir lui payer des royalties, cela va gérer de la facturation interne à la boîte et d'une manière générale on met le doigt dans un engrenage bureaucratique infernal qui s'auto-alimente. Ca chie quoi.

Donc qu'elle est l'alternative actuellement utilisée? Eh bien c'est simple, on collectivise. On considère que l'invention est la propriété d'une personne morale (l'entreprise) et au sein de cette entreprise tout le monde fait ce qu'il veut. L'inventeur lui, renonce à ses droits en bloc. On constate qu'il continue à inventer des choses car finalement c'est son job. Donc la personne physique qui invente n'en n'a à peu près rien à foutre de pouvoir utiliser le levier de pression qu'est le brevet pour rentabiliser à mort son invention. Finalement, son but est ailleurs, et dans tous les cas il a tout intérêt à trouver des choses innovantes car il y gagne:
- ponctuellement car il peut bénéficier d'une prime
- en terme d'image car il sera mieux vu de son patron, ses compétences sont reconnues
- a titre personnel car son emploi est mieux garanti dans la mesure où il est parmi les (sinon le) plus compétent dans son domaine
- sur le long terme car son invention représente de toutes façons une avancée pour l'humanité en général, rien ne sert d'emporter son secret dans sa tombe...
Et donc l'inventeur est prêt à partager son invention avec son entreprise, et à renoncer à tous ses droits.

Soit.

Maintenant ce qu'il faut savoir c'est que les entreprises sont de plus en plus grosses. Concrêtement le type va partager son info avec 10000, 100000, peut-être 1000000 de personnes (si on n'y est pas déjà, on y arrivera un jours...).

Donc on peut se poser la question, pourquoi est-ce que c'est la personne "entreprise" qui est retenue pour définir la portée d'un brevet (portée au sens: qui peut l'utiliser sans contraintes)?. Pourquoi ne pas élargir encore le cercle? Pourquoi est-ce qu'on ne choisirait pas plutôt la personne morale "pays" (sachant que certains pays sont plus petits que certaines entreprises...) ou bien même la personne morale "humanité"?

Concrêtement, ce qu'on voit émerger aujourd'hui, c'est un "engrenage bureaucratique infernal" tel que je le décris plus haut, où des entreprises déposent et déposent des brevets et se privent d'un partage efficace de l'information. Elles ont bien compris que ce partage était bénéfique en interne, mais elles ne voient pas dans quelle mesure il serait profitable à grande échelle. Elles réfléchissent comme l'inventeur avare de ses idées qui se dit dans son coin "hin hin hin je vais garder mon idée pour moi et je vais niquer tout le monde".

Alors certes cette optique a le mérite de cultiver la compétitivité, mais au final je reste convaincu qu'on y perd. Typiquement, si on imagine qu'il y a une deuxième "terre" (Mars attacks!) avec des industriels à côté de nous, et que la lutte économique s'installe, on peut se dire qu'il vaudrait mieux tous s'unir entre terriens car l'union fait la force (comme l'oignon fait la soupe) et s'organiser ensemble plutôt que de se chamailler à savoir qui a inventé quoi.

Et même à ce moment là, on pourrait se demander, pourquoi ne pas collaborer avec les aliens d'en face?

Alors effectivement supprimer les brevets priverait les entreprises de certains revenus, mais d'un autre côté ça allègerait leurs dépenses... Et puis dans tous les cas une société innovante pourrait toujours tirer des avantages d'une invention:
- ponctuellement car elle peut bénéficier d'un avantage concurrentiel et vendre des produits à coût élevé, le temps que les concurrents assimilent la techno
- en terme d'image car elle expose clairement sa compétence de manière publique, notamment auprès des actionnaires potentiels
- a titre personnel car elle se place d'emblée dans la catégorie la mieux placée pour assurer du support, proposer des évolutions, industrialiser son invention, etc.
- sur le long terme car son invention représente de toutes façons une avancée pour l'humanité en général, rien ne sert d'emporter son secret dans sa tombe...
J'ai pas déjà écrit quelque chose de similaire plus haut? Suffit de changer d'échelle, c'est tout.

Concrêtement, je pense que les brevets profitent essentiellement aux entreprises, au détriment des individus, des états, et du monde en général. De là à penser que ce sont les entreprises qui dictent les lois aujourd'hui il n'y a qu'un pas. Pour d'autres exemples confirmant ce point de vue, cf DMCA et l'EUCD par exemple...

D'ailleurs, au passage, pour ce qui est de ma fantaisie avec la 2ème planète en face de la notre, les aliens, la collaboration et tout ça, essayez de parler avec un éditeur de logiciel propriétaire. Expliquez-lui le concept de Logiciel Libre, de travail communautaire, etc. Dites-lui que certains ont laissé des milliers d'heures de travail informatique à disposition, souvent gratuitement, même pendant des périodes où trouver du travail en informatique était trivial. Vous verrez, il aura l'impression que vous venez d'une autre planète. C'est bien connu, les linuxiens n'ont pas les pieds sur terre 8-)

Si je me rappelle bien, sur HP48, RFP était composé de 2 programmes: le décompresseur faisait à peu près 700 octets, et le compresseur environ 2K, mais comme le compresseur était lui-même compressé et utilisait de décompresseur avant de s'éxécuter vraiment on arrivait à un total d'à peine plus de 2K. Les fichiers textes se compressaient plutôt bien, et concrêtement, et il me semble que j'arrivais à produire des fichiers compressés représentant à peu près 40% de l'original. C'est certes moins bien qu'un vrai bon vieux bzip2 avec lequel on peut souvent descendre à 20%, mais c'est déjà pas mal. Sur un fichier de 8K par exemple, tu peux imaginer tomber à 3,3K et il te reste 0,7K pour loger le décompresseur.

A part ça AMHA ce genre de technique n'est pas hyper fair play ni élégante. Contourner le règlement c'est toujours possible mais là n'est pas le but. D'un autre côté la plupart des démos vraiment petites utilisent de manière non modérée toute la panopile de compressions et d'astuces qui sont à leur disposition. Donc...

Pour info, RFP est dispo ici: http://www.hpcalc.org/details.php?id=2369(...)
Et le "code source" est dispo dans la mesure où c'est un programme en assembleur, donc du coup pas besoin de déssassembler pour remonter au source 8-) Sinon, l'assembleur HP48 c'est pas ce qu'on fait de plus lisible, ça a beau être du Motorola (ie beaucoup plus sympa qu'Intel) les registres de 64 bits découpés en quartets couplés à un mode d'adressage datant de l'époque de Néanderthal (traduire -> il faut charger à la mimine les registres d'adresse avec des adresses calculées/contenues au préalable dans les registres de calcul, qui ne sont évidemment pas les mêmes, ce serait trop simple) ça a tendance à rendre le code un poil compliqué.

> le réchauffement de la Terre n'est pas une théorie alarmiste, c'est un fait expérimental
De même que le tarissement inévitable des ressources fossiles, qui une fois qu'il sera arrivé à terme posera de sérieux problèmes pour fabriquer des textiles (faudra s'habiller avec du coton ou de la laine, sale temps pour les noirs et les moutons!), des plastiques (c'est qu'il va falloir en couper des arbres pour faire des sacs en papier et remplacer toute la menuiserie PVC par du vrai bois comme dans l'temps), et plein de choses encore.

Et effectivement, n'importe quel calcul objectif montre que sans spéculer ni théoriser on arrivera un jour, de manière évidente, à se retrouver sans une goutte de pétrole ni un grain de charbon exploitables sur le globe.

Un peu comme le réchauffement de la planète.<cynique>Tant que les Pays Bas ne seront pas engloutis par la Mer du Nord la plupart de nos dirigeants continueront à s'en foutre royalement (je prends les Pays Bas comme exemple car le Bengladesh ça compte pas vraiment).</cynique>

Ouais ceci dit je me rappelle d'un excellent hors-série informatique de Fluide Glacial où ils expliquaient comment remplacer sa carte graphique par une saucisse de morteau. D'ailleurs je vais essayer de retrouver le canard en question et de le scanner - avec le scanner mentionné dans mon post ci-dessus - pour vous montrer ça 8-)

> vu le nombre de personne qui achètent des NVidia
Il n'y a pas que les cartes graphiques dans la vie. Par exemple j'ai acheté un scanner USB récemment et on peut le dire, mon critère de choix principal a été le support du bidule sous nunux, sans driver binaire propriétaire évidemment... Mon choix s'est porté sur Epson en grande parce que le scanner en question marchait bien avec sane.

Je nourris l'espoir secret de faire réapparaître le concept de la boule qui roule sous Linux, dans le cadre d'un nouveau jeu un tantinet plus ambitieux, mais bon c'est à l'état de pré-pré-pré-alpha et l'idée émerge péniblement. Mais ça arrive 8-)

> et sous Ouindows (les fuites mémoires se verront immédiatement)
Indépendemment de la qualité de Windows, il est 100% vrai que lancer un programme sous différents OS et/ou processeurs permet de bien mettre en évidence certaines erreurs de programmation liés à la gestion de la mémoire. Concrêtement, les erreurs les plus chiantes sont celles "qu'on ne voit pas" mais qui se déclenchent de temps en temps. Et le bug peut ne jamais apparaître sur une config donnée - en général celle du développeur vu que s'il avait vu le bug il l'aurait corrigé. Perso, quand je développe des programmes Windows, j'essaye - quand c'est possible - de les faire tourner sous wine. Si ça passe, c'est bon signe 8-) Pour les programmes UNIX, rien ne vaut un bon test sur plusieurs distribs, plusieurs machines, plusieurs OS (Linux, FreeBSD,...) et idem, si ça passe c'est bon.

J'ai récemment fait le port d'un programme pour FreeBSD, et bien j'ai mis le doigt sur un bug qui arrivait 1 fois sur 10000 sous GNU/Linux. Je savais qu'il existait mais ne pouvait le reproduire facilement sous Linux. Sous BSD, impeccable, taux d'échec de 100% donc j'ai pu cerner le problème et le corriger. Et pour le coup, un valgrind ne m'aurait pas beaucoup aidé vu qu'il n'y avait aucune fuite ni dépassement mémoire ni rien de ce genre. Enfin pas concernant ce problème particulier... Simplement, la génération de nombres aléatoires n'est pas la même sous Linux et sous BSD, et comme sous Linux elle est assez reproductible (!) je ne tombais jamais dans le cas foireux.

> "recompilent-ils tout kde à chaque fois qu'ils changent une ligne ?"
Et d'ailleurs je me demande si ça vaudrait pas le coup de faire plus de choses en script au niveau des IHMs. Typiquement, sur une IHM, ce qui doit être rapide, c'est les routines d'affichage, donc ce qui concerne Qt, et puis pour le reste la plupart des choses peuvent se scripter. Genre l'aspect "si je clique sur ce bouton alors ça lance tel bout de programme" peut se faire en script, l'affichage du bouton et le bout de programme étant eux des binaires. C'est à priori le genre de solution retenue par tcl/tk par exemple, et à part le faire que tcl est un peu pas super moderne et que tk est super moche je pense que c'était une bonne idée. Mais les IHMs 100% C++, je pense pas que ce soit une riche idée, entre autres parce que le temps de compilation est rédhibitoire.

> par manque de modéros à cette période, elle est restée en attente
Oarf c'est pas très grave de toutes façons, pas besoin de se justifier. Perso, l'annonce des résultats direct sans avoir été prévenu du vote avant ne me choque pas vraiment plus que ça.

> le concours n'etant pas super connu
Bah oui, en fait j'ai appris l'existence du concours parce qu'un pote m'a envoyé un mail il y a quelques minutes. Je le soupçonne d'ailleurs de lire LinuxFR et d'avoir découvert le concours aujourd'hui lui aussi 8-)

Bon, enfin maintenant je vais pouvoir passer une news sur mon site, personne ne pourra m'accuser d'avoir fait de la pub ;-P