skip to main | skip to sidebar
22 commenti

Dite addio a Internet Explorer 8, 9 e 10: da martedì prossimo non saranno più supportati da Microsoft

Martedì 12 gennaio le versioni 8, 9 e 10 di Internet Explorer raggiungeranno la “fine vita” (end of life), ossia non saranno più supportate da Microsoft per quanto riguarda aggiornamenti di sicurezza o correttivi. Chi li usa resterà quindi vulnerabile alle falle note e a quelle che verranno presumibilmente scoperte in futuro.

L’avviso di Microsoft (in italiano) consiglia agli utenti di passare a Internet Explorer 11, “che continuerà a ricevere aggiornamenti della sicurezza, correzioni rapide per la compatibilità e supporto tecnico in Windows 7, Windows 8.1 e Windows 10”.

Chi non segue questo consiglio ma scarica gli aggiornamenti periodici di Microsoft si troverà con un promemoria sullo schermo a partire sempre da questo martedì. L’unica versione di Internet Explorer che resterà supportata è la 11, ma in realtà Microsoft sta spingendo affinché gli utenti abbandonino anche questa in favore del suo nuovo browser, denominato Edge.

Per chi sviluppa software e gestisce sistemi informatici la cessazione del supporto alle vecchie versioni di Internet Explorer, celebri per le loro idiosincrasie e incompatibilità, è probabilmente una buona notizia, perché semplifica il numero di versioni di browser da gestire e offre una giustificazione per andare dal capo e finalmente costringerlo ad aggiornare il software.
Invia un commento
I commenti non appaiono subito, devono essere tutti approvati da un moderatore. Lo so, è scomodo, ma è necessario per tenere lontani scocciatori, spammer, troll e stupidi: siate civili e verrete pubblicati qualunque sia la vostra opinione; gli incivili di qualsiasi orientamento non verranno pubblicati, se non per mostrare il loro squallore.
Inviando un commento date il vostro consenso alla sua pubblicazione, qui o altrove.
Maggiori informazioni riguardanti regole e utilizzo dei commenti sono reperibili nella sezione apposita.
NOTA BENE. L'area sottostante per l'invio dei commenti non è contenuta in questa pagina ma è un iframe, cioè una finestra su una pagina di Blogger esterna a questo blog. Ciò significa che dovete assicurarvi che non venga bloccata da estensioni del vostro browser (tipo quelle che eliminano le pubblicità) e/o da altri programmi di protezione antimalware (tipo Kaspersky). Inoltre è necessario che sia permesso accettare i cookie da terze parti (informativa sulla privacy a riguardo).
Commenti
Commenti (22)
Ho smesso da qualche anno di supportare anche MSIE per le applicazioni non erga omnes che scrivo con interfaccia HTML/CSS/JS

Si fa molto prima a dire al cliente in fase preliminare "questo programma funziona solo con Chrome o Firefox"
Non hai idea di quanti servizi nelle grandi aziende funzionano *solo* con IE sotto la versione 11 e di come sia difficile cambiare la situazione.
Ci sono servizi che noi _dobbiamo_ usare che funzionano _solo_ con IE8 e IE10 (qui in retrocompatibilità). Quindi siamo costretti a tenere computer con Windows XP e browser vecchi.
Simpatico, vero?
Che cosa bella ... tre quarti dei nostri utenti usano ie 9 e 10 e NON saranno in grado di modificare il registro o disinstallare la patch dell'avviso... speriamo che migrino (in realtà spero che Emigrino proprio...)
Il sistema centralizzato dell'aria condizionata del fabbricato dove lavoro (che ha aperto da soli 3 anni!) funziona sono in internet explorer 6(!!!) a causa di un ocx, probabilmente. Quindi per cambiare la temperatura di una delle stanze, siamo costretti ad avere una VM con XP... Per poter usare IE6... Nel 2016...
Ma perché? Qualcuno ancora usa IE? @_@
Non sarà peggio? Purtroppo ci sono ancora troppe copie di quei browser
Uso Firefox e Opera, che peccato... non posso festeggiare la morte dei vecchi IE, non avendoli :)
Il fatto che nel 2016 ci sia ancora gente costretta ad usare versioni obsolete di un browser, addirittura IE6 di 14 anni fa, che non è più supportato già da un po' comunque (sai la sicurezza ad usarlo), la dice lunga sui danni che fa il "vendor lock-in" e la poca lungimiranza di chi poi ha scritto software andandoci dietro, fregandosene degli standard condivisi.
Uno standard condiviso rende liberi di creare software alternativo che possa farne uso e lascia libertà di scelta anche agli utenti, invece di essere costretti ad usare un software o una sua versione. E la competizione incentiva a migliorarsi.
Se non altro. l'epoca del famoso "abbraccia, estendi ed estingui" di MS sembra essere finita, almeno dal lato browser, ma qualche strascico si vede ancora.
Chi crea siti e sviluppa web app avrà la vita almeno un po' più facile, man mano che l'utenza passa a browser più rispettosi degli standard.
Veramente a IE ho detto addio dalla prima versione che è uscita... ;)
Non esistono, se non erro, versioni di IE11 compatibili con Windows Vista (si... lo so), che pure è "vivo" e supportato.
Cosa si fa quindi? Si aggiorna il sistema operativa per indisponibilità del browser?
Ah no, c'è un'altra soluzione :-)
In realtà, siccome Vista è ancora supportato fino all'11 aprile 2017, anche IE_9, l'ultimo disponibile per quella piattaforma, sarà tenuto vivo limitatamente a Vista e Server_2008, ed IE_10 lo sarà per Server_2012, come spiegato nella pagina
https://support.microsoft.com/it-it/lifecycle#gp/Microsoft-Internet-Explorer.
Per i soliti fanboy appliani mal informati, anche con il solo IE11 qualora abbiate un servizio compatibile solo con versioni precedenti di IE potete attivare l'emulazione tramite tag metà oppure gpo. Certo, bisogna essere informati, non disinformati ...

Unknown,

anche con il solo IE11 qualora abbiate un servizio compatibile solo con versioni precedenti di IE potete attivare l'emulazione tramite tag metà oppure gpo. Certo, bisogna essere informati, non disinformati ...

Davvero. Purtroppo c'è gente che manda commenti sarcastici invece di spiegarsi chiaramente e linkare le fonti che potrebbero toglierci da questo fetido pantano d'ignoranza.
"poca lungimiranza degli sviluppatori"? No, qui vorreste che prevedessero il futuro. Certo, si sa che i software evolvono ma non puoi pretendere compatibilità verso versioni future. Il problema è piuttosto il fatto che esista uno standard finto che si chiama html.
@Lupo
standard finto
e' finto solo perche' Microsoft ha deciso di strasbattersene degli standard, e c'e' gente che gli e' andata dietro. Quindi ti ritrovi siti ottimizzati per ie e il resto del mondo. Finche' ie aveva la maggioranza poteva anche stare, ma ora che non e' piu' dominante nel mercato forse si potrebbe bellamente ignorare tutti i fuori standard e passare a browser che rispettino pienamente l'html...
@Lupo
"poca lungimiranza degli sviluppatori"? No, qui vorreste che prevedessero il futuro.
dipende. Ti faccio un esempio: mettere dei testi bindati nel codice e' semplice e veloce ma ti costringe a dover ricompilare l'applicativo se questi testi cambiano. Per contro pescarle da db (o da un file di configurazione) richiede piu' lavoro e progettazione ma ti rende piu' flessibile in caso di cambiamenti.
Il cambiamento e' nella natura del software, e tu che sviluppi lo devi mettere in conto. Non farlo e quindi legarsi strettamente a doppio giro ad un determinato componente significa pessima progettazione (oppure necessiti di un'alta ottimizzazione per cui allora e' accettabile) perche' non tieni conto che se quel componente affonda il tuo software lo segue a meno di non riscriverlo da capo...
Beh no perché sarebbe come lamentarsi che chi sviluppava per DOS non è stato lungimirante perché non pensava a Windows.

Piuttosto mi chiederei perché una pagina scritta per Internet Explorer 8 non si vede bene sull'11 e perché non sono retrocompatibili. Il contrario non ha senso.

Per non parlare degli standard per finta dell'html...
Ah poi nel tuo esempio non c'è niente di male ad usare hard coding se i dati non cambiano, per esempio i comandi dei menù, è inutile fare cose modulari se non serve. Poi se ci tieni a separare la presentazione dalla logica lo puoi fare ma non sei obbligato.
@Lupo
dipende dai dati... Devi tenere sempre presente che il cambiamento esiste. Il DOS e' un sistema operativo e non deve tenere di conto altri che di se' stesso... Ma chi sviluppa software per il DOS deve tenere conto che i cambiamenti ci saranno e quindi devi cercare di rendere il tuo sw meno dipendente possibili da particolarita' del SO sul quale lo stai eseguendo (portabilita') - a meno che non serva un software ad elevate prestazioni o altre particolarita' (vedi gestione eventi realtime). Per esempio se il tuo software necessita di una certa versione di una certo componente puoi stare sicuro come l'oro che avrai problemi.
I comandi del menu' hardwired? E se devi tradurre il tuo programma in un'altra lingua? Ti tocca
a) cercare tutte quelle c@%%0 di label che Dio sa dove l'hai inguattate
b) tradurle e sperare che la traduzione piaccia al cliente
c) creare una versione apposta per quella lingua (e mantenerla!)
quando basterebbe un file di conf (o una tabella) dalla quale leggere a seconda della lingua che l'utente sceglie
questa per dirtene una.
Facciamo un altro esempio: sviluppi il tuo sw strettamente dipendente da oracolo, non usi un framework che ti aiuti a non essere dipendente dal db e metti tutta la parte CRUD bella hardwired nel codice, tanto non cambiera' mai no? Alla versione xxy oracolo cambia un qualchecosa (oppure il tuo cliente decide che quei nonsoquantimila euro di licenza sono troppi), tu o riscrivi tutta la parte di accesso al db da 0 oppure non puoi cambiare database. Riscrivere tutta la logica di accesso al db vuol dire cercare tutti i punti dove il tuo applicativo legge e scrive sul database e riscrivere le query per renderle adatte al nuovo database (in un caso) oppure cercare di capire quali query non vanno piu' bene e riscriverle (nell'altro). Vedi bene che e' un lavoro immane ed inutilmente dispendioso, che avresti potuto evitare con un minimo di pianificazione in piu' all'inizio
"E se devi tradurre il tuo programma in un'altra lingua?" Devo? Allora devo mettere le stringhe separate.

Ma non vedo perché devo PER FORZA tradurre il programma in più lingue. Tra parentesi pure se le metto hard coded basta avere l'accortezza di metterle tutte nello stesso posto e ottengo lo stesso risultato senza dover ricorrere a file esterni..

Ripeto, non puoi dire che un programmatore "non è lungimirante" solo perché scrive un programma che funziona nella versione corrente del browser e non in quelle SUCCESSIVE. Non può sapere come saranno le versioni successive e se saranno retrocompatibili. Sta a chi realizza il browser fare in modo che le versioni nuove "degradino" in modo da poter usare i programmi vecchi, il contrario è improponibile.

Guarda che non vuol dire niente DOVE metti il codice se tanto lo dovrai cambiare. Ancora, devo usare un framework che mi rende il codice indipendente dal DB. Primo, potrebbe non importarmi che lo sia, secondo potrei pure scrivermi un framework mio personalizzato, volendo.

Dici, se ho un programma che accede ad Oracle e quelli di Oracle levano una funzione che uso per farlo ANCHE se c'è un framework ci saranno per forza da fare modifiche nel codice del framework, le demando al suo autore (e quindi DIPENDO da quelle), ma siccome non prevedo il futuro NON POSSO escludere di aver bisogno di modifiche ANCHE nel mio codice..

Non devo essere IO che uso gli strumenti (un framework, o oracle, nel tuo esempio) che devo tirare a indovinare cercando di intuire come diventeranno un domani, ma dev'essere chi mi fa gli strumenti da pensare a cosa c'era PRIMA.

@Lupo
mai sentito parlare di Dialetti? Per esempio in hibernate tu usi HQL/Criteria che poi hibernate traduce nel dialetto del db che stai usando, basta cambiare il dialetto e ti trovi le tue CRUD "tradotte" automaticamente per un altro db (o versione che sia) quindi non devi cambiare un bel niente.
Ci sono delle cose di cui _devi_ tenere di conto, come il fatto che le risorse di sistema non sono infinite, che il codice puo' fallire (e quindi gestire le eccezioni) e che sul codice ci dovrai rimettere mano tu o qualcun'altro... Sarebbe come dire non scrivo commenti perche' tanto il codice va bene cosi' e non va piu' toccato...
A meno che non ci sia una ragione specifica, e' buona norma non dipendere troppo dall'architettura sottostante. Poi ci sono casi obbligati, ma meno sono meglio e'.

Ma non vedo perché devo PER FORZA tradurre il programma in più lingue.

Per esempio perche' il tuo cliente vuole vendere l'applicativo ad un cliente che per forza non parla italiano? Oppure perche' il tuo cliente vuole cambiare una label? Ti sembra sensato che per cambiare una dicitura devi ricompilare interamente l'applicativo?
Tra parentesi pure se le metto hard coded basta avere l'accortezza di metterle tutte nello stesso posto e ottengo lo stesso risultato senza dover ricorrere a file esterni..
Ti sembra sensato dovere ricompilare l'applicativo per una label? Si chiama flessibilita' ed e' quello che distingue un sw fatto bene da uno fatto alla c...arlona.
A meno che non ci siano requisiti particolari non ha senso quello che dici tu, perche' fare un file di configurazione costa poco in termini di programmazione e ti permette di effettuare eventuali cambiamenti con pochissimo sforzo...
secondo potrei pure scrivermi un framework mio personalizzato, volendo.
Certo. Pero' 1. stai reinventando la ruota 2. un eventuale programmatore che viene dopo di te dovra' prima imparare a capire il tuo framework (e non ci sara' documentazione online che possa aiutarlo) e dopo potra' iniziare a lavorare. Se usi uno strumento standard e' tutto molto piu' semplice, sia che conosca lo strumento che non lo conosca. Inoltre se ci sono problemi (quasi) sicuramente "la' fuori" ci sara' qualcuno che avra' avuto lo stesso problema e quindi sara' piu' facile trovare la relativa soluzione. Se il framework e' tuo e ce l'hai solo te sono "gatti situoy".

Non devo essere IO che uso gli strumenti (un framework, o oracle, nel tuo esempio) che devo tirare a indovinare cercando di intuire come diventeranno un domani, ma dev'essere chi mi fa gli strumenti da pensare a cosa c'era PRIMA.

Si e no. Nel senso tu non puoi prevedere a priori che un certo metodo sara' deprecato, ma quando un metodo lo diventa hai tempo fino alla versione successiva per sistemare le cose, e non aspettare per poi lamentarti che quel metodo e' "sparito"