totof2000 a écrit 9656 commentaires

Quelle horreur :)

tail -n2 "$tmp"|head -n1|awk '{printf ("%3s %6s ", $7, $9)}'

Si j'ai bien compris et que tu veux récuperer la 3eme ligne ...
awk ' ($NR==3) {printf ("%3s %6s ", $7, $9)}'

awk --field-separator / '{print $NF" "$3}'

La version porrtable doit être awk -F"/" '{print $NF" "$3}"

Et si le but est de récupérer le nom de fichier .... man basename

# basename /toto/titi/tutu.tmp
tutu.tmp

Il me semble que le dernier hors-série parle de l'embarqué. Sinon pour te donner une démarche dans les grandes lignes, il te faut :
- générer un environnement de cross compilation pour ton architecture cible sur ta machine de travail
- générer ton environnemet cible à partir de ta chaine de cross-compilation
- transfére ce que tu as compilé sur ton environnement cible
- tester.

Tu devrais trouver suffisamment d'ééments à partir de ce que je t'ai indiqué. Cherche déjà sur google ce qu'est la cross compilation, effectue des recherches sur ton environnment cible (ARM ? ) et tu auras des infos. Une fois que c'est fait, s'il y a des points que tu ne cmprends pas, vien poser tes questions.

Tu ne serais pas en train de lancer un bon veux troll par hasard ?

Aussi ne serait-il pas plus utile/approprié de créer une catégorie adéquat dans le forum, ou une section particulière ?

Ce n'est pas une critique, juste une proposition (à débattre avec avantages/inconvénients par rapport à un journal comme ça a été fait ici). Le premier inconvénient que je vois c'est que certains qui passent souvent ici ne le verraient pas parce que ne lisent pas le orum.

Mais je fais ça tous les jours :)

Moins moche :

echo "un deux trois quatre" |awk -F"[ \\t]+" ' {sub($1"("FS")","");print }'

L'avantage de cette règle est que tu peux avoir des champs séparés d'une ou plusieurs tablulation ou espaces ....

Amusant ce petit problème. Ca détend :)

un rom ment c'est mieux ?

C'est pas mal de savoir le faire en AWK, ça évite ensuite des aberrations dy style cat | grep .... | cut .... | awk ... | sed ...

J'ai mieux ...

echo "un deux trois quatre" |awk '{sub($1 FS,"");print}'

Si on remplace le séparateur de champ :

echo "un;deux;trois;quatre" |awk -F\; '{sub($1 FS,"");print }'

Coute pas cher (j'en ai trouvé un pour moins de 5 euros en Allemagne). Il existe aussi des espèces de clés USB faisant office d'adaptateur micro SD.

Sur un serveur c'est sur que l'on change les disques de place tous les jours. En tout cas je change moins souvent mes disques de place que je ne les reboot.

L'admin ou l'utilisateur ne comprenait pas que linux ne marche plus dès que l'on changeait le disque de place, que l'on réorganise les partitions alors que windows s'en sortait bien. Surtout avec grub1 ou liloo ou en gros le système devenait complètement imbootable dans ces cas la.
C'est sur que sur un serveur avec 300 disques, on change de place les disques tous les jours :).

Plus sérieusement, je n'ai rien contre cette façon de faire pour les postes de travail bureautique. Pour le reste, c'est pas forcément la bonne façon de faire et je pense que les distribs orientées "entreprises" devraient favoriser une autre approche.

Devoir gérer 300 disques ça n'est pas un besoin courant, et il y a quand même by-id et by-path présent par défaut pour ceux qui sont dans ce cas.

300 disques, sur des serveurs d'entreprise, ce n'est pas si banal que ça .... Si tu prends des métas de 33 Gb, ça ne fait que 9 To de données,

Et même dans ton cas, rien que pour trouver la partition racine, je garderait quand même la méthode des UUID, parce que c'est fait pour. Bien sur, je n'ai rien contre, ce qui me gène c'est la non persistence des chemins dans /dev et le fait que l'on doit configurer UDEV pour avoir un truc persistant.

Les autres OS gèrent tellement bien les gros systèmes qu'il font à peine de la figuration dans le top 500 des super-machines...

Aucun rapport : le top500 ne parle que des perfs de calcul, La geston du stockage n'a rien a voir et les OS qui gèrent le mieux leur volumétrie sont loin d'être des bêtes de courses (mainframes IBM par exemple).

Si l'utilisateur a accès facilement à la mémoire et qu'il l'a change, au hasard avec une carte SD NoName MadeInChina de chez Carrouf, l'OS va ramer/bugguer aléatoirement. L'utilisateur va penser : Windows Phone 7 c'est de la merde.

Tu crois que Windows a besoin de ça pour ramer/bugger ?

Cela dit des gens qui pensent que windows c'est de la merde et qui n'utilisent pas autre chose, j'en connais plein. Le fait de penser que windows c'est de la merde ne les empêchent pas de l'utiliser.

Ya un peu de travail à faire à la base, mais ça reste jouable.

C'est le "S" de Secure Digital : prévu dès le début pour ce genre de fonctionnement. Ca ne me gène pas plus que ça, si c'est bien indiqué dès le départ sur le téléphone. L'intéret pourrait être d'empêcher quelqu'un qui dérobe la carte d'accéder aux données contenues sur celles-ci (contact, messages, etc ...). Mais bon, que la carte soit inutilisable ailleurs, ça c'est plutot gênant. Il devrait
y avoir possibilité de réutiliser la carte (sans forcémant accéder aux données présentes sur celles-ci).

Ça me parait raisonnable comme configuration par défaut,

Pas quand tu as 300 disques à gérer. S'il faut faire la conf de 300 disques à la main, ça devient vite pénible. L'UUID nest pas un problème en soi, ça peut servir, par contre une config par défaut avec une norme quelque part (qui serait à mon avis plus du ressort de la distrib que du kernel) pourrait être intéressant, mais là je parle un peu dans le vide car je n'ai pas eu le temps de regarder comment ça marche exactement sur Linux. Tout ce que je peux te dire, c'est que sur d'autres systèmes, l'approche par chemin hardware persistent marche plutot bien, et sur des serveurs ayant à gérer plus de 100 To, je n'ai jamais rencontré de gros inconvénients à cette approche, et j'ai vraiment du mal à voir les avantage de la méthode Linux.

Effectivement, ça pourrait être inéressant, sauf que ce serait mieux si c'était natif ....

Du coup, tu ne peux pas le faire automatiquement, puisque le chemin des librairies du système varie d'un système à l'autre.
Etya pas moyen de récupérer cette info automatiquement ? Je serais surpris que ça ne soit pas possible.

Je suppose que la densité d'information (au sens de la quantité d'information par unité de surface) est à peu près constante sur toute la surface du disque, à l'ère moderne (pour pas gâcher).
C'est ce que je me souviens avoir lu.
Je suppose également que la vitesse de rotation des plateaux est une constante en fonctionnement (hors ralentissement pour l'économie d'énergie sur les disques modernes).
Oui.
Je suppose que, comme pour un CD/DVD, le début de l'espace de stockage est à la périphérie.

Ca par contre je n'en sais rien : avec les disques modernes, je me demande si la "vue" que l'on a de l'attribution de la volumétrie sur le disque est bien réelle. Mais si ma mémoire est bonne, il y a un temps, l'attribution des cylindres se faisait du centre vers la périphérie (a moins que je ne me trompe). Et j'ai toujours cru que le début de l'espace de stockage d'un CD/DVD se faisait au centre, et non à la périphérie.

Peut-être, je ne connais pas cette méthode d'accès aux disques. Faut que j'y jette un oeil cet apres-midi ou demain si j'ai un peu de temps.

Certes, c’est un peu plus compliqué que de mettre un label à une partition, mais quelqu’un qui administre une BDD qui demande à accéder direct au hardware devrait être capable de faire ça, quand même.
Non. Soit il n'en a pas les droits, ou il ne sait pas faire ... son métier c'est DBA, pas admin système, et il n'a pas à connaitre la totalité des subtilités de chaque OS sur lesquels sa BDD tourne.

donc retenir et récupérer le mappage matos/nom dans une BDD
GNI ?????
Dans le genre simple ....

Ben dans ce cas la il définit LD_LIBRARY_PATH avec en premier les libs systeme et ensuite les libs de son soft ....

Pour ceux qui ne connaissent pas (dont totof apparemment), on peut avec udev créer des règles pour associer à un périphérique (détecté par son uniqueID, son chemin physique, son nom commercial, ...) un nom système (ou un lien symbolique dans /dev) permanent.

Cool, alors si je veux devoir gérer 300 disques avec ma babasse Linux, je dois créer 300 regles UDEV pour être sur que mes disques ne seront pas renommé entre 2 redémarrages ? ya pas un raccourci possible avec UDEV ? CCe serait déjà mieux que rien.