Le Fri, 11 Dec 2009 20:59:41 +0100, Stephan Peccini a écrit:
Oui et non. Non car c'est une bêtise de ma part de le proposer en production sous Linux (je me suis emmêlé les pinceaux) mais oui car on peut avoir zfs sous Linux (enfin pas dans le noyau).
Je suis trop vieux, peut-être que dans 10 ans je pourrai éventuellement admettre qu'on pourrait peut-être avoir un pilote fuse en production pour un truc critique genre un fs, mais pour l'instant, non :) C'est même pour ça que je ne me suis pas plongé dans gluster (pourtant maintenant ils ont même une version commerciale).
-- La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. Anatole France.
Le Fri, 11 Dec 2009 20:59:41 +0100, Stephan Peccini a écrit:
Oui et non. Non car c'est une bêtise de ma part de le proposer en
production sous Linux (je me suis emmêlé les pinceaux) mais oui car on
peut avoir zfs sous Linux (enfin pas dans le noyau).
Je suis trop vieux, peut-être que dans 10 ans je pourrai éventuellement
admettre qu'on pourrait peut-être avoir un pilote fuse en production pour
un truc critique genre un fs, mais pour l'instant, non :) C'est même pour
ça que je ne me suis pas plongé dans gluster (pourtant maintenant ils ont
même une version commerciale).
--
La loi, dans un grand souci d'égalité, interdit aux riches comme aux
pauvres de coucher sous les ponts, de mendier dans les rues et de voler
du pain.
Anatole France.
Le Fri, 11 Dec 2009 20:59:41 +0100, Stephan Peccini a écrit:
Oui et non. Non car c'est une bêtise de ma part de le proposer en production sous Linux (je me suis emmêlé les pinceaux) mais oui car on peut avoir zfs sous Linux (enfin pas dans le noyau).
Je suis trop vieux, peut-être que dans 10 ans je pourrai éventuellement admettre qu'on pourrait peut-être avoir un pilote fuse en production pour un truc critique genre un fs, mais pour l'instant, non :) C'est même pour ça que je ne me suis pas plongé dans gluster (pourtant maintenant ils ont même une version commerciale).
-- La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. Anatole France.
Emmanuel Florac
Le Fri, 11 Dec 2009 20:52:46 +0100, Stephan Peccini a écrit:
Cela confirme en partie ce que j'ai pu voir avec xfs et ext4. Pour l'instant, je pense que vais y rester uniquement pour le snapshot sinon ce sera xfs.
Oui, sans compter que nilfs n'a toujours pas d'acls et d'attributs étendus. Il y a pas mal d'applications où c'est franchement problématique.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Fri, 11 Dec 2009 20:52:46 +0100, Stephan Peccini a écrit:
Cela confirme en partie ce que j'ai pu voir avec xfs et ext4. Pour
l'instant, je pense que vais y rester uniquement pour le snapshot sinon
ce sera xfs.
Oui, sans compter que nilfs n'a toujours pas d'acls et d'attributs
étendus. Il y a pas mal d'applications où c'est franchement problématique.
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Le Fri, 11 Dec 2009 20:52:46 +0100, Stephan Peccini a écrit:
Cela confirme en partie ce que j'ai pu voir avec xfs et ext4. Pour l'instant, je pense que vais y rester uniquement pour le snapshot sinon ce sera xfs.
Oui, sans compter que nilfs n'a toujours pas d'acls et d'attributs étendus. Il y a pas mal d'applications où c'est franchement problématique.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Stephane TOUGARD
JKB wrote:
Le problème est surtout que le 2.6.32 merdoie joyeusement sur sun4u
Tout ça pour dire que je ne vais pas installer ce noyau immédiatement en prod sur mes machines.
Parce que t'as des machines de prod sur Sun4U ET tournant sous Linux.
Quand on voit la stabilite tres relative de Linux (et tu es le premier a en parler) sur Sun Ultra. Le moins qu'on puisse dire c'est que melanger les deux sur de la prod, c'est vraiment pas pro.
JKB wrote:
Le problème est surtout que le 2.6.32 merdoie joyeusement sur sun4u
Tout ça pour dire que je ne vais pas installer ce noyau
immédiatement en prod sur mes machines.
Parce que t'as des machines de prod sur Sun4U ET tournant sous Linux.
Quand on voit la stabilite tres relative de Linux (et tu es le premier a en
parler) sur Sun Ultra. Le moins qu'on puisse dire c'est que melanger les
deux sur de la prod, c'est vraiment pas pro.
Le problème est surtout que le 2.6.32 merdoie joyeusement sur sun4u
Tout ça pour dire que je ne vais pas installer ce noyau immédiatement en prod sur mes machines.
Parce que t'as des machines de prod sur Sun4U ET tournant sous Linux.
Quand on voit la stabilite tres relative de Linux (et tu es le premier a en parler) sur Sun Ultra. Le moins qu'on puisse dire c'est que melanger les deux sur de la prod, c'est vraiment pas pro.
Emmanuel Florac
Le Sat, 12 Dec 2009 04:01:33 +0100, Stephan Peccini a écrit:
en oubliant complétement de signaler que ce n'est pas sous Linux qu'il faut l'utiliser en production.
Et apparemment, sous FreeBSD c'est pas encore tout à fait ça; sous Darwin c'est mort.... Bon, il reste Solaris. QUelqu'un a testé Hammer sous DragonFlyBSD? :)
-- In girum imus nocte ecce et consumimur igni
Le Sat, 12 Dec 2009 04:01:33 +0100, Stephan Peccini a écrit:
en oubliant complétement de signaler que ce n'est pas sous Linux qu'il
faut l'utiliser en production.
Et apparemment, sous FreeBSD c'est pas encore tout à fait ça; sous Darwin
c'est mort.... Bon, il reste Solaris. QUelqu'un a testé Hammer sous
DragonFlyBSD? :)
Le Sat, 12 Dec 2009 04:01:33 +0100, Stephan Peccini a écrit:
en oubliant complétement de signaler que ce n'est pas sous Linux qu'il faut l'utiliser en production.
Et apparemment, sous FreeBSD c'est pas encore tout à fait ça; sous Darwin c'est mort.... Bon, il reste Solaris. QUelqu'un a testé Hammer sous DragonFlyBSD? :)
-- In girum imus nocte ecce et consumimur igni
JKB
Le 11-12-2009, ? propos de Re: Trojan dans Linux, Emmanuel Florac ?crivait dans fr.comp.os.linux.debats :
Le Fri, 11 Dec 2009 20:00:15 +0000, JKB a écrit:
Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.
Au problème près de la libcpap lorsque tu as un userland 32/64
bits !
Vu que c'est exactement la configuration dans laquelle je travaille, tu peux préciser? Je n'ai pas remarqué de gros souci (même si j'ai eu quelques bizarreries en FC).
Certaines API du noyau ont changé, en particulier dans la couche logique du réseau. Il y a un problème d'alignement mémoire qui fait que les fonctions de récupération des paquets en mode utilisateur de la libpcap bloquent indéfiniment sans jamais voir de paquets. Ce changement a eu lieu entre les noyau 2.6.26 et 27 ou 27 et 28, je ne sais plus. Mais j'ai eu la désagréable surprise de ne plus pouvoir utiliser knockd, iftop, même p0f sur mes serveurs. Il faut donc recompiler lors du passage la libpcap avec les en-têtes du noyau courant. Je n'ai vu ce souci que sur mes sparcs qui utilisent un noyau 64 bits, un userland 32 bits (avec quelques applications 64 bits). Je n'ai vu ça ni sur i386, ni sur amd64. Le truc est mentionné en tout petit dans le ChangeLog du noyau.
Concernant le FCAL, le noyau 2.6.31 est buggué et n'arrive pas à initialiser les adaptateurs. Ça se termine avec un timeout et un panic. Les 2.6.31 se comportent aussi bizarrement sur sun4v et n'arrivent pas à initialiser correctement les interfaces SAS. En fait, j'ai deux machines strictement identiques qui fonctionnent parfaitement en 2.6.30.9. En 2.6.31.x, l'une boote toujours, l'autre plante toujours au boot sur des erreurs SAS. Ce n'est pas un problème matériel, mais je n'arrive pas à savoir d'où vient le souci.
Je vais peut-être utiliser un peu de temps ce week-end pour essayer de débugguer le 2.6.32 sur sun4u (au moins pour régler le problème du firmware FCAL et le i2c_bbc qui dysfonctionne à mort depuis le 2.6.26 inclus. En 2.6.27, les températures peuvent devenir folkloriques et arrêtent la machine et depuis le 2.6.28, le module se charge ou ne se charge pas, fait un panic lors du déchargement et ne pilote plus rien...).
Cordialement,
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 11-12-2009, ? propos de
Re: Trojan dans Linux,
Emmanuel Florac ?crivait dans fr.comp.os.linux.debats :
Le Fri, 11 Dec 2009 20:00:15 +0000, JKB a écrit:
Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.
Au problème près de la libcpap lorsque tu as un userland 32/64
bits !
Vu que c'est exactement la configuration dans laquelle je travaille, tu
peux préciser? Je n'ai pas remarqué de gros souci (même si j'ai eu
quelques bizarreries en FC).
Certaines API du noyau ont changé, en particulier dans la couche
logique du réseau. Il y a un problème d'alignement mémoire qui fait
que les fonctions de récupération des paquets en mode utilisateur de
la libpcap bloquent indéfiniment sans jamais voir de paquets. Ce
changement a eu lieu entre les noyau 2.6.26 et 27 ou 27 et 28, je ne
sais plus. Mais j'ai eu la désagréable surprise de ne plus pouvoir
utiliser knockd, iftop, même p0f sur mes serveurs. Il faut donc
recompiler lors du passage la libpcap avec les en-têtes du noyau
courant. Je n'ai vu ce souci que sur mes sparcs qui utilisent un
noyau 64 bits, un userland 32 bits (avec quelques applications 64
bits). Je n'ai vu ça ni sur i386, ni sur amd64. Le truc est
mentionné en tout petit dans le ChangeLog du noyau.
Concernant le FCAL, le noyau 2.6.31 est buggué et n'arrive pas à
initialiser les adaptateurs. Ça se termine avec un timeout et un
panic. Les 2.6.31 se comportent aussi bizarrement sur sun4v et
n'arrivent pas à initialiser correctement les interfaces SAS. En
fait, j'ai deux machines strictement identiques qui fonctionnent
parfaitement en 2.6.30.9. En 2.6.31.x, l'une boote toujours, l'autre
plante toujours au boot sur des erreurs SAS. Ce n'est pas un
problème matériel, mais je n'arrive pas à savoir d'où vient le
souci.
Je vais peut-être utiliser un peu de temps ce week-end pour essayer
de débugguer le 2.6.32 sur sun4u (au moins pour régler le problème
du firmware FCAL et le i2c_bbc qui dysfonctionne à mort depuis le
2.6.26 inclus. En 2.6.27, les températures peuvent devenir
folkloriques et arrêtent la machine et depuis le 2.6.28, le module
se charge ou ne se charge pas, fait un panic lors du déchargement et
ne pilote plus rien...).
Cordialement,
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 11-12-2009, ? propos de Re: Trojan dans Linux, Emmanuel Florac ?crivait dans fr.comp.os.linux.debats :
Le Fri, 11 Dec 2009 20:00:15 +0000, JKB a écrit:
Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.
Au problème près de la libcpap lorsque tu as un userland 32/64
bits !
Vu que c'est exactement la configuration dans laquelle je travaille, tu peux préciser? Je n'ai pas remarqué de gros souci (même si j'ai eu quelques bizarreries en FC).
Certaines API du noyau ont changé, en particulier dans la couche logique du réseau. Il y a un problème d'alignement mémoire qui fait que les fonctions de récupération des paquets en mode utilisateur de la libpcap bloquent indéfiniment sans jamais voir de paquets. Ce changement a eu lieu entre les noyau 2.6.26 et 27 ou 27 et 28, je ne sais plus. Mais j'ai eu la désagréable surprise de ne plus pouvoir utiliser knockd, iftop, même p0f sur mes serveurs. Il faut donc recompiler lors du passage la libpcap avec les en-têtes du noyau courant. Je n'ai vu ce souci que sur mes sparcs qui utilisent un noyau 64 bits, un userland 32 bits (avec quelques applications 64 bits). Je n'ai vu ça ni sur i386, ni sur amd64. Le truc est mentionné en tout petit dans le ChangeLog du noyau.
Concernant le FCAL, le noyau 2.6.31 est buggué et n'arrive pas à initialiser les adaptateurs. Ça se termine avec un timeout et un panic. Les 2.6.31 se comportent aussi bizarrement sur sun4v et n'arrivent pas à initialiser correctement les interfaces SAS. En fait, j'ai deux machines strictement identiques qui fonctionnent parfaitement en 2.6.30.9. En 2.6.31.x, l'une boote toujours, l'autre plante toujours au boot sur des erreurs SAS. Ce n'est pas un problème matériel, mais je n'arrive pas à savoir d'où vient le souci.
Je vais peut-être utiliser un peu de temps ce week-end pour essayer de débugguer le 2.6.32 sur sun4u (au moins pour régler le problème du firmware FCAL et le i2c_bbc qui dysfonctionne à mort depuis le 2.6.26 inclus. En 2.6.27, les températures peuvent devenir folkloriques et arrêtent la machine et depuis le 2.6.28, le module se charge ou ne se charge pas, fait un panic lors du déchargement et ne pilote plus rien...).
Cordialement,
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
Le 12-12-2009, ? propos de Re: Trojan dans Linux, Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Le problème est surtout que le 2.6.32 merdoie joyeusement sur sun4u
Tout ça pour dire que je ne vais pas installer ce noyau immédiatement en prod sur mes machines.
Parce que t'as des machines de prod sur Sun4U ET tournant sous Linux.
Quand on voit la stabilite tres relative de Linux (et tu es le premier a en parler) sur Sun Ultra. Le moins qu'on puisse dire c'est que melanger les deux sur de la prod, c'est vraiment pas pro.
Je te signale aimablement que je participe un poil au développement sur sun4u et sun4v. Je sais donc à peu près comment rendre le truc stable et à ce jour je n'ai pas eu de problème avec mes sparcs en prod sous Linux. Si tu veux vraiment savoir, j'ai plus de problèmes avec mes sparcs sous Solaris (le coup du crle de la semaine passée a été très chaud !...).
Il y a un truc qui t'échappe, mais pour le comprendre, il faudrait que tu puisses commencer à avoir le début d'un raisonnement logique. Dans la vraie vie, on choisie une architecture en fonction de ses capacités à encaisser des traitements et une charge. Un fois qu'on a choisi cette architecture, on regarde les OS qui sont dessus et s'ils peuvent répondre au problème posé. C'est comme ça qu'on se retrouve avec plusieurs architectures et plusieurs OS dans une grappe de machine. Faire tourner RDB sous Solaris, c'est une connerie. Exactement la même que faire tourner un firewall sous Solaris. Une fois ces choix faits, on regarde la stabilité desdits OS. Au passage, mes sun4v tournant sous Linux avaient un uptime de 450 jours avant qu'une machine dans une baie à l'autre bout de la salle disjoncte et entraîne une microcoupure électrique. Je pense donc qu'on peut déclarer ces machines comme stables.
Au passage, j'ai assez de machines de test pour faire mes modifications avant de les déployer. Je ne m'amuse pas à patcher un système critique à chaud (c'est même pour cela que je ne m'amuse plus à mettre en frontaux des machines sous Solaris !). Bref, une architecture, ça se pense, c'est une histoire de compromis. C'est ça le professionnalisme.
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 12-12-2009, ? propos de
Re: Trojan dans Linux,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Le problème est surtout que le 2.6.32 merdoie joyeusement sur sun4u
Tout ça pour dire que je ne vais pas installer ce noyau
immédiatement en prod sur mes machines.
Parce que t'as des machines de prod sur Sun4U ET tournant sous Linux.
Quand on voit la stabilite tres relative de Linux (et tu es le premier a en
parler) sur Sun Ultra. Le moins qu'on puisse dire c'est que melanger les
deux sur de la prod, c'est vraiment pas pro.
Je te signale aimablement que je participe un poil au développement
sur sun4u et sun4v. Je sais donc à peu près comment rendre le truc
stable et à ce jour je n'ai pas eu de problème avec mes sparcs en prod
sous Linux. Si tu veux vraiment savoir, j'ai plus de problèmes avec mes
sparcs sous Solaris (le coup du crle de la semaine passée a été très
chaud !...).
Il y a un truc qui t'échappe, mais pour le comprendre, il faudrait
que tu puisses commencer à avoir le début d'un raisonnement logique.
Dans la vraie vie, on choisie une architecture en fonction de ses
capacités à encaisser des traitements et une charge. Un fois qu'on a
choisi cette architecture, on regarde les OS qui sont dessus et
s'ils peuvent répondre au problème posé. C'est comme ça qu'on se
retrouve avec plusieurs architectures et plusieurs OS dans une
grappe de machine. Faire tourner RDB sous Solaris, c'est une
connerie. Exactement la même que faire tourner un firewall sous
Solaris. Une fois ces choix faits, on regarde la stabilité desdits
OS. Au passage, mes sun4v tournant sous Linux avaient un uptime de
450 jours avant qu'une machine dans une baie à l'autre bout de la
salle disjoncte et entraîne une microcoupure électrique. Je pense
donc qu'on peut déclarer ces machines comme stables.
Au passage, j'ai assez de machines de test pour faire mes
modifications avant de les déployer. Je ne m'amuse pas à patcher un
système critique à chaud (c'est même pour cela que je ne m'amuse
plus à mettre en frontaux des machines sous Solaris !). Bref, une
architecture, ça se pense, c'est une histoire de compromis. C'est ça
le professionnalisme.
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 12-12-2009, ? propos de Re: Trojan dans Linux, Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Le problème est surtout que le 2.6.32 merdoie joyeusement sur sun4u
Tout ça pour dire que je ne vais pas installer ce noyau immédiatement en prod sur mes machines.
Parce que t'as des machines de prod sur Sun4U ET tournant sous Linux.
Quand on voit la stabilite tres relative de Linux (et tu es le premier a en parler) sur Sun Ultra. Le moins qu'on puisse dire c'est que melanger les deux sur de la prod, c'est vraiment pas pro.
Je te signale aimablement que je participe un poil au développement sur sun4u et sun4v. Je sais donc à peu près comment rendre le truc stable et à ce jour je n'ai pas eu de problème avec mes sparcs en prod sous Linux. Si tu veux vraiment savoir, j'ai plus de problèmes avec mes sparcs sous Solaris (le coup du crle de la semaine passée a été très chaud !...).
Il y a un truc qui t'échappe, mais pour le comprendre, il faudrait que tu puisses commencer à avoir le début d'un raisonnement logique. Dans la vraie vie, on choisie une architecture en fonction de ses capacités à encaisser des traitements et une charge. Un fois qu'on a choisi cette architecture, on regarde les OS qui sont dessus et s'ils peuvent répondre au problème posé. C'est comme ça qu'on se retrouve avec plusieurs architectures et plusieurs OS dans une grappe de machine. Faire tourner RDB sous Solaris, c'est une connerie. Exactement la même que faire tourner un firewall sous Solaris. Une fois ces choix faits, on regarde la stabilité desdits OS. Au passage, mes sun4v tournant sous Linux avaient un uptime de 450 jours avant qu'une machine dans une baie à l'autre bout de la salle disjoncte et entraîne une microcoupure électrique. Je pense donc qu'on peut déclarer ces machines comme stables.
Au passage, j'ai assez de machines de test pour faire mes modifications avant de les déployer. Je ne m'amuse pas à patcher un système critique à chaud (c'est même pour cela que je ne m'amuse plus à mettre en frontaux des machines sous Solaris !). Bref, une architecture, ça se pense, c'est une histoire de compromis. C'est ça le professionnalisme.
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.
talon
Emmanuel Florac wrote:
Le Sat, 12 Dec 2009 04:01:33 +0100, Stephan Peccini a écrit:
> en oubliant complétement de signaler que ce n'est pas sous Linux qu'il > faut l'utiliser en production.
Et apparemment, sous FreeBSD c'est pas encore tout à fait ça; sous Darwin
Il paraît que ça marche parfaitement en 64 bits sous FreeBSD. Je l'ai sur une partition de ma machine en 32 bits, il ne m'a jamais fait de panic, mais je ne le sollicite pas beaucoup, en gros uniquement la mise à jour de l'arbre des ports tous les jours et quelques compilations. J'ai réduit drastiquement la taille du cache (arc) donc les perfs sont limitées, mais enfin ça marche sur une machine x86-32 avec 1.5 Gigs de mémoire. En général si on veut des perfs, il faut beaucoup de cache, donc beaucoup de mémoire, donc 64 bits. Dans ces conditions, il semble que les performances soient de haut niveau, supérieures à UFS, et évidemment on a en plus toutes les commodités et sécurités de ZFS.
Je pense que dans le genre d'applications que tu as dans ton business, FreeBSD + ZFS devrait être très supérieur à Linux, pour toutes sortes de raisons.
c'est mort.... Bon, il reste Solaris. QUelqu'un a testé Hammer sous DragonFlyBSD? :)
C'est encore en développement, il faut au moins 5 ans pour développer un truc pareil, se lancer là dedans au lieu de suivre l'idée initiale de dragonfly m'a toujours semblé une idée bizarre.
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Sat, 12 Dec 2009 04:01:33 +0100, Stephan Peccini a écrit:
> en oubliant complétement de signaler que ce n'est pas sous Linux qu'il
> faut l'utiliser en production.
Et apparemment, sous FreeBSD c'est pas encore tout à fait ça; sous Darwin
Il paraît que ça marche parfaitement en 64 bits sous FreeBSD. Je l'ai
sur une partition de ma machine en 32 bits, il ne m'a jamais fait de
panic, mais je ne le sollicite pas beaucoup, en gros uniquement la mise
à jour de l'arbre des ports tous les jours et quelques compilations.
J'ai réduit drastiquement la taille du cache (arc) donc les perfs sont
limitées, mais enfin ça marche sur une machine x86-32 avec 1.5 Gigs
de mémoire. En général si on veut des perfs, il faut beaucoup de cache,
donc beaucoup de mémoire, donc 64 bits. Dans ces conditions, il semble
que les performances soient de haut niveau, supérieures à UFS, et
évidemment on a en plus toutes les commodités et sécurités de ZFS.
Je pense que dans le genre d'applications que tu as dans ton business,
FreeBSD + ZFS devrait être très supérieur à Linux, pour toutes sortes de
raisons.
c'est mort.... Bon, il reste Solaris. QUelqu'un a testé Hammer sous
DragonFlyBSD? :)
C'est encore en développement, il faut au moins 5 ans pour développer un
truc pareil, se lancer là dedans au lieu de suivre l'idée initiale de
dragonfly m'a toujours semblé une idée bizarre.
Le Sat, 12 Dec 2009 04:01:33 +0100, Stephan Peccini a écrit:
> en oubliant complétement de signaler que ce n'est pas sous Linux qu'il > faut l'utiliser en production.
Et apparemment, sous FreeBSD c'est pas encore tout à fait ça; sous Darwin
Il paraît que ça marche parfaitement en 64 bits sous FreeBSD. Je l'ai sur une partition de ma machine en 32 bits, il ne m'a jamais fait de panic, mais je ne le sollicite pas beaucoup, en gros uniquement la mise à jour de l'arbre des ports tous les jours et quelques compilations. J'ai réduit drastiquement la taille du cache (arc) donc les perfs sont limitées, mais enfin ça marche sur une machine x86-32 avec 1.5 Gigs de mémoire. En général si on veut des perfs, il faut beaucoup de cache, donc beaucoup de mémoire, donc 64 bits. Dans ces conditions, il semble que les performances soient de haut niveau, supérieures à UFS, et évidemment on a en plus toutes les commodités et sécurités de ZFS.
Je pense que dans le genre d'applications que tu as dans ton business, FreeBSD + ZFS devrait être très supérieur à Linux, pour toutes sortes de raisons.
c'est mort.... Bon, il reste Solaris. QUelqu'un a testé Hammer sous DragonFlyBSD? :)
C'est encore en développement, il faut au moins 5 ans pour développer un truc pareil, se lancer là dedans au lieu de suivre l'idée initiale de dragonfly m'a toujours semblé une idée bizarre.
--
Michel TALON
Stephane TOUGARD
JKB wrote:
plus à mettre en frontaux des machines sous Solaris !). Bref, une architecture, ça se pense, c'est une histoire de compromis. C'est ça le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un bouquin, j'en connais plein qui sont aussi interessants.
JKB wrote:
plus à mettre en frontaux des machines sous Solaris !). Bref, une
architecture, ça se pense, c'est une histoire de compromis. C'est ça
le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un
bouquin, j'en connais plein qui sont aussi interessants.
plus à mettre en frontaux des machines sous Solaris !). Bref, une architecture, ça se pense, c'est une histoire de compromis. C'est ça le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un bouquin, j'en connais plein qui sont aussi interessants.
JKB
Le 12-12-2009, ? propos de Re: Trojan dans Linux, Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
plus à mettre en frontaux des machines sous Solaris !). Bref, une architecture, ça se pense, c'est une histoire de compromis. C'est ça le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un bouquin, j'en connais plein qui sont aussi interessants.
Explique-nous.
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 12-12-2009, ? propos de
Re: Trojan dans Linux,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
plus à mettre en frontaux des machines sous Solaris !). Bref, une
architecture, ça se pense, c'est une histoire de compromis. C'est ça
le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un
bouquin, j'en connais plein qui sont aussi interessants.
Explique-nous.
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 12-12-2009, ? propos de Re: Trojan dans Linux, Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
plus à mettre en frontaux des machines sous Solaris !). Bref, une architecture, ça se pense, c'est une histoire de compromis. C'est ça le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un bouquin, j'en connais plein qui sont aussi interessants.
Explique-nous.
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.
Stephane TOUGARD
JKB wrote:
JKB wrote:
plus à mettre en frontaux des machines sous Solaris !). Bref, une architecture, ça se pense, c'est une histoire de compromis. C'est ça le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un bouquin, j'en connais plein qui sont aussi interessants.
Explique-nous.
Il y a rien a expliquer. T'as ecrit 40 lignes et tu n'as strictement rien dit. Ah si, tu t'es gonfle les chevilles, ca tres fort. Franchement j'admire ta capacite a t'auto-admirer.
JKB wrote:
JKB wrote:
plus à mettre en frontaux des machines sous Solaris !). Bref, une
architecture, ça se pense, c'est une histoire de compromis. C'est ça
le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un
bouquin, j'en connais plein qui sont aussi interessants.
Explique-nous.
Il y a rien a expliquer. T'as ecrit 40 lignes et tu n'as strictement
rien dit. Ah si, tu t'es gonfle les chevilles, ca tres fort. Franchement
j'admire ta capacite a t'auto-admirer.
plus à mettre en frontaux des machines sous Solaris !). Bref, une architecture, ça se pense, c'est une histoire de compromis. C'est ça le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un bouquin, j'en connais plein qui sont aussi interessants.
Explique-nous.
Il y a rien a expliquer. T'as ecrit 40 lignes et tu n'as strictement rien dit. Ah si, tu t'es gonfle les chevilles, ca tres fort. Franchement j'admire ta capacite a t'auto-admirer.
