Aldoo a écrit 2794 commentaires

... du pipotron !
http://www.w3perl.com/fun/management/pipotron.html

Non franchement, attendre un jour de plus pour poster ce journal, ce n'était pas difficile, non ?

Oui, c'est vrai que ça a bougé récemment, après des années de galère. Cela dit, il faut du temps pour qu'un bugfix se propage à la version distribuée !
Apparemment, ils considèrent ça comme un changement suffisament important de comportement pour ne pas le backporter dans les branches 1.5 et 2.0... Bon, je ne sais pas à quel point c'est justifié, mais c'est clair qu'en général, il vaut mieux être patient, avec les produits Mozilla.

Pour la petite histoire, c'est intéressant de voir que la plupart des gens se réveillent en général quand une nouvelle version est imminente, pour apprendre que le changement ne pourra de toute manière pas être appliqué à la prochaine version. Après cette déception ça se calme... au point que plus rien ne bouge... jusqu'à ce que la prochaine version soit imminente. Et ainsi de suite.

Ma formulation est purement rhétorique. Effectivement on peut faire plusieurs choses en même temps (par exemple développer simultanément une killer app pour windows et un bouzin pour linux).

Mais bon, si on fait des demandes sur plein de trucs à la fois, les demandes les plus essentielles risquent d'être inaudibles.

Pour le choix des priorités je me baserais plutôt sur des arguments pragmatiques tels la sécurité :

Tout périphérique de communication dont le fonctionnement est obscur est une faille potentielle (à moins de ne lui envoyer que des flux cryptés, et encore ! En plus il faudrait que la norme de cryptage soit reprise à l'autre bout. Pas sûr que ça intéresse mon FAI !).

Par contre, que ma carte graphique ou mon ventilateur USB utilisent un firmware non libre, ça me dérange moins ! (alors oui, on pourrait imaginer la carte graphique envoyant des fréquences spéciales dans le tube cathodique afin d'envoyer des signals codés à la NSA... avouons que ce serait un peu capilotracté ! Quoique... j'avais vu un journal sur un émetteur TNT bricolé à partir d'une carte graphique... ).

Tiens, pareil sur mon AMD sous Gentoo. En fait, le plantage c'était que la musique s'arrêtait toute seule au bout d'un moment (quel que soit le backed), mais la GUI ne freezait pas avant que j'appuie sur un bouton (comme "play" ou "stop", par exemple).

Aujourd'hui, sur mon Core Duo sous Ubuntu, aucun problème.

Cela dit, je n'ai jamais réussi à isoler d'où ça venait, et je n'ai jamais vu une seule allusion à ce problème dans les forums.

Pas franchement le contraire de ce que je dis...

Le html sert à être rendu partout. Quand je dis de manière "plus ou moins pareille", je veux dire que l'essentiel y reste. Je n'ai pas parlé de rendu identique à la pdf.

Maintenant, la notion d'essentiel évolue. Dans l'idéal d'aujourd'hui, l'essentiel c'est la sémantique et les informations utiles contenues qui seront restituées d'une manière ou d'une autre sur tout logiciel, tout périphérique de consultation. La présentation, elle, varie énormément.

Cela s'oppose aux formats de travail bureautiques, où il n'y a pas de notion claire de ce qu'est l'essentiel (ce qui, je l'espère devrait changer avec les formats standardisés).

Pour le coup du premier butineur/éditeur, je ne savais pas. Cela dit, éditer du html est de toute manière facile (au pire avec un éditeur de texte).

Avant d'implanter des fonctionnalités super compliquées, ce serait déjà bien pour Wikipédia que FF répare une bonne fois pour toute cet ancestral bug de remplacement des espaces insécables qui détruit les mises en page de Wikipédia !

https://bugzilla.mozilla.org/show_bug.cgi?id=218277

Ceci dit, même avec l'ancienne API, est-ce qu'il n'y aurait pas moyen de mieux l'utiliser ?

Quelques exemples :

- gestion de la molette : quand je fais défiler une page à toute vitesse, si mon curseur de souris a le malheur de passer par dessus une applet flash, le défilement s'arrête, grrr !!!

- choix d'un wrapper audio (aoss ou autre) pour les plugins utilisant l'architecture obsolète OSS, afin de profiter du software mixing : combien de fois on rage de ne pas avoir lancé firefox dans un tel wrapper et de ne pas pouvoir avoir le son dans youtube parce qu'on avait lancé amarok avant de lancer Firefox ?
(au passage, konqueror propose d'utiliser arstsdsp... ce qui à la base est à peu près ce que je cherche, sauf que je ne veux pas utiliser arts ! Pourquoi ne laissent-ils pas le choix ?)

- ça rejoint un peu le problème avec la molette, mais avoir un moyen d'obtenir le menu contextuel de firefox en cliquant sur une inclusion gérée par un plugin, ça pourrait être pratique aussi. "tiens ce swf me plait ! paf ! clic droit, enregistrer sous ! Bon, il faudrait songer à un moyen pour continuer à pouvoir faire l'action prévue par le plugin pour le clic droit (menu de flash, par exemple).

Sinon, dans le cadre d'une nouvelle architecture, ce serait bien que ce soit FF qui gère l'affichage du menu contextuel, avec éventuellement des éléments supplémentaires proposés par le plugin via une API adhoc.

Au final c'est l'utilisateur qui est gagnant : il peut communiquer avec l'État en utilisant à peu près n'importe quelle suite bureautique de son choix.

Donner le choix, ce n'est pas un peu ça aussi, l'esprit du libre ?

De plus, vu que ODF est le format natif de OO.o, il sera est très bien supporté par cette suite, qui aura alors une meilleure image qu'à l'époque où elle était testée avec des fichiers .doc 2 3 fois, avant de suivre le chemin de la désinstallation définitive.

Bon, ç'aurait été mieux que OO.o soit le logiciel officiel, mais il faut reconnaître que certaines habitudes sont dures à changer et que certains greffons (notamment pour l'accessibilité, argument mis en avant par MS) ne sont pas encore disponibles pour OO.o. Cela dit, vu qu'OO.o lit le format officiel, nul doutes que les greffons en question seront développés fissa.

Le firmware est logiciel, certes. Mais sa fermeture ne pose pas tous les problèmes éthiques que la fermeture de l'OS ou de ce qui tourne dessus : en effet les périphériques installés (avec ou sans firmware) sont toujours des boîtes noires du point de vue de l'OS. Au mieux on a des spécifs permettant d'implanter des drivers libres, mais on ne sait pas ce qui se passe dans la boîte.

Le problème principal est que vu que c'est du logiciel, le firmware a une licence, et il faut donc vérifier qu'elle est compatible avec le mode de distribution.

Bon, maintenant revenons au bénéfice supposé de l'ouverture des firmwares : à savoir la possibilité de personnaliser et compiler ses propres versions. Si certains périphériques peuvent se reprogrammer ainsi (ça s'est vu, nombreux exemples : WRT54G, Archos, Freebox, etc. ), beaucoup tournent sur des processeurs super spécialisés avec des optimisations parallèles réglées au quart de millipoil, à tel point que je me demande s'ils sont vraiment "compilés" ou juste assemblés. Enfin, même compilés depuis un langage de haut niveau, celui-ci doit-être certainement très différent de ce dont on a l'habitude, et qui plus est spécifique à chaque architecture. Autant d'architectures à ajouter à la liste déjà longue qu'il faut supporter quand on maintient une distrib...
(même s'il ne s'agit pas de faire du support pour un nombre aussi conséquent de paquets, il faut tout de même maintenir la chaîne de compilation croisée).
Cela n'est pas impossible, mais je dirais que c'est un peu hors sujet pour le distributeur Linux, dont le rôle est de maintenir un OS basé sur Linux, tournant sur un processeur de PC. Les firmwares ne font pas partie de cet OS ! Par contre, le logiciel qui envoie le firmware, éventuellement oui.

Qu'on ne me parle pas des firmwares basés sur linux tournant sur les périphériques cités plus haut ! Il s'agit de projets séparés dédiés à maintenir un firmware uniquement, et non un OS pour PC. Maintenant, dans le cadre d'un tel projet (ou tout autre projet de firmware libre), si le mainteneur décide d'intégrer un morceau de code non libre, il y a effectivement de quoi faire la gueule, puisque le projet de firmware était là avant tout un projet d'OS embarqué libre, c'est à dire de faire tourner du code libre sur le processeur embarqué.

Pour résumer ma position : OS (de PC) et firmware sont deux mondes séparés et il n'y a pas de problème éthique à utiliser simultanément du libre d'un côté et du proprio de l'autre (même si c'est mieux d'avoir du libre partout ;-) ). Juste un problème de distribution éventuellement.

C'est déjà plus ou moins fait ;-). Pas volontairement du moins.

En effet, il semblerait que le protocole ait déjà été rétro-ingénié, et même qu'un logiciel compatible ait été implanté : http://www.oreillynet.com/etel/blog/2006/07/skype_reverseeng(...)

Sinon, il y a ce pdf déjà connu qui fait le décortiquage en règle du protocole : http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-(...) .

Ah, j'oubliais : le jour où le matériel sera lui aussi libre, il est clair qu'il sera crucial que les firmwares le soient aussi, sinon à quoi bon ?

On ne parle pas de blobs, mais de firmwares, là.

La différence est de taille : l'un s'exécute sur le processeur principal avec tous les droits, l'autre s'exécute sur le périphérique concerné seulement (avec tous les droits sur le périphérique, mais ça s'arrête ici, si le module noyau correspondant est ouvert et bien foutu). Le résultat, c'est que le périphérique avec le firmware chargé revient finalement à un périphérique tout court, du point de vue du noyau.
On ne sait pas exactement ce qui s'y passe, mais ce serait pareil pour un périphérique sans firmware.

Le problème finalement, avec ces firmwares, est plutôt du côté de la distribution : en effet, la galette d'installation du système dit "libre" contient des morceaux non libres, et tu ne peux donc pas coller l'étiquette "libre" sur le CD. Sans compter qu'il est possible que certains firmwares aient une licence ne permettant même pas la redistribution...

Je ne suis pas trop au courant de ce qui se fait chez debian, mais ça m'étonnerait qu'ils autorisent le moindre blob dans leur distrib. S'il y a des intAIgristes, c'est bien eux !

Euh, petit bémol sur le HTML : celui-ci n'a pas été conçu comme format de travail, mais comme format pouvant être rendu "plus ou moins pareil" sur tout butineur web respectant "plus ou moins" les standards.

Cela dit, pour les pages statiques, c'est un format de travail aussi.

Non ! Non ! Rien de si compliqué !

Par "standard", j'entends police fournie avec OO.o. Ce qui implique évidemment d'en fournir un certain nombre !

Autre proposition, complémentaire : OpenOffice avertit l'utilisateur quand il utilise une police "non standard", avec une explication de ce que ça peut impliquer. La boîte de dialogue aurait évidemment la traditionelle case à cocher : "ne plus m'avertir à présent" pour pas que ça finisse par devenir lourd (ce qui n'empêchera pas de signaler les polices standard par un symbole bien visible dans la liste de sélection des polices).

Astronomes et astrologues étaient la même personne à l'origine, c'est vrai. Et ce n'est que depuis le siècle des lumières que les astronomes ne pratiquent plus l'astrologie.
Néanmoins, ce n'est pas pour autant que les "astrologues" d'antan ne se rendaient pas compte de la différence. Ainsi, si on en croit Bertolt Brecht dans la vie de Galilée (mais bon, à quel point cette pièce dit-elle la vérité ?), Galilée, "astrologue" on ne peut plus sérieux, écrivait des horoscopes auxquels il ne croyait pas le moins du monde parce que ça se vendait mieux que de dire que la Terre tournait autour du Soleil... Il fallait bien vivre !

Il y a bien des informaticiens sérieux qui sont développeurs Windows. Et bien c'est pareil.

@Pierre Muller : j'ai feuilleté ton site qui m'a l'air très documenté et propose de nombreux liens utiles.

Si je lance mon projet je pense qu'il va falloir qu'on travaille ensemble, ne serait-ce pour que je ne duplique pas bêtement le contenu de ton site.

Je pense que ce qui pourrait distinguer les deux serait :
- là ou R-D.org propose beaucoup de liens, mon wiki devra avoir une présentation plus synthétique, avec du contenu directement sur le site qui je l'espère deviendra plus une référence qu'un annuaire (référent). Néanmoins il faudra quand-même quelques liens vers les grands sites qui traitent du sujet (R-D.org, par exemple !)
- R-D.org a un message qui est "méfiez vous !". Mon projet devra avoir une présentation plus neutre. Ses articles démontreront des faits par 1+1=2 mais pourra être cité par des sites plus orientés (c'est un des objectifs).
- R-D.org s'intéresse à ce qui se fait effectivement dans le monde, et aux prises de positions des différents acteurs. Pour mon projet, tout cela peut-être cité, mais à titre anecdotique seulement.

Au fond mon projet serait un espèce de mini-wikipédia dédié à la technique du vote électronique, du moins pour une grosse partie du site. En effet, je n'exclus pas non plus que certains articles soient des essais plus "littéraires" sur l'éthique du vote électronique. Ces essais seront d'ailleurs nécessaires pour justifier la liste des bonnes propriétés attendues d'un système de vote électronique.

Mon projet ne prétend pas forcément réinventer la roue. Réussir à répertorier l'état des connaissances serait déjà génial. Cela dit c'est en répertoriant qu'on se rendra compte qu'il y a des trous à combler. Peut-être qu'on pourra alors envisager un appel aux spécialistes pour ce faire (si le site est attrayant, vu le nombre d'universitaires qui se sont impliqués dans le débat, je crois que ça peut intéresser du monde !).

Pour ce qui est du style, vu que l'objectif est de fournir des bases techniques aux argumentaires, il faudra réussir le pari d'être à la fois rigoureux (de vraies preuves mathématiques) et à la fois accessible aux personnes désirant rédiger des argumentaires (donc pas forcément des mathématiciens ou des informaticiens).

Une autre question que je n'arrive pas à trancher : celle de la langue. Le français serait la solution de facilité : je parle français, et les gens que je connais aussi, et c'est en France que je veux voir les choses bouger avant tout, même si c'est un peu égoïste ! Choisir l'anglais pourrait un peu brider ma plume, même si c'est surmontable, et surtout pourrait refroidir aussi les gens que je souhaite intéresser, mais ça aurait l'avantage de pouvoir attirer des compétences du monde entier et de faciliter le contact avec la communauté scientifique internationale de manière générale.

... ainsi que tous les animaux sur la vidéo !
Le pingouin (auk en anglais) est un oiseau assez différent !

Mais bon, ça, sur TrollFR LinuxFR, tout le monde le sait ;-)

Tests : en effet, il peut y avoir des paramètres cachés qui ne se déclenchent que le jour J... il faudrait un moyen d'être sûr de pouvoir réinitialiser toutes les mémoires de la machine ce jour-là (pas évident !).

Pour éviter un "cheat code", on pourrait limiter (mécaniquement) les entrées du système, en forçant une alternance de "autorisation" (bouton situé hors de l'isoloir), "vote" (boutons situés dans l'isoloir). Bref, l'alphabet d'entrée permis mécaniquement serait quelque chose de la forme (aV)* où V est l'ensemble des votes. Il faudrait aussi, pour bien faire, introduire un certain hasard dans l'ordre de passage des votants pour éviter qu'une coalition de votants successifs puissent entrer le cheat code. C'est très compliqué, et je me demande si on ne peut pas passer le code même au travers ce brouillage aléatoire, justement en utilisant un protocole de canal bruité... pas évident évident tout ça.

Par redondance, j'entends l'utilisation simultanée de plusieurs machines à voter d'origines différentes, avec un seul périphérique d'entrée (mécanique à mécanisme apparent pour qu'il soit clair qu'il n'y a pas d'entourloupe à ce niveau là).

Pour les FPGA : je n'y connais pas grand chose, mais existe-t-il des fpga munis d'une puce qui exporte une somme de contrôle visible ? Si c'est le cas, toute personne désireuse de vérifier le système pourrait entrer son propre code et vérifier que ça ne change pas la somme de contrôle. Faudrait voir ce que la personne qui a eu cette idée avait derrière la tête.

Ah si, il y avait une ligne "Math mode" au temps pour moi.

Sympa ce lien !

Ça pourrait m'être utile car je vais sûrement lancer bientôt un wiki sur le vote électronique (l'aspect technique), et l'export pdf me botte bien : ça permettrait de publier des articles ou un bouquin à partir de l'état actuel du wiki sans aucun effort particulier.

Je vois que ce tableau n'a pas dans ses critères le mode latex pour les formules mathématiques (comme dans Wikipédia, donc Médiawiki), c'est dommage.

En fait, mon avis va faire tache ici, mais je ne pense pas que l'open source soit la solution au problème. Ça pourrait certainement intervenir à un moment, mais tant que le hardware reste une boîte noire, t'as beau mettre du libre dedans...
(ceci dit, quelqu'un dans ces commentaires a parlé d'une solution à base de FPGA... peut-être qu'il faudrait voir ça de plus près !)

De plus il reste la question délicate de la vérification du compilateur (et par récurrence du compilateur qui a compilé ce compilateur, etc.).

Sinon, il existe d'autre manières de contrôler un système qu'ouvrir le code : tests intensifs, redondance des machines...
(s'il y a un domaine ou faire du test est efficace, c'est bien le vote électronique : en effet, on ne cherche pas une fiabilité à 100%, mais juste que le résultat ne soit pas faussé à une échelle statistique significative)

M'enfin ça ne mange pas de pain d'ouvrir tout le soft qui intervient dans le système de vote. Ne serait-ce que pour dire : "voyez, je n'ai rien à cacher !", même si c'est de la poudre aux yeux, car refuser l'accès au code pour un système censé inspirer la confiance, c'est mal barré.

Ouais, si on veut, un sondage exhaustif et sécurisé. Moi je pense que c'est plus proche du vote que du sondage. En plus, dans l'esprit, il s'agirait de prendre une décision, et non de donner un avis qui n'engage personne.

Mais ce n'est une question de vocabulaire.