Windows 7-vecchio thread ufficiale-Read Only, per scrivere usare il nuovo

  • Autore discussione Autore discussione dovella
  • Data d'inizio Data d'inizio
Pubblicità
Stato
Discussione chiusa ad ulteriori risposte.
Già con Valentine il source repository usato internamente era un gran bel prodotto, ma non era integrato con l'IDE e andava usato da command line o creando .bat da lanciare all'interno dell'IDE.
Se penso che all'epoca MS vendeva Source Safe... è un pò come se la mercedes usasse le sue auto solo per uso interno e vendesse le trabant :lol:

Comunque a parte gli strumenti usati, Sinofsky ha stravolto le metodologie di lavoro, e ha costretto i vari team a seguire delle procedure estremamente rigorose per lo sviluppo in modo che di fatto tutte le build di Windows 7, persino le alpha, erano usabili, al contrario Vista ad un certo punto dello sviluppo (dopo circa 2 anni) non riuscivano più nemmeno a compilarlo.

Windows 7 non è ancora uscito, ma di certo alcune persone stanno già lavorando a Windows 8, e considerato l'eccellente lavoro svolto con Windows 7 mi chiedo se continueranno sulla stessa strada (ovvero evolvere senza stravolgere) o se correranno il rischio di fare un'altra volta il passo più lungo della gamba (come è avvenuto con Vista nei primi due anni di sviluppo).
Io credo che Windows 7 per quanto ottimo sia ancora ampiamente migliorabile senza bisogno di stravolgere tutto.
Alcune aree di miglioramento:
- ulteriore astrazione dall'hardware e ulteriore miglioramento della virtualizzazione
- eliminazione dell'uso di GDI/GDI+ (che resterebbe per compatibilità ma che non verrebbe più usato da componenti di sistema come Windows Explorer)
- ulteriore modularità di tutto quello che c'è oltre al kernel per rendere davvero Windows scalabile dal cellulare al super computer
- rendere la trasferibilità degli account da una macchina all'altra un processo che richiede un click
- adottare .Net in modo pervasivo all'interno del sistema, ad oggi è davvero ancora poco usato dalla stessa MS, e fino a quando non diventerà realmente la piattaforma usata da tutto il software MS non sarà mai davvero maturo (per quanto già ottimo, ma le possibilità di migliormamento sono ancora tante).
- ancor più che un nuovo filesystem (di cui sinceramente non sento particolarmente il bisogno) quello che serve è di cambiare la rappresentazione che si fa. Le libraries sono un piccolo primo passo, la cartella Games un'altro, ma c'e' tanto da fare in quella direzione, io speravo che già in Windows 7 avremmo trovato un nuovo modo di "vedere" le applicazioni installate, ma purtroppo hanno solo fatto qualche timido tentativo che è rimasto nelle build di laboratorio e non è mai arrivato nella main build. Spero che in Windows 8 questa diventi una priorità e l'integrazione tra search e explorer sia tale da fornire una nuova modalità di accesso ai dati e alle applicazioni.
 
Windows 2000 :inchino::inchino:

Un sistema che, piaccia o meno, ancora oggi mostra la sua bontà. Prima di 7, per me è il migliore sistema operativo fatto da MS. Certo, anche 2000 ebbe bisogno dei suoi Service Pack, ma rimane nel complesso uno dei migliori OS di Redmond. Il figlio (XP) non è venuto altrettanto benissimo, dal SP2 se ne può parlare bene. Ma si può dire che sia proprio la gestione Allchin che sia stata un po' difficoltosa, XP e Vista. Anzi, Vista è venuto abbastanza bene, nonostante i casini del team. Le basi sono venute sicure, e ora 7 le sta rendendo anche prestanti.

Anch'io trovo che Windows possa essere ancora migliorato. E, tanto per rimanere pedanti su questa linea :D , perché non andare su Midori? A quanto pare c'è stata l'assunzione di Jonathan Shapiro, uno che ha esperienza nell'ambito di questi nuovi sistemi operativi microkernel. Inoltre, da quanto leggo, il multicore è una priorità in casa MS, e stanno facendo veramente "razzia" di ingegneri (sembra ne sia arrivato uno dalla divisione SPARC di Sun, ed è anche, a quanto pare, un pezzo grosso). Indubbiamente, nel futuro, vedremo un sistema più adattabile ai diversi device. Io non mi stupirei se nei laboratori avessero versioni di Windows, o Midori con l'aspetto di Windows, girare tranquillamente su ARM... :evil:
 
@Enrico G.

Non ti dimenticare che la tabella di marcia è stata altrettanto rigida.
quindi..

PS
dimenticavo.

Gia Windows 7 parte dall Embadded fino a 250 CPu
 
- ulteriore modularità di tutto quello che c'è oltre al kernel per rendere davvero Windows scalabile dal cellulare al super computer
- rendere la trasferibilità degli account da una macchina all'altra un processo che richiede un click
- adottare .Net in modo pervasivo all'interno del sistema, ad oggi è davvero ancora poco usato dalla stessa MS, e fino a quando non diventerà realmente la piattaforma usata da tutto il software MS non sarà mai davvero maturo (per quanto già ottimo, ma le possibilità di migliormamento sono ancora tante).

Beh, io penso che rendere ancora più modulare il kernel porterebbe ad un vero microkernel e non credo sia poi così immediata la cosa:sisi:.

Sul .net...beh, lo trovo una piattaforma fantastica in quanto a funzionalità e librerie. Librerie quali la Linq fanno veramente paura per quanto sono potenti.
Ma forse non è meglio tentare di mantenere in C o comunque linguaggi di livello più basso finché si riesce?
In fondo un blocco note scritto in C# sicuramente non influirebbe sulle prestazioni, ma non vorrei si sfruttasse troppo la potenza delle attuali macchine lasciando da parte l'ottimizzazione del codice.
 
Beh, io penso che rendere ancora più modulare il kernel porterebbe ad un vero microkernel e non credo sia poi così immediata la cosa:sisi:.

Sul .net...beh, lo trovo una piattaforma fantastica in quanto a funzionalità e librerie. Librerie quali la Linq fanno veramente paura per quanto sono potenti.
Ma forse non è meglio tentare di mantenere in C o comunque linguaggi di livello più basso finché si riesce?
In fondo un blocco note scritto in C# sicuramente non influirebbe sulle prestazioni, ma non vorrei si sfruttasse troppo la potenza delle attuali macchine lasciando da parte l'ottimizzazione del codice.

Il microkernel ce li hanno, Singularity e Midori. Anche Azure probabilmente è un microkernel.

Sulla questione .NET, credo tu abbia ragione. Mi spiego: con Longhorn tentarono di convertire Windows Explorer in una applicazione .NET. Il risultato fu un gran pasticcio (memory leak, crash) che li convinse nel reset a non ritentarci. Io sarei pure favorevole ad una conversione in .NET, ma se può dare più problemi che benefici in certi casi, è meglio di no.
 
Il microkernel ce li hanno, Singularity e Midori. Anche Azure probabilmente è un microkernel.

Sulla questione .NET, credo tu abbia ragione. Mi spiego: con Longhorn tentarono di convertire Windows Explorer in una applicazione .NET. Il risultato fu un gran pasticcio (memory leak, crash) che li convinse nel reset a non ritentarci. Io sarei pure favorevole ad una conversione in .NET, ma se può dare più problemi che benefici in certi casi, è meglio di no.

Beh, il garbage collector di .net funziona bene ed è quasi impossibile che i programmi .net diano errori quali l' overflow che può mettere a rischio il sistema.

Ok, ma midori ha un vero microkernel o è anch'esso un ibrido?
Se non sbaglio sono rimasti ad NT per mantenere la compatibilità software...quindi prevede un cambiamento drastico su api e architettura del sistema.
 
Beh, il garbage collector di .net funziona bene ed è quasi impossibile che i programmi .net diano errori quali l' overflow che può mettere a rischio il sistema.

Ok, ma midori ha un vero microkernel o è anch'esso un ibrido?
Se non sbaglio sono rimasti ad NT per mantenere la compatibilità software...quindi prevede un cambiamento drastico su api e architettura del sistema.

Errori da mettere a rischio il sistema no, ma funzionava male. Difatti non ci hanno ritentato oltre.

Midori sarebbe intesa come l'emanazione futura commerciale di Singularity, e Singularity è un microkernel, in managed code, Sing# (derivato da Spec#, a sua volta derivato dal C#). Niente ibrido, dunque. Cmq è naturale (l'ho detto anche più volte sul thread di ReactOS) aspettarsi prima una efficace modalità di compatibilità, altrimenti proseguiranno con NT, onde evitare di farsi mangiare dalla loro vecchia creatura.
 
Errori da mettere a rischio il sistema no, ma funzionava male. Difatti non ci hanno ritentato oltre.

Midori sarebbe intesa come l'emanazione futura commerciale di Singularity, e Singularity è un microkernel, in managed code, Sing# (derivato da Spec#, a sua volta derivato dal C#). Niente ibrido, dunque. Cmq è naturale (l'ho detto anche più volte sul thread di ReactOS) aspettarsi prima una efficace modalità di compatibilità, altrimenti proseguiranno con NT, onde evitare di farsi mangiare dalla loro vecchia creatura.

Io credo che a MS ci siano molte delle più grandi menti informatiche del pianeta...i fondi non mancano io porterei sul mercato un nuovo prodotto parallelo a NT con tutte le nuove tecnologie che hanno implementato e fanposteriore la compatibilità.
Spero che 7 mi sorprenda nella release finale, vedremo che sono riusciti a combinare:)
 
Beh, io penso che rendere ancora più modulare il kernel porterebbe ad un vero microkernel e non credo sia poi così immediata la cosa:sisi:.
Il kernel è già piuttosto piccolo e modulare, io dicevo di rendere ancora più modulare tutto quello che non è kernel. Rispetto a Vista hanno ridotto le dipendenze tra moduli, ma sono sicuro che possono migliorare ancora.
Ad esempio Windows Server 2008 c'è in versione Core che non ha proprio il Window Manager, ecco quello è un esempio di modularità di componenti che stanno fuori dal kernel.

.Net: crash, memory leak etc. sono invece la cosa che si elimina passando dal C/C++ standard a .Net.
Inoltre se tutte le componenti di Windows venissero scritte in .Net si avrebbe un testing davvero importante all'interno di MS. Fino a che una tecnologia non viene adottata internamente non raggiungerà mai il massimo possibile della qualità e delle performance.

Per quanto riguarda le prestazioni: è un falso mito che usando .Net si abbia un degrado, in quanto per sua natura il framework può fare ottimizzazioni al runtime impossibili per un compilatore C/C++. L'esempio più semplice che mi viene in mente è la sostituzione inline di funzioni di librerie esterne. Ma di altre ottimizzazioni più significative ce ne sono tante. Basterebbe pensare alle performance ottenute da Phyton.Net già alla sua prima implementazione, a sentire "gli esperti" della comunità open source sarebbe stato un fiasco, invece hanno tutti dovuto rimangiarsi il veleno che avevano sputato su .Net.
La potenzialità è enorme e il fatto che si possano mischiare parti di codice di linguaggi procedurali come il C# e di linguaggi funzionali come F#, apre le porte a soluzioni molto interessanti.
Chi conosce e ama il Lisp sa a cosa mi riferisco. L'idea di poter integrare nel sistema operativo parti di codice funzionale in modo del tutto indolore e avendo a disposizione tutte le librerie di sistema è qualcosa di impagabile.
 
Il kernel è già piuttosto piccolo e modulare, io dicevo di rendere ancora più modulare tutto quello che non è kernel. Rispetto a Vista hanno ridotto le dipendenze tra moduli, ma sono sicuro che possono migliorare ancora.
Ad esempio Windows Server 2008 c'è in versione Core che non ha proprio il Window Manager, ecco quello è un esempio di modularità di componenti che stanno fuori dal kernel.

La cosa rischia di essere troppo simile a linux:D...in questo caso sì, la modularità servirebbe.
Non ho mai visto dei Windows server all'opera, ma se si intende rendere tutto così modulare, bisogna anche dare una rispolverata alla linea di comando che per ora non essendo protagonista in Windows non è un granché
 
La cosa rischia di essere troppo simile a linux:D...in questo caso sì, la modularità servirebbe.
Non ho mai visto dei Windows server all'opera, ma se si intende rendere tutto così modulare, bisogna anche dare una rispolverata alla linea di comando che per ora non essendo protagonista in Windows non è un granché
Linux ha però il suo tallone d'achille nel kernel, essendo monolitico male si adatta ai cambiamenti di hardware. Basta vedere le prestazioni delle più note distribuzioni sui netbook. Fino a quando non esce l'aggiornamento del kernel non c'è molto da fare. In Windows invece basta riscrivere i driver e sei a posto.
Non è un caso che sui portatili la durata della batteria sia quasi sempre peggiore con Linux che con Windows.

Comunque tornando in topic: Windows Server appena installato è praticamente all'asso, poi l'amministratore può scegliere i vari moduli da attivare.
Non dico che Windows in versione client sui PC debba essere così, mi va bene che di default abbia le cose più diffuse già attive, ma servirebbe per poter creare più facilmente le versioni per cellulari, palmari, netbook e via dicendo.
Per quanto riguarda la linea di comando PowerShell è avanti a qualunque shell unix.
 
Linux ha però il suo tallone d'achille nel kernel, essendo monolitico male si adatta ai cambiamenti di hardware. Basta vedere le prestazioni delle più note distribuzioni sui netbook. Fino a quando non esce l'aggiornamento del kernel non c'è molto da fare. In Windows invece basta riscrivere i driver e sei a posto.
Non è un caso che sui portatili la durata della batteria sia quasi sempre peggiore con Linux che con Windows.

Comunque tornando in topic: Windows Server appena installato è praticamente all'asso, poi l'amministratore può scegliere i vari moduli da attivare.
Non dico che Windows in versione client sui PC debba essere così, mi va bene che di default abbia le cose più diffuse già attive, ma servirebbe per poter creare più facilmente le versioni per cellulari, palmari, netbook e via dicendo.
Per quanto riguarda la linea di comando PowerShell è avanti a qualunque shell unix.

Beh il kernel linux è comunque ricompilabile a piacere, il suo tallone è essere monilitico ma per ora non è un problema...gira persino sugli ipod prima generazione.

PowerShell l'ho usata (e devi ammettere che ricalca molto lo stile delle Shell linux) ma è lenta e comunque meno potente di shell quali la bash.
Tra l'altro non mi va giù il fatto che non sia key sensitive.

Da Wiki:
Alcune delle funzionalità delle shell dei sistemi Unix sono state riprese in varia misura anche dalle shell testuali per i sistemi Microsoft Windows, tuttavia esistono prodotti che offrono un ambiente Unix-like (e le relative shell) per tali sistemi, come ad esempio quello del progetto Cygwin, o anche Microsoft Windows Services for UNIX[1] o ancora lo MKS Toolkit.[2]

Interessante la storia di Windows Server, non la sapevo.
Thanks
 
Beh il kernel linux è comunque ricompilabile a piacere, il suo tallone è essere monilitico ma per ora non è un problema...gira persino sugli ipod prima generazione.
Ma non è pratico. Se sono la signora Sony e faccio un nuovo netbook mi devo ricompilare il kernel per quello specifico modello... sai i costi di gestire una cosa del genere, e poi se l'utente vuole mettersi un'altra distribuzione siamo punto e a capo.
Windows potrà non piacere, ma se oggi XP gira ancora sul 60% dei PC al mondo è grazie al fatto che non hai bisogno di ricompilare il kernel. Voglio vedere se c'è qualcuno che oggi usa ancora qualche distribuzione del 2001 su hardware recente.

PowerShell l'ho usata (e devi ammettere che ricalca molto lo stile delle Shell linux) ma è lenta e comunque meno potente di shell quali la bash.
Se vuoi la bash su Windows non c'è problema, io la usavo nel 1998 quando mi avvicinai a Windows e avevo bisogno di sentirmi a casa :)
PowerShell è più "potente" delle shell di unix perché quelle hanno la pipeline testuale, mentre la PS ha pipeline ad oggetti.
 
Stato
Discussione chiusa ad ulteriori risposte.
Pubblicità
Pubblicità
Indietro
Top