Longhorn nel 2006, prime considerazioni

Sto cercando di farmi un’idea delle conseguenze provocate dalle novità annunciate ieri.


La cosa più importante è che di fatto Longhorn non è più l’unico sistema operativo su cui si potrà sviluppare con WinFX (su cui si basano Avalon, Indigo e WinFS). WinFX sarà disponibile su Windows XP e Windows 2003. Conseguenze:



  • Per gli sviluppatori non ci sarà una discontinuità così forte tra Windows XP/2003 e Longhorn
  • Per gli utenti si potrà sarà come installare una nuova versione di .NET
  • Sarà più facile vedere programmi basati su WinFX, in quanto non dovranno contare su una base di installato limitata a Longhorn e non vedremo versioni “doppie” di uno stesso programma (una per Longhorn/Avalon e l’altra per WindowsXP/2003/Windows Forms)
  • Ha più senso cominciare da subito a valutare WinFX anche per progetti a medio termine e non solo a lungo termine. Sul breve (ma per lo più parliamo di progetti grandi già in corso o di progetti piccoli) comunque si rimane su .NET 1.1
  • Dal punto di vista della security e del deployment si potranno scrivere applicazioni 100% managed e distribuite con ClickOnce per una distribuzione anche all’interno di aziende medio-grandi (in prospettiva, nel 2007 sarà più probabile avere in un’azienda dei client XP di quanto non sia oggi… se aspettassimo Longhorn andremmo almeno al 2010). So che qualcuno penserà che molte aziende hanno ancora Windows 98, ma qui si ragiona su aziende che hanno Active Directory e Group Policy, quindi sono passate per lo meno a Windows 2000 già oggi.

Il fatto di rendere disponibile WinFX è in realtà legato alla volontà di distribuire Indigo e Avalon anche su XP e 2003. Per Indigo già si sapeva mentre per Avalon no, ed è proprio Avalon ad avere le maggiori dipendenze da WinFX (in realtà ne ha anche Indigo, ma in maniera più limitata e in un certo senso “isolata”). Fornire Avalon  è la chiave per spingere lo sviluppo di applicazioni basate su questa interfaccia. Anche se Microsoft nega, una larga diffusione di Avalon può consentire di avere un’alternativa ai vari player Flash, anche se non sarebbe nativamente multi-piattaforma (ma qui potrebbero entrare delle terze parti, vedi Xamlon, che potrebbero prendere come target Linux e Mac). Su questo c’è ovviamente il problema di brevetti e mancanza di standard, ma il futuro in questo campo è ancora da scrivere. Comunque, veniamo alle conseguenze date dalla disponibilità di Avalon su XP/2003:



  • Spinta per uno sviluppo di applicazioni Avalon
  • Vita di Windows Forms più breve (intendiamoci… mentre prima mi sarei aspettato di vedere nuove applicazioni Windows Forms almeno fino al 2009/2010, con questa mossa il declino potrebbe iniziare già nel 2007/2008)
  • Aumenterà il numero di applicazioni “miste” (magari applicazioni Windows Forms che gradualmente incorporeranno componenti in Avalon); la necessità di valutare l’interoperabilità tra i due mondi sarà enorme, mentre prima era relativamente meno importante – purtroppo questo si trascina dietro anche il problema della compatibilità con componenti ActiveX e sinceramente è un film che preferirei non vedere…

In tutto questo viene a mancare WinFS e anche qui vedo diverse conseguenze:



  • Mancanza di uno dei punti “strategici” per alcune killer application: vi ricordate l’utopia di prendere le foto e catalogarle in modo quasi automatico? Anche se qualche pezzo di WinFS potremmo vederlo (Bill Gates ha parlato di “tecnologie di ricerca” che saranno comunque presenti, vedremo come funzioneranno) la mancanza di questo componente, poco visibile all’utente finale in una demo veloce, rischia di far venire meno uno dei motivi per passare a Longhorn
  • Per contro, non c’è bisogno di preoccuparsi troppo di WinFS per almeno un anno o due: solo quando vedremo la prima beta (nel 2006?) sarà il caso di dargli un’occhiata
  • Nessuno ha ancora parlato del Microsoft Business Framework, che insieme a Object Spaces era diventato parte di WinFS. Mi pare inverosimile che tutto quanto slitti al 2007/2008 (e soprattutto a una data non definita a oggi). Pochi mesi fa la notizia era che MBF sarebbe stato allineato a Longhorn e Orcas, ma la mancanza di WinFS assume un ruolo chiave. Ora che succederà? Attendiamo notizie…

Finite le prime considerazioni da sviluppatore, ce ne sono alcune più generali:



  • Longhorn non sarà così diverso da XP (completo di WinFX/Avalon). Il grado di adozione di Longhorn dipenderà più dall’installazione su nuovi PC che non dall’upgrade di PC vecchi. Soprattutto, vedo meno “forte” lo stimolo a cambiare PC solo per avere Longhorn; sarà più o meno lo stesso stimolo che si ha adesso vedendo un PC più veloce e più potente. Sicuramente ci saranno nuovi device gestiti al meglio solo da Longhorn, ma in termini quantitativi l’adozione di Longhon seguirà il normale “ciclo di vita” dei PC
  • Microsoft ha deciso di non creare una discontinuità così grande con il passato, come sarebbe avvenuto se avesse mantenuto la decisione di riservare WinFX a Longhorn. Forse era un rischio troppo grande, sicuramente rende le cose più semplici a tante società che sviluppano software per Windows e anche a chi lo usa, però viene un po’ a mancare il brivido della “scommessa”. Vedremo una graduale evoluzione, come è sempre avvenuto finora
  • Longhorn potrebbe avere meno problemi legati alla necessità di mantenere la compatibilità con hardware/applicazioni esistenti. Io lo vedo come un vantaggio: se la compatibilità con certe applicazioni o certi dispositivi ha un costo troppo elevato, possono decidere di non mantenere tale compatibilità. Se Longhorn avesse dovuto staccarsi troppo, per assurdo tale compatibilità avrebbe dovuto essere massima (a costo di usare macchine virtuali) per non creare un divario così ampio col passato. In altri termini: se un’applicazione è critica, la si può tenere fuori da Longhorn fino a che non arriva una versione “compatibile”. Sto parlando in termini molto generici perché non ho idea di quali potrebero essere questi problemi in dettaglio, ma sicuramente ce ne sono (forse più dal punto di vista hardware che software). Questo può aiutare anche a creare una piattaforma più “sicura” (talvolta la compatibilità con il passato è uno dei talloni d’achille della security)

Per ora non mi viene in mente altro. Sicuramente nei prossimi mesi vedremo ancora tante novità e a questo punto la PDC 2005 può anche arrivare in primavera (con un’alfa o addirittura una beta di WinFX per XP/2003/Longhorn).


 

Via WinFS, Avalon anche su XP

UPDATE: la notizia di cui parlo in questo post è già ufficiale.


Sembrerebbe non essere uno scherzo: queste indiscrezioni provengono da una fonte relativamente affidabile e sono anche molto consistenti tra loro:



  • WinFS non è indispensabile per una nuova release di Windows
  • Avalon è legato a .NET e non a una nuova release di Windows (tolte alcune ottimizzazioni e forse anche il DWM)
  • Indigo può essere distribuito separatamente (già era stato annunciato a PDC 2003)
  • Office 12 (che deve girare anche su versioni di Windows pre-Longhorn) potrebbe così basarsi almeno su Avalon

Questo scenario rende una data di rilascio entro il 2006 più credibile (comunque andremmo sempre almeno a fine 2006…) e il passaggio a Longhorn meno traumatico. Per contro, senza WinFS e l’integrazione che può fornire ad alcune applicazioni, la necessità di un nuovo sistema operativo potrebbe venire un po’ a mancare. Come al solito, staremo a vedere.

Aggiornamento VC++ 2005 post Beta 1

Non è passato molto dalla beta 1 di Visual Studio che è già disponibile un aggiornamento destinato ai soli sviluppatori Visual C++. Nel tool refresh ci sono novità nel compilatore e alcune correzioni alle librerie. Non ho tempo di provarlo prima di qualche giorno ma se qualcuno sta già usando la beta è una notizia interessante.

Tutorial per SCM

SCM sta per Source Control Manager e identifica quella categoria di programmi che consentono di gestire la “storia” delle versioni dei sorgenti di un programma (anche noti come VCS, version control system), nonché di gestire un gruppo di programmatori che lavorano insieme a uno stesso progetto. Eric Sink sta scrivendo un tutorial (che lui chiama “how to”) interessante per chi è alle prime armi.

Motore .Text per blog DevLeap

Come avrete notato, negli ultimi giorni abbiamo sostituito il motore di blog di DevLeap, passando da un’implementazione proprietaria a quella di .Text.


Abbiamo cercato di mantenere i feed RSS esistenti, stiamo lavorando per risolvere gli ultimi problemi (permalink nel formato vecchio, ecc.). Se usate un RSS aggregator avrete trovato qualche messaggio duplicato… è stato un male minore.


Se riscontrate delle anomalie segnalatecele! La funzionalità Feedback all’interno del sito consente di mandare un messaggio via mail all’autore del blog.


Ultima cosa: per scelta non abbiamo attivato i commenti nel blog. E’ una cosa su cui stiamo ragionando ma preferiamo avere tutto a posto per poi valutare come gestirla. Un’idea è quella di averla disabilitata per default, attivandola volontariamente sui post dove si desidera aprire un dibattito. I problemi sono spesso la mancata lettura dei commenti nel tempo da parte dei lettori (chi legge un post oggi magari non ci torna giorni dopo per vedere dei commenti interessanti) e il possibile spam. Anche su questo argomento, fateci sapere cosa ne pensate, sia come lettori che eventualmente come blogger.


PS: un grazie ad Alessandro Perilli che ci ha dato una mano nella definizione dello skin usato.

Ancora demo…

Nel post precedente ho parlato di Assembly 2004 ma stamattina Davide Mauri mi ha prontamente segnalato un po’ di link sul tema, che giro alle persone eventualmente interessate.


Siti per demo scene: www.pouet.net e www.ojuice.net.
Segnalazone di demo da 64K: http://www.pouet.net/prod.php?which=1221.


Davide mi ha anche segnalato questa demo tra le sue preferite (VIP 2) ma io voto decisamente per The popular demo (veramente divertente).
 
Ok, avete i link per perdere tutto un weekend, io ora torno a occuparmi di Yukon…

Assembly 2004

No, in questo caso non sto parlando di assembly .NET ma della manifestazione Assembly (giunta alla tredicesima edizione!) che si tiene annualmente in Finlandia. Si riuniscono gruppi che fanno grafica, musica, video e quant’altro si possa creare con un PC.


Il meglio sono le demo in tempo reale: un programma che gira sul PC e “crea” una demo (audio/video, in genere) live… Le categorie più estreme sono 4K e 64K (il programma deve stare in 4 o 64 Kb, attenzione Kb e non Mb o Gb). Ovviamente molti sono programmi che si scompattano poi in memoria, il vincitore della categoria 64K arriva a occupare circa 256Mb in memoria…. Se vi chiedete il linguaggio più usato… ma l’assembler, naturalmente! La categoria 4K dovrebbe farvi chiedere come diavolo buttiamo via la memoria al giorno d’oggi…


Se volete vedere qualcosa di veramente diverso, scaricate qualche demo (per esempio da qui). Io sono rimasto decisamente colpito da Obsoleet (vincitore categoria Demo) di Unreal Voodoo: se avete cominciato anche voi all’epoca del Commodore o dello Spectrum o se siete curiosi… questa demo è bellissima, ricca di rimandi e comprensibile al 100% solo con un background di programmazione grafica alle spalle. Vedere per credere!


Ci sono molte demo belle e spettacolari. Le musiche sono originali, insieme a tutto il resto. Da vedere e ascoltare. Unico problema: bisogna avere un PC ben carrozzato, altrimenti in alcuni casi ci sono degli AVI che rendono più semplice la visione…

Prevedere il futuro

Post scherzoso da week-end… Volete prevedere il futuro? Semplice, basta leggere qualche libro di fantascienza.


La riflessione nasce da un’incredibile coincidenza, tanto che c’è veramente da dubitare che sia tale. Nel primi anni ’60 in “A for Andromeda” viene citata una multinazionale dell’elettronica chiamata Intel, la quale è stata fondata nel 1968. I suoi fondatori scelsero un nome diverso per poi passare quasi subito a Intel. Qua è poco chiara la sequenza temporale (il nome era anche quello di una catena di hotel), ma la circostanza è quantomeno curiosa.


Dunque, chi ha visto Blade Runner si starà chiedendo cosa fa oggi la Nexus… ce n’è diverse (in Italia e all’estero) ma www.nexus.com da quarant’anni fa solo pulsanti e jack per microfoni…

Misurando si scopre sempre qualcosa

Tre giorni fa criticavo alcuni tips&tricks che mi era capitato di leggere. Oggi mi è capitato di ottimizzare alcune query e quindi ho misurato l’uso dell’alternativa suggerita a WHERE NOT IN, scoprendo che è efficiente anche in casi dove mi sarei aspettato il contrario. La condizione che va soddisfatta è che la WHERE NOT IN vada a operare sul risultato di una query che estrae la chiave primaria di una tabella; in una situazione simile il piano di query generato risulta più efficiente con la LEFT JOIN (con una WHERE campoInJoin IS NULL) anche se la tabella oggetto della join è molto piccola.


Ovviamente resta valida la considerazione che facevo (misurare, misurare, misurare…) perché in assenza di indici la subquery indipendente potrebbe presentare dei vantaggi, ma in effetti il numero di casi in cui la WHERE NOT IN è più efficiente è minore di quanto pensassi. Mi sembrava giusto dirlo…