On Sun, 9 Nov 2025, Matteo Bini wrote:
Non ho capito quest'ultimo esempio, però a naso mi sembrerebbe che l'errore stia nel non considerare entrambe le possibilità (macchina in multiprocesso e non), piuttosto che scegliere quale componente del numero di versione aggiornare. In teoria mi sembrerebbe possibile risolvere questo problema, senza rompere la retrocompatibilità, senza aggiungere nuove funzionalità, modificando solo il numero di patch. Tuttavia non mi è chiaro se gli utenti si aspettassero che il programma girasse a tutta randa, prima della correzione.
Si tratta di un programma diagnostico di rete, con un numero "normale" di host sul segmento e con la frequenza di scansione "normale" (un test ogni 4 secondi) tutto va bene, ma se l'utente impostava frequenza a un test ogni 100 ms ecco che il carico mandava la CPU a 80% ... con la versione precedente tutto funzionava perfettamante, con la versione "migliorata" ecco che cominciava a perdere dati per frequenza di scansione troppo bassa. Pare che gli sviluppatori avessere ricevuti reclami da chi diceva che il programma faceva scaldare troppo la CPU che e si sono inventati la strana soluzione, che però penalizzava chi usava il programma per un certo scopo e aveva semplicemente messo un dissipatore più grosso, senza lamentarsi.
E il problema capita più spesso del normale, perché chi è contento di una feature non va a lamentarsi con chi ha fatto il programma, ma chi è scontento della stessa va a lamentarsi ... e ovviamente a chi da retta lo sviluppatore ? col risultato che quando esce la nuova versione arrivano le lamentele del primo gruppo, che pretendono in reintegro delle features cambiate.
-- Leonardo Boselli Firenze, Toscana, Europa http://i.trail.it tel:+393287329225
