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.
C'est gentil de vouloir me prendre pour un con, mais je suis conscient de cet état de fait.
Je te prends pas pour un con, je te reponds. Tu sembles mettre en doute le fait qu'on peut vouloir eviter une mise a jour de securite. Oui, il y a des raisons ou l'on veut.
Puisque tes machines sont peu exposées, tu peux mettre en place une procédure de validation. Si la mise à jour casse ton système, tu l'installes pas. Personne ne te met un pistolet sur la tempe pour que tu fasses un apt-get upgrade !
Surtout pas. Mais laisse tomber, c'est un peu special je l'admets. Mon point c'est juste qu'on peut avoir des serveurs ou des upgrades, meme de securite, ne sont pas indispensables, voire pas conseilles ou pas possibles.
Mais là je parle de procédures de validation à quelqu'un qui compile directement sur les serveurs...
J'utilise des procedure de validations avec des mechanismes de rollback qui ne sont meme pas envisageables avec un systeme de package conventionel (je peux revenir a n'importe quel version precedente en 3 secondes). C'est gentil de vouloir me donner des lecons, mais t'as jamais marche dans mes chaussures.
En fait tes arguments contre Debian ne disent pas que Debian est mauvais, mais inadapté à ton besoin. Je ne fais pas de SS7, effectivement, et mon usage en téléphonie se limite à Asterisk, avec du SIP. Sur une Debian ça va très bien. Dans l'intérêt du débat, il faudrait que je demande à FDN sous quoi tourne(ra) leur SS7.
En fait, je n'ai jamais vu de Debian dans ce domaine.
Principalement, j'ai rencontre les OS suivants : Solaris (Ultra), SuSE (avec en general 1 a 2 versions de retard) et RedHat.
Ne me dis pas que tu as passer ton MX en prod sans avoir regardé comment Debian l'avait configuré !
Non, j'ai rien passe en prod. J'ai repris une machine qui avait ete configure ainsi (par defaut) et qui rendait l'ame.
Changer une config sur une machine avant de mettre en prod, c'est une chose. Prendre un MX a pleine charge en route et essayer de le faire tenir, c'en est une tout autre (c'est dans ses moments qu'on deteste profondement les choix stupides de certains packagers de Debian).
-- http://unices.over-blog.com/ Un Francais en Chine
Riquer Vincent a perdu son temps a nous dire:
C'est gentil de vouloir me prendre pour un con, mais je suis conscient
de cet état de fait.
Je te prends pas pour un con, je te reponds. Tu sembles mettre en doute
le fait qu'on peut vouloir eviter une mise a jour de securite. Oui, il y
a des raisons ou l'on veut.
Puisque tes machines sont peu exposées, tu peux mettre en place une
procédure de validation. Si la mise à jour casse ton système, tu
l'installes pas. Personne ne te met un pistolet sur la tempe pour que tu
fasses un apt-get upgrade !
Surtout pas. Mais laisse tomber, c'est un peu special je l'admets. Mon
point c'est juste qu'on peut avoir des serveurs ou des upgrades, meme de
securite, ne sont pas indispensables, voire pas conseilles ou pas
possibles.
Mais là je parle de procédures de validation à quelqu'un qui compile
directement sur les serveurs...
J'utilise des procedure de validations avec des mechanismes de rollback
qui ne sont meme pas envisageables avec un systeme de package
conventionel (je peux revenir a n'importe quel version precedente en 3
secondes). C'est gentil de vouloir me donner des lecons, mais t'as
jamais marche dans mes chaussures.
En fait tes arguments contre Debian ne disent pas que Debian est
mauvais, mais inadapté à ton besoin. Je ne fais pas de SS7,
effectivement, et mon usage en téléphonie se limite à Asterisk, avec du
SIP. Sur une Debian ça va très bien.
Dans l'intérêt du débat, il faudrait que je demande à FDN sous quoi
tourne(ra) leur SS7.
En fait, je n'ai jamais vu de Debian dans ce domaine.
Principalement, j'ai rencontre les OS suivants : Solaris (Ultra), SuSE
(avec en general 1 a 2 versions de retard) et RedHat.
Ne me dis pas que tu as passer ton MX en prod sans avoir regardé comment
Debian l'avait configuré !
Non, j'ai rien passe en prod. J'ai repris une machine qui avait ete
configure ainsi (par defaut) et qui rendait l'ame.
Changer une config sur une machine avant de mettre en prod, c'est une
chose. Prendre un MX a pleine charge en route et essayer de le faire
tenir, c'en est une tout autre (c'est dans ses moments qu'on deteste
profondement les choix stupides de certains packagers de Debian).
--
http://unices.over-blog.com/ Un Francais en Chine
C'est gentil de vouloir me prendre pour un con, mais je suis conscient de cet état de fait.
Je te prends pas pour un con, je te reponds. Tu sembles mettre en doute le fait qu'on peut vouloir eviter une mise a jour de securite. Oui, il y a des raisons ou l'on veut.
Puisque tes machines sont peu exposées, tu peux mettre en place une procédure de validation. Si la mise à jour casse ton système, tu l'installes pas. Personne ne te met un pistolet sur la tempe pour que tu fasses un apt-get upgrade !
Surtout pas. Mais laisse tomber, c'est un peu special je l'admets. Mon point c'est juste qu'on peut avoir des serveurs ou des upgrades, meme de securite, ne sont pas indispensables, voire pas conseilles ou pas possibles.
Mais là je parle de procédures de validation à quelqu'un qui compile directement sur les serveurs...
J'utilise des procedure de validations avec des mechanismes de rollback qui ne sont meme pas envisageables avec un systeme de package conventionel (je peux revenir a n'importe quel version precedente en 3 secondes). C'est gentil de vouloir me donner des lecons, mais t'as jamais marche dans mes chaussures.
En fait tes arguments contre Debian ne disent pas que Debian est mauvais, mais inadapté à ton besoin. Je ne fais pas de SS7, effectivement, et mon usage en téléphonie se limite à Asterisk, avec du SIP. Sur une Debian ça va très bien. Dans l'intérêt du débat, il faudrait que je demande à FDN sous quoi tourne(ra) leur SS7.
En fait, je n'ai jamais vu de Debian dans ce domaine.
Principalement, j'ai rencontre les OS suivants : Solaris (Ultra), SuSE (avec en general 1 a 2 versions de retard) et RedHat.
Ne me dis pas que tu as passer ton MX en prod sans avoir regardé comment Debian l'avait configuré !
Non, j'ai rien passe en prod. J'ai repris une machine qui avait ete configure ainsi (par defaut) et qui rendait l'ame.
Changer une config sur une machine avant de mettre en prod, c'est une chose. Prendre un MX a pleine charge en route et essayer de le faire tenir, c'en est une tout autre (c'est dans ses moments qu'on deteste profondement les choix stupides de certains packagers de Debian).
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Riquer Vincent a perdu son temps a nous dire:
Et rien ne t'oblige, quand tu joues dans ton coin, à suivre les debian-policy.
C'est clair que lorsque je gere une Debian, je le fais exactement de la meme facon que je gere une Slackware (par exemple).
Je ne vois pas de bonne raison de ne pas suivre le modèle de configuration apache2 de Debian. Pour le boulot, j'ai même écrit des scripts qui font à peu près la même chose mais pour proftpd. Si tu peux expliciter dans quel(s) cas ce modèle est inadapté, ça m'intéresse.
J'en sais rien. Je n'utilise pas le package Apache2 de la Debian, j'ai mes propres procedures pour gerer Apache et je n'ai pas de serveur Debian de toutes facons. Qui plus est, je ne gere pas de serveurs web, mes serveurs HTTP sont des serveurs applicatifs transactionnels avec une configuration tres particuliere (j'ai meme modifie les sources d'Apache pour coller au besoin).
Si c'est de moi que tu parles, je dois être le dino le plus jeune
Non, je ne parlais de personne en particulier. Je n'ai pas la moindre idee de ce avec quoi tu travailles, je ne sais pas ton age, je ne sais rien qui me permet de parler de toi en particulier.
J'ai aussi un petit ARM qui fonctionne avec une clé USB comme disque dur. Aucun besoin de -dev et de -doc là dessus, de toute façon, compiler sur cette machine est beaucoup trop lent, et tuerais la flash.
C'est bien. Une Slack complete doit pas prendre 2GB. Ton IBM ou ton ARM, ca tient sans probleme et c'est complet.
-- http://unices.over-blog.com/ Un Francais en Chine
Riquer Vincent a perdu son temps a nous dire:
Et rien ne t'oblige, quand tu joues dans ton coin, à suivre les
debian-policy.
C'est clair que lorsque je gere une Debian, je le fais exactement de la
meme facon que je gere une Slackware (par exemple).
Je ne vois pas de bonne raison de ne pas suivre le modèle de
configuration apache2 de Debian. Pour le boulot, j'ai même écrit des
scripts qui font à peu près la même chose mais pour proftpd. Si tu peux
expliciter dans quel(s) cas ce modèle est inadapté, ça m'intéresse.
J'en sais rien. Je n'utilise pas le package Apache2 de la Debian, j'ai
mes propres procedures pour gerer Apache et je n'ai pas de serveur
Debian de toutes facons. Qui plus est, je ne gere pas de serveurs web,
mes serveurs HTTP sont des serveurs applicatifs transactionnels avec une
configuration tres particuliere (j'ai meme modifie les sources d'Apache
pour coller au besoin).
Si c'est de moi que tu parles, je dois être le dino le plus jeune
Non, je ne parlais de personne en particulier. Je n'ai pas la moindre
idee de ce avec quoi tu travailles, je ne sais pas ton age, je ne sais
rien qui me permet de parler de toi en particulier.
J'ai aussi un petit ARM qui fonctionne avec une clé USB comme disque
dur. Aucun besoin de -dev et de -doc là dessus, de toute façon, compiler
sur cette machine est beaucoup trop lent, et tuerais la flash.
C'est bien. Une Slack complete doit pas prendre 2GB. Ton IBM ou ton ARM,
ca tient sans probleme et c'est complet.
--
http://unices.over-blog.com/ Un Francais en Chine
Et rien ne t'oblige, quand tu joues dans ton coin, à suivre les debian-policy.
C'est clair que lorsque je gere une Debian, je le fais exactement de la meme facon que je gere une Slackware (par exemple).
Je ne vois pas de bonne raison de ne pas suivre le modèle de configuration apache2 de Debian. Pour le boulot, j'ai même écrit des scripts qui font à peu près la même chose mais pour proftpd. Si tu peux expliciter dans quel(s) cas ce modèle est inadapté, ça m'intéresse.
J'en sais rien. Je n'utilise pas le package Apache2 de la Debian, j'ai mes propres procedures pour gerer Apache et je n'ai pas de serveur Debian de toutes facons. Qui plus est, je ne gere pas de serveurs web, mes serveurs HTTP sont des serveurs applicatifs transactionnels avec une configuration tres particuliere (j'ai meme modifie les sources d'Apache pour coller au besoin).
Si c'est de moi que tu parles, je dois être le dino le plus jeune
Non, je ne parlais de personne en particulier. Je n'ai pas la moindre idee de ce avec quoi tu travailles, je ne sais pas ton age, je ne sais rien qui me permet de parler de toi en particulier.
J'ai aussi un petit ARM qui fonctionne avec une clé USB comme disque dur. Aucun besoin de -dev et de -doc là dessus, de toute façon, compiler sur cette machine est beaucoup trop lent, et tuerais la flash.
C'est bien. Une Slack complete doit pas prendre 2GB. Ton IBM ou ton ARM, ca tient sans probleme et c'est complet.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Patrice Karatchentzeff a perdu son temps a nous dire:
Tu n'as pas compris ce que j'ai écrit : il est écrit *explicitement* dans la charte de Debian que Debian se destine à la reprise pour personnalisation.
J'ai parfaitement compris. Il est egalement explicitement ecrit dans toutes les licences de LL que le code peut etre repris, change ou re-utilise dans le cadre d'autres projets.
Tu peux jouer sur la definition du verbe "pouvoir" contre celui de "se destiner", mais le fait est que les sources sont fournis dans les deux cas dans l'objectif explicite que chacun puisse les reprendre, les personnaliser ou en faire ce que bon lui semble (dans les limites de la licence de re-distribution).
Ce n'est ni le cas des autres distributions, ni le cas du LL en général.
Si tu penses cela, c'est que tu n'as rien compris a la philosophie du LL. Tout simplement.
-- http://unices.over-blog.com/ Un Francais en Chine
Patrice Karatchentzeff a perdu son temps a nous dire:
Tu n'as pas compris ce que j'ai écrit : il est écrit *explicitement*
dans la charte de Debian que Debian se destine à la reprise pour
personnalisation.
J'ai parfaitement compris. Il est egalement explicitement ecrit dans
toutes les licences de LL que le code peut etre repris, change ou
re-utilise dans le cadre d'autres projets.
Tu peux jouer sur la definition du verbe "pouvoir" contre celui de "se
destiner", mais le fait est que les sources sont fournis dans les deux
cas dans l'objectif explicite que chacun puisse les reprendre, les
personnaliser ou en faire ce que bon lui semble (dans les limites de la
licence de re-distribution).
Ce n'est ni le cas des autres distributions, ni le cas du LL en
général.
Si tu penses cela, c'est que tu n'as rien compris a la philosophie du
LL. Tout simplement.
--
http://unices.over-blog.com/ Un Francais en Chine
Patrice Karatchentzeff a perdu son temps a nous dire:
Tu n'as pas compris ce que j'ai écrit : il est écrit *explicitement* dans la charte de Debian que Debian se destine à la reprise pour personnalisation.
J'ai parfaitement compris. Il est egalement explicitement ecrit dans toutes les licences de LL que le code peut etre repris, change ou re-utilise dans le cadre d'autres projets.
Tu peux jouer sur la definition du verbe "pouvoir" contre celui de "se destiner", mais le fait est que les sources sont fournis dans les deux cas dans l'objectif explicite que chacun puisse les reprendre, les personnaliser ou en faire ce que bon lui semble (dans les limites de la licence de re-distribution).
Ce n'est ni le cas des autres distributions, ni le cas du LL en général.
Si tu penses cela, c'est que tu n'as rien compris a la philosophie du LL. Tout simplement.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Patrice Karatchentzeff a perdu son temps a nous dire:
C'est dire si même les dév d'Apache sont d'accord avec toi.
Je ne critique pas la qualite. Je critique le fait que c'est "invasif".
Il serait plus intelligent de faire une Debian version mini-disk pour le 0.1% de dino qui utilisent des disques durs de 200Mb et de faire une gestion normale de packages pour les 99.9% qui ont des disques de plus
s/normale/à la Tougard/
Non, "normale" comme tous les Unix depuis que les Unix existent.
Ce n'est pas parce que tu travailles comme un goret que les autres sont obligés de faire de même.
Je suis sur que l'ensemble des gens qui travaillent sur des distributions plus classiques sont content de savoir que le grand Patrice K. pense qu'ils travaillent comme des gorets.
-- http://unices.over-blog.com/ Un Francais en Chine
Patrice Karatchentzeff a perdu son temps a nous dire:
C'est dire si même les dév d'Apache sont d'accord avec toi.
Je ne critique pas la qualite. Je critique le fait que c'est "invasif".
Il serait plus intelligent de faire une Debian version mini-disk
pour le 0.1% de dino qui utilisent des disques durs de 200Mb et de
faire une gestion normale de packages pour les 99.9% qui ont des
disques de plus
s/normale/à la Tougard/
Non, "normale" comme tous les Unix depuis que les Unix existent.
Ce n'est pas parce que tu travailles comme un goret que les autres
sont obligés de faire de même.
Je suis sur que l'ensemble des gens qui travaillent sur des
distributions plus classiques sont content de savoir que le grand
Patrice K. pense qu'ils travaillent comme des gorets.
--
http://unices.over-blog.com/ Un Francais en Chine
Patrice Karatchentzeff a perdu son temps a nous dire:
C'est dire si même les dév d'Apache sont d'accord avec toi.
Je ne critique pas la qualite. Je critique le fait que c'est "invasif".
Il serait plus intelligent de faire une Debian version mini-disk pour le 0.1% de dino qui utilisent des disques durs de 200Mb et de faire une gestion normale de packages pour les 99.9% qui ont des disques de plus
s/normale/à la Tougard/
Non, "normale" comme tous les Unix depuis que les Unix existent.
Ce n'est pas parce que tu travailles comme un goret que les autres sont obligés de faire de même.
Je suis sur que l'ensemble des gens qui travaillent sur des distributions plus classiques sont content de savoir que le grand Patrice K. pense qu'ils travaillent comme des gorets.
-- http://unices.over-blog.com/ Un Francais en Chine
Riquer Vincent
Stephane TOUGARD a écrit :
Riquer Vincent a perdu son temps a nous dire:
J'ai aussi un petit ARM qui fonctionne avec une clé USB comme disque dur. Aucun besoin de -dev et de -doc là dessus, de toute façon, compiler sur cette machine est beaucoup trop lent, et tuerais la flash.
C'est bien. Une Slack complete doit pas prendre 2GB. Ton IBM ou ton ARM, ca tient sans probleme et c'est complet.
Couper le passage où je parle de datas de jeux te permet de dire ça. En remettant ce passage, ta réponse est juste à côté de la plaque.
Et je n'ai pas parlé de limitations dûes à l'espace disque sur l'ARM, juste de l'inutilité d'avoir ces données.
Stephane TOUGARD a écrit :
Riquer Vincent a perdu son temps a nous dire:
J'ai aussi un petit ARM qui fonctionne avec une clé USB comme disque
dur. Aucun besoin de -dev et de -doc là dessus, de toute façon, compiler
sur cette machine est beaucoup trop lent, et tuerais la flash.
C'est bien. Une Slack complete doit pas prendre 2GB. Ton IBM ou ton ARM,
ca tient sans probleme et c'est complet.
Couper le passage où je parle de datas de jeux te permet de dire ça. En
remettant ce passage, ta réponse est juste à côté de la plaque.
Et je n'ai pas parlé de limitations dûes à l'espace disque sur l'ARM,
juste de l'inutilité d'avoir ces données.
J'ai aussi un petit ARM qui fonctionne avec une clé USB comme disque dur. Aucun besoin de -dev et de -doc là dessus, de toute façon, compiler sur cette machine est beaucoup trop lent, et tuerais la flash.
C'est bien. Une Slack complete doit pas prendre 2GB. Ton IBM ou ton ARM, ca tient sans probleme et c'est complet.
Couper le passage où je parle de datas de jeux te permet de dire ça. En remettant ce passage, ta réponse est juste à côté de la plaque.
Et je n'ai pas parlé de limitations dûes à l'espace disque sur l'ARM, juste de l'inutilité d'avoir ces données.
Riquer Vincent
Stephane TOUGARD a écrit :
Riquer Vincent a perdu son temps a nous dire:
Puisque tes machines sont peu exposées, tu peux mettre en place une procédure de validation. Si la mise à jour casse ton système, tu l'installes pas. Personne ne te met un pistolet sur la tempe pour que tu fasses un apt-get upgrade !
Surtout pas. Mais laisse tomber, c'est un peu special je l'admets. Mon point c'est juste qu'on peut avoir des serveurs ou des upgrades, meme de securite, ne sont pas indispensables, voire pas conseilles ou pas possibles.
Oui, j'ai compris ce point. Par contre je ne comprend pas que tu reproches à Debian de proposer ces mises à jour.
Mais là je parle de procédures de validation à quelqu'un qui compile directement sur les serveurs...
J'utilise des procedure de validations avec des mechanismes de rollback qui ne sont meme pas envisageables avec un systeme de package conventionel (je peux revenir a n'importe quel version precedente en 3 secondes). C'est gentil de vouloir me donner des lecons, mais t'as jamais marche dans mes chaussures.
Tu as besoin des headers sur tes serveurs, j'en avais conclu que tu compilais directeemnt dessus. Sinon je ne vois pas pourquoi tu aurais besoin des headers.
Quant à pouvoir revenir en arrière, c'est tout à fait possible avec quasiment tout système de paquet. Y compris celui de Debian.
En fait tes arguments contre Debian ne disent pas que Debian est mauvais, mais inadapté à ton besoin. Je ne fais pas de SS7, effectivement, et mon usage en téléphonie se limite à Asterisk, avec du SIP. Sur une Debian ça va très bien. Dans l'intérêt du débat, il faudrait que je demande à FDN sous quoi tourne(ra) leur SS7.
En fait, je n'ai jamais vu de Debian dans ce domaine.
>
Principalement, j'ai rencontre les OS suivants : Solaris (Ultra), SuSE (avec en general 1 a 2 versions de retard) et RedHat.
Mais tu reproches à Debian stable d'être obsolète...
Ne me dis pas que tu as passer ton MX en prod sans avoir regardé comment Debian l'avait configuré !
Non, j'ai rien passe en prod. J'ai repris une machine qui avait ete configure ainsi (par defaut) et qui rendait l'ame.
Oui c'est un tout autre problème. La distribution n'est pas en cause.
Changer une config sur une machine avant de mettre en prod, c'est une chose. Prendre un MX a pleine charge en route et essayer de le faire tenir, c'en est une tout autre (c'est dans ses moments qu'on deteste profondement les choix stupides de certains packagers de Debian).
Non, tu regrettes les mauvais choix des précédents administrateurs de ladite machine. Un spamd n'a rien à faire sur un MX frontal. -- Vincent Riquer
BOFH excuse #99:
SIMM crosstalk.
Stephane TOUGARD a écrit :
Riquer Vincent a perdu son temps a nous dire:
Puisque tes machines sont peu exposées, tu peux mettre en place une
procédure de validation. Si la mise à jour casse ton système, tu
l'installes pas. Personne ne te met un pistolet sur la tempe pour que tu
fasses un apt-get upgrade !
Surtout pas. Mais laisse tomber, c'est un peu special je l'admets. Mon
point c'est juste qu'on peut avoir des serveurs ou des upgrades, meme de
securite, ne sont pas indispensables, voire pas conseilles ou pas
possibles.
Oui, j'ai compris ce point. Par contre je ne comprend pas que tu
reproches à Debian de proposer ces mises à jour.
Mais là je parle de procédures de validation à quelqu'un qui compile
directement sur les serveurs...
J'utilise des procedure de validations avec des mechanismes de rollback
qui ne sont meme pas envisageables avec un systeme de package
conventionel (je peux revenir a n'importe quel version precedente en 3
secondes). C'est gentil de vouloir me donner des lecons, mais t'as
jamais marche dans mes chaussures.
Tu as besoin des headers sur tes serveurs, j'en avais conclu que tu
compilais directeemnt dessus. Sinon je ne vois pas pourquoi tu aurais
besoin des headers.
Quant à pouvoir revenir en arrière, c'est tout à fait possible avec
quasiment tout système de paquet. Y compris celui de Debian.
En fait tes arguments contre Debian ne disent pas que Debian est
mauvais, mais inadapté à ton besoin. Je ne fais pas de SS7,
effectivement, et mon usage en téléphonie se limite à Asterisk, avec du
SIP. Sur une Debian ça va très bien.
Dans l'intérêt du débat, il faudrait que je demande à FDN sous quoi
tourne(ra) leur SS7.
En fait, je n'ai jamais vu de Debian dans ce domaine.
>
Principalement, j'ai rencontre les OS suivants : Solaris (Ultra), SuSE
(avec en general 1 a 2 versions de retard) et RedHat.
Mais tu reproches à Debian stable d'être obsolète...
Ne me dis pas que tu as passer ton MX en prod sans avoir regardé comment
Debian l'avait configuré !
Non, j'ai rien passe en prod. J'ai repris une machine qui avait ete
configure ainsi (par defaut) et qui rendait l'ame.
Oui c'est un tout autre problème. La distribution n'est pas en cause.
Changer une config sur une machine avant de mettre en prod, c'est une
chose. Prendre un MX a pleine charge en route et essayer de le faire
tenir, c'en est une tout autre (c'est dans ses moments qu'on deteste
profondement les choix stupides de certains packagers de Debian).
Non, tu regrettes les mauvais choix des précédents administrateurs de
ladite machine. Un spamd n'a rien à faire sur un MX frontal.
--
Vincent Riquer
Puisque tes machines sont peu exposées, tu peux mettre en place une procédure de validation. Si la mise à jour casse ton système, tu l'installes pas. Personne ne te met un pistolet sur la tempe pour que tu fasses un apt-get upgrade !
Surtout pas. Mais laisse tomber, c'est un peu special je l'admets. Mon point c'est juste qu'on peut avoir des serveurs ou des upgrades, meme de securite, ne sont pas indispensables, voire pas conseilles ou pas possibles.
Oui, j'ai compris ce point. Par contre je ne comprend pas que tu reproches à Debian de proposer ces mises à jour.
Mais là je parle de procédures de validation à quelqu'un qui compile directement sur les serveurs...
J'utilise des procedure de validations avec des mechanismes de rollback qui ne sont meme pas envisageables avec un systeme de package conventionel (je peux revenir a n'importe quel version precedente en 3 secondes). C'est gentil de vouloir me donner des lecons, mais t'as jamais marche dans mes chaussures.
Tu as besoin des headers sur tes serveurs, j'en avais conclu que tu compilais directeemnt dessus. Sinon je ne vois pas pourquoi tu aurais besoin des headers.
Quant à pouvoir revenir en arrière, c'est tout à fait possible avec quasiment tout système de paquet. Y compris celui de Debian.
En fait tes arguments contre Debian ne disent pas que Debian est mauvais, mais inadapté à ton besoin. Je ne fais pas de SS7, effectivement, et mon usage en téléphonie se limite à Asterisk, avec du SIP. Sur une Debian ça va très bien. Dans l'intérêt du débat, il faudrait que je demande à FDN sous quoi tourne(ra) leur SS7.
En fait, je n'ai jamais vu de Debian dans ce domaine.
>
Principalement, j'ai rencontre les OS suivants : Solaris (Ultra), SuSE (avec en general 1 a 2 versions de retard) et RedHat.
Mais tu reproches à Debian stable d'être obsolète...
Ne me dis pas que tu as passer ton MX en prod sans avoir regardé comment Debian l'avait configuré !
Non, j'ai rien passe en prod. J'ai repris une machine qui avait ete configure ainsi (par defaut) et qui rendait l'ame.
Oui c'est un tout autre problème. La distribution n'est pas en cause.
Changer une config sur une machine avant de mettre en prod, c'est une chose. Prendre un MX a pleine charge en route et essayer de le faire tenir, c'en est une tout autre (c'est dans ses moments qu'on deteste profondement les choix stupides de certains packagers de Debian).
Non, tu regrettes les mauvais choix des précédents administrateurs de ladite machine. Un spamd n'a rien à faire sur un MX frontal. -- Vincent Riquer
Voyons voir, peut etre parce que le D70 n'est plus au catalogue de Nikon.
Quel rapport ?
Patrick Lamaizière
JKB :
Je ne sais pas comment tu les installes, mais chaque fois que j'installe une debian, ça me pose la question (la dernière installation étant sur une Blade 2000 avec debian/testing et date de moins d'un mois). Je fais toutes mes installations en mode texte, c'est peut-être ça.
J'ai installé à partir d'un cd "testing xfce"
JKB :
Je ne sais pas comment tu les installes, mais chaque fois que
j'installe une debian, ça me pose la question (la dernière
installation étant sur une Blade 2000 avec debian/testing et date de
moins d'un mois). Je fais toutes mes installations en mode texte,
c'est peut-être ça.
Je ne sais pas comment tu les installes, mais chaque fois que j'installe une debian, ça me pose la question (la dernière installation étant sur une Blade 2000 avec debian/testing et date de moins d'un mois). Je fais toutes mes installations en mode texte, c'est peut-être ça.
