Microsoft: identificate 22 nuove vulnerabilità

[Ikitt_Claw]

Originariamente inviato da ][xwilsonx][
ma ne sei sicuro???? prova a far funzionare un modem adsl usb su win e poi prova su linux....

Come dici tu stesso piu` sopra, senza i driver del produttore tutto si complica.
Comunque, questo e` un problema di supporto HW

[joe4th]

Originariamente inviato da cdimauro
La soluzione al problema non è neppure quella di trincerarsi in una politica integralista che riconosce come "giusta cosa" soltanto quella di avere a che fare con sorgenti aperti per qualunque cosa, driver inclusi, e che come miglioramento al problema della carenza dei driver propone delle regole ancora più rigide che tagliano fuori un'altra fetta di driver closed-source (vedi recente vicenda dei driver per la webcam Philips, se non ricordo male).

Vogliamo parlare dei driver conexant o adesso di quelli
ECI per i modem ADSL USB, per i quali sono venute fuori battaglie legali?

Ne abbiamo discusso (non con te, ma in generale) tempo addietro: la norma per i s.o. è stata quella di avere dei driver binari, non open source, e tutto ha funzionato sempre bene (anche per altri s.o. Unix-like). La comunità di Linux ha scelto quella di avere dei driver (quasi esclusivamente) open source, opponendo una battaglia ideologica che non fa che peggiorare le situazione.

Non sono scelte integraliste, ma vengono fuori come sottoprodotto
della situazione attuale e delle evoluzioni che sta
avendo quello che e' considerato un sistema come Linux + applicazioni
GPL. In Linux non e' vietato avere driver o moduli binari (e
per questo Stallman ne ha sempre dato colpa a Torlvads che non
l'ha vietato), semplicemente questi non funzionano o funzionano
male, per diversi motivi: perche' il sistema cambia troppo velocemente,
perche' ci sono troppe distribuzioni,
perche' i programmatori non rispettono le specifiche utilizzando
funzioni deprecate (hai mai provato a dare un'occhiata
ai driver dei moduli vmnet di VMWare?) da anni, perche' ognuno
i kernel con gli allineamenti che preferisce, etc.

Sul fatto che poi i driver binari hanno funzionano sempre bene,
beh ho i miei dubbi, visto che non conto neanche piu' tutte
le volte che i sistemi Windows si sono imballati
definitivamente, perche' un driver (pensa ai VIA 4in1)
e' stato aggiornato. Forse era vero per i sistemi come SCOa o DigitalUX...,
dove le cose cambiavano, molto, molto lentamente. Ah, no, ecco,
in Windows si sono inventati i drivers "certificati", che servono
per spillare ulteriori soldi ai produttori e si piantano come quelli
non certificati.

L'ideale sarebbe invece avere dei driver platform indipendent
(platform independent non significano i tarocchi attuali che
vengono usati per far funzionare le schede Wireless con i
driver e le DLL di Windows). Se non ricordo male tempo fa se n'era parlato.

La soluzione ideale, IMHO, è quella di rilasciare un insieme di specifiche che permettano di scrivere dei driver, siano essi open o closed source, che si adattano a qualunque compilazione del kernel sia stata scelta, senza porre eccessivi vincoli, come quello del rifiuto di soluzioni quali l'impiego di hook per richiamare funzioni esterne al kernel, che soltanto gente fanatica e con una limitata visione come Torvalds può bollare aprioristicamente come "pericolose".


E' per questo che in genere è meglio procedere in maniera opposta: Linux che gira dentro una virtual machine...

Visto che quello che verrebbe emulato e' piu' stabile del sistema
nativo che starebbe fuori, direi proprio di no.

[cdimauro]

Originariamente inviato da Ikitt_Claw
Esatto! E questo perche` la norma dei SO era (e`) di essere closed-source...

Beh, s.o. e driver hanno poco a che spartire quanto a filosofia di sviluppo.

all'OSDL stanno iniziando a pensarci su, pare, fatti salvi certi limiti tecnici di cui parlava ilsensine qualche tempo fa.

Lo spero bene. Comunque non credo che ci siano eccessivi problemi in merito; nVidia ha già fatto un buon lavoro con i suoi driver binari, dimostrando che è possibile far coesistere le esigenze dei kernel con la sua politica di tutela della proprietà intellettuale...

In effetti e` un capolavoro di design, eh?

Sai che non apprezzo particolarmente i s.o. Unix-like: li trovo troppo arretrati concettualmente. AmigaOS rimane ancora uno dei s.o. più semplici, potenti e che ha offerto una ventata d'aria nuova ai problemi legati all'implementazione di un s.o...

PS: Torvalds fanatico? Da quando?

Vedi vicenda degli hook, per quanto riguarda i driver, e le sue sparate contro l'uso del C++ quale linguaggio per lo sviluppo del kernel. Del primo se n'è parlato qualche mese fa nella sezione Linux, in merito alla vicenda di Philips, e del secondo tempo addietro nelle news.

[Ikitt_Claw]

Originariamente inviato da cdimauro
Beh, s.o. e driver hanno poco a che spartire quanto a filosofia di sviluppo.

pero` driver e SO (quantomeno nei macrokernel) dovrebbero seguire la stessa filosofia di sviluppo, e cosi`...

Lo spero bene. Comunque non credo che ci siano eccessivi problemi in merito;

Vedremo, vedremo.

Sai che non apprezzo particolarmente i s.o. Unix-like:

Uh, beh, in effetti si intuisce vagamente

le sue sparate contro l'uso del C++ quale linguaggio per lo sviluppo del kernel.

Nel 1994 o quand'era, considerando la situazione di g++, non aveva proprio tutti i torti...

in merito alla vicenda di Philips, e del secondo tempo addietro nelle news.

Il punto e` che ci sono scelte e motivazioni, non sono molto frequenti i casi in cui ha detto "si fa cosi` perche` si".
E d'altrocanto, potrei citare i casi di LVM e reiserfs, ebtrati (chi piu` chi meno) a furor di popolo...

[ilsensine]

Originariamente inviato da cdimauro
Vedi vicenda degli hook, per quanto riguarda i driver

Ha perfettamente ragione, ho commentato la cosa fino alla nausea nella sez. linux. Ci sono ragioni tecnico/legali legati a quella vicenda.
L'errore lo ha fatto lo sviluppatore che ha introdotto gli hook: se intendeva interfacciarsi a moduli closed source, poteva farlo. Non con degli hook, però.
nb visto che sei così informato sul kernel linux, saprai anche che ora il driver ha un nuovo mantainer, e che le routine closed source che prima venivano interfacciate dagli hook sono misteriosamente diventate GPL

e le sue sparate contro l'uso del C++ quale linguaggio per lo sviluppo del kernel.

Ho scoperto giusto ieri, che ci fu una fase nello sviluppo del kernel 0.99 dove il codice era stato portato in c++.
Linus ha quindi _provato_ il c++, e lo ha in seguito scartato. Esistono valide _motivazioni tecniche_ perché il kernel linux non può essere c++.

[sheijtan]

Originariamente inviato da cdimauro
Per quanto mi riguarda, lo stesso vale per Windows: per quale motivo lo riterresti un giocattolo?

Ma chi ha detto che windows è un giocattolo? io stavo polemizzando con zek che aveva affermato che chi usa linux ha tempo da perdere. C' hai la coda di paglia?
(scherzo, eh...non ti arrabbiare che se no inondi il forum di post...)

Ti sei risposto da solo: non sai (tu) dove mettere le mani. I socket esistono anche per Windows (WinSocket), e puoi usare le apposite API che ricalcano in buona parte i classici socket BSD.

oh-mio-dio-cdmauro!
ti spiego il senso del mio post: volevo mostrare con quell' esempio (il mini cluster) che è possibile usare linux (magari sbattendoci la testa) per imparare cose utili non fine a se stesse e immediatamente spendibili per risolvere problemi pratici.
Dire: "con windows non avrei saputo dove mettere le mani" era un modo (auto)ironico per mettere in evidenza che la "semplicità d' uso" può essere un fatto soggettivo.

per finire con questa querelle, non metto in dubbio che per windows siano presenti tutte le API e gli ambienti di sviluppo di questo mondo, i driver di tutte le periferiche passate e future e che grazie a bill il mondo è un po' migliore e che senza il suo genio imprenditoriale a quest' ora stavamo senza interfaccia grafica...
Però è contrario al MIO gusto e finché potrò cercherò di farne a meno...
(mannaggia per half life 2, eh...)
ciao!

[fek]

Originariamente inviato da ilsensine

Ho scoperto giusto ieri, che ci fu una fase nello sviluppo del kernel 0.99 dove il codice era stato portato in c++.
Linus ha quindi _provato_ il c++, e lo ha in seguito scartato. Esistono valide _motivazioni tecniche_ perché il kernel linux non può essere c++.

Sono curiosissimo di conoscere questa valide motivazioni tecniche

(Perche' non esiste una valida motivazione tecnica per preferire C a C++ in nessun tipo di software)

[fek]

Originariamente inviato da sheijtan

Dire: "con windows non avrei saputo dove mettere le mani" era un modo (auto)ironico per mettere in evidenza che la "semplicità d' uso" può essere un fatto soggettivo.

Non e' un fatto soggettivo. Dai un'occhiata alla sfilza di libri che ho postato.

[ilsensine]

Originariamente inviato da fek
Sono curiosissimo di conoscere questa valide motivazioni tecniche

(Perche' non esiste una valida motivazione tecnica per preferire C a C++ in nessun tipo di software)

1) Gestione della memoria.
Il c++ utilizza un layer di astrazione per la gestione della memoria, soprattutto nella gestione delle classi. Nel kernel linux, per contro, la gestione della memoria non è come in user space: esistono tecniche di allocazione diverse a seconda delle circostanze: memoria fisicamente contigua, memoria virtualmente contigua, multipli di pagina, allocazione di tanti oggetti di uguale dimensione, memoria highmem, memoria dma legacy, memoria per-cpu, memoria consistente/coerente per operazioni dma ecc, e del contesto di allocazione (contesto di interruzione, contesto utente, allocazioni atomiche/non atomiche ecc.)
Voler conciliare la gestione c++ della memoria con le esigenze del kernel significa creare nuove complicazioni, invece di ridurle.

2) Gestione delle eccezioni
Il kernel utilizza una propria tecnica per la gestione delle eccezioni, in nessun modo compatibile con il c++. Anzi, il codice che il c++ genera per prevedere e gestire eventuali eccezioni è un problema per il kernel.

3) Utilizzo dello stack
Il kernel linux ormai viaggia con stack di 4k, e i path di codice superiori a 2.5k di consumo di stack sono ritenuti "eccessivi". Il c++ è molto più famelico di stack rispetto al c.

4) Ottimizzazione
Il gcc ottimizza il codice in maniera decisamente migliore del g++

5) Dimensione del codice
Il codice c++ è inevitabilmente più "bloated" rispetto al codice in c. Questo è un problema per il kernel, in quanto la memoria in kernel space non può essere soggetta a swapping (e, possibilmente, il codice del kernel dovrebbe toccare meno cache di sistema possibile).

Risolvere tutte queste complicazioni per ottenere vantaggi limitati (quali?) non è conveniente.

[fek]

Originariamente inviato da ilsensine
1) Gestione della memoria.
Il c++ utilizza un layer di astrazione per la gestione della memoria, soprattutto nella gestione delle classi. Nel kernel linux, per contro, la gestione della memoria non è come in user space: esistono tecniche di allocazione diverse a seconda delle circostanze: memoria fisicamente contigua, memoria virtualmente contigua, multipli di pagina, allocazione di tanti oggetti di uguale dimensione, memoria highmem, memoria dma legacy, memoria per-cpu, memoria consistente/coerente per operazioni dma ecc, e del contesto di allocazione (contesto di interruzione, contesto utente, allocazioni atomiche/non atomiche ecc.)
Voler conciliare la gestione c++ della memoria con le esigenze del kernel significa creare nuove complicazioni, invece di ridurle.

Falso.
In C++ non costringe ad alcun layer per la gestione della memoria, e' possibile usare malloc e free esattamente come in C, inoltre, volendo evitare queste funzioni, ma usando allocatori custom per eventuali ottimizzazioni e' possibile overloadare gli operatori new e delete, usando un proprio sistema di allocazione (oppure rivolgendosi ad uno esattamente equivalente a quello del C), in maniera piu' semplice e concisa di quanto si possa fare in C.
Qualunque tipo di allocazione che hai nominato puo' essere elegantemente implementata con overload degli operatori new e delete.

Questo e' un non argomento.

2) Gestione delle eccezioni
Il kernel utilizza una propria tecnica per la gestione delle eccezioni, in nessun modo compatibile con il c++. Anzi, il codice che il c++ genera per prevedere e gestire eventuali eccezioni è un problema per il kernel.

Falso.
La gestione delle eccezioni e' opzionale. Qualunque gestione delle eccezioni alternativa compatibile con il C e' compatibile con il C++ e puo' essere "wrappata". Esempio: le structured exceptions di Win32.

3) Utilizzo dello stack
Il kernel linux ormai viaggia con stack di 4k, e i path di codice superiori a 2.5k di consumo di stack sono ritenuti "eccessivi". Il c++ è molto più famelico di stack rispetto al c.

Falso.
Il C++ non e' intrinsecamente piu' famelico di stack, dipende dal programmatore e dal suo uso.
In tutti questi problemi vedo un pattern comunue: chi li ha esposti, non sa programmare in C++.

4) Ottimizzazione
Il gcc ottimizza il codice in maniera decisamente migliore del g++

Problema del compilatore, non del linguaggio. E vorrei vedere test specifici, riguardo al guadagno prestazionale: se e' sotto l'0.1%, diventa automaticamente un non argomento, paragonato ai vantaggi in termini di stabilita' e produttivita' che un modello di programmazione orientato agli oggetti in C++ fornirebbe.

5) Dimensione del codice
Il codice c++ è inevitabilmente più "bloated" rispetto al codice in c. Questo è un problema per il kernel, in quanto la memoria in kernel space non può essere soggetta a swapping (e, possibilmente, il codice del kernel dovrebbe toccare meno cache di sistema possibile).

Falsissimo. Incredibilmente falso. Non dipende dal linguaggio, ma dal programmatore che lo usa.
Questo mito e' stato ampiamente smontato qui:
http://www.amazon.co.uk/exec/obidos/...027200-9583865

Risolvere tutte queste complicazioni per ottenere vantaggi limitati (quali?) non è conveniente.

Non si tratta di risolvere complicazioni, si tratta di imparare a programmare in C++.
Vantaggi?
Tutti quelli che un modello ad oggetti fornisce rispetto alla programmazione predicativa classica di 20 anni fa. Il mondo si e' evoluto, sarebbe ora che anche Linus si evolvesse e imparasse un nuovo linguaggio.

[sheijtan]

Originariamente inviato da fek
Non e' un fatto soggettivo. Dai un'occhiata alla sfilza di libri che ho postato.

Non metto in dubbio che il livello di astrazione raggiunto da windows nella gestione del sistema sia notevole e che da questo derivi una maggiore semplicità d' uso rispetto ad altri o.s. , però in alcuni casi entra in gioco l' attitudine personale (o la soggettività). es:
generalmente il processo di configurazione di un programma, di un servizio o di una periferica con windows è un susseguirsi di clicca qui, poi li, riclicca di qua una cliccatina di la....magari tutto per editare un parametro. Dimmi quello che vuoi, però a ME 'sta cosa scoccia! Io (nella mia soggettività) preferisco l' approccio seguito da alcune distros linux: quasi sempre (e speriamo sempre più spesso) puoi "cliccare qui e la", però puoi ANCHE editare il file di configurazione appropriato (che generalmente sta in /etc ) ed impostare manualmente il parametro che ti interessa modificare. insomma certe cose si fanno più facilmente con l' interfaccia grafica, altre possono essere fatte facilmente e velocemente a riga di comando.
P.S. già sento le proteste: Ah, marrano! anche con windows puoi editare i file di configurazione...
Non usciremo mai vivi da questa discussione. Siamo perduti.
PPS. propongo l' istituzione di un' area del forum dove il massacro win Vs linux sia finalmente libero e sfrenato.

[fek]

Originariamente inviato da sheijtan
Non metto in dubbio che il livello di astrazione raggiunto da windows nella gestione del sistema sia notevole e che da questo derivi una maggiore semplicità d' uso rispetto ad altri o.s. , però in alcuni casi entra in gioco l' attitudine personale (o la soggettività). es:
generalmente il processo di configurazione di un programma, di un servizio o di una periferica con windows è un susseguirsi di clicca qui, poi li, riclicca di qua una cliccatina di la....magari tutto per editare un parametro. Dimmi quello che vuoi, però a ME 'sta cosa scoccia! Io (nella mia soggettività) preferisco l' approccio seguito da alcune distros linux: quasi sempre (e speriamo sempre più spesso) puoi "cliccare qui e la", però puoi ANCHE editare il file di configurazione appropriato (che generalmente sta in /etc ) ed impostare manualmente il parametro che ti interessa modificare. insomma certe cose si fanno più facilmente con l' interfaccia grafica, altre possono essere fatte facilmente e velocemente a riga di comando.
P.S. già sento le proteste: Ah, marrano! anche con windows puoi editare i file di configurazione...
Non usciremo mai vivi da questa discussione. Siamo perduti.
PPS. propongo l' istituzione di un' area del forum dove il massacro win Vs linux sia finalmente libero e sfrenato.

Tutto assolutamente vero, e concordo. La semplificazione forzata di molte procedure in Windows porta spesso ad una gestione meno efficiente, non meno complessa. Certe cose si potrebbero sicuramente fare piu' velocemente, tipo io sono un grande fan di file di testo di configurazione e non sopporto il registry.

[ilsensine]

Originariamente inviato da fek
Falso.
(...)
Qualunque tipo di allocazione che hai nominato puo' essere elegantemente implementata con overload degli operatori new e delete.

A che scopo quindi utilizzare new/delete? Quante versioni _per classe_ ne dovrei creare, per coprire tutti i casi possibili?

Falso.
La gestione delle eccezioni e' opzionale.

Bene. Visto che al kernel linux servono le eccezioni, mi stai confermando che quelle fornite dal c++ sono inutili.

Falso.
Il C++ non e' intrinsecamente piu' famelico di stack, dipende dal programmatore e dal suo uso.

Quindi dovrei programmare in c++ "avendo cura" di non programmare nello stile c++? E a che mi serve allora?

Problema del compilatore, non del linguaggio.

Si infatti gcc e g++ sono i compilatori disponibili sotto linux. E' un problema che abbiamo, purtroppo.

...che un modello di programmazione orientato agli oggetti in C++ fornirebbe.

Il kernel linux è fortemente orientato agli oggetti, con tanto di polimorfismi ecc.
Per favore, non ci hai mai messo mano. Io lo faccio per lavoro.

Falsissimo. Incredibilmente falso. Non dipende dal linguaggio, ma dal programmatore che lo usa.
Questo mito e' stato ampiamente smontato qui:
http://www.amazon.co.uk/exec/obidos/...027200-9583865

Dovrei leggere un libro solo per capire come non generare codice bloated con il c++?
Per tua informazione, esistono diversi driver linux closed source con core c++. Normalmente sono 10 volte più grandi dei moduli del kernel.
Rivolgi le tue rimostranze (e il link) a chi scrive quei driver (che mi risulta sono gli stessi che li scrivono per windows).

Non si tratta di risolvere complicazioni, si tratta di imparare a programmare in C++.

Sì io uso spesso il c++ nei miei programmi user space. Non sarò il più grande dei guru, ma me la cavo. E mi piace molto come linguaggio. Ciò nonostante, condivido che il c++ è da evitare come la peste dentro il kernel.

Vantaggi?
Tutti quelli che un modello ad oggetti fornisce rispetto alla programmazione predicativa classica di 20 anni fa. Il mondo si e' evoluto, sarebbe ora che anche Linus si evolvesse e imparasse un nuovo linguaggio.

Allora prendi i sorgenti del kernel e riscrivili in c++. La fama che riceverai, ridicolizzando quella di tutti quegli idioti che ci lavorano usando ancora tecniche neanderthaliane, vale bene la fatica che farai.

[fek]

Originariamente inviato da ilsensine
A che scopo quindi utilizzare new/delete? Quante versioni _per classe_ ne dovrei creare, per coprire tutti i casi possibili?

Devi scriverne esattamente il numero dei casi possibili, poi erediti o incapsuli

Bene. Visto che al kernel linux servono le eccezioni, mi stai confermando che quelle fornite dal c++ sono inutili.

No, ti sto dicendo che puoi usare lo schema di eccezioni Linux anche in C++, esattamente come in C. E' uguale.

Quindi dovrei programmare in c++ "avendo cura" di non programmare nello stile c++? E a che mi serve allora?

No, devi programmare in C++ avendo cura di programmare in maniera intelligente. Puoi fare porcate in C++ come puoi farle in C, la differenza e' che il C++ e' un linguaggio piu' ricco e potente, quindi e' piu' facile fare porcate se non si sa quello che si sta facendo.
Come tutti gli strumenti, bisogna essere in grado di usarlo per trarne il meglio.

Si infatti gcc e g++ sono i compilatori disponibili sotto linux. E' un problema che abbiamo, purtroppo.

Hai un link che riporti qualche dato sulla differenza di prestazioni nei due compilatori per compilare lo stesso codice?

Il kernel linux è fortemente orientato agli oggetti, con tanto di polimorfismi ecc.
Per favore, non ci hai mai messo mano. Io lo faccio per lavoro.

Piano, non ho detto che il kernel non sia orientato agli oggetti, ho detto che l'implementazione non puo' esserlo e qui confermi il mio discorso: perche' costringere un linguaggio come il C ad un'idioma per il quale non e' stato progettato? Scommetto qualunque cosa che molto del kernel implementato in C++ sarebbe non solo piu' coerente e leggibile, ma alla fine sarebbe anche piu' veloce.

Mi fai per favore un qsort di un tipo generico in C veloce come la stessa versione che posso scrivere in C++?
Per quanto ti sforzi, non arriverai a scriverla piu' di 5 volte piu' lenta (di media).

Dovrei leggere un libro solo per capire come non generare codice bloated con il c++?
Per tua informazione, esistono diversi driver linux closed source con core c++. Normalmente sono 10 volte più grandi dei moduli del kernel.
Rivolgi le tue rimostranze (e il link) a chi scrive quei driver (che mi risulta sono gli stessi che li scrivono per windows).

Che imparino a programmare in C++.
Scommetto che non fanno altro che passare oggetti per valore.

Allora prendi i sorgenti del kernel e riscrivili in c++. La fama che riceverai, ridicolizzando quella di tutti quegli idioti che ci lavorano usando ancora tecniche neanderthaliane, vale bene la fatica che farai.

Ho gia' un lavoro, grazie

[fek]

E per concludere, il kernel del BeOS era scritto interamente in C++, e' un kernel unix-like (anche se monoutente) ed in quanto a leggerezza ed efficienza e stabilita' si mangiava a colazione il kernel di Windows e quello di Linux.

Quelli sapevano programmare.

[ilsensine]

Originariamente inviato da fek
Ho gia' un lavoro, grazie

Diamoci un taglio, altrimenti non ne usciamo più...
Hai un lavoro che personalmente ti invidio, ma se facessi il tuo lavoro allora invidierei il mio attuale.
Dammi retta -- non c'è posto per il c++ nel kernel linux. Prima la pensavo come te, ma dopo parecchio tempo che ci lavoro, mi sono ricreduto. E non è facile riassumere in poche righe l'esperienza di svariate giornate passate davanti al codice. Ora non cambierei l'interfaccia c attuale del kernel con null'altro, neanche se scritta dal migliore programmatore c++. Per il "resto del mondo" (l'ambiente user space) è un'altra storia -- ma ci sono esigenze, strumenti e (soprattutto) vincoli diversi. Il fatto che tutte le persone che lavorano seriamente sul kernel la pensino come me, vorrà dire qualcosa? O siamo tutti vecchi babbioni senza la minima attenzione all'evoluzione dell'informatica?

Dovresti passare un pò di tempo a scrivere per il kernel linux. Ti insegnerebbe parecchie cose

[fek]

Originariamente inviato da ilsensine
Diamoci un taglio, altrimenti non ne usciamo più...
Hai un lavoro che personalmente ti invidio, ma se facessi il tuo lavoro allora invidierei il mio attuale.
Dammi retta -- non c'è posto per il c++ nel kernel linux. Prima la pensavo come te, ma dopo parecchio tempo che ci lavoro, mi sono ricreduto. E non è facile riassumere in poche righe l'esperienza di svariate giornate passate davanti al codice. Ora non cambierei l'interfaccia c attuale del kernel con null'altro, neanche se scritta dal migliore programmatore c++. Per il "resto del mondo" (l'ambiente user space) è un'altra storia -- ma ci sono esigenze, strumenti e (soprattutto) vincoli diversi. Il fatto che tutte le persone che lavorano seriamente sul kernel la pensino come me, vorrà dire qualcosa? O siamo tutti vecchi babbioni senza la minima attenzione all'evoluzione dell'informatica?

Dovresti passare un pò di tempo a scrivere per il kernel linux. Ti insegnerebbe parecchie cose

Non c'e' niente da invidiare nel mio lavoro, te l'assicuro

A parte gli scherzi, non e' perche' non mi fido di te (anzi, sicuramente sei fra i piu' preparati), ma non mi fido di nessuno, non c'e' alcuna motivazione tecnica per preferire il C al C++ in un Kernel, ti ho dato i motivi che smontano le ragioni che hai postato, e ti ho portato un esempio di kernel efficiente scritto in C++.

Perche' dirmi che non si puo' scrivere il Kernel in C++ perche' non si possono scrivere allocatori diversi o c'e' bisogno di scriverne uno specifico per classe e' una boiata, e dimostra che chi lo pensa non e' in grado di applicare semplici concetti come l'ereditarieta e l'incapsulamento.

Se mi si dice che il codice C++ e' per forza di cose bloated, mi viene da pensare che chi fa questa affermazione non ha mai scritto un progetto serio in C++ e non ha mai imparato il linguaggio, perche' e' un non argomento. Semplicemente non e' vero, e i perche' sono spiegati nel libro che ti ho postato. E' interessante, merita di essere letto, e' scritto dai due autori di CFront (il primo traduttore da C++ a C). In sintesi, nel libro, e' descritto come l'object model del C++ viene tradotto in codice C e fa capire come tutti gli argomenti contro il C++ siano solo frutto di miti.

Infine, io non so se chi lavora sul Kernel Linux sia un vecchio babbione o meno, io mi baso su quello che tu hai riportato: se quelle sono le opinioni e i motivi, allora questa gente non conosce il C++. Poi puo' essere anche Dio sceso in terra.

Se non programmassi in 3d, sicuramente cecherei di programmare kernel di SO, e' la mia seconda passione

[ilsensine]

Originariamente inviato da fek
A parte gli scherzi, non e' perche' non mi fido di te (anzi, sicuramente sei fra i piu' preparati), ma non mi fido di nessuno, non c'e' alcuna motivazione tecnica per preferire il C al C++ in un Kernel, ti ho dato i motivi che smontano le ragioni che hai postato, e ti ho portato un esempio di kernel efficiente scritto in C++.

Il kernel Beos non lo conosco (e penso che non lo conosci neanche tu). Quindi non posso risponderti su quello (è un brutto vizio che ho, ma che dovresti prendere anche tu )
Per il resto, non mi hai smontato molto: o mi hai confermato che alcune tecniche del c++ semplicemente non sono applicabili al kernel, o comunque che dovrei fare un lavoro aggiuntivo che con il c non è necessario. Non posso usare il c++ per programmare il kernel allo stesso modo con cui lo uso per programmare OpenOffice, in sintesi. E no, il fatto di includere i metodi nell'interfaccia "class foo" invece che "struct bar" non è un buon motivo per cambiare linguaggio, se di quel linguaggio poi posso usarne solo una parte, e un'altra la devo "adattare" opportunamente.
L'equivalenza logica dei moduli del kernel agli oggetti c++ c'è: "this" non si chiamerà "this" ma avrà un altro nome; quando invochi un metodo, hai il piccolo "fastidio" di dover passare esplicitamente il reference tra i parametri (cosa che il c++ fa ma ti nasconde). L'incapsulamento c'è -- di un driver hai accesso solo ad una interfaccia ben definita. L'ereditarietà anche -- tutti gli oggetti del kernel ad esempio "derivano" da un "kobject". Ho anche un piccolo "esempio in c" di template, se ti interessa.
Eppure, nonostante ciò, contiuiamo a fare tutto questo in c. E _nessuno_ fin'ora si è preso la briga di scrivere delle parti in c++ -- semplicemente, perché in un kernel non serve, e sarebbe più complicato da gestire della struttura attuale.
L'unica cosa che mi hai contestato è che, volendo, è possibile. Ma non puoi nascondere che ci sono complicazioni, problemi, limiti, e del lavoro (forse inutile) in più da fare. E continuo a non vederne i vantaggi, visto che _oggi_ aggiungere un driver in più al kernel è una fesseria. Provaci!(*)

Se non programmassi in 3d, sicuramente cecherei di programmare kernel di SO, e' la mia seconda passione

Non occorre leggere libri per fare un buon modulo per il kernel, né avere ddk particolari, basta saper programmare


(*) ehm...siamo un pò a corto di programmatori per driver 3d...

[fek]

Originariamente inviato da ilsensine
Il kernel Beos non lo conosco (e penso che non lo conosci neanche tu). Quindi non posso risponderti su quello (è un brutto vizio che ho, ma che dovresti prendere anche tu )

Ho fatto parte del team di OpenBeOs e del team OpenGL di BeOS

E' C++ con tutti i crismi, e' un missile, e' la dimostrazione vivente di due concetti:
1) se fosse stato standard al posto di Windows il mondo sarebbe forse migliore
2) si puo' scrivere un kernel efficientissimo in C++

Io parlo solo di quello che so, infatti parlo solo di due argomenti e su tutto il resto sto zitto.

Per il resto, non mi hai smontato molto: o mi hai confermato che alcune tecniche del c++ semplicemente non sono applicabili al kernel, o comunque che dovrei fare un lavoro aggiuntivo che con il c non è necessario. Non posso usare il c++ per programmare il kernel allo stesso modo con cui lo uso per programmare OpenOffice, in sintesi. E no, il fatto di includere i metodi nell'interfaccia "class foo" invece che "struct bar" non è un buon motivo per cambiare linguaggio, se di quel linguaggio poi posso usarne solo una parte, e un'altra la devo "adattare" opportunamente.

Ma che discorso e', e' ovvio che non puoi usare le stesse metodologie di sviluppo per OpenOffice e per un kernel, e' scoprire l'acqua calda.
Puoi usare lo stesso linguaggio, ma in C++ non puoi fare solo object oriented, puoi fare anche:

- Paradigm programming
- Generic programming

Mi fai un po' di generic programming in C?

Le mie obiezioni hanno semplicemente smontato i miti che:
- il C++ e' intrinsecamente piu' lento e pesante (falso)
- il C++ non permette gestori di memoria custom (incredibilmente falso)
- il C++ non permette gestioni dell'eccezioni custom (e' piu' facile che gli asini volino)

L'equivalenza logica dei moduli del kernel agli oggetti c++ c'è: "this" non si chiamerà "this" ma avrà un altro nome; quando invochi un metodo, hai il piccolo "fastidio" di dover passare esplicitamente il reference tra i parametri (cosa che il c++ fa ma ti nasconde). L'incapsulamento c'è -- di un driver hai accesso solo ad una interfaccia ben definita. L'ereditarietà anche -- tutti gli oggetti del kernel ad esempio "derivano" da un "kobject". Ho anche un piccolo "esempio in c" di template, se ti interessa.
Eppure, nonostante ciò, contiuiamo a fare tutto questo in c. E _nessuno_ fin'ora si è preso la briga di scrivere delle parti in c++ -- semplicemente, perché in un kernel non serve, e sarebbe più complicato da gestire della struttura attuale.
L'unica cosa che mi hai contestato è che, volendo, è possibile. Ma non puoi nascondere che ci sono complicazioni, problemi, limiti, e del lavoro (forse inutile) in più da fare. E continuo a non vederne i vantaggi, visto che _oggi_ aggiungere un driver in più al kernel è una fesseria. Provaci!(*)

Nessuno mette in dubbio l'equivalenza logica, ma mi stai solo confermando che il Kernel di Linux puo' essere scritto in C++, perche' di fatto sta gia' forzando il C a comportarsi da C++ ma senza gli automatismi messi a disposizione dal linguaggio. E senza l'efficienza (sia in termini di codice sia in termini di sviluppo) che usare gli automatismi invece che re inventare la ruota fornisce.

Per concludere, sto contestando l'affermazione che il Kernel di Linux non possa essere scritto in C++ perche' sarebbe intrinsecamente peggiore. Non e' vero, molto probabilmente ne uscirebbe un prodotto migliore per i motivi che ho elencato.

Secondo me dovrebbero fermare tutto e riscriverlo in C++ ora? Ovviamente sarebbe pura follia, richiederebbe mesi, dovrebbe essere ritestato dall'inizio, io non farei mai una tale scelta.

Non occorre leggere libri per fare un buon modulo per il kernel, né avere ddk particolari, basta saper programmare

(*) ehm...siamo un pò a corto di programmatori per driver 3d...

Il tempo libero a mia disposizione oggi e' stato esaurito scrivendo questi post
Pero' se riuscissi a installare una distribuzione Linux funzionante, con ambiente di sviluppo in un tempo ragionevole inferiore alla settimana (ci ho provato negl'ultimi anni e non ci sono mai riuscito, sono niubbo), sarebbe anche interessante.
Non fosse che non c'e' modo di avere accesso alle specifiche interne delle GPU piu' recenti.

[][xwilsonx][]

Originariamente inviato da Ikitt_Claw
Come dici tu stesso piu` sopra, senza i driver del produttore tutto si complica.
Comunque, questo e` un problema di supporto HW

Si ma la balla che win nn è facile da usare, proprio nn regge...
E' questo il punto