Quand le bureau KDE et toutes ses applications seront portés sur Windows
(on s'en rapproche pour ceux qui suivent, les applications deviennent de
plus en plus stables), celui-ci envahira Windows car, contrairement à
Linux qui possède des dizaines de bureaux, il sera l'unique alternative
au bureau Windows : KDE apporterait un souffle nouveau à Windows, en
tous cas plus que le bureau de Seven.
Du coup, l'utilisateur lambda (qui est l'utilisateur très largement
majoritaire) ne verra plus la différence entre un Windows et un linux
(ou un OpenSolaris ou un BSD) qui tournera derrière et au bout du
compte, il préférera naturellement se tourner vers l'OS qui lui coûte le
moins cher.
Dans fr.comp.os.linux.debats Yves Lambert nous expliquait:
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
*toutes* les distributions sont basée sur la slack. Par définition.
Non, toutes les distrib sont basees sur la SLS (Slack incluse).
Désolé j'ai du confuser. Néanmoins j'aurais du mal avec la slackware. Je préférerait ne pas avoir du tout de gestion de paquetage (un système de ports me plait bien)
Ca existe (j'adore le nom de ce projet, ça met en confiance :-D ) http://emerde.freaknet.org/ (je ne sais pas ce que ça vaut)
Sinon il existe une version de pkgsrc adapté à Slackware mais dans mes souvenirs c'est assez foireux, tout au moins risqué.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.os.linux.debats Yves Lambert nous expliquait:
In article <lcv717-e2l2.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Yves Lambert a perdu son temps a nous dire:
*toutes* les distributions sont basée sur la slack. Par définition.
Non, toutes les distrib sont basees sur la SLS (Slack incluse).
Désolé j'ai du confuser. Néanmoins j'aurais du mal avec la slackware. Je
préférerait ne pas avoir du tout de gestion de paquetage (un système de
ports me plait bien)
Ca existe (j'adore le nom de ce projet, ça met en confiance :-D )
http://emerde.freaknet.org/ (je ne sais pas ce que ça vaut)
Sinon il existe une version de pkgsrc adapté à Slackware mais dans
mes souvenirs c'est assez foireux, tout au moins risqué.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Dans fr.comp.os.linux.debats Yves Lambert nous expliquait:
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
*toutes* les distributions sont basée sur la slack. Par définition.
Non, toutes les distrib sont basees sur la SLS (Slack incluse).
Désolé j'ai du confuser. Néanmoins j'aurais du mal avec la slackware. Je préférerait ne pas avoir du tout de gestion de paquetage (un système de ports me plait bien)
Ca existe (j'adore le nom de ce projet, ça met en confiance :-D ) http://emerde.freaknet.org/ (je ne sais pas ce que ça vaut)
Sinon il existe une version de pkgsrc adapté à Slackware mais dans mes souvenirs c'est assez foireux, tout au moins risqué.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
yl
In article , JKB writes:
Le 03-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
Ces OS plus stables ne tournent pas sur PC ???
Et non, comme quoi a chaque plateforme son OS et a chaque OS sa plateforme.
Exemple d'OS (on va rester dans l'open source pour ne pas trop se disperser) qui tourne sur d'hypothétiques machines ultra-stables (tu n'as pas cité de marque on ne peut faire que des suppositions) qui ne peut pas etre porté sur un PC ?
Il y a un projet qui consiste à cloner OpenVMS sur PC
Si le projet aboutit je connais quelqu'un que ça interresera.
et qui patine sur la PAL des machines VAX/Alpha/IA64. Une partie de l'OS est codée en dur dans un FPGA qui gère les niveaux de privilège. Ces niveaux de privilèges n'existant pas sur un processeur intel, il te faut émuler le fonctionnement de ladite PAL en soft, ce qui est loin d'être trivial.
Ok. Je comprend mieux ce que voulait dire ST, mais il n'a pas été foutu de donner un seul exemple Open Source. C'est encore d'actualité sur des machines neuves OS400, Irix, HP/UX etc. ? Et qu'est-ce qui empecherait de porter IRIX et HP/UX sur PC si on avait les sources ? Rien, si ? Quand à OS400 il existe des émulateurs qui tournent sur PC...
Tant que c'est en userland, c'est assez facile. Mais en mode kernel, c'est beaucoup plus joyeux ;-)
J'imagine, et je vois l'intéret (j'ai travaillé (comme luser, hein, je n'ai aps fait d'administration système) sur Multics. Aucun Unix n'atteint la sophistication de la gestion des niveaux de privilège de Multics. VMS je croyais que c'était très basique à ce niveau là au contraire. Je connais très mal...
-- http://mikeread.tripod.com/archive.htm
In article <slrnhk232f.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article <fp1617-h7j2.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Yves Lambert a perdu son temps a nous dire:
Ces OS plus stables ne tournent pas sur PC ???
Et non, comme quoi a chaque plateforme son OS et a chaque OS sa
plateforme.
Exemple d'OS (on va rester dans l'open source pour ne pas trop se
disperser) qui tourne sur d'hypothétiques machines ultra-stables (tu
n'as pas cité de marque on ne peut faire que des suppositions) qui ne
peut pas etre porté sur un PC ?
Il y a un projet qui consiste à cloner OpenVMS sur PC
Si le projet aboutit je connais quelqu'un que ça interresera.
et qui patine sur
la PAL des machines VAX/Alpha/IA64. Une partie de l'OS est codée en
dur dans un FPGA qui gère les niveaux de privilège. Ces niveaux de
privilèges n'existant pas sur un processeur intel, il te faut émuler
le fonctionnement de ladite PAL en soft, ce qui est loin d'être
trivial.
Ok. Je comprend mieux ce que voulait dire ST, mais il n'a pas été foutu
de donner un seul exemple Open Source. C'est encore d'actualité sur des
machines neuves OS400, Irix, HP/UX etc. ? Et qu'est-ce qui empecherait
de porter IRIX et HP/UX sur PC si on avait les sources ? Rien, si ?
Quand à OS400 il existe des émulateurs qui tournent sur PC...
Tant que c'est en userland, c'est assez facile. Mais en
mode kernel, c'est beaucoup plus joyeux ;-)
J'imagine, et je vois l'intéret (j'ai travaillé (comme luser, hein, je
n'ai aps fait d'administration système) sur Multics. Aucun Unix
n'atteint la sophistication de la gestion des niveaux de privilège de
Multics. VMS je croyais que c'était très basique à ce niveau là au
contraire. Je connais très mal...
Le 03-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
Ces OS plus stables ne tournent pas sur PC ???
Et non, comme quoi a chaque plateforme son OS et a chaque OS sa plateforme.
Exemple d'OS (on va rester dans l'open source pour ne pas trop se disperser) qui tourne sur d'hypothétiques machines ultra-stables (tu n'as pas cité de marque on ne peut faire que des suppositions) qui ne peut pas etre porté sur un PC ?
Il y a un projet qui consiste à cloner OpenVMS sur PC
Si le projet aboutit je connais quelqu'un que ça interresera.
et qui patine sur la PAL des machines VAX/Alpha/IA64. Une partie de l'OS est codée en dur dans un FPGA qui gère les niveaux de privilège. Ces niveaux de privilèges n'existant pas sur un processeur intel, il te faut émuler le fonctionnement de ladite PAL en soft, ce qui est loin d'être trivial.
Ok. Je comprend mieux ce que voulait dire ST, mais il n'a pas été foutu de donner un seul exemple Open Source. C'est encore d'actualité sur des machines neuves OS400, Irix, HP/UX etc. ? Et qu'est-ce qui empecherait de porter IRIX et HP/UX sur PC si on avait les sources ? Rien, si ? Quand à OS400 il existe des émulateurs qui tournent sur PC...
Tant que c'est en userland, c'est assez facile. Mais en mode kernel, c'est beaucoup plus joyeux ;-)
J'imagine, et je vois l'intéret (j'ai travaillé (comme luser, hein, je n'ai aps fait d'administration système) sur Multics. Aucun Unix n'atteint la sophistication de la gestion des niveaux de privilège de Multics. VMS je croyais que c'était très basique à ce niveau là au contraire. Je connais très mal...
-- http://mikeread.tripod.com/archive.htm
yl
In article , Stephane TOUGARD writes:
Patrice Karatchentzeff a perdu son temps a nous dire:
Tiens, c'est vrai : on va dire que Suse et Solaris font kif-kif dans ce cas, chacune étant un peu cantonnée dans son secteur...
J'aime les stats vues par PK, on dirait un mix de P4 et de pipolin.
ça va se voir que tu ne sais pas lire. Il était juste question de softs qui ne sont supportés que sur la redhat et d'autres qui ne sont supporté que sur la suse, PK plussoie avec Solaris et ne parle certainement pas de stats.
-- http://mikeread.tripod.com/archive.htm
In article <riu817-phs1.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Patrice Karatchentzeff a perdu son temps a nous dire:
Tiens, c'est vrai : on va dire que Suse et Solaris font kif-kif dans
ce cas, chacune étant un peu cantonnée dans son secteur...
J'aime les stats vues par PK, on dirait un mix de P4 et de pipolin.
ça va se voir que tu ne sais pas lire. Il était juste question de softs qui
ne sont supportés que sur la redhat et d'autres qui ne sont supporté
que sur la suse, PK plussoie avec Solaris et ne parle certainement pas de
stats.
Patrice Karatchentzeff a perdu son temps a nous dire:
Tiens, c'est vrai : on va dire que Suse et Solaris font kif-kif dans ce cas, chacune étant un peu cantonnée dans son secteur...
J'aime les stats vues par PK, on dirait un mix de P4 et de pipolin.
ça va se voir que tu ne sais pas lire. Il était juste question de softs qui ne sont supportés que sur la redhat et d'autres qui ne sont supporté que sur la suse, PK plussoie avec Solaris et ne parle certainement pas de stats.
-- http://mikeread.tripod.com/archive.htm
yl
In article <hhqfd7$g99$, Nicolas George <nicolas$ writes:
Michel Talon, dans le message <hhq0np$asm$, a écrit :
Cette assertion est parfaitement ridicule,
C'est ce que j'ai hélas trop souvent constaté. J'ai pas mal fouillé dans les sources de divers trucs, et ça fait parfois très peur.
du même tonneau que celle qui consiste à dire qu'un prof de math de lycée est plus compétent qu'un grand mathématicien pour exposer au mieux un sujet.
Ça dépend pour exposer quel sujet à quel public.
Tout dépend aussi si le grand mathématicien enseigne et auprès de quel public ou bien s'il ne sort pas de son labo et ne communique qu'avec ses pairs et si le prof du lycée est docteur et agrégé ou propédeutique et certifié.
-- http://mikeread.tripod.com/archive.htm
In article <hhqfd7$g99$1@nef.ens.fr>,
Nicolas George <nicolas$george@salle-s.org> writes:
Michel Talon, dans le message <hhq0np$asm$1@asmodee.lpthe.jussieu.fr>, a
écrit :
Cette assertion est parfaitement ridicule,
C'est ce que j'ai hélas trop souvent constaté. J'ai pas mal fouillé dans les
sources de divers trucs, et ça fait parfois très peur.
du même tonneau que celle
qui consiste à dire qu'un prof de math de lycée est plus compétent
qu'un grand mathématicien pour exposer au mieux un sujet.
Ça dépend pour exposer quel sujet à quel public.
Tout dépend aussi si le grand mathématicien enseigne et auprès de quel public
ou bien s'il ne sort pas de son labo et ne communique qu'avec ses pairs
et si le prof du lycée est docteur et agrégé ou propédeutique et certifié.
In article <hhqfd7$g99$, Nicolas George <nicolas$ writes:
Michel Talon, dans le message <hhq0np$asm$, a écrit :
Cette assertion est parfaitement ridicule,
C'est ce que j'ai hélas trop souvent constaté. J'ai pas mal fouillé dans les sources de divers trucs, et ça fait parfois très peur.
du même tonneau que celle qui consiste à dire qu'un prof de math de lycée est plus compétent qu'un grand mathématicien pour exposer au mieux un sujet.
Ça dépend pour exposer quel sujet à quel public.
Tout dépend aussi si le grand mathématicien enseigne et auprès de quel public ou bien s'il ne sort pas de son labo et ne communique qu'avec ses pairs et si le prof du lycée est docteur et agrégé ou propédeutique et certifié.
-- http://mikeread.tripod.com/archive.htm
yl
In article <4b40e23a$0$6275$, Stéphane CARPENTIER writes:
Yves Lambert wrote:
In article <4b40b3ef$0$4970$, Stéphane CARPENTIER writes:
Ce n'est pas insultant pour les développeurs originaux, c'est reconnaître qu'ils ne font pas le même métier.
Je suis d'accord aussi. Je rajouterai qu'il ne faut pas les opposer non plus.
Ouais, ben c'est un forum de troll aussi. Ça fait parti du jeu de dire un truc vrai qui peut avoir des interprétations fausses.
Le trollage n'est pas une obligation ni meme une pratique conseillée, il est juste explicitement autorisé sur ce forum.
-- http://mikeread.tripod.com/archive.htm
In article <4b40e23a$0$6275$426a34cc@news.free.fr>,
Stéphane CARPENTIER <stef.carpentier@gratuit.fr.invalid> writes:
Yves Lambert wrote:
In article <4b40b3ef$0$4970$426a34cc@news.free.fr>,
Stéphane CARPENTIER <stef.carpentier@gratuit.fr.invalid> writes:
Ce n'est pas insultant pour les développeurs originaux, c'est
reconnaître qu'ils ne font pas le même métier.
Je suis d'accord aussi. Je rajouterai qu'il ne faut pas
les opposer non plus.
Ouais, ben c'est un forum de troll aussi. Ça fait parti du jeu de dire
un truc vrai qui peut avoir des interprétations fausses.
Le trollage n'est pas une obligation ni meme une pratique conseillée,
il est juste explicitement autorisé sur ce forum.
In article <4b40e23a$0$6275$, Stéphane CARPENTIER writes:
Yves Lambert wrote:
In article <4b40b3ef$0$4970$, Stéphane CARPENTIER writes:
Ce n'est pas insultant pour les développeurs originaux, c'est reconnaître qu'ils ne font pas le même métier.
Je suis d'accord aussi. Je rajouterai qu'il ne faut pas les opposer non plus.
Ouais, ben c'est un forum de troll aussi. Ça fait parti du jeu de dire un truc vrai qui peut avoir des interprétations fausses.
Le trollage n'est pas une obligation
Non.
ni meme une pratique conseillée,
Non plus.
il est juste explicitement autorisé sur ce forum.
Voilà. Donc, il faut t'attendre à ce qu'il y en ait beaucoup qui trollent ici.
yl
In article , JKB writes:
J'ai plusieurs programmes qui ne _fonctionnent_ pas sur NetBSD en raison de bugs spécifiques (sigpending()). Sous FreeBSD, j'ai trouvé un bug dans sig_info. Sous OpenBSD, il traîne un sombre problème dans sigaltstack().
La gestion des signaux n'est pas très différente sous *BSD et linux ? Je pensais que tu parlais de programmes en userland.
Les logiciels des ports ont été patchés pour fonctionner malgré ces problèmes (en tout cas, mon NetBSD/sparc32 et mon FreeBSD/i386 téléchargent les sources puis les patchent). Il ne me viendrait pas à l'idée d'utiliser autre chose que les logiciels des ports car le fonctionnement de ceux-ci ont été validés.
Ce que je parlais c'était de patcher un port ou ajiouter un port pour répondre à un besoin spécifique. Chez toi tu t'en fous, et pour le valider, ça passe par les développeurs du BSDD sur lequel tuu le fais (ou si c'(est crade tu ne le propose pas). 1. Utiliser le mécanislme de port pour un logiciel qui n'y est pas ou patcher le port pour qu'il installe la version qui t(intéresse et qui n'est pas la version du port ou bien - éventuellement appliquer des patchs tiers, si tu sais leur utilité (ça ou des patchs que tu as fait toi, c'est hyper facile du moins avec NetBSD.
Je me contrefiche de la sécurité de ces machines de test
Là il était plus question de fonctionnalité que de sécurité. Ou alors j'ai pas suivi le film.
car elles ne sont pas directement sur le grand ternet (adresses non routables et derrière des firewall sérieux). Les frontales sont toutes sous debian avec les patches de sécurité.
LAMP c'est d'un commun :)
-- http://mikeread.tripod.com/archive.htm
In article <slrnhk1fvc.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
J'ai plusieurs programmes qui ne _fonctionnent_ pas sur NetBSD en
raison de bugs spécifiques (sigpending()). Sous FreeBSD, j'ai trouvé
un bug dans sig_info. Sous OpenBSD, il traîne un sombre problème
dans sigaltstack().
La gestion des signaux n'est pas très différente sous *BSD et linux ? Je
pensais que tu parlais de programmes en userland.
Les logiciels des ports ont été patchés pour
fonctionner malgré ces problèmes (en tout cas, mon NetBSD/sparc32 et
mon FreeBSD/i386 téléchargent les sources puis les patchent). Il ne
me viendrait pas à l'idée d'utiliser autre chose que les logiciels
des ports car le fonctionnement de ceux-ci ont été validés.
Ce que je parlais c'était de patcher un port ou ajiouter un port pour
répondre à un besoin spécifique. Chez toi tu t'en fous, et pour le
valider, ça passe par les développeurs du BSDD sur lequel tuu le fais
(ou si c'(est crade tu ne le propose pas).
1. Utiliser le mécanislme de port pour un logiciel qui n'y est pas ou
patcher le port pour qu'il installe la version qui t(intéresse et qui
n'est pas la version du port ou bien
- éventuellement appliquer des patchs tiers, si tu sais leur utilité (ça
ou des patchs que tu as fait toi, c'est hyper facile du moins avec
NetBSD.
Je me contrefiche de la sécurité de ces machines de test
Là il était plus question de fonctionnalité que de sécurité. Ou alors
j'ai pas suivi le film.
car elles
ne sont pas directement sur le grand ternet (adresses non routables
et derrière des firewall sérieux). Les frontales sont toutes sous
debian avec les patches de sécurité.
J'ai plusieurs programmes qui ne _fonctionnent_ pas sur NetBSD en raison de bugs spécifiques (sigpending()). Sous FreeBSD, j'ai trouvé un bug dans sig_info. Sous OpenBSD, il traîne un sombre problème dans sigaltstack().
La gestion des signaux n'est pas très différente sous *BSD et linux ? Je pensais que tu parlais de programmes en userland.
Les logiciels des ports ont été patchés pour fonctionner malgré ces problèmes (en tout cas, mon NetBSD/sparc32 et mon FreeBSD/i386 téléchargent les sources puis les patchent). Il ne me viendrait pas à l'idée d'utiliser autre chose que les logiciels des ports car le fonctionnement de ceux-ci ont été validés.
Ce que je parlais c'était de patcher un port ou ajiouter un port pour répondre à un besoin spécifique. Chez toi tu t'en fous, et pour le valider, ça passe par les développeurs du BSDD sur lequel tuu le fais (ou si c'(est crade tu ne le propose pas). 1. Utiliser le mécanislme de port pour un logiciel qui n'y est pas ou patcher le port pour qu'il installe la version qui t(intéresse et qui n'est pas la version du port ou bien - éventuellement appliquer des patchs tiers, si tu sais leur utilité (ça ou des patchs que tu as fait toi, c'est hyper facile du moins avec NetBSD.
Je me contrefiche de la sécurité de ces machines de test
Là il était plus question de fonctionnalité que de sécurité. Ou alors j'ai pas suivi le film.
car elles ne sont pas directement sur le grand ternet (adresses non routables et derrière des firewall sérieux). Les frontales sont toutes sous debian avec les patches de sécurité.
LAMP c'est d'un commun :)
-- http://mikeread.tripod.com/archive.htm
yl
In article , Stephane TOUGARD writes:
Stéphane CARPENTIER a perdu son temps a nous dire:
Mais ce qui me gêne, c'est de faire un ./configure && make && make install sur un serveur de prod, sans avoir peur du script kiddy.
Ca n'a rien de plus dangereux que de downloader un package binaire, l'installation se passe egalement en root et le package peut embarquer un script kiddy exactement de la meme facon.
Oui bon, après réflexion, je ne suis plus tout à fait d'accord avec PK et SC, mais j'ai mieux compris le souci. Si tu as une machine compromlise sur le réseau, et qu'elle dispose d'une chaine de compilation complète, celle ci peut etre utilisée pour installer le rootkit le plus vicieux, une bombe ou tout autre malware, alors que si ce n'est pas le cas, l'attaquant resterait dans son rootjail et ne peut rien faire d'autre que ce que tu lui permet. Ce n'est pas le code du logiciel qui est en jeu, mais le fait de le compiler sur le serveur de prod (et donc que celui ci embarque make, gcc et wget)
-- http://mikeread.tripod.com/archive.htm
In article <1su717-e2l2.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Stéphane CARPENTIER a perdu son temps a nous dire:
Mais ce qui me gêne, c'est de faire un ./configure && make && make
install sur un serveur de prod, sans avoir peur du script kiddy.
Ca n'a rien de plus dangereux que de downloader un package binaire,
l'installation se passe egalement en root et le package peut embarquer
un script kiddy exactement de la meme facon.
Oui bon, après réflexion, je ne suis plus tout à fait d'accord avec PK et
SC, mais j'ai mieux compris le souci. Si tu as une machine compromlise
sur le réseau, et qu'elle dispose d'une chaine de compilation complète,
celle ci peut etre utilisée pour installer le rootkit le plus vicieux,
une bombe ou tout autre malware, alors que si ce n'est pas le cas,
l'attaquant resterait dans son rootjail et ne peut rien faire d'autre
que ce que tu lui permet. Ce n'est pas le code du logiciel qui est en
jeu, mais le fait de le compiler sur le serveur de prod (et donc que
celui ci embarque make, gcc et wget)
Stéphane CARPENTIER a perdu son temps a nous dire:
Mais ce qui me gêne, c'est de faire un ./configure && make && make install sur un serveur de prod, sans avoir peur du script kiddy.
Ca n'a rien de plus dangereux que de downloader un package binaire, l'installation se passe egalement en root et le package peut embarquer un script kiddy exactement de la meme facon.
Oui bon, après réflexion, je ne suis plus tout à fait d'accord avec PK et SC, mais j'ai mieux compris le souci. Si tu as une machine compromlise sur le réseau, et qu'elle dispose d'une chaine de compilation complète, celle ci peut etre utilisée pour installer le rootkit le plus vicieux, une bombe ou tout autre malware, alors que si ce n'est pas le cas, l'attaquant resterait dans son rootjail et ne peut rien faire d'autre que ce que tu lui permet. Ce n'est pas le code du logiciel qui est en jeu, mais le fait de le compiler sur le serveur de prod (et donc que celui ci embarque make, gcc et wget)
-- http://mikeread.tripod.com/archive.htm
Riquer Vincent
Yves Lambert a écrit :
In article , JKB writes:
C'est sûr qu'en consommation brute et en chauffage d'appoint, c'est pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine charge. Le jour où je trouve un i386 capable de faire ça, je reviendrai sur ma position.
460W quand meme.
Soit le dimensionnement d'une alim de serveur à base de Xeon...
Yves Lambert a écrit :
In article <slrnhk1omh.big.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
C'est sûr qu'en consommation brute et en chauffage d'appoint, c'est
pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine
charge. Le jour où je trouve un i386 capable de faire ça, je
reviendrai sur ma position.
460W quand meme.
Soit le dimensionnement d'une alim de serveur à base de Xeon...
C'est sûr qu'en consommation brute et en chauffage d'appoint, c'est pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine charge. Le jour où je trouve un i386 capable de faire ça, je reviendrai sur ma position.
460W quand meme.
Soit le dimensionnement d'une alim de serveur à base de Xeon...
yl
In article , Stephane TOUGARD writes:
JKB a perdu son temps a nous dire:
Utiliser exim pour un serveur privé (comprendre une station de travail qui a besoin d'un serveur de mail pour que certains daemons puissent envoyer un courrier à l'administrateur en cas de problème), pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise tant le truc est troué.
C'est faux. Les failles sont corrigées. ALors que Postfix qui n'a soi-disant pas eu de problème de sécurité n'a pas eu non plus de patches de sécurité.
Oui on sait, comme Qmail, comme Postfix, comme ... en fait tout ce qui n'est pas sendmail
exim4 ne doit plus avoir grand chose de commun avec le sendmail d'origine. Mais c'est une usine à gaz à con,figurer, mais une fois que ça l'est c'est plutot tranquille.
ça ne répond toujours pas à ma question : pourquoi c'est MAL de mettre un spamd sur le mx frontal (qu'il tourne en socket unix ou en socket tcp, sur le serveur de mail ou une autre machine n'entre pas en jeu dans la question) et que ce soit postfix ou exim4 ne change strictement rien au problème puisque les deux le permettent. Je n'y vois que des avantages (à part le temps machine). Je ne sais pas qui a dit que c'était mal, qu'il se dénonce et m'explique pourquoi.
(de preference sur OpenVMS).
Oui mais bon c'est apparemment la seule réponse à la question que je t'avais posé par ailleurs, et j'avoue que les arguments sont solides. D'autant que les exemple que tu as donné meme en ne tenant pas compte de la contrainte que j'avais donné ne tiennent pas la route. -- http://mikeread.tripod.com/archive.htm
In article <tvu717-e2l2.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
JKB a perdu son temps a nous dire:
Utiliser exim pour un serveur privé (comprendre une station de
travail qui a besoin d'un serveur de mail pour que certains daemons
puissent envoyer un courrier à l'administrateur en cas de problème),
pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise
tant le truc est troué.
C'est faux. Les failles sont corrigées. ALors que Postfix qui n'a
soi-disant pas eu de problème de sécurité n'a pas eu non plus de patches
de sécurité.
Oui on sait, comme Qmail, comme Postfix, comme ... en fait tout ce qui
n'est pas sendmail
exim4 ne doit plus avoir grand chose de commun avec le sendmail
d'origine. Mais c'est une usine à gaz à con,figurer, mais une fois que
ça l'est c'est plutot tranquille.
ça ne répond toujours pas à ma question : pourquoi c'est MAL de mettre un spamd
sur le mx frontal (qu'il tourne en socket unix ou en socket tcp, sur le
serveur de mail ou une autre machine n'entre pas en jeu dans la
question) et que ce soit postfix ou exim4 ne change strictement rien au
problème puisque les deux le permettent. Je n'y vois que des avantages
(à part le temps machine). Je ne sais pas qui a dit que c'était mal,
qu'il se dénonce et m'explique pourquoi.
(de preference sur OpenVMS).
Oui mais bon c'est apparemment la seule réponse à la question que je
t'avais posé par ailleurs, et j'avoue que les arguments sont solides.
D'autant que les exemple que tu as donné meme en ne tenant pas compte de
la contrainte que j'avais donné ne tiennent pas la route.
--
http://mikeread.tripod.com/archive.htm
Utiliser exim pour un serveur privé (comprendre une station de travail qui a besoin d'un serveur de mail pour que certains daemons puissent envoyer un courrier à l'administrateur en cas de problème), pourquoi pas. L'utiliser sur un vrai serveur de mail est une bêtise tant le truc est troué.
C'est faux. Les failles sont corrigées. ALors que Postfix qui n'a soi-disant pas eu de problème de sécurité n'a pas eu non plus de patches de sécurité.
Oui on sait, comme Qmail, comme Postfix, comme ... en fait tout ce qui n'est pas sendmail
exim4 ne doit plus avoir grand chose de commun avec le sendmail d'origine. Mais c'est une usine à gaz à con,figurer, mais une fois que ça l'est c'est plutot tranquille.
ça ne répond toujours pas à ma question : pourquoi c'est MAL de mettre un spamd sur le mx frontal (qu'il tourne en socket unix ou en socket tcp, sur le serveur de mail ou une autre machine n'entre pas en jeu dans la question) et que ce soit postfix ou exim4 ne change strictement rien au problème puisque les deux le permettent. Je n'y vois que des avantages (à part le temps machine). Je ne sais pas qui a dit que c'était mal, qu'il se dénonce et m'explique pourquoi.
(de preference sur OpenVMS).
Oui mais bon c'est apparemment la seule réponse à la question que je t'avais posé par ailleurs, et j'avoue que les arguments sont solides. D'autant que les exemple que tu as donné meme en ne tenant pas compte de la contrainte que j'avais donné ne tiennent pas la route. -- http://mikeread.tripod.com/archive.htm
