Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit
être une espèce de process qui tient de la licorne ou du minautaure, vu
les latences de l'OS.
Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit
être une espèce de process qui tient de la licorne ou du minautaure, vu
les latences de l'OS.
Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit
être une espèce de process qui tient de la licorne ou du minautaure, vu
les latences de l'OS.
Michel Talon wrote:2.0 et 2.2 étaient encore bien pires que 2.4, là tu peux dire que
c'étaient des bouses infâmes par rapport à FreeBSD, et je l'ai
vérifié sur la même machine, exactement comme tu dis. D'ailleurs, à part
toi, personne ne le conteste, juqu'au développeurs de Linux 2.6 qui
disent qu'ils ont enfin réussi à faire à peu prés aussi bien que
FreeBSD.
Je ne conteste rien, je remarque juste qu'a part ton KDE qui a des
chaleurs, tu n'as rien de precis pour prouver tes propos. Aucun code
particulier de test, aucune situation reproductible, ...
C'est plutot dogmatique tout ca.
Michel Talon wrote:
2.0 et 2.2 étaient encore bien pires que 2.4, là tu peux dire que
c'étaient des bouses infâmes par rapport à FreeBSD, et je l'ai
vérifié sur la même machine, exactement comme tu dis. D'ailleurs, à part
toi, personne ne le conteste, juqu'au développeurs de Linux 2.6 qui
disent qu'ils ont enfin réussi à faire à peu prés aussi bien que
FreeBSD.
Je ne conteste rien, je remarque juste qu'a part ton KDE qui a des
chaleurs, tu n'as rien de precis pour prouver tes propos. Aucun code
particulier de test, aucune situation reproductible, ...
C'est plutot dogmatique tout ca.
Michel Talon wrote:2.0 et 2.2 étaient encore bien pires que 2.4, là tu peux dire que
c'étaient des bouses infâmes par rapport à FreeBSD, et je l'ai
vérifié sur la même machine, exactement comme tu dis. D'ailleurs, à part
toi, personne ne le conteste, juqu'au développeurs de Linux 2.6 qui
disent qu'ils ont enfin réussi à faire à peu prés aussi bien que
FreeBSD.
Je ne conteste rien, je remarque juste qu'a part ton KDE qui a des
chaleurs, tu n'as rien de precis pour prouver tes propos. Aucun code
particulier de test, aucune situation reproductible, ...
C'est plutot dogmatique tout ca.
Sebastien Tanguy wrote:Bah tiens, je fais pas des serveurs d'uptime sous windows à mon boulot
comme certains en font sous Linux, Hurd ou je ne sais quoi dans leur
placard...
Je ne sais pas sous Windows, mais sous Unix, il suffit de taper ca
:~$ uptime
07:55:01 up 143 days, 16:50, 1 user, load average: 0.00, 0.00, 0.00
:~$ uname -a
Linux eagle 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i686 unknown
:~$
Voila, je sais que cette machine est up depuis 143 jours et je sais ce
que c'est (PS: 143 jours, ca correspond a sa date d'installation, c'est
juste un exemple).
Sans rigoler, ton meilleur uptime, c'est quoi ?
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?
Entre nous, un uptime, c'est le temps entre deux reboot, qu'ils soient
volontaires ou non, dus a une panne de courant, a une operation de
maintenance ou a un plantage.
Tu fais quoi avec du Linux, alors ?
Des serveurs, des firewalls, du transactionnel, de l'espace disque, bref
mon metier et rien que Windows n'a fait aussi bien que le pire des
Unices.
Tu sors des on-dit et des préjugés. Stable ? J'ai vu des Linux se
faire reformater la partition système en appuyant sur une touche à
cause de drivers foireux. Fonctionnel ? Sors moi une installation type
Tu as vu ? mais tu m'impressionnes fortement d'avoir vu un driver
foireux reformater une partition, t'es sur que tu confonds pas avec un
systeme Microsoftien ?
Parce que lorsque M Talon nous fait un Troll sur Linux, il a au moins
pour lui de s'appuyer sur une base (tres faible certe) de verite. Mais
la, tu dois confondre fantasme et realite.
Dans ton cas, c'est tellement peu credible, qu'on depasse a peine le
stade de la blague de potache.
Sebastien Tanguy wrote:
Bah tiens, je fais pas des serveurs d'uptime sous windows à mon boulot
comme certains en font sous Linux, Hurd ou je ne sais quoi dans leur
placard...
Je ne sais pas sous Windows, mais sous Unix, il suffit de taper ca
elair@eagle:~$ uptime
07:55:01 up 143 days, 16:50, 1 user, load average: 0.00, 0.00, 0.00
elair@eagle:~$ uname -a
Linux eagle 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i686 unknown
elair@eagle:~$
Voila, je sais que cette machine est up depuis 143 jours et je sais ce
que c'est (PS: 143 jours, ca correspond a sa date d'installation, c'est
juste un exemple).
Sans rigoler, ton meilleur uptime, c'est quoi ?
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?
Entre nous, un uptime, c'est le temps entre deux reboot, qu'ils soient
volontaires ou non, dus a une panne de courant, a une operation de
maintenance ou a un plantage.
Tu fais quoi avec du Linux, alors ?
Des serveurs, des firewalls, du transactionnel, de l'espace disque, bref
mon metier et rien que Windows n'a fait aussi bien que le pire des
Unices.
Tu sors des on-dit et des préjugés. Stable ? J'ai vu des Linux se
faire reformater la partition système en appuyant sur une touche à
cause de drivers foireux. Fonctionnel ? Sors moi une installation type
Tu as vu ? mais tu m'impressionnes fortement d'avoir vu un driver
foireux reformater une partition, t'es sur que tu confonds pas avec un
systeme Microsoftien ?
Parce que lorsque M Talon nous fait un Troll sur Linux, il a au moins
pour lui de s'appuyer sur une base (tres faible certe) de verite. Mais
la, tu dois confondre fantasme et realite.
Dans ton cas, c'est tellement peu credible, qu'on depasse a peine le
stade de la blague de potache.
Sebastien Tanguy wrote:Bah tiens, je fais pas des serveurs d'uptime sous windows à mon boulot
comme certains en font sous Linux, Hurd ou je ne sais quoi dans leur
placard...
Je ne sais pas sous Windows, mais sous Unix, il suffit de taper ca
:~$ uptime
07:55:01 up 143 days, 16:50, 1 user, load average: 0.00, 0.00, 0.00
:~$ uname -a
Linux eagle 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i686 unknown
:~$
Voila, je sais que cette machine est up depuis 143 jours et je sais ce
que c'est (PS: 143 jours, ca correspond a sa date d'installation, c'est
juste un exemple).
Sans rigoler, ton meilleur uptime, c'est quoi ?
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?
Entre nous, un uptime, c'est le temps entre deux reboot, qu'ils soient
volontaires ou non, dus a une panne de courant, a une operation de
maintenance ou a un plantage.
Tu fais quoi avec du Linux, alors ?
Des serveurs, des firewalls, du transactionnel, de l'espace disque, bref
mon metier et rien que Windows n'a fait aussi bien que le pire des
Unices.
Tu sors des on-dit et des préjugés. Stable ? J'ai vu des Linux se
faire reformater la partition système en appuyant sur une touche à
cause de drivers foireux. Fonctionnel ? Sors moi une installation type
Tu as vu ? mais tu m'impressionnes fortement d'avoir vu un driver
foireux reformater une partition, t'es sur que tu confonds pas avec un
systeme Microsoftien ?
Parce que lorsque M Talon nous fait un Troll sur Linux, il a au moins
pour lui de s'appuyer sur une base (tres faible certe) de verite. Mais
la, tu dois confondre fantasme et realite.
Dans ton cas, c'est tellement peu credible, qu'on depasse a peine le
stade de la blague de potache.
La littérature sur la gestion de la mémoire par Linux est quand même
abondante. Il était notoire que Linux marchait mal sur les systèmes
multiprocesseurs (> 16 CPU) qui faisaient tourner des milliers de
processus, car il passait tout son temps dans le gestionnaire de VM, les
I/O,... Désormais, ce problème semble résolu avec le noyau 2.6. Cf par
exemple : http://dsoulayrol.free.fr/articles/wonderful_2.6.html, pour voir
les améliorations aportés par le noyau 2.6
La littérature sur la gestion de la mémoire par Linux est quand même
abondante. Il était notoire que Linux marchait mal sur les systèmes
multiprocesseurs (> 16 CPU) qui faisaient tourner des milliers de
processus, car il passait tout son temps dans le gestionnaire de VM, les
I/O,... Désormais, ce problème semble résolu avec le noyau 2.6. Cf par
exemple : http://dsoulayrol.free.fr/articles/wonderful_2.6.html, pour voir
les améliorations aportés par le noyau 2.6
La littérature sur la gestion de la mémoire par Linux est quand même
abondante. Il était notoire que Linux marchait mal sur les systèmes
multiprocesseurs (> 16 CPU) qui faisaient tourner des milliers de
processus, car il passait tout son temps dans le gestionnaire de VM, les
I/O,... Désormais, ce problème semble résolu avec le noyau 2.6. Cf par
exemple : http://dsoulayrol.free.fr/articles/wonderful_2.6.html, pour voir
les améliorations aportés par le noyau 2.6
[] % snmpget -c ***** -v1 tirpitz SNMPv2-MIB::sysDescr.0
SNMPv2-MIB::sysUpTime.0
SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 15 Model 2 Stepping 7
AT/AT COMPATIBLE - Software: Windows 2000 Version 5.0
(Build 2195 Uniprocessor Free)
SNMPv2-MIB::sysUpTime.0 = Timeticks: (110599359) 12 days, 19:13:13.59
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?
À ton avis, quelle est la signification du mot "mais" dans ma phrase ?
Mais sinon, c'était de la Debian testing ou unstable (pour avoir une
version de X décente), avec un noyau 2.2.19 ou 2.2.20 et de l'ext2fs.
[seb@batavia] % snmpget -c ***** -v1 tirpitz SNMPv2-MIB::sysDescr.0
SNMPv2-MIB::sysUpTime.0
SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 15 Model 2 Stepping 7
AT/AT COMPATIBLE - Software: Windows 2000 Version 5.0
(Build 2195 Uniprocessor Free)
SNMPv2-MIB::sysUpTime.0 = Timeticks: (110599359) 12 days, 19:13:13.59
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?
À ton avis, quelle est la signification du mot "mais" dans ma phrase ?
Mais sinon, c'était de la Debian testing ou unstable (pour avoir une
version de X décente), avec un noyau 2.2.19 ou 2.2.20 et de l'ext2fs.
[] % snmpget -c ***** -v1 tirpitz SNMPv2-MIB::sysDescr.0
SNMPv2-MIB::sysUpTime.0
SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 15 Model 2 Stepping 7
AT/AT COMPATIBLE - Software: Windows 2000 Version 5.0
(Build 2195 Uniprocessor Free)
SNMPv2-MIB::sysUpTime.0 = Timeticks: (110599359) 12 days, 19:13:13.59
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?
À ton avis, quelle est la signification du mot "mais" dans ma phrase ?
Mais sinon, c'était de la Debian testing ou unstable (pour avoir une
version de X décente), avec un noyau 2.2.19 ou 2.2.20 et de l'ext2fs.
T'es a douze jours quand meme, c'est a dire la moitie du record d'uptime
pour un W2000 installe en tant que serveur et en prod. C'est pas mal.
J'exagere, j'ai vu des NT tenir 60 jours.
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?
À ton avis, quelle est la signification du mot "mais" dans ma phrase ?
Attends, je te demande ton meilleur uptime et tu me reponds un an, deux
ans, ensuite tu me confirmes malgre tout que tu rebootes a cause d'un
"mais" dans ta phrase.
Je repose ma question : ton meilleur uptime avec un W2K, c'est combien
de jours (on va pas parler en mois, je comprends le cote desagreable a
parler en fractions) ?
Mais sinon, c'était de la Debian testing ou unstable (pour avoir une
version de X décente), avec un noyau 2.2.19 ou 2.2.20 et de l'ext2fs.
Et un driver proprietaire dont le code source se resume a :
#!/bin/sh
mke2fs /dev/hda1
Bien sur, je comprends.
T'es a douze jours quand meme, c'est a dire la moitie du record d'uptime
pour un W2000 installe en tant que serveur et en prod. C'est pas mal.
J'exagere, j'ai vu des NT tenir 60 jours.
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?
À ton avis, quelle est la signification du mot "mais" dans ma phrase ?
Attends, je te demande ton meilleur uptime et tu me reponds un an, deux
ans, ensuite tu me confirmes malgre tout que tu rebootes a cause d'un
"mais" dans ta phrase.
Je repose ma question : ton meilleur uptime avec un W2K, c'est combien
de jours (on va pas parler en mois, je comprends le cote desagreable a
parler en fractions) ?
Mais sinon, c'était de la Debian testing ou unstable (pour avoir une
version de X décente), avec un noyau 2.2.19 ou 2.2.20 et de l'ext2fs.
Et un driver proprietaire dont le code source se resume a :
#!/bin/sh
mke2fs /dev/hda1
Bien sur, je comprends.
T'es a douze jours quand meme, c'est a dire la moitie du record d'uptime
pour un W2000 installe en tant que serveur et en prod. C'est pas mal.
J'exagere, j'ai vu des NT tenir 60 jours.
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?
À ton avis, quelle est la signification du mot "mais" dans ma phrase ?
Attends, je te demande ton meilleur uptime et tu me reponds un an, deux
ans, ensuite tu me confirmes malgre tout que tu rebootes a cause d'un
"mais" dans ta phrase.
Je repose ma question : ton meilleur uptime avec un W2K, c'est combien
de jours (on va pas parler en mois, je comprends le cote desagreable a
parler en fractions) ?
Mais sinon, c'était de la Debian testing ou unstable (pour avoir une
version de X décente), avec un noyau 2.2.19 ou 2.2.20 et de l'ext2fs.
Et un driver proprietaire dont le code source se resume a :
#!/bin/sh
mke2fs /dev/hda1
Bien sur, je comprends.
J'exagere, j'ai vu des NT tenir 60 jours.
Et tu es parti de dépit ?
J'ai dit avoir eu des NT (sous entendu du 4.0) avec un à deux ans
d'uptime. Comme ceux-ci étaient dans un environnement particulier, il
n'y avait pas besoin de les patcher spécialement hormis les besoins
spécifiques à la prod et à aux éléments validés.
fonctionner des machines windows 2000 mieux que tu ne le ferais avec
tes propres Linux.
Non, ça aurait plutôt été de l'ordre du dd if=/dev/random of=/dev/hda,
mais en l'occurrence, pour faire de l'OpenGL, cela aurait été un peu
léger.
J'exagere, j'ai vu des NT tenir 60 jours.
Et tu es parti de dépit ?
J'ai dit avoir eu des NT (sous entendu du 4.0) avec un à deux ans
d'uptime. Comme ceux-ci étaient dans un environnement particulier, il
n'y avait pas besoin de les patcher spécialement hormis les besoins
spécifiques à la prod et à aux éléments validés.
fonctionner des machines windows 2000 mieux que tu ne le ferais avec
tes propres Linux.
Non, ça aurait plutôt été de l'ordre du dd if=/dev/random of=/dev/hda,
mais en l'occurrence, pour faire de l'OpenGL, cela aurait été un peu
léger.
J'exagere, j'ai vu des NT tenir 60 jours.
Et tu es parti de dépit ?
J'ai dit avoir eu des NT (sous entendu du 4.0) avec un à deux ans
d'uptime. Comme ceux-ci étaient dans un environnement particulier, il
n'y avait pas besoin de les patcher spécialement hormis les besoins
spécifiques à la prod et à aux éléments validés.
fonctionner des machines windows 2000 mieux que tu ne le ferais avec
tes propres Linux.
Non, ça aurait plutôt été de l'ordre du dd if=/dev/random of=/dev/hda,
mais en l'occurrence, pour faire de l'OpenGL, cela aurait été un peu
léger.
Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit
être une espèce de process qui tient de la licorne ou du minautaure, vu
les latences de l'OS.
Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit
être une espèce de process qui tient de la licorne ou du minautaure, vu
les latences de l'OS.
Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit
être une espèce de process qui tient de la licorne ou du minautaure, vu
les latences de l'OS.
Tu devrais aller prévenir Microsoft, ils seraient vraiment intéressés
par voir tes systèmes parce que, eux, ils n'y arrivent pas.
Je pense qu'ils y arrivent, même s'ils ont fait des déclarations sur
des systèmes en développement qui vont dans le sens contraire...
Tu devrais aller prévenir Microsoft, ils seraient vraiment intéressés
par voir tes systèmes parce que, eux, ils n'y arrivent pas.
Je pense qu'ils y arrivent, même s'ils ont fait des déclarations sur
des systèmes en développement qui vont dans le sens contraire...
Tu devrais aller prévenir Microsoft, ils seraient vraiment intéressés
par voir tes systèmes parce que, eux, ils n'y arrivent pas.
Je pense qu'ils y arrivent, même s'ils ont fait des déclarations sur
des systèmes en développement qui vont dans le sens contraire...
Sinon, ssh, hein, y'a pas besoin d'une interface graphique pour
utiliser un Linux à distance.
Le sujet des échanges était "de l'utilisation de X Window en réseau,
par rapport à windows", pas "utiliser Linux à distance".
Sinon, ssh, hein, y'a pas besoin d'une interface graphique pour
utiliser un Linux à distance.
Le sujet des échanges était "de l'utilisation de X Window en réseau,
par rapport à windows", pas "utiliser Linux à distance".
Sinon, ssh, hein, y'a pas besoin d'une interface graphique pour
utiliser un Linux à distance.
Le sujet des échanges était "de l'utilisation de X Window en réseau,
par rapport à windows", pas "utiliser Linux à distance".