Predator ha detto:
Interfaccia:
Win: L'interfaccia grafica estremamente user friendly, ed esteticamente molto curata.
Linux: L'interfaccia grafica molto user friendly, permette effetti stile "aero" anche con schede grafiche piccole
Risultato: Le interfacce sono molto simili, anche se ad un primo impatto quella di windows rimane piu' intuitiva rispetto linux
In genere preferisco sempre parlare di funzionalitàe use-case, non di interfacce e semplicitàd'uso, che dovrebbero essere giusto l'elemento veramente terminale nel giudicare un sistema operativo...
In ogni caso, la strategia vincente di Linux, e della maggior parte dei sistemi Unix-like, è stata quella di mantenere un gestore dell'interfaccia grafica separato dal kernel.
Credo che la progettazione del kernel Linux sia lo stato dell'arte attuale nella progettazione di un kernel, checché Tanembaum ne dicesse a suo tempo (1992) in "Linux is obsolete". La storia ha dato ragione alla gestione monolitica nella progettazione di un kernel, e MINIX e i vari minikernel annessi e connessi sono rimasti sempre e solo in ambito accademico. Un minikernel è modulare, figo, teoricamente perfetto, ok, ma il costo di una progettazione modulare con le varie componenti che interagiscono solo per cooperazione si paga nei tempi di comunicazione fra le varie componenti, nella gestione di ulteriori primitive di sincronizzazione e nella lentezza conseguente che ne viene fuori, che rende l'approccio minikernel-oriented inadatto a un'utenza domestica o a esigenze sia da workstation, sia da server (mentre può ancora andar bene per sistemi embedded con kernel ridotti all'osso).
Ora, nel corso degli anni Linux ha trovato, pur nel suo essere "monolitico", l'approccio ottimale e la scelta vincente. Mantenere un kernel monolitic, con scheduling della CPU e dell'I/O, gestione del filesystem, della memoria, segmentazione e paginazione, gestione del layer di rete ecc. tutte inglobate in questo bell'oggetto monolitico. E mantenere invece tutti i servizi end-user (interfaccia grafica, riga di comando, interfaccia audio, gestione della stampa ecc.) separate, e comunicanti con il kernel o attraverso un meccanismo client-server o attraverso dispositivi virtuali. E integrare anche il supporto per le diverse features o periferiche/chipset hardware come moduli, da configurare e caricare come si vuole, quando si vuole, se si vuole.
Ecco, i sistemi Unix-oriented in queste cose sono ancora 1000 anni luce avanti rispetto a Windows. Windows è un kernel monolitico e a scatola chiusa, dove ti tieni il sistema così com'è, con gestore di interfaccia grafica, audio, stampa e quant'altro tutto integrato nel kernel. E se non va un componente, non va tutto il resto del sistema. E se vuoi personalizzare un componente, non puoi, perché il kernel è una scatola chiusa. E i motivi di questa scelta poi si pagano tutti, e tutti in vantaggio dei sistemi Unix. Perché i sistemi Unix avranno il server X per gestire l'interfaccia grafica, completamente trasparente rispetto al kernel e completamente configurabile dall'utente (quindi il più smanettone potràusare direttamente la tty, senza nessun ambiente grafico, anche per l'uso quotidiano, magari con screen, mentre il più niubbo potràinstallarsi KDE o Gnome semplificati al massimo, da far invidia alla stessa interfaccia Windows). Cosa non possibile in ambiente Windows, dato che l'interfaccia è tutta integrata nel kernel, e se non va quello non va tutto il resto, e ti tieni quella così com'è con scarse possibilitàdi configurazione.
Sulla progettazione - CON CRITERIO - del kernel e sull'interfaccia grafica direi quindi che i sistemi Unix vincono a man bassa.
File Sistem:
Windows: legge e scrive Fat, Fat32, NTFS
Linux:Ext2, Ext3, ecc... (non lo so)
Risultato: Windows puo' leggere partizioni linux con software di terze parti, linux invece puo' leggere e scrivere NTFS nativamente (se è vero, non lo so sto sparando a caso)
Windows può supportare Ext* con driver di terze parti. Dal kernel 2.6.qualcosa invece Linux supporta nativamente NTFS in lettura, e in scrittura usando FUSE+ntfs-3g (e ovviamente supporta FAT* da sempre). Ma non è tanto il discorso sui filesystem supportati che andrebbe fatto, dato che ormai volendo, con i moduli giusti, qualsiasi sistema operativo può supportare, più o meno in rw, qualsiasi filesystem. Il discorso che andrebbe fatto è su qual è l'approccio ottimale nativo per la gestione del filesystem. E anche qui, i sistemi Unix-based stravincono a mio parere. FAT* prima ed NTFS poi sono filesystem che gestiscono i cluster su disco come una lista connessa non ordinata, e questo produce un livello di frammentazione esterna non indifferente (ed ecco che periodicamente ci sarebbe la deframmentazione...). Ext*, e a maggior ragione ReiserFS, hanno invece sempre preferito la strategia dell'allocazione contigua, ed ecco che il livello di frammentazione esterna è praticamente nullo. Poi FAT* e NTFS sono filesystem che non distinguono fra file grandi e file piccoli, quindi si arriva talvolta all'anomalia di una tabella per la descrizione di cluster più grande del file stesso che è contenuto al suo interno, mentre ReiserFS rimane un filesystem ottimizzato anche per i file di piccole dimensioni. Altra cosa, FAT* e NTFS hanno una gestione molto primitiva delle transazioni su disco (o meglio, NTFS ce l'ha ma molto primitiva, FAT* non ce l'ha proprio), e questo rende indispensabile il controllo di ogni singolo cluster su disco in caso di inconsistenze (caro vecchio scandisk). ReiserFS invece ha un approccio completamente transaction-oriented sul modello dei database relazionali, e in caso di inconsistenze riprende dal proprio log interno le transazioni non portate a compimento e può decidere se farne il rollback, il commit o il replay, a seconda di quale azione porta il filesystem ad uno stato di coerenza maggiore.
Consumi:
Risultato: in un portatile con entrambe i sistemi operativi installati, dove windows ha una autonomia di 1 ora e 30, linux dura 2 ore.
Qui il tutto dipende dall'uso...volendo sullo stesso portatile posso usare Windows Vista per scrivere con Notepad o Linux con Compiz configurato con il massimo degli effetti e contemporaneamente giocare a Nexuiz, e nel secondo caso avrò una durata della batteria molto più ridotta...
Però i consumi dipendono fortemente dalle operazioni compiute dal sistema operativo in stato idle. Se in stato idle il sistema deve comunque gestire un'interfaccia grafica non proprio leggera come Aero, con tutto il costo che ciò comporta in fatto di occupazione della memoria centrale e risorse di calcolo sfruttate della CPU, in cicli potenzialmente idle, è normale che i consumi crescono, rispetto a un sistema che in stato idle dovràsolo gestire la riga di comando e un paio di demoni in esecuzione...
Driver:
Windows: esistono driver per qualsiasi periferica
Linux: compre tantissime periferiche
Risultato: Windows ricopre una piu' vasta gamma di hardware rispetto linux
Questo è dovuto ai produttori hardware che spesso si rifiutano di testare i loro prodotti su sistemi Unix, e spesso i programmatori open source devono fare lavori di reverse engineering ai limiti del disumano per scrivere driver per quel determinato componente hardware...
Ma è anche vero che l'hardware in ambiente Windows ha un'etàmolto minore. E giàc'è gente che ha computer con hardware vecchio di 5-6 anni al massimo che fa fatica a far funzionare quell'hardware con Vista (stesso discorso delle politiche di mercato subdole e ripugnanti di Microsoft: non supporto più il tuo hardware, tu sei costretto ad acquistare nuovo hardware). Linux invece volendo supporta ancora, se configurato il supporto nel kernel, I/O su schede perforate, supporto per hardware AMIGA o ATARI, & so on.
Periferiche:
Windows: la facilitàdi installazione è notevole, solitamente seguita da modalitàdi autoinstallazione
Linux: non sempre è facile installare nuove periferiche hardware su un sistema giàconsolidato (pessima esperienza personale con la scheda video)
Risultato: Windows è maggiormente gestibile con l'hardware
Anche in questo caso, supporto hardware != facilitàdi installare e configurare hardware.
Le caratteristiche end-user sono le cose da considerare di meno nell'efficienza di un sistema operativo, proprio perché sono solo lo strato più elevato della "cipolla" del sistema operativo che c'è sotto. E in ogni caso, con le mie schede nVidia non ho mai avuto problemi, basta scaricare il .sh ufficialmente supportato dalla nVidia dal sito ufficiale e fare una procedura che non si discosta molto dal classico Avanti -> Avanti -> Fine windowsiano per la compilazione del modulo e la configurazione di xorg.conf. Per le ATI è un altro discorso (ma più per colpa dello scarso supporto ATI che per i programmatori open source fannulloni), ma anche lì di progressi se ne sono fatti e ora il supporto per schede ATI è paragonabile a quello per schede nVidia.
Sicurezza:
Windows: è una piattaforma bersagliata da virus e spyware
Linux: la presenza di virus e spyware è quasi nulla
Risultato: linux risulta piu' sicuro in quanto non vengono sviluppati maleware e la struttura stessa dell'OS ne rende difficile l'intrusione
Più che la struttura dell'OS, è la politica di gestione dell'utenza di default dell'OS. Ricordo che 7 anni fa quando provavo a fare il login grafico su una Mandrake 8.0 come root mi comparivano mille warning e checkbox che mi chiedevano se fossi proprio sicuro di quello che stavo facendo, e una poco invitante schermata con sfondo rosso per sottolineare la pericolositàdi quella scelta. I sistemi Windows invece fino a ieri l'altro prevedevano senza problemi che l'utente quotidiano fosse di default anche amministratore del sistema, e questa scelta è stata la responsabile del 90% del malware in giro.
http://gtfo.org/
