Entries Tagged 'programmazione' ↓

Ficcatevelo in testa: nascondere (o negare) i problemi di un sistema è il peggiore dei comportamenti possibili.

La considerazione nasce, ovviamente, dalla paradossale storia che ha coinvolto alcuni studenti del MIT e un servizio di trasporti pubblici del Massachussetts. Innanzi tutto va chiarito che le persone coinvolte non sono un manipolo di malviventi, ma studenti del MIT il cui professore è Ron Rivest, la ‘R’ del RSA. Gli studenti hanno scoperto un problema nel sistema di tariffazione dei trasporti pubblici e hanno applicato le procedure descritte dalla Full Disclosure Policy (RFPolicy) v2.0. La policy prevede che chi scopre un problema di un sistema contatti per prima cosa l’autore/gestore del sistema con cui stabilisce un dialogo che ha come scopo primario la soluzione del problema.

Questa volta, anziché dar retta ai tecnici è stata prestata attenzione ai legali, i quali sono riusciti sì ad impedire che venissero rivelati gli estremi della vulnerabilità, ma non a risolvere il problema. Intendiamoci: come sono riusciti gli studenti del MIT potrebbe arrivarci chiunque altro e questa volta potrebbe non essere ispirato da nobili sentimenti. Oppure potrebbe essere che già in questo momento qualcuno stia utilizzando da tempo le falle del sistema per viaggiare gratuitamente e questo qualcuno ha ringraziato l’ufficio legale che ha bloccato gli studenti del MIT.

Se qualcuno, quindi, scopre un problema nei nostri sistemi e applica la RFPolicy, non dobbiamo rispondere con una granaiuola di cause, ma dobbiamo ringraziarlo e, magari, invitarlo a collaborare per sistemare il problema. Una volta sistemato il problema, bisogna renderlo pubblico sia per invogliare chi è coinvolto ad aggiornare il proprio sistema, sia per evitare che altri facciano la medesima scoperta e la utilizzino per scopi non proprio legali.

L’adesione alla RFPolicy da parte di una Società è sempre un comportamento coraggioso perché alcuni presunti responsabili delle PR pensano alla caduta di immagine nell’immediato e non vedono le conseguenze per l’intera Società (non solamente per la sua immagine) a lunga scadenza.

In cauda venenum: il fatto che vengano denunciate pochissime frodi informatiche al sistema bancario dipende dalla robustezza della loro infrastuttura informatica?

Aggiunta: La presentazione è stata pubblicata e vale la pena di essere consultata da qualsiasi persona che abbia a che fare con la sicurezza informatica, non solamente riguardo ai trasporti pubblici.

Come programmatore sono sempre stato affascinato dagli algoritmi, specialmente se compatti ed eleganti

Ci sono, però, dei problemi per la cui soluzione non esistono algoritmi efficienti; di contro, per gli stessi problemi, se viene presentata una soluzione, questa è immediatamente e facilmente verificabile come corretta. Prendete, per esempio, una mappa con un sacco di isole e ponti: non esiste un algoritmo efficiente che tracci un percorso per visitare tutte le isole una sola volta, ma se vi viene presentata una soluzione, è facile capire se sia corretta. Un altro problema da un lato più teorico, ma con tremende ripercussioni pratiche è, dato un numero, capire se sia il prodotto di due numeri primi e di quali. Se quest’ultimo problema è semplice con numeri piccoli, non lo è, fortunatamente, per numeri molto grossi. Perché «fortunatamente»? Perché la gran parte di transazioni informatiche crittografate si basa su questo assunto. Se leggete che qualcuno ha trovato un algoritmo per fattorizzare rapidamente numeri di grandi dimensioni, iniziate a preoccuparvi davvero.

Charles Stross, uno dei miei autori di fantascienza preferiti, ha addirittura ipotizzato che la soluzione per via algoritmica di problemi NP-completi porterebbe rapidamente alla creazione di una singolarità tecnologica con conseguente fine della nostra civiltà. Robot 52 ha pubblicato il gustosissimo raccorto Anticorpi ambientato nell’universo della Lavanderia in cui Stross analizza, appunto, questa eventualità.

Per ora non è nemmeno stato dimostrato se esistano soluzioni algoritmiche ai problemi NP-completi. Secondo un articolo di Scott Aaronson pubblicato sull’ultimo numero di Le Scienze (a cui vi rimando per una trattazione più autorevole di questa), anche con i computer quantici non sarebbe possibile risolvere ogni tipo di problema, in particolar modo quelli NP-completi, per un mero fatto di leggi fisiche.

Meglio: di leggi fisiche attuali, perché sarebbe possibile realizzare un computer in grado di risolvere ogni tipo di problema (anche quelli ancora più complessi dei problemi NP-completi) usando leggi della fisica in contrasto con quelle attuali. Mi ha divertito abbastanza il concetto di computer che si basa sulle curve temporali chiuse (il nome scientifico dei viaggi arbitrari nel tempo): si tratta in pratica di un computer che risolve un problema in un tempo lungo a piacere che comunichi, però, la soluzione appena dopo che gli è stata sottoposta.

Forse un computer del genere non verrà mai realizzato, ma se lo fosse mi eviterebbe, finalmente, di sentire lamentele sulla lentezza di Windows. Il vantaggio sarebbe anche che la fine dell’Universo verrebbe prorogata indefinitivamente a causa del tempo necessario per far girare Windows.

Scrivo software da… uhm… tanti anni e ho visto nascere, crescere e morire molti linguaggi del futuro.

Nei primi anni di MS-DOS e anche nei primi anni di Windows (diciamo dal 3.0 in avanti) queste erano piattaforme entusiasmanti su cui scrivere. C’erano dei bachi sia nel sistema operativo sia nei tool di sviluppo, ma erano ben noti e quasi sempre facilmente aggirabili. C’erano molte librerie di terze parti (anche senza Internet le informazioni circolavano benissimo tra i programmatori) che sopperivano alle carenze delle librerie standard dei linguaggi e alle necessità dei programmatori. C’era chi pubblicava compilatori, chi pubblicava librerie e chi comprava i due per creare programmi.

Poi è successo qualcosa, credo attorno al 1995/1996. Windows si è trasformato in una piattaforma di utilizzo in cui i tool di sviluppo c’erano, ma gestiti quasi esclusivamente dal produttore del sistema operativo. Sono usciti prodotti interessanti, ma la potenza di fuoco di Micorosft è sempre stata soverchiante: quante volte hanno cambiato il modello di accesso ai database in Access e/o in Visual Basic con la motivazione (sempre uguale) che il nuovo modello è migliore di quello vecchio, ogni occorrenza del quale nel vostro codice deve essere isolata e distrutta come un campione di malattia infettiva? La prima volta ci siamo stati dietro, la seconda abbiamo storto il naso, la terza è partita una raffica di moccoli verso Redmond ed il codice è rimasto invariato.

È inutile che Ballmer, sudato come un cammello, si metta ad urlare «Developers! Developers! Developers!» sul palco delle presentazioni di Microsoft se poi loro stessi fanno scappare gli sviluppatori innovando i loro linguaggi ogni 18 mesi. Ma credono davvero che le aziende che sviluppano (per non parlare del software sviluppato in house) abbiano soldi da buttare per stare dietro ai loro capricci?! Anche ars tecnica recentemente ha trattato il problema dello sviluppo sotto Microsoft.

E allora cosa rimane a noi sviluppatori? Una buona alternativa potrebbe essere l’utilizzo dell’interfaccia HTML generata da un linguaggio server side che si appoggia su un motore SQL. La piattaforma del web browser è oramai ben consolidata presso l’utente finale, che ha una discreta familiarità con essa e ne accetta le limitazioni. Su questo fronte ci sono vari linguaggi, molti dei quali gratuiti, integrabili tra loro e con un’ampia base di installato e di librerie pronte per vari scopi. L’innegabile vantaggio di queste soluzioni è la portabilità tra gli ambienti e la facilità con cui interagiscono con altre piattaforme attraverso protocolli aperti.

Vista la natura di questi linguaggi e di queste tecnologie, è anche più facile trovare sviluppatori, anche giovani, entusiasti di poter mettere a frutto le loro esperienze e vogliosi di crescere.

Quando Ballmer se ne accorgerà sarà sempre comunque troppo tardi.