Tel que promis, après nis petites discussions de cette semaine, je
fais mes petits tests :)
Je viens d'installer Xine avec swaret, qui fonctionne décidément mieux
que slapt-get. Comme il n'existe pas de version Xine pour Slack 9
sur les miroirs, j'ai pris celle pour 9.1. Après l'installation, au
lancement dans une console, j'ai reçu un message disant qu'il me
fallait la glibc-2.3.2.
Je l'ai installée. (Je suppose que la vraie commande aurait été
update, mais elle est bien là.) Maintenant, quand je tape la commande,
Xine ouvre, mais je reçois les messages d'erreur suivants:
# xine
This is xine (X11 gui) - a free video player v0.9.22.
(c) 2000-2003 The xine Team.
Built with xine library 1.0.0 (1-rc0a)
Found xine library version: 1.0.0 (1-rc0a).
XServer Vendor: The XFree86 Project, Inc. Release: 40300000,
Protocol Version: 11, Revision: 0,
Available Screen(s): 1, using 0
Depth: 24.
XShmQueryVersion: 1.1.
-[ xiTK version 0.10.5 [XMB]]-
-[ xiTK will use XShm ]-
-[ WM type: (EWMH) KWIN {KWin} ]-
Display is not using Xinerama.
main: probing <aadxr3> video output plugin
load_plugins: failed to load video output plugin <aadxr3>
main: probing <dxr3> video output plugin
load_plugins: failed to load video output plugin <dxr3>
main: probing <xv> video output plugin
main: probing <oss> audio output plugin
xine_interface: unknown param 10
xine_interface: unknown param 10
xine_interface: unknown param 10
xine_interface: unknown param 10
vo_scale: invalid ratio, using 4:3
vo_scale: unknown aspect ratio (0) in stream => using 4:3
--------------
Si je clique un fichier .asf (ou .asx) Xine ne démarre pas. Ex.:
http://src.ca/actualite/ZoneLibre/
Cliquer "Le reportage", puis une des caméras.
Quelqu'un a une idée?
Autre bizarrerie, mais qui n'a pas rapport. Chez linuxpackages,
plusieurs packages, sinon tous les plus récents, ont -i686 dans leur
nom. Or, Slackware compile le noyau -1486, le -i386 venant d'être
abandonné pour la version 9.1, je pense. Ça ne change rien?
Merci bien!
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
A partir du 2.4.24 pour la branche 2.4, et du 2.6.0 pour la branche 2.6.
Ben ca fait pas plusieurs annees ca !!
En stable, non. Mais C'EST stable, n'en doute pas. Les clusters 128 processeurs qui tournent en CXFS (clustered XFS) chez Total, au CEA, etc. sont là pour le montrer si nécessaire.
[quoted text muted] ?? qu'est ce qu tu racontes? Les benchmark sont une chose, mais quand les perfs sont 2 fois meilleures avec un FS qu'un autre...
Le seul FS qui, sur un meme materiel, a ete plusieurs fois plus rapide qu'un ext2, c'est de l'UFS sous FreeBSD en async. Ce n'est pas une question de limite de materiel, c'est sur un materiel identique.
Fort bien. Je n'ai pas testé UFS, mais sous Linux et de façon régulière, j'ai de bien meilleures perfs avec XFS et reiser qu'ext2 ou pire, ext3. A la fois dans des benchmarks effectués avec bonnie++ ou dd, comme en usage réel (serveur de fichier en charge, base de données, etc).
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <slrnbu8vuf.3hh.stephane@titanic.kirch>, stephane@unices.org
disait...
A partir du 2.4.24 pour la branche 2.4, et du 2.6.0 pour la branche 2.6.
Ben ca fait pas plusieurs annees ca !!
En stable, non. Mais C'EST stable, n'en doute pas. Les clusters 128
processeurs qui tournent en CXFS (clustered XFS) chez Total, au CEA,
etc. sont là pour le montrer si nécessaire.
[quoted text muted]
?? qu'est ce qu tu racontes? Les benchmark sont une chose, mais quand les
perfs sont 2 fois meilleures avec un FS qu'un autre...
Le seul FS qui, sur un meme materiel, a ete plusieurs fois plus rapide
qu'un ext2, c'est de l'UFS sous FreeBSD en async. Ce n'est pas une
question de limite de materiel, c'est sur un materiel identique.
Fort bien. Je n'ai pas testé UFS, mais sous Linux et de façon régulière,
j'ai de bien meilleures perfs avec XFS et reiser qu'ext2 ou pire, ext3. A
la fois dans des benchmarks effectués avec bonnie++ ou dd, comme en usage
réel (serveur de fichier en charge, base de données, etc).
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
A partir du 2.4.24 pour la branche 2.4, et du 2.6.0 pour la branche 2.6.
Ben ca fait pas plusieurs annees ca !!
En stable, non. Mais C'EST stable, n'en doute pas. Les clusters 128 processeurs qui tournent en CXFS (clustered XFS) chez Total, au CEA, etc. sont là pour le montrer si nécessaire.
[quoted text muted] ?? qu'est ce qu tu racontes? Les benchmark sont une chose, mais quand les perfs sont 2 fois meilleures avec un FS qu'un autre...
Le seul FS qui, sur un meme materiel, a ete plusieurs fois plus rapide qu'un ext2, c'est de l'UFS sous FreeBSD en async. Ce n'est pas une question de limite de materiel, c'est sur un materiel identique.
Fort bien. Je n'ai pas testé UFS, mais sous Linux et de façon régulière, j'ai de bien meilleures perfs avec XFS et reiser qu'ext2 ou pire, ext3. A la fois dans des benchmarks effectués avec bonnie++ ou dd, comme en usage réel (serveur de fichier en charge, base de données, etc).
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Stephane TOUGARD
Emmanuel Florac wrote:
En stable, non. Mais C'EST stable, n'en doute pas. Les clusters 128 processeurs qui tournent en CXFS (clustered XFS) chez Total, au CEA, etc. sont là pour le montrer si nécessaire.
Ben tout ca c'est bien, mais le fait que ce soit pas dans le noyau stable et que certaines fonctionnalites soit marquees (EXPERIMENTALE) suffisent a me convaincre que si je veux un FS stable sous Linux, ben je prendrai pas du XFS.
Fort bien. Je n'ai pas testé UFS, mais sous Linux et de façon régulière, j'ai de bien meilleures perfs avec XFS et reiser qu'ext2 ou pire, ext3. A la fois dans des benchmarks effectués avec bonnie++ ou dd, comme en usage réel (serveur de fichier en charge, base de données, etc).
Ben c'est bien, lorsque j'ai compare ReiserFS et ext2, ben aucun des deux n'a ete absolument meilleur et ext2 s'est montre plus regulier. J'y peux rien, pour moi, toute affirmation qui dirait haut et fort : ext2 est une bouse qui se fait eclater la gueule par ReiserFS, ben ca releve plus du dogme que de la chose demontree.
sur de l'ext3 :
titanic [/tmp] time for i in `seq 100000` ; do echo $i ; done > tt
real 0m9.103s user 0m7.060s sys 0m2.010s
Sur du reiserfs
titanic [~] time for i in `seq 100000` ; do echo $i ; done > ttt
real 0m9.131s user 0m7.090s sys 0m1.930s
Toujours sur du reiserfs
titanic [~/ttt] time for i in `seq 10000` ; do touch $i ; done
real 0m40.886s user 0m9.990s sys 0m30.000s titanic [~/ttt]
Et sur de l'ext3
titanic [/tmp/ttt] time for i in `seq 10000` ; do touch $i ; done
real 0m59.770s user 0m9.340s sys 0m49.290s
Et du JFS, mais lui est sur une carte SCSI alors que les deux autres sont en IDE.
titanic [/data/elair/ttt] time for i in `seq 10000` ; do touch $i ; done
real 0m47.628s user 0m10.410s sys 0m30.000s titanic [/data/elair/ttt]
C'est vrai, dans le pire des cas ext3 est moins bon que reiserfs et dans le meilleur il tient tout a fait la charge. Je n'ai pas de UFS sous la main pour faire le meme test. Dommage.
-- http://www.unices.org
Emmanuel Florac wrote:
En stable, non. Mais C'EST stable, n'en doute pas. Les clusters 128
processeurs qui tournent en CXFS (clustered XFS) chez Total, au CEA,
etc. sont là pour le montrer si nécessaire.
Ben tout ca c'est bien, mais le fait que ce soit pas dans le noyau
stable et que certaines fonctionnalites soit marquees (EXPERIMENTALE)
suffisent a me convaincre que si je veux un FS stable sous Linux, ben je
prendrai pas du XFS.
Fort bien. Je n'ai pas testé UFS, mais sous Linux et de façon régulière,
j'ai de bien meilleures perfs avec XFS et reiser qu'ext2 ou pire, ext3. A
la fois dans des benchmarks effectués avec bonnie++ ou dd, comme en usage
réel (serveur de fichier en charge, base de données, etc).
Ben c'est bien, lorsque j'ai compare ReiserFS et ext2, ben aucun des
deux n'a ete absolument meilleur et ext2 s'est montre plus regulier. J'y
peux rien, pour moi, toute affirmation qui dirait haut et fort : ext2 est
une bouse qui se fait eclater la gueule par ReiserFS, ben ca releve plus
du dogme que de la chose demontree.
sur de l'ext3 :
titanic [/tmp] time for i in `seq 100000` ; do echo $i ; done > tt
real 0m9.103s
user 0m7.060s
sys 0m2.010s
Sur du reiserfs
titanic [~] time for i in `seq 100000` ; do echo $i ; done > ttt
real 0m9.131s
user 0m7.090s
sys 0m1.930s
Toujours sur du reiserfs
titanic [~/ttt] time for i in `seq 10000` ; do touch $i ; done
real 0m40.886s
user 0m9.990s
sys 0m30.000s
titanic [~/ttt]
Et sur de l'ext3
titanic [/tmp/ttt] time for i in `seq 10000` ; do touch $i ; done
real 0m59.770s
user 0m9.340s
sys 0m49.290s
Et du JFS, mais lui est sur une carte SCSI alors que les deux autres
sont en IDE.
titanic [/data/elair/ttt] time for i in `seq 10000` ; do touch $i ; done
real 0m47.628s
user 0m10.410s
sys 0m30.000s
titanic [/data/elair/ttt]
C'est vrai, dans le pire des cas ext3 est moins bon que reiserfs et dans
le meilleur il tient tout a fait la charge. Je n'ai pas de UFS sous la
main pour faire le meme test. Dommage.
En stable, non. Mais C'EST stable, n'en doute pas. Les clusters 128 processeurs qui tournent en CXFS (clustered XFS) chez Total, au CEA, etc. sont là pour le montrer si nécessaire.
Ben tout ca c'est bien, mais le fait que ce soit pas dans le noyau stable et que certaines fonctionnalites soit marquees (EXPERIMENTALE) suffisent a me convaincre que si je veux un FS stable sous Linux, ben je prendrai pas du XFS.
Fort bien. Je n'ai pas testé UFS, mais sous Linux et de façon régulière, j'ai de bien meilleures perfs avec XFS et reiser qu'ext2 ou pire, ext3. A la fois dans des benchmarks effectués avec bonnie++ ou dd, comme en usage réel (serveur de fichier en charge, base de données, etc).
Ben c'est bien, lorsque j'ai compare ReiserFS et ext2, ben aucun des deux n'a ete absolument meilleur et ext2 s'est montre plus regulier. J'y peux rien, pour moi, toute affirmation qui dirait haut et fort : ext2 est une bouse qui se fait eclater la gueule par ReiserFS, ben ca releve plus du dogme que de la chose demontree.
sur de l'ext3 :
titanic [/tmp] time for i in `seq 100000` ; do echo $i ; done > tt
real 0m9.103s user 0m7.060s sys 0m2.010s
Sur du reiserfs
titanic [~] time for i in `seq 100000` ; do echo $i ; done > ttt
real 0m9.131s user 0m7.090s sys 0m1.930s
Toujours sur du reiserfs
titanic [~/ttt] time for i in `seq 10000` ; do touch $i ; done
real 0m40.886s user 0m9.990s sys 0m30.000s titanic [~/ttt]
Et sur de l'ext3
titanic [/tmp/ttt] time for i in `seq 10000` ; do touch $i ; done
real 0m59.770s user 0m9.340s sys 0m49.290s
Et du JFS, mais lui est sur une carte SCSI alors que les deux autres sont en IDE.
titanic [/data/elair/ttt] time for i in `seq 10000` ; do touch $i ; done
real 0m47.628s user 0m10.410s sys 0m30.000s titanic [/data/elair/ttt]
C'est vrai, dans le pire des cas ext3 est moins bon que reiserfs et dans le meilleur il tient tout a fait la charge. Je n'ai pas de UFS sous la main pour faire le meme test. Dommage.
-- http://www.unices.org
talon
Vincent Bernat wrote:
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers 11:19, (Michel Talon) disait:
Et bien ils feraient mieux de proposer au moins la vitesse de Windows en standard. Parceque depuis que j'ai des machines rapides je ne me rendais plus compte, mais la Mandrake 9.2 sur un PII 300 ( avec quand même 256 Megs de mémoire) c'est exaspérant à un point inimaginable. Au point d'attendre 30s pour une Konsole, et pas de xterm en standard.
Il y a sans doute un problème un peu plus important sur cette installation pour nécessiter 30 secondes pour une console. Un serveur de fontes en rade, localhost qui n'est pas monté ou que sais-je encore.
Je pense que tu as raison, mais le PC je l'ai donné ce midi au destinataire final, et je n'ai pas eu plus de temps pour vérifier d'où venait le pb, alors que l'installation est totalement standard. J'ai juste vérifié qu'on voyait les disques, que le zip se montait correctement et que les cartes réseau étaient configurées comme il faut. J'ai booté Knoppix sur ce PC et ça ne m'avait pas paru spécialement calamiteux. En tout cas WinXP lui, s'est installé comme une fleur et tourne à vitesse raisonnable compte tenu de la fréquence de la bête. J'ai aussi perdu du temps avec la carte son qui est une Aureal Vortex, j'avais réussi à compiler le module son OK sous Knoppix, et évidemment sous Mandrake ça a merdé avec le nouveau compilateur, ou je ne sais quoi dans leur noyau patché. Je hais ces noyaux patchés contre lesquels on ne peut rien compiler comme il faut. J'avais testé Mandrake sous vmware, ça m'avait paru correct, mais là sur une machine concrète, ça tourne franchement au vinaigre. Si j'avais su j'aurais installé tout bêtement la Knoppix et m'en serais sorti avec beaucoup moins d'ennuis.
--
Michel TALON
Vincent Bernat <vince@khabale.org> wrote:
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers
11:19, talon@lpthe.jussieu.fr (Michel Talon) disait:
Et bien ils feraient mieux de proposer au moins la vitesse de
Windows en standard. Parceque depuis que j'ai des machines rapides
je ne me rendais plus compte, mais la Mandrake 9.2 sur un PII 300 (
avec quand même 256 Megs de mémoire) c'est exaspérant à un point
inimaginable. Au point d'attendre 30s pour une Konsole, et pas de
xterm en standard.
Il y a sans doute un problème un peu plus important sur cette
installation pour nécessiter 30 secondes pour une console. Un serveur
de fontes en rade, localhost qui n'est pas monté ou que sais-je
encore.
Je pense que tu as raison, mais le PC je l'ai donné ce midi au
destinataire final, et je n'ai pas eu plus de temps pour vérifier d'où
venait le pb, alors que l'installation est totalement standard. J'ai
juste vérifié qu'on voyait les disques, que le zip se montait
correctement et que les cartes réseau étaient configurées comme il faut.
J'ai booté Knoppix sur ce PC et ça ne m'avait pas paru spécialement
calamiteux. En tout cas WinXP lui, s'est installé comme une fleur et
tourne à vitesse raisonnable compte tenu de la fréquence de la bête.
J'ai aussi perdu du temps avec la carte son qui est une Aureal Vortex,
j'avais réussi à compiler le module son OK sous Knoppix, et évidemment
sous Mandrake ça a merdé avec le nouveau compilateur, ou je ne sais quoi
dans leur noyau patché. Je hais ces noyaux patchés contre lesquels on ne
peut rien compiler comme il faut. J'avais testé Mandrake sous vmware, ça
m'avait paru correct, mais là sur une machine concrète, ça tourne
franchement au vinaigre. Si j'avais su j'aurais installé tout bêtement
la Knoppix et m'en serais sorti avec beaucoup moins d'ennuis.
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers 11:19, (Michel Talon) disait:
Et bien ils feraient mieux de proposer au moins la vitesse de Windows en standard. Parceque depuis que j'ai des machines rapides je ne me rendais plus compte, mais la Mandrake 9.2 sur un PII 300 ( avec quand même 256 Megs de mémoire) c'est exaspérant à un point inimaginable. Au point d'attendre 30s pour une Konsole, et pas de xterm en standard.
Il y a sans doute un problème un peu plus important sur cette installation pour nécessiter 30 secondes pour une console. Un serveur de fontes en rade, localhost qui n'est pas monté ou que sais-je encore.
Je pense que tu as raison, mais le PC je l'ai donné ce midi au destinataire final, et je n'ai pas eu plus de temps pour vérifier d'où venait le pb, alors que l'installation est totalement standard. J'ai juste vérifié qu'on voyait les disques, que le zip se montait correctement et que les cartes réseau étaient configurées comme il faut. J'ai booté Knoppix sur ce PC et ça ne m'avait pas paru spécialement calamiteux. En tout cas WinXP lui, s'est installé comme une fleur et tourne à vitesse raisonnable compte tenu de la fréquence de la bête. J'ai aussi perdu du temps avec la carte son qui est une Aureal Vortex, j'avais réussi à compiler le module son OK sous Knoppix, et évidemment sous Mandrake ça a merdé avec le nouveau compilateur, ou je ne sais quoi dans leur noyau patché. Je hais ces noyaux patchés contre lesquels on ne peut rien compiler comme il faut. J'avais testé Mandrake sous vmware, ça m'avait paru correct, mais là sur une machine concrète, ça tourne franchement au vinaigre. Si j'avais su j'aurais installé tout bêtement la Knoppix et m'en serais sorti avec beaucoup moins d'ennuis.
--
Michel TALON
Vincent Bernat
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers 11:30, GP disait:
Ben si s'est si, il y a un gros problème côté Windows et je me demande comment il se fait qu'on ne sert pas cet argument plus souvent en faveur de Linux. On dit que Windows est un système facile à installer et opérer et voilà qu'on fait suer le burnous à tonton newbie parce qu'on ne veut pas lui fournir l'outil adéquat, lequel n'en est qu'un parmi tant d'autres, auquel on ne pense même pas, sur Linux.
Je ne comprends pas trop ce fil. Windows dispose d'un serveur DHCP qui vient avec le partage de connexion et est activé automatiquement quand on désire partager la connexion. Il vient aussi avec un serveur de DNS simpliste pour les mêmes raisons et des capacités NAT adé- quates. Évidemment, le bidule n'est absolument pas configurable. Faut pas pousser. -- die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers
11:30, GP <gilpel@inverse.nretla.org> disait:
Ben si s'est si, il y a un gros problème côté Windows et je me
demande comment il se fait qu'on ne sert pas cet argument plus
souvent en faveur de Linux. On dit que Windows est un système facile
à installer et opérer et voilà qu'on fait suer le burnous à tonton
newbie parce qu'on ne veut pas lui fournir l'outil adéquat, lequel
n'en est qu'un parmi tant d'autres, auquel on ne pense même pas, sur
Linux.
Je ne comprends pas trop ce fil. Windows dispose d'un serveur DHCP qui
vient avec le partage de connexion et est activé automatiquement quand
on désire partager la connexion. Il vient aussi avec un serveur de DNS
simpliste pour les mêmes raisons et des capacités NAT adé-
quates. Évidemment, le bidule n'est absolument pas configurable. Faut
pas pousser.
--
die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers 11:30, GP disait:
Ben si s'est si, il y a un gros problème côté Windows et je me demande comment il se fait qu'on ne sert pas cet argument plus souvent en faveur de Linux. On dit que Windows est un système facile à installer et opérer et voilà qu'on fait suer le burnous à tonton newbie parce qu'on ne veut pas lui fournir l'outil adéquat, lequel n'en est qu'un parmi tant d'autres, auquel on ne pense même pas, sur Linux.
Je ne comprends pas trop ce fil. Windows dispose d'un serveur DHCP qui vient avec le partage de connexion et est activé automatiquement quand on désire partager la connexion. Il vient aussi avec un serveur de DNS simpliste pour les mêmes raisons et des capacités NAT adé- quates. Évidemment, le bidule n'est absolument pas configurable. Faut pas pousser. -- die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
talon
Vincent Bernat wrote:
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers 11:22, (Michel Talon) disait:
Ah, ça veut juste dire que tu peux pas activer le DMA sur un périphérique contrôlé par ide-scsi _via_ la couche SCSI (avec hdparm par exemple). Rien ne t'empêche de l'activer via la couche IDE : echo using_dma:1 > /proc/ide/hdb/settings La baisse d'occupation proc prouve que cela marche.
Non, non ce n'est pas ce que j'ai lu, ou tout au moins compris. Les transfers de données passant par la couche ide-scsi sont tous programmés en PIO. En fait l'étaient, car d'aprés ce que j'ai lu aussi, ceci aurait été modifié dans les 2.4.* les plus récents.
Cela fait 3 ans que j'ai un graveur sur IDE dans ma machine et cela fait 3 ans que j'active le DMA comme je l'ai indiqué. Quand j'oubliais, c'était flagrant, la machine se figeait littéralement le temps du gravage.
J'utilise également le lecteur de DVD en émulation SCSI (parce que c'est aussi mon lecteur de CD et que pas mal de logiciels veulent parler SCSI, comme cdparanoia). Il est impossible de regarder un DVD sur une machine de puissance modeste sans activer le DMA.
Bizarre: -un, mon lecteur de DVD marche sous Windows en PIO (pour une raison bizarre Windows refuse de le mettre en DMA) et pourtant, il marche. -deux, encore en 2002 il y avait des corrections de bugs dans le kernel 2.5 pour le module ide-scsi qui mettait la zone quand le CD était en UDMA http://www.cs.helsinki.fi/linux/linux-kernel/2002-22/0571.html En fait une recherche sur google montre un tas de gens qui ont des problèmes sévères avec l'UDMA et ide-scsi en 2002. Et je vois bien sur un kernel 2.6 le message suivant: kernel: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device Et aussi: | "somebody" strongly felt that ide-scsi was not just ugly but _evil_, | and that the syntax and usage of "cdrecord" was absolutely stupid. | | That somebody was me.
- Linus Torvalds
--
Michel TALON
Vincent Bernat <vincent.bernat@raysa.org> wrote:
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers
11:22, talon@lpthe.jussieu.fr (Michel Talon) disait:
Ah, ça veut juste dire que tu peux pas activer le DMA sur un
périphérique contrôlé par ide-scsi _via_ la couche SCSI (avec hdparm
par exemple). Rien ne t'empêche de l'activer via la couche IDE :
echo using_dma:1 > /proc/ide/hdb/settings
La baisse d'occupation proc prouve que cela marche.
Non, non ce n'est pas ce que j'ai lu, ou tout au moins compris. Les
transfers de données passant par la couche ide-scsi sont tous
programmés en PIO. En fait l'étaient, car d'aprés ce que j'ai lu
aussi, ceci aurait été modifié dans les 2.4.* les plus récents.
Cela fait 3 ans que j'ai un graveur sur IDE dans ma machine et cela
fait 3 ans que j'active le DMA comme je l'ai indiqué. Quand
j'oubliais, c'était flagrant, la machine se figeait littéralement le
temps du gravage.
J'utilise également le lecteur de DVD en émulation SCSI (parce que
c'est aussi mon lecteur de CD et que pas mal de logiciels veulent
parler SCSI, comme cdparanoia). Il est impossible de regarder un DVD
sur une machine de puissance modeste sans activer le DMA.
Bizarre:
-un, mon lecteur de DVD marche sous Windows en PIO (pour une raison
bizarre Windows refuse de le mettre en DMA) et pourtant, il marche.
-deux, encore en 2002 il y avait des corrections de bugs dans le
kernel 2.5 pour le module ide-scsi qui mettait la zone quand
le CD était en UDMA
http://www.cs.helsinki.fi/linux/linux-kernel/2002-22/0571.html
En fait une recherche sur google montre un tas de gens qui ont des
problèmes sévères avec l'UDMA et ide-scsi en 2002.
Et je vois bien sur un kernel 2.6 le message suivant:
kernel: ide-scsi is deprecated for cd burning! Use
ide-cd and give dev=/dev/hdX as device
Et aussi:
| "somebody" strongly felt that ide-scsi was not just ugly but _evil_,
| and that the syntax and usage of "cdrecord" was absolutely stupid.
|
| That somebody was me.
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers 11:22, (Michel Talon) disait:
Ah, ça veut juste dire que tu peux pas activer le DMA sur un périphérique contrôlé par ide-scsi _via_ la couche SCSI (avec hdparm par exemple). Rien ne t'empêche de l'activer via la couche IDE : echo using_dma:1 > /proc/ide/hdb/settings La baisse d'occupation proc prouve que cela marche.
Non, non ce n'est pas ce que j'ai lu, ou tout au moins compris. Les transfers de données passant par la couche ide-scsi sont tous programmés en PIO. En fait l'étaient, car d'aprés ce que j'ai lu aussi, ceci aurait été modifié dans les 2.4.* les plus récents.
Cela fait 3 ans que j'ai un graveur sur IDE dans ma machine et cela fait 3 ans que j'active le DMA comme je l'ai indiqué. Quand j'oubliais, c'était flagrant, la machine se figeait littéralement le temps du gravage.
J'utilise également le lecteur de DVD en émulation SCSI (parce que c'est aussi mon lecteur de CD et que pas mal de logiciels veulent parler SCSI, comme cdparanoia). Il est impossible de regarder un DVD sur une machine de puissance modeste sans activer le DMA.
Bizarre: -un, mon lecteur de DVD marche sous Windows en PIO (pour une raison bizarre Windows refuse de le mettre en DMA) et pourtant, il marche. -deux, encore en 2002 il y avait des corrections de bugs dans le kernel 2.5 pour le module ide-scsi qui mettait la zone quand le CD était en UDMA http://www.cs.helsinki.fi/linux/linux-kernel/2002-22/0571.html En fait une recherche sur google montre un tas de gens qui ont des problèmes sévères avec l'UDMA et ide-scsi en 2002. Et je vois bien sur un kernel 2.6 le message suivant: kernel: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device Et aussi: | "somebody" strongly felt that ide-scsi was not just ugly but _evil_, | and that the syntax and usage of "cdrecord" was absolutely stupid. | | That somebody was me.
- Linus Torvalds
--
Michel TALON
talon
Stephane TOUGARD wrote:
Ben c'est bien, lorsque j'ai compare ReiserFS et ext2, ben aucun des deux n'a ete absolument meilleur et ext2 s'est montre plus regulier. J'y peux rien, pour moi, toute affirmation qui dirait haut et fort : ext2 est une bouse qui se fait eclater la gueule par ReiserFS, ben ca releve plus du dogme que de la chose demontree.
J'ai pas dit que ext2 était une "bouse qui .." j'ai dit que ext3 était une "bouse qui ..." chose démontrée par tous les benchmarks que j'ai pu voir et qui font un peu plus quelque chose que le tien. Sans parler que ton bench oublie complètement de tenir compte de ce que Linux garde en cache et n'écrit pas sur le disque. Tu fais plus une mesure de l'accés au buffer cache que de l'accés au disque. Comme Reiserfs XFS et JFS font des choses bien plus sophistiquées dans le kernel que ext2 il est fort possible que tu obtiennes ainsi des résultats complètement à l'opposé de ce que donnerait une utilisation concréte accédant au disque. Il est notoire que ext2 est autant ou plus rapide que tous les sytèmes journalisés, sauf qu'il assure une sécurité *NULLE* en cas de panne, ce qui le disqualifie radicalement pour un usage dans un serveur. Le système qui à la fois bufferise un maximum en mémoire comme ext2 tout en assurant des écritures consistantes sur disque est softupdates de FreeBSD. Inutile de dire que ça suppose un maximum d'activité au niveau du noyau et donc si tu fais tourner ça sur une brouette, mais dotée de disques SCSI rapides, tu vas trouver que UFS+softupdates est plus lent que, disons ext3, qui lui va écrire sans arrêt sur le disque pour journaliser tout ce qu'il voit passer sous le nez dés que ça lui arrive. Tout le point c'est que la puissance de calcul et la mémoire augmentent plus vite que les temps de latence des disques, et donc il y a intérêt à faire un maximum de choses en mémoire et écrire un minimum sur le disque, ce qui avantage Reiserfs et softupdates.
--
Michel TALON
Stephane TOUGARD <stephane@unices.org> wrote:
Ben c'est bien, lorsque j'ai compare ReiserFS et ext2, ben aucun des
deux n'a ete absolument meilleur et ext2 s'est montre plus regulier. J'y
peux rien, pour moi, toute affirmation qui dirait haut et fort : ext2 est
une bouse qui se fait eclater la gueule par ReiserFS, ben ca releve plus
du dogme que de la chose demontree.
J'ai pas dit que ext2 était une "bouse qui .." j'ai dit que ext3 était
une "bouse qui ..." chose démontrée par tous les benchmarks que j'ai pu
voir et qui font un peu plus quelque chose que le tien. Sans parler que
ton bench oublie complètement de tenir compte de ce que Linux garde en
cache et n'écrit pas sur le disque. Tu fais plus une mesure de l'accés au
buffer cache que de l'accés au disque. Comme Reiserfs XFS et JFS font
des choses bien plus sophistiquées dans le kernel que ext2 il est fort
possible que tu obtiennes ainsi des résultats complètement à l'opposé de
ce que donnerait une utilisation concréte accédant au disque.
Il est notoire que ext2 est autant ou plus rapide que tous les sytèmes
journalisés, sauf qu'il assure une sécurité *NULLE* en cas de panne, ce
qui le disqualifie radicalement pour un usage dans un serveur.
Le système qui à la fois bufferise un maximum en mémoire comme ext2 tout
en assurant des écritures consistantes sur disque est softupdates de
FreeBSD. Inutile de dire que ça suppose un maximum d'activité au niveau
du noyau et donc si tu fais tourner ça sur une brouette, mais dotée
de disques SCSI rapides, tu vas trouver que UFS+softupdates est plus lent
que, disons ext3, qui lui va écrire sans arrêt sur le disque pour
journaliser tout ce qu'il voit passer sous le nez dés que ça lui arrive.
Tout le point c'est que la puissance de calcul et la mémoire augmentent
plus vite que les temps de latence des disques, et donc il y a intérêt
à faire un maximum de choses en mémoire et écrire un minimum sur le
disque, ce qui avantage Reiserfs et softupdates.
Ben c'est bien, lorsque j'ai compare ReiserFS et ext2, ben aucun des deux n'a ete absolument meilleur et ext2 s'est montre plus regulier. J'y peux rien, pour moi, toute affirmation qui dirait haut et fort : ext2 est une bouse qui se fait eclater la gueule par ReiserFS, ben ca releve plus du dogme que de la chose demontree.
J'ai pas dit que ext2 était une "bouse qui .." j'ai dit que ext3 était une "bouse qui ..." chose démontrée par tous les benchmarks que j'ai pu voir et qui font un peu plus quelque chose que le tien. Sans parler que ton bench oublie complètement de tenir compte de ce que Linux garde en cache et n'écrit pas sur le disque. Tu fais plus une mesure de l'accés au buffer cache que de l'accés au disque. Comme Reiserfs XFS et JFS font des choses bien plus sophistiquées dans le kernel que ext2 il est fort possible que tu obtiennes ainsi des résultats complètement à l'opposé de ce que donnerait une utilisation concréte accédant au disque. Il est notoire que ext2 est autant ou plus rapide que tous les sytèmes journalisés, sauf qu'il assure une sécurité *NULLE* en cas de panne, ce qui le disqualifie radicalement pour un usage dans un serveur. Le système qui à la fois bufferise un maximum en mémoire comme ext2 tout en assurant des écritures consistantes sur disque est softupdates de FreeBSD. Inutile de dire que ça suppose un maximum d'activité au niveau du noyau et donc si tu fais tourner ça sur une brouette, mais dotée de disques SCSI rapides, tu vas trouver que UFS+softupdates est plus lent que, disons ext3, qui lui va écrire sans arrêt sur le disque pour journaliser tout ce qu'il voit passer sous le nez dés que ça lui arrive. Tout le point c'est que la puissance de calcul et la mémoire augmentent plus vite que les temps de latence des disques, et donc il y a intérêt à faire un maximum de choses en mémoire et écrire un minimum sur le disque, ce qui avantage Reiserfs et softupdates.
--
Michel TALON
talon
Vincent Bernat wrote:
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers 11:30, GP disait:
Ben si s'est si, il y a un gros problème côté Windows et je me demande comment il se fait qu'on ne sert pas cet argument plus souvent en faveur de Linux. On dit que Windows est un système facile à installer et opérer et voilà qu'on fait suer le burnous à tonton newbie parce qu'on ne veut pas lui fournir l'outil adéquat, lequel n'en est qu'un parmi tant d'autres, auquel on ne pense même pas, sur Linux.
Je ne comprends pas trop ce fil. Windows dispose d'un serveur DHCP qui vient avec le partage de connexion et est activé automatiquement quand on désire partager la connexion. Il vient aussi avec un serveur de DNS simpliste pour les mêmes raisons et des capacités NAT adé- quates. Évidemment, le bidule n'est absolument pas configurable. Faut pas pousser.
Il vient même avec un firewall à état, qui marche raisonnablement, et l'ensemble permet effectivement de partager une connexion sur l'extérieur sans se prendre la tête, et tout particulièrement quand le modem a un bon driver sous Windows et un mauvais sur Linux (exemple le Sagem Fast 800). Toujours est-il que chez moi ce dispositif marche parfaitement depuis longtemps. Et que la machine tourne des jours et des jours sans planter. Si bien que les conneries grossières sur "Windaube" ne font que discréditer les partisans de Linux.
--
Michel TALON
Vincent Bernat <vincent.bernat@raysa.org> wrote:
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers
11:30, GP <gilpel@inverse.nretla.org> disait:
Ben si s'est si, il y a un gros problème côté Windows et je me
demande comment il se fait qu'on ne sert pas cet argument plus
souvent en faveur de Linux. On dit que Windows est un système facile
à installer et opérer et voilà qu'on fait suer le burnous à tonton
newbie parce qu'on ne veut pas lui fournir l'outil adéquat, lequel
n'en est qu'un parmi tant d'autres, auquel on ne pense même pas, sur
Linux.
Je ne comprends pas trop ce fil. Windows dispose d'un serveur DHCP qui
vient avec le partage de connexion et est activé automatiquement quand
on désire partager la connexion. Il vient aussi avec un serveur de DNS
simpliste pour les mêmes raisons et des capacités NAT adé-
quates. Évidemment, le bidule n'est absolument pas configurable. Faut
pas pousser.
Il vient même avec un firewall à état, qui marche raisonnablement, et
l'ensemble permet effectivement de partager une connexion sur
l'extérieur sans se prendre la tête, et tout particulièrement quand le
modem a un bon driver sous Windows et un mauvais sur Linux (exemple
le Sagem Fast 800). Toujours est-il que chez moi ce dispositif marche
parfaitement depuis longtemps. Et que la machine tourne des jours et des
jours sans planter. Si bien que les conneries grossières sur "Windaube"
ne font que discréditer les partisans de Linux.
OoO En cette fin de matinée radieuse du samedi 20 décembre 2003, vers 11:30, GP disait:
Ben si s'est si, il y a un gros problème côté Windows et je me demande comment il se fait qu'on ne sert pas cet argument plus souvent en faveur de Linux. On dit que Windows est un système facile à installer et opérer et voilà qu'on fait suer le burnous à tonton newbie parce qu'on ne veut pas lui fournir l'outil adéquat, lequel n'en est qu'un parmi tant d'autres, auquel on ne pense même pas, sur Linux.
Je ne comprends pas trop ce fil. Windows dispose d'un serveur DHCP qui vient avec le partage de connexion et est activé automatiquement quand on désire partager la connexion. Il vient aussi avec un serveur de DNS simpliste pour les mêmes raisons et des capacités NAT adé- quates. Évidemment, le bidule n'est absolument pas configurable. Faut pas pousser.
Il vient même avec un firewall à état, qui marche raisonnablement, et l'ensemble permet effectivement de partager une connexion sur l'extérieur sans se prendre la tête, et tout particulièrement quand le modem a un bon driver sous Windows et un mauvais sur Linux (exemple le Sagem Fast 800). Toujours est-il que chez moi ce dispositif marche parfaitement depuis longtemps. Et que la machine tourne des jours et des jours sans planter. Si bien que les conneries grossières sur "Windaube" ne font que discréditer les partisans de Linux.
--
Michel TALON
Vincent Bernat
OoO Peu avant le début de l'après-midi du samedi 20 décembre 2003, vers 13:30, (Michel Talon) disait:
-un, mon lecteur de DVD marche sous Windows en PIO (pour une raison bizarre Windows refuse de le mettre en DMA) et pourtant, il marche.
Tu as une machine puissante (surtout vu que tu appelles un PII 350 une antiquité).
-deux, encore en 2002 il y avait des corrections de bugs dans le kernel 2.5 pour le module ide-scsi qui mettait la zone quand le CD était en UDMA http://www.cs.helsinki.fi/linux/linux-kernel/2002-22/0571.html En fait une recherche sur google montre un tas de gens qui ont des problèmes sévères avec l'UDMA et ide-scsi en 2002.
Oui, j'en suis également persuadé. Pour ma part, l'activation de l'UDMA se fait comme ça :
,---- | alias scsi_hostadapter ide-scsi | options ide-cd ignore=hda | # C'est un peu le bazar, on active le DMA apres tout, comme ca, c'est plus | # sur. On espere bien fort qu'il n'y a pas de race condition dans le lot. | post-install ide-scsi echo "using_dma:1 io_32bit:1" > /proc/ide/hda/settings | post-install sr_mod echo "using_dma:1 io_32bit:1" > /proc/ide/hda/settings | post-install sg echo "using_dma:1 io_32bit:1" > /proc/ide/hda/settings `----
Je ne me suis pas cassé la tête à savoir laquelle était le plus indispensable. Le DMA est désactivé au boot et l'ide-scsi est en effet capricieux là-dessus. Au final, le DMA était activé et c'est ce qui m'importait.
Et je vois bien sur un kernel 2.6 le message suivant: kernel: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
Chez moi, ça fait un beau kernel panic. Au moins, l'ide-scsi est plus ou moins éprouvé même si, c'est là tout le problème, personne ne s'est soucié à le remettre à niveau pour le 2.6. Il reste de plus indispensable pour d'autres opérations (mais là aussi, cela évolue).
Et aussi: | "somebody" strongly felt that ide-scsi was not just ugly but _evil_, | and that the syntax and usage of "cdrecord" was absolutely stupid. | | That somebody was me.
- Linus Torvalds
On peut citer aussi certains développeurs de FreeBSD. N'empêche, en attendant, l'ide-scsi faisait son boulot et continue à le faire dans plusieurs domaines. La possibilité de graver en IDE est plutôt pour moi un gadget puisque je n'ai jamais eu de gros problèmes avec l'ide-scsi et je n'en ai pas constaté non plus chez d'autres personnes (les problèmes de DMA se réglaient comme indiqués ci-dessus).
Que les développeurs aient à en redire sur le design, c'est bien leur boulot. -- I WILL NOT BURY THE NEW KID I WILL NOT BURY THE NEW KID I WILL NOT BURY THE NEW KID -+- Bart Simpson on chalkboard in episode 9F03
OoO Peu avant le début de l'après-midi du samedi 20 décembre 2003,
vers 13:30, talon@lpthe.jussieu.fr (Michel Talon) disait:
-un, mon lecteur de DVD marche sous Windows en PIO (pour une raison
bizarre Windows refuse de le mettre en DMA) et pourtant, il marche.
Tu as une machine puissante (surtout vu que tu appelles un PII 350 une
antiquité).
-deux, encore en 2002 il y avait des corrections de bugs dans le
kernel 2.5 pour le module ide-scsi qui mettait la zone quand le CD
était en UDMA
http://www.cs.helsinki.fi/linux/linux-kernel/2002-22/0571.html En
fait une recherche sur google montre un tas de gens qui ont des
problèmes sévères avec l'UDMA et ide-scsi en 2002.
Oui, j'en suis également persuadé. Pour ma part, l'activation de
l'UDMA se fait comme ça :
,----
| alias scsi_hostadapter ide-scsi
| options ide-cd ignore=hda
| # C'est un peu le bazar, on active le DMA apres tout, comme ca, c'est plus
| # sur. On espere bien fort qu'il n'y a pas de race condition dans le lot.
| post-install ide-scsi echo "using_dma:1 io_32bit:1" > /proc/ide/hda/settings
| post-install sr_mod echo "using_dma:1 io_32bit:1" > /proc/ide/hda/settings
| post-install sg echo "using_dma:1 io_32bit:1" > /proc/ide/hda/settings
`----
Je ne me suis pas cassé la tête à savoir laquelle était le plus
indispensable. Le DMA est désactivé au boot et l'ide-scsi est en effet
capricieux là-dessus. Au final, le DMA était activé et c'est ce qui
m'importait.
Et je vois bien sur un kernel 2.6 le message suivant:
kernel: ide-scsi is deprecated for cd burning! Use ide-cd and give
dev=/dev/hdX as device
Chez moi, ça fait un beau kernel panic. Au moins, l'ide-scsi est plus
ou moins éprouvé même si, c'est là tout le problème, personne ne s'est
soucié à le remettre à niveau pour le 2.6. Il reste de plus
indispensable pour d'autres opérations (mais là aussi, cela évolue).
Et aussi:
| "somebody" strongly felt that ide-scsi was not just ugly but _evil_,
| and that the syntax and usage of "cdrecord" was absolutely stupid.
|
| That somebody was me.
- Linus Torvalds
On peut citer aussi certains développeurs de FreeBSD. N'empêche, en
attendant, l'ide-scsi faisait son boulot et continue à le faire dans
plusieurs domaines. La possibilité de graver en IDE est plutôt pour
moi un gadget puisque je n'ai jamais eu de gros problèmes avec
l'ide-scsi et je n'en ai pas constaté non plus chez d'autres personnes
(les problèmes de DMA se réglaient comme indiqués ci-dessus).
Que les développeurs aient à en redire sur le design, c'est bien leur
boulot.
--
I WILL NOT BURY THE NEW KID
I WILL NOT BURY THE NEW KID
I WILL NOT BURY THE NEW KID
-+- Bart Simpson on chalkboard in episode 9F03
OoO Peu avant le début de l'après-midi du samedi 20 décembre 2003, vers 13:30, (Michel Talon) disait:
-un, mon lecteur de DVD marche sous Windows en PIO (pour une raison bizarre Windows refuse de le mettre en DMA) et pourtant, il marche.
Tu as une machine puissante (surtout vu que tu appelles un PII 350 une antiquité).
-deux, encore en 2002 il y avait des corrections de bugs dans le kernel 2.5 pour le module ide-scsi qui mettait la zone quand le CD était en UDMA http://www.cs.helsinki.fi/linux/linux-kernel/2002-22/0571.html En fait une recherche sur google montre un tas de gens qui ont des problèmes sévères avec l'UDMA et ide-scsi en 2002.
Oui, j'en suis également persuadé. Pour ma part, l'activation de l'UDMA se fait comme ça :
,---- | alias scsi_hostadapter ide-scsi | options ide-cd ignore=hda | # C'est un peu le bazar, on active le DMA apres tout, comme ca, c'est plus | # sur. On espere bien fort qu'il n'y a pas de race condition dans le lot. | post-install ide-scsi echo "using_dma:1 io_32bit:1" > /proc/ide/hda/settings | post-install sr_mod echo "using_dma:1 io_32bit:1" > /proc/ide/hda/settings | post-install sg echo "using_dma:1 io_32bit:1" > /proc/ide/hda/settings `----
Je ne me suis pas cassé la tête à savoir laquelle était le plus indispensable. Le DMA est désactivé au boot et l'ide-scsi est en effet capricieux là-dessus. Au final, le DMA était activé et c'est ce qui m'importait.
Et je vois bien sur un kernel 2.6 le message suivant: kernel: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
Chez moi, ça fait un beau kernel panic. Au moins, l'ide-scsi est plus ou moins éprouvé même si, c'est là tout le problème, personne ne s'est soucié à le remettre à niveau pour le 2.6. Il reste de plus indispensable pour d'autres opérations (mais là aussi, cela évolue).
Et aussi: | "somebody" strongly felt that ide-scsi was not just ugly but _evil_, | and that the syntax and usage of "cdrecord" was absolutely stupid. | | That somebody was me.
- Linus Torvalds
On peut citer aussi certains développeurs de FreeBSD. N'empêche, en attendant, l'ide-scsi faisait son boulot et continue à le faire dans plusieurs domaines. La possibilité de graver en IDE est plutôt pour moi un gadget puisque je n'ai jamais eu de gros problèmes avec l'ide-scsi et je n'en ai pas constaté non plus chez d'autres personnes (les problèmes de DMA se réglaient comme indiqués ci-dessus).
Que les développeurs aient à en redire sur le design, c'est bien leur boulot. -- I WILL NOT BURY THE NEW KID I WILL NOT BURY THE NEW KID I WILL NOT BURY THE NEW KID -+- Bart Simpson on chalkboard in episode 9F03
Vincent Bernat
OoO En ce début d'après-midi nuageux du samedi 20 décembre 2003, vers 14:14, (Michel Talon) disait:
Il est notoire que ext2 est autant ou plus rapide que tous les sytèmes journalisés, sauf qu'il assure une sécurité *NULLE* en cas de panne, ce qui le disqualifie radicalement pour un usage dans un serveur.
Tss, tss, il suffit bien sûr d'utiliser un onduleur. Cesse donc d'être aussi réducteur. -- /* * We used to try various strange things. Let's not. */ 2.2.16 /usr/src/linux/fs/buffer.c
OoO En ce début d'après-midi nuageux du samedi 20 décembre 2003, vers
14:14, talon@lpthe.jussieu.fr (Michel Talon) disait:
Il est notoire que ext2 est autant ou plus rapide que tous les
sytèmes journalisés, sauf qu'il assure une sécurité *NULLE* en cas
de panne, ce qui le disqualifie radicalement pour un usage dans un
serveur.
Tss, tss, il suffit bien sûr d'utiliser un onduleur. Cesse donc d'être
aussi réducteur.
--
/*
* We used to try various strange things. Let's not.
*/
2.2.16 /usr/src/linux/fs/buffer.c
OoO En ce début d'après-midi nuageux du samedi 20 décembre 2003, vers 14:14, (Michel Talon) disait:
Il est notoire que ext2 est autant ou plus rapide que tous les sytèmes journalisés, sauf qu'il assure une sécurité *NULLE* en cas de panne, ce qui le disqualifie radicalement pour un usage dans un serveur.
Tss, tss, il suffit bien sûr d'utiliser un onduleur. Cesse donc d'être aussi réducteur. -- /* * We used to try various strange things. Let's not. */ 2.2.16 /usr/src/linux/fs/buffer.c
Alain Labarthe
Le 19-12-2003, GP écrivait:
Alain Labarthe wrote:
Le 19-12-2003, GP écrivait:
Je crainds que non. Tree ne donne que la dimension des fichiers. Pourtant, il y a moyen de le faire, puisque KDE la donne dasn properties.
man du? du -h /etc du -skh /etc
Un bon point pour vous, élève Labarthe. On va dire comme on dit, il était temps! Inscrit dasn mon grand livre du didacticiel à venir. (J'espère que d'autres font de même: tout d'un coup que la prochaine épidémie de SRAS m'emporterait...)
Avant que le SRAS ne vous emporte cher maître, je ne saurais trop
vous conseiller de poster toute demande technique sur le forum idoine, au risque de réponses oiseuses...
-- apt-get --purge remove Bush
Le 19-12-2003, GP écrivait:
Alain Labarthe wrote:
Le 19-12-2003, GP écrivait:
Je crainds que non. Tree ne donne que la dimension des fichiers.
Pourtant, il y a moyen de le faire, puisque KDE la donne dasn properties.
man du?
du -h /etc
du -skh /etc
Un bon point pour vous, élève Labarthe. On va dire comme on dit, il
était temps! Inscrit dasn mon grand livre du didacticiel à venir.
(J'espère que d'autres font de même: tout d'un coup que la prochaine
épidémie de SRAS m'emporterait...)
Avant que le SRAS ne vous emporte cher maître, je ne saurais trop
vous conseiller de poster toute demande technique sur le forum
idoine, au risque de réponses oiseuses...
Je crainds que non. Tree ne donne que la dimension des fichiers. Pourtant, il y a moyen de le faire, puisque KDE la donne dasn properties.
man du? du -h /etc du -skh /etc
Un bon point pour vous, élève Labarthe. On va dire comme on dit, il était temps! Inscrit dasn mon grand livre du didacticiel à venir. (J'espère que d'autres font de même: tout d'un coup que la prochaine épidémie de SRAS m'emporterait...)
Avant que le SRAS ne vous emporte cher maître, je ne saurais trop
vous conseiller de poster toute demande technique sur le forum idoine, au risque de réponses oiseuses...
