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! =-----
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.
C'est pourtant lui que j'utilise sur la plupart des serveurs en prod que je gere. C'est pas complique, c'est le seul serieux gere par le kernel 2.2, c'est a dire la derniere serie des kernels Linux stables et secures et proposes par defaut sur une Debian.
Les derniers problemes du 2.4.x ou x < 22 m'ont d'ailleurs tout a fait donne raison sur l'opinion que je me fais de ce kernel.
Qd a la securite quasi NULLE en ext2, le seul serveur qui a du faire un fsck manuel avait un disque completement et physiquement mort, j'ai quand meme reussi a le faire tenir 1 semaine sans plantage avant de pouvoir le changer. Pour un truc NUL, il s'en est tres bien sorti.
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.
Je te parlais d'UFS en async et non en suftupdates, ce qui n'a strictement rien a voir.
-- http://www.unices.org
Michel Talon wrote:
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.
C'est pourtant lui que j'utilise sur la plupart des serveurs en prod que
je gere. C'est pas complique, c'est le seul serieux gere par le kernel
2.2, c'est a dire la derniere serie des kernels Linux stables et secures
et proposes par defaut sur une Debian.
Les derniers problemes du 2.4.x ou x < 22 m'ont d'ailleurs tout a fait
donne raison sur l'opinion que je me fais de ce kernel.
Qd a la securite quasi NULLE en ext2, le seul serveur qui a du faire un
fsck manuel avait un disque completement et physiquement mort, j'ai
quand meme reussi a le faire tenir 1 semaine sans plantage avant de
pouvoir le changer. Pour un truc NUL, il s'en est tres bien sorti.
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.
Je te parlais d'UFS en async et non en suftupdates, ce qui n'a
strictement rien a voir.
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.
C'est pourtant lui que j'utilise sur la plupart des serveurs en prod que je gere. C'est pas complique, c'est le seul serieux gere par le kernel 2.2, c'est a dire la derniere serie des kernels Linux stables et secures et proposes par defaut sur une Debian.
Les derniers problemes du 2.4.x ou x < 22 m'ont d'ailleurs tout a fait donne raison sur l'opinion que je me fais de ce kernel.
Qd a la securite quasi NULLE en ext2, le seul serveur qui a du faire un fsck manuel avait un disque completement et physiquement mort, j'ai quand meme reussi a le faire tenir 1 semaine sans plantage avant de pouvoir le changer. Pour un truc NUL, il s'en est tres bien sorti.
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.
Je te parlais d'UFS en async et non en suftupdates, ce qui n'a strictement rien a voir.
-- http://www.unices.org
Richard Delorme
OoO En ce début d'après-midi ensoleillé du samedi 20 décembre 2003,
Arghh, je suis sous la pluie ici...
vers 15:54, Richard Delorme disait:
Tss, tss, il suffit bien sûr d'utiliser un onduleur. Cesse donc d'être aussi réducteur.
Existe-t-il des onduleurs magiques qui protègent : - de l'extinction accidentelle de la machine par un <CENSURÉ> qui a appuyé sur le bouton off ? - de l'extinction accidentelle de la machine par un <CENSURÉ> qui a arraché le fil entre la machine et l'onduleur ? - de la panne de l'alimentation où les différents périphériques de stockage puisent leur énergie ?
Tss, tss, tu fais l'effet d'un neuneu qui tape des pieds parce qu'on vient de le contredire.
Non je me suis contenté de lister une série de problème que j'ai connu. Par contre j'ai récemment jeté un onduleur dont l'utilité a été nulle, les coupures non annoncées d'EDF (et des électriciens) étant rarissimes par chez moi, suffisamment pour ne pas se produire sur la durée de vie d'un onduleur.
-- Richard
OoO En ce début d'après-midi ensoleillé du samedi 20 décembre 2003,
Arghh, je suis sous la pluie ici...
vers 15:54, Richard Delorme <abulmo@nospam.fr> disait:
Tss, tss, il suffit bien sûr d'utiliser un onduleur. Cesse donc
d'être aussi réducteur.
Existe-t-il des onduleurs magiques qui protègent :
- de l'extinction accidentelle de la machine par un <CENSURÉ> qui a
appuyé sur le bouton off ?
- de l'extinction accidentelle de la machine par un <CENSURÉ> qui a
arraché le fil entre la machine et l'onduleur ?
- de la panne de l'alimentation où les différents périphériques de
stockage puisent leur énergie ?
Tss, tss, tu fais l'effet d'un neuneu qui tape des pieds parce qu'on
vient de le contredire.
Non je me suis contenté de lister une série de problème que j'ai connu. Par
contre j'ai récemment jeté un onduleur dont l'utilité a été nulle, les
coupures non annoncées d'EDF (et des électriciens) étant rarissimes par
chez moi, suffisamment pour ne pas se produire sur la durée de vie d'un
onduleur.
OoO En ce début d'après-midi ensoleillé du samedi 20 décembre 2003,
Arghh, je suis sous la pluie ici...
vers 15:54, Richard Delorme disait:
Tss, tss, il suffit bien sûr d'utiliser un onduleur. Cesse donc d'être aussi réducteur.
Existe-t-il des onduleurs magiques qui protègent : - de l'extinction accidentelle de la machine par un <CENSURÉ> qui a appuyé sur le bouton off ? - de l'extinction accidentelle de la machine par un <CENSURÉ> qui a arraché le fil entre la machine et l'onduleur ? - de la panne de l'alimentation où les différents périphériques de stockage puisent leur énergie ?
Tss, tss, tu fais l'effet d'un neuneu qui tape des pieds parce qu'on vient de le contredire.
Non je me suis contenté de lister une série de problème que j'ai connu. Par contre j'ai récemment jeté un onduleur dont l'utilité a été nulle, les coupures non annoncées d'EDF (et des électriciens) étant rarissimes par chez moi, suffisamment pour ne pas se produire sur la durée de vie d'un onduleur.
-- Richard
Stephane TOUGARD
Richard Delorme wrote:
Non je me suis contenté de lister une série de problème que j'ai connu. Par contre j'ai récemment jeté un onduleur dont l'utilité a été nulle, les coupures non annoncées d'EDF (et des électriciens) étant rarissimes par chez moi, suffisamment pour ne pas se produire sur la durée de vie d'un onduleur.
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).
L'avantage de la journalisation etant plus dans le temps necessaire au check au moment du reboot apres un plantage que dans la fiabilite du systeme en lui meme.
Apres, la notion du neuneu qui appuie sur un ON/OFF sur un serveur qui est dans une baie fermee a clef qui, elle meme, se trouve dans une salle blanche fermee a clef, c'est toujours possible, mais tu m'excuseras de ne pas trop en tenir compte.
-- http://www.unices.org
Richard Delorme wrote:
Non je me suis contenté de lister une série de problème que j'ai connu. Par
contre j'ai récemment jeté un onduleur dont l'utilité a été nulle, les
coupures non annoncées d'EDF (et des électriciens) étant rarissimes par
chez moi, suffisamment pour ne pas se produire sur la durée de vie d'un
onduleur.
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).
L'avantage de la journalisation etant plus dans le temps necessaire au
check au moment du reboot apres un plantage que dans la fiabilite du
systeme en lui meme.
Apres, la notion du neuneu qui appuie sur un ON/OFF sur un serveur qui
est dans une baie fermee a clef qui, elle meme, se trouve dans une salle
blanche fermee a clef, c'est toujours possible, mais tu m'excuseras de
ne pas trop en tenir compte.
Non je me suis contenté de lister une série de problème que j'ai connu. Par contre j'ai récemment jeté un onduleur dont l'utilité a été nulle, les coupures non annoncées d'EDF (et des électriciens) étant rarissimes par chez moi, suffisamment pour ne pas se produire sur la durée de vie d'un onduleur.
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).
L'avantage de la journalisation etant plus dans le temps necessaire au check au moment du reboot apres un plantage que dans la fiabilite du systeme en lui meme.
Apres, la notion du neuneu qui appuie sur un ON/OFF sur un serveur qui est dans une baie fermee a clef qui, elle meme, se trouve dans une salle blanche fermee a clef, c'est toujours possible, mais tu m'excuseras de ne pas trop en tenir compte.
-- http://www.unices.org
talon
Emmanuel Florac wrote:
Dans article <bs2ht8$ldf$, disait...
Il vient même avec un firewall à état, qui marche raisonnablement,
Excuse-moi, mais il me semble d'après les discussions que je suis régulièrement sur fr.comp.securite, qu'il est assez notoire que le firewall intégré à XP ne vaut pas tripette, et en tout cas ne certes vaut pas un simple Kerio gratuit.
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. Par contre contrairement à Kerio ou ZoneAlarm, ce firewall ne vérifie pas la nature du serveur qui va recevoir le paquet ou son md5. A ma connaissance, aucun firewall Unix ne fait ce genre de choses, et d'ailleurs l'utilité en est fortement contestée par les spécialistes.
Quant au problème du modem, j'ai présentement une connexion ouverte sur ma slack avec le fameux fast 800 depuis 5 ou 6 jours (la dernière fois que j'ai rebooté), sans déconnexion ni autre problème; contrairement au driver fourni il y a un an, l'actuel (eagle 1.04) me paraît donc tout à fait fiable (en tout cas pour un usage strictement personnel).
Ca se peut je n'ai pas essayé le 1.04 depuis les déboires de l'an passé.
Je ne pense pas que le driver soit meilleur, je pense plutôt que Free a largement amélioré son matos. Le code source lui même du driver je l'ai regardé et 1.04 n'a que des modifications infimes dans un truc qui est un vrai plat de spaghetti. Un bien meilleur driver pour le Fast 800 au moins au niveau de la clarté a été écrit pour FreeBSD, voir http://damien.bergamini.free.fr/ueagle/ Je vais l'essayer pendant les vacances.
--
Michel TALON
Emmanuel Florac <eflorac@verisign.com> wrote:
Dans article <bs2ht8$ldf$5@asmodee.lpthe.jussieu.fr>,
talon@lpthe.jussieu.fr disait...
Il vient même avec un firewall à état, qui marche raisonnablement,
Excuse-moi, mais il me semble d'après les discussions que je suis
régulièrement sur fr.comp.securite, qu'il est assez notoire que le
firewall intégré à XP ne vaut pas tripette, et en tout cas ne certes vaut
pas un simple Kerio gratuit.
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.
Par contre contrairement à Kerio ou ZoneAlarm, ce firewall ne vérifie
pas la nature du serveur qui va recevoir le paquet ou son md5. A ma
connaissance, aucun firewall Unix ne fait ce genre de choses, et
d'ailleurs l'utilité en est fortement contestée par les spécialistes.
Quant au problème du modem, j'ai présentement une connexion ouverte sur
ma slack avec le fameux fast 800 depuis 5 ou 6 jours (la dernière fois
que j'ai rebooté), sans déconnexion ni autre problème; contrairement au
driver fourni il y a un an, l'actuel (eagle 1.04) me paraît donc tout à
fait fiable (en tout cas pour un usage strictement personnel).
Ca se peut je n'ai pas essayé le 1.04 depuis les déboires de l'an passé.
Je ne pense pas que le driver soit meilleur, je pense plutôt que Free
a largement amélioré son matos. Le code source lui même du driver je
l'ai regardé et 1.04 n'a que des modifications infimes dans un truc qui
est un vrai plat de spaghetti. Un bien meilleur driver pour le Fast 800
au moins au niveau de la clarté a été écrit pour FreeBSD, voir
http://damien.bergamini.free.fr/ueagle/
Je vais l'essayer pendant les vacances.
Il vient même avec un firewall à état, qui marche raisonnablement,
Excuse-moi, mais il me semble d'après les discussions que je suis régulièrement sur fr.comp.securite, qu'il est assez notoire que le firewall intégré à XP ne vaut pas tripette, et en tout cas ne certes vaut pas un simple Kerio gratuit.
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. Par contre contrairement à Kerio ou ZoneAlarm, ce firewall ne vérifie pas la nature du serveur qui va recevoir le paquet ou son md5. A ma connaissance, aucun firewall Unix ne fait ce genre de choses, et d'ailleurs l'utilité en est fortement contestée par les spécialistes.
Quant au problème du modem, j'ai présentement une connexion ouverte sur ma slack avec le fameux fast 800 depuis 5 ou 6 jours (la dernière fois que j'ai rebooté), sans déconnexion ni autre problème; contrairement au driver fourni il y a un an, l'actuel (eagle 1.04) me paraît donc tout à fait fiable (en tout cas pour un usage strictement personnel).
Ca se peut je n'ai pas essayé le 1.04 depuis les déboires de l'an passé.
Je ne pense pas que le driver soit meilleur, je pense plutôt que Free a largement amélioré son matos. Le code source lui même du driver je l'ai regardé et 1.04 n'a que des modifications infimes dans un truc qui est un vrai plat de spaghetti. Un bien meilleur driver pour le Fast 800 au moins au niveau de la clarté a été écrit pour FreeBSD, voir http://damien.bergamini.free.fr/ueagle/ Je vais l'essayer pendant les vacances.
--
Michel TALON
talon
Vincent Bernat wrote:
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. :)
Ca vient faire qu'elle se passe toute seule, sans que l'utilisateur
lambda ne s'apercoive de rien, ce qui est quand même nettement plus facile pour lui que de taper ifconfig eth0 192.168.10.2 netmask 255.255.255.0 ou bien plus encore que de faire grep -r dans /etc pour savoir où ce putain de configurateur de Mandrake est allé fourrer des valeurs erronnées, pourquoi la table de routage est fausse, etc.
Pour ma part, je prétends également que la gestion des drivers sous Windows est à 100 lieues de ce qui se fait sous Linux puisque les drivers ne sont pas génériques comme ils le sont sous Linux, ce qui fait qu'il y a besoin d'un driver différent pour une Sound Blaster Live 5.1 et pour la version Value qui est absolument identique à quelques détails près.
C'est pour ça que si tu installes une carte vidéo nvidia il suffit d'installer le driver windows nvidia qui marche quel que soit le modèle de la carte (idem sous Linux d'ailleurs). C'est pour ça que sur la machine que j'ai installée la semaine dernière sous Windows XP, et qui comprenait une Matrox Millenium II, deux cartes réseau, une 3COM et une Netgear, une carte son Aureal Vortex, et un Zip sur port parallèle, il ne m'a pas fallu installer un seul driver, WinXP avait tous les drivers appropriés sur son CDROM, et a tout détecté correctement. Ce n'est que quand j'ai changé la Matrox pour une GeForce qu'il a fallu que je fasse venir un driver car la carte était trop récente par rapport à mon OS. Par contre sous Mandrake il a fallu que je touille pour détecter que le Zip était géré par imm et non ppa, la Matrox Millenium est sortie noire, car il n'y avait pas "assez de mémoire vidéo pour la profondeur choisie -24 bits", et je n'ai pas pu compiler le driver pour l'Aureal, tandis que les drivers Alsa n'étaient pas assez récents pour avoir ledit support.
Les utilisateurs de Windows sont habitués à faire cette gymnastique de drivers au point que quand ils arrivent sous Linux, ils se plaignent du manque de drivers pour celui-ci tout simplement parce que c'est soit déjà intégré, soit parfaitement inutile.
Il faut te moderniser, c'est fini tout ça.
--
Michel TALON
Vincent Bernat <vince@khabale.org> wrote:
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. :)
Ca vient faire qu'elle se passe toute seule, sans que l'utilisateur
lambda ne s'apercoive de rien, ce qui est quand même nettement plus
facile pour lui que de taper
ifconfig eth0 192.168.10.2 netmask 255.255.255.0
ou bien plus encore que de faire grep -r dans /etc pour savoir où ce
putain de configurateur de Mandrake est allé fourrer des valeurs
erronnées, pourquoi la table de routage est fausse, etc.
Pour ma part, je prétends également que la gestion des drivers sous
Windows est à 100 lieues de ce qui se fait sous Linux puisque les
drivers ne sont pas génériques comme ils le sont sous Linux, ce qui
fait qu'il y a besoin d'un driver différent pour une Sound Blaster
Live 5.1 et pour la version Value qui est absolument identique à
quelques détails près.
C'est pour ça que si tu installes une carte vidéo nvidia il suffit
d'installer le driver windows nvidia qui marche quel que soit le modèle
de la carte (idem sous Linux d'ailleurs). C'est pour ça que sur la
machine que j'ai installée la semaine dernière sous Windows XP, et qui
comprenait une Matrox Millenium II, deux cartes réseau, une 3COM et une
Netgear, une carte son Aureal Vortex, et un Zip sur port parallèle, il
ne m'a pas fallu installer un seul driver, WinXP avait tous les drivers
appropriés sur son CDROM, et a tout détecté correctement. Ce n'est que
quand j'ai changé la Matrox pour une GeForce qu'il a fallu que je fasse
venir un driver car la carte était trop récente par rapport à mon OS.
Par contre sous Mandrake il a fallu que je touille pour détecter que le
Zip était géré par imm et non ppa, la Matrox Millenium est sortie noire,
car il n'y avait pas "assez de mémoire vidéo pour la profondeur choisie
-24 bits", et je n'ai pas pu compiler le driver pour l'Aureal, tandis que
les drivers Alsa n'étaient pas assez récents pour avoir ledit support.
Les utilisateurs de Windows sont habitués à faire cette gymnastique de
drivers au point que quand ils arrivent sous Linux, ils se plaignent
du manque de drivers pour celui-ci tout simplement parce que c'est
soit déjà intégré, soit parfaitement inutile.
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. :)
Ca vient faire qu'elle se passe toute seule, sans que l'utilisateur
lambda ne s'apercoive de rien, ce qui est quand même nettement plus facile pour lui que de taper ifconfig eth0 192.168.10.2 netmask 255.255.255.0 ou bien plus encore que de faire grep -r dans /etc pour savoir où ce putain de configurateur de Mandrake est allé fourrer des valeurs erronnées, pourquoi la table de routage est fausse, etc.
Pour ma part, je prétends également que la gestion des drivers sous Windows est à 100 lieues de ce qui se fait sous Linux puisque les drivers ne sont pas génériques comme ils le sont sous Linux, ce qui fait qu'il y a besoin d'un driver différent pour une Sound Blaster Live 5.1 et pour la version Value qui est absolument identique à quelques détails près.
C'est pour ça que si tu installes une carte vidéo nvidia il suffit d'installer le driver windows nvidia qui marche quel que soit le modèle de la carte (idem sous Linux d'ailleurs). C'est pour ça que sur la machine que j'ai installée la semaine dernière sous Windows XP, et qui comprenait une Matrox Millenium II, deux cartes réseau, une 3COM et une Netgear, une carte son Aureal Vortex, et un Zip sur port parallèle, il ne m'a pas fallu installer un seul driver, WinXP avait tous les drivers appropriés sur son CDROM, et a tout détecté correctement. Ce n'est que quand j'ai changé la Matrox pour une GeForce qu'il a fallu que je fasse venir un driver car la carte était trop récente par rapport à mon OS. Par contre sous Mandrake il a fallu que je touille pour détecter que le Zip était géré par imm et non ppa, la Matrox Millenium est sortie noire, car il n'y avait pas "assez de mémoire vidéo pour la profondeur choisie -24 bits", et je n'ai pas pu compiler le driver pour l'Aureal, tandis que les drivers Alsa n'étaient pas assez récents pour avoir ledit support.
Les utilisateurs de Windows sont habitués à faire cette gymnastique de drivers au point que quand ils arrivent sous Linux, ils se plaignent du manque de drivers pour celui-ci tout simplement parce que c'est soit déjà intégré, soit parfaitement inutile.
Il faut te moderniser, c'est fini tout ça.
--
Michel TALON
talon
Stephane TOUGARD wrote:
Je te parlais d'UFS en async et non en suftupdates, ce qui n'a strictement rien a voir.
J'avais bien compris mais un UFS en asynchrone c'est encore plus
dangereux qu'un ext2, pour la raison que l'UFS gère des blocs et des fragments, tandis que l'ext2 a supprimé les fragments, ce qui fait qu'une coupure de courant en plein milieu d'une opération compliquée comprenant la réorganisation de fragments en blocs avec toutes les écritures nécessaires risque bien plus de mettre la zone. Comme UFS+softupdates est en fait aussi rapide que UFS asynchrone sur une machine qui n'est pas anémique, il faut être malade pour utiliser l'asynchrone sur un serveur. D'ailleurs exactement comme il faut l'être pour utiliser ext2 sur un serveur, et pourtant on l'a fait des années.
De toute façon aussi bien ext2 que UFS risquent fort de disparaître pour la simple raison qu'au cas où un fsck est nécessaire sur les disques gigantesques actuels, c'est plusieurs heures qu'il faut pour y parvenir, et ceci est inacceptable sur un serveur. Donc les systèmes journalisés, Reiserfs, XFS, JFS, et n'oublions pas le NTFS de Windows sont la voie de l'avenir.
--
Michel TALON
Stephane TOUGARD <stephane@unices.org> wrote:
Je te parlais d'UFS en async et non en suftupdates, ce qui n'a
strictement rien a voir.
J'avais bien compris mais un UFS en asynchrone c'est encore plus
dangereux qu'un ext2, pour la raison que l'UFS gère des blocs et des
fragments, tandis que l'ext2 a supprimé les fragments, ce qui fait
qu'une coupure de courant en plein milieu d'une opération compliquée
comprenant la réorganisation de fragments en blocs avec toutes les
écritures nécessaires risque bien plus de mettre la zone. Comme
UFS+softupdates est en fait aussi rapide que UFS asynchrone sur une
machine qui n'est pas anémique, il faut être malade pour utiliser
l'asynchrone sur un serveur. D'ailleurs exactement comme il faut l'être
pour utiliser ext2 sur un serveur, et pourtant on l'a fait des années.
De toute façon aussi bien ext2 que UFS risquent fort de disparaître
pour la simple raison qu'au cas où un fsck est nécessaire sur les disques
gigantesques actuels, c'est plusieurs heures qu'il faut pour y parvenir,
et ceci est inacceptable sur un serveur. Donc les systèmes journalisés,
Reiserfs, XFS, JFS, et n'oublions pas le NTFS de Windows sont la voie de
l'avenir.
Je te parlais d'UFS en async et non en suftupdates, ce qui n'a strictement rien a voir.
J'avais bien compris mais un UFS en asynchrone c'est encore plus
dangereux qu'un ext2, pour la raison que l'UFS gère des blocs et des fragments, tandis que l'ext2 a supprimé les fragments, ce qui fait qu'une coupure de courant en plein milieu d'une opération compliquée comprenant la réorganisation de fragments en blocs avec toutes les écritures nécessaires risque bien plus de mettre la zone. Comme UFS+softupdates est en fait aussi rapide que UFS asynchrone sur une machine qui n'est pas anémique, il faut être malade pour utiliser l'asynchrone sur un serveur. D'ailleurs exactement comme il faut l'être pour utiliser ext2 sur un serveur, et pourtant on l'a fait des années.
De toute façon aussi bien ext2 que UFS risquent fort de disparaître pour la simple raison qu'au cas où un fsck est nécessaire sur les disques gigantesques actuels, c'est plusieurs heures qu'il faut pour y parvenir, et ceci est inacceptable sur un serveur. Donc les systèmes journalisés, Reiserfs, XFS, JFS, et n'oublions pas le NTFS de Windows sont la voie de l'avenir.
--
Michel TALON
Sam Hocevar
On Sun, 21 Dec 2003 15:58:26 +0000 (UTC), Michel Talon wrote:
[...] il faut être malade pour utiliser l'asynchrone sur un serveur. D'ailleurs exactement comme il faut l'être pour utiliser ext2 sur un serveur, et pourtant on l'a fait des années.
Je trouve toujours amusant de voir un FreeBSDiste pisser comme ca sur 20 ans d'histoire et de philosophie Unix. Ça démontre beaucoup de choses.
-- Sam.
On Sun, 21 Dec 2003 15:58:26 +0000 (UTC), Michel Talon wrote:
[...] il faut être malade pour utiliser
l'asynchrone sur un serveur. D'ailleurs exactement comme il faut l'être
pour utiliser ext2 sur un serveur, et pourtant on l'a fait des années.
Je trouve toujours amusant de voir un FreeBSDiste pisser comme ca sur
20 ans d'histoire et de philosophie Unix. Ça démontre beaucoup de choses.
On Sun, 21 Dec 2003 15:58:26 +0000 (UTC), Michel Talon wrote:
[...] il faut être malade pour utiliser l'asynchrone sur un serveur. D'ailleurs exactement comme il faut l'être pour utiliser ext2 sur un serveur, et pourtant on l'a fait des années.
Je trouve toujours amusant de voir un FreeBSDiste pisser comme ca sur 20 ans d'histoire et de philosophie Unix. Ça démontre beaucoup de choses.
-- Sam.
Emmanuel Florac
Dans article <slrnbubmh4.oli.sam+, sam+ disait...
Je trouve toujours amusant de voir un FreeBSDiste pisser comme ca sur 20 ans d'histoire et de philosophie Unix. Ça démontre beaucoup de choses.
Arf :)
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <slrnbubmh4.oli.sam+news@poulet.zoy.org>, sam+news@zoy.org
disait...
Je trouve toujours amusant de voir un FreeBSDiste pisser comme ca sur
20 ans d'histoire et de philosophie Unix. Ça démontre beaucoup de choses.
Arf :)
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Je trouve toujours amusant de voir un FreeBSDiste pisser comme ca sur 20 ans d'histoire et de philosophie Unix. Ça démontre beaucoup de choses.
Arf :)
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Vincent Bernat
OoO En cette aube naissante du dimanche 21 décembre 2003, vers 07:49, (Michel Talon) disait:
C'est pour ça que si tu installes une carte vidéo nvidia il suffit d'installer le driver windows nvidia qui marche quel que soit le modèle de la carte (idem sous Linux d'ailleurs).
Inexact, le driver nvidia ne marche pas pour la Geforce2 Go.
C'est pour ça que sur la machine que j'ai installée la semaine dernière sous Windows XP, et qui comprenait une Matrox Millenium II, deux cartes réseau, une 3COM et une Netgear, une carte son Aureal Vortex, et un Zip sur port parallèle, il ne m'a pas fallu installer un seul driver, WinXP avait tous les drivers appropriés sur son CDROM, et a tout détecté correctement.
Si tu avais une 3com 590, il t'aurait fallu aller sur le net. Je parle bien d'une carte PCI dont le pilotage est a priori très proche d'une 3Com 3c59x.
Les utilisateurs de Windows sont habitués à faire cette gymnastique de drivers au point que quand ils arrivent sous Linux, ils se plaignent du manque de drivers pour celui-ci tout simplement parce que c'est soit déjà intégré, soit parfaitement inutile.
Il faut te moderniser, c'est fini tout ça.
Ben voyons. Pourquoi diable tous les produits que j'achète viennent avec des drivers pour _XP_ ? Seul le lecteur de carte CF sur port USB échappe à la règle. Tout le reste vient avec un driver qui en profite pour installer une flopée de logiciels.
De plus, une fois le XP installé, te voilà parti pour mettre à jour DirectX, ajouter les VIA 4-in-1, mettre à jour ton driver de Sound Blaster parce que le EAX 2 foire avec le tient dans les jeux, aller récupérer un driver pour ton scanner USB, puis pour ton imprimante, etc.
Sous Linux, tu mets à jour ton noyau vers un plus récent (un coup de apt-get ou urpmi) et te voilà à jour sur pas mal de point. Niveau imprimante et scanner, la Mandrake gère ça toute seule, pour les autres, tout réside en un seul logiciel : xsane pour un scanner, cups pour l'imprimante. Tout est donc homogénéisé. Pas la peine d'aller te perdre sur le site de tel constructeur pour trouver le dernier driver de ton imprimante, ta distrib s'occupe de mettre cela à niveau comme le reste.
Je répète : du moment que tu as eu un noyau ou un logiciel qui a géré ton matériel, si tu mets ta distrib à jour, le reste vient avec. Ce qui est à 100 lieues de ce que fait Windows vu que : - le windowsupdate se limite aux mises à jour de Windows et non aux drivers (ne me parlez pas de la partie qui met à jour les drivers, elle est en retard et totalement inefficace la plupart du temps) - le windowsupdate est bien incapable de te mettre à jour tout et simplement (cette mise à jour doit être faite séparément) - tu n'as aucun moyen simple de savoir si tu es à jour sur tous les drivers, il te faut aller parcourir les sites des constructeurs pour voir si y'a pas un driver plus récent
Windows se contente de mettre sur un CD des drivers pas trop vieux, pas trop récents. Ça marche sans doute très bien au moment de la sortie mais est inutilisable quelques années après (sauf évidemment si on affectionne la arpentage des sites Web à la recherche des drivers plus récents). -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette aube naissante du dimanche 21 décembre 2003, vers 07:49,
talon@lpthe.jussieu.fr (Michel Talon) disait:
C'est pour ça que si tu installes une carte vidéo nvidia il suffit
d'installer le driver windows nvidia qui marche quel que soit le
modèle de la carte (idem sous Linux d'ailleurs).
Inexact, le driver nvidia ne marche pas pour la Geforce2 Go.
C'est pour ça que sur la machine que j'ai installée la semaine
dernière sous Windows XP, et qui comprenait une Matrox Millenium II,
deux cartes réseau, une 3COM et une Netgear, une carte son Aureal
Vortex, et un Zip sur port parallèle, il ne m'a pas fallu installer
un seul driver, WinXP avait tous les drivers appropriés sur son
CDROM, et a tout détecté correctement.
Si tu avais une 3com 590, il t'aurait fallu aller sur le net. Je parle
bien d'une carte PCI dont le pilotage est a priori très proche d'une
3Com 3c59x.
Les utilisateurs de Windows sont habitués à faire cette gymnastique
de drivers au point que quand ils arrivent sous Linux, ils se
plaignent du manque de drivers pour celui-ci tout simplement parce
que c'est soit déjà intégré, soit parfaitement inutile.
Il faut te moderniser, c'est fini tout ça.
Ben voyons. Pourquoi diable tous les produits que j'achète viennent
avec des drivers pour _XP_ ? Seul le lecteur de carte CF sur port USB
échappe à la règle. Tout le reste vient avec un driver qui en profite
pour installer une flopée de logiciels.
De plus, une fois le XP installé, te voilà parti pour mettre à jour
DirectX, ajouter les VIA 4-in-1, mettre à jour ton driver de Sound
Blaster parce que le EAX 2 foire avec le tient dans les jeux, aller
récupérer un driver pour ton scanner USB, puis pour ton imprimante,
etc.
Sous Linux, tu mets à jour ton noyau vers un plus récent (un coup de
apt-get ou urpmi) et te voilà à jour sur pas mal de point. Niveau
imprimante et scanner, la Mandrake gère ça toute seule, pour les
autres, tout réside en un seul logiciel : xsane pour un scanner, cups
pour l'imprimante. Tout est donc homogénéisé. Pas la peine d'aller te
perdre sur le site de tel constructeur pour trouver le dernier driver
de ton imprimante, ta distrib s'occupe de mettre cela à niveau comme
le reste.
Je répète : du moment que tu as eu un noyau ou un logiciel qui a géré
ton matériel, si tu mets ta distrib à jour, le reste vient avec. Ce
qui est à 100 lieues de ce que fait Windows vu que :
- le windowsupdate se limite aux mises à jour de Windows et non aux
drivers (ne me parlez pas de la partie qui met à jour les drivers,
elle est en retard et totalement inefficace la plupart du temps)
- le windowsupdate est bien incapable de te mettre à jour tout et
simplement (cette mise à jour doit être faite séparément)
- tu n'as aucun moyen simple de savoir si tu es à jour sur tous les
drivers, il te faut aller parcourir les sites des constructeurs
pour voir si y'a pas un driver plus récent
Windows se contente de mettre sur un CD des drivers pas trop vieux,
pas trop récents. Ça marche sans doute très bien au moment de la
sortie mais est inutilisable quelques années après (sauf évidemment si
on affectionne la arpentage des sites Web à la recherche des drivers
plus récents).
--
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette aube naissante du dimanche 21 décembre 2003, vers 07:49, (Michel Talon) disait:
C'est pour ça que si tu installes une carte vidéo nvidia il suffit d'installer le driver windows nvidia qui marche quel que soit le modèle de la carte (idem sous Linux d'ailleurs).
Inexact, le driver nvidia ne marche pas pour la Geforce2 Go.
C'est pour ça que sur la machine que j'ai installée la semaine dernière sous Windows XP, et qui comprenait une Matrox Millenium II, deux cartes réseau, une 3COM et une Netgear, une carte son Aureal Vortex, et un Zip sur port parallèle, il ne m'a pas fallu installer un seul driver, WinXP avait tous les drivers appropriés sur son CDROM, et a tout détecté correctement.
Si tu avais une 3com 590, il t'aurait fallu aller sur le net. Je parle bien d'une carte PCI dont le pilotage est a priori très proche d'une 3Com 3c59x.
Les utilisateurs de Windows sont habitués à faire cette gymnastique de drivers au point que quand ils arrivent sous Linux, ils se plaignent du manque de drivers pour celui-ci tout simplement parce que c'est soit déjà intégré, soit parfaitement inutile.
Il faut te moderniser, c'est fini tout ça.
Ben voyons. Pourquoi diable tous les produits que j'achète viennent avec des drivers pour _XP_ ? Seul le lecteur de carte CF sur port USB échappe à la règle. Tout le reste vient avec un driver qui en profite pour installer une flopée de logiciels.
De plus, une fois le XP installé, te voilà parti pour mettre à jour DirectX, ajouter les VIA 4-in-1, mettre à jour ton driver de Sound Blaster parce que le EAX 2 foire avec le tient dans les jeux, aller récupérer un driver pour ton scanner USB, puis pour ton imprimante, etc.
Sous Linux, tu mets à jour ton noyau vers un plus récent (un coup de apt-get ou urpmi) et te voilà à jour sur pas mal de point. Niveau imprimante et scanner, la Mandrake gère ça toute seule, pour les autres, tout réside en un seul logiciel : xsane pour un scanner, cups pour l'imprimante. Tout est donc homogénéisé. Pas la peine d'aller te perdre sur le site de tel constructeur pour trouver le dernier driver de ton imprimante, ta distrib s'occupe de mettre cela à niveau comme le reste.
Je répète : du moment que tu as eu un noyau ou un logiciel qui a géré ton matériel, si tu mets ta distrib à jour, le reste vient avec. Ce qui est à 100 lieues de ce que fait Windows vu que : - le windowsupdate se limite aux mises à jour de Windows et non aux drivers (ne me parlez pas de la partie qui met à jour les drivers, elle est en retard et totalement inefficace la plupart du temps) - le windowsupdate est bien incapable de te mettre à jour tout et simplement (cette mise à jour doit être faite séparément) - tu n'as aucun moyen simple de savoir si tu es à jour sur tous les drivers, il te faut aller parcourir les sites des constructeurs pour voir si y'a pas un driver plus récent
Windows se contente de mettre sur un CD des drivers pas trop vieux, pas trop récents. Ça marche sans doute très bien au moment de la sortie mais est inutilisable quelques années après (sauf évidemment si on affectionne la arpentage des sites Web à la recherche des drivers plus récents). -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plaugher)
Vincent Bernat
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. -- #if 0 2.2.16 /usr/src/linux/fs/buffer.c
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.
--
#if 0
2.2.16 /usr/src/linux/fs/buffer.c
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. -- #if 0 2.2.16 /usr/src/linux/fs/buffer.c
