Gwenael Moreau wrote:
> Et déjà j'ai plein de questions à vous poser ...
>
> 1--Tout d'abord, je vais, comme c'est la mode, me poser des questions
> pour y répondre :
> Hier soir vers 1h10 j'ai écris
>
> Alors sinon quand je bouge un fichier vers la disquette :
>
> /root>mv /home/gwen/pbdvips /mnt/floppy/
> mv: /mnt/floppy/pbdvips: Operation not permitted
>
> Y dit ça mais malgré tout :
>
> /root>ls /mnt/floppy/
> pbdvips structure.tex urgent ws_ftp.log
>
> Que dois je comprendre ???
> Est ce parce que le fichier est en buffer sous emacs ???
> Surement pas je viens de tester avec ce fichier après avoir tué le
> buffer
> je retrouve le meme message ...
> Faut-il seulement le copier ???
>
> Et en effet il faut seulement le copier ...
> Quelqu'un peut-il me dire pourquoi ???
Ben pour ce qui est du fait que mv ne marche que sur un meme filesystem, c'
est vrai, j' ai essayé de faire mv sur deux partitions de mon disque dur (
les deux sont en ext2fs ), et ca marche.Par contre mv *.tar.gz /dos (
partition en fat 16 ) me donne la meme erreur.
>
>
> 3-- et pour finir :
> Comment peut-on faire pour que le CPU soit utilisé à fond ?? Est-ce
> utile d'abord (pour faire gagner du temps de calcul and so on ...) ??
Ben généralement, une application utilise le cpu à fond quand elle tourne,
mais elle utilise plus ou moins logntemps.
meme vi utilise ton processeur à fond :))
>
> Ce soir je viens de faire tourner gimp sur un fichier postcript et il
> ne m'a donné ma figure que toute petite et tronquée dans une grande
> feuille blanche alors qu'à la base elle prend l'ensemble de la feuille
> (je vous l'envoie ce sera plus simple que de tenter de la décrire).
> Bon y'avait déjà ce problème que je tentais de résoudre en augmentant
> la taille (width et height) (ah oui je suis en version gimp-1.0.1-2)
> en jouant sur l'antialiasing donc certains discutaient il y a peu et
> sur le nombre de pages...
faut faire gaffe , quand on applique l' antialiasing sur de gros docs, ça
peut durer longtemps.
> Enfin pas très productif, je me retrouve en 2500*4000 (de taille non
> !!! en tout cas sur un écran d'à peine 13 pouces et des bananes ça
> fait grand si grand (N'y aurait-il pas un moyen de dimensionner les
> fenetres que gimp ouvre au fur et à mesure des opérations ??))
> et là je crois enclencher la loupe je ne fais que croire car la
> fenetre trop grande m'empeche de voir le "gimp-tools" et en fait
> j'actionne autre chose (comme un déplacement de fenetre avec une croix
> à pointe de fleches)...
Normalement, si tu as windowmaker ( peux tu préciser quel window manager tu
utilises ? ), tu peux avoir plusieurs workspaces ( plusieurs bureaux quoi
!), he donc avoir les gimp tools sur un, et l' image sur l' autre.La
version 0.52.0 de WindowMaker est sorti.A prendre sur
http://www.windowmaker.ogr
>
> Big beans des tonnes de calcul se lance et qui tourne des minutes et
> des minutes ( pas le torchon hebdomadaire mais si j'avais dit des
> heures et des heures vous m'auriez pris pour un marseillais) je lance
> un top au bout de ma patience et là :
> 3:42am up 6:54, 3 users, load average: 1.73, 1.11, 0.68
> 41 processes: 39 sleeping, 2 running, 0 zombie, 0 stopped
> CPU states: 2.7% user, 4.2% system, 0.0% nice, 93.5% idle
^^^^^
C' est surement qu' un autre processus utilise des ressources, mais idle ,
je sais pas torp ce que c' est donc.Ton processeurs ne fénéante pas, il est
occupé par autre chose qui a plus d' importance que gimp ( l' attribution
des ressources est faite en fonction de l' importance du processu ou je me
trompe ? ).
>
>
> Mem: 14664K av, 14432K used, 232K free, 3272K shrd, 148K buff
> Swap: 104796K av, 23036K used, 81760K free 2048K
> cached
> Ah bin c'est tout de suite moins agréble à lire forcément...
> Alors je me dit que si au lieu de laisser fainéanter 93.5% des états
> CPU on les faisaient bosser un peu, déjà les autres seraient pas
> complètement crevés en fin de semaine et tout ça tout ça ...
> C'est utopique ou réalisable ???
Ben c' est tout à fait réalisable puisque j' y suis arrivé.
