Planet Libre

Avertissement: L’utilisation des méthodes exposées nécessite une certaine maîtrise et une certaine compréhension du fonctionnement du système. Bien entendu elles sont livrées sans garantie et l’auteur décline toute responsabilité quant à leur usage…

Introduction

Sous GNU/Linux et les systèmes UNIX, il est un fait connu et établi que le système multi-utilisateurs (à condition d’être bien paramétré) apporte une sécurité supplémentaire à la machine.

D’une manière générale (en oubliant entre autres quelques failles occasionnelles et vite corrigées dans le noyau), chaque utilisateur ne peut faire que ce que le système lui permet de faire, et peut difficilement nuire plus aux autres utilisateurs. Cela signifie aussi que si un compte utilisateur est compromis (virus (rare), utilisation d’une faille de sécurité d’un executable lancé, etc…), les conséquences s’arrêtent souvent à ce seul compte utilisateur…

Jusque là, rien de nouveau si ce n’est des généralités très connues de nombreux Linuxiens… Pourtant une chose moins utilisée est l’utilisation de comptes multiples de façon simultané par un seul utilisateur physique.À quoi bon cela peut il servir? Non pas à gérer d’éventuels doublements de personnalité (ce n’est pas à un programme informatique de gérer cela, pas même à Emacs…), mais à diminuer l’impact éventuel d’une brèche de sécurité.

Exemple typique de l’utilité des comptes multiples

Supposons que vous surfez sur le web (quoi de plus anodin?) à l’aide de votre navigateur préféré (par exemple firefox). Supposons que votre navigateur est affecté par une faille permettant l’exécution non désirée de code arbitraire (autrement dit une faille sévère, observez par exemple les notes concernant les différences de version entre firefox 2.0.15 et firefox 2.0.16). Vous ne voudriez pas que toutes vos données personnelles (éventuellement confidentielles, numéro de CB et tout…) et vos fichiers (votre travail d’un mois que certes vous n’aurez pas manqué de sauvegarder) puissent être modifiées ou lus sans votre accord?

Eh bien c’est là que l’on peut profiter d’une sécurité accrue, par exemple si firefox est lancé par un utilisateur qui ne sert que pour ce programme et qui n’a que des droits d’accès restreint aux données des autres utilisateurs. Certes le nombre de données confiées à un navigateur peut être grand (voire immense), néanmoins quand on peut limiter les dégâts autant ne pas s’en priver…

Bref, vous l’aurez compris, utiliser des comptes supplémentaires pour certaines applications peut aider beaucoup…

Quels comptes créer? Quelques éléments de réponse…

Sans tomber dans la philosophie “un compte pour une application” (quoique d’après ce que j’ai compris ce principe pourrait avoir un écho non négigeable dans le futur), il est possible de renforcer facilement la sécurité en créant quelques comptes pour des usages spécifiques…

Bien que ceci n’est pas un guide, voici quelques idées possibles de comptes supplémentaires à créer pour un utilisateur physique régulier de la machine:

• Un compte rien que pour firefox: programme très soumis à des données extérieures (donc données échappant à tout contrôle total). C’est aussi un programme complexe et donc il reste “normal” que malgré la grande qualité de son code on puisse trouver de temps en temps des failles critiques. “Isoler” spécifiquement ce programme peut être un bon choix stratégique.
• Un compte pour la plupart des autres programmes traitant des données provenant du web (mais facilement isolables de l’activité de navigation) par exemple votre client IRC et quelques autres trucs…
• Vous aurez probablement votre sorte de “compte principal” qui cumulera la plupart de vos usages…
• Vous aurez peut être aussi un compte éventuel pour protéger vos données ultra-confidentielles (le cas échéant), ce qui concerne votre job, etc…

Bref, le choix des différents comptes n’est pas forcément facile, et tout ne se fait pas forcément sans complication… (La philosophie “le compte unique + le compte root” n’est pas forcément toujours critiquable…)

En résumé: c’est à vous de bien réfléchir à vos besoins…

Utiliser plusieurs comptes, pour une seule personne… Donc souvent en même temps!

Si vous utilisez différents comptes pour différentes personnes, ouvrir/fermer/suspendre des sessions (graphiques) est souvent assez facilement gérable… Maintenant si vous avez plusieurs comptes pour vous, il y a déjà plus de chances pour que vous ressentiez un besoin un peu plus accru de les utiliser en même temps…

En mode texte c’est généralement assez facile (et connu). En mode graphique, ça se complique (un tout petit peu) mais la situation reste tout à fait gérable. Je vais donc vous apporter quelques pistes à ce sujet:

Supposons que vous avez un utilisateur principal “NomUtilisateurPrincipal” (session graphique sous X ouverte) et que vous souhaitez faire quelques activités avec l’utilisateur secondaire “NomUtilisateurSecondaire“, la méthode est en général assez simple. Ici un scénario parmi tant d’autres pour vous familiariser:

• lancez un terminal (avec “NomUtilisateurPrincipal“)
• dans ce terminal tapez kdesu -u “NomUtilisateurSecondaire” konsole (il vous faut les programmes nécessaires, et il y a bien sûr d’autres scénarios possibles)
• le nouveau terminal lancé (il peut éventuellement mettre du temps à apparaitre…), possède les droits de “NomUtilisateurSecondaire“, il en est de même des programmes qu’il servira à lancer…
• essayez de lancer un ou deux programmes depuis cette nouvelle konsole, et profitez en pour tester un peu…

Notes diverses

• À chaque fois que mozilla firefox vous lancerez, l’option “-no-remote” vous prendrez soin d’utiliser, ou alors du multi-utilisateurs simultanés vous vous abstiendrez! (Plus sérieusement sinon vous risquez quelques petites surprises…)
• Sinon si vous lancez un programme depuis un terminal, pensez à faire attention avant de fermer le terminal… (Surtout si vous n’avez pas utilisé “nohup”…)

Introduction

Cet article est comme son nom le laisse supposer, un article qui prolonge SwapBoost épisode I : Les méthodes simples. Il est donc plus que préférable que vous lisiez cet article ainsi que Windows’s ReadyBoost vs Linux’s SwapBoost : Quelques détails pour pouvoir comprendre la suite…

Cet article s’intéresse à l’utilisation d’un fichier pour stocker le swap sur votre support flash à la place d’une partition swap dédiée.

Avertissement

Le même avertissement que dans l’article SwapBoost épisode I : Les méthodes simples s’applique: vous devez comprendre les risques des méthodes (ou liées à l’application des idées), et vous agissez de votre propre initiative. L’auteur du post décline toute responsabilité quant à l’utilisation…

Swapper dans un fichier: rappels succincts

Bien que sous Linux la mode soit à l’usage de partition de swap (contrairement à Windows où la mode est plutôt un fichier de taille dynamique ce qui peut souvent faciliter la non performance du système de fichier), il est également possible de créer un fichier de taille fixe pour “swapper” dedans.

Pour créer le fichier, la commande dd est habituellement d’un grand recours et il suffit de passer ensuite le nom du fichier (attention à ne pas tapper seulement le nom de la partition qui le contient!) en paramètre à la commande swapon.

Bref, rien de compliqué et la méthode se transpose aussi sur clé…

Swapper dans un fichier: les raisons

La question que vous pouvez à juste titre vous poser est “pourquoi donc dans un fichier et non dans une partition?“.

Une première réponse possible à cette question est la souplesse que cela procure (quitte à perdre un peu en performances): il est souvent plus facile de manipuler de simples fichiers que des partitions. Cet argument n’est pas spécifique aux supports externes flash, cependant sur un disque dur interne dans le cas le plus usuel, il est souvent facile de prévoir une quantité minimale de swap attribuée sous forme de partition lors de l’installation (puis en cas de besoin, même si beaucoup l’ignorent, on peut en rajouter en plus en utilisant un fichier).

Une seconde réponse peut s’intéresser plus au fait que l’on a affaire à un support flash. Comme cela a déjà été évoqué, les supports flash s’usent au fur et à mesure des écritures. Plus exactement le support est assez souvent constitué de blocs (au niveau physique) ayant chacun un nombre d’écritures limité, d’où l’intérêt de répartir les écritures. On peut ainsi envisager de déléguer cette gestion améliorée des écritures à un système de fichier fait pour cela, d’où l’intérêt de swapper dans un fichier plutôt que dans une partition.

Quels sont donc ces systèmes de fichier spécialisés?

Ce post sur DLFP qui avait attiré mon attention il y a quelque temps vous présentera mieux que moi ces différents systèmes de fichiers particulièrement adaptés aux supports flash: JFFS(2), YAFFS, LOGFS ou UBIFS par exemple…

Pour en savoir plus à ce sujet, je vous laisse utiliser les armes bien connues que vous avez pour satisfaire votre curiosité…

Petite note au passage

Il se peut aussi que l’électronique de votre support flash gère (plus ou moins bien) la répartition des écritures. Malheureusement ce n’est pas toujours le genre d’informations qu’il est aisé d’obtenir…

Retour à la répartition des écritures

Comme indiqué, je n’ai pas prévu (tout du moins pour l’instant) de vous faire une présentation détaillée de chaque système de fichier évoqué. Néanmoins je vais essayer d’apporter quelques précisions générales utiles pour celui qui aurait envie d’expérimenter…

Tout d’abord, pour répartir les écritures sans engendrer d’écriture supplémentaire, il convient en général d’avoir de l’espace libre. Cet élément mérite un point de détail qui peut facilement échapper: il faut que le système de fichier puisse détecter qu’il y a de l’espace libre.

Par exemple, si vous avez un seul fichier qui occupe la quasi totalité de la partition, vous risquez d’avoir tout faux! Y compris si l’utilisation actuelle de ce fichier pour les besoins du swap est très faible (c’est là que me parait être un piège): il suffit par exemple d’avoir utilisé une fois le swap à un fort pourcentage pour qu’il soit très difficile de savoir (du point de vue du système de fichier) que des données présentes sont inutiles à stocker…

Pour récapituler, si vous souhaitez utiliser un fichier de swap dans une partition utilisant un système de fichier spécialisé, il parait quasi indispensable de laisser une quantité non négligeable d’espace libre qui ne sera pas utilisée par le swap… Tout du moins si vous souhaitez prolonger au mieux la durée de vie du support flash…

Pour aller plus loin…

Il y a divers moyens d’améliorer un peu la situation et de faire face aux quelques “obstacles” qui se présentent: deamon pour créer des fichiers swap supplémentaires “à la volée” en cas d’utilisation mémoire intensive, modification de la gestion du swap, recréation d’un système de fichier intermédiaire encore plus adapté (qui tient compte du fait qu’il s’agit de swap), etc…

Dans la série…

• Windows’s ReadyBoost vs Linux’s SwapBoost : Quelques détails
• SwapBoost épisode I : Les méthodes simples
• SwapBoost épisode II : Et si on utilisait un simple fichier?

C’est en tout cas une possibilité technique future évoqué par Mark Shuttleworth au cours d’une interview…

Liens (en anglais):

• nouvelle sur Slashdot
• interview complète sur derstandard.at

NB: Ceci est une présentation de liens et non un article complet en lui-même…

Introduction

Ce post fait suite à un post que j’ai publié récemment (Windows’s ReadyBoost vs Linux’s SwapBoost : Quelques détails) et qu’il est préférable que vous lisiez d’abord pour mieux comprendre le contexte.
Pour rappel, ce qui est souvent appellé SwapBoost (très probablement en référence à ReadyBoost) est le fait d’utiliser un support externe utilisant de la mémoire flash pour stocker le swap.

Ce post discute de l’intérêt du procédé, et évoque quelques façons de faire.

Avertissement Important

La mémoire flash est un type de mémoire non volatile qui admet un nombre limité d’écritures. Même si ce nombre est “relativement grand”, il n’en reste pas moins qu’en en faisant une utilisation intensive vous l’usez (beaucoup) plus vite.

Il vous convient donc (si vous utilisez ces méthodes) de considérer la mémoire flash comme quelque chose de consommable, de savoir ce que vous faites (ou d’être prêt à prendre le risque) et de l’assumer.

Si votre clé connait des défaillances (dont aucune garantie n’est fournise quant à leur détection) alors qu’elle sert pour du swap, cela peut également avoir des conséquences (de même que si vous utilisez un module mémoire défaillant).

L’auteur du post n’assume en aucun cas les conséquences et risques (multiples) liées à l’utilisation des méthodes, qui sont présentées à titre purement indicatif.

SwapBoost: est-ce valable?

C’est une bonne question… Déjà premièrement il faut tenir compte des risques, mais ensuite il faut voir ce qu’il y a à gagner!

Il y a plusieurs facteurs qui peuvent vous donner une indication quant à la “valeur apportée” par les méthodes:

• l’utilisation typique actuelle de votre mémoire et votre disque: commencez par surveiller régulièrement l’usage du swap en laissant tourner une commande “top” dans une console. Si vous swappez beaucoup (ie une quantité plus que non négligeable par rapport à la quantité de mémoire RAM physique dont vous disposez) et si en plus quasiment à chaque fois que votre pc “ramme” le voyant du disque dur indique une activité intensive alors il y a des chances pour que la méthode donne du résultat, sinon il y a peu de chance que ce soit utile…
• le prix et la capacité de la clé envisagée: si vous y dédiez une clé de 2 Go pour 7 euros, ça peut sembler correct (au jour du post)
• la performance et le débit de la clé envisagée: vitesse de lecture et d’écriture suffisantes nécessaires: si la moyenne de ces deux vitesses se rapproche de celle de votre disque dur actuel (ou dépasse) alors vous avez des chances d’être gagnant (grâce aux opérations de la clé simultanées avec celles du disque et grâce au temps d’accès plus faible)
• vos autres façon d’agir: quand on peut il est souvent préférable d’ajouter de la RAM, de changer de disque dur ou d’avoir un système à plusieurs disques dur, etc…

Bref ces critères sont non exhaustifs et à titre indicatifs, vous préfèrerez peut être un test réel…

Méthode la plus basique

La méthode la plus simple (parmi celles que je présente) consiste à formater la clé telle qu’elle soit constituée d’une seule partition de swap, et à utiliser ensuite cette partition telle quelle. La méthode est décrite “dans ses grandes lignes” de façon générale et ce post n’en est pas un détail pas à pas. Une maitrise satisfaisante des concepts mis en jeu est donc souhaitable.

• Assurez vous que la clé ne contient aucune donnée que vous ne souhaiteriez garder (et assurez vous que vous comprenez parfaitement le sens de cette remarque avant de poursuivre)
• Commencez par partitionner la clé (ex de commandes: fdisk, cfdisk) préalablement démontée (ou non montée) en une seule partition de type “Linux swap” (type héxa: 82)
• Pour vous évitez des désagréments (suite à une mauvaise “reconnaissance automatique” de la clé par un autre système par exemple): remplissez quelques mégas du début de la partition swap avec des zéros (par exemple avec dd). Si vous ne comprennez pas exactement pourquoi, dites vous que ça ne coute pas grand chose…
• Formatez ensuite la partition en question au type swap (ex de commande: mkswap)

Le reste est à faire ensuite, puis à chaque redémarrage (bon un script peut simplifier…):

• Visualiser le swap déjà utilisé/utilisable par le système (cat /proc/swaps)
• Activer le swap sur la clé et donner une priorité plus élevée à cette partition que celle du swap déjà existant (en root: swapon -p 32767 /chemin_vers_partition_swap_de_la_clé/)
• Désactiver éventuellement les autres partitions swap (en root avec swapoff)

Pour aller plus loin

Cette méthode simpliste présente l’inconvénient de ne rien faire de spécifique pour répartir les écritures sur des zones variables de la clé afin de la faire durer plus longtemps face à l’usure due aux nombres d’écritures.

Face à ça diverses solutions existent, en utilisant plusieurs partitions de swap sur la clé et en jouant sur les priorités par exemple.

Parmi ces solutions, on peut essayer de définir un nombre élevé de partitions sur la clé et faire “tourner circulairement” l’ordre des priorités (option “-p” de swapon) de manière à répartir de façon “suffisante” (dans tout les cas pour rester avec un nombre de partitions raisonnable on reste très loin de la perfection) les écritures sur les différentes zones de la clé. Cette solution reste assez simple car elle peut ne faire intervenir que des programmes déjà existant (partitionnement, activation du swap) et non conçus spécialement pour faire du swap sur clé dans les meilleures conditions.

Il est aussi envisageable de développer des solutions plus poussées et adaptées aux spécificités des clés…

Le mot de la fin (du post)

Plus de vrai mémoire (RAM), c’est mieux!

Dans la série… (UPDATE)

• Windows’s ReadyBoost vs Linux’s SwapBoost : Quelques détails
• SwapBoost épisode I : Les méthodes simples
• SwapBoost épisode II : Et si on utilisait un simple fichier?

If you’ve inserted your Google Analytics code inside your wordpress theme’s template files (for example in footer.php), don’t forget to modify the file of the new theme after a theme change!

(That can easilly explain the syndrom of “0 visitor” with more than 500 kb of logs for the day…)

In fact, this post is here only because I forgot it myself…

Qu’est ce que la technologie ReadyBoost?

La technologie ReadyBoost est une technologie développée par Microsoft pour Windows Vista. Elle consiste à utiliser une clé USB en tant que sorte de mémoire cache pour stocker des fichiers couramment utilisés dans le but d’y accéder ensuite plus rapidement.

Le principe clé mis en avant: les temps d’accès différents

Le principe clé couramment mis en avant pour justifier le gain de performance est le fait que les clés USB ont des temps d’accès souvent bien meilleurs que les disques durs. En effet, contrairement à un disque dur, une clé USB n’est pas composés de plateaux et de têtes de lecture. Le processus physique de déplacement des têtes est la raison des temps d’accès élevés des disques durs: lorsqu’on accède à de l’information de manière non séquentielle, il faut à chaque fois positionner les têtes de lecture. Les clés USB ne font pas intervenir un tel processus physique, le temps d’accès est du pour l’essentiel à la réactivité de l’électronique de la clé, donc il est plutôt bon.

C’est ce type de discussion sur les temps d’accès que l’on peut souvent entendre pour justifier le ReadyBoost…

Qu’est ce que le SwapBoost pour Linux?

Le procédé appelé par un certain nombre de linuxiens comme le SwapBoost (voire parfois comme le “ReadyBoost pour Linux”) est en fait quelque chose qui n’a rien à voire avec le ReadyBoost (il faut clairement le dire), même si au final, le but de gain de performances dans des conditions similaires est souvent atteint (j’y reviendrais).

Il s’agit en fait tout simplement d’utiliser une clé USB en tant que mémoire swap plutôt que d’utiliser le disque dur. On peut ainsi rendre une configuration plus réactive (cf suite).

Deuxième argument clé pour du ReadyBoost / SwapBoost: des accès concurrents

C’est là un argument que je n’entends ou ne lis pas souvent pour le moins, mais qui me parait néanmoins plus qu’essentiel: lorsqu’on lit sur une clé USB et que on l’utilise (pendant un laps de temps) à 100% de ses performances, le disque dur est “libre pour autre chose”. Le système aura donc tendance (quand c’est justifié) à effectuer 2 opérations de lecture (ou une opération de lecture et une d’écriture, etc.) “en même temps”.

Pour mieux comprendre l’importance de cet argument, il convient de voir plus en détail ce qui se passe souvent lorsqu’une machine “ramme”, cela peut par exemple être le cas à l’ouverture d’un programme lourd, par exemple: très souvent dans ce cas il y a un besoin fort en lecture/écriture sur le système de fichier: cela se traduit par une certaine utilisation du disque dur… Mais en plus de ça, typiquement une configuration qui marche au ralentit est souvent une configuration qui n’a pas assez de mémoire. Cela veut dire que le système va chercher à “créer virtuellement de la mémoire en plus”, dit plus rigoureusement il utilise le swap sur disque pour stocker sur un disque (relativement lent) ce qui “devrait” être stocké en RAM (bien plus rapide). Avoir besoin du swap est donc déjà pas si bon… Mais si en plus il y a beaucoup d’autres accès au même disque en même temps, cela ne va plus très bien: une demande “doublée” sur le disque, de nombreux déplacements des têtes supplémentaires. Bref il devient logique que le système marche au ralentit.

Que ce soit en utilisant ReadyBoost ou SwapBoost, on permet donc (d’une façon différente) de faire des accès concurrents sur deux disques différents, ce qui permet de gagner du temps (on peut aussi en gagner en ayant deux disques durs et en “swappant” sur celui le moins utilisé pour les opérations habituelles sur le système de fichier, ou bien encore en utilisant du RAID, etc…).

C’est donc un réel avantage en plus, complémentaire à celui des temps d’accès réduits sur les clés USB.

Une approche typiquement différente mais des résultats similaires: des raisons?

Comme indiqué plus tôt les deux approches (ReadyBoost et SwapBoost) sont tout à fait différentes. Dans un cas (ReadyBoost) il s’agit de mettre en cache des fichiers sur clé USB, dans l’autre cas (SwapBoost) il s’agit de stocker le swap sur la clé USB.

Dans le cas typique de ralentissement évoqué plus tôt, avec la technologie dite SwapBoost, le principe des accès simultanés marche à la condition que des accès disque au système de fichiers soient nécessaires à ce moment (plus que très probable…). La réduction des temps d’accès due à la technologie Flash de la clé s’appliquera sur les accès au swap (donc à priori il y a des chances pour que ce soit assez utile).

Dans ce même cas avec la technologie ReadyBoost, si la selection des fichiers mis en cache a bien marché (i.e. si le système a bien fait son job), il y a des chances pour qu’il y ait des accès concurrents et aussi un bénéfice du au temps d’accès réduits de la clé.

Bien que les technologies soient fondamentalement différentes, elles tendent donc à déboucher sur le même effet en pratique: un gain de performance.

Quelques détails supplémentaires sur ReadyBoost

Pour que cette technologie soit utilisable, il faut qu’un certain nombre de critères soient remplis concernant la clé, notamment de performances concernant cette clé.

Le système utilise du cryptage pour protéger la confidentialité en cas de vol de la clé.

Il est couramment indiqué que les gains de performances réels ne se produisent que pour des configurations avec “peu de mémoire”, afin de rendre la situation “potable”. Cela serait donc des situations où l’on gagne peut-être beaucoup à éviter Windows Vista…

Quelques détails supplémentaires sur SwapBoost

En fait comme indiqué plus tôt SwapBoost est un nom couramment utilisé et ne décrit pas entièrement comment les choses se passent… (Mais par pitié, évitez d’utiliser le nom ReadyBoost pour Linux!)

Tout dépend donc de comment on s’y prend, et j’espère avoir prochainement l’occasion d’en préciser plus à ce sujet…

Dans la série… (UPDATE)

• Windows’s ReadyBoost vs Linux’s SwapBoost : Quelques détails
• SwapBoost épisode I : Les méthodes simples
• SwapBoost épisode II : Et si on utilisait un simple fichier?

Bon le nouveau thème est loin d’être parfait mais au moins il a l’avantage de garder une présentation sur deux colonnes lorsqu’on sélectionne un post précis (contrairement au thème précédent).

Il se peut que des posts rendent mal avec ce nouveau thème (notamment car les balises <code>…</code> ne rendent pas pareil qu’avec l’ancien thème). Si c’est le cas, n’hésitez pas à me le signaler!

Voilà, inutile de me le dire, je sais bien que HTTP/1.0 et HTTP/1.1 sont au départ deux versions d’un protocole, HTTP/1.1 étant tout simplement plus récente que HTTP/1.0. Alors pourquoi donc un tel titre? Le fait est que la plupart des navigateurs récents envoient des requêtes HTTP/1.1 (jusqu’ici logique), mais pour des raisons qui m’échappent, beaucoup de bots (ou de proxies de temps en temps) semblent envoyer des requêtes HTTP/1.0 (en fait ce qui m’échappe le plus est de savoir pourquoi envoyer des requêtes HTTP/1.0 quand on a pris la peine de trafiquer le champ User-Agent pour qu’il ressemble à un navigateur ordinaire).

Lorsque l’on établit des blocages grace au .htaccess, le but est souvent de rendre les blocages les plus restrictifs possibles, c’est à dire qu’ils ne bloquent que les personnes, bots ou IPs que l’on veut bloquer. Cela peut être un robot qui visite à vitesse démesurée les pages de votre site (par exemple plus de 200 requêtes en très peu de temps), un robot spammeur, etc… Pour moi les buts principaux sont la protection des ressources (lorsqu’on a un trafic mensuel limité c’est normal), la protection contre les attaques visant à altérer le fonctionnement de mes sites ou à récupérer des mots de passe, ainsi que la protection contre le spam (commentaires, etc…).

J’envisage donc de rajouter à l’avenir dans mes règles de blocages (avec un “et logique” par rapport au règles déjà établies, il n’est pas question de bloquer plus mais au contraire de cibler plus), une vérification de la version de protocole HTTP employée (dans les cas où ça marche).

Voilà si quelqu’un a des liens utiles vers des ressources telles qu’une liste correspondant au protocoles utilisées selon le navigateur (et l’User-Agent), ou d’autres pages évoquant le lien (statistique seulement) entre HTTP/1.0 et bot plus probable, je suis preneur (y compris des liens vers des pages en anglais).

UPDATE (le même jour): Après quelques observations (supplémentaires), pour les proxies (ou proxies suspectés), ça semble être du 50/50 entre les deux versions (en gros), pour les accès direct avec un navigateur récent (ou ce qui y ressemble) ça semble être quasiment tout le temps du HTTP/1.1, et pour les robots et lecteurs de feeds, il y a une très forte proportion de HTTP/1.0… Comme je évoqué plus tôt le seul intérêt semble donc être de limiter les effets des bloquages (ex: si un bot se comporte mal avec votre site web et que ce bot n’utilise que HTTP/1.0, autant ne bloquer que ce protocole). Pour trouver qui/quoi bannir, le mieux semble être de regarder régulièrement ses logs (et éventuellement en plus de les analyser automatiquement pour réagir au plus vite).

Voilà je n’ai pas l’habitude de faire du copier/coller et je ne vois rien de particulièrement nouveau à ajouter, donc pour faire bref si vous êtes intéressés par les dernières actualités des smartphones libres je ne peux que vous recommander l’article Consolidation des smartphones libres : LiPS fusionne avec LiMo (évoque bien plus que le titre laisse penser) sur DLFP.

Petite anecdote du web totalement secondaire: si vous trouvez les url réduites de tinyurl.com (cf article wikipédia) encore trop longues, il y a un “concurrent” qui semble encore plus efficace: ur1.ca: il semble actuellement possible de produire des url aussi courtes que “ur1.ca/7i”. Ceci dit je vois quelques particularités dans le système:

• Les adresses semblent être attribuées de façon assez séquentielles (voir “ur1.ca/7h”, “ur1.ca/7g”, etc.), il est donc assez probable que des histoires similaires à tinyurl.com/dick réapparaissent… (À noter que tinyurl a visiblement décidé de faire mieux depuis peu… il semblerait qu’on ait du choix réel sur les urls: http://tinyurl.com/tinyurltinyurl -> http://attribuer_lineairement.saimal.fr/)
• Il semble très aisé de s’attribuer une plage et de faire pointer les url en cascade (ou une url sur elle même): si c’est trop utilisé et que des gens publient des url qui font travailler plus leur serveurs… Pas très bon (même si il y a une limite sur le nombre de redirection qu’un navigateur suit…)!

UPDATE: L’adresse de ce blog est http://ur1.ca/aa ou http://ur1.ca/ab (au choix)