marzo 2005 - Posts
Segnalo questo post di Alberto Dallagiacoma che illustra sinteticamente come configurare Reporting Services con un utente che non è amministratore su IIS5. Credo sia utile a chi deve percorrere la stessa strada sfruttando il lavoro di chi ha già smanettato con RegMon e FileMon...
Da poche ore è disponibile Windows 2003 SP1, al momento solo in inglese e tedesco.
Sono 330Mb di download, praticamente un nuovo CD. Inutile aggiungere che è un aggiornamento importante che va installato al più presto, ma sempre facendo le dovute verifiche di compatibilità se avete dei server critici in produzione. Segnalo i riferimenti forniti da Bink.nu relativamente a questo aggiornamento, in particolare la pagina sul sito Microsoft dedicata alle informazioni su questo Service Pack.
Non è un aggiornamento da prendere alla leggera, io lo sto scaricando e lo proverò su qualche server di sviluppo prima di andare su quelli in produzione.
UPDATE: segnalo questo post di Alessandro Perilli che riassume le principali novità introdotte da questo Service Pack.
Credo che la gestione della posta in arrivo sia una delle pratiche più controverse e personali della nostra quotidianità. Tuttavia esistono alcune scuole di pensiero e probabilmente ciascuno di noi ricade in un qualche stereotipo.
Lo spunto di questo post mi è venuto leggendo questo post di Eric Gunnerson: lui si è convertito al credo "zero mail nella Inbox". Io sono passato a questa convinzione un paio di anni fa e l'uso di NEO mi ha facilitato nella scelta.
Ora... prima di aprire una discussione sull'argomento... chi ha voglia di dirmi quante mail ha mediamente nella inbox a fine giornata e in quale linguaggio programma abitualmente (si può anche dire "nessuno") ? Voglio capire se c'è una qualche relazione... i commenti sono aperti.
ILMerge è un tool che consente di unire più assembly .NET in un unico assembly. Si tratta di un progetto sviluppato da Michael Barnett, ricercatore in Microsoft Research, che è "nato" da oltre un anno ma solo da pochi giorni è disponibile "ufficialmente" via MSDN.
Può essere uno strumento interessante per incapsulare tutti gli assembly di un progetto in un solo eseguibile. Il dubbio è che fornisca altri vantaggi in termini di impronta in memoria o di tempi di caricamento e/o compilazione JIT. In teoria è così (va più veloce un solo assembly), ma quanto sia significativo l'impatto su uno scenario reale è tutto da misurare. Qualcuno ha esperienze in proposito?
Ho appena terminato di leggere questo post di Eric Sink che parla di Visual Studio Team System e del suo modello di pricing, spiegando come il prodotto sia in realtà destinato a una fascia di mercato che è diversa da coloro i quali si sono lamentati, in questi giorni, del costo eccessivo del prodotto stesso (e del fatto che gli abbonati a MSDN non avranno automaticamente diritto a usare tale prodotto).
In estrema sintesi, Visual Studio Team System è indirizzato a grandi gruppi di sviluppo. Non 5 programmatori. Non 10. Centinaia o migliaia di programmatori.
Insomma... spero perdonerete la battuta che vuole essere, appunto, una battuta e non un'affermazione... in Italia praticamente Visual Studio Team System non serve a nessuno! :-)
Per il post numero 700 uno si potrebbe immaginare chissà quali disquisizioni architetturali... e invece eccomi qua a parlare di monitor LCD! Ma in fondo non è un argomento così off-topic e prima o poi tutti ci faranno i conti con queste considerazioni...
Anni fa ho speso un'enormità per acquistare due monitor LCD 1280x1024 con funzione Pivot. Ancora oggi funzionano egregiamente, ma è chiaro (e in parte me lo aspettavo) che anche i monitor subiscono la legge dell'obsolescenza tecnologica, peraltro in modo di gran lunga inferiore rispetto a molti altri dispositivi elettronici.
Un mese fa stavo per acquistare un nuovo LCD da 20" con risoluzione da 1680x1050. Una delle tante offerte commerciali stava per intrappolarmi ma... per fortuna ho resistito all'acquisto d'impulso, anche perché una rapida ricerca mi ha consentito di scoprire che da lì a poco sarebbe arrivato sul mercato un nuovo mostro: 24" con risoluzione da 1.920x1.200.
Fin qui niente di strano, monitor così ce ne sono in giro da un pezzo, ma quello che è stato devastante (per me) è stato il prezzo. Devo fare nomi e cognomi: il Dell 2405FPW ha un prezzo di listino di 1.049€+IVA. Acquistandone uno viene offerto a 891,65€. Ma acquistandone due lo sconto diventa ancora maggiore e ogni monitor costa 786,75€, senza neppure le spese di spedizione. Detto monitor supporta anche la rotazione a 90 gradi (pivot) con un eccellente 1.200x1.920. Oltre ad avere una serie di gadget per me poco significativi (USB, card reader multi-standard, ecc.) ma che sicuramente poi tornano comodi.
Cosa avrei dovuto fare? Continuare a dire a me stesso che tanto tra 6 mesi ci sarebbe stato un nuovo modello a un prezzo più basso? Non ce l'ho fatta, in meno di 24 ore ho trovato un compagno d'acquisto e abbiamo fatto un ordine per due monitor, così abbiamo la coscienza a posto sul piano del risparmio economico (si fa per dire, ovviamente).
Adesso devo risolvere il dilemma: usare due o tre monitor? L'idea è di provare a usarne 3, dotandosi di opportuna scheda grafica. Farò un po' di prove, ma inevitabilmente entro un paio di mesi cambierò completamente il PC desktop.
Anche perché (e veniamo al tema del post) Longhorn si avvicina e per sfruttare Longhorn bisognerà avere: tanto schermo, tanta grafica, tanta CPU, tanta RAM. Con il monitor dovrei essere a posto per qualche anno (almeno 3?). Ora devo cominciare a pensare a una scheda video adeguata...
Con l'ultima CTP di SQL Server 2005 dovremmo avere quasi tutte le funzionalità complete... anche il materiale più o meno ufficiale aumenta e quindi ho pensato di segnalare qualche link dedicato.
Consiglio a chi è interessato di dare un'occhiata al mio blog in inglese (dove anche se non ci sono tanti post cerco di mantenere un elenco aggiornato e più completo alle risorse interessanti).
David Chappel sarà in Italia il 22 marzo 2005 a parlare di SOA (Service Oriented Architecture). L'evento si chiama Architect Day e si terrà a Segrate (MI) presso la sede di Microsoft. La partecipazione è gratuita.
Si tratta di un evento di tipo principalmente architetturale, diverso dall'evento SOA tenuto da Paolo il 14 gennaio scorso a Brescia, che invece aveva come tema dominante l'architettura e la realizzazione in particolare di Smart Client. Dobbiamo fare attenzione a usare troppo spesso le buzzword del momento (ora è il momento di SOA) perché si rischia di fare un po' di confusione. L'evento di David Chappel sarà probabilmente utile a tutti quelli che vogliono avere una panoramiza dell'architettura e delle tecnologie utilizzabili (da Indigo a BizTalk passando ovviamente per .NET).
Spesso mi è capitato di parlare con persone che hanno avuto problemi creando applicazioni che creano un grande numero di oggetti/finestre nell'interfaccia utente. In Windows ogni elemento (un bottone, una cobo, una lista...) è una finestra, cioè ha un suo window handle, che maschera una serie di strutture gestite dal modulo USER dell'interfaccia utente. Anche quando si usa Windows Forms o VB6, dietro le quinte vengono allocati questi oggetti.
Purtroppo ogni window handle in Windows costa parecchio e il numero di window handle istanziabili è limitato per processo (ma le prestazioni solitamente decadono ben prima di raggiungere il limite). Visual Basic 6 ha un modello di controlli window-less (che fa a meno di window handle) che ricalca ciò che era stato fatto in una delle primissime versioni di Delphi, con la differenza che in Delphi si potevano (e si possono) scrivere nuovi componenti window-less, mentre in VB6 no.
Quando ho visto per la prima volta Windows Forms (parliamo del 2000) mi sono immediatamente chiesto per quale assurdo motivo non avessero pensato di definire un'architettura di componenti che contemplasse i controlli window-less: Windows Forms è molto simile a VCL (libreria di Delphi) e a WFC (Windows Fundation Class di J#); non conosco WFC ma VCL prevedeva (e prevede) architetturalmente questa possibilità, ed è un peccato che tale scelta non sia stata replicata in Windows Forms.
Chi ha affrontato lo sviluppo di gestionali complessi con Windows Forms ha affrontato questo problema, di non facile soluzione. In questo post Raymond Chen spiega storicamente i motivi dell'architettura di Windows che portano ad avere i window-handle - vi consiglio di leggere anche i commenti, perché si scopre che anche Amiga aveva qualcosa di meglio a livello architetturale. Anche qui trovate un'interessante discussione sull'argomento, che spiega come Internet Explorer non usi controlli di Windows ma abbia controlli window-less proprio per evitare di toccare questi limiti.
Per fortuna Avalon elimina alla radice il problema. Se qualcuno conoscesse delle librerie per .NET alternative o complementari a Windows Forms in grado di definire dei controlli window-less... me lo faccia sapere. Purtroppo la convivenza dei due mondi è tutt'altro che semplice (anche in Delphi ci sono diverse limitazioni per questo).
Ieri sera leggevo un articolo sull'outsourcing IT nelle aziende italiane, dove si sostiene (relativamente alle PMI) che in Italia c'è una domanda praticamente nulla ma anche una scarsissima offerta.
Mi sono chiesto: ma la domanda non c'è e non ci sarebbe, neppure se stimolata, oppure è proprio la mancanza di offerta l'impedimento maggiore?
L'assunto dell'outsourcing è che costa meno o, per lo meno, a parità di costi si ottiene un servizio migliore.
Io ho sempre pensato che ci sia un conflitto di interessi tra chi fornisce l'outsourcing e chi lo richiede, al punto che è difficile trovarne una convenienza reale se il servizio che si dà all'esterno è una parte strategica del business. Nell'articolo si cita l'home banking come esempio di uso dell'IT che da servizio collaterale diventa una colonna portante del business, sostenendo che l'outsourcing dia un vantaggio perché consente di avere le migliori competenze con un costo inferiore (rispetto a formarsele in casa). Dall'altra (per come la vedo io) l'outsourcing costituisce un'arma a doppio taglio perché, se ci si basa su un fornitore esterno per una parte così cruciale del business, diventa poi molto difficile separarsene (e allora addio controllo dei costi...).
Un conto è andare da un fornitore esterno per fare il servizio di manutenzione di 1.000 PC client (con amministrazione di Active Directory, deployment automatici, ecc.). Un conto è dare lo sviluppo e l'intera infrastruttura di erogazione del servizio in appalto a una società esterna non controllata: molte banche infatti si fanno la loro società di outsourcing, così per lo meno riducono i rischi di perderne il controllo.
Comunque, come al solito, è bene avere dei dubbi. Leggendo l'articolo il dubbio è che, nel panorama italiano, sarebbe veramente più facile migliorare l'infrastruttura IT di un'azienda rivolgendosi a una struttura di outsourcing piuttosto che cercare di fare tutto in casa. Una struttura dedicata potrebbe mantenere competenze elevate su tutta una serie di campi (tra cui uno dei più importanti, cioè la sicurezza) e fornire così servizi di qualità molto alta (24x7, aggiornamento continuo, sviluppo secondo standard qualitativi elevati potendo contare su team composti da specializzazioni molto ampie e non basato sulle competenze specifiche dei 2-3 sviluppatori bravi - quando ci sono - di una piccola software house).
Al di là del fatto che una struttura simile oggi forse non esiste (ce ne sono sul lato hardware-sistemistico, ma sono rivolte prevalentemente a grandi aziende per servizi di data-center soprattutto) mi chiedo se esista poi una cultura di fondo che possa recepire una proposta del genere...
Ho scambiato allora una mail con chi ha tentato (e tenta) di offrire un servizio simile alle aziende. Ecco la risposta (che posso ripubblicare con l'autorizzazione dell'autore omettendo alcuni riferimenti).
Mi proponi una riflessione di cui discutevo giusto la settimana scorsa.
Io sono convinto che l’outsourcing sia il “solo” sistema che le PMI italiane hanno a disposizione per la crescita tecnologica della propria azienda. Nessuna PMI oggi ha la possibilità di strutturare internamente le competenze necessarie allo sviluppo di progetti che vanno dal web alla firma digitale per l’invio dell’iva mensile. La nostra idea è proprio questa, mettere a disposizione delle aziende una conoscenza molto “skillata” e distribuita per lo sviluppo dei progetti e il costante aggiornamento degli stessi. Ci scontriamo però con l’aspetto da te evidenziato della “percezione” di pericolo per la dipendenza che ne deriva (dipendenza che spesso viene interpretata come interesse economico sullo sviluppo in determinate direzioni e investimenti).
Ti faccio alcuni esempi da noi vissuti per darti un feed-back reale dello stato dell’arte delle aziende:
1. [omissis] Media azienda con prodotto tecnologicamente molto avanzato in cui alla nostra proposta di outsourcing della parte EDP hanno preferito una collaborazione occasionale con il solo scopo di “controllo” indiretto dell’attività e delle scelte della struttura interna
2. [omissis] Media azienda in cui la parte EDP è affidata a un dipendente che “smanetta” access e l’odbc di Oracle. Solo grazie alla mia amicizia con il responsabile di produzione riusciamo a sviluppare qualche progetto ma senza una continuità in quanto gli investimenti in informatica vengono visti solo come un costo dall’amministratore delegato e siamo arrivati al punto di fatturare a giornata di assistenza tecnica i progetti per “nascondere” gli investimenti. Pensa che dovevano [omissis] e ad una nostra proposta di outsourcing dell’attività hanno preferito comprare [omissis] da 10.000 €uro e far fare il lavoro a tempo perso ai dipendenti interni (e il termine perso è un vero eufemismo).
3. [omissis] Media azienda in cui dopo un buon inizio, sempre grazie ad una mia conoscenza, ci siamo arenati su un dirigente neo assunto che alla nostra proposta di outsourcing (una riunione mensile di progettazione e sviluppo dell’infrastruttura e assistenza sull’implementazione dei progetti) ha preferito assumere 6 persone con varie competenze per tenersi in casa la gestione e probabilmente evitare che qualcuno esterno mettesse in evidenza i suoi limiti di conoscenza informatica.
Ora il vero problema di queste aziende è che nessuno dei titolari “percepisce” l’informatica come uno strumento di business e quindi le decisioni vengono delegate a personaggi che limitano le soluzioni al solo indispensabile. Inoltre forse le poche volte che hanno delegato all’esterno si sono imbattuti in brutte esperienze….
Hai anche recentemente tastato con mano come anche imprenditori informatici ritengano una tariffa di un corso troppo alta in quanto la percezione del servizio reso sia “equivalente” al risparmio di tempo per la lettura di testi che permettano ai suoi valenti tecnici (che assolutamente non affidano attività in outsourcing perché non è opportuno) di migliorare la loro competenza!
Oppure di ISV che vendono software a PMI lombarde solo perché evitando di investire sul prodotto riescono a tenere basso il prezzo e a essere considerati meno costosi dei concorrenti.
Io penso che per ora non ne usciamo, dobbiamo aspettare che nelle aziende arrivino i figli dei titolari che hanno cominciato dall’ X-Box e si sono travati a scuola un PC per usare Paint o per trovare su internet la canzone per la fidanzata, e allora la percezione che l’informatica sia il motore di sviluppo sarà nel DNA dei decision maker delle aziende.
La mia risposta è stata: ma la generazione cresciuta con PacMan non doveva essere sufficiente? Se aspettiamo quella della XBox... siamo in pensione (ok, noi non ci andremo, ma insomma forse non saremo più tanto attivi lo stesso...).
L'argomento è interessante, i commenti sono aperti...
Pochi giorni fa ho tenuto per Microsoft un
webcast su Business Scorecard Accelerator. In particolare il tema delle Balanced Scorecard meriterebbe almeno un articolo che ho in testa ma non trovo il tempo di scrivere. Per chi volesse comunque approfondire la cosa posso citare il libro
The Balanced Scorecard: Translating Strategy into Action di (R.Kaplan e S.Norton) e questo articolo
Process Warehouse: The Missing Link in Business Performance Management di Nari Kannan e segnalato da
Duncan Lamb in cui si suggerisce come impostare il Data Warehouse per l'analisi dei processi aziendali (da qui il nome Process Warehouse).
Per chi conosce un po' l'argomento (o ha seguito il webcast), resto dell'idea che forse in Italia è ancora difficile parlare di Balanced Scorecard (specialmente se pensiamo alla PMI - Piccola e Media Impresa), ma è ragionevole pensare a soluzioni più generiche di Business Scorecard o comunque a sistemi di KPI (Key Performance Indicator) per singoli processi aziendali implementabili in tempi ragionevoli e fornendo comunque indicazioni utili a comprendere l'andamento delle varie parti dell'azienda al di là dei singoli dati finanziari.
Sto ultimando la preparazione delle demo per il .NET Security Day che terremo a Lugano martedì 15 marzo.
Per far comprendere i rischi che comporta usare un utente amministratore, ho pensato di scrivere qualche demo ad-hoc e di documentarmi sui vari rootkit esistenti (un rootkit è un software che consente di nascondere l'esistenza di processi/risorse/driver intercettando e modificando il comportamento di parti del sistema operativo). L'obiettivo è dimostrare come non si può pensare di essere al sicuro solo perché si ha un anti-virus, un anti-spyware, un firewall e poi si usa il computer con un utente amministratore.
Bene, io non vorrei dare idee sbagliate a qualcuno, però penso anche che l'ignoranza non sia una tecnica di difesa particolarmente efficace, se non a livello psicologico (non so, quindi non mi preoccupo). Quindi mi limito a segnalare l'esistenza di siti come www.rootkit.com che consentono di documentarsi ampiamente su tutte le tecniche di attacco esistenti. KeyLogger a livello di driver (tra l'altro la documentazione spiega come catalogare in modo accurato i "filter driver" installati), un sistema per fare un log su file di tutti i logon (password comprese), driver che nascondono del codice nella memoria non volatile di una scheda video (così si reinstallano senza lasciare tracce sul disco) e altro ancora. Ce n'è veramente per tutti i gusti.
Purtroppo esistono determinati "malware" che possono essere eseguiti con un utente normale, magari con l'esplicito consenso dell'utente che pensa di utilizzare una nuova versione di Tetris. Questi software hanno comunque un potenziale di attacco (ai danni di dati confidenziali e/o riservati a cui l'utente ha accesso) sfruttabile anche senza essere amministratori; una difesa verso questo genere di attacchi è possibile solo utilizzando tecniche analoghe a quelle usate per installare un rootkit, filtrando le chiamate ad alcune API di Windows e chiedendo conferma all'utente delle intenzioni del software. Un po' come fa l'anti-spyware di Windows a fronte di certi programmi che tentano di installare servizi e/o driver. Peccato che l'anti-spyware di Windows non intercetti un KeyLogger scritto ad-hoc (no, non chiedetemi il codice, ma è facile costruirlo).
Sarà possibile quindi distinguere tra rootkit benigno e un maligno? Per un utente normale, l'unica certezza viene dagli autori. Per un programmatore esperto, leggere il codice sorgente e poi compilarselo in proprio dà una qualche garanzia in più. Ma quanti sono in grado di farlo? E quanti lo fanno veramente, senza trascurare nulla? Alla fine, bisogna basarsi sulla fiducia dell'autore.
Per questi motivi .NET è una strada decisamente obbligata, grazie alla Code Access Security.
Nel frattempo, se avete un po' di soldi in banca, fate operazioni con remote banking, usate il PC con con diritti amministrativi oppure ogni tanto lo fate usare anche a vostro figlio/moglie/parenti/amici senza dargli un utente diverso dal vostro che non sia amministratore... beh... controllate spesso l'estratto conto...
Tanti commenti al mio post di ieri sulla petizione di VB6: sono felice che la discussione sia rimasta pacata, anche se ci sono stati pochi interventi pro-VB6, con la rilevante eccezione di uno dei firmatari della petizione. Vi invito a leggere i commenti se non l'avete ancora fatto e a intervenire se volete.
Ci sono anche molti blog che hanno trattato l'argomento, italiani e non, e mi ha appena colpito il post di Frans Bouma che evidenzia l'inesorabilità di .NET e quanto VB6 in realtà sia tanto amato più per la disponibilità di tanti componenti COM che non per la sintassi (interessante il paragone con RealBasic). Irriverente poi il richiamo a Windows for Workgroup 3.11 e i Pentium a 60MHz...
Un tema trattato da pochi è la differenza nell'accesso ai dati tra VB6 e VB.NET (ma sarebbe meglio dire tra ADO e ADO.NET). Forse per tante realtà più o meno piccole è questo uno degli scogli più grandi da superare: usare una tecnologia che complica la vita (al programmatore) anche quando non ne avrebbe realmente bisogno, visto che avrà sì e no un paio di utenti. Chi sente nostalgia di client-server?
Prendo lo spunto da un commento che ho fatto a un post di Alessandro Perilli relativo alle vulnerabilità che potrebbero esistere nel kernel di Windows (descritte in questo whitepaper) per spiegare più in dettaglio come potrebbe migliorare la sicurezza del sistema operativo grazie alla scrittura di driver in codice managed.
Gli attuali sistemi operativi (come Windows e Linux) sfruttano in genere un'architettura dei microprocessori che consente privilegi di esecuzione differenti al codice macchina: i servizi del sistema operativo richiedono il massimo dei privilegi, mentre i normali processi applicativi (Word, Excel, ma anche Internet Explorer) utilizzano dei privilegi minori che consentono di proteggere i dati del sistema operativo e di isolare la memoria degli altri processi. In altre parole, il mio Word non può andare a "curiosare" nella memoria del mio programma di contabilità, indipendentemente dalla sua volontà. Una tecnica che viene usata per aggirare questo limite è quella di utilizzare privilegi di particolari utenti (come quelli di un amministratore) per richiedere (in modo apparentemente legittimo) al sistema operativo di effettuare operazioni altrimenti vietate (una situazione in cui ciò è legale è il debug di un altro processo in esecuzione, ma non è l'unica). Per questo motivo l'uso di utenti con privilegi minimi è preferibile all'uso continuo di utenti con diritti amministrativi, proprio per limitare la superficie di attacco.
Le macchine virtuali (come Java e .NET) introducono un concetto più evoluto di questa forma di protezione: non esistono solo delle modalità di esecuzione delle istruzioni che, in pratica, limitano l'accesso a determinate zone di memoria; viene definita, a livello di "macchina virtuale", una sorta di policy che definisce quali funzioni possono essere richieste da un determinato codice, consentendo l'accesso non solo in base all'utente che sta eseguendo l'applicazione ma anche in base alla provenienza del codice. Quest'ultimo concetto è sviluppato molto bene in .NET con la Code Access Security: un programma può, per esempio, leggere la clipboard solo se l'autore, il produttore, il sito di provenienza del codice o addirittura il singolo eseguibile è stato autorizzato a farlo, indipendentemente dall'utente che esegue il programma (sia esso amministratore o guest). Si tratta di un grande passo in avanti, perché si possono definire dei perimetri di sicurezza molto precisi e personalizzati: è un po' come prestare l'automobile a un amico e, invece di dargli le chiavi con cui può andare dappertutto, gli si fornisce una limitazione alle strade che potrà percorrere, alla velocità massima che potrà mantenere e alle radio che potrà ascoltare, pur avendo una chiave del mezzo che gli consentirebbe in teoria di avere libero arbitrio. [Notare che, a parte la limitazione delle radio selezionabili, per il resto ci sono già sistemi di antifurto satellitare che fanno esattamente quello che ho appena descritto]
Tutto questo è molto bello e in realtà funziona. Prova ne è il fatto che, fino a oggi, non sono ancora state scovate serie vulnerabilità nel Framework .NET o in programmi scritti in .NET. Il vero problema è che .NET vive in un ambiente (Windows) che è meno sicuro se si esegue del codice unmanaged, quindi è molto più facile attaccare il lato unmanaged di un sistema che non quello managed. Forse anche per questo fino a oggi abbiamo visto pochi tentativi di attacco (e nessuno con successo) attraverso codice 100% managed.
Proteggere il sistema operativo esterno a .NET è possibile e si può arrivare a eliminare Win32 mantenendo, per il livello applicativo, solo codice managed. Siamo già su questa strada, che sarà ancora molto molto lunga e richiederà ancora molti anni (almeno 10, credo). Si tratta però di una linea di tendenza già chiara nei suoi principi, ora diventa "solo" una questione implementativa e di distribuzione/diffusione. Se però andiamo alla parte più "interna" del sistema operativo, scopriamo che gran parte del codice che viene eseguito con il massimo dei privilegi è composto da driver per la gestione di periferiche e dispositivi vari. In Windows questo è necessario perché solo un driver può accedere direttamente all'hardware esterno, rispondere a degli interrupt del microprocessore e definire dei device di I/O logici o fisici.
Qui arriviamo a un punto debole storico di Windows. Un driver che fa un errore manda in crash l'intero sistema operativo. I driver non sono isolati tra loro come i processi "utente" cui siamo abituati, e come se non bastasse i driver hanno accesso all'intera memoria di sistema, senza alcune limitazione di sorta (un driver è più potente di un amministratore, insomma). Storicamente, dicevo, questo tallone d'achille di Windows è noto come blue screen (anche detto BSOD, Blue Screen Of Death). Molto è stato fatto da Microsoft per migliorare questo problema (causato il più delle volte da driver di terze parti) e oggi il BSOD è infinitamente meno frequente di quanto avveniva ai tempi di NT4. Poco o nulla, però, è stato fatto dal punto di vista della security. Come evidenziato dal whitepaper che ho già citato, una vulnerabilità di un driver potrebbe essere sfruttata da un attaccante per attacchi assolutamente devastanti rispetto alle risorse di una macchina: il codice dell'attaccante si viene a trovare in uno stato di "grazia" in cui ha accesso a tutto quello che c'è su un computer e, teoricamente, è il tipo di vulnerabilità peggiore che si possa immaginare (dico teoricamente perché sfruttare queste vulnerabilità richiede particolari acrobazie... ma il punto è che se una cosa è possibile, prima o poi si avvera).
Sono abbastanza certo che in Microsoft abbiano già pensato a questi scenari. Già a PDC 2003 avevo colto i segnali dei primi studi su come mettere il CLR nel kernel. All'epoca, devo dire la verità, mi ero concentrato più sul problema della stabilità del sistema operativo rispetto a dei driver difettosi piuttosto che sulle problematiche di sicurezza. Il ragionamento però è, per la sicurezza, ancora più importante. Con il CLR il codice è gestito e verificato prima della sua esecuzione: eliminando alla radice la possibilità di un buffer overrun, gran parte delle tecniche di attacco attuali vengono sterilizzate; con la Code Access Security, un driver per la scheda video si vedrebbe anche impossibilitato a scrivere su un socket TCP/IP o a installare un filtro per intercettare tutti gli eventi della tastiera (tutte cose che oggi un qualsiasi driver può fare senza che il sistema operativo possa opporsi). Il problema, ovviamente, è che tutto ha un prezzo e la difficoltà tecnica sta nel coniugare il costo di avere del codice managed con le esigenze prestazionali richieste a un driver, in particolare per quanto riguarda i tempi di latenza (ritardo nella risposta rispetto alle richieste in arrivo) più che per la semplice "forza bruta" di calcolo (anche se resta importante avere dei driver che non siano affamati di CPU).
Anche qui si tratta, in fin dei conti, di una questione implementativa: il fatto che sia teoricamente possibile creare un sistema operativo 100% managed si può dare per scontato. Come ci si possa arrivare oggi lo è un po' meno, ci sono tante questioni sul tappeto e non è facile capire quale sarà la strategia vincente. Io ipotizzo che l'hardware potrà dare una mano: processori sempre più specializzati (si pensi ai processori delle schede video) toglieranno sempre più compiti attualmente svolti da driver del sistema operativo (pensate solo ai vari gestori/codec audio/video esistenti). Il pericolo è che poi il problema si sposti su questi ultimi (volete che una scheda video dell'ultima generazione non abbia bug più o meno nascosti?), ma essendo processori dedicati il loro "campo d'azione" sarebbe necessariamente limitato: difficile che la scheda video riesca a fare un bonifico via internet dopo aver intercettato le mie password, almeno nelle architetture hardware attuali.
Ovviamente un sistema operativo 100% managed non sarebbe la panacea di tutti i problemi. Se però riuscissimo ad alzare il livello minimo di protezione di un sistema già ci scosteremmo dall'attuale situazione per cui oggi chi naviga in Internet ha un PC accessibile quanto lo sarebbe il proprio appartamento con un segnalatore vicino al citofono che comunica ai passanti se c'è qualcuno in casa e se la porta è rimasta aperta (o è facilmente forzabile). Ecco, riuscire ad avere più o meno tutti una chiave sulla porta d'ingresso, un citofono che non dica se siamo in casa prima ancora di aver suonato e la possibilità di vedere chi bussa senza dover necessariamente aprire la porta... sarebbe già un primo traguardo; non saremo ancora "al sicuro" ma saremo meno "sprovveduti" di oggi.
Robert Scoble segnala che esiste una petizione di oltre 100 MVP perché Microsoft riprenda lo sviluppo di VB6.
La cosa potrebbe sembrare uno scherzo ma è vera.
Non prendo spesso una posizione netta come questa, ma stavolta sento il dovere di oppormi a un simile tentativo. Milioni di sviluppatori VB6 hanno prodotto milioni di software, alcuni scritti bene, altri peggio. Purtroppo VB6 è stato usato (e viene ancora usato) in progetti dove è assolutamente inadeguato. La presenza di un supporto a VB6 sarebbe l'alibi per programmatori e aziende che non sanno distinguere tra produttività e semplificazione per continuare a ignorare cosa significhi la parola evoluzione in senso tecnologico.
Da un punto di vista puramente marketing potrebbe avere senso accontentare alcuni milioni di sviluppatori nel mondo. Dal punto di vista strategico, però, questa strada condurrebbe dritti dritti a mantenere quel mercato di software scritti da programmatori più o meno improvvisati che, forti di un po' di componenti che danno un'idea di interfaccia utente conforme (ma non troppo) agli standard Windows, abbattono la qualità media dei programmi esistenti per Windows, danneggiandone in ultima analisi l'immagine stessa di sistema operativo.
Non me ne vogliano quei programmatori VB che utilizzano in modo congruo VB6, usando interfacce, capendo la differenza Set e Let e avendo ben compreso cause ed effetti dei riferimenti circolari negli oggetti. Ho citato tre cose a caso che un programmatore improvvisato difficilmente conosce. Parlo per esperienza: sono tanti e sono numeri che alla lunga danneggiano utenti e professionisti (sì, ecco un altro programmatore che ci farà impazzire, pensa l'utente medio sopravvissuto all'uso di un software dilettantesco). Mi spiace per voi, so che in fondo, se usato bene, VB6 dà buoni risultati, ma se lo conoscete così bene... sarete già passati a VB.NET o a C#, ma comunque a .NET, e non ve ne sarete certo pentiti. Leggo che tra i firmatari ci sono persone che conosco e ammiro, hanno sicuramente le loro ragioni ma nonostante questo spero che la petizione non abbia un gran seguito.
L'eutanasia di VB6 porta a un mondo migliore.
Ci credo veramente.
Molti mi odieranno per questo.
I commenti sono aperti.
Sono pronto a cambiare idea, ma servono giustificazioni che in questo momento non riesco a immaginare.
More Posts
Next page »