C'est la solution qui va bien.
tu peux autoriser la publication de certains enregistrements uniquement si la demande provient d'une certaine classe d'addresses IPs, par exemple ton reseau local.
Il est plus rapide que Bind.
Il est plus secure que Bind.
Il est plus sexy que Bind.
Bon en gros il est bien, tu fais un forward de port de ta gate vers ton DNS et c'est bon. Faudra tout de meme lire la doc (http://cr.yp.to(...)) ou recuperer le script qui genere les pages de manuel a partir du site web (sous certaines distribs c'est integre).
Tu vois ce qu'est un système de fichiers virtuel ?
Quand tu fais un opendir "/chemin/vers/un/dossier" tu reçois une liste des fichiers se trouvant dans ce dossier, et le opendir est spécifique au système de fichiers utilisé.
Pour /proc par exemple, tu as monté le device none (ou proc, ou truc) en procfs sur /proc. Enfin normalement, c'est écrit dans ton fstab.
Donc tous les open, read, write, opendir (getdents) ... de "/proc/tout/ce/qu'on/veut" seront ceux de procfs.
Et procfs génère ses informations à la volée (à partir de la liste de processus du kernel entre autres). Il ne va jamais lire sur le disque, c'est ce qu'on appelle un système de fichiers virtuel, d'ailleurs il n'a pas besoin de device (tu peux mettre ce que tu veux).
Oui procfs est indispensable pour monter /proc, tu peux même monter en procfs sur /ailleurs/procs et en même temps.
Devfs est un système de fichiers virtuel aussi.
Quand tu écris un module (disons le module device_mod) tu l'enregistres pour un major et certains minor.
C'est à dire qu'un open (read, write ...) sur un fichier de type device qui porte ce major et un de ces minors appellera le open (read, write ...) de ton module.
Et tu peux aussi l'enregistrer pour un nom de fichier (e.g. misc/device).
Maintenant si tu as monté en devfs sur le dossier /truc, essayer d'accéder (open) à /truc/misc/device chargera le module device_mod.
Et le module device_mod créera le fichier /truc/misc/device avec les bons major et minor.
En plus devfs a une toute autre manière (que personnellement je préfère) de nommer les devices.
Dernière chose sur devfs il est souvent accompagné de devfsd (même si ce n'est pas obligatoire) car devfs, donc le kernel, ne se rappelle pas d'un boot sur l'autre les permissions spéciales que tu avais pu accorder sur tel ou tel device.
Le démon devfsd permet d'attribuer des permissions dès la création des devices, de gérer des liens symboliques pour par exemple rester compatible avec l'ancien système de nommage ...
udev est différent.
il n'est pas situé dans le kernel. Mais le kernel le lance au moment de la détection (ou du chargement d'un module?) d'un matériel. Plus précisément il lance /sbin/hotplug qui lui lancera udev.
Suivant ses arguments et un fichier de conf udev va créer les devices à la demande avec les bons droits.
C'est plus modulaire car il permet d'utiliser les noms qu'on veut (et moi décidemment j'aime bien les noms devfs). Ca fait moins de code éxécuté en kernel, et il parait que le code de devfs était pas super en plus.
Si si ...
cp -a les copie tres bien. Garanti. Avec les fifos les dates et tout et tout.
Normalement meme les sparse (blocs plein de zeros qui ne prennent pas de place sur le disque) mais ca j'ai pas verifie. Et puis --sparse=always le fait.
Sinon sur le sujet:
Si tu copies un /dev/ en etat de marche ca passera.
Mais est-ce que udev effacera plus tard les devices qu'il n'utilise pas ?
Vu qu'il ne les aura pas cree, vu qu'ils l'ont deja ete par ta copie et pas par lui ?
Je ne connais pas encore assez udev pour te repondre. Si tu veux tu peux rebooter avec init=/bin/sh et copier uniquement les devices presents a ce moment. Tu n'auras que ceux necessaires (/dev/console en fait partie).
Le bios assigne 0x80 (premier disque dur) au ... premier disque dur !
Et 0x81 au second.
Et ainsi de suite.
Le premier secteur d'une partion bootable windows va chercher NTLDR sur le disque 0x80, pas de moyen (simple) de faire *booter* Windows sur le disque secondaire, il n'est pas prevu pour.
Les commandes ci-dessus vont "changer" le disque represente par 0x81 et 0x80.
Je crois par contre que seuls le secteur de boot et NTLDR accedent au disques dur via le BIOS (et les interruptions qui prennent 0x8[0-f] en parametre).
Le but de NTLDR etant de charger les drivers absolument necessaires au fonctionnement de Windows, il charge les drivers ATA. Et Windows lui n'accede jamais aux disques via le BIOS. Enfin je peux me tromper.
> Je cherche à utiliser les raccourcis claviers *standards* (shift + directions pour sélectionner...) dans une application (jed) lancée dans un xterm.
> Malheureusement, ce dernier "bloque" ces touches pour son propre usage.
Comment sais-tu qu'il bloque ces touches ? Il affiche une fenêtre ? Que ce passe-t-il quand tu appuies sur ces touches ? Il y a tellement de choses qui peuvent influer la-dessus que j'aimerais bien un peu plus de précisions pour t'aider.
Il se peut aussi que ce soit ton environnement de bureau et/ou ton window manager qui intercepte ces appuis sur touche avant XTerm.
Voir XFree avant tout le monde (peu probable).
Pour être sur que XTerm bloque bien shift + Flèche-droite, dans un XTerm lance cat, puis vérifie ce qui est affiché quand tu appuies sur Flèche-droite et sur shift + Flèche-droite.
Si ca ressemble a '^[[1;2c' (d'ailleurs si quelque-chose s'affiche) c'est que XTerm ne les intercepte pas pour son usage personnel.
> J'ai essayé de modifier ce comportement avec ses fichiers de configurations et la commande loadkeys, sans succès.
loadkeys(1) associe une action (qui peut être le simple envoi d'un caractère) à une combinaison de touches (ou une seule) mais pour la console intégrée au kernel. Il ne t'est d'aucune aide ici.
Je n'ai plus d'association "combinaison de touches" -> "action" dans la configuration de mon XTerm, mais je ne crois pas qu'il y en ai par défaut pour shift + direction.
Regarde si ta distribution n'en a pas installé dans /etc/X11/app-defaults/XTerm(-color). L'emplacement du fichier peut bien entendu changer. Sinon ~/.XResources, ~/.XDefaults. Tout ça peut être modifié en cours d'utilisation via editres(1).
Fais attention à une dernière chose: la sélection dans XTerm et dans jed sont deux choses différentes. Peut-être est-ce aussi un problème de paramétrage de jed.
-8<----------------------------------------8<--------------------------------------------
XTerm est un émulateur de terminal, il émule donc un lien série et doit sérialiser les données avant de les envoyer à ton shell ou jed (à l'application en foreground).
Sur ces liens série ne passait que de l'ascii (en résumé). Et dans la table ascii il n'existe pas de symbôle Flèche-droite, ce n'est pas du texte. Donc XTerm envoie une série de caractères ascii pour représenter Flèche-droite: un truc du genre ESC-[-A.
Et c'est à l'application en foreground d'interpréter que l'utilisateur a appuyé sur Flèche-droite et d'agir en conséquence.
Quand a shift + Flèche-droite alors là ca se complique !
-8<----------------------------------------8<--------------------------------------------
Si tu veux que ton tableau soit initialise avec des 0 (attention NULL peut etre different de 0) alors declare le en global ou statique, c'est le comportement par defaut.
Si tu utilises un gcc (assez) recent il y a des operatieurs specialement prevu pour:
Et tu peux apres pour certaines cases ecraser leur valeur:
# DJBDns
Posté par Raphael Monrouzeau . En réponse au message DNS pour réseau local et externe derrière un NAT. Évalué à 2.
tu peux autoriser la publication de certains enregistrements uniquement si la demande provient d'une certaine classe d'addresses IPs, par exemple ton reseau local.
Il est plus rapide que Bind.
Il est plus secure que Bind.
Il est plus sexy que Bind.
Bon en gros il est bien, tu fais un forward de port de ta gate vers ton DNS et c'est bon. Faudra tout de meme lire la doc (http://cr.yp.to(...)) ou recuperer le script qui genere les pages de manuel a partir du site web (sous certaines distribs c'est integre).
Postes a nouveau si tu rencontres des problemes.
# virtual filesystem
Posté par Raphael Monrouzeau . En réponse au message qu est ce que udev ? devfs ?. Évalué à 6.
Quand tu fais un opendir "/chemin/vers/un/dossier" tu reçois une liste des fichiers se trouvant dans ce dossier, et le opendir est spécifique au système de fichiers utilisé.
Pour /proc par exemple, tu as monté le device none (ou proc, ou truc) en procfs sur /proc. Enfin normalement, c'est écrit dans ton fstab.
Donc tous les open, read, write, opendir (getdents) ... de "/proc/tout/ce/qu'on/veut" seront ceux de procfs.
Et procfs génère ses informations à la volée (à partir de la liste de processus du kernel entre autres). Il ne va jamais lire sur le disque, c'est ce qu'on appelle un système de fichiers virtuel, d'ailleurs il n'a pas besoin de device (tu peux mettre ce que tu veux).
Oui procfs est indispensable pour monter /proc, tu peux même monter en procfs sur /ailleurs/procs et en même temps.
Devfs est un système de fichiers virtuel aussi.
Quand tu écris un module (disons le module device_mod) tu l'enregistres pour un major et certains minor.
C'est à dire qu'un open (read, write ...) sur un fichier de type device qui porte ce major et un de ces minors appellera le open (read, write ...) de ton module.
Et tu peux aussi l'enregistrer pour un nom de fichier (e.g. misc/device).
Maintenant si tu as monté en devfs sur le dossier /truc, essayer d'accéder (open) à /truc/misc/device chargera le module device_mod.
Et le module device_mod créera le fichier /truc/misc/device avec les bons major et minor.
En plus devfs a une toute autre manière (que personnellement je préfère) de nommer les devices.
Dernière chose sur devfs il est souvent accompagné de devfsd (même si ce n'est pas obligatoire) car devfs, donc le kernel, ne se rappelle pas d'un boot sur l'autre les permissions spéciales que tu avais pu accorder sur tel ou tel device.
Le démon devfsd permet d'attribuer des permissions dès la création des devices, de gérer des liens symboliques pour par exemple rester compatible avec l'ancien système de nommage ...
udev est différent.
il n'est pas situé dans le kernel. Mais le kernel le lance au moment de la détection (ou du chargement d'un module?) d'un matériel. Plus précisément il lance /sbin/hotplug qui lui lancera udev.
Suivant ses arguments et un fichier de conf udev va créer les devices à la demande avec les bons droits.
C'est plus modulaire car il permet d'utiliser les noms qu'on veut (et moi décidemment j'aime bien les noms devfs). Ca fait moins de code éxécuté en kernel, et il parait que le code de devfs était pas super en plus.
Voilà pour un court résumé, plein de fautes.
[^] # Re: rsync ?
Posté par Raphael Monrouzeau . En réponse au message copie du systeme sur une autre partition. Évalué à 1.
cp -a les copie tres bien. Garanti. Avec les fifos les dates et tout et tout.
Normalement meme les sparse (blocs plein de zeros qui ne prennent pas de place sur le disque) mais ca j'ai pas verifie. Et puis --sparse=always le fait.
Sinon sur le sujet:
Si tu copies un /dev/ en etat de marche ca passera.
Mais est-ce que udev effacera plus tard les devices qu'il n'utilise pas ?
Vu qu'il ne les aura pas cree, vu qu'ils l'ont deja ete par ta copie et pas par lui ?
Je ne connais pas encore assez udev pour te repondre. Si tu veux tu peux rebooter avec init=/bin/sh et copier uniquement les devices presents a ce moment. Tu n'auras que ceux necessaires (/dev/console en fait partie).
[^] # Re: Grub
Posté par Raphael Monrouzeau . En réponse au message Problème dual-boot Fedora Core 2 | Windows XP. Évalué à 1.
Le bios assigne 0x80 (premier disque dur) au ... premier disque dur !
Et 0x81 au second.
Et ainsi de suite.
Le premier secteur d'une partion bootable windows va chercher NTLDR sur le disque 0x80, pas de moyen (simple) de faire *booter* Windows sur le disque secondaire, il n'est pas prevu pour.
Les commandes ci-dessus vont "changer" le disque represente par 0x81 et 0x80.
Je crois par contre que seuls le secteur de boot et NTLDR accedent au disques dur via le BIOS (et les interruptions qui prennent 0x8[0-f] en parametre).
Le but de NTLDR etant de charger les drivers absolument necessaires au fonctionnement de Windows, il charge les drivers ATA. Et Windows lui n'accede jamais aux disques via le BIOS. Enfin je peux me tromper.
# standards ces raccourcis ?
Posté par Raphael Monrouzeau . En réponse au message xterm et raccourcis standards. Évalué à 1.
> Malheureusement, ce dernier "bloque" ces touches pour son propre usage.
Comment sais-tu qu'il bloque ces touches ? Il affiche une fenêtre ? Que ce passe-t-il quand tu appuies sur ces touches ? Il y a tellement de choses qui peuvent influer la-dessus que j'aimerais bien un peu plus de précisions pour t'aider.
Il se peut aussi que ce soit ton environnement de bureau et/ou ton window manager qui intercepte ces appuis sur touche avant XTerm.
Voir XFree avant tout le monde (peu probable).
Pour être sur que XTerm bloque bien shift + Flèche-droite, dans un XTerm lance cat, puis vérifie ce qui est affiché quand tu appuies sur Flèche-droite et sur shift + Flèche-droite.
Si ca ressemble a '^[[1;2c' (d'ailleurs si quelque-chose s'affiche) c'est que XTerm ne les intercepte pas pour son usage personnel.
> J'ai essayé de modifier ce comportement avec ses fichiers de configurations et la commande loadkeys, sans succès.
loadkeys(1) associe une action (qui peut être le simple envoi d'un caractère) à une combinaison de touches (ou une seule) mais pour la console intégrée au kernel. Il ne t'est d'aucune aide ici.
Je n'ai plus d'association "combinaison de touches" -> "action" dans la configuration de mon XTerm, mais je ne crois pas qu'il y en ai par défaut pour shift + direction.
Regarde si ta distribution n'en a pas installé dans /etc/X11/app-defaults/XTerm(-color). L'emplacement du fichier peut bien entendu changer. Sinon ~/.XResources, ~/.XDefaults. Tout ça peut être modifié en cours d'utilisation via editres(1).
Fais attention à une dernière chose: la sélection dans XTerm et dans jed sont deux choses différentes. Peut-être est-ce aussi un problème de paramétrage de jed.
-8<----------------------------------------8<--------------------------------------------
XTerm est un émulateur de terminal, il émule donc un lien série et doit sérialiser les données avant de les envoyer à ton shell ou jed (à l'application en foreground).
Sur ces liens série ne passait que de l'ascii (en résumé). Et dans la table ascii il n'existe pas de symbôle Flèche-droite, ce n'est pas du texte. Donc XTerm envoie une série de caractères ascii pour représenter Flèche-droite: un truc du genre ESC-[-A.
Et c'est à l'application en foreground d'interpréter que l'utilisateur a appuyé sur Flèche-droite et d'agir en conséquence.
Quand a shift + Flèche-droite alors là ca se complique !
-8<----------------------------------------8<--------------------------------------------
[^] # Re: peut être
Posté par Raphael Monrouzeau . En réponse au message initialisation statique tableau. Évalué à 4.
Si tu utilises un gcc (assez) recent il y a des operatieurs specialement prevu pour:
Et tu peux apres pour certaines cases ecraser leur valeur:
int my_tab[65536] = {
[0 ... 65535] = 32, // gcc seulement, ajout au C99
[32767] = 64, // portable, C99
[16384] = 64 //
};
Le tout tres bien documente dans info gcc.