Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.
Auteur(s) du livre : Richard Gillam
Éditeur : Addison-Wesley
Première rédaction de cet article le 27 décembre 2002
Pour tous ceux qui sont désormais :-) convaincus de l'utilité d'Unicode (parce qu'ils travaillent dans un environnement non-anglo-saxon ou simplement parce qu'ils sont sensibles à la diversité culturelle du monde), voici un livre qui évitera de se cogner le texte de la norme. Celle-ci n'est pas incompréhensible (un peu plus austère qu'un RFC mais beaucoup moins que les normes ITU/ISO) mais c'est une norme, elle n'a pas de vocation pédagogique.
Le livre de Gillam, au contraire, se veut une introduction pratique et claire à Unicode, et notamment aux problèmes pratiques que pose son déploiement. Il cible les programmeurs d'abord, les ingénieurs système et réseaux ensuite.
Il explique très bien les concepts de base d'Unicode (si différents des autres jeux de caractère que beaucoup de bêtises ont été écrites par des informaticiens n'ayant rien compris à Unicode) et il a notamment une utilisation originale du modèle en couches appliqué aux jeux de caractères (Unicode a cinq couches).
Le chapitre historique est passionnant, avec plein de détails sur les techniques d'encodage (un encodage n'est pas juste un choix arbitraire de bits pour représenter une information, il a des avantages et des inconvénients).
Les sujets très difficiles de la canonicalisation ("masse" est-il l'équivalent de "maße" ?) ou de la bidirectionnalité ("Avram said 'Mazel Tov', and smiled", avec la phrase du milieu en hébreu) sont très bien traités, très clairs.
Une grande (peut-être trop grande, mais c'est la taille d'Unicode qui est en cause) partie est consacrée à l'examen de beaucoup d'écritures, avec leurs particularités (il n'existe pas une écriture sans au moins une idiosyncrasie gênante à implémenter, pas une langue qui ne rajoute ses propres variations ; vous connaissiez le "French accent sorting" ?). Un voyage passionnant, et plein de jolis dessins.
Les derniers chapitres, consacrés à l'implémentation, raviront ceux qui se souviennent avec émotion du cours de Structures de Données à la fac. Plein de solutions rigolotes et détaillées à des problèmes spécifiques à Unicode (la plupart des opérations nécessitent une table, contrairement à ASCII, et il n'est pas évident de gérer une table de 2^21 entrées). On y retrouve même le « trie » des routeurs IP, qui sert aussi, par exemple, aux conversions de l'alphabet latin tapé au clavier en cyrillique (car il y a la meme règle du longest match).
La plupart des codes sont en Java mais aucun gadget objet n'est utilisé et ces exemples sont facilement compréhensibles.
Quelques critiques : le chapitre 1 est bâclé (confondant Unicode et UTF-16) et contredit le texte ultérieur (qui explique bien la différence). Il y a des erreurs manifestes concernant le monde Internet qu'il connait évidemment peu (le livre d'Andries est bien meilleur sur ce point). Et la dernière partie sur le support d'Unicode dans les langages de programmation et dans les systèmes d'exploitation n'est qu'une synthèse d'informations officielles, dans un domaine où tout système prétend être Unicode et où le diable est dans les détails (quel niveau de support Unicode, exactement ?)
Auteur(s) du livre : C.J. Date, Hugh Darwen
Éditeur : Addison-Wesley
Première rédaction de cet article le 24 octobre 2002
Alors qu'il existe plein de livres sur tel ou tel SGBD et ses fonctions rigolotes (une dizaine d'O'Reilly différents pour Oracle, quatre livres sur PostgreSQL, qui n'en avait aucun un an auparavant), il existe peu de livres se concentrant sur le langage SQL et ses caractéristiques indépendantes du SGBD.
Bien sûr, on peut toujours lire le standard lui-même. D'abord, il faut le trouver (ce n'est pas un RFC, il n'est pas en ligne, il semble qu'on ne puisse même pas obtenir une forme machine, même en payant). Ensuite, il faut le lire. Des centaines de pages écrites serrées, sans souci pédagogique, avec un vocabulaire complètement non standard (comme "authID" au lieu de "user").
Bref, un guide est le bienvenu. "A guide to the SQL standard" ne vise pas les débutants complets, ni ceux qui veulent une solution pratique tout de suite. C'est plutôt un livre pour ceux qui veulent approfondir les choses, un livre pour les language lawyers qui adorent discuter pendant des heures un détail de la norme, mais qui manquent de tripes pour lire la norme elle-même.
On y trouvera tous les concepts du SQL standard (et c'est toujours un sujet d'émerveillement de voir que les choses les plus utiles de SQL comme les stored procedures sont absolument non standards), chacun détaillé en profondeur avec beaucoup d'exemples.
La discussion sur NULL, qui a introduit la logique tri-valuée dans SQL (vrai, faux, bof), est très représentative : c'est fou ce qu'une décision aussi simple peut entrainer comme conséquences. Un quizz pour les pros de SQL : s'il y a des NULL dans les tuples récupérés, est-ce que COUNT(*) et AVG(*) ignorent les NULL ou pas ? (La discussion figure dans le livre.)
Le livre n'est pas tout récent, et j'ignore ce qui s'est fait en matière de normalisation SQL depuis quelques années, donc il y a peut-être des changements. Les exemples de SQL embarqué sont écrit en PL/1 :-)
Auteur(s) du livre : Danny Goodman
Éditeur : O'Reilly
Première rédaction de cet article le 14 octobre 2002
Le titre est trompeur : le livre parle peu de cette soupe marketing jamais définie clairement qu'est le "HTML dynamique". C'est en fait un livre de référence sur les techniques Web, HTML, bien sûr, mais aussi CSS, DOM et Javascript.
Par exemple, pour HTML, le livre décrit chaque élément, ses attributs (standards ou pas), sa place dans DOM, sa présence ou pas dans tel ou tel navigateur, etc. Le truc à lire quant on sèche devant son code HTML, à se demander quel élément utiliser. (Les fanas de lecture sur l'écran utiliseront l'excellent HTML Help.)
Cette exhaustivité est particulièrement utile pour CSS, où le support selon les navigateurs est... très... variable.
La taille du livre, 1398 pages, donne une idée du désordre qu'est le Web. Vivement XML :-)
Auteur(s) du livre : Norman Walsh
Éditeur : O'Reilly
Première rédaction de cet article le 14 octobre 2002
Ce livre (également disponible en ligne pour ceux qui veulent laisser leurs arbres aux petits écureuils pour l'hiver) est écrit par un übergourou SGML et XML, Norman Walsh, l'auteur des "DocBook stylesheets", inlassablement actif sur les listes de diffusion des logiciels libres.
Vous voulez écrire des documents structurés et pas des jolies notes de service ? Vous voulez faire des documentations traitables par programme, publiables sur le Web comme en papier, cherchables et éditables avec du logiciel libre ? Vous voulez rentrer dans l'avenir comme quasiment tous les projets de logiciel libre, qui utilisent DocBook pour leur documentation ? Alors, vous pouvez commencer par ce livre.
SGML a toujours fait peur, et pas à tort. XML bénéficie d'un baratin marketing d'enfer... mais qui ne se traduit pas toujours en pratique. Alors, si vous avez déjà essayé de lire la norme DocBook sans y parvenir, ce livre va vous aider, vous guider et vous fournir la référence sympa, avec exemples, pour naviguer dans les 3 ou 400 éléments que définit DocBook.
Le chapitre sur les adaptations de DocBook (une des forces de cette norme) est particulièrement clair et complet.
Après ce livre, vous ne ferez plus de docs en nroff.
Auteur(s) du livre : Marshall Rose
Éditeur : O'Reilly
Première rédaction de cet article le 8 août 2002
Vous avez toujours révé de concevoir un protocole ? De faire le nouveau SMTP ou le nouveau IPP ? Mais vous reculez devant la quantité de détails qu'il va falloir traiter, la sécurité, l'encodage, le multiplexage, tout cela en plus du problème que votre protocole doit résoudre ? Alors, BEEP ("Blocks Extensible Exchange Protocol", RFC 3080) est fait pour vous.
BEEP est un outil pour les concepteurs de protocole. Il fournit un cadre (framework) de description des protocoles (l'utilisation de ce cadre permet plus facilement aux relecteurs de comprendre les spécificités de ce protocole, sans se perdre dans des détails) et un ensemble de services tout faits, que vous pouvez utiliser tel quel. Par exemple, vous voulez de la confidentialité ? Vous spécifiez juste que votre protocole peut utiliser le profil TLS de BEEP et, sans autre effort de spécification (ou de codage), vous avez un mécanisme de confidentialité éprouvé et reconnu, qui fera que vous ne perdrez pas de temps à l'IETF à expliquer votre solution de sécurité.
Bref, BEEP est le retour de la couche session du modèle ISO :-)
Le livre, par l'auteur bien connu de BEEP (qui se vante du nombre de RFC qu'il a écrit, ce que je trouve assez vulgaire, style "la mienne est plus grosse que la tienne"), décrit les concepts de BEEP (sessions, canaux, messages) le mécanisme de tuning (qui permet d'"améliorer" un canal, par exemple en y démarrant TLS), la modélisation des échanges (requête-réponse, comme les RPC ou bien autre), et présente l'utilisation de BEEP pour faire un syslog fiable (RFC 3195). Des mises en oeuvre en Java, C et TCL permettent au techos de base de se faire une meilleure idée.
Auteur(s) du livre : Steve Krug
Éditeur : New riders
Première rédaction de cet article le 1 août 2002
Si vous croyez que faire un site Web, c'est taper du HTML (ou du Javascript, ou du PHP), voici un livre pour parler de ceux dont on ne parle jamais : les utilisateurs. Tout ce que le webmestre doit savoir sur les utilisateurs de son site. Comment tester leurs réactions, comment faire en sorte que cela marche pour ceux qui "ne veulent pas penser".
Pour les culturés, le livre de Jakob Nielsen Designing Web usability, couvre le même genre de problèmes. Krug est plus léger, moins universitaire et son livre fait honneur à son titre.
Auteur(s) du livre : DJ Adams
Éditeur : O'Reilly
Première rédaction de cet article le 1 août 2002
Vous en étiez resté au routage des paquets IP ? Vous envoyez toujours des bits et pas des messages structurés ? Il est temps de passer à Jabber, qui route des éléments XML et plus de simples 0 ou 1.
Connu surtout à l'origine comme plate-forme pour développer des applications de messagerie instantanée (genre ICQ), Jabber a évolué pour devenir un protocole de transport et de routage d'informations structurées, en XML en l'occurrence. Jabber peut servir de transport à des protocoles applicatifs ou à des protocoles plutôt session comme SOAP (un exemple XML-RPC figure dans le livre).
Le livre décrit le protocole, le serveur, la façon dont se prennent les décisions de routage. Beaucoup d'exemple de clients Jabber dans tous les langages, ainsi que des composants de serveur Jabber (des plug-ins du serveur assurant telle ou telle fonction) sont décrits en grand détail.
La lecture de l'été si vous maitrisez HTTP et que ce protocole commence à vous sembler ennuyeux.
Auteur(s) du livre : Milton L. Mueller
Éditeur : MIT press
Première rédaction de cet article le 22 juillet 2002
Ce livre est, à ma connaissance, le premier vrai bouquin entièrement écrit sur des arbres morts qui soit consacré uniquement au DNS, pas à sa partie technique (couverte par le O'Reilly) mais à sa partie politique et aux luttes autour de la gestion de la racine (il englobe sous ce terme la gestion du DNS et celles des adresses IP, malheureusement comme toujours le parent pauvre de ces discussions).
Il est écrit d'un point de vue des sciences humaines (droit, économie, science politique, que Mueller convoque pour analyser la formation de la fameuse gouvernance Internet) mais la partie technique a été bien relue et, quoique il y a des erreurs amusantes, elles ne sont pas graves.
Un chapitre 2 très bien fait remet le problème dans le cadre plus général de la gestion des identificateurs (dont le DNS n'est qu'un cas particulier) et analyse pourquoi les adresses Ethernet n'ont jamais déclenché de telles bagarres.
Ensuite, la partie historique est très détaillée, puisque Mueller reprend le problème à sa base, quant Postel avait un coin de bureau et pas de secrétaire pour gérer la racine. On y retrouve les grands moments de l'Internet, du IAHC au gTLD-MOU en passant par le "détournement" de la racine qu'avait tenté Postel.
Mueller n'a pas le défaut courant chez beaucoup de juristes et de politiques qui consiste à prendre pour argent comptant les déclarations publiques et les statuts formels. Analysant ceux de l'ICANN il note que les principales caractéristiques de l'ICANN (notamment le poids du gouvernement US) sont justement non-écrites.
Ensuite, le chapitre 11 passe à la politique. Ici, Mueller ne prend plus de gants. Il réagit en tant que défenseur de la liberté contre les prétentions exorbitantes des propriétaires de marques déposées qui tentent de profiter de l'institutionnalisation de la racine pour s'approprier des pouvoirs supplémentaires, en extension considérable du rôle original des marques. (Les lecteurs de Lawrence Lessig, souvent cité, retrouveront beaucoup de thèmes communs entre ces deux universitaires.)
La conclusion est un mélange de pessimisme et d'optimisme. Je cite le dernier paragraphe, qui conclut un chapitre expliquant qu'il semble difficile de revenir sur la prise du pouvoir par la Fédération du Commerce : But no doubt there are other technologies and systems hatching somewhere, ready to take the world by surprise.
Première rédaction de cet article le 13 mai 2002
Le 13 mai 2002, à la réunion AFNOG (African Network Operators Group) à Lomé, j'ai fait un exposé (en anglais) sur les points d'échange Internet.
Le but de l'exposé était d'expliquer techniquement comment monter un point d'échange et les obstacles à surmonter. La partie technique du IX est très simple, les grosses difficultés surviennent plutôt au niveau « commercial » ou bien politique. En Afrique, la situation n'est pas tout à fait la même : obtenir les lignes spécialisées entre les POP des opérateurs et le IX est en soi un gros problème.
Environ douze personnes ont suivi cet exposé. Voici les transparents en version Postscript et le source (en MagicPoint).
À noter que le compte-rendu que j'avais fait de la réunion pour mon commanditaire est en ligne.
First publication of this article on 28 March 2002
Last update on of 30 August 2006
UUCP is a very good way to distribute email to a domain (not just a specific individual but an entire domain, with several persons, mailing lists, aliases, etc) when the machine which serves the domain is not always connected or does not have a permanent address (dial-up with POTS or ISDN but also cable modems with dynamic IPs or frequent cut-offs). It was intended that way (unlike many hacks over SMTP) and it works.
UUCP can work over TCP, so you do not need to have the agreement of
your access
provider (which is great because, unfortunately, very few handle UUCP). Any server on the
Internet will work fine for you (if you have trouble finding one, try http://www.uucpssh.org/
).
But, by default, when you connect over TCP, the password is sent in cleartext, with the security problems it triggers.
Therefore, this page is dedicated to the setup of UUCP over SSH. It allows the use of UUCP over an encrypted tunnel. As with any security measure, it does not protect you against everything. It just solves the issue of UUCP passwords travelling in clear. Period.
Warning: the actual file names are taken from a Debian machine. On other Unices, the files may be at different places.
First, let us configure the server.
Create an anonymous account for UUCP like that:
anonuucp:*:400:400:Anonymous UUCP:/home/anonuucp:/bin/ash
Be sure the shell exists: most SSH versions will check that. Also,
this user needs the right to run uucico
(for instance,
being member of the uucp
group).
Make a RSA key without a password:
ssh-keygen -C "anonuucp@YOURNAME" -f ~anonuucp/key
Hit two returns when it asks the passphrase, so you'll get an empty one.
Authorize bearers of this key to connect (but only to run UUCP), by adding in
~anonuucp/.ssh/authorized_keys
the public key (~anonuucp/key.pub
):
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/sbin/uucico -l" 1024 35 121718545783400431245097717073812650999828959524504747280733926667144812752987559784683441942777577667330183024858262562630220387319750811710254096614413985817319996843445535636538787910938954240295512196814272044747628764010397862173191052356031770343581123286414989641645943931907667678114220177403305005773 anonuucp@YOURNAME
You do not need to have an entry for UUCP in /etc/inetd.conf
.
Now, let us configure the client.
Copy the private key on your machine, say in
/etc/uucp/anonuucp-YOURPROVIDER
. chmod 600
it, SSH will check that. But be sure the UUCP user will be able to
read it (for instance chown uucp
it).
Add this in the UUCP sys
file:
system YOURPROVIDER call-login * call-password * time any chat "" \d\d\r\c ogin: \d\L word: \P chat-timeout 30 protocol i port UUCPoverSSH
And in the UUCP port
file:
port UUCPoverSSH type pipe command /usr/bin/ssh -a -x -q -i /etc/uucp/anonuucp-YOURPROVIDER -l anonuucp uucp.YOURPROVIDER.org reliable true protocol etyig
You should put the server's fingerprint in known_hosts (may be with a command performed by hand first). By default, SSH queries you and UUCP does not run interactively.
That's all: UUCP will be used as usual.
But not everything works the first time. What to do if we need debugging?
Always check the logfiles (for instance /var/log/uucp/Log
). You can have more debugging information
from software with '-x 9'. It will be written in UUCP
Debug
logfile.
If the problem is an SSH one, running the ssh command in the
port
file, replacing -q (quiet) by -v (verbose) will help
you a lot.
To learn more, you can see:
Articles des différentes années : 2024 2023 2022 2021 2020 2019 2018 Précédentes années
Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.