"KDE 4.3.2 est efficace et rapide. Ce n’est pas un environnement de
travail facile d’accès, car il est aussi puissant que polyvalent. Une
impression de fouillis se fait donc rapidement sentir. Les plus frileux
préféreront donc peut-être GNOME, qui est ici présent en mouture
2.28.1."
Essayez d'y comprendre qqchose ... En tout cas c'est pas fait pour
travailler...
"Un manque flagrant de sobriété
Une distribution Linux axée sur KDE est toujours intéressante.
Toutefois, la complexité de cet environnement de bureau empire à cause
des choix réalisés par Mandriva. Il est ainsi dommage qu’autant
d’applications KDE soient installées par défaut. Était-il nécessaire de
proposer plusieurs dizaines de jeux, ou des outils multiples effectuant
des tâches identiques ? Même constat avec le design de l’OS : il est
superbe, mais peu adapté aux professionnels. Heureusement, ce point
pourra facilement être corrigé"
Essayez d'y comprendre qqchose ... En tout cas c'est pas fait pour
travailler...
"Et que dire de l’excellente suite bureautique KOffice, qui n’est même
pas installée par défaut"
Essayez d'y comprendre qqchose ... En tout cas c'est pas fait pour
travailler...
Bref, c'est un jouet de boutonneux cliquodrômé
--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com
Vu que je vois des Debian partout aujourd'hui, y compris chez des gens qui disent ne pas l'utiliser, tu vas te retrouver bientôt tout seul.
On doit pas bosser dans les memes boites alors.
Ce que je peux te dire, c'est que les Telcos, c'est pas vraiment une distrib qui vient a l'esprit quand on parle de Linux. En tous, j'ai jamais vu une plateforme l'utiliser dans ce domaine.
Patrice Karatchentzeff wrote:
Vu que je vois des Debian partout aujourd'hui, y compris chez des gens
qui disent ne pas l'utiliser, tu vas te retrouver bientôt tout seul.
On doit pas bosser dans les memes boites alors.
Ce que je peux te dire, c'est que les Telcos, c'est pas vraiment une
distrib qui vient a l'esprit quand on parle de Linux. En tous, j'ai
jamais vu une plateforme l'utiliser dans ce domaine.
Vu que je vois des Debian partout aujourd'hui, y compris chez des gens qui disent ne pas l'utiliser, tu vas te retrouver bientôt tout seul.
On doit pas bosser dans les memes boites alors.
Ce que je peux te dire, c'est que les Telcos, c'est pas vraiment une distrib qui vient a l'esprit quand on parle de Linux. En tous, j'ai jamais vu une plateforme l'utiliser dans ce domaine.
totof01
On 9 nov, 18:42, Nicolas George <nicolas$ wrote:
totof01 , dans le message , a écrit :
> C'est le genre de comportement qui m'horripile chez Debian ...
Et tu as des raisons de fond à ton horripilation, ou c'est juste épid ermique et irrationnel ?
Il y a des raisons de fond. Tôt ou tard, lorsque j'administre une Debian, j'en viens à m'énerver parce que la distribution pense qu'elle sait mieux que toi ce que ta machine doit faire.
Pour moi un gestionnaire de paquets doit se contenter d'installer les paquets et les dépendance. La configuration c'est le travail de l'admin, pas du gestionnaire de paquet. Et les commandes du style dpkg configure ou le comportement auquel je répondais, ça me gonfle grave .... Mais je conçois tout à fait que ça puisse convenir à d'autres personnes ...
On 9 nov, 18:42, Nicolas George <nicolas$geo...@salle-s.org> wrote:
totof01 , dans le message
<e4f3298f-770a-421a-9d04-fea21328d...@s31g2000yqs.googlegroups.com>, a
écrit :
> C'est le genre de comportement qui m'horripile chez Debian ...
Et tu as des raisons de fond à ton horripilation, ou c'est juste épid ermique
et irrationnel ?
Il y a des raisons de fond. Tôt ou tard, lorsque j'administre une
Debian, j'en viens à m'énerver parce que la distribution pense qu'elle
sait mieux que toi ce que ta machine doit faire.
Pour moi un gestionnaire de paquets doit se contenter d'installer les
paquets et les dépendance. La configuration c'est le travail de
l'admin, pas du gestionnaire de paquet. Et les commandes du style dpkg
configure ou le comportement auquel je répondais, ça me gonfle
grave .... Mais je conçois tout à fait que ça puisse convenir à
d'autres personnes ...
> C'est le genre de comportement qui m'horripile chez Debian ...
Et tu as des raisons de fond à ton horripilation, ou c'est juste épid ermique et irrationnel ?
Il y a des raisons de fond. Tôt ou tard, lorsque j'administre une Debian, j'en viens à m'énerver parce que la distribution pense qu'elle sait mieux que toi ce que ta machine doit faire.
Pour moi un gestionnaire de paquets doit se contenter d'installer les paquets et les dépendance. La configuration c'est le travail de l'admin, pas du gestionnaire de paquet. Et les commandes du style dpkg configure ou le comportement auquel je répondais, ça me gonfle grave .... Mais je conçois tout à fait que ça puisse convenir à d'autres personnes ...
totof01
On 9 nov, 18:57, (Michel Talon) wrote:
totof01 wrote: > Je me suis toujours demandé comment pouvait être géré une mise à jour > noyau sans redémarrage ....
Tu peux bien retirer le module d'une composante modulaire du noyau, et réinstaller une version nouvelle, tout ça sans rebooter. Par exemp le ce module correspond à un driver, mais ça peut être un système de fichiers, etc. En fait il n'y a qu'une partie centrale du noyau, la gestion des processus, de la mémoire, etc. qui ne peut pas être patch ée sans reboot.
--
Michel TALON
Merci pour l'explication, ça confirme bien ce que je pensais ..... Il y a toujours un morceau du noyau qu'on ne peut pas patcher sans arrêter le système ...
On 9 nov, 18:57, ta...@lpthe.jussieu.fr (Michel Talon) wrote:
totof01 <cdesques...@ifrance.com> wrote:
> Je me suis toujours demandé comment pouvait être géré une mise à jour
> noyau sans redémarrage ....
Tu peux bien retirer le module d'une composante modulaire du noyau,
et réinstaller une version nouvelle, tout ça sans rebooter. Par exemp le
ce module correspond à un driver, mais ça peut être un système de
fichiers, etc. En fait il n'y a qu'une partie centrale du noyau, la
gestion des processus, de la mémoire, etc. qui ne peut pas être patch ée
sans reboot.
--
Michel TALON
Merci pour l'explication, ça confirme bien ce que je pensais ..... Il
y a toujours un morceau du noyau qu'on ne peut pas patcher sans
arrêter le système ...
totof01 wrote: > Je me suis toujours demandé comment pouvait être géré une mise à jour > noyau sans redémarrage ....
Tu peux bien retirer le module d'une composante modulaire du noyau, et réinstaller une version nouvelle, tout ça sans rebooter. Par exemp le ce module correspond à un driver, mais ça peut être un système de fichiers, etc. En fait il n'y a qu'une partie centrale du noyau, la gestion des processus, de la mémoire, etc. qui ne peut pas être patch ée sans reboot.
--
Michel TALON
Merci pour l'explication, ça confirme bien ce que je pensais ..... Il y a toujours un morceau du noyau qu'on ne peut pas patcher sans arrêter le système ...
totof01
On 9 nov, 18:53, Patrice Karatchentzeff wrote:
totof01 a écrit :
> On 8 nov, 21:19, Nicolas George <nicolas$ wrote:
[...]
>> Ce n'est pas nano par défaut, c'est /usr/bin/editor. Si tu ne fais >> pas pointer ce lien vers ton éditeur favori (via >> update-alternative, sinon ce sera annulé à la première mise à >> jour), il ne faut t'en prendre qu'à toi-même. > C'est le genre de comportement qui m'horripile chez Debian ...
C'est pourtant de la simple logique UNIX...
Ce n'est pas parce que les autres ont figé une façon de faire les choses faute d'idées que c'est une bonne idée d'en rester là.
C'est surtout ça qui m'agace : (via update-alternative, sinon ce sera annulé à la première mise à jour)
On 9 nov, 18:53, Patrice Karatchentzeff <p.karatchentz...@free.fr>
wrote:
totof01 <cdesques...@ifrance.com> a écrit :
> On 8 nov, 21:19, Nicolas George <nicolas$geo...@salle-s.org> wrote:
[...]
>> Ce n'est pas nano par défaut, c'est /usr/bin/editor. Si tu ne fais
>> pas pointer ce lien vers ton éditeur favori (via
>> update-alternative, sinon ce sera annulé à la première mise à
>> jour), il ne faut t'en prendre qu'à toi-même.
> C'est le genre de comportement qui m'horripile chez Debian ...
C'est pourtant de la simple logique UNIX...
Ce n'est pas parce que les autres ont figé une façon de faire les
choses faute d'idées que c'est une bonne idée d'en rester là.
C'est surtout ça qui m'agace :
(via update-alternative, sinon ce sera annulé à la première mise à
jour)
> On 8 nov, 21:19, Nicolas George <nicolas$ wrote:
[...]
>> Ce n'est pas nano par défaut, c'est /usr/bin/editor. Si tu ne fais >> pas pointer ce lien vers ton éditeur favori (via >> update-alternative, sinon ce sera annulé à la première mise à >> jour), il ne faut t'en prendre qu'à toi-même. > C'est le genre de comportement qui m'horripile chez Debian ...
C'est pourtant de la simple logique UNIX...
Ce n'est pas parce que les autres ont figé une façon de faire les choses faute d'idées que c'est une bonne idée d'en rester là.
C'est surtout ça qui m'agace : (via update-alternative, sinon ce sera annulé à la première mise à jour)
JKB
Le 10-11-2009, ? propos de Re: Ils ne sont pas difficile..., Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff wrote:
Vu que je vois des Debian partout aujourd'hui, y compris chez des gens qui disent ne pas l'utiliser, tu vas te retrouver bientôt tout seul.
On doit pas bosser dans les memes boites alors.
Ce que je peux te dire, c'est que les Telcos, c'est pas vraiment une distrib qui vient a l'esprit quand on parle de Linux. En tous, j'ai jamais vu une plateforme l'utiliser dans ce domaine.
Et bien, on ne doit pas vraiment connaître les mêmes... Les telcos comme je les connais, ils utilisent RedHat lorsqu'il faut un support. Dans tous les autres cas, ils utilisent debian. Dans la plupart des cas, pour des raisons de sécurité, lorsqu'ils sont contraints à utiliser du RedHat (ou du SuSE, c'est un peu moins merdique), ces machines sont _derrière_ des frontaux tournant sous debian et parfaitement à jour (parce que passer des patches sur des machines sur lesquelles tu as un support, c'est le meilleur moyen pour que le support payé à grands moyens se débine !).
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 10-11-2009, ? propos de
Re: Ils ne sont pas difficile...,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff wrote:
Vu que je vois des Debian partout aujourd'hui, y compris chez des gens
qui disent ne pas l'utiliser, tu vas te retrouver bientôt tout seul.
On doit pas bosser dans les memes boites alors.
Ce que je peux te dire, c'est que les Telcos, c'est pas vraiment une
distrib qui vient a l'esprit quand on parle de Linux. En tous, j'ai
jamais vu une plateforme l'utiliser dans ce domaine.
Et bien, on ne doit pas vraiment connaître les mêmes... Les telcos
comme je les connais, ils utilisent RedHat lorsqu'il faut un
support. Dans tous les autres cas, ils utilisent debian. Dans la
plupart des cas, pour des raisons de sécurité, lorsqu'ils sont
contraints à utiliser du RedHat (ou du SuSE, c'est un peu moins
merdique), ces machines sont _derrière_ des frontaux tournant sous
debian et parfaitement à jour (parce que passer des patches sur des
machines sur lesquelles tu as un support, c'est le meilleur moyen
pour que le support payé à grands moyens se débine !).
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 10-11-2009, ? propos de Re: Ils ne sont pas difficile..., Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
Patrice Karatchentzeff wrote:
Vu que je vois des Debian partout aujourd'hui, y compris chez des gens qui disent ne pas l'utiliser, tu vas te retrouver bientôt tout seul.
On doit pas bosser dans les memes boites alors.
Ce que je peux te dire, c'est que les Telcos, c'est pas vraiment une distrib qui vient a l'esprit quand on parle de Linux. En tous, j'ai jamais vu une plateforme l'utiliser dans ce domaine.
Et bien, on ne doit pas vraiment connaître les mêmes... Les telcos comme je les connais, ils utilisent RedHat lorsqu'il faut un support. Dans tous les autres cas, ils utilisent debian. Dans la plupart des cas, pour des raisons de sécurité, lorsqu'ils sont contraints à utiliser du RedHat (ou du SuSE, c'est un peu moins merdique), ces machines sont _derrière_ des frontaux tournant sous debian et parfaitement à jour (parce que passer des patches sur des machines sur lesquelles tu as un support, c'est le meilleur moyen pour que le support payé à grands moyens se débine !).
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 10-11-2009, ? propos de Re: Ils ne sont pas difficile..., Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Là, tu viens de prouver que tu n'as jamais vraiment été confronté à des tas de systèmes différents. Je n'ai _jamais_ vu la même façon
Si, j'ai ete confronte a des tas de systemes differents. Tous ont une logique differente, comme tu le decris.
Il se trouve simplement que je peux comprendre et accepter bien des facons de faire, mais je dois avouer qu'une des pire que j'ai trouve, parce que la plus invasive, c'est bien celle de Debian.
Je te laisse réfléchir pour essayer de comprendre en quoi cette phrase contredit une palanquée et demi de messages que tu as écrit dans les dernières vingt-quatre heures.
En d'autres termes, quel que soit le système, il est bon de lire la doc sauf si tu veux vraiment des emmerdes. Corrolaire, jamais je n'embaucherai un type aussi fermé que toi et assis sur ses certitudes.
Ca tombe bien, j'ai passe l'age de bosser pour des geek (j'ai pas dit jeunes morveux parce que je ne connais pas ton age, mais a te lire, tu parrais pas bien vieux quand meme).
Merci, ça me rajeunit. Au passage, je n'ai jamais bossé pour des geeks.
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 10-11-2009, ? propos de
Re: Ils ne sont pas difficile...,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Là, tu viens de prouver que tu n'as jamais vraiment été confronté à
des tas de systèmes différents. Je n'ai _jamais_ vu la même façon
Si, j'ai ete confronte a des tas de systemes differents. Tous ont une
logique differente, comme tu le decris.
Il se trouve simplement que je peux comprendre et accepter bien des
facons de faire, mais je dois avouer qu'une des pire que j'ai trouve,
parce que la plus invasive, c'est bien celle de Debian.
Je te laisse réfléchir pour essayer de comprendre en quoi cette
phrase contredit une palanquée et demi de messages que tu as écrit
dans les dernières vingt-quatre heures.
En d'autres termes, quel que soit le système, il est bon de lire la doc
sauf si tu veux vraiment des emmerdes. Corrolaire, jamais je
n'embaucherai un type aussi fermé que toi et assis sur ses
certitudes.
Ca tombe bien, j'ai passe l'age de bosser pour des geek (j'ai pas dit
jeunes morveux parce que je ne connais pas ton age, mais a te lire, tu
parrais pas bien vieux quand meme).
Merci, ça me rajeunit. Au passage, je n'ai jamais bossé pour des
geeks.
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 10-11-2009, ? propos de Re: Ils ne sont pas difficile..., Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Là, tu viens de prouver que tu n'as jamais vraiment été confronté à des tas de systèmes différents. Je n'ai _jamais_ vu la même façon
Si, j'ai ete confronte a des tas de systemes differents. Tous ont une logique differente, comme tu le decris.
Il se trouve simplement que je peux comprendre et accepter bien des facons de faire, mais je dois avouer qu'une des pire que j'ai trouve, parce que la plus invasive, c'est bien celle de Debian.
Je te laisse réfléchir pour essayer de comprendre en quoi cette phrase contredit une palanquée et demi de messages que tu as écrit dans les dernières vingt-quatre heures.
En d'autres termes, quel que soit le système, il est bon de lire la doc sauf si tu veux vraiment des emmerdes. Corrolaire, jamais je n'embaucherai un type aussi fermé que toi et assis sur ses certitudes.
Ca tombe bien, j'ai passe l'age de bosser pour des geek (j'ai pas dit jeunes morveux parce que je ne connais pas ton age, mais a te lire, tu parrais pas bien vieux quand meme).
Merci, ça me rajeunit. Au passage, je n'ai jamais bossé pour des geeks.
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.
Nicolas George
totof01 , dans le message , a écrit :
(via update-alternative, sinon ce sera annulé à la première mise à jour)
Il faut bien que le paquet contienne le lien pour que le lien soit là en premier lieu.
Ceci dit, il est tout à fait possible qu'update-alternative soit assez intelligent pour se rendre compte d'une modification manuelle.
En revanche, je suis prêt à parier que si tu changes le lien toi-même à la main, tu vas oublier de changer l'autre lien, celui de la page de man.
totof01 , dans le message
<ea596140-d7a3-4d52-93ca-9e0360228296@h34g2000yqm.googlegroups.com>, a
écrit :
(via update-alternative, sinon ce sera annulé à la première mise à
jour)
Il faut bien que le paquet contienne le lien pour que le lien soit là en
premier lieu.
Ceci dit, il est tout à fait possible qu'update-alternative soit assez
intelligent pour se rendre compte d'une modification manuelle.
En revanche, je suis prêt à parier que si tu changes le lien toi-même à la
main, tu vas oublier de changer l'autre lien, celui de la page de man.
(via update-alternative, sinon ce sera annulé à la première mise à jour)
Il faut bien que le paquet contienne le lien pour que le lien soit là en premier lieu.
Ceci dit, il est tout à fait possible qu'update-alternative soit assez intelligent pour se rendre compte d'une modification manuelle.
En revanche, je suis prêt à parier que si tu changes le lien toi-même à la main, tu vas oublier de changer l'autre lien, celui de la page de man.
Kevin Denis
Le 10-11-2009, totof01 a écrit :
Tu peux bien retirer le module d'une composante modulaire du noyau, et réinstaller une version nouvelle, tout ça sans rebooter. Par exemple ce module correspond à un driver, mais ça peut être un système de fichiers, etc. En fait il n'y a qu'une partie centrale du noyau, la gestion des processus, de la mémoire, etc. qui ne peut pas être patchée sans reboot.
Puis un gars a inventé ksplice.
Merci pour l'explication, ça confirme bien ce que je pensais ..... Il y a toujours un morceau du noyau qu'on ne peut pas patcher sans arrêter le système ...
Cf ksplice.com; on peut patcher sans rebooter. -- Kevin
Le 10-11-2009, totof01 <cdesquesnes@ifrance.com> a écrit :
Tu peux bien retirer le module d'une composante modulaire du noyau,
et réinstaller une version nouvelle, tout ça sans rebooter. Par exemple
ce module correspond à un driver, mais ça peut être un système de
fichiers, etc. En fait il n'y a qu'une partie centrale du noyau, la
gestion des processus, de la mémoire, etc. qui ne peut pas être patchée
sans reboot.
Puis un gars a inventé ksplice.
Merci pour l'explication, ça confirme bien ce que je pensais ..... Il
y a toujours un morceau du noyau qu'on ne peut pas patcher sans
arrêter le système ...
Cf ksplice.com; on peut patcher sans rebooter.
--
Kevin
Tu peux bien retirer le module d'une composante modulaire du noyau, et réinstaller une version nouvelle, tout ça sans rebooter. Par exemple ce module correspond à un driver, mais ça peut être un système de fichiers, etc. En fait il n'y a qu'une partie centrale du noyau, la gestion des processus, de la mémoire, etc. qui ne peut pas être patchée sans reboot.
Puis un gars a inventé ksplice.
Merci pour l'explication, ça confirme bien ce que je pensais ..... Il y a toujours un morceau du noyau qu'on ne peut pas patcher sans arrêter le système ...
Cf ksplice.com; on peut patcher sans rebooter. -- Kevin
JKB
Le 10-11-2009, ? propos de Re: Ils ne sont pas difficile..., Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Tu viens de prouver que tu n'as jamais lu la doc de sendmail. La doc de sendmail est en deux partie : d'une part les macros m4 (et il n'y en a pas deux cents pages comme tu le prétends) et d'autre part les specs du fichier sendmail.cf (et là, il y a largement plus de deux cents pages, mais rares sont ceux qui sont contraints de la lire exhaustivement).
Ok, ben qmail, c'est une dizaine de fichiers avec 1 lignes dedans et ca repond miraculeusement a tous les besoins.
C'est vachement long comme configuration, et ça fait tout y compris le SMTP authentifié sur SSL, la gestion de domaines virtuels, l'antivirus, l'antispam et la gestion plus fine de certains SMTP particulièrement foireux.
Configurer un serveur de mail en 15 minutes (ou la doc du truc et l'assimiler) fait preuve soit de prétention, soit de sa capacité à s'asseoir sur les RFC.
Excuse moi, mais je passe pas mon temps a me masturber sur les RFC. Ca, c'est le boulot du mec qui pond le MX, le mien est d'installer et de faire tourner le truc. Pour se faire, ma connaissance du SMTP est suffisante pour resoudre l'ensemble des problemes que j'ai rencontre jusqu'a ce jour. Et ca fait longtemps que je me pose plus de questions sur comment gerer un MX.
Parfait, arrogant comme d'habitude en reportant les problèmes de son adminsitration sur les autres.
- M'sieur, m'sieur, mes mails ne passent pas ! - C'est pas mon problème, mon qmail fonctionne !
Je ne vois pas comment (mais vas-y, explique-moi, j'ai besoin du tranche de franche rigolade) comment tu peux administrer un serveur de mail sans connaître un minimum les RFCs et les transactions SMTP.
Tu prétends qu'il ne tient pas la charge, ce qui veut dire en d'autres termes qu'il rame. Dans le cas contraire, il faut que tu m'expliques la subtile différence.
Non, il n'a pas tenu la charge dans certaines configurations la ou qmail s'en sortait mieux a serveur de puissance egale.
Fais gaffe, tu es encore en train de raconter une connerie. Plus haut, tu as indiqué que tu n'avais jamais pris le temps de comprendre comment se configure un sendmail. Pas étonnant alors que la configuration n'ait pas été adaptée. Sendmail, c'est un truc capable de répondre à tous les besoins, une configuration par défaut est forcément largement sous optimale. Si tu n'arrives pas à comprendre ça, je ne peux strictement rien pour toi.
Le fait est que le MX etait utilise dans un cadre tres special qui n'avait pas grand chose avec du traitement d'email (interface SMTP sur un hub SMS).
Parlons-en justement, j'ai une machine qui est dédiée à cet usage (à peu près).
Par contre, ce que je dis, c'est que une utilisation standard et hors cadre ISP (centaines de milliers d'adresses), aucun des deux ne peut etre pris en defaut pour des problemes de performances parce que ca fait longtemps qu'on ne se pose plus ce genre de problemes sur ce type de programmes.
Ce n'est pas ce que j'ai écrit, mais comme d'habitude, tu ne retiens que ce qui t'arrange. Je t'ai parlé du problème de dimensionnement de puissance pour un MX. Si tu sais aujourd'hui dimensionner un MX pour une utilisation le mois prochain, il faut que tu me donnes la marque de ta boule de cristal.
Un outil n'est jamais bêtement compliqué. Que tu ne comprennes pas sa complexité est un autre problème.
Ah si. Mais ca va etre dur de te l'expliquer. Disons que dans ton cas, plus c'est complique, mieux c'est. Dans le mien, plus c'est simple, mieux c'est.
C'est simple parce que ton truc ne suit pas la moitié des RFC et que ça pose des problèmes à tout le monde. Si tu as un outil qui suit exactement les RFC, il sera forcément compliqué. De toute façon, ça ne sert à rien, tu n'as jamais ouvert ces RFC.
C'est ça, tu peux être mort de rire. Je ne suis pas sûr que les serveurs de Chine soient mieux administrés que les serveurs des FAI français. Sendmail a un immense avantage, il permet d'avoir une
Tu vas me parler de la Chine maintenant ?
Je te parle de ce que je connais, donc de la majorité des serveurs de mail des FAI européens, c'est déjà pas mal. Et je ne vois aucune raison valable que les MX des FAI du monde entier soient gérés différemment.
avoir avec des vrais SMTP/MX qui respectent les RFC, utiliser un truc comme qmail, c'est au mieux se foutre de la gueule de ses utilisateurs, au pire, de celle des adminsitrateurs des serveurs distants.
Oh, un FUD !!!
Non, une réalité. Les administrateurs de MX devraient pouvoir rejeter tout ce qui ne respecte pas les RFC plutôt que de tourner autour des problèmes.
Continue comme à ton habitude à répondre n'importe quoi. Tu auras le dernier mot et tu seras content, j'ai des tas de choses plus importantes à faire que de répondre à un type comme toi.
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 10-11-2009, ? propos de
Re: Ils ne sont pas difficile...,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Tu viens de prouver que tu n'as jamais lu la doc de sendmail. La doc
de sendmail est en deux partie : d'une part les macros m4 (et il n'y
en a pas deux cents pages comme tu le prétends) et d'autre part les
specs du fichier sendmail.cf (et là, il y a largement plus de deux
cents pages, mais rares sont ceux qui sont contraints de la lire
exhaustivement).
Ok, ben qmail, c'est une dizaine de fichiers avec 1 lignes dedans et ca
repond miraculeusement a tous les besoins.
C'est vachement long comme configuration, et ça fait tout y compris
le SMTP authentifié sur SSL, la gestion de domaines virtuels,
l'antivirus, l'antispam et la gestion plus fine de certains SMTP
particulièrement foireux.
Configurer un serveur de mail en 15 minutes (ou la doc du truc et
l'assimiler) fait preuve soit de prétention, soit de sa capacité à
s'asseoir sur les RFC.
Excuse moi, mais je passe pas mon temps a me masturber sur les RFC. Ca,
c'est le boulot du mec qui pond le MX, le mien est d'installer et de
faire tourner le truc. Pour se faire, ma connaissance du SMTP est
suffisante pour resoudre l'ensemble des problemes que j'ai rencontre
jusqu'a ce jour. Et ca fait longtemps que je me pose plus de questions
sur comment gerer un MX.
Parfait, arrogant comme d'habitude en reportant les problèmes de son
adminsitration sur les autres.
- M'sieur, m'sieur, mes mails ne passent pas !
- C'est pas mon problème, mon qmail fonctionne !
Je ne vois pas comment (mais vas-y, explique-moi, j'ai besoin du
tranche de franche rigolade) comment tu peux administrer un serveur
de mail sans connaître un minimum les RFCs et les transactions SMTP.
Tu prétends qu'il ne tient pas la charge, ce qui veut dire en
d'autres termes qu'il rame. Dans le cas contraire, il faut que tu
m'expliques la subtile différence.
Non, il n'a pas tenu la charge dans certaines configurations la ou qmail
s'en sortait mieux a serveur de puissance egale.
Fais gaffe, tu es encore en train de raconter une connerie. Plus
haut, tu as indiqué que tu n'avais jamais pris le temps de
comprendre comment se configure un sendmail. Pas étonnant alors que
la configuration n'ait pas été adaptée. Sendmail, c'est un truc
capable de répondre à tous les besoins, une configuration par défaut
est forcément largement sous optimale. Si tu n'arrives pas à
comprendre ça, je ne peux strictement rien pour toi.
Le fait est que le MX
etait utilise dans un cadre tres special qui n'avait pas grand chose
avec du traitement d'email (interface SMTP sur un hub SMS).
Parlons-en justement, j'ai une machine qui est dédiée à cet usage (à
peu près).
Par contre, ce que je dis, c'est que une utilisation standard et hors
cadre ISP (centaines de milliers d'adresses), aucun des deux ne peut
etre pris en defaut pour des problemes de performances parce que ca fait
longtemps qu'on ne se pose plus ce genre de problemes sur ce type de
programmes.
Ce n'est pas ce que j'ai écrit, mais comme d'habitude, tu ne retiens
que ce qui t'arrange. Je t'ai parlé du problème de dimensionnement
de puissance pour un MX. Si tu sais aujourd'hui dimensionner un MX
pour une utilisation le mois prochain, il faut que tu me donnes la
marque de ta boule de cristal.
Un outil n'est jamais bêtement compliqué. Que tu ne comprennes pas
sa complexité est un autre problème.
Ah si. Mais ca va etre dur de te l'expliquer. Disons que dans ton cas,
plus c'est complique, mieux c'est. Dans le mien, plus c'est simple,
mieux c'est.
C'est simple parce que ton truc ne suit pas la moitié des RFC et que
ça pose des problèmes à tout le monde. Si tu as un outil qui suit
exactement les RFC, il sera forcément compliqué. De toute façon, ça
ne sert à rien, tu n'as jamais ouvert ces RFC.
C'est ça, tu peux être mort de rire. Je ne suis pas sûr que les
serveurs de Chine soient mieux administrés que les serveurs des FAI
français. Sendmail a un immense avantage, il permet d'avoir une
Tu vas me parler de la Chine maintenant ?
Je te parle de ce que je connais, donc de la majorité des serveurs
de mail des FAI européens, c'est déjà pas mal. Et je ne vois aucune
raison valable que les MX des FAI du monde entier soient gérés
différemment.
avoir avec des vrais SMTP/MX qui respectent les RFC, utiliser un truc
comme qmail, c'est au mieux se foutre de la gueule de ses
utilisateurs, au pire, de celle des adminsitrateurs des serveurs
distants.
Oh, un FUD !!!
Non, une réalité. Les administrateurs de MX devraient pouvoir
rejeter tout ce qui ne respecte pas les RFC plutôt que de tourner
autour des problèmes.
Continue comme à ton habitude à répondre n'importe quoi. Tu auras le
dernier mot et tu seras content, j'ai des tas de choses plus
importantes à faire que de répondre à un type comme toi.
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 10-11-2009, ? propos de Re: Ils ne sont pas difficile..., Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Tu viens de prouver que tu n'as jamais lu la doc de sendmail. La doc de sendmail est en deux partie : d'une part les macros m4 (et il n'y en a pas deux cents pages comme tu le prétends) et d'autre part les specs du fichier sendmail.cf (et là, il y a largement plus de deux cents pages, mais rares sont ceux qui sont contraints de la lire exhaustivement).
Ok, ben qmail, c'est une dizaine de fichiers avec 1 lignes dedans et ca repond miraculeusement a tous les besoins.
C'est vachement long comme configuration, et ça fait tout y compris le SMTP authentifié sur SSL, la gestion de domaines virtuels, l'antivirus, l'antispam et la gestion plus fine de certains SMTP particulièrement foireux.
Configurer un serveur de mail en 15 minutes (ou la doc du truc et l'assimiler) fait preuve soit de prétention, soit de sa capacité à s'asseoir sur les RFC.
Excuse moi, mais je passe pas mon temps a me masturber sur les RFC. Ca, c'est le boulot du mec qui pond le MX, le mien est d'installer et de faire tourner le truc. Pour se faire, ma connaissance du SMTP est suffisante pour resoudre l'ensemble des problemes que j'ai rencontre jusqu'a ce jour. Et ca fait longtemps que je me pose plus de questions sur comment gerer un MX.
Parfait, arrogant comme d'habitude en reportant les problèmes de son adminsitration sur les autres.
- M'sieur, m'sieur, mes mails ne passent pas ! - C'est pas mon problème, mon qmail fonctionne !
Je ne vois pas comment (mais vas-y, explique-moi, j'ai besoin du tranche de franche rigolade) comment tu peux administrer un serveur de mail sans connaître un minimum les RFCs et les transactions SMTP.
Tu prétends qu'il ne tient pas la charge, ce qui veut dire en d'autres termes qu'il rame. Dans le cas contraire, il faut que tu m'expliques la subtile différence.
Non, il n'a pas tenu la charge dans certaines configurations la ou qmail s'en sortait mieux a serveur de puissance egale.
Fais gaffe, tu es encore en train de raconter une connerie. Plus haut, tu as indiqué que tu n'avais jamais pris le temps de comprendre comment se configure un sendmail. Pas étonnant alors que la configuration n'ait pas été adaptée. Sendmail, c'est un truc capable de répondre à tous les besoins, une configuration par défaut est forcément largement sous optimale. Si tu n'arrives pas à comprendre ça, je ne peux strictement rien pour toi.
Le fait est que le MX etait utilise dans un cadre tres special qui n'avait pas grand chose avec du traitement d'email (interface SMTP sur un hub SMS).
Parlons-en justement, j'ai une machine qui est dédiée à cet usage (à peu près).
Par contre, ce que je dis, c'est que une utilisation standard et hors cadre ISP (centaines de milliers d'adresses), aucun des deux ne peut etre pris en defaut pour des problemes de performances parce que ca fait longtemps qu'on ne se pose plus ce genre de problemes sur ce type de programmes.
Ce n'est pas ce que j'ai écrit, mais comme d'habitude, tu ne retiens que ce qui t'arrange. Je t'ai parlé du problème de dimensionnement de puissance pour un MX. Si tu sais aujourd'hui dimensionner un MX pour une utilisation le mois prochain, il faut que tu me donnes la marque de ta boule de cristal.
Un outil n'est jamais bêtement compliqué. Que tu ne comprennes pas sa complexité est un autre problème.
Ah si. Mais ca va etre dur de te l'expliquer. Disons que dans ton cas, plus c'est complique, mieux c'est. Dans le mien, plus c'est simple, mieux c'est.
C'est simple parce que ton truc ne suit pas la moitié des RFC et que ça pose des problèmes à tout le monde. Si tu as un outil qui suit exactement les RFC, il sera forcément compliqué. De toute façon, ça ne sert à rien, tu n'as jamais ouvert ces RFC.
C'est ça, tu peux être mort de rire. Je ne suis pas sûr que les serveurs de Chine soient mieux administrés que les serveurs des FAI français. Sendmail a un immense avantage, il permet d'avoir une
Tu vas me parler de la Chine maintenant ?
Je te parle de ce que je connais, donc de la majorité des serveurs de mail des FAI européens, c'est déjà pas mal. Et je ne vois aucune raison valable que les MX des FAI du monde entier soient gérés différemment.
avoir avec des vrais SMTP/MX qui respectent les RFC, utiliser un truc comme qmail, c'est au mieux se foutre de la gueule de ses utilisateurs, au pire, de celle des adminsitrateurs des serveurs distants.
Oh, un FUD !!!
Non, une réalité. Les administrateurs de MX devraient pouvoir rejeter tout ce qui ne respecte pas les RFC plutôt que de tourner autour des problèmes.
Continue comme à ton habitude à répondre n'importe quoi. Tu auras le dernier mot et tu seras content, j'ai des tas de choses plus importantes à faire que de répondre à un type comme toi.
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:
Et bien, on ne doit pas vraiment connaître les mêmes... Les telcos
JKB, tu me feras toujours rire. En plus comique que toi sur le forum, on doit compter, dans l'ordre :
- Pipolin - Nicolas George - Pandi Panda
Ah desole, tu peux pas monter sur le podium de tete. Mais quand meme, quatrieme, c'est un place d'honneur.
JKB wrote:
Et bien, on ne doit pas vraiment connaître les mêmes... Les telcos
JKB, tu me feras toujours rire. En plus comique que toi sur le forum, on
doit compter, dans l'ordre :
- Pipolin
- Nicolas George
- Pandi Panda
Ah desole, tu peux pas monter sur le podium de tete. Mais quand meme,
quatrieme, c'est un place d'honneur.
