Linuxman - septembre 1999


INDEX

Mois précédent

Mois suivant


2 9 1999
4 9 1999
7 9 1999
19 9 1999
26 9 1999

 2 9 1999

Mots Clés : xterm en couleur.

Un truc qu'est sympa c'est les xterm, c'est sûr, mais un truc encore plus cool est de pouvoir avoir des couleurs sympas pour les caractères. Bon je ne parle pas des Eterms et autres, c'est aussi un style de vie, mais chacun son style. En ce milieu de semaine j'ai donc finalement réussi à me faire une petite commande sympa qui me change la couleur des caractères de manière aléatoire chaque fois que je crée un nouvel xterm (en bash):

xterm  -vb -bg black -fg `printf #%6x $(($RANDOM*$RANDOM/64)) | tr \  0` &
Le tr sert à compléter avec des 0 quand c'est un petit chiffre qui sort. On pourra objecter à juste titre (héhé, méga expression, la classe :-) qu'il peut arriver assez souvent que l'on se retrouve avec des couleurs trop foncées et qu'on voit que dalle. C'est vrai, j'en suis conscient, mais la résolution est plus complexe que simplement ajouter une valeur fixe pour ne pas aller trop vers les couleurs foncées parce que cela nous prive des couleurs du type #0000EE qui sont quand même visibles. L'idéal serait de forcer la somme des trois valeurs pour le rouge, le vert et le bleu à dépasser un certain seuil mais je pense que c'est un peu trop lourd. Et puis bon, suffit d'en relancer un autre et puis basta...

haut de page

 4 9 1999

Mots Clés : last, last.

Alors c'est la rentrée ? Et oui le temps passe, boah, tant mieux remarquez... Tiens au fait l'autre jour à propos de sox et lame et les relais nommés j'avais dit une bétise il n'y en a pas besoin ça marche sans :

sox -t ossdsp -r 44100 -c 2 -w /dev/dsp -t wav - | lame - file.mp3

Pas grand chose à dire sinon... Hum... La commande last liste les dernieres personnes qui se sont connectées sur une machine. La commande at permet de programmer une tâche à une heure précise ou dans un certain temps, ça marche avec un fichier ou sur l'entrée standard, si je tape :

at now + 2days

Je passe en mode d'entrée :

at>/bin/echo coucou | /bin/mail warly -s test

Puis Ctrl+D pour valider la ligne...  

haut de page

 7 9 1999

Mots Clés : interface.

Dans la vie, si on veut que les choses marchent bien, ce qu'il faut c'est causer un langage à peu près potable, si possible causé par d'autres personnes, avec des concepts pas trop ésotériques. L'idée c'est que quel que soit votre fonctionnement interne, du moment que de l'extérieur vous paraissez normal personne viendra vous chercher des noises.  

Ceci soulève le problème des interfaces, qui sont présentes de partout et notamment en informatique. Elles sont présentes à tous les niveaux, interface graphique entre vous et le logiciel, interface réseau entre votre machine et le monde. Elles sont de toutes natures, physique, théorique, conceptuelle, logicielle... Mais leur but est toujours le même : faire communiquer deux mondes entre eux.

Les interfaces, leur définition et leur création demande toujours beaucoup plus de travail que de ne pas les utiliser et créer directement un matériel ou tout parle le même langage, ou tout le monde comprend tout le monde directement. Mais le problème c'est que le jour ou vous brancherez votre cerveau sur votre tout nouveau AMD Atchoum et que vous comprendrez facile les 0 et les 1 à la pelle, n'est pas encore là (le jour, pour ceux qui ne suivent pas) et que donc chacun cause avec son langage à lui et que pour que tout le monde cause avec tout le monde et bien il faut coder des trucs, et faire des cartes et définir des protocoles et tout et tout.

Cette brève introduction qui pourrait bien être aussi longue que le reste de l'article (suivant ma motivation, que je qualifierais de moyenne en ces premières minutes du 8 Septembre 1999) décrit sommairement l'intérêt et la nécessité des interfaces. Mais en fait mon but n'est pas de discourir de concepts profondemment puissants sur ce genre de chose, mais plutôt de me baser sur une chose qui nous tient tous à coeur, enfin un peu, c'est le noyau de Linux et son architecture.

Comme vous pouvez le constater en jetant un rapide coup d'oeil aux sources, la partie dépendante de l'architecture reste tout de même relativement restreinte et n'influe pas sur une grande partie du code qui relève plus de concepts théoriques de gestion de mémoire ou de répartition de processus que de problèmes spécifiquement liés au matériel. Cela, comme vous vous en doutez sûrement, parce que les sources du noyau font un usage intensif voire extensif (je ne sais pas trop si cela a un sens mais en tout cas ça fait le mec qui maîtrise) des interfaces.

L'idée est d'avoir une grande partie du code qui s'occupe de problèmes d'architecture, de modularité, de performances, d'algorithmes, de concepts mais qui ne soit pas dépendante de tel ou tel protocole réseau qui sémantiquement sont tous les mêmes, ils servent à transmettre de l'information, ou de tel autre disque dur, ou carte video ou je ne sais quoi d'autre. De cette manière on peu clairement identifier une partie que j'appellerai clean du noyau d'une autre partie plus bidouille qui traite des problèmes spécifiques à un matériel particulier.

Je prendrai comme exemple les systèmes de fichiers et les protocoles réseaux ; conceptuellement on y retrouve les mêmes fonctions, qui sont entre autres écrire, lire, etc... Et il est assez séduisant de concevoir un système où la majorité du code n'a pas à se soucier s'il écrit dans une socket, sur une partition ext2, NTFS (ça marche pas top encore, faites gaffe), FAT ou je ne sais quoi d'autre. La solution est de mettre en place des structures qui rassemblent les fonctions pour un type d'action donnée, par exemple lire et ecrire, et qui derrière appellent les fonctions adéquates suivant le contexte. Pour faire cela en C rien de plus simple, il suffit de déclarer une structure du type :


struct operation {
      int (*lire)(char *);
      int (*ecrire)(char *, char *)
}

Ensuite de déclarer dans le code un tableau de telle structure avec un taille légèrement surdimensionnée si vous pouvez associer à chaque type de système de fichiers un numéro fixe ou bien d'utiliser des listes chainée (mais c'est plus efficace d'utiliser un tableau, même si c'est conceptuellement moins joli). Et enfin au démarage de la machine ou au chargement du module, de créer une fonction d'initialisation qui enregistre les nouvelles fonctions pour le système consiéré :


struct operation OP[NB_DE_TRUC_DIFFERENT];
...
OP[i]= {
      lire: lire_sur_le_truc_mega_complique;
      ecrire: ecrire_sur_le_truc_vraiment_mega_complique;
}

En définissant les deux fonctions lire_sur_le_truc_mega_complique et ecrire_sur_le_truc_vraiment_mega_complique pour lire et écrire sur le nouveau système de fichier profondemment révolutionnaire que vous êtes en train de mettre au point. Et de cette manière tout votre ancien code qui utilisait les fonctions OP[i]->lire(fichier) et OP[i]->ecrire(fichier,bla bla bla) marchera encore. Reste quand même le problème de la détermination du i, et bien ya pas de mystères il faut quand même un minimum de connaissance des systèmes de fichiers pour savoir que celui-là est du type i et celui-ci i+1.

En conclusion l'usage des interfaces permet de conserver une grande partie du code logique et indépendante et de laisser aux pilotes et autres protocoles divers de mettre en place une politique d'enregistrement auprès du noyau pour utiliser une interface commune et ne pas gêner le monde extérieur avec des caractéristiques spécifiques dont, il faut bien l'avouer, tout le monde se moque...

haut de page

 19 9 1999

Mots Clés : firewall (noyau > 2.3.15), firewall (noyau > 2.3.15).

La rentrée est toujours un peu un choc après le calme général de l'été, on se rappelle ce que travailler veut dire, et les joies de l'overbooking (je ne sais pas comment on dit en français). Tout cela diminue considérablement mon temps libre mais bon, un peu de stress de temps en temps ne peut que faire du bien...

Je n'ai malheureusement pas grand chose à raconter, si ce n'est que les HOWTOs sont généralement bien fait et que l'on y trouve beaucoup d'informations. Aussi que j'ai appris avec enchantement qu'à partir du noyau 2.3.15 le firewalling et le masquerading (appelé NAT desormais : Network Address Translation) a encore changé, fini ipchains, vive ipnatctl et iptables ! Attention pour le noyau 2.3.18 il vous faudra la version 0.1.8 de netfilter qui contient ces deux programmes.

Autre nouvelle, ext3 est sortie en 0.0.1, autant dire que je n'en ferai pas encore mon / mais bon. La principale évolution par rapport à ext2 est je crois la journalisation, qui est une sécurité supplémentaire car mémorisant les dernieres opérations effectuées dans le système de fichier. Je ne sais pas si cela est basé sur XFS, le système de fichier journalisé de SGI récemment donné à la communauté ou bien si c'est written from scratch.

Beowulf était un héros mythique qui est allé se battre contre le méchant Grendel, c'est tout ce que je sais. Toujours est il qu'aujourd'hui Beowulf est associé à des clusters de machines Linux. Pour ceux qui s'interrogent sur Beowulf, outre http://www.beowulf.org, je peux vous en dire deux mots. Un cluster Beowulf n'est rien d'autre qu'un ensemble de machines en réseau local (du type 192.168.0.0 ou 10.0.0.0) et piloté par une ou plusieurs machines serveurs faisant office d'interfaces avec le monde. Beowulf n'est pas une surcouche de l'OS qui réparti les charges (load balancing) ou optimise quoi que ce soit ; c'est à vous de faire cela, il ne faut pas réver. Cela passe par l'utilisation de programme de programmantion parallèle come PVM ou, plus récent, MPI et pour les téméraires des programmes de création de mémoire partag! é (NUMA : Non Uniform Memor y Access, dans un cluster de machines, en considérant l'ensemble de la mémoire de toutes les machines, il est évident que pour un des noeuds (c'est comme cela que l'on appelle souvent une machine dans un cluster) sa mémoire locale a un temps d'accés différent de la mémoire d'un des autres noeuds du cluster), avec si possible de quoi maintenir la cohérence des caches.

Faire un cluster linux n'est pas très cher puisque les noeuds peuvent se passer de disques durs (on boote via le réseau) de cartes videos, d'écrans, et tout quoi. Disons qu'un boitier (et encore), une carte mère, un processeur, de la mémoire et une carte réseau et le tour est joué (allez, petit calcul, 1000 celerons 400 avec 128 Mo de ram plus 10 noeuds serveurs bi-celeron 400 avec 512 Meg de ram et 36 Go de disques (ya pas besoin de place), le tout relié par du fast ethernet 100, y'en a pour quoi, allez, 3000 balles par noeuds, plus 20000 balles par serveur, 100000 balles de switches, et voilà, pour 3 300 000 balles vous avez une machines 1000 proc, 128 Go de ram dans votre garage, c'est pas cool ca ? Bon peut etre ça serait bien de mettre du gigabit ethernet, et vous êtes parés pour craquer le mot de passe root de votre ecole :-)

haut de page

 26 9 1999

Mots Clés : cluster, beowulf, mosix, cluster.

C'est l'automne, et oui déjà, bientôt le froid de nouveau nous enveloppera et la soif et la faim et... Bon ok j'exagère mais l'hiver sera rude... Et il est loin le printemps 2000... Enfin bon d'ici là il y a de quoi faire... Je vous avez causé de Beowulf la semaine dernière, après quelques investigations supplémentaires j'ai déniché quelques informations. Tout d'abord je vous avez prévenu que Beowulf n'était pas une surcouche de l'OS se chargeant de parallèliser vos processus ou d'équilibrer la charge, ceci est vrai mais néanmoins il existe déjà des softs qui font cela.  La meilleure des preuves est qu'en ce moment même je tapote sur le clavier de mon portable sur l'Xemacs qui tourne sur mon desktop via un remote display mais il se peut très bien que ce même Xemacs ait été migré par MOSIX sur le portable. Autrement dit m on portable (PII 366) et mon desktop (K6 233) sont en cluster et les deux utilisent un noyau modifié MOSIX qui fait de l'équilibrage de charge dynamique entre les deux.

MOSIX est composé d'un patch que l'on applique au noyau (le 2.2.12 pour le moment) et de quelques binaires qui permettent d'une part de définir un ensemble de machine participant au cluster et d'autre part de migrer les processus des machine chargées vers les machines plus peinardes. MOSIX n'est pas très difficile à mettre en oeuvre, compter une bonne journée pour lire les docs, l'installer sur vos différentes machines et relancer le tout. Bien évidemment dans le cas où votre cluster est composé d'un grand nombre de machine fortement hétérogènes (ce qui implique que les noyaux sont spécifiques à chaque machine et ne peuvent pas être réutilisé par d'autres machines) il faudra un peu plus de temps.  

MOSIX ajoute des entrées dans /proc pour suivre et configurer le cluster. Chaque machine est équivalente et tourne sous un noyau MOSIX qui accepte des processus des autres machines ou fait migrer ses propres processus quand la machine est chargée et que d'autres sont libres (idle).  

La configuration est suffisemment aisée, un script d'install fait a peu près tout sauf la topologie de votre cluster qu'il vous faut rentrer dans un fichier /etc/mosix.map. Attention à ce niveau là j'ai un peu galéré parce que normalement à l'aide du /etc/hosts MOSIX doit retrouver le noeud local dans le fichier /etc/mosix.map, or ce n'était pas mon cas et le programme setpe qui met en place les noeuds me lançait un setpe: the table looks ok, but I'm not there! ou un truc dans le genre, qui, une fois que l'on connait la raison, est assez clair, mais avant je l'ai quand même légèrememnt injurié :-). Toujours est -il que d'ajouter un fichier /etc/mospe avec à l'intérieur le numéro du noeud local que l'on peu retrouver dans la liste /etc/mosix.map aide pas mal. Je prends un exemple, disons que /etc/mo! six.map ressemble à :

1 192.168.1.1 1
2 192.168.1.4 1


man mosix donnera toutes les infos quant à la syntaxe de ce fichier, en gros je dis que j'ai un noeud numéro 1 à l'adresse 192.168.1.1 et qu'il n'y en a qu'un à partir de cette adresse et que j'ai un noeud 2 à 192.168.1.4 et qu'il n'y en a q'un à partir de cette adresse. Pour être un tout petit peu plus clair, je vous fais un autre exemple et cela sera évident, si par exemple j'ai 4 machines 192.168.1.10, 192.168.1.11, 192.168.1.12 et 192.168.1.35 et bien /etc/mosix.map sera :

1 192.168.1.10 3
4 192.168.1.35 1


Cela signifie que j'ai trois machines à partir de 192.168.1.10, donc 192.168.1.10, 192.168.1.11 et 192.168.1.12 et une 192.168.1.35. Pour l'ensemble des possibilités, notamment ce qui concerne la présence de routeur ou autres passerelles au milieu de vos machines, man mosix saura illuminer vos lanternes. Toujours est-il que si setpe ne trouve pas tout seul où il est il faut rajouter un fichier /etc/mospe avec par exemple 2 dedans pour dire que le noeud local est la machine numéro 2 du fichier /etc/mosix.map.

MOSIX a l'avantage et l'inconvénient de faire de l'équilibrage de charge de manière transparente entre vos machines. Avantage parce que vous pouvez faire autant de mp3 que vous voulez sur une machine, la charge sera répartie sans que vous n'ayez rien à faire sur l'ensemble des machines disponibles. Inconvénient parce qu'à priori si MOSIX transfère le processus sur une autre machine, celui-ci dépend encore de la machine locale, notamment tout ce qui concerne les appels systèmes, les éventuels fichier utilisés, les périphériques mis en oeuvre, autant donc dire que les processus gourmand en accès disques qui sont migrés créront une importante charge du réseau. Cependant quelques tests me laissent suspecter que MOSIX ne migrent pas tous les processus avec la même priorité et laisse les processus qui ont plus d'entrées/sorties que de ca! lcul même en local, mais cel a n'est (pour l'instant) qu'une supposition de ma part, à vérifier donc. MOSIX fournit de plus la possibilité de migrer manuellement certain processus (via la commande migrate PID MOSIX_ID).

Toujours est il qu'il assez marrant de voir la charge de ces deux machines (ou plus si disponibles) sur le petit moniteur fourni et de temps en temps un équilibrage intervenir pour arranger un peu l'affaire. Mais il faut prendre conscience qu'une migration de processus est couteuse et que par conséquent seuls les processus longs et beaucoup plus gourmands en calcul qu'en entrées/sorties seront bénéfiquement migrés.

Il existe plusieurs logiciels du type de MOSIX me semble t'il, avec plus ou moins la même sémantique. bproc ressemble en apparence à MOSIX mais n'a pas réellement la même approche. bproc permet aussi de migrer des processus vers une aute machine tout en les concervant dans la tables des processus locaux (autrement dit ils apparaissent toujours dans un top local, tout comme avec MOSIX) mais ceux ci n'ont plus accès aux entrées/sorties locales si ce n'est STDIN et STDOUT qui sont conservées via un socket réseau. Autrement dit, contrairement à MOSIX il n'y aura pas de surcharge du réseau du fait que les processus distant accèderont aux ressources de la machine sur laquelle ils s'exécutent tout en restant propriétaire de leur machine de départ. Et de plus bproc ne fait pas cela de manière transparente, il vous faut explicitement migrer! un processus.

Il faut cependant bien garder à l'esprit que l'équilibrage se fait ici par processus. Si le cluster est destiné à faire tourner un seul programme très gourmand en calcul, MOSIX ou bproc n'aideront pas, il faudra dans ce cas utiliser des bibliothèques du type MPI ou PVM pour paralléliser le code et le faire tourner sur toutes les machines simultanément.

haut de page

Mots Clés : pub VolksWagen.

He he je viens d'entendre la pub de VolksWagen à la radio, celle où y'a du pipo (pipau ? pipeau ? pipot peut-être ? bon vous aurez compris), je trouve cela pas mal. En tous cas cela me fait rire, he he :-). Il est vrai que 95% si ce n'est plus des pubs à la radio sont assez nulles. Cependant on en trouve des pas mal, tiens par exemple l'autre jour j'ai entendu une des pubs pour la carte omnicon où la nana se plaint que son mec raccroche trop tot, juste après les préliminaire, genre allo, allo, ça va et puis il coupe ; et l'autre toubib lui explique qu'il doit être victime d'ellocution précoce et que cela arrive souvent quand on a des possibilités mais pas les moyens et qu'elle pourrait lui acheter une carte omnicom pour arranger ca, en vente partout, comme les préservatifs :-)...

Mais sinon c'est dingue à quel point les mecs qui font des pubs à la radio sont incompétents, je sais pas moi mais comment peuvent ils espérer que l'on ne change pas de station direct quand on entends une pub pour peugeot (les plus minables) ou intermarché (si je trouve Klein je me le fais :-), comment humainement peut-on faire des pubs aussi pourries ? Cela reste un mystère pour moi, un jour faudra que je me trouve un nana d'écoles de commerce et qu'elle m'explique un peu la pub parce que là j'ai du louper une étape fondamentale de formation cérébrale qui me rend complètement antireceptif de ces pubs...).  

Il est vrai que je ne porte pas un amour frénétique aux commerciaux, bien que je comprenne que les gens étant facilement et complètement manipulables il est légitime de vouloir leur faire acheter son produit plutôt que celui d'un autre, tant qu'à faire. Sur ce point j'aimerai quand même que quelque part dans l'éducation ou je ne sais pas trop où on donne un minimum d'esprit critique aux personnes et qu'on leur fasse comprendre que porter des pompes Nike ne vous rends pas plus sportif ni plus intelligent, pas plus que de regarder le journal à la télé complètement affalé dans un canapé ne vous rend instruit. Tant qu'à faire il serait bien de leur faire comprendre que si un homme politique n'a rien fait dans les 40 dernières années, cela n'est pas un signe qu'il va sûrement faire quelque chose dans les 20 prochaines, et aussi que si les foncti! onnaires sont peinards et ne trava illent que 20 heures par semaines, et bien qu'ils n'ont qu'à faire fonctionnaires au lieu de nous les briser avec cela, et aussi quelque part si le fonctionnariat existe c'est uniquement parce que les personnes qu'ils ont élu ont mis cela en place et qu'ils n'ont qu'à s'en prendre à eux même et un peu se bouger au lieu de râler et rentrer chez eux dès qu'il pleut. Il parait que la différence entre l'homme et la femme c'est que l'homme en a mais j'ai quand même de sérieux doutes parfois.

La morale de tout cela, si tant est qu'il y en ait une, serait:  « N'attend pas des autres ce que tu ne fais pas toi même, et arrète de mater ces trucs débiles à la télé et code un peu à la place, bon sang ! ».

haut de page

Mois suivant

Valid HTML 4.0!

Warly Home Page   Generated 2000-07-02, 11h31   Mail
Copyright © 1999,2000 Florent Villard (warly@bigfoot.com)
This site was created with daily (tar.gz, rpm)