Pousser les gens à changer de logiciel perce qu'une brique n'a pas eu besoin d'évoluer depuis longtemps risque de les pousser vers des solutions moins testées, voir permettre à des gens de se spécialiser dans le renouvellement des briques pour y rajouter des trucs indésirables;
C'est aussi une ode à la consommation, car on fait rarement des softs pour une vieille machine.
y a t'il plus de faille dans les vieille briques que dans les nouvelles ?
Pour les entreprises, le soucis ne changera pas: celle qui savent ce que c'est payent une équipe ou la maintenance, les autres ne voient pas l'intérêt de bloquer du temps / des ressources pour risquer de remplacer un truc qui marche par un truc qui plante.
Enfin, en tant que développeur (open source depuis peu :P) je suis incapable de te donner une date pour les biques que je code.
1) si je suis le seul dessus et que je me plante dans un accident de speeder la date de fin de support que j'aurais donné est forcément erronée
2) si y a une faille dans une brique, elle est déjà périmée ton décideur il va dire pas besoin de mettre à jour, il est valable jusqu'à tant.
Bref à part donner un faux sentiment de sécurité, je ne pense pas que ça soit une riche idée.
Par contre lister l'ensemble des briques constituant un logiciel permet à ceux en assurant leur sécurité de s'assurer de leur risque.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Mouais
Posté par fearan . En réponse au journal Assurer la sécurité informatique sur le modèle de la sécurité alimentaire. Évalué à 9.
Pousser les gens à changer de logiciel perce qu'une brique n'a pas eu besoin d'évoluer depuis longtemps risque de les pousser vers des solutions moins testées, voir permettre à des gens de se spécialiser dans le renouvellement des briques pour y rajouter des trucs indésirables;
C'est aussi une ode à la consommation, car on fait rarement des softs pour une vieille machine.
y a t'il plus de faille dans les vieille briques que dans les nouvelles ?
Pour les entreprises, le soucis ne changera pas: celle qui savent ce que c'est payent une équipe ou la maintenance, les autres ne voient pas l'intérêt de bloquer du temps / des ressources pour risquer de remplacer un truc qui marche par un truc qui plante.
Enfin, en tant que développeur (open source depuis peu :P) je suis incapable de te donner une date pour les biques que je code.
1) si je suis le seul dessus et que je me plante dans un accident de speeder la date de fin de support que j'aurais donné est forcément erronée
2) si y a une faille dans une brique, elle est déjà périmée ton décideur il va dire pas besoin de mettre à jour, il est valable jusqu'à tant.
Bref à part donner un faux sentiment de sécurité, je ne pense pas que ça soit une riche idée.
Par contre lister l'ensemble des briques constituant un logiciel permet à ceux en assurant leur sécurité de s'assurer de leur risque.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent