Vous n'êtes pas identifié(e).
Je ne suis pas aller plus loin dans mes tests, je n'ai même pas essayé de booter sur la clé usb.
@+
Zoroastre.
PS : J'ai fouillé et farfouillé sur la toile à la recherche de retour d'experience du clonage à la sauce cp, cette methode est en définitive peu commentée et souvent mal ressentie.
Dernière modification par zoroastre74 (17-04-2011 10:08:11)
Hors ligne
Je voulais dire que dd réalisait les entrées/sorties en interne comparativement à cp ou cat qui eux utilisent des pipes (stdio) et sollicitent le shell du fait pour traiter ces même entrées/sorties.
Que dire, sinon que tout est faux dans cette phrase.
– Lorsqu'il s'agit d'accès disque (en lecture comme en écriture) ce n'est jamais une appli, ni même l'OS qui réalise la copie, mais le firmware du disque. Les applis (cat, cp, dd...) ne font que donner des ordres à l'OS (Linux), ces ordres sont nommés "appels systèmes" par les développeurs d'appli, ou "primitives systèmes" par les développeurs du noyau, ou encore mais là ça devient lourd à prononcer, bien que ce soit la formulation la plus exacte: "appeler une primitive système". OPEN, READ, WRITE, CLOSE... sont des primitives systèmes de Linux, l'appel étant réalisé (côté appli) par une interruption du CPU. Dans le cas d'un CPU x86 ou x86_64, c'est l'interruption n°128 notée "INT 80h" ou "INT 0x80" en fonction du langage assembleur utilisé. Lorsqu'on programme une appli, on écrit rarement en langage assembleur mais plutôt en C. Une primitive système est une fonction tout à fait classique, mais qui doit s'exécuter en mode noyau. Pour utiliser une primitive système, il faut mettre les paramètres dans la pile (comme pour toute fonction), puis mettre le numéro de primitive dans le registre EAX puis réaliser l'interruption INT 80h. Le compilateur C se charge du rangement des paramètres dans la pile, le numéro de primitive est positionné par les fonctions de la section 2 du man: open(), read(), write(), close()... qui sont des fonctions ultra-courtes dont le but est simplement d'appeler les primitives OPEN, READ, WRITE, CLOSE... grâce à 2 instructions CPU: écrire la bonne valeur dans EAX puis faire INT 80h. Toutes les applications sont à égalité sur ce point, autant cat que cp que dd. Aucune appli ne peut réaliser une copie en interne.
– Aucun flux de données ne transite par l'intermédiaire du Shell. Si tu écris cat <a >b, le Shell va créer un fils (appel système FORK), ce processus fils va ouvrir le fichier a en mode read only dans son descripteur n°0 appelé aussi stdin (appel système OPEN), puis ouvrir le fichier b en mode write only dans son descripteur n°1 appelé aussi stdout (appel système OPEN), puis va se transformer (appel système EXEC) en /bin/cat et à partir de ce moment le Shell n'est plus concerné par ce que va faire cat. Lorsque cat commencera son exécution, il va hériter de l'état des descripteurs qu'il a reçus au moment de l'EXEC et va faire ce pour quoi il est programmé: des READ du descripteur n°0 et des WRITE dans le descripteur n°1, sans même savoir précisément ce qu'il lit ni dans quoi il écrit, jusqu'à ce qu'il n'y ait plus rien à lire. La commande cp, n'utilise pas l'entrée et la sortie standard, mais utilise les descripteurs suivants: 3, 4, 5, 6, 7... en réalisant elle-même les OPEN et CLOSE. La commande dd peut utiliser les descripteurs 0 et 1 (exemple: dd <a >b) dans quel cas les OPEN ont sont réalisés avant le EXEC, ou alors utiliser les descripteurs 3, 4... (exemple: dd if=a if=b) dans quel cas les OPEN sont réalisés après le EXEC, mais dans tous les cas, la performance de copie sera exactement la même, et ne transitera pas par le Shell. D'ailleurs, dans l'absolu, cat, cp et dd pourrait très bien être lancés par autre chose que le Shell.
– Je ne vois pas pourquoi tu parles de pipes. Un pipe est un lien de données entre 2 processus. Dans l'exemple: dd </dev/sda bs=512 count=1 | gzip >mbr.gz, les WRITE de dd seront récupérés par les READ de gzip, mais ni dd ni gzip ne savent qu'ils ont affaire à un pipe. Un pipe permet de copier les données directement depuis la mémoire virtuelle d'un processus vers la mémoire virtuelle d'un autre processus, sans aucun tampon intermédiaire. Un pipe ne consomme donc aucune ressource mémoire. Dans mon exemple, chaque WRITE de dd sera exécuté en même temps qu'un READ de gzip, en d'autres termes: si un WRITE a lieu avant un READ, dd sera endormi jusqu'à ce que gzip fasse un READ, ou si un READ a lieu avant un WRITE, gzip sera endormi jusqu'à ce que dd fasse un WRITE. Lorsque ce WRITE-READ sera exécuté (en fois par le noyau), les processus se réveilleront simultanément. L'endormissement est le moyen utilisé pour éviter d'avoir un tampon.
En définitive, je pense que les avantages sont du côté de dd, de par ses nombreuses options et sa capacité à accueillir differents types de péripheriques.
C'est le noyau (Linux) qui gère les différents types de fichiers/périphériques/tubes nommés... certainement pas les applis. Les applis ne font que des appels à OPEN, READ, WRITE, CLOSE... et autres primitives système, sans faire attention s'il s'agit d'un fichier régulier, d'un périphérique, d'un tube nommé...
J'ai omis d'ajouter que le MBR est en dehors de la partition, dd le recuperera lors d'un clonage de disque, ce que ne fera pas cp !
Le MBR est présent dans /dev/sda mais absent de /dev/sda1, peu importe l'appli utilisée. /dev/sda donne accès au contenu du disque entier (MBR compris) tandis que /dev/sda1 donne accès au contenu de la première partition (sans MBR).
Je pourrais ajouter également que cp retournera certainement une erreur s'il rencontre un block defectueux, ce que ne fera pas dd.
Alors là, j'avoue que je n'y avais pas pensé. Il est normal que la mécanique d'un disque puisse commettre moins d'1% d'erreur, mais cela est géré et rattrapé de façon transparente par le firmware du disque grâce aux sommes de contrôle (une somme par secteur). Dans tous les cas, le disque recommencera jusqu'à ce que les sommes de contrôles soient correctes, sans que l'OS en soit informé. Un disque est donc vu par l'OS comme 100% fiable. Par contre, si un disque fait des erreurs si grosses que son firmware n'arrive pas à les rattraper, il le signalera à l'OS, mais cela veut dire qu'il y a probablement plein d'autres secteurs très endommagés, même si leurs erreurs ont jusque-là pu être rattrapées, mais qu'en sera-t-il demain? sans compter que les relectures intempestives prennent du temps, et usent encore plus le disque. Un tel disque, moi je le jette direct à la poubelle.
PS : J'ai fouillé et farfouillé sur la toile à la recherche de retour d'experience du clonage à la sauce cp, cette methode est en définitive peu commentée et souvent mal ressentie.
Il n'y a pas de "méthode cp" de même qu'il n'y a pas de "méthode dd". cp et dd ne sont que des outils, de même que /dev/sda et /dev/sdb ne sont que des moyens de présenter le contenu du disque, rien de plus.
Dernière modification par e-miel (17-04-2011 17:39:16)
Hors ligne
J'ai cloné ce disque dur...
Étonnant, vue l'importance des explications ! En tout le cas, je mettrai "sous les coudes" ce topic.
Amicalement.
Lorsqu'il s'agit d'accès disque (en lecture comme en écriture) ce n'est jamais une appli, ni même l'OS qui réalise la copie, mais le firmware du disque.
Rappeles-toi ce qu'est un firmware !!! Les firmwares n'ont pas toujours existés...Il s'agit avant tout d'électronique et de mode de communication entre péripheriques. Pas besoin de firmware pour faire du rs232, de l'i2c par exemple...L'informatique s'est développé de concert avec les periphériques communicants. Il n'empêche qu'un assemblage intelligent de composants électroniques peuvent communiquer ensembles, rien qu'en utilisant des signaux électroniques, si si !!!
Le language assembleur est ce qui se rapproche le plus du langage machine, pourtant il y demeure plusieurs façon d'ecrire une seule fonction dans ce langage, il en va de même en c, vb, pascal ou autre. Le resultat sera le même pour peu que l'on respecte le cahier des charges, la methode differera en fonction des qualités artistiques du ou des programmateurs...Les "primitives" que tu évoques ne sont pas uniques à linux, elles sont parties intégrantes des modes de communication entre électroniques et péripheriques, elles sont binaires.
Toutes les applications sont à égalité sur ce point, autant cat que cp que dd. Aucune appli ne peut réaliser une copie en interne.
Exacte car il s'agit d'electronique, pourtant dans le sens où tu l'entends tu subodores que touch equivaut à rm. En effet, ces deux programmes font appels aux systèmes pour contrôler le disque dur et utilisent à la fois le système et le firmware correspondant pour manipuler ce même disque dur...Que nenni, ces programmes appelent le système, qui lui même grâce à un adressage complexe effectue ce qu'on lui demande. Le firmware est juste là pour optimiser ce travail. Le code programme pourrait surprendre tant la similitude entre ces deux fonctions est proche, en langage assembleur du moins...
Un pipe est un lien de données entre 2 processus
C'est aussi un lien entre les données entrantes et sortantes...
(stdio)
...Je ne l'entendais pas dans le sens linuxien, je pensais que tu comprendrais !
Dire aussi que le shell n'est pas concerné dans certaines opérations est aussi une erreur car des commandes tels que cp, mkdir, rm, cat "existent" (entre guillemet, hein!) parce que le shell existe. D'ailleurs, on pourrait interpreter le shell comme un langage de programmation, non ???
Dire le contraire reviendrait à nier l'existence du shell ! Oooohhh !!!
Je sais reconnaitre mes erreurs quand je me trompe et ne m'en cache pas (je l'ai prouvé).
Mais affirmer des contre-vérités sans avoir une connaissance globale de ce qu'est une communication physique entre péripheriques, c'est oublier l'Histoire !!!
@+
Zoroastre.
PS :
Tout en lisant attentivement cette discussion, je constate que principal intéressé n'est toujours pas là.
Vrai...peut-être est-il le seul à se marrer là !
Hors ligne
(..) Les firmwares n'ont pas toujours existés... (..)
C'est vrai. J'ai utilisé le terme firmware pour parler des périphériques actuels. N'empêche que dans les années 1990, il existait des appareils avec firmware qui communiquaient en RS232.
Le language assembleur est ce qui se rapproche le plus du langage machine, pourtant il y demeure plusieurs façon d'ecrire une seule fonction dans ce langage, il en va de même en c, vb, pascal ou autre. Le resultat sera le même pour peu que l'on respecte le cahier des charges, la methode differera en fonction des qualités artistiques du ou des programmateurs...
C'est vrai. Il y a la propreté du code (un code propre est plus lisible par un humain, mais aussi plus performant car il va "droit au but") et surtout l'algorithme qui déterminent la performance d'un traitement. Cependant, dans le cas d'une copie, il n'y a pas de traitement, ce n'est que de la délégation au noyau (pour la découpe en paquets, le système de fichiers avec cache-disque en RAM) et au contrôleur disque (pour réaliser la copie elle-même).
Les "primitives" que tu évoques ne sont pas uniques à linux, elles sont parties intégrantes des modes de communication entre électroniques et péripheriques, elles sont binaires.
Exact. Linux, Windows... ont leurs primitives. Dans les OS multitâches, les primitives permettent aux processus de communiquer, mais pour réaliser un traitement interne pas besoin d'appels-système: les processus réalisent tout dans leurs mémoires virtuelles.
(..) tu subodores que touch equivaut à rm.
Tout dépend du point de vue. D'un point de vue du Shell, touch et rm sont les applications /bin/touch et /bin/rm. Mais une fois le EXEC passé, ces 2 applications n'émettent pas du tout les mêmes appels-système, alors que cat, cp et dd émettent les mêmes appels-système, aux tailles de bloc près.
[small]Hors-sujet 1 : touch fichier change la date de modification de fichier (très utilisé avec make) alors que rm fichier supprime fichier.
Hors-sujet 2 : certains utilisent touch fichier pour créer un fichier vide, moi j'utilise >fichier pour ça.[/small]
Un pipe (..) est aussi un lien entre les données entrantes et sortantes...
Qui entrent et sortent d'où ? Pour moi, on ne peut parler de pipe qu'entre 2 processus. Dans cat <a >b, je ne vois aucun pipe.
stdio (..) Je ne l'entendais pas dans le sens linuxien, je pensais que tu comprendrais !
Je n'étais pas bloqué sur le sens linuxien, quoi que sous Windows les pipes n'existent pas. Je sais que Cygwin peut simuler des pipes, du moins lorsque les applis sont compilées avec le compilateur Cygwin, mais au sens propre du terme, il n'existe pas de pipe sous Windows.
Dire aussi que le shell n'est pas concerné dans certaines opérations est aussi une erreur car des commandes tels que cp, mkdir, rm, cat "existent" (entre guillemet, hein!) parce que le shell existe. D'ailleurs, on pourrait interpreter le shell comme un langage de programmation, non ???
C'est vrai, toutes ces applis ont été créées pour être utilisées dans un Shell. Cependant, même si l'utilisateur écrit sa ligne de commande dans un Shell, et qu'il hérite des descripteurs préparés par le Shell, l'exécution sera indépendante du Shell, dans le sens que les données ne transiteront pas par le Shell.
Je sais reconnaitre mes erreurs quand je me trompe et ne m'en cache pas (je l'ai prouvé). Mais affirmer des contre-vérités sans avoir une connaissance globale de ce qu'est une communication physique entre péripheriques, c'est oublier l'Histoire !!!
Il n'y a pas de mal. Tout ce que je voulais dire c'est que si les appels-système sont les mêmes, le résultat sera le même, peu importe qu'ils soient réalisés en partie par le Shell (cat <a >b) ou intégralement par l'appli lancée (cp a b) ou au choix de l'utilisateur (dd if=a >b).
Si je crée (par exemple en C) une application perso et que je veux tester si elle fonctionne correctement en lisant des gros blocs ou des petits blocs, je peux utiliser dd if=données bs=taille_à_tester | perso >résultat. Je veux aussi tester si mon appli perso arrive à bien découper sa sortie grâce à perso <données | dd of=résultat bs=petite_taille. Pour moi, dd et touch sont des commandes quasi-inutiles pour le commun des mortels, mais très utiles pour les développeurs d'applications.
Hors ligne
Cependant, dans le cas d'une copie, il n'y a pas de traitement, ce n'est que de la délégation au noyau (pour la découpe en paquets, le système de fichiers avec cache-disque en RAM) et au contrôleur disque (pour réaliser la copie elle-même)
On pourrait même dire qu'en fait il ne se passe rien !
Le système ne copie pas des données physiques, il modifie des adressages mémoires et transmet ces modifications selon des règles mathématiques et electriques aux autres péripheriques. La complexité des algorithmes et des composantes informatiques ne doivent pas masquer une réalité philosophique, celle du non-sens de nos interpretations, l'informatique est devenu une boîte noire, secrete, que seul des magiciens pourraient comprendre.
Le langage assembleur est effectivement ce qui se rapproche le plus du langage machine, je l'ai déjà dit, mais il serait bon de définir ce qu'est une machine avant tout et ne pas omettre que le langage assembleur travaille avec des registres mémoires.
Là, je renvoie qui veut vers la machine de Turing
Qui entrent et sortent d'où ? Pour moi, on ne peut parler de pipe qu'entre 2 processus
FIFO est un pipe aussi.
La bonne définition d'un pipe est le partage d'un espace mémoire entre plusieurs processus.
Il y aurait donc des pipes partout et peut-être encore plus chez Windows !!!
Pour moi, dd et touch sont des commandes quasi-inutiles pour le commun des mortels, mais très utiles pour les développeurs d'applications.
Je pense le contraire et nous sommes beaucoup de mortels
@+
Zoroastre.
Hors ligne
Pour moi, dd et touch sont des commandes quasi-inutiles pour le commun des mortels, mais très utiles pour les développeurs d'applications.
Je pense le contraire et nous sommes beaucoup de mortels
Selon M. Mc Luhan, lorsque nous utilisons un outil, nous devenons cet outil par anesthésie de nos sensations mises en action par cet outil.
Ors donc, le langage informatique exprime cette anesthésie et les commandes dd et touch sont donc tout à fait exploitables par nous tous,mortels, sans discrimination, avec tout ce qu'elles comportent de rigueur attaché, comme avec l'utilisation de tout outil créé humainement.
Ensuite, il nous revient chacun (ou non) d'en apprendre les arcanes pour en tirer un profit plus personnel.
Comme toute l'informatique et comme le permet totalement debian et le libre en général.
Yeaaaaaaaaaaaaaaah
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Il est à considerer que nombre de nos péripheriques ne possèdent pas de firmware. Nul besoin de décortiquer un ordinateur pour s'en rendre compte. Ceux-ci sont bien souvent gérés par le système d'exploitation et ne réclament aucune performance outrancière.
D'après moi, tous les périphériques ont un firmware, mais tous ne le stockent pas nécessairement dans une Flash embarquée. Certains périphériques lors du démarrage demandent au pilote de leur fournir le firmware. Les cartes graphiques, même haut-de-gamme, ont de base un mini-firmware compatible VESA qui ne gère aucune accélération, ni 3D ni la vitesse de rotation du ventilateur. Le pilote officiel contient le firmware à copier dans la RAM de la carte graphique lorsqu'elle le demandera au démarrage. Je pense même que la majorité de la taille du pilote ne sert pas aux "fonctions de pilotage" mais plutôt au firmware vu comme un "gros binaire incompréhensible" que le pilote doit copier dans la carte graphique lors du démarrage. C'est pour ça qu'on parle de pilote DirectX 10 ou DirectX 11, ce n'est pas les "fonctions de pilotage" qui sont DirectX mais plutôt les fonctions rendu 3D que le firmware est capable de calculer. Il en va de même dans les mini-dongles USB qui servent de carte-son, tunerTV, etc... et je suppose que concernant les périphériques intégrés dans la carte-mère, on choisit dans le BIOS quels sont les firmware à fournir (Enable) ou à ne pas fournir (Disable) lors de l'initialisation. Je peux me tromper, mais c'est comme ça que je l'ai compris. Par contre, les disques-durs ou SSD embarquent à 100% le firmware, c'est pour ça qu'il faut les "flasher" pour les mettre à jour, expression qu'on n'emploiera jamais pour une carte graphique ou un dongle-USB.
FIFO est un pipe aussi.
Oui, pipe = FIFO, mais dans cat <a >b je ne vois aucune FIFO.
La bonne définition d'un pipe est le partage d'un espace mémoire entre plusieurs processus.
Il y aurait donc des pipes partout et peut-être encore plus chez Windows !!!
Je ne suis pas d'accord, du moins quant à l'emploi du terme pipe. Pour moi, lorsque plusieurs processus se partagent du code exécutable, on appelle ça des librairies (ou bibliothèques en français). Lorsque plusieurs processus se partagent une zone de travail, on appelle ça de la mémoire partagée (optenue sous Linux avec shm ou mmap). Lorsque des données sont copiées (et non partagées) d'un processus à l'autre directement (c'est-à-dire sans mémoire partagée ni tampon intermédiaire) on appelle ça un pipe (ou tube en français). Le pipe est un moyen de partager l'exécution du WRITE d'un processus et du READ d'un autre processus, mais il n'y a aucune zone de mémoire partagée dans un pipe. FIFO (First In First Out) désigne simplement l'ordre dans lequel les données sont copiées, c'est tout.
Pour moi, dd et touch sont des commandes quasi-inutiles pour le commun des mortels, mais très utiles pour les développeurs d'applications. (..) Je pense le contraire et nous sommes beaucoup de mortels.
Si Monsieur Lambda veut sauvegarder son MBR (à supposer qu'il sache ce que c'est) il va plutôt écrire head -c 512 /dev/sda >mbr, et s'il est un peu futé (qu'il a lu dans man head que b=512 et qu'il pense à compresser) il va écrire head -c b /dev/sda | gzip >mbr.gz, et concernant les futurs boots EFI, ils seront faciles à sauvegarder avec head et tail, mais je ne vois pas comment y arriver avec dd.
Selon M. Mc Luhan, lorsque nous utilisons un outil, nous devenons cet outil par anesthésie de nos sensations mises en action par cet outil. Or donc, le langage informatique exprime cette anesthésie et les commandes dd et touch sont donc tout à fait exploitables par nous tous,mortels, sans discrimination, avec tout ce qu'elles comportent de rigueur attaché, comme avec l'utilisation de tout outil créé humainement.
Si quelqu'un est habitué à dd, je lui souhaite bien du plaisir avec dd, mais si j'avais en face de moi un débutant, je préférerai lui conseiller cp et head plutôt que dd.
Si on laisse de côté l'aspect feeling d'un éventuel passionné de touch ou dd, je ne vois pas de cas dans lequel Monsieur Lambda aurait intérêt de fixer manuellement une taille de blocs de copie, ou de changer la date de modification d'un fichier sans avoir modifié son contenu. Par contre, pour un développeur d'applications, j'en vois tout à fait l'utilité.
Hors ligne
Ah ben oui, là, elle va bien moins marcher maintenant !
Bourvil dans le film Le Corniaud.
À propos de sa 2 chevaux complètement démantibulée à un carrefour par la Bentley de De Funes, comme la question de guynux l'est dans ce déroulement des logiques et des fonctionnements de l'informatique en réponses.
J'ajouterai donc, que d'utiliser dd ou touch pour e-miel, c'est utiliser une belle voiture de luxe avec un klaxon en diamant pour faire simplement "coin-coin" ?
Alors que les commandes lambda de cat ou de cp suffisent sans excès au même résultat de copie certaine dans tous les cas compréhensibles intuitivement ?
Concernant la commande chevron : > à la place de la commande : touch, de mémoire d'utilisateur, la commande chevron > pour créer un fichier peut être interprétée différemment par le système, selon le contexte, par exemple, lors d'une commande find ou dans un script bash, non ?
Bisou à guinux et merci de vos explications, chers e-miel et zoroastre74.
Comme arien, je mets ce topic sous le coude.
Amitié, Jojo l'halluciné
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Le pipe est un moyen de partager l'exécution du WRITE d'un processus et du READ d'un autre processus, mais il n'y a aucune zone de mémoire partagée dans un pipe.
Comment un processus pourrait se passer de la réservation d'un espace mémoire ???
Prends exemple sur la mémoire tampon où les données y sont stockées les unes derrières les autres, découpées, en attente que cette mémoire se vide et se remplisse à nouveau, jusqu'à la dernière once.
Le langage C utilise ces mémoires pour réguler ses entrées/sorties. Le noyau n'en est pas exclu non plus, car dés le moment où nous faisons appel à une variable, une chaine, nous travaillons avec la mémoire. Le processeur a ses registres aussi...
L'assembleur, pour finir, utilise ses mnémoniques pour les convertir en langage machine. Terme tout à fait adapté.
@+
Zoroastre.
Dernière modification par zoroastre74 (18-04-2011 18:05:06)
Hors ligne
Hors ligne
Lecture
Les pipes permettent de filtrer des commandes ou processus, il n'y a pas de limite théorique au nombre de programmes ou de commandes que l'on peut enchaîner.
Un pipe permet de copier les données directement depuis la mémoire virtuelle d'un processus vers la mémoire virtuelle d'un autre processus, sans aucun tampon intermédiaire. Un pipe ne consomme donc aucune ressource mémoire
http://en.wikipedia.org/wiki/Pipeline_(Unix)
Implementation
In most Unix-like systems, all processes of a pipeline are started at the same time, with their streams appropriately connected, and managed by the scheduler together with all other processes running on the machine. An important aspect of this, setting Unix pipes apart from other pipe implementations, is the concept of buffering: a sending program may produce 5000 bytes per second, and a receiving program may only be able to accept 100 bytes per second, but no data is lost. Instead, the output of the sending program is held in a queue. When the receiving program is ready to read data, the operating system sends its data from the queue, then removes that data from the queue. If the queue buffer fills up, the sending program is suspended (blocked) until the receiving program has had a chance to read some data and make room in the buffer. In Linux, the size of the buffer is 65536 bytes.
Pas besoin de traduire buffer j'espère...
La modification qu'apporte un pipe sur le flot de données entre processus dépend bien entendu des processus en jeu et des données à transiter, la mémoire virtuelle est un fait inhérent, il n'empêche que les données sont affectés par la taille du buffer et la vélocité des processus à effectuer les read/write.
NetBSD par exemple, utilise la mémoire vive afin de réduire les échanges entre les read/write au sein même d'un pipe.
Les pipes ne se résument pas uniquement à donner le relais au processus suivant. Ils ont differentes facettes et ne peuvent plus se résumer à un simple tuyau unidirectionnel et invariable.
@+
Zoroastre.
Dernière modification par zoroastre74 (18-04-2011 20:39:07)
Hors ligne
Hors ligne
Dernière modification par guynux (19-04-2011 22:48:16)
Hors ligne
La seule inconnue est d'attendre la fin du processus sans aucun renseignement
http://dcfldd.sourceforge.net/
Le paquet est fonctionnel mais date de 2006 !!!
Il existe une astuce (script bash) pour obtenir une barre de progression avec cp.
Concernant ton problème...
As-tu necessairement besoin de configurer tes postes en ip fixe ?
iface eth0 inet static
As-tu un routeur/serveur cisco ? Je pensais à fixer les ip en fonctions des adresses mac des cartes réseaux.
As-tu configurer un pc en tant que serveur dhcp ou passerelle ?
Je pense que la solution la plus confortable pour un deploiement rapide demeure un serveur PXE.
http://publications.jbfavre.org/system/ … tos_redhat
Je crois savoir aussi que dans ce domaine, des solutions toutes faites existent.
@+
Zoroastre.
Dernière modification par zoroastre74 (20-04-2011 00:50:06)
Hors ligne
dd if=/dev/sda1 of=/dev/sda2 &
PID=$!
kill -USR1 $PID
Par contre, je ne connaissais pas dcfldd (quel nom pourri). Je viens de le tester et ça affiche la progression en temps réel, c'est donc la solution idéale pour ce genre d'opération. Je l'adopte.
Merci Zoroastre.
Hors ligne
Hors ligne
guynux écrit :
je ne m'attendais pas à déclencher pareil tsunami avec ma question de connexion au réseau de mon bahut...
guynux écrit :
J'ai rempli infodistri, 3 lignes , c'est tout ?
Impec !
Et ne te gêne pas guynux à déclencher encore de tels kamikazes (vent divin) sur le forum df, on est preneur sans satiété !
Tchibâââ !
zoroastre74 écrit :
Bienvenue chez les fous
Et même :
Bienvenue chez les fous-faciles
Là : http://debian-facile.org/forum/viewtopi … 662#p27662
Nous dirait un certain MaTTuX_ originellement !
Pour la barre de progression de la commande cp dans le post précédent de zoroastre74, j'ai ouvert un nouveau fil là :
http://debian-facile.org/forum/viewtopi … 707#p30707
Afin de ne pas tout mêler davantage !
Hop hop hop !
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Hors ligne
et non :
je pensais à /etc/interfaces et etc/resolv.conf
Je te conseille pour l'ensemble de tes commandes en terminal d'utiliser l'autocomplément de la tabulation.
C'est à dire que tu rédiges les 3 premières lettres de ta ligne de commande, et en appuyant sur tabulation de ton clavier, le complément du mot tapé s'écrit automatiquement.
Si tu ne te rappelles pas la suite d'une commande par le chemin, à partir du dernier repertoire trouvé, tu tapes deux fois sur tabulation et une liste de possibilités est proposée à notre mémoire défaillante.
Pour ce qui concerne le réseau, je laisse à d'autres plus pointus (et moins pressés que je ne le suis ces temps) de te fournir des réponses.
Il reste aussi que tu as un salon df très actif où tu peux poser des questions et recevoir des réponses par qui le sait immédiatement.
Voir :
http://debian-facile.org/asso:salon-irc-df
ou bien là :
http://debian-facile.org/logiciel:konversation
Tchibâââ ! :lol
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Dernière modification par guynux (20-04-2011 23:03:45)
Hors ligne
Hors ligne
Dernière modification par zoroastre74 (24-04-2011 01:27:57)
Hors ligne