Assez rapidement, le décideur se rend compte qu'un logiciel stable est moins coûteux qu'un logiciel tout récent : on privilégiera Ubuntu LTS à la dernière version, RHEL à Fedora, un noyau LTS à celui le plus récent, etc.
... commence par lister pour une installe minimale toutes les briques utilisées,
ensuite installe le serveur graphique
et recommence ;)
La liste est bien trop longue pour avoir une pertinence sur la prise de décision; et si tu te limites aux briques principales, tu risque de zapper celle qui sera à l'origine de la faille (récemment sudoedit, pas certains que sudo fasse partie des briques que tu aurais listé spontanément)
C'est le rôle de ton admin sys de savoir ce qui tourne sur quel machines, ajouter une date théorique à coté de tel ou tel composant n'a pas de sens :
la faille n’apparaît pas magiquement à la date indiquée, ni n'attend celle-ci pour exister.
Tu parles des distrib LTS, justement c'est déjà le cas, on indique qu'on va gérer les mises à jours jusqu'à tel date, le faire au niveau des briques n'a pas de sens. Pareil pour les langages comme le java qui sorts des versions comme on sort des iphones, mais qui indique lesquelles bénéficieront d'un support.
Quand tu payes un logiciel à une (削除) SSII (削除ここまで) ESN, tu as une période de garanti et/ou de support qui fait parti du contrat.
Assez rapidement, le décideur se rend compte qu'un logiciel stable est moins coûteux qu'un logiciel tout récent :
Non très rapidement il va se rendre compte que ne rien changer est bien plus rentable, si en plus tu le noie sous l'information il prend le risque d'être passé à coté du truc que tout le monde sait comme essentiel et qui va lui retomber sur le coin de la gueule; à partir de là 2 solutions :
a) faire comme tout le monde
b) ne rien faire
Bref on a déjà au niveau macro ce que tu réclame au niveau micro; regarde about:license dans firefox rien que le nombre, dit toi que coté brique y'en a encore plus. J'ajouterai que tu veux remplacer un service informatique par un service commercial, et ça ce n'est JAMAIS une bonne idée.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mouais
Posté par fearan . En réponse au journal Assurer la sécurité informatique sur le modèle de la sécurité alimentaire. Évalué à 4.
... commence par lister pour une installe minimale toutes les briques utilisées,
ensuite installe le serveur graphique
et recommence ;)
La liste est bien trop longue pour avoir une pertinence sur la prise de décision; et si tu te limites aux briques principales, tu risque de zapper celle qui sera à l'origine de la faille (récemment sudoedit, pas certains que sudo fasse partie des briques que tu aurais listé spontanément)
C'est le rôle de ton admin sys de savoir ce qui tourne sur quel machines, ajouter une date théorique à coté de tel ou tel composant n'a pas de sens :
la faille n’apparaît pas magiquement à la date indiquée, ni n'attend celle-ci pour exister.
Tu parles des distrib LTS, justement c'est déjà le cas, on indique qu'on va gérer les mises à jours jusqu'à tel date, le faire au niveau des briques n'a pas de sens. Pareil pour les langages comme le java qui sorts des versions comme on sort des iphones, mais qui indique lesquelles bénéficieront d'un support.
Quand tu payes un logiciel à une
(削除) SSII (削除ここまで)ESN, tu as une période de garanti et/ou de support qui fait parti du contrat.Non très rapidement il va se rendre compte que ne rien changer est bien plus rentable, si en plus tu le noie sous l'information il prend le risque d'être passé à coté du truc que tout le monde sait comme essentiel et qui va lui retomber sur le coin de la gueule; à partir de là 2 solutions :
a) faire comme tout le monde
b) ne rien faire
Bref on a déjà au niveau macro ce que tu réclame au niveau micro; regarde about:license dans firefox rien que le nombre, dit toi que coté brique y'en a encore plus. J'ajouterai que tu veux remplacer un service informatique par un service commercial, et ça ce n'est JAMAIS une bonne idée.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent