C'est bête parce que ça veut aussi dire (entre autre) Calling Line Identification. Dont dérive le CLIP (Calling Line Identification Presentation) qui est la présentation du numéro de l'appelant.
Pour une liste francophone, ce n'est pas terrible d'utiliser une abréviation en anglais.
Concernant les systèmes de fichiers adaptés aux mémoires non volatiles; la réponse n'est pas simple.
Tous les supports ne sont pas égaux. La mémoire Flash doit être effacé et écrite par blocs, il vaut éviter de fatiguer prématurément certaines cellules en les modifiant en permanence. Comme pratiquement tous les appareils travaillent en FAT qui demande une ré-écriture continuelle de ces secteurs, les fabriquants ont carrément intégré dans les controleurs un mécanisme d'indirection pour faire une rotation des cellules.
Pour la MRAM, on ne connait pas encore très bien ses limites, ou en tout cas elles ne sont pas publiques. Il y a des FS adaptés à la Flash, qui ont été cité. Si la MRAM ne souffre pas de ces limitations, alors ils ne seront probablement pas adaptés. Un autre facteur a prendre en compte est la garantie d'atomicité des écritures; que se passe-t'il lorsqu'il y a une coupure au milieu d'une écriture ? Si l'écriture est faite octet par octet, ça va compliquer les choses, on va avoir beaucoup de mal à retrouver où est-ce que l'on s'est arreté, si c'est par secteur de 512 octets, c'est comme un disque ordinaire...
Les FS classiques ne sont plus vraiment optimisés pour la géométrie des disques. Aujourd'hui je ne pense pas que l'on fabrique encore de disques qui publient leur géométrie réelle; on tombe toujours sur une géométrie logique qui permet de booter, ensuite le FS se base sur une couche d'abstraction qui fonctionne en blocs logiques.Les FS n'ont donc pas spécialement de contre indication pour leur usage sur de la MRAM.
Cout de la solution :
n noeuds
n robotiques
bandes SDLT/LTO ...
logiciel de sauvegarde gérant des sauvegardes incrémentales / différencielles
Le problème, c'est qu'une bande SDLT, ça fait dans les 500 Go, imaginons un robot avec 32 slots, on a une capacité de 16 To, ce qui est loin de la capacité totale. Installer 50 robots n'est pas une solution viable, à cause du coût et de la maintenance que cela impose.
Et puis vu le budget qu'il est possible de dégager d'une boite au lettre de FAI (quelques dizaines de centime d'euros par mois), le robot est loin d'être remboursé, en plus de toute l'infrastructure pour rendre le service.
Si on considère 100 Mo de taille moyenne de boite par client, ça fait un robot pour 160.000 clients.
- la redondance ?
La redondance n'est pas une méthode de sauvegarde !!! Et bien évidement, personne ne s'amuse à faire du RAID0, sur de tels volumes, on a toujours du SAN et/ou du NAS avec du RAID 1 ou du RAID5, mais le RAID ne fait pas grand chose face à un incendie ou un formattage sauvage.
- la mutualisation ?
La mutualisation ne change rien aux volumes à sauver, ce qui est le problème ici.
Ce n'est pas la taille qui compte, bien heureusement, sinon toute entreprise avec des To et des To de données à traiter verraient des gouttes de sueur froide couler sur le front de leurs admins régulièrement.
Je ne suis pas du tout d'accord:
- Le volume de donnée à un très fort impact sur le coût de la sauvegarde.
- Les données à sauver ont aussi une valeur qui n'est pas liée au volume.
Dans un message au dessus quelqu'un proposait d'ajouter une baie de disques à la baie nominale, or une baie de disque à un coût énorme, si on veut avoir une unique sauvegarde, il faut pratiquement doubler le coût du stockage. Si on veut faire des sauvegardes incrémentales, conserver quelques snapshot, alors il faut encore augmenter la volumétrie, et donc le coût.
Si ça se justifie tout à fait pour une base de gestion commerciale, avec les clients et les commandes à traiter; informations qui ont généralement un prix énorme pour une entreprise, c'est beaucoup plus discutable pour des boites aux lettres qui ont une valeur très faible.
Il y a énormément de moyens de sauvegarde et de récupération des données adaptés aux différents types de données à stocker.
Pour un petit FAI qui n'a que 700 Go de mail, c'est encore envisageable; mais lorsque ça tourne autour de 700 To de mail, je ne vois pas trop quelle solution permettrait de faire des sauvegardes.
Et imaginons qu'un gars réponde à ces critières, il faudrait que les poursuites à l'encontre de "DVD Jon" ne le décourage pas.
DVD Jon a fait de la publicité autour de son travail, mais avec les joies d'internet, rien n'interdit à quelqu'un de publier son travail anonymement.
Il y a quelques développeurs de drivers Linux (probablement pas aux USA) qui ont ouvert des serveurs FTP avec upload garanti "sans logs" dans lesquels ils trouvent de temps en temps des specs et des bouts de code qui sont arrivés là tout seul et qui documentent le fonctionnement de certains matériels dont la documentation n'est pas publique.
Avec Freenet, on peut faire la même chose facilement j'imagine.
Tu fais des tests avec -s pour savoir si le fichier existe. En général on utilise plutot le -r.
-s FILE True if file exists and is not empty.
-r FILE True if file is readable by you.
Si le fichier est vide, on s'en fiche un peu, ça n'empèche pas de le sourcer; par contre, s'il n'est pas lisible, ça va provoquer une erreur. Il est aussi possible de remonter une erreur si le fichier n'est pas lisible.
Tu retournes l'aide en exécutant pratiquement vingt fois la commande echo. Dans bash, c'est une commande interne qui ne fait peut-être pas un fork, mais avec d'autres shell, cela peut faire appel à une commande externe. Pour cela, on préfère généralement faire un seul echo, ou un cat
echo -e "Première ligne\\nSeconde ligne"
echo "Première ligne
Seconde ligne"
ou encore
cat << _VERSION_
Première ligne
Seconde ligne
_VERSION_
Si le wget retourne une erreur, tu ne testes rien, tu te contentes de regarder si quelque chose sort au bout de la chaine.
L'adresse IP du routeur est codée en dur à 192.168.1.1
wget utilise la version courte des paramêtres, rendant la relecture du script plus compliquée.
Il y a aussi une dépendance sur logger, je ne sais pas s'il est présent sur toutes les distribs, sous les BSD...
Voila, sinon c'est encourageant de voir qu'il y a encore des choses écrites proprement. Quand je vois ce pourquoi on paye au boulot...
Je pense que c'est le cas, au boulot on a des dizaines de serveurs avec des JVM sous tout un tas d'OS et clairement, Windows n'est pas favorisé par rapport à Linux.
Si je me souviens bien, les benchs faisaient resortir que les versions Sparc/Solaris étaient plutôt plus performantes, mais ça date de Java 1.2; je n'ai pas fait de bench sur des versions plus récentes pour voir la différence.
Sous windows y'a d'autres trucs à faire dans le panneau de configuration:
- Changer la langue du clavier
- Inverser les boutons de la souris
- Accélérer ou ralentir la souris au maximum
- Mettre le délai de répétition des touches au minimum
Ce sont aussi des choses que l'on peut faire sous X avec la commande xset.
La commande iptables permet de faire cela, et de manière bien plus fine, elle est également un peu plus pénible à utiliser parce qu'elle controle l'effective group id (egid). Voir le paragraphe sur le module "owner" de la page de manuel.
Il est possible de bloquer l'accès à certain site, à certains ports, à certaines heures, de laisser la résolution de nom (souvent utile)...
Les interfaces réseaux ne sont pas dans /dev/ parce que les gens qui l'ont développé ont estimé que cela n'apportait rien. Le Linux Networking Howto dit http://www.tldp.org/HOWTO/NET3-4-HOWTO-5.html#ss5.3
In many Unix operating systems the network devices have appearances in the /dev directory. This is not so in Linux. In Linux the network devices are created dynamically in software and do not require device files to be present.
Les périphériques dans /dev/ ont deux analogies possibles:
- ceux en mode bloc, comme un disque dur, sur lequel on peut se positionner, lire et écrire à une position arbitraire
- ceux en mode caractère, comme un terminal, sur lequel on se contente de lire les octets dans l'ordre ou ils arrivent et ou aucun déplacement dans le flux n'est possible.
Une interface réseau ne présente aucune analogie ni avec le mode bloc ni avec le mode caractère. On pourrait éventuellement lui trouver une ressemblance avec le mode caractère dans le cas où l'on récupère tout ce qui passe sur le médium de transmission (première couche OSI http://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI ), et écrire du code pour faire l'abstraction, mais
- la variété des supports rend cette analogie douteuse et sans grand intérêt (liaison série point à point, ethernet, carte réseau sans fil à sauts de fréquence...)
- cela n'est pas toujours disponible ou souhaitable pour des raisons de performance, les cartes tendent à gérer des choses de plus en plus haut niveau par elles même dans la couche OSI (Retransmission, checksums variés, ARP, découpage TCP... voir le Via Velocity VT6122 http://www.vntek.com/en/products/velocity/ qui est dans la Dedibox de Iliad)
Donc le noyau n'a pas de périphérique à présenter parce qu'il n'y aurait rien à faire dessus.
Au début, ça gène un peu l'utilisateur, un peu plus avec udev et consorts parce qu'on prends l'habitude de regarder dans /dev/ pour voir ce qui existe; et puis on s'y fait.
Est-ce que tu vois un usage des interfaces réseau dans /dev/ ?
/dev/ethX sont les noms habituels des périphériques ethernet. Le Wi-Fi est très éloigné d'ethernet, il n'y a pas vraiment de raison de lui donner ce nom, au contraire.
Par contre, je suis d'accord qu'un peu d'unité dans les noms des périphériques Wi-Fi ne ferait pas de mal.
Le travail de Devicescape avec le kernel n'a pas commencé le 1er mai; et ils n'ont pas travaillé tous seuls dans leur coin, sans quoi il y aurait vraiment peu de chances que ce qu'ils ont produit soit intégré dans le kernel.
On peut voir en lisant http://lwn.net/Articles/179305/ qui a déjà été cité; que Devicescape a beaucoup travaillé avec les gens du noyau. Ils étaient présent au 2006 Wireless Networking Summit les 6 et 7 avril chez OSDL et sont des contributeurs majeurs. C'est ce qui donne de la valeur au don de code de Devicescape.
Cela ne change rien au fait que l'annonce a eu lieu le 1er mai et qu'avant, aucune annonce officielle n'avait été faite, ni de Devicescape, ni sur LinuxFR.
UTF-8 permet de représenter le code d'un caractère jusqu'à 21 bits, ces 21 bits sont répartis dans 4 octets.
Il serait possible d'étendre UTF-8 pour coder jusqu'à 31 bits, mais la norme d'aujourd'hui l'interdit (cela ferai 6 octets pour les caractères de code élevé).
En UTF-16, c'est plus compliqué, parce qu'on fait l'extension sur une plage de non-caractères (qui deviennent alors non-représentable, mais les utilise-t'on si ce sont des non-caractères), il est possible de représenter 20 bits, auquels viennent s'ajouter les 16 bits des caractères ordinaire (à l'exception de la plage des non-caractères).
En UCS-2, on peut représenter 16 bits
En UCS-4 on peut représenter 32 bits
En UTF-32, qui est un sous-ensemble de UCS-4, on peut représenter un peu moins de 21 bits, (de U+0 à U+10FFFF), parce que la norme interdit d'aller plus loin.
Finalement nous n'avons aucun mécanisme qui permettent de représenter un caractère de code arbitraire, quelque soit les extensions que nous feront à la norme Unicode si elle évolue encore.
Je ne connais pas la réponse à la question parce qu'il s'agit de détails d'implémentation, mais il y a trois solutions, ou familles de solution, plus ou moins couteuses:
* On ne fait rien, et une couche supplémentaire vient faire le travail. C'est ce qui est fait par exemple en XML/HTML: une entité permet de représenté un caractère unicode quelconque alors que le document est dans un codage qui ne permet pas de le représenter directement.
* On change tout pour augmenter la taille allouée à un caractère, en espérant que cette fois ci, on aura suffisement de place.
* On bricole pour rester compatible. UTF-8 est de ce coté un mécanisme très bien conçu: les programmes qui pensent qu'un caractère est un octet doivent continuer à fonctionner, mais un mécanisme doit permettre aux programme "aware" de placer des caractères supplémentaires. Au passage, il ne faut pas qu'un caractère codé sur plusieurs octets génère des octets qui seraient interprété comme un caractère de controle par un programme d'ancienne génération.
Pour le problème de Windows et de Java, on peut faire exactement la même extension, mais sur 16 bits. Ca s'appelle UTF-16. Un programme qui est purement UCS-2 verra des caractères, plusieurs caractères étrange à la place de ceux qui dépassent U+0FFFF, mais cela ne lui posera pas de problème. Un programme travaillant en UTF-16 sera capable de reconnaitre certaines séquences de caractères de 16 bits et de produire le caractère étendu correspondant.
[^] # Re: CLI ?
Posté par Sébastien Koechlin . En réponse au journal Un wiki sur la CLI. Évalué à 6.
Pour une liste francophone, ce n'est pas terrible d'utiliser une abréviation en anglais.
Il faudrait peut-être s'inscrire à l'a.a.a.a.a.a.
[^] # Re: Bravo !
Posté par Sébastien Koechlin . En réponse à la dépêche Le futur des systèmes de fichiers discuté au Linux Filesystems Workshop 2006. Évalué à 10.
Tous les supports ne sont pas égaux. La mémoire Flash doit être effacé et écrite par blocs, il vaut éviter de fatiguer prématurément certaines cellules en les modifiant en permanence. Comme pratiquement tous les appareils travaillent en FAT qui demande une ré-écriture continuelle de ces secteurs, les fabriquants ont carrément intégré dans les controleurs un mécanisme d'indirection pour faire une rotation des cellules.
Pour la MRAM, on ne connait pas encore très bien ses limites, ou en tout cas elles ne sont pas publiques. Il y a des FS adaptés à la Flash, qui ont été cité. Si la MRAM ne souffre pas de ces limitations, alors ils ne seront probablement pas adaptés. Un autre facteur a prendre en compte est la garantie d'atomicité des écritures; que se passe-t'il lorsqu'il y a une coupure au milieu d'une écriture ? Si l'écriture est faite octet par octet, ça va compliquer les choses, on va avoir beaucoup de mal à retrouver où est-ce que l'on s'est arreté, si c'est par secteur de 512 octets, c'est comme un disque ordinaire...
Les FS classiques ne sont plus vraiment optimisés pour la géométrie des disques. Aujourd'hui je ne pense pas que l'on fabrique encore de disques qui publient leur géométrie réelle; on tombe toujours sur une géométrie logique qui permet de booter, ensuite le FS se base sur une couche d'abstraction qui fonctionne en blocs logiques.Les FS n'ont donc pas spécialement de contre indication pour leur usage sur de la MRAM.
# FS capables de grossir
Posté par Sébastien Koechlin . En réponse au journal Gestion de volumes. Évalué à 3.
Si tu avais choisi un truc lent et obsolète comme le FAT qui est lisible partout, tu n'aurais pas pu étendre tes partitions, monter à 350 Go.
Je ne suis pas certain que ce soit ce que tu cherches.
[^] # Re: Et zut
Posté par Sébastien Koechlin . En réponse au journal World Jump Day: c'est demain !. Évalué à 6.
A non pardon, on me dit dans mon oreillette que c'est Richard qui a mis la clim plus fort.
[^] # Re: GNU/Linux
Posté par Sébastien Koechlin . En réponse au journal Indignation : Ebay et Linux. Évalué à 1.
[^] # Re: Et les backups ?
Posté par Sébastien Koechlin . En réponse au journal Il y a 2 catégories d'administrateurs .... Évalué à 1.
n noeuds
n robotiques
bandes SDLT/LTO ...
logiciel de sauvegarde gérant des sauvegardes incrémentales / différencielles
Le problème, c'est qu'une bande SDLT, ça fait dans les 500 Go, imaginons un robot avec 32 slots, on a une capacité de 16 To, ce qui est loin de la capacité totale. Installer 50 robots n'est pas une solution viable, à cause du coût et de la maintenance que cela impose.
Et puis vu le budget qu'il est possible de dégager d'une boite au lettre de FAI (quelques dizaines de centime d'euros par mois), le robot est loin d'être remboursé, en plus de toute l'infrastructure pour rendre le service.
Si on considère 100 Mo de taille moyenne de boite par client, ça fait un robot pour 160.000 clients.
[^] # Re: Et les backups ?
Posté par Sébastien Koechlin . En réponse au journal Il y a 2 catégories d'administrateurs .... Évalué à 1.
La redondance n'est pas une méthode de sauvegarde !!! Et bien évidement, personne ne s'amuse à faire du RAID0, sur de tels volumes, on a toujours du SAN et/ou du NAS avec du RAID 1 ou du RAID5, mais le RAID ne fait pas grand chose face à un incendie ou un formattage sauvage.
- la mutualisation ?
La mutualisation ne change rien aux volumes à sauver, ce qui est le problème ici.
Ce n'est pas la taille qui compte, bien heureusement, sinon toute entreprise avec des To et des To de données à traiter verraient des gouttes de sueur froide couler sur le front de leurs admins régulièrement.
Je ne suis pas du tout d'accord:
- Le volume de donnée à un très fort impact sur le coût de la sauvegarde.
- Les données à sauver ont aussi une valeur qui n'est pas liée au volume.
Dans un message au dessus quelqu'un proposait d'ajouter une baie de disques à la baie nominale, or une baie de disque à un coût énorme, si on veut avoir une unique sauvegarde, il faut pratiquement doubler le coût du stockage. Si on veut faire des sauvegardes incrémentales, conserver quelques snapshot, alors il faut encore augmenter la volumétrie, et donc le coût.
Si ça se justifie tout à fait pour une base de gestion commerciale, avec les clients et les commandes à traiter; informations qui ont généralement un prix énorme pour une entreprise, c'est beaucoup plus discutable pour des boites aux lettres qui ont une valeur très faible.
Il y a énormément de moyens de sauvegarde et de récupération des données adaptés aux différents types de données à stocker.
Que proposes-tu pour ce cas précis ?
[^] # Re: Et les backups ?
Posté par Sébastien Koechlin . En réponse au journal Il y a 2 catégories d'administrateurs .... Évalué à 1.
# Rideaux de feu
Posté par Sébastien Koechlin . En réponse au journal Cinq ans de VoIP libre!. Évalué à 10.
L'analogie utilisée est exactement l'inverse du mur de feu. Le feu symbolise les attaques néfastes, et le pare-feu protège de ces attaques.
# Install party
Posté par Sébastien Koechlin . En réponse au journal Un grand moment culinaire. Évalué à 2.
Avec un menu surprise ? Tiens, j'ai eu une Redflag Linux en xfs (c'était la semaine asiatique).
[^] # Re: Bah ... pas moche.
Posté par Sébastien Koechlin . En réponse au journal encore un bureau pas pratique. Évalué à 2.
[^] # Re: CSS est aussi un DRM
Posté par Sébastien Koechlin . En réponse au journal Les DVD pourris arrivent .... Évalué à 2.
DVD Jon a fait de la publicité autour de son travail, mais avec les joies d'internet, rien n'interdit à quelqu'un de publier son travail anonymement.
Il y a quelques développeurs de drivers Linux (probablement pas aux USA) qui ont ouvert des serveurs FTP avec upload garanti "sans logs" dans lesquels ils trouvent de temps en temps des specs et des bouts de code qui sont arrivés là tout seul et qui documentent le fonctionnement de certains matériels dont la documentation n'est pas publique.
Avec Freenet, on peut faire la même chose facilement j'imagine.
[^] # Re: Mouais
Posté par Sébastien Koechlin . En réponse au journal Les mousquetaires, un remake de 3 zéros.... Évalué à 1.
Une fois, le livreur qui avait oublié un carton, est même repassé le soir à la fin de sa tournée.
Visiblement les mousquetaires ne sont pas au niveau.
# Quelques remarques sur le script
Posté par Sébastien Koechlin . En réponse au journal Hébergement dynamique et modem ADSL Comtrend. Évalué à 4.
Tu fais des tests avec -s pour savoir si le fichier existe. En général on utilise plutot le -r.
-s FILE True if file exists and is not empty.
-r FILE True if file is readable by you.
Si le fichier est vide, on s'en fiche un peu, ça n'empèche pas de le sourcer; par contre, s'il n'est pas lisible, ça va provoquer une erreur. Il est aussi possible de remonter une erreur si le fichier n'est pas lisible.
Tu retournes l'aide en exécutant pratiquement vingt fois la commande echo. Dans bash, c'est une commande interne qui ne fait peut-être pas un fork, mais avec d'autres shell, cela peut faire appel à une commande externe. Pour cela, on préfère généralement faire un seul echo, ou un cat
echo -e "Première ligne\\nSeconde ligne"
echo "Première ligne
Seconde ligne"
ou encore
cat << _VERSION_
Première ligne
Seconde ligne
_VERSION_
Si le wget retourne une erreur, tu ne testes rien, tu te contentes de regarder si quelque chose sort au bout de la chaine.
L'adresse IP du routeur est codée en dur à 192.168.1.1
wget utilise la version courte des paramêtres, rendant la relecture du script plus compliquée.
Il y a aussi une dépendance sur logger, je ne sais pas s'il est présent sur toutes les distribs, sous les BSD...
Voila, sinon c'est encourageant de voir qu'il y a encore des choses écrites proprement. Quand je vois ce pourquoi on paye au boulot...
[^] # Re: he be
Posté par Sébastien Koechlin . En réponse au journal Java bientot libre ?. Évalué à 5.
Si je me souviens bien, les benchs faisaient resortir que les versions Sparc/Solaris étaient plutôt plus performantes, mais ça date de Java 1.2; je n'ai pas fait de bench sur des versions plus récentes pour voir la différence.
[^] # Re: xhost +
Posté par Sébastien Koechlin . En réponse au journal Petites blagues de Geek. Évalué à 2.
- Changer la langue du clavier
- Inverser les boutons de la souris
- Accélérer ou ralentir la souris au maximum
- Mettre le délai de répétition des touches au minimum
Ce sont aussi des choses que l'on peut faire sous X avec la commande xset.
[^] # Re: nommage des interfaces réseaux
Posté par Sébastien Koechlin . En réponse à la dépêche Une pile Wi-Fi améliorée pour le noyau Linux ?. Évalué à 3.
Il est possible de bloquer l'accès à certain site, à certains ports, à certaines heures, de laisser la résolution de nom (souvent utile)...
[^] # Re: nommage des interfaces réseaux
Posté par Sébastien Koechlin . En réponse à la dépêche Une pile Wi-Fi améliorée pour le noyau Linux ?. Évalué à 5.
Les interfaces réseaux ne sont pas dans /dev/ parce que les gens qui l'ont développé ont estimé que cela n'apportait rien. Le Linux Networking Howto dit http://www.tldp.org/HOWTO/NET3-4-HOWTO-5.html#ss5.3
Les périphériques dans /dev/ ont deux analogies possibles:
- ceux en mode bloc, comme un disque dur, sur lequel on peut se positionner, lire et écrire à une position arbitraire
- ceux en mode caractère, comme un terminal, sur lequel on se contente de lire les octets dans l'ordre ou ils arrivent et ou aucun déplacement dans le flux n'est possible.
Une interface réseau ne présente aucune analogie ni avec le mode bloc ni avec le mode caractère. On pourrait éventuellement lui trouver une ressemblance avec le mode caractère dans le cas où l'on récupère tout ce qui passe sur le médium de transmission (première couche OSI http://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI ), et écrire du code pour faire l'abstraction, mais
- la variété des supports rend cette analogie douteuse et sans grand intérêt (liaison série point à point, ethernet, carte réseau sans fil à sauts de fréquence...)
- cela n'est pas toujours disponible ou souhaitable pour des raisons de performance, les cartes tendent à gérer des choses de plus en plus haut niveau par elles même dans la couche OSI (Retransmission, checksums variés, ARP, découpage TCP... voir le Via Velocity VT6122 http://www.vntek.com/en/products/velocity/ qui est dans la Dedibox de Iliad)
Donc le noyau n'a pas de périphérique à présenter parce qu'il n'y aurait rien à faire dessus.
Au début, ça gène un peu l'utilisateur, un peu plus avec udev et consorts parce qu'on prends l'habitude de regarder dans /dev/ pour voir ce qui existe; et puis on s'y fait.
Est-ce que tu vois un usage des interfaces réseau dans /dev/ ?
[^] # Re: nommage des interfaces réseaux
Posté par Sébastien Koechlin . En réponse à la dépêche Une pile Wi-Fi améliorée pour le noyau Linux ?. Évalué à 4.
Par contre, je suis d'accord qu'un peu d'unité dans les noms des périphériques Wi-Fi ne ferait pas de mal.
# Un commentaire de la pile
Posté par Sébastien Koechlin . En réponse à la dépêche Une pile Wi-Fi améliorée pour le noyau Linux ?. Évalué à 5.
http://www.linux-watch.com/news/NS6755691725.html
un texte de Vaughan-Nichols's qui donne pas mal de précision sur le code de Devicescape
[^] # Re: incohérence
Posté par Sébastien Koechlin . En réponse à la dépêche Une pile Wi-Fi améliorée pour le noyau Linux ?. Évalué à 6.
On peut voir en lisant http://lwn.net/Articles/179305/ qui a déjà été cité; que Devicescape a beaucoup travaillé avec les gens du noyau. Ils étaient présent au 2006 Wireless Networking Summit les 6 et 7 avril chez OSDL et sont des contributeurs majeurs. C'est ce qui donne de la valeur au don de code de Devicescape.
Cela ne change rien au fait que l'annonce a eu lieu le 1er mai et qu'avant, aucune annonce officielle n'avait été faite, ni de Devicescape, ni sur LinuxFR.
[^] # Re: Pour faire de la pub......
Posté par Sébastien Koechlin . En réponse au journal Comment assurer une promotion correcte d'un logiciel ?. Évalué à -10.
# Pas très clair
Posté par Sébastien Koechlin . En réponse au journal Se vêtir geek pour moins de 5¤ (Journal pratique). Évalué à 2.
On ne sait pas trop quel couche se colle où, qu'est ce qu'il faut découper (et avec quoi ? Un cutter si c'est collé ?)
Qu'obtient-on au final ? Un tissus collé, un papier collé, comment est-ce que ça résiste aux lavages ?
[^] # Re: Codage des caractères ?
Posté par Sébastien Koechlin . En réponse à la dépêche Appel à commentaires sur le référentiel général d'interopérabilité. Évalué à 4.
UTF-8 permet de représenter le code d'un caractère jusqu'à 21 bits, ces 21 bits sont répartis dans 4 octets.
Il serait possible d'étendre UTF-8 pour coder jusqu'à 31 bits, mais la norme d'aujourd'hui l'interdit (cela ferai 6 octets pour les caractères de code élevé).
En UTF-16, c'est plus compliqué, parce qu'on fait l'extension sur une plage de non-caractères (qui deviennent alors non-représentable, mais les utilise-t'on si ce sont des non-caractères), il est possible de représenter 20 bits, auquels viennent s'ajouter les 16 bits des caractères ordinaire (à l'exception de la plage des non-caractères).
En UCS-2, on peut représenter 16 bits
En UCS-4 on peut représenter 32 bits
En UTF-32, qui est un sous-ensemble de UCS-4, on peut représenter un peu moins de 21 bits, (de U+0 à U+10FFFF), parce que la norme interdit d'aller plus loin.
Finalement nous n'avons aucun mécanisme qui permettent de représenter un caractère de code arbitraire, quelque soit les extensions que nous feront à la norme Unicode si elle évolue encore.
[^] # Re: Codage des caractères ?
Posté par Sébastien Koechlin . En réponse à la dépêche Appel à commentaires sur le référentiel général d'interopérabilité. Évalué à 4.
* On ne fait rien, et une couche supplémentaire vient faire le travail. C'est ce qui est fait par exemple en XML/HTML: une entité permet de représenté un caractère unicode quelconque alors que le document est dans un codage qui ne permet pas de le représenter directement.
* On change tout pour augmenter la taille allouée à un caractère, en espérant que cette fois ci, on aura suffisement de place.
* On bricole pour rester compatible. UTF-8 est de ce coté un mécanisme très bien conçu: les programmes qui pensent qu'un caractère est un octet doivent continuer à fonctionner, mais un mécanisme doit permettre aux programme "aware" de placer des caractères supplémentaires. Au passage, il ne faut pas qu'un caractère codé sur plusieurs octets génère des octets qui seraient interprété comme un caractère de controle par un programme d'ancienne génération.
Pour le problème de Windows et de Java, on peut faire exactement la même extension, mais sur 16 bits. Ca s'appelle UTF-16. Un programme qui est purement UCS-2 verra des caractères, plusieurs caractères étrange à la place de ceux qui dépassent U+0FFFF, mais cela ne lui posera pas de problème. Un programme travaillant en UTF-16 sera capable de reconnaitre certaines séquences de caractères de 16 bits et de produire le caractère étendu correspondant.