Per ogni party c’è sempre un rovina-feste.
Ho installato Win7 sul vecchio Sony e funziona tutto molto bene tranne la webcam, il cui driver non ne vuole sapere di installarsi (l’installazione è per Windows Vista e tra Vista e Win 7 dal punto di vista di driver della Webcam non è cambiato niente).
Windows 7 Upgrade Advisor riporta che i driver “sono disponibili sul sito del produttore”. Sul sito del produttore, per il VAIO VGN-SZ381P ieri era scritto che sarebbero stati disponibili con il rilascio al pubblico di Windows 7.
Oggi c’è scritto:
Più sotto:
Sì, certo, come no! Apro subito il portafogli. La cosa più irritante è il fatto che questi ca**ony abbiano speso tempo e pecunia per fare un sito in cui dare un annuncio “a mezzanotte” pur di non eliminare il blocco del driver della webcam. Vorrà dire che mi toccherà installare Vista, installare il driver e creare un installer a mano per bypassare il problema. (*)
Cosa buffa anche per la scheda grafica, una normalissima NVidia Go 7400, c’è bisogno dei driver “Sony” in quanto il PnPID è “taroccato”: Apple Style per l’appunto.
-quack
(*) Ho poi risolto installando i driver per XP, che hanno funzionato senza menarsela tanto. 
È un piacere bestiale vedere che qualche volta qualcosa va secondo i piani. Dovevamo essere pronti per domani e lo siamo: Windows Compatibility Center e Windows 7 Upgrade Advisor sono RTM.
Del Windows Compatibility Center (aka WEC) ho coordinato lo sviluppo, anche se verso la fine – quando tutto sembrava andare già per il verso giusto – mi son dato latitante. Per W7UA ci ho lasciato lo zampino in due modi: il primo, molto poco rilevante, è stato quello di giocherellare con la traduzione italiana e segnalare un paio di ‘chicche’. Il secondo contributo, quello più importante, è stato di fare in modo che la quantità di dati disponibile per WEC fosse mappata anche in W7UA con un progetto dal nome in codice PIMS: problema che si è rivelato molto più insidioso di quanto potesse apparire. PIMS è un sistema che utilizzando un meccanismo di feedback migliora i risultati con il passare del tempo. Un progetto abbastanza divertente se non fosse per l’interazione con il test team, che è stato uno dei tanti motivi che mi ha spinto ad abbandonare la via vecchia… Quindi visto che tutto funziona, sto facendo in modo che Venerdì sia l’ultimo giorno, quello di addio ai vecchi compagni e di ben trovati a quelli nuovi.
A proposito di G.A. (general availability ovvero disponibilità al pubblico) mi è venuto in mente un modo per mettere in palio un paio di licenze retail di Windows 7: uno pseudo-concorso grafico/CSS possibilmente inter-nos per rifare quasi ex-novo il tema di questo blog. Al vincitore una licenza di W7 Ultimate, al secondo posto W7 Home premium. I due stili verranno usati come look di default in due fasi separate ed ovviamente devono rispondere ai temi di questo blog: informatica, cazzate, Seattle e…. Paperino.
Prima di lanciare però il concorso ufficialmente, ho bisogno del parere dei possibili partecipanti sulla bontà dell’idea (la cosa deve essere divertente e non vuole essere un tentativo di procurarmi della ‘consulenza grafica’ a poco prezzo). Lasciate un commento in coda a questo post.
-quack
Cosa succede gli ultimi giorni prima del rilascio? Perché secondo alcuni l’RTM non è un punto nel tempo ma un intervallo di tempo? Provo a dare qualche risposta.
Chi controlla il rilascio di un software è principalmente il test team che firma (col sangue!) sulla qualità del prodotto ed infatti il test team è anche denominato Quality Assurance team. Le fasi di un prodotto si distinguono grosso modo in sviluppo, stabilizzazione e rilascio. Lo sviluppo introduce modifiche che causano bachi: questo di solito è tollerato entro certi limiti e tali limiti durante lo sviluppo di Windows 7 sotto la guida di Sinofsky sono stati ridotti di parecchio. Durante la pianificazione del prodotto si scelgono delle cut-off dates (in genere milestone) e se la feature non ce la fa ad essere codificata in tempo è fuori dal prodotto (feature fantasma, di cui pochissimo si sente parlare in giro).
Successivamente, la fase di stabilizzazione è quella in cui ci si concentra per la sistemazione dei neo-introdotti bachi (o qualche vecchio baco stagionato). I test automatizzati vengono completati e se qualche team dichiara di avere bisogno di più tempo per sistemare i bachi o completare il testing, la feature viene “processata”: in base al tempo richiesto, all’importanza della feature ed altri fattori astrologici viene deciso se la feature viene tagliata (postposta a nuove versioni) o meno valutandone il rischio di far slittare il rilascio. Ovviamente nel frattempo il test team individua nuovi bachi, i developer sistemano e ogni giorno viene generata una nuova build. Man mano che il tempo passa la barra dei bachi sale di livello: ad esempio si passa da “ogni team decide per se” al “tell mode” dove ogni team dichiara la propria mano all’ask mode, dove ogni team chiede il permesso di poter sistemare certi tipi di baco. Durante l’ask mode poi la barra può continuare a salire: alcune priorità vengono automaticamente scartate (esempio: bachi di priorità 3 o più bassa), altri bachi vengono “processati” e così via. Ovviamente trattasi di esempi, ma la costante è il fatto che periodicamente la bug bar viene alzata (o abbassata se si pensa ad una gara di Limbo). Durante tutto questo tempo la differenza tra una build e l’altra, a livello di bit, è così grande che gli stress test assumono un significato diverso da quello più tradizionale di stress test. Si cercano bachi che si verificano solo dopo lunghe sessioni di azioni ripetitive o meno (ortogonalmente: artificiali o meno) ma molti di questi vengono dichiarati “automagically fixed”.
Raggiunta la stabilizzazione comincia il vero e proprio rilascio: questo avviene con la prima build “abbastanza buona” che viene dichiarata escrow e si entra nell’escrow period, ovvero un periodo di tempo in cui quella build è garantita per la maggior parte delle funzionalità di essere equivalente a quella finale. Gli stress test entrano nel vivo, i bachi importanti continuano ad essere sistemati, ogni giorno viene generata automaticamente una nuova build e tutto fila liscio fino all’accadere di due possibili eventi:
- nessun nuovo baco viene trovato
- viene trovato un baco importante e con un impatto così elevato che bisogna resettare l’escrow, ovvero non si può più garantire con una certa confidenza statistica che la build che contiene la fix sia funzionalmente equivalente alla precedente, baco a parte of course
Nella condizione 2. il ciclo si ripete e si continua fino a quando non si esce dal ciclo tramite la condizione 1.
A questo punto la build è QUASI quella finale. Vengono sistemate le ultime cose (numero della build), viene interrotto il processo di generazione giornaliera delle build (nel ramo RTM of course) e si invita i vari team a fare il sign-off dei propri componenti. Il sign-off consiste nel fare le ultime verifiche durante le quali qualche baco potrebbe sempre fare capolino. Nel caso il baco sia molto importante sarà necessario generare una nuova build e in alcuni casi annullare il sign-off già cominciato. Il sign-off può richiedere un lasso di tempo che va da qualche ora per i prodotti più semplici a qualche giorno o settimana: si tratta di una vera e propria firma su un modulo Web e tutte le eventualità del caso possono accadere (malattie, assenze, ecc.). Ovviamente si può decidere che per alcuni bachi non vale la pena generare una nuova build oppure che vale la pena oppure che si approfitta della necessità di una nuova build richiesta da un altro team (piggy-back) per schiacciare gli ultimissimi bachi. Quando tutti i responsabili firmano il sign-off è fatta; alcuni stappano lo champagne, altri come il sottoscritto escono in corridoio a fare il ballo della banana.
Ora dovrebbe essere chiaro perché una build con qualche numero cabalistico (es. 7600) è condizione necessaria ma non sufficiente per la RTM; dovrebbe anche essere chiaro perché è impossibile prevedere con determinata precisione la data ufficiale di rilascio: ogni previsione ha una componente di rischio non indifferente che può portare ad interpretazioni diverse; e dovrebbe essere anche chiaro perché la build RTM è sempre vecchia di qualche giorno nel momento in cui viene dichiarata tale.
-quack
P.S. quello che ho scritto è valido in generale
Le voci di corridoio online dicono che tra qualche giorno Windows 7 potrebbe essere rilasciato Urbis et Orbis in versione gold. Le voci ufficiali (seconda metà di Luglio) sono in linea con quelle di corridoio.
Gli ultimi giorni del rilascio non sono più come quelli di una volta a causa dell'evoluzione dei processi di sviluppo: il rilascio di Windows NT 3.1 seguì una vera e propria Death March, meglio ancora Death Marathon. L'aria che si respira nel building 26 (e 37) sembra invece surrealmente silenziosa. Ma tecnicamente cosa succede? Lo raccontano Larry Ostermann e Raymond Chen in queste tre storie:
- Last Checkin Chicken
- Losing the game of the Last Checkin Chicken
- Thinking about the Last Checkin Chicken
In Vista l'ultimo checkin spettò allo stack audio. Ma neanche questo bachino scherzava assolutamente. Stavolta sono io che ho trovato un baco, sempre nello stack audio, col mio netbook solamente pochi giorni fa. Un po' di analisi e la risposta è stata: There is an audio driver on WU that will fix this issue. Peccato! Ahem... volevo dire Great! 
-quack
P.S. il post è stato scritto con il Blogoo Editor Online nuovo di zecca. La Beta sta arrivando.
Tadà.
Proprio mentre si parlava di mancate notizie sullo sviluppo di Virtual PC la feature a sorpresa che – anche se non fa parte della RC di Windows 7 – era stata pianificata per un annuncio a reti unificate.
Ed era esattamente quello che pensavo alcuni giorni fa (a meno di ulteriori sorprese):
E a proposito di annunci misteriosi: non è da sottovalutare quello che verrà annunciato durante la presentazione ufficiale della RC di Windows 7. Io *penso* di sapere di cosa si tratti ma ovviamente non posso rivelarlo nemmeno sotto tortura.
Il forte indizio è stata una mail che invogliava il nostro team a provare in anteprima Virtual XP (diventato ora ufficialmente Windows XP mode) proprio gli stessi giorni in cui era stato fatto l’annuncio ufficiale. Ne sapevo già abbastanza perché un giorno mentre il mio codice compilava, mi sono rovistato tutte le specifiche ufficiali di Windows 7 e per l’occasione dell’annuncio ho lasciato di stucco un po’ di colleghi colti di sorpresa. C’è da aggiungere che ho visto anche cose…
Cose che sotto tortura ho già dimenticato. 
Happy weekend
A più di due anni dall’uscita di Vista gli articoli sul fantomatico DRM di Vista hanno cominciato a diventare molto rari: persino Batman ha saggiamente deciso di dedicarsi ad altro anche se il tono dei suoi post mira sempre a dipingere Windows come il male assoluto.
Almeno questo era quello che pensavo fino a ieri sera, quando su Slashdot è comparso questo post letteralmente vomitevole che segna il ritorno in scena delle cornacchie del DRM: Draconian DRM Revealed in Windows 7
Neanche Adrian Kingsley-Hughes, sempre piuttosto critico verso Vista, ha retto l’impatto e l’ha bollato come Worst. Windows 7. Piece. EVER!
La perla più gustosa è che l’autore dice di avere una copia legittima di Photoshop CS4 ma che infastidito dalla schermata di registrazione ha scaricato una losca DLL via Internet e ha scoperto che su Windows 7 la “modifica” non funziona scompigliando un po’ di ACL su alcune directory; la mia diagnosi: il pir*a ha scaricato un bel trojan ma secondo lui la colpa è di un fantomatico e “Draconiano” DRM.
Non mi sorprende che in giro ci sia gente fondamentalmente ignorante e semi-analfabeta(*): ma che Slashdot pubblichi senza riscontro qualsiasi cosa parli male di Windows è davvero sorprendente.
-quack
(*) semi-analfabeta: persona che non sa leggere ma che muore dal desiderio impellente di scrivere.
Per motivi di tempo e perché mi aspettavo che la questione si sarebbe conclusa nel migliore dei modi a stretto giro di posta, mi sono astenuto da intervenire sulla debacle dei nuovi setting di default di UAC in Windows 7.
Comincio dalla fine: i nuovi setting di default, nonostante la mia tendenza paranoica, mi piaciono parecchio. L’obbiettivo delle modifiche apportate in Windows 7 è quello di cercare di distinguere le azioni iniziate dall’utente che clicca su qualcosa, da quelle delle applicazioni che impersonano l’utente. La questione è un po’ il Sacro Graal dell’informatica: chiunque ci riuscisse avrebbe inventato il primo sistema operativo a prova di malware, moderna macchina del moto perpetuo informatico. Gödel per fortuna ci dice che ogni sforzo è vano: se non si può capire a priori se un programma termina, figuriamoci se si può capire a priori cosa realmente fa il progra
mma e con quali intenzioni. But I digress…
In Vista molto spartanamente è stato diviso l’amministratore in due entità separate e tutti i task che richiedono permessi amministrativi richiedono un prompt di conferma o la password. Questo significa che anche cambiare il fuso orario richiede un prompt UAC. Qualcuno però abituato ai silenzi di Windows XP ha dipinto la questione in maniera molto peggiore della realtà, come se vivesse a confine tra due fusi orari e avesse la necessità di cambiare questi importanti setting di sistema ogni 5 minuti. In Windows 7 Beta si è scelta un’altra via, evoluzione di tanti esperimenti fatti nelle build intermedie: è stata creata una lista di applicazioni di sistema (white-list) che a livello UAC di default consente all’utente loggato di auto-elevarsi ad amministratore senza nessun prompt, ovviamente a patto che l’utente appartenga al gruppo degli amministratori. L’intento, come citato sopra, è di dare ai vari pannelli di controllo la possibilità di cambiare i setting di sistema senza necessariamente disturbare l’utente.
L’idea della whitelist non è una grandissima novità in quanto anche su Unix esiste un meccanismo simile preso in considerazione anche prima del rilascio di Vista; pero tale meccanismo ha un punto debole che nell’ecosistema Windows non è sostenibile: qualsiasi amministratore può aggiungere/rimuovere applicazioni dalla whitelist. Nel passaggio tra XP a Vista il meccanismo sarebbe stato ampiamente abusato da tutti i produttori di applicazioni pigri (e quindi tutti) che tra rendere l’applicazione capace di girare senza permessi di amministratore e settare un flag sull’eseguibile avrebbero scelto la seconda senza pensarci due volte considerando che l’installer gira sempre con permessi amministrativi. L’idea è stata perciò accantonata con Vista e ripresa con Seven usando un espediente semplice e geniale: la whitelist è sigillata con una firma digitale e quindi non è manipolabile in nessun modo.
La whitelist rilasciata con la beta è ben lungi da essere perfetta ma tra le tante applet quella che ha dato più nell’occhio è stata l’applet che gestisce i setting UAC. Siccome l’applet esegue un’auto-elevazione senza altre misure di protezione è stato possibile scrivere uno script che emula la pressione di alcuni tasti in sequenza e disabilitare UAC automaticamente. Rafael Rivera ha pubblicato un post a riguardo che è rimbalzato in tutta la blogosfera catturando una notevole attenzione mediatica; Rafael e tanti altri proponevano di rimuovere l’applet UAC dalla whitelist ed in tal modo qualsiasi tentativo di cambiare il setting UAC dall’esterno avrebbe richiesto un ulteriore prompt mettendo in guardia l’utente. Però come in un dialogo tra muti e sordi la risposta ufficiale ‘by design’ è suonata un pochino stonata. Il ping pong tra Jon DeVaan e i vari blogger ha assunto connotati surreali fino a quando una nota di ‘retromarcia’ è apparsa sul blog Engineering Windows 7 portando finalmente giubilo, pace e serenità. Se si legge tra le righe si comprende bene qual’era il vero problema e la giusta soluzione: il problema non stava nel fatto che cambiare i setting di UAC non richiedesse nessun prompt ma che l’applet fosse pilotabile da altre applicazioni; individuato il problema (la pilotabilità) la soluzione è diventata ovvia: anziché usare il secure desktop basta aumentare il livello di integrità in cui l’applet gira per impedire che riceva messaggi dalle applicazioni desktop che girano sotto l’utenza normale. Basterebbe questo per risolvere il problema e rimuovere UAC dalla whitelist non diventa più necessario; quest’ultima cosa è stata comunque fatta più per motivi psicologici (su cui concordo pienamente!) che per necessità contingenti.
La cosa più buffa di tutta la questione è stato vedere gente che non sa neanche cos’è un security boundary sostenere con forza l’una o l’altra posizione o elargire consigli a destra e a manca.
C’est la vie
Linkografia a futura memoria:
Windows 7 auto-elevation mistake lets malware elevate freely, easily
List of Windows 7 (beta build 7000) auto-elevated binaries
Second Windows 7 beta UAC security flaw- malware can silently self-elevate with default UAC policy
Update on UAC
Is UAC broken in Windows 7 beta-
Microsoft’s worst nightmare- Windows 7 deemed less secure than Vista
Permanent Link to UAC in 7- Exponential Silent Attack Vector Multiplier
UAC Feedback and Follow-Up
Users prevail- Microsoft changes Windows 7 UAC control panel behavior to address security flaw
Microsoft backtracks on Windows 7 UAC, pretends it was all part of the plan
-quack
P.S. il mio consiglio: se non usate un antivirus, lasciate pure i setting di default di Windows 7 Beta, siete abbastanza accorti da evitare di far girare certa robaccia sul PC. Se usate un antivirus…. è uguale! 
Pagina Successiva »
