I governi guardano dentro Windows

Re: le differenze sono due...
Dopotutto il Dos non e' una brutta copia di Unix?

Re: Buonasera! Io da mo' che l'ho fatto.
- Scritto da: Anonimo
Qui si tratta di
fare raffronti a livello di codie e posso
dirti che non è la stessa cosa (come non lo
è a livello prestazionale).Non tanto: stando a questo articolohttp://wwwww-106.ibm.com/developerworks/linux/library/l-rt7/w-106.ibm.com/developerworks/linux/library/l-rt7 Linux è più veloce di Windows XP soltanto del 66% nel creare thread e del 100% nel creare processi.
Il codice di Linux è ottimizzato 486 è un
po' pochinoIl kernel viene compilato e distribuito per moltearchitetture, compresa i686 e athlon.
il kernel si pianta (nel senso
che si ferma) ad ogni I/O, anche con la 2.5
le istruzioni di I/O non perdono ancora
sulla prelazione del kernel.Non è esatto che si fermi ad ogni I/O, neppure MSDOS lofaceva: se vuoi dire che un processo in modalità utente che passa da "in attesa" a "pronto" non va in esecuzione se un altro processo è in esecuzione in modalità kernel fino a che quest'ultimo non torna dalla system call, ciò è esatto fatte salve le situazioni, quali RedHat 9, che anticipano la kernel preemption patch. Come altri hanno fatto notare, fare altrimenti riduce la latenza ma anche il throughput.
Se devi fare
qualcosa di real time ti serve un sacco di
ram e devi disabilitare lo swap.Esatto, ed è una buona politica comunque: un sistema real-time alloca più risorse per ottenere la garanzia di avere risposte in tempi certi. Per Windows il real-time ha un problema più fondamentale: dato che il processo in foreground ha un boost di priorità se l'utente fa qualcosa, prima che a disabilitare lo swap bisogna impedirgli di agitare il mouse ...
Linux usa
ancora i processi (che sono lentissimi) per
un non so quale puntiglio nel non usare i
thread (fortunatamente il trend sta
cambiando ma sono poche le applicazioni che
usano i thread piuttosto che fare una fork).I processi sono effettivamente lentissimi su Windows rispetto ai thread, mentre su Linux la differenza è più limitata: il tempo di context switching tra processi ai tempi del 2.1 era circa il doppio del context switching tra thread. In compenso, è assai più facile introdurre bachi con il multithreading che con processi separati, in particolare corse critiche e mancate sincronizzazioni nell'accesso a dati condivisi. Nelle FAQ suggeriscono che nel 90% dei casi conviene adoperare uno o più processi: se le performance sono insoddisfacenti e il profiling (non la propria personale opinione) mostrano che il problema è l'overhead di context switching allora si è nel 10% dei casi in cui sono da preferire i thread. I processi sono indispensabili, inoltre, tutte le volte che c'è un client, un server e il server non si fida del client: un thread non può impedire ad un altro di leggere e scrivere la propria area di memoria.
Poi vogliamo parlare del process switching
fatto tutto in software quando ormai le CPU
permettono di farlo completamente in HW?Vero, ma la differenza non è grande:http://lwn.net/1998/0924/a/lc-context.html
lentezza cronica dei WM che utilizzano i
socket per funzionare (e questo li manterrà
sempre centinaia di volte più lenti di un WM
integrato nel kernel, non a caso questi
ultimi costano migliaia di dollari, sono
closed e col cacchio che li cedono per una
manciata di noccioline)I socket AF_UNIX non sono particolarmente lenti, anzi: sono probabilmente il meccanismo di IPC con il miglior rapporto tra performance e funzionalità. Integrare un WM nel kernel è inappropriato: il kernel deve essere quanto più semplice possibile perchè deve essere affidabile e sicuro, mentre le interfacce grafiche richiedono parecchio codice.
la mancanza di una
standard GUI sia a livello di programmazione
(aiuterebbe tantissimo a rendere "native"
per un determinato WM applicazioni scritte
per un altro)Una API indipendente dal WM e dal desktop sarebbe effettivamente una cosa utile (di alto livello: Xlib è indipendente dai suddetti, ma lo scopo è semplificarsi la vita non riscrivere un toolkit).
sia a livello di utenza (vabbé
ma tanto stanno diventando tutti cloni di
windows quando è che impedirete a kde di
usare konqueror perché integrato nel
sistema? o a Gnome Nautilus?E che vantaggio si dovrebbe trarre dall'impedirlo ?
Sono cose che
alla lunga si pagano. Come pure la
dipendenza da una distro che rende
impossibile aggiornamenti manuali con
pacchetti standard o sorgenti ma che ti
vincola ai propri.La maggior parte delle distribuzioni usa i pacchetti a ragion veduta: semplificano l'amministrazione del sistema. Chi aggiorna da sorgente si documenti su come farlo salvaguardando i vantaggi della gestione a pacchetti, ovvero facendo i propri pacchetti.
Senza contare gli scempi
che fanno al kernel per rendere le patch
generiche inapplicabili.Quando una patch dà conflitti, non c'è che studiarseli e risolverli uno per uno oppure, come da altri suggerito, rimuovere la patch originale nel caso offra funzionalità che non interessano. Quando una patch imposta qualcosa a 0e un'altra la imposta a 1, una delle due è inapplicabile.