Samuel Thibault a écrit 191 commentaires

0.01% ? Waouh, quelle sous-estimation.

Rien que le daltonisme, renseigne-toi: oui, ça fait 8% de la population masculine. Bien sûr, à différents degrés, mais rien que ne plus pouvoir distinguer le rouge et le vert, cela pose éventuellement de gros problème avec pas mal de logiciels.

Et puis la vue qui baisse, les capacités motrices qui baissent, etc. Ça ne te rappelle rien ? Ben oui, c'est ce qui va t'arriver, oh bien sûr, pas tout de suite, mais pourtant même à un âge avancé, tu voudras pouvoir continuer à troller sur linuxfr :)

Fais un inventaire si tu as du temps, mais je pense que les handicaps qui posent un problème pour l'utilisation de logiciels sont bien majoritaires.

Pour ce qui est du coût supposé de l'adaptation d'un logiciel une d'une page web. En fait il est souvent négatif, je m'explique. Rendre un logiciel ou une page web accessible revient bien souvent à juste les penser de manière logique, bien structurée, détaillée, documentée... Ça ne vous rappelle rien ? Ce sont là des méthodes classiques de développement de logiciels, qu'on devrait de toutes façons appliquer, et qu'on n'applique pas forcément. Bien souvent, se forcer à les appliquer, ne serait-ce que pour l'accessibilité, est au final un bénéfice pour la pérennité du logiciel.

> A part lui, il y a des toolkit multi-OS (euh... Parce que prendre les handicapés visuels sous Linux uniquement, ça fait un marché encore plus restreint!) qui proposent quelque chose?

Heu, ben oui, gtk.

Et la console texte aussi, bien sûr :)

Par ailleurs, où as-tu vu qu'on parlait de handicap visuel seulement ?

Dans le cours d'informatique que j'avais eu, il y avait une distinction entre un langage rationnel et un langage régulier: l'un était défini par les règles:

- le langage vide
- des langages de mots d'une lettre.
- des combinaisons de langages par union (\| en regexp).
- des combinaisons de langages par concaténation (juxtaposition en regexp).
- des répétitions d'un langage (* en regexp)

et l'autre par le fait qu'il est reconnu par un automate fini. Je ne me souviens plus du tout lequel était nommé comment :)

À l'Université de Bordeaux, on utilise Nachos pour l'enseignement de Système d'Exploitation.

> Apres, les autres acteurs du LL peuvent participer aussi, personne ne les empeche de le faire.

Personne, non, mais comme je le dis dans la dépêche, ça demande un savoir-faire qui est loin d'être inné, et donc cela réduit le nombre d'acteurs qui arrivent effectivement à contribuer.

Le genre de choses auxquelles j'essaie de faire attention, justement, c'est d'essayer de rendre le développement sur l'accessibilité "accessible" (au gens qui n'y connaissent rien, donc). Par exemple, http://wiki.debian.org/DebianInstaller/Accessibility pour tester l'accessibilté braille et vocale de l'installeur Debian.

> Ou meme des volontaires pas payes, c'est du LL apres tout, si il y a un besoin partage par assez de monde, ca se resoudra tout seul.

C'est bien là le problème du domaine de l'accessibilité: il n'y a pas assez de monde qui a ce besoin. Et donc ça ne se résoud pas tout seul. Et d'autant moins par objectif lucratif, puisque le marché est très petit.

Longue histoire entre gnome et KDE, on est en train d'arriver à une solution unifiée autour d'AT-SPI2 basé sur DBUS. et le problème reste de toutes façons le même: qui va financer le développement d'Orca? (J'insiste: c'est vraiment un boulot énorme, une personne à _plein_ temps c'est déjà pas vraiment suffisant)

La démarche vers la MoFo était surtout par rapport à l'accessibilité de
ses propres navigateurs. Sans Orca, pas de possibilité de surfer sur le
web avec eux.

As-tu lu le détail de ma dépêche ? J'y mentionne qu'effectivement, pour
tous les marchés publics les logiciels doivent être accessible. Dans le
cas de Sun, exSun affirme que l'accessibilité allait bien au-delà de
juste l'environnement gnome, et je confirme.

> -O3 semble profiter plus à memcpy qu'à la copie manuelle.

Et pour cause... elles sont inversées !

Par ailleurs, pour les versions 32bits de la glibc qui a priori ne
peuvent pas supposer disposer des instructions SSE pour utiliser à
plein régime le processeur, les distributions fournissent
éventuellement une version "i686" de la glibc, et par ailleurs, cf

http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2010/02/07#st(...)

Bon, mbw est vraiment à jeter tel quel. Les version dumb et memcpy sont
INVERSEES:

type: 0=use memcpy, 1=use dumb copy

if(type==1) { /* memcpy test */

Donc il faut inverser complètement l'interprétation, et le memcpy de la
glibc est bien celui qui remporte le benchmark.

La version bloc de mbw est bugguée, elle ne fait pas vraiment un
memcpy, il ne faut vraiment pas prendre en compte le résultat obtenu
avec... Il faut appliquer le patch ci-dessous pour que ce soit vraiment
une copie complète:

Seulement dans mbw-mine: mbw
diff -ur mbw/mbw.c mbw-mine/mbw.c
--- mbw/mbw.c 2006-07-04 14:45:01.000000000 +0200
+++ mbw-mine/mbw.c 2010-02-09 13:39:52.000000000 +0100
@@ -98,11 +98,11 @@
gettimeofday(&endtime, NULL);
} else if(type==2) { /* memcpy block test */
gettimeofday(&starttime, NULL);
- for(t=0; t<array_bytes; t+=block_size) {
- c=mempcpy(b,a,block_size);
+ for(t=0; t+block_size<=array_bytes; t+=block_size) {
+ c=mempcpy((void*)b+t,(void*)a+t,block_size);
}
- if(t>array_bytes){
- c=mempcpy(b,a,t-array_bytes);
+ if(t<array_bytes){
+ c=mempcpy((void*)b+t,(void*)a+t,array_bytes-t);
}
gettimeofday(&endtime, NULL);
} else { /* dumb test */

Bien que le wiki ait été mis à jour récemment, Hurdfr est pas mal
en léthargie actuellement, oui, essentiellement parce que les gens ont
moins de temps à y consacrer. Ça ne veut pas dire qu'il ne faut pas
venir voir ce qu'il y a à faire, les gens sont encore là, juste ils
n'ont pas le temps de les faire effectivement, mais ils peuvent
déléguer.

Pour ce qui est de GNU/Hurd lui-même, cf les news mensuelles de
http://hurd.gnu.org/

Ou plus simplement utiliser hwloc, qui est portable :)

Mais dans ce cas-ci, autant laisser le noyau se débrouiller, il y a
arrivera très bien.

Heu, non, KVM et autres ne sont pas dérivés de kQemu, ils utilisent la base de drivers de qemu seulement, qui certes est un composant essentiel de qemu, mais n'est pas sa raison première: _q_emu c'est surtout "quick" emu, avec un moteur JIT qui recompile des morceaux de codes en natif pour aller bien plus vite que bochs & co qui ne font qu'interpréter en direct. Ce que fait kQemu, c'est bidouiller avec le noyau pour se passer le plus souvent possible de recompiler le code et directement l'exécuter en natif. Ce que font kvm, Xen en virtualisation totale, virtualbox, etc., c'est utiliser la fonctionnalité vmx/svm des processeurs récents pour que ce soit le processeur lui-même qui s'occupe de la bidouille (ce qui rend la chose encore plus rapide, donc).

kQemu et KVM ont donc un principe assez similaire: remplacer la partie recompilation de code de qemu, mais les implémentations n'ont rien à voir :)

Note: quand j'aurai le temps, j'ajouterai aussi les périphériques eux-même (eth0, hda, etc.)

Oui mais c'est en général homogène, i.e. la même pour tous les processeurs de la machines (pour un type donné, du moins).

Au besoin on pourra rajouter le champ, au pire, la question, c'est où s'arrêter: mettre l'associativité, la taille de la TLB, etc?

Oui, exactement. L'objectif est essentiellement la localisation (d'où le nom). Les tailles de ligne de cache par exemple sont en général homogène, ce n'est donc pas forcément très utile (et rares sont les OS/processeurs qui le rapporte). Les types de processeur par contre on voudra sans doute le rajouter pour le Cell ou le Larrabee.

man ionice

> En même temps sous les desktops GNU/Linux classiques je ne crois pas qu'il y ait de vrai SAK

Heingg ??

Et ctrl-alt-backspace c'est quoi ?

http://brl.thefreecat.org/wiki/moin.cgi/LUG

> Le « panning » est maintenant possible

En fait, c'est plutôt _de nouveau_ possible. La fonctionalité
existait depuis des lustres, et avait été supprimée lors de
l'arrivée de Xrandr 1.2.

> Bon, je vais m'abonner chez FDN, ça, je l'ai déjà dit. Il va me falloir un modem et un routeur IPv6 décent. Donc questions :
> - OpenWRT peut-il exécuter radvd ?

Oui. Perso je l'ai recompilé à la mano mais il doit exister des packages :)

> - Que me conseilleriez-vous comme tout petit ordinateur, disposant d'un modem ADSL2+, de quelques ports et d'un commutateur Ethernet interne (et c'est tout, je n'ai pas besoin d'établir de connexion micro-onde), c'est à dire ce qu'on appelle un « modem routeur »), pour y faire tourner OpenWRT ?

Moi j'utilise simplement ma fonera branchée sur mon bewan. Il a fallu que je recompile pppd pour y activer l'ipv6, mais sinon les modules ipv6 et ip6tables sont dispo chez gcd.org/fonera.

Mmmm, l'article a quand même tendance à décourager je trouve:

« Ensuite, l'environnement n'a visuellement rien à voir, mais les
éditeurs cultivent la simplicité. »

"rien à voir", un bureau gnome où la seule réelle différence, c'est que
le bouton démarrer est en haut à gauche ?

« Enfin, les logiciels utilisés sous Windows ne sont pas
compatibles. Mais certains trouvent des équivalents sous Linux (pas
toujours évidents à installer). »

C'est un raccourci *très* rapide et dangereux... Il aurait fallu
indiquer , que la plupart des types logiciels (Office, Outlook, MSQL,
etc.) ont leur équivalent déjà installé par la distrib. Que pour
les autres, avec un émulateur (wine), il y a quand même pas mal de
choses qui passent. Au final, ce ne sont que les logiciels vraiment
spécialisés (genre application métier) qui ne sont pas forcément
évident à trouver/installer/etc.

"ce n'est plus de plusieurs ordres de magnitudes", avec la paravirtualisation, oui: bien que la latence reste élevée (ça reste de l'ordre de la µs pour vraiment soumettre un paquet réseau), le débit est très bon maintenant.

Mais pour ce qui est typiquement de lancer un ./configure donc création/destruction de plein de contextes de mémoire virtuelle (merci les scripts shells...), ça reste très cher par rapport à une exécution native: on est de toutes façons obligé de faire un hypercall, donc des µs. Après, bien sûr, le TLB miss reste le même qu'en exécution native, mais l'impression que j'ai c'est quand même bien plus lent.