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! =-----
OoO En cette nuit nuageuse du dimanche 21 décembre 2003, vers 01:50, Stephane TOUGARD disait:
Ce qui me surprend le plus, c'est la croyance qui semble coutumiere qu'ext2 n'est pas resistant aux pannes alors qu'il faut des sacres charges au moment de la panne pour que le fsck demande une intervention manuelle (ce qui d'ailleurs ne veut pas dire perte d'informations de facon irreversible).
C'est pour cela qu'on peut perdre assez facilement quelque chose comme le super bloc ou un répertoire en entier si la panne a eu lieu au mauvais moment. Bien entendu, je ne doute pas que tu n'aies jamais rencontré cela et que donc c'est totalement impossible (oui, oui, je réfléchis à ta place). -- BOFH excuse #34: (l)user error
OoO En cette nuit nuageuse du dimanche 21 décembre 2003, vers 01:50,
Stephane TOUGARD <stephane@unices.org> disait:
Ce qui me surprend le plus, c'est la croyance qui semble coutumiere
qu'ext2 n'est pas resistant aux pannes alors qu'il faut des sacres
charges au moment de la panne pour que le fsck demande une
intervention manuelle (ce qui d'ailleurs ne veut pas dire perte
d'informations de facon irreversible).
C'est pour cela qu'on peut perdre assez facilement quelque chose comme
le super bloc ou un répertoire en entier si la panne a eu lieu au
mauvais moment. Bien entendu, je ne doute pas que tu n'aies jamais
rencontré cela et que donc c'est totalement impossible (oui, oui, je
réfléchis à ta place).
--
BOFH excuse #34:
(l)user error
OoO En cette nuit nuageuse du dimanche 21 décembre 2003, vers 01:50, Stephane TOUGARD disait:
Ce qui me surprend le plus, c'est la croyance qui semble coutumiere qu'ext2 n'est pas resistant aux pannes alors qu'il faut des sacres charges au moment de la panne pour que le fsck demande une intervention manuelle (ce qui d'ailleurs ne veut pas dire perte d'informations de facon irreversible).
C'est pour cela qu'on peut perdre assez facilement quelque chose comme le super bloc ou un répertoire en entier si la panne a eu lieu au mauvais moment. Bien entendu, je ne doute pas que tu n'aies jamais rencontré cela et que donc c'est totalement impossible (oui, oui, je réfléchis à ta place). -- BOFH excuse #34: (l)user error
GP
Vincent Bernat wrote:
OoO Vers la fin de l'après-midi du samedi 20 décembre 2003, vers 16:00, GP disait:
Tk... Je disais donc, quelque part plus haut que, alors que le livret d'instructions de ma carte D-Link se penchait sur le cas Windows, j'avais installé la mienne simplement en l'insérant dans une fente et en rebootant. Le serveur dhcp s'était occupé du reste. Alors, pourquoi toutes ces instructions pour Windows?
Ceci dit, je ne vois pas non plus ce que vient faire un serveur DHCP avec la configuration d'une carte réseau, que ce soit sous Windows ou sous Linux. Je ne sais pas quelle salade de cresson vous avez fumés tous les deux. :)
Arrête donc! Ça se fume? Va falloir que j'essaie! Quant au dhcp... Attends que je sorte les instrucs pour ma carte. Pour l'installation, il s'agit bien d'un driver, qui apparemment est choisi automatiquement.
Ensuite, soit que tu installes rp-pppoe ou tu configures un router (le mien fait partie intégrante du modem). C'est plutôt ici qu'il y a des instructions pour les différentes versions de Windows, vu que «les interfaces, ça change, ça change. Les interfaces, ça change énormément». Avec Linux, il faut effectivement faire un ifconfig pour configurer le modem par l'interface http, mais ça, ça prend une ligne. Tu devrais voir les instructions click-o-dromes de Windows. Il y en a tout un paragraphe plus que touffu pour chaque version.
Ensuite, le serveur dhcp reconnaît le modem lors du boot. Et là, à ce que je comprends, maintenant, tout le monde est d'accord, il y a un serveur dhcp pour Windows. S'il y a un lan, tout le monde va recevoir son adresse auto. D'ac?
Dis donc, je viens d'essayer, le cresson. Pas terrible.
GP
-----= 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! =-----
Vincent Bernat wrote:
OoO Vers la fin de l'après-midi du samedi 20 décembre 2003, vers
16:00, GP <gilpel@inverse.nretla.org> disait:
Tk... Je disais donc, quelque part plus haut que, alors que le
livret d'instructions de ma carte D-Link se penchait sur le cas
Windows, j'avais installé la mienne simplement en l'insérant dans
une fente et en rebootant. Le serveur dhcp s'était occupé du
reste. Alors, pourquoi toutes ces instructions pour Windows?
Ceci dit, je ne vois pas non plus ce que vient faire un serveur DHCP
avec la configuration d'une carte réseau, que ce soit sous Windows ou
sous Linux. Je ne sais pas quelle salade de cresson vous avez fumés
tous les deux. :)
Arrête donc! Ça se fume? Va falloir que j'essaie! Quant au dhcp...
Attends que je sorte les instrucs pour ma carte. Pour l'installation,
il s'agit bien d'un driver, qui apparemment est choisi automatiquement.
Ensuite, soit que tu installes rp-pppoe ou tu configures un router (le
mien fait partie intégrante du modem). C'est plutôt ici qu'il y a des
instructions pour les différentes versions de Windows, vu que «les
interfaces, ça change, ça change. Les interfaces, ça change
énormément». Avec Linux, il faut effectivement faire un ifconfig pour
configurer le modem par l'interface http, mais ça, ça prend une ligne.
Tu devrais voir les instructions click-o-dromes de Windows. Il y en a
tout un paragraphe plus que touffu pour chaque version.
Ensuite, le serveur dhcp reconnaît le modem lors du boot. Et là, à ce
que je comprends, maintenant, tout le monde est d'accord, il y a un
serveur dhcp pour Windows. S'il y a un lan, tout le monde va recevoir
son adresse auto. D'ac?
Dis donc, je viens d'essayer, le cresson. Pas terrible.
GP
-----= 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! =-----
OoO Vers la fin de l'après-midi du samedi 20 décembre 2003, vers 16:00, GP disait:
Tk... Je disais donc, quelque part plus haut que, alors que le livret d'instructions de ma carte D-Link se penchait sur le cas Windows, j'avais installé la mienne simplement en l'insérant dans une fente et en rebootant. Le serveur dhcp s'était occupé du reste. Alors, pourquoi toutes ces instructions pour Windows?
Ceci dit, je ne vois pas non plus ce que vient faire un serveur DHCP avec la configuration d'une carte réseau, que ce soit sous Windows ou sous Linux. Je ne sais pas quelle salade de cresson vous avez fumés tous les deux. :)
Arrête donc! Ça se fume? Va falloir que j'essaie! Quant au dhcp... Attends que je sorte les instrucs pour ma carte. Pour l'installation, il s'agit bien d'un driver, qui apparemment est choisi automatiquement.
Ensuite, soit que tu installes rp-pppoe ou tu configures un router (le mien fait partie intégrante du modem). C'est plutôt ici qu'il y a des instructions pour les différentes versions de Windows, vu que «les interfaces, ça change, ça change. Les interfaces, ça change énormément». Avec Linux, il faut effectivement faire un ifconfig pour configurer le modem par l'interface http, mais ça, ça prend une ligne. Tu devrais voir les instructions click-o-dromes de Windows. Il y en a tout un paragraphe plus que touffu pour chaque version.
Ensuite, le serveur dhcp reconnaît le modem lors du boot. Et là, à ce que je comprends, maintenant, tout le monde est d'accord, il y a un serveur dhcp pour Windows. S'il y a un lan, tout le monde va recevoir son adresse auto. D'ac?
Dis donc, je viens d'essayer, le cresson. Pas terrible.
GP
-----= 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! =-----
Stephane TOUGARD
Vincent Bernat wrote:
C'est pour cela qu'on peut perdre assez facilement quelque chose comme le super bloc ou un répertoire en entier si la panne a eu lieu au mauvais moment. Bien entendu, je ne doute pas que tu n'aies jamais rencontré cela et que donc c'est totalement impossible (oui, oui, je réfléchis à ta place).
Si, ca m'est deja arrive, avec de l'ext3.
La seule panne sous ext2 etait du une defaillance physique. Par contre avec ext3, NTFS, FFS et UFS exploites sous leurs OS respectifs, j'ai deja eu des problemes lies aux FS.
-- http://www.unices.org
Vincent Bernat wrote:
C'est pour cela qu'on peut perdre assez facilement quelque chose comme
le super bloc ou un répertoire en entier si la panne a eu lieu au
mauvais moment. Bien entendu, je ne doute pas que tu n'aies jamais
rencontré cela et que donc c'est totalement impossible (oui, oui, je
réfléchis à ta place).
Si, ca m'est deja arrive, avec de l'ext3.
La seule panne sous ext2 etait du une defaillance physique. Par contre
avec ext3, NTFS, FFS et UFS exploites sous leurs OS respectifs, j'ai
deja eu des problemes lies aux FS.
C'est pour cela qu'on peut perdre assez facilement quelque chose comme le super bloc ou un répertoire en entier si la panne a eu lieu au mauvais moment. Bien entendu, je ne doute pas que tu n'aies jamais rencontré cela et que donc c'est totalement impossible (oui, oui, je réfléchis à ta place).
Si, ca m'est deja arrive, avec de l'ext3.
La seule panne sous ext2 etait du une defaillance physique. Par contre avec ext3, NTFS, FFS et UFS exploites sous leurs OS respectifs, j'ai deja eu des problemes lies aux FS.
-- http://www.unices.org
talon
Vincent Bernat wrote:
OoO En cette aube naissante du dimanche 21 décembre 2003, vers 07:37, (Michel Talon) disait:
Je ne t'ai pas dit que le firewall intégré à XP valait Kerio ou ZoneAlarm, je t'ai dit que c'était un firewall à états qui marchait, tout comme iptables sous Linux, ni plus ni moins. Avec le gros avantage d'être trés simple à configurer et pas emmerdant comme peut l'être ZoneAlarm. En outre tout aussi gratuit que les deux autres puisqu'il est intégré au système. Bref comme tout firewall à états, les paquets entrants sont bloqués, sauf s'ils sont en réponse à un paquet sortant ou si on a percé un trou spécifique pour un serveur.
Comme iptables sous Linux, ni plus ni moins ? Cette merde de firewall sous XP ne sait gérer que les connexions entrantes avec comme seul point discriminatoire le numéro de port et le protocole ! Tu compares ça avec NetFilter ? Il ne faut vraiment pas avoir peur.
Sauf qu'il gère les connections entrantes si elles correspondent à un état, ce qui pour moi, représente 99% de l'utilisation d'un firewall.
--
Michel TALON
Vincent Bernat <vincent.bernat@raysa.org> wrote:
OoO En cette aube naissante du dimanche 21 décembre 2003, vers 07:37,
talon@lpthe.jussieu.fr (Michel Talon) disait:
Je ne t'ai pas dit que le firewall intégré à XP valait Kerio ou
ZoneAlarm, je t'ai dit que c'était un firewall à états qui marchait,
tout comme iptables sous Linux, ni plus ni moins. Avec le gros
avantage d'être trés simple à configurer et pas emmerdant comme peut
l'être ZoneAlarm. En outre tout aussi gratuit que les deux autres
puisqu'il est intégré au système. Bref comme tout firewall à états,
les paquets entrants sont bloqués, sauf s'ils sont en réponse à un
paquet sortant ou si on a percé un trou spécifique pour un serveur.
Comme iptables sous Linux, ni plus ni moins ? Cette merde de firewall
sous XP ne sait gérer que les connexions entrantes avec comme seul
point discriminatoire le numéro de port et le protocole ! Tu compares
ça avec NetFilter ? Il ne faut vraiment pas avoir peur.
Sauf qu'il gère les connections entrantes si elles correspondent à un
état, ce qui pour moi, représente 99% de l'utilisation d'un firewall.
OoO En cette aube naissante du dimanche 21 décembre 2003, vers 07:37, (Michel Talon) disait:
Je ne t'ai pas dit que le firewall intégré à XP valait Kerio ou ZoneAlarm, je t'ai dit que c'était un firewall à états qui marchait, tout comme iptables sous Linux, ni plus ni moins. Avec le gros avantage d'être trés simple à configurer et pas emmerdant comme peut l'être ZoneAlarm. En outre tout aussi gratuit que les deux autres puisqu'il est intégré au système. Bref comme tout firewall à états, les paquets entrants sont bloqués, sauf s'ils sont en réponse à un paquet sortant ou si on a percé un trou spécifique pour un serveur.
Comme iptables sous Linux, ni plus ni moins ? Cette merde de firewall sous XP ne sait gérer que les connexions entrantes avec comme seul point discriminatoire le numéro de port et le protocole ! Tu compares ça avec NetFilter ? Il ne faut vraiment pas avoir peur.
Sauf qu'il gère les connections entrantes si elles correspondent à un état, ce qui pour moi, représente 99% de l'utilisation d'un firewall.
--
Michel TALON
Vincent Bernat
OoO Peu avant le début de l'après-midi du dimanche 21 décembre 2003, vers 13:17, (Michel Talon) disait:
Comme iptables sous Linux, ni plus ni moins ? Cette merde de firewall sous XP ne sait gérer que les connexions entrantes avec comme seul point discriminatoire le numéro de port et le protocole ! Tu compares ça avec NetFilter ? Il ne faut vraiment pas avoir peur.
Sauf qu'il gère les connections entrantes si elles correspondent à un état, ce qui pour moi, représente 99% de l'utilisation d'un firewall.
Il ne gère _que_ les connexions entrantes. Quand on connaît le nid à virus que peut devenir un Windows, c'est quand même une sacré limitation. Je ne tiens pas compte de ton 99% sorti du chapeau, je doute que les utilisateurs de firewalls personnels se cantonnent tous à la gestion des connexions entrantes. -- panic("aha1740.c"); /* Goodbye */ 2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
OoO Peu avant le début de l'après-midi du dimanche 21 décembre 2003,
vers 13:17, talon@lpthe.jussieu.fr (Michel Talon) disait:
Comme iptables sous Linux, ni plus ni moins ? Cette merde de
firewall sous XP ne sait gérer que les connexions entrantes avec
comme seul point discriminatoire le numéro de port et le protocole
! Tu compares ça avec NetFilter ? Il ne faut vraiment pas avoir
peur.
Sauf qu'il gère les connections entrantes si elles correspondent à
un état, ce qui pour moi, représente 99% de l'utilisation d'un
firewall.
Il ne gère _que_ les connexions entrantes. Quand on connaît le nid à
virus que peut devenir un Windows, c'est quand même une sacré
limitation. Je ne tiens pas compte de ton 99% sorti du chapeau, je
doute que les utilisateurs de firewalls personnels se cantonnent tous
à la gestion des connexions entrantes.
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
OoO Peu avant le début de l'après-midi du dimanche 21 décembre 2003, vers 13:17, (Michel Talon) disait:
Comme iptables sous Linux, ni plus ni moins ? Cette merde de firewall sous XP ne sait gérer que les connexions entrantes avec comme seul point discriminatoire le numéro de port et le protocole ! Tu compares ça avec NetFilter ? Il ne faut vraiment pas avoir peur.
Sauf qu'il gère les connections entrantes si elles correspondent à un état, ce qui pour moi, représente 99% de l'utilisation d'un firewall.
Il ne gère _que_ les connexions entrantes. Quand on connaît le nid à virus que peut devenir un Windows, c'est quand même une sacré limitation. Je ne tiens pas compte de ton 99% sorti du chapeau, je doute que les utilisateurs de firewalls personnels se cantonnent tous à la gestion des connexions entrantes. -- panic("aha1740.c"); /* Goodbye */ 2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
Emmanuel Florac
Dans article , disait...
je doute que les utilisateurs de firewalls personnels se cantonnent tous à la gestion des connexions entrantes.
En fait c'est même le contraire : les firewall personnels ont pour vocation d'empécher les connexions sortantes, en particulier (pour les gens soucieux de sécurité) pour un certain iexplorer.exe.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <m3pteh7qdk.fsf@neo.loria>, vincent.bernat@raysa.org
disait...
je
doute que les utilisateurs de firewalls personnels se cantonnent tous
à la gestion des connexions entrantes.
En fait c'est même le contraire : les firewall personnels ont pour
vocation d'empécher les connexions sortantes, en particulier (pour les
gens soucieux de sécurité) pour un certain iexplorer.exe.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
je doute que les utilisateurs de firewalls personnels se cantonnent tous à la gestion des connexions entrantes.
En fait c'est même le contraire : les firewall personnels ont pour vocation d'empécher les connexions sortantes, en particulier (pour les gens soucieux de sécurité) pour un certain iexplorer.exe.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Benjamin FRANCOIS
Michel Talon s'est exprimé en ces termes:
Ben t'étais riche il y a 4 ans toi!
Bah non, il y a 4 ans le SCSI était encore un peu répandu et pas tellement plus cher que l'IDE.
C'est pas demain la veille que je vais acheter un outil 2 fois plus cher en SCSI pour un bénéfice nul.
Bénéfice nul ? Il y a 4 ans, les graveurs IDE n'étaient pas munis de Burnproof et toutes ces petites technologies qui permettent d'être à l'aise en cramant une galette. Sous Windows 98, ça n'était même pas la peine d'espèrer lire une vidéo en gravant sous peine de fiche en l'air le CD vierge, alors qu'avec le graveur SCSI sous Linux on joue à Quake3 pour patienter. Alors non, désolé, le bénéfice était trèèèèès loin d'être nul.
-- <luc2> bon, si vous voulez pas m'aider, foutez le camp
Michel Talon s'est exprimé en ces termes:
Ben t'étais riche il y a 4 ans toi!
Bah non, il y a 4 ans le SCSI était encore un peu répandu et pas
tellement plus cher que l'IDE.
C'est pas demain la veille que je vais acheter un outil 2 fois plus cher
en SCSI pour un bénéfice nul.
Bénéfice nul ? Il y a 4 ans, les graveurs IDE n'étaient pas munis de
Burnproof et toutes ces petites technologies qui permettent d'être à
l'aise en cramant une galette. Sous Windows 98, ça n'était même pas la
peine d'espèrer lire une vidéo en gravant sous peine de fiche en l'air
le CD vierge, alors qu'avec le graveur SCSI sous Linux on joue à Quake3
pour patienter. Alors non, désolé, le bénéfice était trèèèèès loin
d'être nul.
--
<luc2> bon, si vous voulez pas m'aider, foutez le camp
Bah non, il y a 4 ans le SCSI était encore un peu répandu et pas tellement plus cher que l'IDE.
C'est pas demain la veille que je vais acheter un outil 2 fois plus cher en SCSI pour un bénéfice nul.
Bénéfice nul ? Il y a 4 ans, les graveurs IDE n'étaient pas munis de Burnproof et toutes ces petites technologies qui permettent d'être à l'aise en cramant une galette. Sous Windows 98, ça n'était même pas la peine d'espèrer lire une vidéo en gravant sous peine de fiche en l'air le CD vierge, alors qu'avec le graveur SCSI sous Linux on joue à Quake3 pour patienter. Alors non, désolé, le bénéfice était trèèèèès loin d'être nul.
-- <luc2> bon, si vous voulez pas m'aider, foutez le camp
Benjamin FRANCOIS
Vincent Bernat s'est exprimé en ces termes:
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.
Ou bien "KDE", tout simplement.
-- <luc2> bon, si vous voulez pas m'aider, foutez le camp
Vincent Bernat s'est exprimé en ces termes:
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.
Ou bien "KDE", tout simplement.
--
<luc2> bon, si vous voulez pas m'aider, foutez le camp
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.
Ou bien "KDE", tout simplement.
-- <luc2> bon, si vous voulez pas m'aider, foutez le camp
talon
Stephane TOUGARD wrote:
Vincent Bernat wrote:
C'est pour cela qu'on peut perdre assez facilement quelque chose comme le super bloc ou un répertoire en entier si la panne a eu lieu au mauvais moment. Bien entendu, je ne doute pas que tu n'aies jamais rencontré cela et que donc c'est totalement impossible (oui, oui, je réfléchis à ta place).
Si, ca m'est deja arrive, avec de l'ext3.
La seule panne sous ext2 etait du une defaillance physique. Par contre avec ext3, NTFS, FFS et UFS exploites sous leurs OS respectifs, j'ai deja eu des problemes lies aux FS.
Ca c'est garanti que si tu utilises l'UFS en asynchrone contre l'avis de
tous les développeurs de FreeBSD, il ne faut pas t'étonner des ennuis. Soit tu utilises le mode standard qui est lent et sur, soit les softupdates, qui sont rapides et surs.
--
Michel TALON
Stephane TOUGARD <stephane@unices.org> wrote:
Vincent Bernat wrote:
C'est pour cela qu'on peut perdre assez facilement quelque chose comme
le super bloc ou un répertoire en entier si la panne a eu lieu au
mauvais moment. Bien entendu, je ne doute pas que tu n'aies jamais
rencontré cela et que donc c'est totalement impossible (oui, oui, je
réfléchis à ta place).
Si, ca m'est deja arrive, avec de l'ext3.
La seule panne sous ext2 etait du une defaillance physique. Par contre
avec ext3, NTFS, FFS et UFS exploites sous leurs OS respectifs, j'ai
deja eu des problemes lies aux FS.
Ca c'est garanti que si tu utilises l'UFS en asynchrone contre l'avis de
tous les développeurs de FreeBSD, il ne faut pas t'étonner des ennuis.
Soit tu utilises le mode standard qui est lent et sur, soit les
softupdates, qui sont rapides et surs.
C'est pour cela qu'on peut perdre assez facilement quelque chose comme le super bloc ou un répertoire en entier si la panne a eu lieu au mauvais moment. Bien entendu, je ne doute pas que tu n'aies jamais rencontré cela et que donc c'est totalement impossible (oui, oui, je réfléchis à ta place).
Si, ca m'est deja arrive, avec de l'ext3.
La seule panne sous ext2 etait du une defaillance physique. Par contre avec ext3, NTFS, FFS et UFS exploites sous leurs OS respectifs, j'ai deja eu des problemes lies aux FS.
Ca c'est garanti que si tu utilises l'UFS en asynchrone contre l'avis de
tous les développeurs de FreeBSD, il ne faut pas t'étonner des ennuis. Soit tu utilises le mode standard qui est lent et sur, soit les softupdates, qui sont rapides et surs.
--
Michel TALON
Stephane TOUGARD
Michel Talon wrote:
La seule panne sous ext2 etait du une defaillance physique. Par contre avec ext3, NTFS, FFS et UFS exploites sous leurs OS respectifs, j'ai deja eu des problemes lies aux FS. Ca c'est garanti que si tu utilises l'UFS en asynchrone contre l'avis de
tous les développeurs de FreeBSD, il ne faut pas t'étonner des ennuis. Soit tu utilises le mode standard qui est lent et sur, soit les softupdates, qui sont rapides et surs.
Non, c'etait lie a la creation d'un grand nombre de fichiers fifo sous OpenBSD.
L'autre probleme etant des fsck manuels en rafale sur un Solaris X86 alors que la machine etait eteinte manuellement avec le plus grand soin (sync, halt, ...).
Dans les deux cas, le hard n'etait pas a mettre en cause.
Ensuite, lorsque je monte un UFS en asynchrone et que je perds des donnees apres un reboot sauvage, je ne dis pas que c'est un probleme lie au file system, je dis que c'est normal et attendu et que les donnees en question ne sont pas assez importantes pour justifier d'un autre mode.
-- http://www.unices.org
Michel Talon wrote:
La seule panne sous ext2 etait du une defaillance physique. Par contre
avec ext3, NTFS, FFS et UFS exploites sous leurs OS respectifs, j'ai
deja eu des problemes lies aux FS.
Ca c'est garanti que si tu utilises l'UFS en asynchrone contre l'avis de
tous les développeurs de FreeBSD, il ne faut pas t'étonner des ennuis.
Soit tu utilises le mode standard qui est lent et sur, soit les
softupdates, qui sont rapides et surs.
Non, c'etait lie a la creation d'un grand nombre de fichiers fifo sous
OpenBSD.
L'autre probleme etant des fsck manuels en rafale sur un Solaris X86
alors que la machine etait eteinte manuellement avec le plus grand soin
(sync, halt, ...).
Dans les deux cas, le hard n'etait pas a mettre en cause.
Ensuite, lorsque je monte un UFS en asynchrone et que je perds des
donnees apres un reboot sauvage, je ne dis pas que c'est un probleme lie
au file system, je dis que c'est normal et attendu et que les donnees en
question ne sont pas assez importantes pour justifier d'un autre mode.
La seule panne sous ext2 etait du une defaillance physique. Par contre avec ext3, NTFS, FFS et UFS exploites sous leurs OS respectifs, j'ai deja eu des problemes lies aux FS. Ca c'est garanti que si tu utilises l'UFS en asynchrone contre l'avis de
tous les développeurs de FreeBSD, il ne faut pas t'étonner des ennuis. Soit tu utilises le mode standard qui est lent et sur, soit les softupdates, qui sont rapides et surs.
Non, c'etait lie a la creation d'un grand nombre de fichiers fifo sous OpenBSD.
L'autre probleme etant des fsck manuels en rafale sur un Solaris X86 alors que la machine etait eteinte manuellement avec le plus grand soin (sync, halt, ...).
Dans les deux cas, le hard n'etait pas a mettre en cause.
Ensuite, lorsque je monte un UFS en asynchrone et que je perds des donnees apres un reboot sauvage, je ne dis pas que c'est un probleme lie au file system, je dis que c'est normal et attendu et que les donnees en question ne sont pas assez importantes pour justifier d'un autre mode.
