Software / Dev
Swisseurobot 2012
Je sors un bref instant ce blog de sa léthargie pour parler brièvement de la coupe Swisseurobot 2012 qui a eu lieu ce 4 et 5 mai 2012 durant le festival de robotique de l’EPFL. J’y étais avec mon équipe, le CVRA, pour concourir avec notre robot : Debra II
Debra II / CVRA
Debra II est donc la suite logique du robot principal Debra de l’année dernière (où nous avions consitué deux équipes, l’une innovant sur presque tous les plans et une deuxième avec des moyens limités pour faire un robot simple). Il ressemble fortement à Debra, sauf que cette fois les deux bras sont pleinement fonctionnels. Ce concept a demandé énormément de travail, autant au niveau mécanique qu’au niveau software et il reste encore énormément de travail pour optimiser cette gestion et rendre le robot beaucoup plus performant. Des outils pour la vision avaient notamment été développé cette année mais n’ont pas pu être intégrer à la stratégie faute de temps. Mais même sans exploiter pleinement son potentiel nous étions concurrentiel face aux meilleurs équipes qui pourtant utilisaient deux robots simultanément !
Le robot à l’oeuvre
Une fois à la coupe, nous avons évidemment eu nombre de surprises comme à chaque fois. Les lingots étaient beaucoup plus lourd que prévu (aucune information dans le règlement), les pièces (CD) n’avaient pas le même état de surface, il n’y avait qu’une table (autant pour les tests/homologations/matchs… heureusement nous pouvons nous en passer). Il y a eu beaucoup de retard ce qui a annulé deux matchs de qualifications et nous avons eu des problèmes lors des deux premiers matchs. Durant la nuit nous avons adapté le robot pour fiabiliser la prise de CD ce qui nous a permis de nous qualifier de justesse pour la phase finale en arrivant à la 8e position. Le plus dure était fait mais comme nous étions dernier, nous devions commencer par affronter le premier des qualifications (RCR), match que nous avons remporté. Ensuite c’était au tour d’EMBA de nous affronter, le match se présentait bien mais lors d’une rotation du robot nous avons perdu la tige qui stockait une partie des CD dans le robot, outre la perte de plusieurs CD et donc points c’est une pièce du robot qui reste sur le table et qui signifie une pénalité. Malgré la perte nous avions davantage de points que l’adversaire mais cela ne couvrait juste pas la pénalité reçue ce qui leur a concédé la victoire. Tombé dans la phase rattrapage nous retrouvons les Belges Montefiore que nous avions déjà combattu lors d’un bras de fer…
… et le problème s’est à nouveau manifesté. Nous nous retrouvons finalement face à RTFM pour décider qui de nous deux occupera la troisième place disponible pour les équipes Suisse pour la finale Eurobot. Le match est tendu et c’est… égalité ! Il faut le rejouer… et c’est à nouveau égalité ! Il faut à nouveau le rejouer. Nous devons cependant qu’un CD qui s’était bloqué sous le robot a endommagé le moteur d’une de nos roue, c’est donc par forfait que nous devons renoncer.
Swisseurobot 2012 - Phase finale
Plus d’informations :
Swisseurobot et Eurobot 2010
Lollipop dans toute sa splendeur
Je profite d’un peu de temps (sic) libre dû à la météo pour tenter de rattraper le retard.
La coupe Swisseurobot puis Eurobot a eu lieu du 27 au 30 mai 2010 à Rapperswil-Jona (SG, Suisse) et j’y étais avec le CVRA et notre robot Lollipop (que nous aurions en réalité dû appeler Pac-Man (ça semble logique lorsqu’on le voit en action)).
Notre robot
Assemblage 3D
Lollipop est pour nous un robot de transition, nous avons en effet abandonné nos classiques pour utiliser de nouvelles techniques et technologies, tout reprendre à zéro. Cela représente un gros challenge, surtout si l’on ajoute à la recette un réglement qui change sans cesse. Ces modifications ont d’ailleurs dû décourage nombre d’équipes puisqu’au final seules 8 équipes Suisse ont passés l’homologation… Le défi a finalement été relevé avec brio pour finir avec un des robots les plus compétitifs aussi bien par rapport aux équipes Suisse (record Suisse du score d’ailleurs) qu’Européennes. Malheureusement comme nous utilisions de nouvelles technologiques et accumulé du retard dans le développement à cause du réglement nous avions peu de temps pour combler aux bugs inhérent au nouveau langage du robot (URBI de Gostai) ce qui nous a fait échouer quelques matchs et surtout le quart de final ce qui est évidemment éliminatoire.
Résultats Swisseurobot 2010
Quelques nouveautés 2010 :
- Ordinateur embarqué sur Linux avec URBI pour la gestion du robot
- Nouvelle carte moteur 3 axes
- Amélioration du soft de nos balises laser (bonne précision de la position du robot, de celle de l’adversaire mais notre position était extrêmement fiable grâce à notre odométrie)
- Utilisation de pièces imprimées en 3D
- Etc…
Voici quelques vidéos :
http://www.youtube.com/view_play_list?p=84D8A43875C42643
La vidéo de présentation du robot
L’adresse du club CVRA : http://www.cvra.ch
Benchmark ou comment tester un serveur
Il m’arrive régulièrement de devoir tester un serveur pour connaitre ses capacités, évaluer l’utilisation possible, etc… il existe plusieurs méthodes. Je vais en décrire quelques-unes simple à mettre en place.
Je traite ici d’un serveur sous Debian.
Voici quelques critères :
- Mesurer les performances CPU
- Tester la mémoire ram
- Débit et latence au disque dur
- Tester la connexion réseau (débit et latence)
- Stabilité du système (test sur plusieurs heures ou jours)
Monitoring
La première étape est de pouvoir superviser les tests et avoir un aperçu aussi bien en temps réel que dans le temps. Pour cela il y a plusieurs outils de monitoring :
En console
top : Le classique top est toujours pratique pour superviser l’état général du serveur en temps réel et contrôler que les tests en cours.
top - 17:47:54 up 2:15, 3 users, load average: 0.18, 0.17, 0.09 Tasks: 194 total, 2 running, 192 sleeping, 0 stopped, 0 zombie Cpu(s): 2.1%us, 2.0%sy, 0.2%ni, 95.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3095720k total, 1045784k used, 2049936k free, 62580k buffers Swap: 907632k total, 0k used, 907632k free, 440860k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1413 root 20 0 202m 64m 13m S 3 2.1 7:35.45 Xorg
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 1 0 86 13 0 0| 148k 346k| 0 0 | 326B 706B| 25 42 2 0 0 98 0 0|1867k 27k| 108B 232B| 12k 0 | 56 66 2 0 0 97 0 0| 630k 46k| 0 0 | 0 0 | 42 47 2 0 0 98 0 0|1074k 43k| 0 0 | 0 0 | 46 50
slurm : Un petit outil pour surveiller les interfaces réseaux.
Active Interface: eth0 Interface Speed: unknown
Current RX Speed: 20464.52 KB/s Current TX Speed: 448.83 KB/s
Graph Top RX Speed: 20464.52 KB/s Graph Top TX Speed: 648.21 KB/s
Overall Top RX Speed: 20464.52 KB/s Overall Top TX Speed: 648.21 KB/s
Received Packets: 495542060 Transmitted Packets: 723671597
GBytes Received: 139.571 GB GBytes Transmitted: 821.331 GB
Errors on Receiving: 0 Errors on Transmission: 0
Graphiques via HTTP :
Pour superviser les tests au fil du temps il est utile sinon indispensable d’avoir recours aux graphiques dans le style RDDTools. Il y a évidemment le classique mrtg mais j’ai une préférence pour munin qui est beaucoup plus puissant, précis sans être beaucoup plus lourd.
Graphique mémoire de Munin
Connexion réseau
Il importe ici de connaitre la connectivité du serveur à internet ainsi que la qualité du réseau (temps de latence, paquet perdu,.. ).
Débit
Pour connaitre le débit de la connexion internet en download vous pouvez télécharger un gros fichier :
wget http://test-debit.free.fr/image.iso --2010-01-24 17:56:02-- http://test-debit.free.fr/image.iso Résolution de test-debit.free.fr... 212.27.60.49 Connexion vers test-debit.free.fr|212.27.60.49|:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 678526976 (647M) [application/x-iso9660-image] Saving to: `image.iso' 100%[======================================>] 678 526 976 11,2M/s in 58s 2010-01-24 17:57:00 (11,1 MB/s) - « image.iso » sauvegardé [678526976/678526976]
N’oubliez pas de supprimer l’image téléchargée afin de ne pas trop encombrer votre espace disque. Ensuite il ne faut pas oublier que ce test de débit est fait principalement pour tester les connexions ADSL > 20 mbps, hors il n’est pas rare de disposer d’une connexion de 100 mbps voir 1 gbps. Il faudra donc trouver quelque chose de plus costaud et effectuer plusieurs tests en parallèle.
En upload il suffit de récupérer ce fichier en ftp depuis un autre serveur par exemple.
Latence et réseau
Pour connaitre la qualité du réseau, les outils classiques comme ping ou encore traceroute sont là.
Performances des disques durs
Vous pouvez vérifier le débit avec hdparm :
hdparm -tT /dev/sda /dev/sda: Timing cached reads: 9790 MB in 2.00 seconds = 4900.65 MB/sec Timing buffered disk reads: 702 MB in 3.01 seconds = 233.54 MB/sec
Pour des données plus précises il y a tiobench :
No size specified, using 512 MB
Unit information
================
File size = megabytes
Blk Size = bytes
Rate = megabytes per second
CPU% = percentage of CPU used during the test
Latency = milliseconds
Lat% = percent of requests that took longer than X seconds
CPU Eff = Rate divided by CPU% - throughput per cpu load
Sequential Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.6.32.2-xxxx-grs-ipv6-64 512 4096 1 ###### 99.60% 0.002 0.04 0.00000 0.00000 1662
2.6.32.2-xxxx-grs-ipv6-64 512 4096 2 ###### 396.8% 0.003 0.04 0.00000 0.00000 621
2.6.32.2-xxxx-grs-ipv6-64 512 4096 4 ###### 1599.% 0.006 0.06 0.00000 0.00000 163
2.6.32.2-xxxx-grs-ipv6-64 512 4096 8 ###### 6369.% 0.020 0.13 0.00000 0.00000 24
Random Reads
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.6.32.2-xxxx-grs-ipv6-64 512 4096 1 ###### 126.1% 0.002 0.01 0.00000 0.00000 1302
2.6.32.2-xxxx-grs-ipv6-64 512 4096 2 ###### 472.4% 0.002 0.01 0.00000 0.00000 651
2.6.32.2-xxxx-grs-ipv6-64 512 4096 4 ###### 503.1% 0.003 0.01 0.00000 0.00000 977
2.6.32.2-xxxx-grs-ipv6-64 512 4096 8 ###### 6713.% 0.005 0.01 0.00000 0.00000 81
Sequential Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.6.32.2-xxxx-grs-ipv6-64 512 4096 1 63.19 19.50% 0.009 0.26 0.00000 0.00000 324
2.6.32.2-xxxx-grs-ipv6-64 512 4096 2 58.85 62.44% 0.016 0.27 0.00000 0.00000 94
2.6.32.2-xxxx-grs-ipv6-64 512 4096 4 53.21 201.5% 0.033 0.40 0.00000 0.00000 26
2.6.32.2-xxxx-grs-ipv6-64 512 4096 8 60.62 1229.% 0.129 19.86 0.00000 0.00000 5
Random Writes
File Blk Num Avg Maximum Lat% Lat% CPU
Identifier Size Size Thr Rate (CPU%) Latency Latency >2s >10s Eff
---------------------------- ------ ----- --- ------ ------ --------- ----------- -------- -------- -----
2.6.32.2-xxxx-grs-ipv6-64 512 4096 1 56.77 13.08% 0.004 0.03 0.00000 0.00000 434
2.6.32.2-xxxx-grs-ipv6-64 512 4096 2 23.68 16.37% 0.005 0.03 0.00000 0.00000 145
2.6.32.2-xxxx-grs-ipv6-64 512 4096 4 13.86 17.74% 0.007 0.04 0.00000 0.00000 78
2.6.32.2-xxxx-grs-ipv6-64 512 4096 8 57.53 254.8% 0.019 0.05 0.00000 0.00000 23
Tester le cpu
Vous pouvez faire des tests de courtes durées comme chronométrer un décompression ou de longue durée (calculs). Voici quelques exemples :
Super PI
C’est une méthode qui va permettre de mesurer les performances du cpu sur une durée plus ou moins longue. C’est une application qui calcule les décimales du nombre Pi. Cette application est en 32 bits donc elle ne mettra pas à profit un cpu 64 bits (si vous le faite tourner sur une distribution 64 bits il faut installer ia32-libs ).
wget ftp://pi.super-computing.org/Linux/super_pi.tar.gz tar xzf super_pi.tar.gz ./super_pi 20 ------ Started super_pi run : Fri Jan 22 18:12:00 CET 2010 ------ Ended super_pi run : Fri Jan 22 18:20:53 CET 2010 Version 2.0 of the super_pi for Linux OS Fortran source program was translated into C program with version 19981204 of f2c, then generated C source program was optimized manually. pgcc 3.2-3 with compile option of "-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant" was used for the compilation. Start of PI calculation up to 16777216 decimal digits End of initialization. Time= 6.704 Sec. I= 1 L= 0 Time= 19.333 Sec. I= 2 L= 0 Time= 22.057 Sec. I= 3 L= 1 Time= 21.969 Sec. I= 4 L= 2 Time= 21.889 Sec. I= 5 L= 5 Time= 21.961 Sec. I= 6 L= 10 Time= 22.017 Sec. I= 7 L= 21 Time= 21.917 Sec. I= 8 L= 43 Time= 23.137 Sec. I= 9 L= 87 Time= 22.309 Sec. I=10 L= 174 Time= 21.897 Sec. I=11 L= 349 Time= 21.957 Sec. I=12 L= 698 Time= 23.033 Sec. I=13 L= 1396 Time= 22.265 Sec. I=14 L= 2794 Time= 22.045 Sec. I=15 L= 5588 Time= 21.957 Sec. I=16 L= 11176 Time= 22.109 Sec. I=17 L= 22353 Time= 22.225 Sec. I=18 L= 44707 Time= 22.349 Sec. I=19 L= 89415 Time= 21.913 Sec. I=20 L= 178831 Time= 22.061 Sec. I=21 L= 357662 Time= 22.745 Sec. I=22 L= 715326 Time= 21.429 Sec. I=23 L= 1430652 Time= 19.389 Sec. End of main loop End of calculation. Time= 525.037 Sec. End of data output. Time= 1.680 Sec. Total calculation(I/O) time= 526.717( 108.831) Sec.
Selon le nombre de décimales calculées (et surtout selon le cpu) le test durera de quelques minutes à quelques heures.
Temps de compression/décompression
cd /dev/shm; wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.31.5-ovh.tar.gz -O linux-2.6.31.5-ovh.tar.gz; time gzip -d linux-2.6.31.5-ovh.tar.gz -c > /dev/null; for i in ` seq 1 4` ; do time gzip -d linux-2.6.31.5-ovh.tar.gz -c > /dev/null & done
MySQL
mysql> SELECT benchmark(100000000,1+2);
Sinon vous pouvez essayer de manipuler de grandes quantités de données en regardant les temps d’exécution des requêtes.
Mettre la ram à vif
Un utilitaire pratique pour tester les performances des différentes mémoires du serveur (L1, L2, RAM, ..) est bandwidth :
wget http://home.comcast.net/~fbui/bandwidth.tar.gz
tar xzf bandwidth.tar.gz && chmod +x bandwidth bandwidth64
./bandwidth
L1 cache sequential read 8022.07 MB/sec
L1 cache sequential write 7524.32 MB/sec
L2 cache sequential read 6862.73 MB/sec
L2 cache sequential write 6318.39 MB/sec
Main memory sequential read 2207.22 MB/sec
Main memory sequential write 1602.92 MB/sec
Conclusion
Évidemment cela ne sert à rien de bourriner sur tout ce qui passe sous la main, ces tests sont à adapter à l’utilisation envisagée. Cela vaut la peine de pousser un peu pour bien se rendre compte des limites et ainsi avoir en tête le contexte et l’évolution de son utilisation à moyen terme.
Si on en a la possibilité, installer l’application voulue et la tester, ce sera le test le plus adapté. Le test le plus important sera celui du point faible du serveur ou de l’infrastructure, par exemple si le serveur est situé géographiquement loin ou encore si les données sont sur un SAN accessible en iSCSI, etc…
Si vous avez d’autres habitudes, propositions vous pouvez les indiquer en commentaire, je complèterai l’article en conséquence.
Péripéties de la vie quotienne (ou pas…)
Ce billet change légèrement de la ligne éditoriale habituelle, Il décrit une journée qui était censée être habituelle hormis un simple détail : migration vers Gutsy, la nouvelle version d’Ubuntu.
Ce matin (j’avais spécialement attendu ce matin pour espérer échapper aux bouchons sur l’autoroute des serveurs Canonical en circulant aux heures creuses par rapport au fuseau horaire américain et en ayant attendu 36 heures après la sortie). Jusque là j’avais raison, la mise à jour se télécharge normalement. Ensuite installation et tout le blabla jusqu’au moment où tout plante après près de 2 heures de compilation.
Là je me dis : « Bon, qu’est-ce qu’on parie que le serveur X on ne le reverra pas de sitôt »… et j’avais raison. Je redémarre, arrivée en mode console. Je finis l’update/upgrade dedans (d’ailleurs la prochaine fois, promis je fais la maj en console sans rien qui tourne à côté…). Quelques messages d’erreurs et retouches plus tard, je redémarre. Bon toujours pas de X, on bidouille un peu le xorg.conf pour avoir au moins un écran et là ça se lance. Enfin Gutsy. Je me rappelle qu’une nouveauté c’est l’édition simple via le menu pour gérer plusieurs écrans mais malheur, le second m’affiche n’importe quoi, le test fait planter l’application et tout le bazar. Soit dit en passant, je n’ai jamais réussi à booter ce linux avec le kernel installé par Gutsy (2.6.22), j’étais en 2.6.20 à ce moment là.
Ensuite je me suis dit, mouais, j’ai vraiment pas de temps à perdre là, depuis le temps que j’hésite, je lance une installation d’OpenSuse 10.3 dont j’avais un cd à portée de main (pas sur la même partition). Tout va bien dans le processus jusqu’à l’installation de Grub qui ne veut rien savoir. Et là, malheur des malheurs j’ai tenté d’installer Lilo à la place. Il veut pas non plus. Je redémarre (sans avoir pu achever l’installation mais en interrompons proprement. Et là : trop cool !! Grub m’affiche juste un message d’erreur 17. Génial.
En gros tout est inutilisable, tout. Ubuntu. OpenSuse. Windows XP. Tout.
Bon évidemment, je ne panique pas. Je fouille mon tiroir où traine une bonne dizaine de Live CD et autres et je commence à essayer. Y a rien qui boot, j’essayais une installation de Debian : pas de disque dur installé sur la machine. Je tente une installation d’OpenSuse sur une clef usb de 2 go comme c’est gentillement proposé par l’installateur mais il m’annonce fièrement qu’il n’a pas réussi à formaté la clef (j’ai constaté que maintenant non seulement je ne peux pas la formater (menfin, on verra ça….) mais en plus elle fait plus que 8 mo. Bref je ne peux rien faire.
Face à cet échec j’ai cherché à rétablir Grub. Live CD (en mode console, décidemment…), retouche de Grub et ça repart mon kiki… enfin presque, seulement Windows XP. C’est cool, mais ça ne suffit pas. Depuis quelques jours il ne veut plus de mes cartes wifi, comme ça boum, indigestion. Donc ça ne me suffit pas un OS sans internet. Mais depuis Win XP j’ai lancé l’installateur d’OpenSuse 10.3 et je n’ai pas eu d’erreur critique durant son installation.
Pas d’erreurs non… sauf lorsqu’il se lance après l’installation, là X refuse de démarrer et sans rien laisser dans les logs. C’est super cool dis voir, je commence à m’éclater.
Je fais un petit break en testant ce que vaut un logiciel de partitionnement que j’avais payé presque aussi cher que Partition Magic : il m’annonce qu’il y a pas de disque dur sur ma machine (alors que les tests du Bios m’indique que tout va bien madame la marquise) et il est incapable de faire la moindre fonctionnalité proposée (que ce soit le soft proprio ou les outils linux embarqués).
Durant ce temps, j’ai fini de télécharger l’iso d’ubuntu 7.10 (à une moyenne de 45 ko/s…) que je grave illico. Là ça démarre, mode graphique et tout, direct du 1680×1050 sur le 22″, on apprécie le geste. Par contre toujours pas moyen d’installer (ça bloque au partitionnement) et toujours pas moyen de configurer le second écran (mais y sert à quoi ce truc pour se simplifier la vie ??). Pas grave, je modifierai xorg.conf plus tard.
Donc je n’ai pas installé mais en bidouillant /etc/network/interface j’ai pu connecter le wifi (je signale au passage que sur toutes les installations linux que j’ai vu passer aujourd’hui il n’y a que Debian Sarge (mes lecteurs ne voulaient pas booter sur l’iso Etch…) qui proposait de configurer du wifi, tout le reste c’était uniquement eth0…).
Donc ce matin j’avais :
- Windows XP
- Ubuntu 7.04
Qui marchaient et après une journée passée à installer/paramétrer j’ai :
- Windows XP
- Ubuntu 7.10 en live
C’est mieux que rien mais ça me bloque trop de trucs. Il est évident que j’ai un problème sur cet ordinateur, disque dur trop foireux (soit c’est le disque dur qui a de la peine avec les formatages, soit c’est toutes les distributions linux qui ont de la peine avec le formatage…) et en tout cas un lecteur optique qu’il faut changer (le second est récent).
Morale : Plusieurs choses, mais ce que je constate et qui est important pour moi c’est que les distributions courantes (Ubuntu/OpenSuse) deviennent presque usine à gaz que Windows et c’est bien dommage. Je préfère un système qui est extrêmement simple (mais robuste) afin d’implémenter dessus ce qui est utile et uniquement utile, j’ai pas besoin du millier de paquets qu’installe ubuntu lors d’un changement de version.
Donc je vais sérieusement envisager de faire une croix sur ces systèmes qui ne me satisfont plus pour migrer sur du Debian Etch, Slackware ou encore Linux from scratch dès qu’un disque dur fiable sera là (demain je pense). Auriez-vous des conseils/remarques à ce sujet ?
ps : Au cas où une partie semble incohérente merci de le signaler. Lorsque j’écrivais la conclusion j’ai fait quelques backspace ce qui a abouti à une petite suppression impromptue de plusieurs lignes dont j’ai retrouvé quelques mots au milieu du post. Les joies des LiveCD…
—————————
Edit du 20/10/2007 : Voilà, nouveau disque dur installé. Installation propre dessus de Ubuntu 7.10 (en gros ce que j’avais à portée de main ce moment là) et pas de soucis. D’ailleurs chapeau pour garder les paramètres wifi entre le LiveCD et l’installation… alors que sous 7.04 il fallait rentrer la clef tous les deux démarrages.
Par contre j’ai toujours des petits problèmes avec le dual-screen (je ne sais pas comment il calcule le 1280*1024 mais ça tient pas sur le 17″…). Il ne veut pas activer les effets 3D mais ça tant mieux.
Un ami m’a recommandé de tester OpenSuse 10.3, promis je le ferai mais pour l’instant je vais profiter un peu de cette installation avant de tout casser à nouveau.
Navigateurs exotiques
En regardant de près les statistiques de Daskoo (qui va super bien soit dit en passant), mon attention a été retenue par les détails des navigateurs et leurs versions.
On parle toujours de deux principaux : Firefox et Internet Explorer mais développer un site pour eux ne suffit pas. Ce qui va suivre démontrer une fois de plus l’importance d’avoir un site accessible avec des alternatives à Flash/AJAX.
Pour commencer avec Firefox et IE, comme je l’ai dit il y a un gros pourcentage de FF 2.0 et IE 6/7 mais il y a aussi…
Ok mais il y a encore ceux qui ne sont ni FF ni IE… comme Netscape (nan il est point mort)
Bon, qu’est-ce qu’il nous reste… simplement le pire car il y a une variété époustouflante et ça représente tout de même 6% des visiteurs…
Est-ce que tout ce beau monde voit convenablement le site ? Daskoo n’est pas un site complexe, mais il faut supporter CSS 2 pour le voir correctement, et CSS 2 tous les navigateurs cités dans ce billets ne le supporte pas. Vous aussi vous avez des navigateurs « exotiques » non ? Que faites-vous pour eux ?