google paga per programmare open source

[recoil]

Originariamente inviato da mjordan

Ho letto bene le email che si scambiavano Torvalds e Tanembaum, ma sinceramente litigavano per delle questioni inesistenti. Torvalds era molto presuntuoso e diceva che Minix era limitato (e questo e' vero ma non un difetto visto che Minix doveva essere un sistema didattico i cui sorgenti andavano stampati in un libro di Sistemi Operativi), le risposte che dava Tanembaum quindi erano fuori luogo.

si le ho lette pure io, cercando su google gruppi si trovano ancora

la mia cmq era una battuta, non voglio mancare di considerazione né verso Torvals né verso Tanembaum.
solo che si beccavano come due galletti e la cosa era piuttosto buffa

Non ho avuto modo di vedere il suo libro sulle reti, ma su Amazon.com lo definiscono un altro classico di quelli imperdibili.

beh il libro è fatto bene anche se ho la versione italiana. però quando ne ho dovuto scegliere uno sui sistemi distribuiti ho puntato su altri autori. non esiste solo Tanembaum dopotutto (anche se a livello universitario da noi monopolizza i corsi di SO e reti).

Quindi W TORVALDS ma anche W Tanembaum.

sicuramente

e leggetevi il loro battibecco perché è una figata
http://groups.google.it/group/comp.o...5c4a78723eeef5

[fek]

Originariamente inviato da recoil

Tanembaum è lo stesso che ha detto a Torvalds "nel mio corso di sistemi operativi avresti preso un brutto voto".

E non faccio fatica a crederci

Originariamente inviato da mjordan

Torvalds e' un grande uomo. Uno che ha sempre preferito il codice alla figa

Abbiamo gusti diversi, io ho sempre preferito il buon codice e la bella figa

Originariamente inviato da AnonimoVeneziano

fek ha consigliato più volte una riscrittura del kernel linux in C++

Risposta seria adesso. Ormai non penso che il Kernel di Linux debba essere riscritto in C++, sarebbe un lavoro enorme, tanto varrebbe buttare tutto e ripartire da zero, ma anche questo sarebbe impossibile.

Io ho sempre affermato che e' falso che il Kernel di un SO come Linux non possa essere scritto in C++, affermato soprattutto da chi adduce come argomento il fatto che il C++ sarebbe piu' lento del C e presenterebbe un overhead al programmatore. E' falso anche questo, ed e' vero il contrario: spesso e volentieri non e' possibile scrivere codice C veloce, compatto ed efficiente come l'equivalente codice C++, per svariati motivi, fra i quali il fatto che un compilatore C++ "conosce" internamente concetti che un compilatore C non conosce ed e' in grado di usarli per produrre codice piu' ottimizzato. Un esempio potrebbe essere implementare una tabella di dispatch virtuale, oppure ordinare un vettore di elementi dove il tipo degli elementi non e' conosciuto a priori.

E' vero pero' che per chi non conosce il C++ e' piu' facile scrivere codice inefficiente, rispetto a chi non conosce il C. Infatti faccio spesso questa battuta rifermendomi a Torvalds e alla sua famosa affermazione: "Non si puo' scrivere un kernel in C++ perche' in C++ non si possono scrivere allocatori custom". Quando fece quest'affermazione probabilmente non sapeva che in C++ si possono scrivere allocatori custom e sono piu' efficienti che in C. Avrebbe potuto impararlo meglio

[71104]

Originariamente inviato da fek

Abbiamo gusti diversi, io ho sempre preferito il buon codice e la bella figa

sai apprezzare i piaceri della vita!!
ma non sottovalutare le tette!!!
vabbè, basta va' ^^'

cmq imho il C++ sarebbe perfetto per scrivere un kernel: un kernel normalmente ha necessariamente delle caratteristiche che richiamano immediatamente la OOP, per le quali il C++ è ottimo; ma è anche vero che non è necessario scrivere solo classi, come in Java: in qualunque momento puoi usare variabili e funzioni di livello globale, come tante ce ne sono in un kernel.
il kernel infatti può anche essere implementato in C++, ma le interfacce messe a disposizione dei programmi devono comunque essere C perché non è detto che il programma applicativo che gira sul sistema operativo sia scritto in C++ o in un linguaggio che supporta le classi.

[cisc]

dato che questo thread è andato completamente OT, l'avete provato hurd?? che ne pensate?

[VICIUS]

Originariamente inviato da 71104

sai apprezzare i piaceri della vita!!
[...]come in Java: in qualunque momento puoi usare variabili e funzioni di livello globale, come tante ce ne sono in un kernel. [...]

Funzioni e variabili globali sono il male! Meglio evitarle se possibile.

ciao

[fek]

Originariamente inviato da VICIUS

Funzioni e variabili globali sono il male! Meglio evitarle se possibile.

ciao

Funzioni e variabili globali NON esistono. E NON esistono neppure i Singleton

[71104]

Originariamente inviato da cisc

dato che questo thread è andato completamente OT, l'avete provato hurd?? che ne pensate?

vabbè ma non esageriamo! almeno nell'OT sii IT!

[71104]

Originariamente inviato da VICIUS

Funzioni e variabili globali sono il male! Meglio evitarle se possibile.

eeeehhh???
scusa, ora perché funzioni e variabili globali sarebbero dannose??
considera che oggi numerosissime librerie (sia in Windows che in Linux) hanno interfacce basate su funzioni globali...

[71104]

Originariamente inviato da fek

Funzioni e variabili globali NON esistono. E NON esistono neppure i Singleton

ssssiiiiiii, evvai!!!!! questo thread è stato fin quasi dall'inizio un delirio completo...

[Brazorv]

Originariamente inviato da 71104

ssssiiiiiii, evvai!!!!! questo thread è stato fin quasi dall'inizio un delirio completo...

il delirio è iniziato con il tuo primo post

[fek]

Originariamente inviato da 71104

ssssiiiiiii, evvai!!!!! questo thread è stato fin quasi dall'inizio un delirio completo...

Mi stai dicendo che affermare che un buon design non prevede mai variabili globali e' un delirio?

Lo sai che esistono linguaggi che non ti permettono neppure di definire variabili globali? Alcuni linguaggi come Eiffel arrivano anche a non permetterti di definire in maniera semplice un campo statico di una classe.

[71104]

Originariamente inviato da fek

Mi stai dicendo che affermare che un buon design non prevede mai variabili globali e' un delirio?

Lo sai che esistono linguaggi che non ti permettono neppure di definire variabili globali? Alcuni linguaggi come Eiffel arrivano anche a non permetterti di definire in maniera semplice un campo statico di una classe.

in Java ci sono solo classi, lo so; ma secondo me non è vero che la "globalità" implica necessariamente un design concettualmente errato.
se definisco una variabile globale vuol dire che nel design che ho progettato nella mia testa, il contenuto di quella variabile è concettualmente globale, cioè è accessibile ovunque nell'ambito del modulo corrente. per quale motivo questo implicherebbe che il mio design è errato o non è buono?

[fek]

Originariamente inviato da 71104

in Java ci sono solo classi, lo so; ma secondo me non è vero che la "globalità" implica necessariamente un design concettualmente errato.
se definisco una variabile globale vuol dire che nel design che ho progettato nella mia testa, il contenuto di quella variabile è concettualmente globale, cioè è accessibile ovunque nell'ambito del modulo corrente. per quale motivo questo implicherebbe che il mio design è errato o non è buono?

Perche' non e' un design facile da testare automaticamente

[theClimber]

Originariamente inviato da 71104

in Java ci sono solo classi, lo so; ma secondo me non è vero che la "globalità" implica necessariamente un design concettualmente errato.
se definisco una variabile globale vuol dire che nel design che ho progettato nella mia testa, il contenuto di quella variabile è concettualmente globale, cioè è accessibile ovunque nell'ambito del modulo corrente. per quale motivo questo implicherebbe che il mio design è errato o non è buono?

Questo e vero, il design sarebbe buono. E la globalita' non esisterebbe, ma risulterebbe 'contestualizzata' al modulo. E la classe in java puo' essere usata con solo metodi statici per creare un modulo.

Il problema purtroppo e' nell'implementazione dei linguaggi correnti piu' usati (Java, C++ ..), nei quali le classi non sono oggetti veri e propri, ma strutture sintatiche diverse. Quindi usando metodi/variabili globali si perdono le funzionalita' proprie degli oggetti (Ereditarieta', polimorfismo, overloading, override). Inoltre la classe ha un ciclo di vita (ad es. in java deve essere caricata dal classloader in momenti ben precisi, in C++ non entro nei dettagli ...... non e' il mio forte ) che ti limita nel riusarla e nel testarla (come ti ha detto fek)

Non e' detto che tutti i linguaggi devono essere cosi': In smalltalk ad esempio la classe e' un oggetto vero e proprio, i metodi di classe sono normali metodi dell'oggetto e seguono esattamente le stesse regole (ad esempio avrei un istanza della classe String. La classe String e' un oggetto, istanza della classe MetaClass, che e' un oggetto .. etc ... )

[71104]

Originariamente inviato da fek

Perche' non e' un design facile da testare automaticamente

perché scusa?

[71104]

Originariamente inviato da theClimber

[...] Il problema purtroppo e' nell'implementazione dei linguaggi correnti piu' usati (Java, C++ ..), nei quali le classi non sono oggetti veri e propri, ma strutture sintatiche diverse. Quindi usando metodi/variabili globali si perdono le funzionalita' proprie degli oggetti (Ereditarieta', polimorfismo, overloading, override). Inoltre la classe ha un ciclo di vita (ad es. in java deve essere caricata dal classloader in momenti ben precisi, in C++ non entro nei dettagli ...... non e' il mio forte ) che ti limita nel riusarla e nel testarla (come ti ha detto fek)

eeehmmmmm... non ho capito una sola parola... o_o''
che vuol dire che le classi non sono oggetti veri e propri? una classe è una cosa, un oggetto un'altra...
ma poi cosa c'entrano le classi e gli oggetti con le funzioni e variabili globali? se dichiaro una cosa come globale non voglio mica usare l'ereditarietà e il polimorfismo su di essa...
e poi ancora devo capire che limitazioni ci sono nel testing; e nel riusarla poi???

Non e' detto che tutti i linguaggi devono essere cosi': In smalltalk ad esempio la classe e' un oggetto vero e proprio, i metodi di classe sono normali metodi dell'oggetto e seguono esattamente le stesse regole (ad esempio avrei un istanza della classe String. La classe String e' un oggetto, istanza della classe MetaClass, che e' un oggetto .. etc ... )

"la classe è un oggetto vero e proprio" temo che sia una frase insensata in qualunque linguaggio... il concetto di classe è diverso dal concetto di oggetto.

[fek]

Originariamente inviato da 71104

eeehmmmmm... non ho capito una sola parola... o_o''
che vuol dire che le classi non sono oggetti veri e propri? una classe è una cosa, un oggetto un'altra...

Vuol dire che in linguaggi come Smalltalk una classe e' a sua volta un oggetto istanza di una metaclasse; puoi creare classi dinamichemente come fossero oggetti, aggiungere e togliere metodi e poi creare oggetti a partire da queste classi, tutto a runtime

In altri linguaggio come C# e Java si chiama reflection. In C++ non esiste reflection.

e poi ancora devo capire che limitazioni ci sono nel testing; e nel riusarla poi???

Il primo principio del testing e' che ogni test non influenzi gli altri test, altrimenti il fallimento o il successo di un test puo' dipendere da cose come l'ordine di esecuzione dei test stessi e diverrebbe drammatico gestirli.
Se hai variabili globali usate dai test (oppure oggetti singleton), vuol dire che ogni test ha potenzialmente effetto su gli altri test via le variabili globali e deve ricordarsi di ripristinare il loro valore dopo averle usate. In un progetto grosso diventa molto complicato seguire queste regole e poi capire quando si dimentica di seguirle. E' meglio evitare le variabili globali totalmente; il design ne esce di solito piu' pulito e modulare, piu' semplice e piu' facilmente testabile.

[71104]

ecco la risposta che mi hai chiesto (spero di aver capito bene a quale post ti riferivi; era questo, no?)

Originariamente inviato da fek

Peccato che sia degenerata perche' sono entrambi molto preparati.

lui non è preparato, almeno non credo: non scommetterei nulla sulla sua preparazione.

Provo a trarre dalla discussione qualche spunto piu' generale. Senza entrare nel merito di come WINE e Linux funzionano perche' non sono particolarmente preparato su entrambi, secondo me 71104 sbaglia l'approccio al problema da un punto di vista Ingegneristico, piu' che tecnico. Dal punto di vista tecnico mi sembra che quello che propone sia fattibile.

come potrebbe non esserlo? si tratta di fare manualmente qualcosa che qualcun altro (Linux) già fa, e si tratta di farlo più velocemente (praticamente uno strato User Mode viene eliminato; vi sembra poco come ottimizzazione?)

L'errore e' piuttosto comune: 71104 propone una modifica del design dell'architettura di WINE con lo scopo di migliorare le prestazioni dell'applicazione. In se' questo non e' un errore, l'errore nasce nel momento in cui il miglioramento delle prestazioni non e' supportato da dati evidenti e incontrovertibili che derivano dal profiling dell'applicazione. Semplici numeri.

questo discorso sinceramente e senza offesa mi pare che regga poco, specialmente quando si parla di opensource: per avere un risultato evidente e tangibile basta scrivere uno scheletro di driver e uno scheletro di "processo WINE"; poi fai in modo che il driver veda il processo WINE e che i due abbiano la possibilità di comunicare, installi il driver, fai in modo che il processo WINE abbia il permesso di entrare in kernel mode, e fai qualche prova di comunicazione. a seconda di quanto ci metti a fare il tutto dovresti farti un'idea della complessità del progetto, che secondo me non è eccessivamente elevata a patto che sia soddisfatto il requisito che a lavorarci siano persone che abbiano esperienza in kernel mode in Linux; secondo me se questo requisito è soddisfatto, a fare la prova ci vuole una mezz'ora.

[...] In parole, WINE nella seconda architettura dipende direttamente sia dall'interfaccia del Kernel, sia dall'interfaccia dei driver, se cambia per qualche motivo una delle due, WINE deve modificarsi di conseguenza.

è assurdo che cambi l'interfaccia dei drivers; anzi, può anche cambiare, ma quella vecchia deve essere ancora supportata!! se è vero che un produttore di hardware deve riscriversi i driver per ogni periferica che produce ad ogni nuova versione di Linux, allora Linux è semplicemente da buttare!!!

Nella prima architettura WINE dipende solo dal Kernel, se l'interfaccia dei driver cambia, il Kernel deve cambiare implementazione, ma la sua interfaccia esterna si mantiene stabile (se non si mantenesse stabile chi scrive il Kernel dovrebbe autoflagellarsi),

a doversi autoflagellare sono i produttori di hardware (ma se voi doveste decidere tra autoflagellarvi e buttare via Linux che scegliereste? ), perché l'interfaccia viene decisa da chi scrive il kernel.

[...] Quindi 71104 propone di aumentare la complessita' del sistema in favore di un aumento prestazionale.

be' guarda, se a lavorarci sono persone esperte di programmazione in kernel mode, l'aumento di complessità è minimo (mentre l'aumento prestazionale rimane sempre notevole).

In se' non sarebbe sempre e comunque una cosa negativa da fare, a volte e' una scelta necessaria e intelligente, ma stiamo pagando in termini di complessita'

ribadisco: paghiamo relativamente.

qualcosa e questo qualcosa deve essere dimostrato ripagare la spesa. Nessuno pagherebbe per una macchina che il commerciante ci giura accendersi, ma non ci ha mai mostrato.

per dimostrarlo basta poco, giusto qualche prova come quella che ho descritto sopra; anzi, se le persone che ci lavorano sono esperte di programmazione in kernel mode, probabilmente non serve neanche quella.

La regola generale e': si favorisce sempre e comunque la semplicita' del design e dell'implementazione, a meno che non esistano dati precisi e incontrovertibili che dimostrano la necessita' di un'ottimizzazione, e esista un requisito che la richieda.

questi dati in questo caso è facilissimo ottenerli; be' almeno lo è relativamente: è chiaro che se arriva uno che non sa nemmeno cosa sia la protezione ma che sa solo ammucchiare qualche riga di C, è chiaro che non può ne' provare la fattibilità della cosa, ne' essere ammesso nel team di sviluppo di un simile progetto

In inglese: "Early optimazation is the root of all evil".

questi inglesi finora mi sembrano aver affermato un sacco di boiate ^^'
cioè, prima la paura causa la rabbia
adesso l'"ottimizzazione precoce" (qualunque cosa sia... ) sembra essere diventata la causa di tutti i mali...
i rapporti causa-effetto più sballati li trovano loro
secondo loro qualsiasi errore che si possa commettere in programmazione è causato da un'ottimizzazione precoce? se mi dimentico di liberare una variabile in un server tcp/ip e un hackerazzo da 4 soldi sfrutta il memory leak per creare un DoS, è stata colpa di una ottimizzazione?
mmmmmaahhhh...

[71104]

Originariamente inviato da fek

Vuol dire che in linguaggi come Smalltalk una classe e' a sua volta un oggetto istanza di una metaclasse; puoi creare classi dinamichemente come fossero oggetti, aggiungere e togliere metodi e poi creare oggetti a partire da queste classi, tutto a runtime

In altri linguaggio come C# e Java si chiama reflection. In C++ non esiste reflection.

ok, non lo sapevo e ho imparato una cosa nuova, ma cosa c'entra sta roba con le variabili e funzioni globali?

Il primo principio del testing e' che ogni test non influenzi gli altri test, altrimenti il fallimento o il successo di un test puo' dipendere da cose come l'ordine di esecuzione dei test stessi e diverrebbe drammatico gestirli.
Se hai variabili globali usate dai test (oppure oggetti singleton), vuol dire che ogni test ha potenzialmente effetto su gli altri test via le variabili globali e deve ricordarsi di ripristinare il loro valore dopo averle usate. In un progetto grosso diventa molto complicato seguire queste regole e poi capire quando si dimentica di seguirle. E' meglio evitare le variabili globali totalmente; il design ne esce di solito piu' pulito e modulare, piu' semplice e piu' facilmente testabile.

a parte che le variabili e funzioni globali capitano raramente (parlo per esperienza, almeno per me è così), comunque basterebbe testare le condizioni dei dati globali e dei singleton dopo l'esecuzione di ciascun test (e anche all'inizio, prima di qualsiasi test). questo potrebbe aumentare la quantità di codice da scrivere, ma non eccessivamente. e comunque secondo me i test aumentano inutilmente il tempo di sviluppo in ogni caso, con o senza roba globale e singleton. ma di questo ne stiamo parlando altrove

[mjordan]

lui non è preparato, almeno non credo: non scommetterei nulla sulla sua preparazione.

Sei proprio seccante e di una presunzione unica.
Certo, dare del non preparato a me, "progettare" una nuova architettura, dire che l'aumento della complessita' e' minimo e poi sta ancora a imparare la pericolosita' delle variabili globali