La surprise de W7 que l'on attendit pas...

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
totof2000 ?crivait dans fr.comp.os.linux.debats :

> Pour OpenBSD : je ne connais pas suffisamment pour juger donc je n'en
> parlerai pas. Pour NetBSD, si on le compare à Linux, il est normal que
> les bugs soient plus vite corrigés, car le nombre de développeurs est
> moins important sous NetBSD, pour un nombre d'archi supporté quasi
> identique ( peut-être un peu plus pour NetBSD).

        Pas compris. S'il y a moins de développeurs, cela devrait être plus
lent, non ?

Oui, je me suis mal exprimé désolé ( voila ce qui se passe quand on
fait trop de choses en même temps) :
Reformulé ça donne :
Pour NetBSD, si on le compare à Linux, il est normal que les bugs
soient moins vite corrigés car le nombre de développeurs est moins
important sous NetBSD, pour un nombre d'archi supporté quasi identique.

Il y a juste une différence de taille. Lorsque tu trouves un bug
sérieux :
- OpenBSD : tu pars avec un coup de pied au cul parce que c'est à la
norme de se plier à OpenBSD;
- NetBSD : les développeurs testent et te remercient en promettant de
faire le possible pour corriger.

Bon, sous Linux, il y a aussi le cas du développeur de pthread qui
tient un discours un peu... bizarre pour justifier son implantation
(discours qui est à la limite de la mauvaise foi, mais c'est un autre
débat).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

> Il y a juste une différence de taille. Lorsque tu trouves un bug
sérieux :
- OpenBSD : tu pars avec un coup de pied au cul parce que c'est à la
norme de se plier à OpenBSD;
- NetBSD : les développeurs testent et te remercient en promettant de
faire le possible pour corriger.

Bon, sous Linux, il y a aussi le cas du développeur de pthread qui
tient un discours un peu... bizarre pour justifier son implantation
(discours qui est à la limite de la mauvaise foi, mais c'est un autre
débat).

JKB

Tu ne fais que confirmer mon sentiment, et c'est une des raisons pour
lesquelles OpenBSD ne me plait guère. En fait tu es plus ou moins en
train de me dire que si NetBSD avait plus de contributeur, ça te
faciliterait la vie .....

Pour l'histoire, à l'époque ou j'ai choisi NetBSD, c'est surtout pour
avoir un système suffisamment cohérent sur les architectures que j'avais
(x86 parfois un peu vieilles, SPARC, SPARC64, et il devait arriver des
machines HP). J'ai exclu Debian car je me suis battu peu de temps avant
sur les problèmes d'ajout de package, que j'ai du corriger à coup de
dpkg reconfigure ou autres incantations du genre (mais je suis peut-être
tombé au mauvais momentsur la mauvaise version ...ca remote à quelques
années donc je ne me rappelle plus trop ce que c'était). De plus Linux
me laissait un sentimen tglobal de "pas fini". La seule distrib avec
laquelle je me sentais à l'aise était la slackware : mais le problème
est qu'elle n'était pas dispo sur autre chose que x86.

J'avais hésité entre freebsd et NetBSD, mais le nombre d'archi était
plus limité sous freeBSD à cette époque.

Maintenant j'avoue que depuis quelques temps je lorgne de plus en plus
vers FreeBSD pour mon poste de travail : il dispose de certains softs
qui ne sont pas dispo sous NetBSD et qui commencent à me manquer. Par
contre pour le(s) serveurs, je garde NetBSD avec Xen, quitte
éventuellement à installer un Linux ou un FreeBSD par dessus .... Je me
suis même remis à Debian il y a peu en essayant de mettre de côté mes
aprioris, mais c'est quand même difficile ....

> Je vais te donner un seul exemple. Je développe des outils de calcul
parallèle. Pour cela, je me limite aux spécifications strictement
POSIX-2001 (c'est un choix qui en vaut un autre). Je pars donc du
principe que sur tous les OS POSIX-2001, mon code va fonctionner de la
même façon, et ce n'est _pas_ le cas. Il faut coller des rustines un peu
partout. Résultat, j'ai des fichiers .h différents selon les OS et les
processeurs (donc un solaris.h qui redéfinit le malloc, parce que le
malloc de la libc marqué comme thread safe dans la doc ne l'est pas !).
Tu te retrouves au final avec des rustines, avec des patches qui
consistent à tourner autour d'un problème parce que tu te rends compte
au bout de cinq ans de développement que NetBSD (pour ne pas le citer)
ne se comporte pas correctement et que tu es contraint au bricolage pour
contourner un problème dans un code qui ne s'y prête plus. Et je ne
parle pas de trucs foireux comme les chaînes statiques ou allouées
renvoyées par certaines fonctions ou du caractère soi-disant thread-safe
de dlsym(). Bref, je passe plus de temps à contourner les bugs
intrinsèques des différents OS qu'à implanter des algorithmes.

Tu sembles être l'un des rares développeurs que la portabilité
intéresse. Est-ce par contrainte ou par envie ? EN tout cas dans un cas
comme dans l'autre je te tire mon chapeau, car bien que n'étant pas
développeur je peux appercevoir la difficulté de la chose et beaucoup
auraient laissé tombé.

Lorsqu'un appel système est marqué disponible sur un OS, il _doit_
suivre les spécifications car le développeur initial n'a aucun moyen de
tester _tous_ les cas de figure.

Je n'ai jamais dit le contraire ... mais ça reste une utopie car
aucun OS n'est dépourvu de bugs

Je viens de remonter un bug à Sun dans Solaris 10/sparc (carrément
dans la libc qui se vautre dans des free() sur un mutex dans certains
contextes). Je mets ma main à couper que le truc sera corrigé très vite.
J'ai remonté les trucs que j'ai trouvé aux équipes d'OpenBSD, je me suis
fait bouler parce que la spécification POSIX n'était pas 'secure'. Ques
Net, ils sont plus réactifs. Tout ça pour dire que les bugs existent.
Faut-il encore vouloir les corriger.

Oui mais OpenBSD est à mon avis un cas à part ..... Quand on voit la
personnalité de son "leader", tout de suite ça donne pas envie ...

Rajouter un patch pour un OS dans un
coin, un autre pour un autre OS ailleurs dans le programme, c'est au
mieux avoir la certitude de ne plus rien comprendre dans un futur assez proche,
au pire, avoir des programmes qui se comporent bizarrement dans certains
cas.

Ce n'est pas forcément au développeur initial de s'occuper du portage
pour telle ou telle archi, mais s'il organise bien son code, n'y a-t-
il pas moyen d'isoler les parties concernées dans des bibliotèques
adaptées et laisser les gens qui portent les applis gérer ces
particularités ?

Ce n'est pas simple du tout. On peut raisonnablement penser qu'un
signal sera traité correctement partout parce que les fonctions en
question sont d'assez haut niveau.

Oui mais ..... Ce n'est pas pour dire, mais tu sembles bosser dans un
domaine assez spécifique .... Si on se cantonne à un domaine plus
"classique", style serveur www/base de données, firewall ou poste
bureautique, quel est l'impact réel de ces problèmes ?

Le problème n'est effectivement pas limité à Linux ou aux BSD et
est général, mais force est de constater que ce problème se pose pour
au moins Net et OpenBSD.

Pour OpenBSD : je ne connais pas suffisamment pour juger donc je n'en
parlerai pas. Pour NetBSD, si on le compare à Linux, il est normal que
les bugs soient plus vite corrigés, car le nombre de développeurs est
moins important sous NetBSD, pour un nombre d'archi supporté quasi
identique ( peut-être un peu plus pour NetBSD).

Pas compris. S'il y a moins de développeurs, cela devrait être plus
lent, non ?

Je vais arrêter là, tu me fatigues.

Tu me déçois, je te pensais plus endurant ..... Ca change de la
Troidé et de Windows non ?

Ça fait huit jours que je dépiote la libdl de Solaris pour trouver
un bug enfoui. Un truc qui fait que de temps en temps, en contexte
multithreadé, dlsym() renvoit NULL sur un point d'entrée _existant_.
Ça finit par miner mon endurance.

Oui mais en même temps initialement on a demandé un troll BSD/Linux, ...

Cela dit la discussion commence à devenir intéressante (pour moi en tout
cas). Faut que je prenne des cours de lacer de trolls !!! Ca va pas là.

Voyons si j'ai bien compris tes règles ...

[0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport ftp -j ACCEPT

Accepter les paques entrants sur eth0, sortants sur eth1, protocole TCP,
port destination!

[0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport ssh -j ACCEPT

Même chose pour ssh (port 22)

[0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport gopher -j ACCEPT

Meme chose pour Gopher (me rappelle plus le port mais peu importe)

[0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport http -j ACCEPT

Idem pour HTTP

[0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport pop3 -j ACCEPT

Idem pour pop3

[0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport imap -j ACCEPT

Idem pour imap

[0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport pop3s -j ACCEPT

idem pour pop3 via ssl je suppose

[0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport imaps -j ACCEPT

même supposition que ci-dessus mais pour imap.

Juste une option que je ne comprends pas : pourquoi -m tcp ?

..

[0:0] -A FORWARD -p icmp -j ACCEPT

Accepter tous las paquts ICMP

[0:0] -A FORWARD -i eth0 -o eth2 -p tcp -m tcp --dport http -j ACCEPT

Accepter les paquets sur port HTTP (80) en provenance de eth0 et passant
par eth2

[0:0] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

La je ne vois pas ....

[0:0] -A FORWARD -m state --state INVALID -j DROP

La non plus ... Tu rejettes des paquets mais sur quel critère ?
J'ai bien une idée .... mais il me faudrait une doc plus complète ...

...
[0:0] -A PREROUTING -d 192.168.0.81 -p tcp -m tcp --dport http -jDNAT
--to-destination 192.168.0.81:8000

La tu fais une translation de ports : tous les paquets a destination de
192.168.0.81 sur le port 80 sont redirigés vers le port 8000

[0:0] -A PREROUTING -s 192.168.0.83 -p tcp -m tcp --dport smtp -jMARK
--set-mark 1

La je vois pas trop ... Tu fais un truc sur les paquets venant de
192.168.0.83 ... Un filtre anti SPAM pour éviter les robots sur ta
machine ?

[0:0] -A POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE

Translation d'adresse? Mais comment ?
J'ai l'impression qu'il me manque des morceaux pour comprendre ....

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
totof2000 ?crivait dans fr.comp.os.linux.debats :

Il y a juste une différence de taille. Lorsque tu trouves un bug
sérieux :
- OpenBSD : tu pars avec un coup de pied au cul parce que c'est à la
norme de se plier à OpenBSD;
- NetBSD : les développeurs testent et te remercient en promettant de
faire le possible pour corriger.

Bon, sous Linux, il y a aussi le cas du développeur de pthread qui
tient un discours un peu... bizarre pour justifier son implantation
(discours qui est à la limite de la mauvaise foi, mais c'est un autre
débat).

JKB

Tu ne fais que confirmer mon sentiment, et c'est une des raisons pour
lesquelles OpenBSD ne me plait guère. En fait tu es plus ou moins en
train de me dire que si NetBSD avait plus de contributeur, ça te
faciliterait la vie .....

Je suis sourtout en train de dire que NetBSD est un gros projet et
que c'est tout à fait normal que ça n'avance pas vite. Il y a plus
d'architectures à supporter que Linux, dont des architectures
franchement bizarres et que le but des développeurs de NetBSD, c'est
d'avoir un noyau et un certain nombre de bibliothèques parfaitement
portables d'une architecture à une autre. Ça demande donc du temps.
OpenBSD prend le problème à l'envers. Très peu d'architectures
supportées et pour ne pas s'emmerder, on déclare ouvertement que
certains côté des spécifications BSD ou Posix sont dangereuses et on les
tourne pour ne pas s'emmerder à programmer des choses sécurisées (pour
de bonnes ou mauvaises raisons, ce n'est pas le débat).

Pour l'histoire, à l'époque ou j'ai choisi NetBSD, c'est surtout pour
avoir un système suffisamment cohérent sur les architectures que j'avais
(x86 parfois un peu vieilles, SPARC, SPARC64, et il devait arriver des
machines HP). J'ai exclu Debian car je me suis battu peu de temps avant
sur les problèmes d'ajout de package, que j'ai du corriger à coup de
dpkg reconfigure ou autres incantations du genre (mais je suis peut-être
tombé au mauvais momentsur la mauvaise version ...ca remote à quelques
années donc je ne me rappelle plus trop ce que c'était). De plus Linux
me laissait un sentimen tglobal de "pas fini". La seule distrib avec
laquelle je me sentais à l'aise était la slackware : mais le problème
est qu'elle n'était pas dispo sur autre chose que x86.

J'avais hésité entre freebsd et NetBSD, mais le nombre d'archi était
plus limité sous freeBSD à cette époque.

Maintenant j'avoue que depuis quelques temps je lorgne de plus en plus
vers FreeBSD pour mon poste de travail : il dispose de certains softs
qui ne sont pas dispo sous NetBSD et qui commencent à me manquer. Par
contre pour le(s) serveurs, je garde NetBSD avec Xen, quitte
éventuellement à installer un Linux ou un FreeBSD par dessus .... Je me
suis même remis à Debian il y a peu en essayant de mettre de côté mes
aprioris, mais c'est quand même difficile ....

P'taing, de la virtualisation... C'est vraiment un truc que mon
cerveau certainement limité d'arrivera _jamais_ à comprendre pour autre
chose que le développement d'OS... Rajouter des couches, et lorsque ça
se bauge, on ne sait plus ce qui foire...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
totof2000 ?crivait dans fr.comp.os.linux.debats :

Je vais te donner un seul exemple. Je développe des outils de calcul
parallèle. Pour cela, je me limite aux spécifications strictement
POSIX-2001 (c'est un choix qui en vaut un autre). Je pars donc du
principe que sur tous les OS POSIX-2001, mon code va fonctionner de la
même façon, et ce n'est _pas_ le cas. Il faut coller des rustines un peu
partout. Résultat, j'ai des fichiers .h différents selon les OS et les
processeurs (donc un solaris.h qui redéfinit le malloc, parce que le
malloc de la libc marqué comme thread safe dans la doc ne l'est pas !).
Tu te retrouves au final avec des rustines, avec des patches qui
consistent à tourner autour d'un problème parce que tu te rends compte
au bout de cinq ans de développement que NetBSD (pour ne pas le citer)
ne se comporte pas correctement et que tu es contraint au bricolage pour
contourner un problème dans un code qui ne s'y prête plus. Et je ne
parle pas de trucs foireux comme les chaînes statiques ou allouées
renvoyées par certaines fonctions ou du caractère soi-disant thread-safe
de dlsym(). Bref, je passe plus de temps à contourner les bugs
intrinsèques des différents OS qu'à implanter des algorithmes.

Tu sembles être l'un des rares développeurs que la portabilité
intéresse. Est-ce par contrainte ou par envie ?

Par contrainte. Je développe sur du biprocesseur sparc64 ou amd64,
mais en production, mes algorithmes tournent sur du 32 procs pour la
plus petite machine (et ça va à 128). Autant dire que je laisse sur les
machines en question l'OS du constructeur qui ne peut plus me voir
tellement je lui remonte d'erreurs dans son OS qui est Solaris pour ne
pas le nommer... Le bug report d'aujourd'hui, c'est :

[8986] SIGFSTOP (thread 22787)
[8986] SIGFSTOP (thread 22789)
[8986] SIGFSTOP (thread 22791)
[8986] Fin du thread 22767
[8986] SIGFSTOP (thread 22793)
[8986] SIGFSTOP (thread 22795)
dlerror() : ld.so.1: rpl: fatal : _ex_unwind : symbole introuvable
Ligne : 1024
[8986] Fin du thread 22771

alors que ce truc est bien dans la bibliothèque en question (et que
d'après monsieur Sun, la bibliothèque en question est thread safe, comme
la libc de Solaris d'ailleurs qui ne l'est absolument pas pour free()...).
Bref, la portabilité, pour moi, ça me permet de tester mes productions
dans des environnements différents avec des gens qui lisent les
spécifications Posix différemment. Ça me permet de débugguer des trucs
plus rapidement. Simple exemple : sous Solaris, pthread_kill() se
comporte comme kill(), tu peux envoyer un signal 0 à un thread pour voir
s'il est vivant (les pthread_t sont des entiers). Sous Linux, pour une
sombre raison, les pthread_t sont des pointeurs et si ton thread est
mort et que tu fais ça, tu te prends un SIGSEGV dans les dents. Dans les
spécifications Posix, la phrase qui dit que le pthread_kill() est
valable avec un signal nul est au _futur_ (si ma mémoire ne fait pas
défaut). Des trucs comme ça, il y en a des tonnes. Donc, en écrivant un
truc portable et en le testant sur plusieurs architectures, ça limite
les effets de bord.

EN tout cas dans un cas
comme dans l'autre je te tire mon chapeau, car bien que n'étant pas
développeur je peux appercevoir la difficulté de la chose et beaucoup
auraient laissé tombé.

Lorsqu'un appel système est marqué disponible sur un OS, il _doit_
suivre les spécifications car le développeur initial n'a aucun moyen de
tester _tous_ les cas de figure.

Je n'ai jamais dit le contraire ... mais ça reste une utopie car
aucun OS n'est dépourvu de bugs

Je viens de remonter un bug à Sun dans Solaris 10/sparc (carrément
dans la libc qui se vautre dans des free() sur un mutex dans certains
contextes). Je mets ma main à couper que le truc sera corrigé très vite.
J'ai remonté les trucs que j'ai trouvé aux équipes d'OpenBSD, je me suis
fait bouler parce que la spécification POSIX n'était pas 'secure'. Ques
Net, ils sont plus réactifs. Tout ça pour dire que les bugs existent.
Faut-il encore vouloir les corriger.

Oui mais OpenBSD est à mon avis un cas à part ..... Quand on voit la
personnalité de son "leader", tout de suite ça donne pas envie ...

Je ne dirais pas en public ce que j'en pense. Enfin, si, je viens de
le dire...

Rajouter un patch pour un OS dans un
coin, un autre pour un autre OS ailleurs dans le programme, c'est au
mieux avoir la certitude de ne plus rien comprendre dans un futur assez proche,
au pire, avoir des programmes qui se comporent bizarrement dans certains
cas.

Ce n'est pas forcément au développeur initial de s'occuper du portage
pour telle ou telle archi, mais s'il organise bien son code, n'y a-t-
il pas moyen d'isoler les parties concernées dans des bibliotèques
adaptées et laisser les gens qui portent les applis gérer ces
particularités ?

Ce n'est pas simple du tout. On peut raisonnablement penser qu'un
signal sera traité correctement partout parce que les fonctions en
question sont d'assez haut niveau.

Oui mais ..... Ce n'est pas pour dire, mais tu sembles bosser dans un
domaine assez spécifique .... Si on se cantonne à un domaine plus
"classique", style serveur www/base de données, firewall ou poste
bureautique, quel est l'impact réel de ces problèmes ?

Le fait de ne pas traiter correctement les masques des signaux qui
ne sont pas à temps réel pose des tas de problèmes. Cela me permet
d'entendre un peu partout que l'utilisation des signaux est
casse-gueule. C'est faut, c'est l'implantation de certaines fonctions
qui est mauvaise. Maintenant, lorsqu'un processus dans un coin attend un
signal pour faire quelque chose (signal déclanché quand il était bloqué)
et que le sigpending() pour le traité renvoie toujours 0, tu n'arriveras
jamais à réveiller le programme en question. J'ai un serveur apache qui
m'a fait ça (sous NetBSD). J'ai eu le même problème avec un sendmail des
familles sur un linux/sparc64 tout à fait officiel. Résultat des
courses, des ajouts de 'workarounds' pour contourner le problème...
Seamonkey refuse de fonctionner sur linux/sparc64 en raison d'un SIGBUS
qui se pointe au lancement (accès à une fonction de la libc dont j'ai
oublié le nom, mais mysql a exactement le même problème). Donc ces
problèmes apparaissent _aussi_ sur un poste bureautique.

Le problème n'est effectivement pas limité à Linux ou aux BSD et
est général, mais force est de constater que ce problème se pose pour
au moins Net et OpenBSD.

Pour OpenBSD : je ne connais pas suffisamment pour juger donc je n'en
parlerai pas. Pour NetBSD, si on le compare à Linux, il est normal que
les bugs soient plus vite corrigés, car le nombre de développeurs est
moins important sous NetBSD, pour un nombre d'archi supporté quasi
identique ( peut-être un peu plus pour NetBSD).

Pas compris. S'il y a moins de développeurs, cela devrait être plus
lent, non ?

Je vais arrêter là, tu me fatigues.

Tu me déçois, je te pensais plus endurant ..... Ca change de la
Troidé et de Windows non ?

Ça fait huit jours que je dépiote la libdl de Solaris pour trouver
un bug enfoui. Un truc qui fait que de temps en temps, en contexte
multithreadé, dlsym() renvoit NULL sur un point d'entrée _existant_.
Ça finit par miner mon endurance.

Oui mais en même temps initialement on a demandé un troll BSD/Linux, ...

Cela dit la discussion commence à devenir intéressante (pour moi en tout
cas). Faut que je prenne des cours de lacer de trolls !!! Ca va pas là.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le Tue, 10 Mar 2009 08:12:36 +0000 (UTC),
JKB a écrit :

[...]
P'taing, de la virtualisation... C'est vraiment un truc que
mon cerveau certainement limité d'arrivera _jamais_ à comprendr e pour
autre chose que le développement d'OS... Rajouter des couches, et
lorsque ça se bauge, on ne sait plus ce qui foire...

Bah ! Il y a plein d'exemples où la virtualisation est très
intéressante. Pour n'en prendre qu'un, disons l'amélioration
du rendement global d'un site.

Regrouper plusieurs serveurs, dont la charge de travail est
faible, en un seul, permet une réduction des dépenses
énergétiques, un gain de place, une sauvegarde et une
restauration plus facile et plus rapide, une duplication
d'un serveur tout aussi facile et rapide en copiant simplement
l'image disque, un meilleur isolement et une plus grande
sécurité entre services que celle fournie par les chroot,
jail et consorts,... Sans compter qu'en réduisant le nombre
de machines, on réduit aussi le risque de panne et d'autant
les interventions de maintenance, etc.

Bref, la virtualisation n'est pas utile qu'au développement
d'OS seulement.

--
Jacques.

Le 10-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
Kojak ?crivait dans fr.comp.os.linux.debats :

Le Tue, 10 Mar 2009 08:12:36 +0000 (UTC),
JKB a écrit :

[...]
P'taing, de la virtualisation... C'est vraiment un truc que
mon cerveau certainement limité d'arrivera _jamais_ à comprendre pour
autre chose que le développement d'OS... Rajouter des couches, et
lorsque ça se bauge, on ne sait plus ce qui foire...

Bah ! Il y a plein d'exemples où la virtualisation est très
intéressante. Pour n'en prendre qu'un, disons l'amélioration
du rendement global d'un site.

Regrouper plusieurs serveurs, dont la charge de travail est
faible, en un seul, permet une réduction des dépenses
énergétiques, un gain de place, une sauvegarde et une
restauration plus facile et plus rapide, une duplication
d'un serveur tout aussi facile et rapide en copiant simplement
l'image disque, un meilleur isolement et une plus grande
sécurité entre services que celle fournie par les chroot,
jail et consorts,... Sans compter qu'en réduisant le nombre
de machines, on réduit aussi le risque de panne et d'autant
les interventions de maintenance, etc.

Le problème, c'est que je fais exactement ça dans mon centre de
calcul sans jamais avoir recours à la virtualisation, et avec des
performances certainement supérieures. La consommation n'est pas un
argument pertinent puisque j'ai des serveurs à 32 voies qui consomment
moins de 400W en charge maximale (mesurés au wattmètre).

Quant à la sécurité apportée, elle est toute relative... Je n'ai
jamais vu un empilement d'OS plus sécuritaire qu'un OS seul.

Bref, la virtualisation n'est pas utile qu'au développement
d'OS seulement.

C'est surtout un truc parfait pour blablater dans des revues
sérieuses de décideurs qui ne comprennent rien. Dans les faits, je n'ai
encore jamais vu un cas ou la virtualisation est nécessaire.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

Le 10-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
Kojak ?crivait dans fr.comp.os.linux.debats :

(...)

Bref, la virtualisation n'est pas utile qu'au développement
d'OS seulement.

C'est surtout un truc parfait pour blablater dans des revues
sérieuses de décideurs qui ne comprennent rien. Dans les faits, je n'ai
encore jamais vu un cas ou la virtualisation est nécessaire.

Par certains côtés, on est petit à petit en train de faire un retour 30
ans en arrière, les serveurs virtualisés reprenant la place des
mainframe d'antan et le poste client étant réduit à sa plus simple
expression. Belle régression... :-(

Jerome Lambert a écrit :

Par certains côtés, on est petit à petit en train de faire un ret our 30
ans en arrière, les serveurs virtualisés reprenant la place des
mainframe d'antan et le poste client étant réduit à sa plus simpl e
expression. Belle régression... :-(

Faire, défaire, refaire.... crache pas dans la soupe, c'est le coeur du
métier!

A+
JF