Re: Del criterio per cambiare il numero di release

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