Si sente spesso “insultare” Linux in questo modo:
È un sistema operativo che usa ancora un kernel monolitico degli anni ’70
Farà piacere sapere a chi afferma questo con lo scopo di denigrare Linux che Windows ha un kernel monolitico, e anzi.. “più” monolitico di Linux.. (anche se lo chiamano Kernel Ibrido)
E ora vi spiego anche perché..
Iniziamo a capire cos’è un kernel..
Versione 1.1 – 2010/01/04
- Spiegato dove trovare il kernel Linux e i suoi moduli
- Separato sezione Kernel Linux da Kernel Windows
- Spiegato meglio le differenze tra microkernel e kernel monolitico
- Aggiunte informazioni sul WDDM di microsoft prendendo direttamente dalla documentazione microsoft
- Aggiornamento a Windows Seven
- Un po’ di chiarimenti per i sistemi multiprocessori nell’introduzione sui kernel
Kernel
Prima di tutto: Linux È il kernel, dire “Kernel di Linux” non è corretto.. perché il kernel non è parte di Linux, Linux è un kernel! 😀
Windows invece è l’insieme di software forniti con un dvd/computer, tra cui il kernel di windows.
il kernel (nucleo) è un programma che si occupa di dare le funzionalità di base per l’utilizzo di un computer come:
- gestione della CPU (o processore), che è quell’hardware che esegue effettivamente i programmi (o dei processori in caso di multi-processore/multi-core)
- gestione della memoria (RAM e non solo), nella quale vengono caricati i dati su cui si lavora, compresi i programmi stessi (un programma viene caricato in RAM prima di poter essere eseguito)
- gestione della comunicazione con le periferiche ( I/O – Input/Output)
- può fornire il multi-tasking: a voi sembra che più programmi funzionino contemporaneamente, in realtà è un illusione creata grazie alla velocità di esecuzione del processore, si esegue un pezzo di ogni programma per volta, ma sempre uno alla volta (a meno di non avere sistemi a più processori, come i nuovi Dual Core / Quad Core e dei programmi scritti per sfruttare questi sistemi)
- schedulazione dei processi: decide in che ordine e “quanto” allocare il processore (o i processori) ai singoli programmi (processi) attivi.
- In caso di sistemi multi-processore / multi-core ne coordina l’operato e la distribuzione del calcolo
- crea lo spazio degli indirizzi che le applicazioni sovrastanti possono utilizzare (qui si crea il limite dei 4 GB di RAM nei kernel Windows ad esempio, in Linux questo limite è 64GB )
- fornire dei modi per far comunicare i programmi
- meccanismi di sicurezza
- una serie di servizi.. ( system calls – chiamate di sistema )
Il Kernel è il sistema operativo, anche se siamo abituati a concepirlo come “un insieme di programmi”. In windows anche l’interfaccia grafica fa parte del Kernel, in Linux invece è un programma “utente” che gira sopra il kernel.
I servizi messi a disposizione dal server non sono in genere orientati agli utenti, non direttamente almeno. Sono orientati ai programmi: ad esempio ci sarà un servizio che permette di preparare l’esecuzione di un programma, uno che permette di scrivere sulla memoria.. e così via.. In windows anche tutto il server grafico (come già detto) è composto da servizi, tutti forniti dal Kernel del sistema.
Ma se il Kernel è un programma.. cos’ha di diverso dagli altri programmi?
È molto semplice: è molto più difficile programmare un kernel perché si utilizza direttamente l’hardware, non esistono meccanismi di protezione e un piccolo errore può bloccare tutto il sistema.
I programmi che utilizziamo di solito girano SOPRA al kernel, in uno spazio protetto (detto user space, spazio utente). I programmi in user-space non possono scrivere in qualunque area di memoria (neppure per sbaglio) perché è il kernel che si preoccupa che questo non accada! Se un programma si blocca (auspicabilmente) il Kernel non si blocca e il sistema resta utilizzabile.
In contrapposizione non c’è nulla che controlla l’operato del Kernel e quindi, come già detto, un piccolo errore può far crashare l’intero sistema, bloccandolo e forzandoci al riavvio! Lo “spazio” senza protezioni e complesso in cui “gira” il kernel si chiama kernel-space.
In genere anche tutti i driver e l’architettura di rete funzionano in kernel space, ecco perché un driver difettoso può rendere instabile tutto il sistema (sia su windows che su Linux).
Come state iniziando a capire.. tutti i programmi che girano in kernel-space possono causare problemi di stabilità, corruzione dei dati ecc.. ecc..
Kernel Monolitico e Microkernel
Esistono sostanzialmente 2 tipologie di kernel:
- microkernel: visto che scrivere un programma in kernel space è difficile e rischioso si scrive un kernel minimale con “lo stretto indispensabile” ad utilizzare l’hardware, e quindi si scrivono tutti i servizi (chiamate di sistema) in user-space, esse comunicano direttamente con il kernel minimale, tutte le altre applicazioni in user-space possono decidere di utilizzare le chiamate di sistema o riferirsi direttamente al microkernel. L’approccio è più sicuro e semplice da programmare ma meno efficiente dal punto di vista delle prestazioni perché la comunicazione tra chiamate di sistema e kernel deve avvenire tramite uno scambio di messaggi che appesantisce tutto il sistema. I driver girano in user space.
- kernel monolitico: tutto quanto necessario ad usare il sistema e a fornirne un utilizzo ai programmi che vi girano è programmato in un unico programma (monolitico) che gira in kernel-space. I driver (solitamente) girano in kernel-space.
Alcuni sostengono che il kernel monolitico sia obsoleto e i microkernel siano superiori. L’esempio tipico in questo caso è Andy Tanenbaum, un docente di informatica americano che sostiene i microkernel definendo sorpassati i kernel monolitici (nel 92 c’è stata un’accesa conversazione tra il professore e Linux Torvalds [1]). Io qui espongo solo dei fatti, penso semplicemente che non sia tutto bianco o nero, buono o sbagliato. Il kernel monolitico ha dei pregi e il microkernel ne ha degli altri. A seconda dell’utilizzo che se ne fa (e dei kernel di un tipo e dell’altro che si trovano in circolazione) si può scegliere una delle due strade.
Nei commenti mi hanno accusati di dar dell’ignorante a Andy Tanenbaum: se leggete attentamente il mio articolo non dico mai che un kernel monolitico è meglio di un microkernel; confronto in realtà 2 kernel monolitici: Windows e Linux.
Kernel Linux
Linux è un kernel monolitico ma modulare..
mi spiego: un kernel monolitico “standard” prevede che tutto il kernel funzioni come un blocco unico, in Linux invece parti di kernel (moduli), in genere driver, possono essere inseriti nel kernel durante il suo utilizzo, e secondo le necessità.
Su una qualunque distribuzione Linux potete trovare il file contenente il kernel nella directory /boot/, il nome del file può essere qualunque ma in genere comincia con vmlinuz-; solitamente ce ne sono diversi perché all’avvio potete scegliere quale eseguire; nella stessa directory trovate anche le configurazioni dei vari kernel (che cominciano per config-): ovvero le opzioni con cui è stato compilato il kernel, com’è stato costruito.
Quasi tutta la configurazione è un elenco di moduli del kernel, per ognuno è specificato il tipo di compilazione con il kernel: fuso insieme al kernel principale, come modulo o assente.
Ciò che è compilato come modulo si trova nella directory /lib/modules/, ogni modulo per ogni kernel installato ha un suo file che può essere caricato o scaricato in qualunque momento.
Su Linux esistono alcuni driver che funzionano in User-Space
- USB
- Sistema di stampa
- FUSE (è un filesystem utilizzato per molti scopi)
Kernel Windows
Il kernel Windows è stato battezzato dalla Microsoft: Kernel Ibrido ( Hybrid Kernel )
Il motivo è che (secondo Microsoft) il kernel di windows è un “miscuglio” di microkernel e kernel monolitico, nella pratica hanno scritto un microkernel, e lo hanno fatto comunicare tramite messaggi con i restanti servizi ( server grafico compreso ) ma fanno girare il tutto in “kernel-space”
In altre parole hanno preso il peggio dei 2 sistemi ( unico vantaggio una semplicità maggiore ad implementarlo )
In più il numero di chiamate di sistema messe a disposizione dal kernel Windows è molto più alto del kernel Linux (questo è dovuto principalmente alla presenza del server grafico di windows all’interno del kernel), e più chiamate non vuol dire meglio, vuol dire più complessità.. e più possibilità di trovare problemi e bachi di sicurezza!
In XP il server grafico era totalmente integrato nel kernel, in Vista c’è stato uno sforzo per tentare di portarlo al di fuori del kernel ma il lavoro è stato svolto solo in parte e il nucleo del sistema grafico è ancora nel kernel. In Windows Seven non è cambiato molto (per quest’aspetto) riguardo il kernel e il driver grafico che è ancora in parte nel kernel.
Per gli scettici riporto qui un estratto della documentazione Microsoft [2]
“In Windows XP, display drivers, which are large and complex, can be a major source of system instability. These drivers execute entirely in kernel mode (i.e., deep in the system code) and hence a single problem in the driver will often force the entire system to reboot.
[…]
(Parlando ora di Windows Vista)At a technical level, WDDM display drivers have two components, a kernel mode driver (KMD) that is very streamlined, and a user-mode driver that does most of the intense computations. With this model, most of the code is moved out of kernel mode”
e lo traduco per i non anglofoni
“In Windows XP, i driver grafici, che sono grandi e complessi, possono essere una delle cause maggiori di instabilità del sistema. Questi driver eseguono interamente in kernel mode (cioè profondamente all’interno del codice del sistema) di conseguenza un piccolo problema nel driver causerà il più delle volte un riavvio dell’intero sistema.
[…]
(Parlando ora di Windows Vista)Ad un livello tecnico, il driver grafico WDDM ha due componenti, un driver in kernel mode (KMD) molto semplificato, e un driver in user mode che effettua i calcoli più complessi. Con questo modello gran parte del codice è spostato all’esterno del kernel mode”
E’ Microsoft stessa a confermarvi quel che vi dico in questo articolo, ancora dubbi in proposito? Se leggendo “driver grafici” avete pensato a quelli della scheda video vi correggo immediatamente: si parla dei WDDM (per Vista) e del suo predecessore in XP, che sono appunto i driver del sistema grafico di windows. In Seven WDDM è stato aggiornato ma una parte funziona ancora in kernel mode.
Corollario
Ecco perché il kernel di windows è “più” monolitico di Linux, e di conseguenza l’insulto: “Linux è obsoleto perché usa ancora un kernel monolitico” denota ignoranza, inclinazione a parlare senza prima informarsi e per sentito dire / luoghi comuni nonché un certo grado di trollaggine¹
Link di approfondimento:
Wikipedia [EN]: Kernel Monolitico
Wikipedia [EN]: Windows Display Driver Model (WDDM)
Kernel Linux ( 2.6.20 ) e Kernel di Windows (Vista) a confronto ( grazie a Debianway per il link)
Descrizione del kernel Linux [EN]
¹ trollaggine: troll è una parola che si utilizza nel gergo di internet per indicare una persona che comunica in modo provocatorio, irritante o stupido.. “trollaggine” è un derivato che ho inventato sul momento 😛
L'importante è avere un titolo 
4 settembre, 2010 at 15:39
Avrei un paio di appunti da fare (peccato solo che arrivo con “leggero ritardo”…)
@mastro: tu affermi che il kernel è stato creato 40 anni fa, il che se è inteso nell’ambito di Linux è una trollata enorme, visto e considerato che Torvalds ha scritto da zero il kernel dato che Minix (come lui stesso ha affermato) gestiva male il sistema ed era limitato, solo successivamente ha chiesto le specifiche POSIX (ed infatti Linux non è UNIX ma UNIX-Like, dato che non segue lo standard sebbene sia molto simile…), questo a differenza dei sistemi BSD che sono direttamente derivati dallo UNIX AT&T originari (vedi wikipedia alla voce FreeBSD).
Per quanto al succo dell’articolo direi non mi trovo d’accordo sul fatto di affermare che Windows utilizzi un kernel più monolitico di Linux, prendendo il presupposto che Windows integri il sistema grafico, quando Linux fa la medesima cosa con in più il fatto che i driver stessi li puoi benissimo compilare built-in al kernel, non a caso i driver di base VGA li vai proprio ad inserire così altrimenti non vedresti manco i primi messaggi durante l’avvio (vedi il supporto al framebuffer).
Infine bisogna ricordare che nel momento che tu compili un kernel, in fase di configurazione ti trovi di fronte l’intera collezione dei drivers compilabili che hai inclusi nel sorgente stesso, questo per l’appunto si definisce “monolitico” (ovvio che se tu disponi di un kernel Win che contiene ad esempio i driver ATI ti do perfettamente ragione, ma guarda caso win questi li carica al di fuori del kernel…), puoi verificare tu stesso quanto dico cercando di installare un driver proprietario ATI o nVidia su un sistema Linux dove non hai gli header del kernel in uso, dato che se mancano il codice il driver non riesce a compilarsi e quindi è ben dura che tu lo possa installare, questo perché il driver stesso si va a fondere con il sorgente principale del kernel(una sorta di patch indiretta) e quindi “apprende” come debba essere compilato, ben lontano dalla spiegazione che hai dato!
C’è anche da dire che se usi distro tipo ubuntu questi aspetti non li vedi perché il procedimento lo ha fatto qualcun’altro per te, se invece usi distro tipo gentoo dove il kernel lo compili a mano, ti accorgi perché semplicemente se non ricompili dopo il kernel i drivers aggiuntivi, semplicemente non ti funziona più Xorg (che infatti necessità generalmente la ricompilazione dei suoi driver)…
Infine… il limite di 4 Gb sulla RAM di Windows suppongo tu lo abbia preso come dato di fatto dimenticandoti palesemente che se vuoi confrontare Linux a Windows, devi prendere di quest’ultimo la versione più estesa (Server datacenter) dato che Linux in qualsiasi forma è in tutto e per tutto un datacenter se lo configuri, in questo caso Windows ti farà piacere sapere che supporta anche 2 TERABYTE di ram che è oltre 500 volte di più di quanto affermi (hai la fonte sul sito dei devel Microsoft: http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx , scorri la tabella e lo vedi), il limite imposto a cui alludi è imposto dalla casa per una questione semplicemente di mercato (se vuoi usare più ram upgradi l’os), comunque 2 Terabyte sono la stessa quantità utilizzabile da linux dato che è un limite fisico dovuto all’architettura del processore (se conosci un minimo l’assembly puoi vedere il dettaglio su http://en.wikipedia.org/wiki/MIPS_architecture )
4 settembre, 2010 at 16:43
Ciao Ghandy
innanzi tutto ti ringrazio per la tua lezione, peraltro inutile 🙂
ti informo subito che non ho mai usato Ubuntu, uso Gentoo e Debian.
Hai fatto un po’ di confusione tra driver grafici e engine per l’interfaccia grafica
un driver, come sicuramente saprai, è un modulo / software / codice che tipicamente gira in kernel mode per questioni di efficienza: il suo compito è “pilotare” l’hardware fornendo un accesso “comodo” e soprattutto standard alle applicazioni che girano sopra il sistema operativo.
Quindi se mi parli di driver ATI, nVidia, VGA, Intel: si sono driver per l’hardware e quindi si, è il caso che girino in server mode e meno male che è così, sia su windows che su linux.
Ma io non stavo parlando dei driver.
Io ho parlato dell’engine grafico.
Quel software che UTILIZZA api grafiche del kernel, intercetta l’input di mouse e tastiera per fornire un’interfaccia non testuale, grafica appunto… dire alla scheda grafica: “qui ci devi mettere un pixel giallo, qui rosso, ecc…)
Su Linux è Xorg che, diversamente da quanto tu hai detto NON richiede di ricompilare il kernel ne ha alcuna parte di codice nel kernel.
In windows (parliamo dei vecchi sistemi XP, in parte Vista, non mi sono informato su 7) il corrispettivo di Xorg è integrato nel kernel, è windows stesso che non ha un’interfaccia testuale dai tempi di Windows 95 e similari. Il prompt dei comandi è un’applicazione che gira dentro all’interfaccia grafica.
Non c’è modo di farla funzionare al di fuori di essa.
Poi sopra all’engine grafico si possono (e di solito è così) costruire librerie grafiche che facilitino ulteriormente il lavoro degli sviluppatori, ma questo è un’altro discorso…
Quindi, torniamo al nostro engine grafico: in windows è dentro al kernel, significa che il kernel fa tantissima roba in più che può “sbagliare” avere un errore e portar giù o rendere instabile tutto il sistema.
Su Linux no, Xorg sta per i fatti suoi, così come potrebbe farlo un server email.
Se Xorg muore il kernel se ne fa un baffo.
Forse hai provato Gentoo e hai notato che tra una versione e l’altra del kernel talvolta occorre ricompilare Xorg stesso, ma il motivo non è quello che hai pensato tu.
Xorg utilizza delle api per interfacciarsi al kernel ed effettuare le sue richieste, cambia le api (aggiorna il kernel, i driver, …) e xorg non riuscirà più a funzionare.
Però non significa che gira in kernel space.
Se xorg girasse in kernel space o si agganciasse come modulo del kernel avresti ragione, ma non è così.
Ultima nota, a volte il kernel muore e si blocca tutto: la colpa è del driver video il 90% delle volte, nVidia o Ati: questo fa un errore dopo una richiesta di xorg e siccome gira in kernel space tira giù tutto il sistema.
Su windows è la stessa cosa: installa un driver non stabile e viene giù tutto, è normale: metti qualcosa in kernel space e quel qualcosa può renderti il sistema instabile, crashare se ha un bug.
Mettici l’intero engine grafico e il rischio sale, Microsoft lo sa ed infatti sta cercando piano piano di rimuoverlo dal kernel (in Vista ne hanno tirato fuori una parte).
Riguardo la RAM.
Il limite di 4gb di ram è un limite di specifiche del kernel windows, non ricordo la versione ma è quello che corrisponde ad XP.
Non vedo perché mai dovrei confrontare il kernel Linux con un kernel Windows dedicato ad ambiente server, non conosco nessuno che a casa usa windows server.
Se poi anche, come tu dici, fosse una configurazione (e questo è vero su versioni più moderne del kernel windows) è ancora peggio a mio modo di vedere.
Chiudo con una nota sull’età del server Linux recuperando la mia frase esatta:
“il kernel è stato CREATO 40 anni fa, poi è stato continuamente aggiornato e modificato, di quello che c’era 40 anni fa non è rimasto quasi più nulla..”
questa frase è vera per Unix così come per Linux.
Linux è un sistema operativo Unix, punto. Significa che il suo antenato è Unix, che sia stato riscritto tutto o meno le sue origini sono quelle, il software è cambiato ma l’architettura di base è la stessa, come idea, non come codice.
Ho scritto quella frase per spiegare che è stupido parlare di “età” di un kernel visto che si tratta di un software in continuo aggiornamento.
2 gennaio, 2010 at 21:10
molto molto interessante e alla portata di tutti, perfino alla mia!!
4 gennaio, 2010 at 13:49
congratulazioni!
grazie al tuo commento (e al fatto che sono in ferie e malato [che culo eh?]) ho deciso di aggiornare l’articolo 😛
14 settembre, 2009 at 12:00
Ma quante minchiate hai scritto…… la gui parte del kernel.. ecc ecc
ahahah
14 settembre, 2009 at 20:14
Il kernel di windows integra le api per l’interfaccia grafica utente direttamente nel kernel
il software corrispondente a X su linux è parte integrante del kernel.
non sono minchiate
io ho citato le mie fonti
e ti aggiungo anche questa:
http://msdn.microsoft.com/en-us/library/aa480220.aspx
(fonte microsoft)
CIT
“In Windows XP, display drivers, which are large and complex, can be a major source of system instability. These drivers execute entirely in kernel mode (i.e., deep in the system code) and hence a single problem in the driver will often force the entire system to reboot.
[…]
(Parlando ora di Windows Vista) At a technical level, WDDM display drivers have two components, a kernel mode driver (KMD) that is very streamlined, and a user-mode driver that does most of the intense computations. With this model, most of the code is moved out of kernel mode”
come vedi in XP il kernel integrava l’intera parte grafica
su vista si sono impegnati per portarla fuori e l’hanno fatto solo in parte.
tu che fonti hai per dire il contrario?
Almeno abbi la decenza di chiedere scusa
1 dicembre, 2009 at 1:19
che razza di cafone.
comunque è molto interessante l’articolo, anche se noto una lievissima vena polemica… 🙂
1 dicembre, 2009 at 1:53
in realtà il “cafone” potrebbe anche aver espresso un pensiero di altre persone..
mi ha semplicemente aiutato a dimostrare che non ho parlato da non informato.
riguardo la vena polemica: la noti perché c’è.
si fa un gran parlare di kernel monolitico sostenendo che Linux è obsoleto perché è un kernel di questo tipo.
chi sostiene questa tesi è, semplicemente, un ignorante. Senza offesa alcuna.
e questo articolo è stato scritto apposta per chiarire le cose.
Se vi dicono che Linux è sorpassato perché monolitico ridete pure in faccia al vostro interlocutore prima di spiegargli perché ha detto fregnaccia 🙂
5 marzo, 2008 at 13:10
@tristano
eheheh si lo avevo già cazziato io 🙂
5 marzo, 2008 at 10:05
@zanshi
Innanzitutto che il kernel XNU di Mac Os X non abbia problemi di stabilità lo pensi tu. Problemi ne ha, eccome.
NetBSD ha un kernel monolitico, e non un microkernel. Utilizzano NetBSD perchè è un ottimo sistema operativo e gira su una quantità impressionante di piattaforme.
Per concludere il kernel di Mac Os X deriva dallo stesso dal quale deriva NetBSD, e non hanno scelto Mac Os X per andare sullo spazio.
Hai le idee molto confuse o parli per sentito dire.
14 gennaio, 2008 at 17:43
@zanshi
non ho mai detto che una struttura è meglio di un altra: anzi mi pare di aver chiaramente distinto i pregi dell’una e dell’altra
ma ho distinto tra microkernel e monolitico non tra monolitico o ibrido!
ho spiegato molto chiaramente perché parlare di kernel ibrido (nel caso di windows) è assolutamente fuorviante..
perché è un kernel monolitico..
linux ha un kernel monolitico e modulare che, in un certo senso, aggiunge qualche vantaggio dei microkernel mantenendo le prestazioni del kernel monolitici perché i moduli non girano in user space ma finiscono diritti in kernel space
forse dovresti dare una rilettura al mio articolo perché non credo tu l’abbia capito 🙂
infine: dici che i microkernel vengono usati quando non ci si possono permettere errori…
in realtà nei sistemi che tu citi vengono utilizzati dei kernel real time: totalmente diversi dai kernel per personal computer!!! e in genere si.. sono microkernel… come tu giustamente dici perché si devono limitare le possibilità di “system failure” anche se le priorità di un sistema real time non sono tanto le prestazioni quanto una corretta progettazione degli algoritmi di scheduling e dell’interazione tra i thread/della scelta delle priorità
i dispositivi embedded invece NON sempre utilizzano microkernel
e quando li utilizzano non li utilizzano per il motivo che tu riporti (totale uniformità in presenza di architetture diverse) ma perché i microkernel sono più piccoli, cosa necessaria e fondamentale per un dispositivo embedded (anche se ultimamente diventa sempre meno necessaria)
per smentire ciò che hai detto mi basta farti notare che il tom tom (chiaramente un dispositivo embedded) utilizza Linux! un kernel monolitico, come ben dovresti sapere se hai letto il mio articolo…
questo kernel è stato compilato con i soli driver e moduli occorrenti al dispositivo, non è in alcun modo modulare probabilmente perché non è necessario che lo sia…
avendo ridotto il kernel eliminando tutto ciò che non occorreva hanno ottenuto un piccolo kernel adatto al dispositivo
davvero zanshi 🙂 è meglio che rileggi l’articolo perché hai le idee un po’ confuse
11 gennaio, 2008 at 13:41
Secondo me l’articolo è sbagliato di partenza.
Non esiste una struttura di kernel migliore di un’altra, dipende tutto da quello che si vuole fare.
Ad esempio anche il Kernel del MacOSX è ibrido, e non ho mai avuto problemi di stabilità.
Quello che bisogna capire è per cosa si utilizza un certo kernel; ad esempio i kernel ibridi sono più lenti, ma hanno una modularità maggiore e quindi possono essere adattati e convertiti per altre piattaforme in tempi brevissimi. In oltre proprio grazie alla loro modularità garantiscono una sicurezza superiore.
Non so se avete sentito parlare della NASA e della stazione spaziale internazionale; quì usano il NetBSD che è basato su microkernel, perché è un sistema in cui non sono concessi margini di errore.
I microkernel vengono usati molto anche per i dispositivi specifici (embedded) in modo da avere una pressoché totale uniformità anche in presenza di parecchie architetture diverse.
7 settembre, 2007 at 16:22
[…] di utilizzare una periferica (per meglio comprendere cosa questo significhi consiglio la lettura di questo mio articolo). Installare un driver su Linux equivale ad installare un qualunque altro programma. Se il driver […]
30 agosto, 2007 at 8:55
Comunque linus torvald ha scritto direttamente linux da minix, solo in seguito ha deciso di continuare il proprio lavoro sul nuovo sistema..-
24 luglio, 2007 at 12:02
@Blackstorm
la tua affermazione non ha senso
il kernel è stato CREATO 40 anni fa, poi è stato continuamente aggiornato e modificato, di quello che c’era 40 anni fa non è rimasto quasi più nulla..
e comunque un software non è come una macchina… non si deteriora con il tempo o con l’uso
i softwarere per l’end user possono sfruttare nuove tecnologie, l’architettura di base di un computer non è cambiata radicalmente in 40 anni
e quel che è cambiato si è adattato anche nel kernel
24 luglio, 2007 at 3:55
Arrivo tardi, ma giusto per fare un commento: il mio problema non è che linux è monolitico, perchè windows da qst punto di vista è anche peggio, il problema imho è che linux ha un kenel vecchio di 40 anni. E 40 anni, in informatica sono eoni…
23 Maggio, 2007 at 21:21
@Massimo S.
allora vai nel canale italiano di supporto alla tua distribuzione e chiedi se gentilmente qualcuno può fare la segnalazione per te 🙂
con un po’ di fortuna risolveranno il problema
23 Maggio, 2007 at 10:54
@mastro
più che voglia mi sa che dovrei avere una padronanza della lingua inglese che non ho 🙂
Comunque una volta cercando su kernel.org credo di aver capito che c’è stato un cambiamento in una cosa chiamata “tty api”
22 Maggio, 2007 at 16:25
@Massimo S.
ah.. 😀
scusa..
hum…
se hai voglia puoi andare su irc (freenode) e chiedere in #kernel se sanno spiegarti perché quel modulo non funziona più con il 2.6.17
22 Maggio, 2007 at 16:19
Non hai capito, a compilare compila, ma come dicevo assolutamente non funziona, fa crepare il SO! 😦
22 Maggio, 2007 at 13:21
@Massimo S.
ottimo..
se funziona perché non metti a disposizione del mondo la tua patch? 🙂
postala in qualche lista (per esempio)
22 Maggio, 2007 at 10:39
@mastro
Beh ci ho provato, come dice il detto, tentar non nuoce, sono soddisfatto solo del fatto che sono riuscito a farlo compilare (comunque ho detto che non sono un programmatore di driver, non che non sono un programmatore, però programmo in Java)
Il problema è che nessun altro ha modificato quel driver, almeno cercando sulla rete non ne ho trovato notizia, quindi mi ci sono provato da solo 🙂
A quanto pare l’autore del driver adesso lavora per la linuxant che produce una versione a pagamento del driver stesso, quindi …… ci siamo capiti no!? 🙂
21 Maggio, 2007 at 17:48
@Massimo S.
non sei un programmatore e modifichi il driver alla cieca? lol… 😀 se non fosse crashato tutto mi sarei stupito 😀
comunque esistono casi in cui cambia qualcosa, come in questo caso, e quindi alcune applicazioni/driver possono smettere di funzionare
in genere però questi cambiamenti sono preceduti da un lungo periodo in cui ciò che viene rimosso o cambiato è contrassegnato come “deprecato” e degli avvertimenti lo segnalano..
quindi in genere esce una diversa versione del programma ( si tratta di cambiare pochissime righe di codice, talvolta semplicemente il nome di una funzione richiamata )
in questo caso specifico è anche possibile che dipenda dalla configurazione che gli sviluppatori di ubuntu hanno scelto per il kernel, ad esempio rimuovendo il supporto a qualcosa di ormai deprecato 🙂
21 Maggio, 2007 at 17:29
@mastro
Non sempre le incompatibilità sono tra cambi “grossi” di versione.
Ad esempio il driver Open Source per il modem Conexant (vedi https://help.ubuntu.com/community/DialupModemHowto/Conexant ) non compila con la versione 2.6.17 del kernel, mentre funzionava con la 2.6.15
Ho provato a modificare il codice del driver, andando per lo più alla cieca, non sono un programmatore di driver.
Quello che ho ottenuto al massimo è stato un crash totale della macchina tanto per riallacciarsi al discorso del kernel space vs user space 😦
28 aprile, 2007 at 2:32
@sughero
grazie del contributo
comunque il mio post è molto chiaro:
Si sente spesso quell’insulto contro Linux, io ho semplicemente fatto notare che se è un “difetto” di Linux lo è anche di Windows, e forse di più!
inoltre che un microkernel sia migliore di un kernel monolitico è tutto da dimostrare.. a mio parere dipende dall’applicazione e da cosa ci devi fare
28 aprile, 2007 at 0:24
Be’ dicendo che ….l’insulto: “Linux è obsoleto perché usa ancora un kernel monolitico” denota ignoranza… dai dell’ignorante ad Andy Tanenbaum docente di informatica presso l’Università Vrije di Amsterdam e inventore di minix, uno unix per macchine intel da cui Linus Torvalds ha preso spunto per creare la prima versione di Linux.
Quell’insulto, come lo chiami tu ha origini molto chiare in un flame nel 92 su usenet. Qui c’è tutta la “litigata” :
http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html
26 aprile, 2007 at 23:07
Ti ho “linkato” anche io 🙂
26 aprile, 2007 at 19:12
@realtebo
grazie..
vengo subito a vedere che dici 😉
26 aprile, 2007 at 18:38
molto interessante, ho linkato sul nostro blog questo articolo, grazie
26 aprile, 2007 at 18:37
[…] Link […]
26 aprile, 2007 at 0:45
@aniceweb
in realtà anche senza rilasciare le specifiche gli sviluppatori del kernel si sono offerti di firmare NDA per poter avere le specifiche e quindi scrivere i driver, o in alternativa avere qualcuno a loro disposizione che possa rispondere a domande su come fare una cosa o l’altra…
il tutto gratuitamente e a beneficio di tutti..
adesso stiamo a vedere… ora non hanno più scuse ( salvo che ci siano altri motivi che non ci vogliono dire, e non saprei quali )
ti passerei il link ma non ce l’ho più, dovrei cercarlo.. 🙂
26 aprile, 2007 at 0:38
Si il driver è chiuso, e purtroppo mi porterà alla vendita del modem(purtroppo è un regalo) per un router.
Purtroppo le aziende non arrivano a capire che per ogni sistema operativo supportato un’utenza maggiore potrà comprare il proprio prodotto = ricavi maggiori. Se poi teniamo conto che se le aziende rilasciassero le specifiche, la comunità svilupperebbe il driver GRATIS, non è più un problema ma l’applicazione di una mentaità ottusa e stupida
26 aprile, 2007 at 0:20
@aniceweb
suppongo che il problema si ponga perché il driver è chiuso giusto?
in realtà non è un difetto di Linux
le incompatibilità grosse tra kernel avvengono tra cambi “grossi” di versione in genere
2.4 -> 2.6 appunto
un po’ come si hanno problemi di compatibilità da win98 -> winXP -> win vista
penso che sarebbe facilmente risolvibile se ci fossero i sorgenti 🙂 in genere si tratta di sostituire qualche chiamata deprecata con qualcuna “nuova”
grazie del contributo comunque, e dei complimenti
26 aprile, 2007 at 0:07
Ti ringrazio per la segnalazione 😀
Comunque il tuo blog è pieno di informazioni molto interessanti! Complimenti!
Un difetto del kernel linux( lo conosco perchè mi ci sono imbattuto pochi giorni fa) è che quando sviluppano un driver, molte volte le aziendo lo fanno solo ed unicamente per uno specifico kernel. Ad esempio io per far funzionare un modem usb dovrei ”tornare” al kernel 2.4.x mandando a quel paese tutte le ottimizzazioni e le innovazioni dell’attuale 2.6.20.qualcosa che ho ora….
Peccato, ma rimane un piccolo difetto nel mare dei pregi dell’utilizzare Linux come sistema operativo 😀
26 aprile, 2007 at 0:06
@Neo
beh.. non direi che “fa schifo”
diciamo che ha degli aspetti positivi, e altri negativi..
bisogna dar atto a microsoft che da windows 4.0 (nt) la stabilità del suo kernel è molto migliorata..
nonostante questo limiti come i 4GB di RAM in un sistema come Vista credo siano semplicemente inaccettabili
comunque il senso di questo articolo era chiarire cosa significa Kernel Monolitico, e soprattutto precisare (perché sia chiaro) che anche Windows ha un kernel Monolitico
25 aprile, 2007 at 22:33
wow, interessante! avevo sentito parlare di microkernel e kernel monolitico, ma non sapevo in cosa differivano. e soprattutto non sapevo che il kernel di windows fosse messo così male 😀
motivo in più per odiarlo