La demo di Edge senza riavvio non è l’impostazione disponibile oggi
Microsoft sperimenta il passaggio di versione a browser aperto. L’opzione attuale per l’inattività riavvia ancora il programma e può incidere sul lavoro non salvato.
Microsoft ha mostrato un prototipo di Edge capace di portare browser, processi di supporto e schede aperte a una nuova versione mentre il lavoro prosegue. Il post tecnico del 15 ottobre ne precisa lo stato: è una ricerca iniziale, non codice in produzione e non parte di Chromium oggi.
L’impostazione già attivabile fa qualcosa di diverso. «Restart to update on idle», in precedenza chiamata Instant Updates, aspetta l’inattività e poi riavvia Edge. Confondere i due meccanismi rischia di creare proprio il problema che la ricerca vuole risolvere: presumere che un modulo incompleto resti intatto mentre avviene un vero riavvio.
Ripristinare una scheda non ripristina ogni stato
Le istruzioni di supporto Microsoft descrivono 15 minuti di inattività seguiti da un conto alla rovescia di cinque minuti, in assenza di wake lock attivi che impediscano il processo. Il browser applica quindi l’aggiornamento e ripristina le schede.
La scheda è soltanto il contenitore visibile dello stato di un’applicazione web. Il suo indirizzo può essere riaperto anche quando testo non salvato o un’operazione incompleta non sono ricostruibili. Alcune applicazioni salvano continuamente, altre no. Microsoft avverte esplicitamente del rischio di perdere contenuti in documenti e moduli non salvati.
Non rende sbagliato l’aggiornamento automatico. Rende importante capire la condizione di «inattività». Si può lasciare il computer con un’attività importante ancora incompleta. Salvare prima di allontanarsi resta utile anche quando il riavvio viene spostato fuori dal tempo di lavoro attivo.
La difficoltà è trasferire un sistema in esecuzione
Un browser è un insieme di processi cooperanti, non una finestra statica. Aggiornarlo preservando il lavoro significa coordinare il passaggio attraverso quel sistema. L’obiettivo del prototipo è eliminare il momento in cui una correzione di sicurezza resta bloccata dalla comprensibile riluttanza a interrompere un’attività.
La conseguenza riguarda il patch gap: l’intervallo tra la disponibilità di una correzione e l’effettiva esecuzione della versione protetta. Scaricare un aggiornamento non chiude necessariamente quell’intervallo. Se il vecchio codice resta attivo fino al riavvio, l’installazione non beneficia ancora pienamente della nuova versione.
Il nostro articolo sulle installazioni Firefox gestite affronta la stessa esigenza operativa in un altro ecosistema. Un’organizzazione deve sapere che cosa stia funzionando sui dispositivi, non soltanto quale pacchetto sia stato scaricato.
Agli amministratori serve anche visibilità
La documentazione della dashboard Edge descrive il monitoraggio delle versioni e gli avvisi di sicurezza per dispositivi Windows gestiti. Gli avvisi possono essere filtrati per gravità, mentre il pannello aiuta a individuare installazioni interessate e azioni disponibili.
La visibilità resta distinta dall’applicazione dell’aggiornamento. Un avviso ben presentato aiuta a stabilire le priorità, ma occorre ancora verificare che il browser in esecuzione sia passato alla versione richiesta. Anche il numero dei dispositivi ha senso soltanto entro l’ambito e l’attualità dei dati di monitoraggio.
La ricerca indica un risultato desiderabile: una correzione di sicurezza che non debba competere con l’esigenza di conservare il lavoro. Finché quel meccanismo non arriverà in produzione, il miglioramento pratico è più limitato ma concreto: rendere prevedibile il riavvio, salvare l’attività e verificare che la nuova versione stia davvero funzionando.
