Finalement la bonne solution, c'est de leur vendre très cher les
applications opensource.
Finalement la bonne solution, c'est de leur vendre très cher les
applications opensource.
Finalement la bonne solution, c'est de leur vendre très cher les
applications opensource.
(Michel Talon) writes:Patrice Karatchentzeff wrote:
Mouarf. Bien avant le débarquement des mastodontes (disons la série
2.0, je ne suis même pas sûr pour le 2.2), le noyau était déjà
largement un truc professionnel...
Mais oui, un truc professionnel pour faire tourner sur le Pécé de la cave.
Tu sais, les IBM haut de gamme aujourd'hui, c'est du pécé...
PK
talon@lpthe.jussieu.fr (Michel Talon) writes:
Patrice Karatchentzeff <p.karatchentzeff@free.fr> wrote:
Mouarf. Bien avant le débarquement des mastodontes (disons la série
2.0, je ne suis même pas sûr pour le 2.2), le noyau était déjà
largement un truc professionnel...
Mais oui, un truc professionnel pour faire tourner sur le Pécé de la cave.
Tu sais, les IBM haut de gamme aujourd'hui, c'est du pécé...
PK
(Michel Talon) writes:Patrice Karatchentzeff wrote:
Mouarf. Bien avant le débarquement des mastodontes (disons la série
2.0, je ne suis même pas sûr pour le 2.2), le noyau était déjà
largement un truc professionnel...
Mais oui, un truc professionnel pour faire tourner sur le Pécé de la cave.
Tu sais, les IBM haut de gamme aujourd'hui, c'est du pécé...
PK
Patrice Karatchentzeff wrote:
Tu sais, les IBM haut de gamme aujourd'hui, c'est du pécé...
Avec combien de processeurs, combien de mémoire, combien de disques,
etc. ?
Avec un Linux 2.0 ou 2.2 ajouter des processeurs soit ne change rien quand il
ne les voit pas soit fait baisser les performances s'il les voit. La
quantité
de mémoire qu'il peut gérer est trés limitée, le swap limité à une quantité
dérisoire, la gestion de la VM, il vaut mieux ne pas en parler, les
systèmes de fichier c'est le salaire de la peur en cas de coupure de courant, la couche
réseau ça doit marcher à peu prés sur du 10 Mb et perdre la moitié des
paquets au delà, et tout à l'avenant.
Patrice Karatchentzeff <p.karatchentzeff@free.fr> wrote:
Tu sais, les IBM haut de gamme aujourd'hui, c'est du pécé...
Avec combien de processeurs, combien de mémoire, combien de disques,
etc. ?
Avec un Linux 2.0 ou 2.2 ajouter des processeurs soit ne change rien quand il
ne les voit pas soit fait baisser les performances s'il les voit. La
quantité
de mémoire qu'il peut gérer est trés limitée, le swap limité à une quantité
dérisoire, la gestion de la VM, il vaut mieux ne pas en parler, les
systèmes de fichier c'est le salaire de la peur en cas de coupure de courant, la couche
réseau ça doit marcher à peu prés sur du 10 Mb et perdre la moitié des
paquets au delà, et tout à l'avenant.
Patrice Karatchentzeff wrote:
Tu sais, les IBM haut de gamme aujourd'hui, c'est du pécé...
Avec combien de processeurs, combien de mémoire, combien de disques,
etc. ?
Avec un Linux 2.0 ou 2.2 ajouter des processeurs soit ne change rien quand il
ne les voit pas soit fait baisser les performances s'il les voit. La
quantité
de mémoire qu'il peut gérer est trés limitée, le swap limité à une quantité
dérisoire, la gestion de la VM, il vaut mieux ne pas en parler, les
systèmes de fichier c'est le salaire de la peur en cas de coupure de courant, la couche
réseau ça doit marcher à peu prés sur du 10 Mb et perdre la moitié des
paquets au delà, et tout à l'avenant.
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris...
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris...
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris...
Le Fri, 14 Apr 2006 09:00:09 +0200, Patrice Karatchentzeff a écrit :
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris...
:) En tout cas j'ai eu des uptimes de plusieurs mois sur un 486 serveur
ftp avec un noyau 1.1, et aussi avec un serveur de dév principal
(serveur de fichiers, DNS, de mail, etc) sous RH 6.2 (linux 2.0 je crois?
ou 2.2?) qui a eu un uptime de plus de 6 mois...
Le Fri, 14 Apr 2006 09:00:09 +0200, Patrice Karatchentzeff a écrit :
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris...
:) En tout cas j'ai eu des uptimes de plusieurs mois sur un 486 serveur
ftp avec un noyau 1.1, et aussi avec un serveur de dév principal
(serveur de fichiers, DNS, de mail, etc) sous RH 6.2 (linux 2.0 je crois?
ou 2.2?) qui a eu un uptime de plus de 6 mois...
Le Fri, 14 Apr 2006 09:00:09 +0200, Patrice Karatchentzeff a écrit :
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris...
:) En tout cas j'ai eu des uptimes de plusieurs mois sur un 486 serveur
ftp avec un noyau 1.1, et aussi avec un serveur de dév principal
(serveur de fichiers, DNS, de mail, etc) sous RH 6.2 (linux 2.0 je crois?
ou 2.2?) qui a eu un uptime de plus de 6 mois...
(Michel Talon) writes:de mémoire qu'il peut gérer est trés limitée, le swap limité à une quantité
dérisoire, la gestion de la VM, il vaut mieux ne pas en parler, les
systèmes de fichier c'est le salaire de la peur en cas de coupure de courant, la couche
réseau ça doit marcher à peu prés sur du 10 Mb et perdre la moitié des
paquets au delà, et tout à l'avenant.
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris... il paraît même que certains fous auraient réussi à exécuter
un 'ls' sur un fichier ext2 un jour...
PK
talon@lpthe.jussieu.fr (Michel Talon) writes:
de mémoire qu'il peut gérer est trés limitée, le swap limité à une quantité
dérisoire, la gestion de la VM, il vaut mieux ne pas en parler, les
systèmes de fichier c'est le salaire de la peur en cas de coupure de courant, la couche
réseau ça doit marcher à peu prés sur du 10 Mb et perdre la moitié des
paquets au delà, et tout à l'avenant.
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris... il paraît même que certains fous auraient réussi à exécuter
un 'ls' sur un fichier ext2 un jour...
PK
(Michel Talon) writes:de mémoire qu'il peut gérer est trés limitée, le swap limité à une quantité
dérisoire, la gestion de la VM, il vaut mieux ne pas en parler, les
systèmes de fichier c'est le salaire de la peur en cas de coupure de courant, la couche
réseau ça doit marcher à peu prés sur du 10 Mb et perdre la moitié des
paquets au delà, et tout à l'avenant.
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris... il paraît même que certains fous auraient réussi à exécuter
un 'ls' sur un fichier ext2 un jour...
PK
Patrice Karatchentzeff wrote:(Michel Talon) writes:de mémoire qu'il peut gérer est trés limitée, le swap limité à une quantité
dérisoire, la gestion de la VM, il vaut mieux ne pas en parler, les
systèmes de fichier c'est le salaire de la peur en cas de coupure de courant, la couche
réseau ça doit marcher à peu prés sur du 10 Mb et perdre la moitié des
paquets au delà, et tout à l'avenant.
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris... il paraît même que certains fous auraient réussi à exécuter
un 'ls' sur un fichier ext2 un jour...
Non l'uptime était relativement bon, tant qu'on ne faisait pas une manoeuvre
dangereuse, telle que monter une disquette avec des bad blocks. Si l'uptime
était bon c'est parceque le système était simple, pour ne pas dire simpliste.
Mais simple et performant ça n'existe pas, et ça n'existera jamais.
Quand au système consistant à faire croire qu'on fait des accés disques trés
trés rapides parcequ'on cache tout en mémoire de façon avide, qu'on ne
synchronise le disque que toutes les 30 secondes bien qu'il n'y ait pas de
journal, c'est à dire le ext2 monté async comme c'était de règle à l'époque,
c'est tout sauf professionnel.
La couche réseau a été refaite de fond en
comble 3 ou 4 fois, ce n'est pas pour rien. Encore à l'heure actuelle
sur les noyaux 2.6 il paraît que l'usage de cartes gigabit ethernet entraîne
une perte généreuse de paquets, là où la même machine, avec la même carte sous
Windows n'en perd pas.
Ne parlons pas aussi des latences bien plus grandes que
sous Windows qui handicapaient le système de son considérablement.s
Tous ces
problèmes ont été plus ou moins attaqués par les ingénieurs de Redhat, Suse,
IBM, etc. au prix d'une grande complexification du système. Contrairement
à ce que tu dis le "fine grained locking" est arrivé avec les noyaux 2.4,
et je pense que IBM a contribué le Read Copy Update pour le 2.6. Ce qui
veut dire que les bons résultats en SMP dont Linux peut se targuer maintenant
datent essentiellement du 2.6.
Tu dis que les machines à beaucoup de
processeurs ça n'existe que dans des applications trés spécialisées, ce
n'est pas vrai. Avec des niagara qui sont déjà à 32 processeurs (virtuels)
tout le monde va s'y mettre rapidement.
Patrice Karatchentzeff <p.karatchentzeff@free.fr> wrote:
talon@lpthe.jussieu.fr (Michel Talon) writes:
de mémoire qu'il peut gérer est trés limitée, le swap limité à une quantité
dérisoire, la gestion de la VM, il vaut mieux ne pas en parler, les
systèmes de fichier c'est le salaire de la peur en cas de coupure de courant, la couche
réseau ça doit marcher à peu prés sur du 10 Mb et perdre la moitié des
paquets au delà, et tout à l'avenant.
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris... il paraît même que certains fous auraient réussi à exécuter
un 'ls' sur un fichier ext2 un jour...
Non l'uptime était relativement bon, tant qu'on ne faisait pas une manoeuvre
dangereuse, telle que monter une disquette avec des bad blocks. Si l'uptime
était bon c'est parceque le système était simple, pour ne pas dire simpliste.
Mais simple et performant ça n'existe pas, et ça n'existera jamais.
Quand au système consistant à faire croire qu'on fait des accés disques trés
trés rapides parcequ'on cache tout en mémoire de façon avide, qu'on ne
synchronise le disque que toutes les 30 secondes bien qu'il n'y ait pas de
journal, c'est à dire le ext2 monté async comme c'était de règle à l'époque,
c'est tout sauf professionnel.
La couche réseau a été refaite de fond en
comble 3 ou 4 fois, ce n'est pas pour rien. Encore à l'heure actuelle
sur les noyaux 2.6 il paraît que l'usage de cartes gigabit ethernet entraîne
une perte généreuse de paquets, là où la même machine, avec la même carte sous
Windows n'en perd pas.
Ne parlons pas aussi des latences bien plus grandes que
sous Windows qui handicapaient le système de son considérablement.s
Tous ces
problèmes ont été plus ou moins attaqués par les ingénieurs de Redhat, Suse,
IBM, etc. au prix d'une grande complexification du système. Contrairement
à ce que tu dis le "fine grained locking" est arrivé avec les noyaux 2.4,
et je pense que IBM a contribué le Read Copy Update pour le 2.6. Ce qui
veut dire que les bons résultats en SMP dont Linux peut se targuer maintenant
datent essentiellement du 2.6.
Tu dis que les machines à beaucoup de
processeurs ça n'existe que dans des applications trés spécialisées, ce
n'est pas vrai. Avec des niagara qui sont déjà à 32 processeurs (virtuels)
tout le monde va s'y mettre rapidement.
Patrice Karatchentzeff wrote:(Michel Talon) writes:de mémoire qu'il peut gérer est trés limitée, le swap limité à une quantité
dérisoire, la gestion de la VM, il vaut mieux ne pas en parler, les
systèmes de fichier c'est le salaire de la peur en cas de coupure de courant, la couche
réseau ça doit marcher à peu prés sur du 10 Mb et perdre la moitié des
paquets au delà, et tout à l'avenant.
Tu as sûrement raison : je crois me rappeler que l'uptime ne dépassait
rarement quelques minutes sur tous ces noyaux tellement ils étaient
pourris... il paraît même que certains fous auraient réussi à exécuter
un 'ls' sur un fichier ext2 un jour...
Non l'uptime était relativement bon, tant qu'on ne faisait pas une manoeuvre
dangereuse, telle que monter une disquette avec des bad blocks. Si l'uptime
était bon c'est parceque le système était simple, pour ne pas dire simpliste.
Mais simple et performant ça n'existe pas, et ça n'existera jamais.
Quand au système consistant à faire croire qu'on fait des accés disques trés
trés rapides parcequ'on cache tout en mémoire de façon avide, qu'on ne
synchronise le disque que toutes les 30 secondes bien qu'il n'y ait pas de
journal, c'est à dire le ext2 monté async comme c'était de règle à l'époque,
c'est tout sauf professionnel.
La couche réseau a été refaite de fond en
comble 3 ou 4 fois, ce n'est pas pour rien. Encore à l'heure actuelle
sur les noyaux 2.6 il paraît que l'usage de cartes gigabit ethernet entraîne
une perte généreuse de paquets, là où la même machine, avec la même carte sous
Windows n'en perd pas.
Ne parlons pas aussi des latences bien plus grandes que
sous Windows qui handicapaient le système de son considérablement.s
Tous ces
problèmes ont été plus ou moins attaqués par les ingénieurs de Redhat, Suse,
IBM, etc. au prix d'une grande complexification du système. Contrairement
à ce que tu dis le "fine grained locking" est arrivé avec les noyaux 2.4,
et je pense que IBM a contribué le Read Copy Update pour le 2.6. Ce qui
veut dire que les bons résultats en SMP dont Linux peut se targuer maintenant
datent essentiellement du 2.6.
Tu dis que les machines à beaucoup de
processeurs ça n'existe que dans des applications trés spécialisées, ce
n'est pas vrai. Avec des niagara qui sont déjà à 32 processeurs (virtuels)
tout le monde va s'y mettre rapidement.
Ne parlons pas aussi des latences bien plus grandes que
sous Windows qui handicapaient le système de son considérablement.s
C'est bizarre. J'ai commencé à maintenir des gros serveurs en prod
(i386 et alpha) en noyau 2.0 et je n'ai _jamais_ vu de problème de
latence, même sur de l'antique 10Base2.
Ne parlons pas aussi des latences bien plus grandes que
sous Windows qui handicapaient le système de son considérablement.s
C'est bizarre. J'ai commencé à maintenir des gros serveurs en prod
(i386 et alpha) en noyau 2.0 et je n'ai _jamais_ vu de problème de
latence, même sur de l'antique 10Base2.
Ne parlons pas aussi des latences bien plus grandes que
sous Windows qui handicapaient le système de son considérablement.s
C'est bizarre. J'ai commencé à maintenir des gros serveurs en prod
(i386 et alpha) en noyau 2.0 et je n'ai _jamais_ vu de problème de
latence, même sur de l'antique 10Base2.
Mais simple et performant ça n'existe pas, et ça n'existera jamais.
datent essentiellement du 2.6. Tu dis que les machines à beaucoup de
processeurs ça n'existe que dans des applications trés spécialisées, ce
n'est pas vrai. Avec des niagara qui sont déjà à 32 processeurs (virtuels)
tout le monde va s'y mettre rapidement.
Mais simple et performant ça n'existe pas, et ça n'existera jamais.
datent essentiellement du 2.6. Tu dis que les machines à beaucoup de
processeurs ça n'existe que dans des applications trés spécialisées, ce
n'est pas vrai. Avec des niagara qui sont déjà à 32 processeurs (virtuels)
tout le monde va s'y mettre rapidement.
Mais simple et performant ça n'existe pas, et ça n'existera jamais.
datent essentiellement du 2.6. Tu dis que les machines à beaucoup de
processeurs ça n'existe que dans des applications trés spécialisées, ce
n'est pas vrai. Avec des niagara qui sont déjà à 32 processeurs (virtuels)
tout le monde va s'y mettre rapidement.
Quand au système consistant à faire croire qu'on fait des accés disques trés
trés rapides parcequ'on cache tout en mémoire de façon avide, qu'on ne
synchronise le disque que toutes les 30 secondes bien qu'il n'y ait pas de
journal, c'est à dire le ext2 monté async comme c'était de règle à l'époque,
c'est tout sauf professionnel.
Mouarf... Celle-là, je l'encardre ! Dis, de quand date le noyau 2.0
? Quels étaient les systèmes de fichiers à l'époque (tous systèmes
confondus) ? Pourquoi ext2 était-il monté par défaut en asynchrone ?
Allez, je t'aide, parce que l'interface des disques durs par défaut
sur un PC était (est toujours d'ailleurs) complètement moisie.
Quand au système consistant à faire croire qu'on fait des accés disques trés
trés rapides parcequ'on cache tout en mémoire de façon avide, qu'on ne
synchronise le disque que toutes les 30 secondes bien qu'il n'y ait pas de
journal, c'est à dire le ext2 monté async comme c'était de règle à l'époque,
c'est tout sauf professionnel.
Mouarf... Celle-là, je l'encardre ! Dis, de quand date le noyau 2.0
? Quels étaient les systèmes de fichiers à l'époque (tous systèmes
confondus) ? Pourquoi ext2 était-il monté par défaut en asynchrone ?
Allez, je t'aide, parce que l'interface des disques durs par défaut
sur un PC était (est toujours d'ailleurs) complètement moisie.
Quand au système consistant à faire croire qu'on fait des accés disques trés
trés rapides parcequ'on cache tout en mémoire de façon avide, qu'on ne
synchronise le disque que toutes les 30 secondes bien qu'il n'y ait pas de
journal, c'est à dire le ext2 monté async comme c'était de règle à l'époque,
c'est tout sauf professionnel.
Mouarf... Celle-là, je l'encardre ! Dis, de quand date le noyau 2.0
? Quels étaient les systèmes de fichiers à l'époque (tous systèmes
confondus) ? Pourquoi ext2 était-il monté par défaut en asynchrone ?
Allez, je t'aide, parce que l'interface des disques durs par défaut
sur un PC était (est toujours d'ailleurs) complètement moisie.
