PDA

View Full Version : Microsoft: identificate 22 nuove vulnerabilità


Pagine : [1] 2

Redazione di Hardware Upg
14-10-2004, 10:56
Link alla notizia: http://news.hwupgrade.it/13336.html

Microsoft ha rilasciato il bollettino di Ottobre: 22 nuove vulnerabilità scoperte pronte per essere fixate

Click sul link per visualizzare la notizia.

romeop
14-10-2004, 11:03
spero siano scaricabili in automatico da windows update

Max Power
14-10-2004, 11:04
http://slonce.com/ThanksfortheInfo.jpg

Spectrum7glr
14-10-2004, 11:11
automatic update aveva già fatto il suo dovere segnalandomi l'esistenza di pacth importanti già l'altro ieri.

luther_zero
14-10-2004, 11:11
Se metti due cassette di mele una vicino all'altra, ed una è infestata dai vermi, prima o poi arrivano anche in quella sana!!!
Sembra che stia succedendo con il Mac in caso di uso di software M%...

trecca
14-10-2004, 11:24
olè! :rolleyes:

dnarod
14-10-2004, 11:38
tra parentesi: a parte il solito discorso trito e ritrito sul fatto che win è usato piu (quindi si scoprono piu buchi), ma ms rilascia patch che risolvono i problemi......con altri os in una miriade di casi i problemi non sono risolvibili (vedi supporto e drv hw non ancora scritti, quindi hw non utilizzabile) e nei casi fortunati devi "solo" ricompilare i sorgenti di qualcosa scritta da qualcuno che non sai chi è.....
da qualche giorno uso indistintamente linux (debian sarge) e winxp e mi trovo benissimo con ciascuno: solo che con debian non (non) posso fare una marea di cose e i problemi spuntano giornalmente, mentre con win ho il problema della sicurezza; anche se in molti casi con linux i problemi si possono risolvere, devo dire che con win i problemi non si presentano proprio! ma perche non tacere ogni tanto e provare ad usare in base alle esigenze/stimoli? ripeto, io uso xp e debian e non mi sento di declassare nessuno dei due: xp è stabile, affidabile e semplice, mentre debian è configurabile, potente, gratis
cmq se fossi un mod io eviterei i reply ad ogni news di questo genere, tanto per andare sul sicuro ;-)

Onda Vagabonda
14-10-2004, 11:38
Credo che update di oggi risolverà la maggior parte dei problemi, richiede anche il riavvio.
Per quanto riguarda mac... considerato il livello di "personalizzazione" che permette, potrette essere un sistema in futuro più instabile, delle patch potrebbero risolvere i problemi di alcuni ma non risolvere quelli di altri... cosa ne pensate?

Mad Penguin
14-10-2004, 11:46
Originariamente inviato da luther_zero
Se metti due cassette di mele una vicino all'altra, ed una è infestata dai vermi, prima o poi arrivano anche in quella sana!!!
Sembra che stia succedendo con il Mac in caso di uso di software M%...


:rotfl:

DevilsAdvocate
14-10-2004, 11:56
Non capisco perche' tirare in ballo Linux per la n-esima
volta. A parte il discorso Debian l'unico problema che
si puo' imputare al pinguino e' la ATI che non sembra
minimamente intenzionata a fare uscire drivers binari
per Xorg (purtroppo per le schede video di sorgenti non
se ne e' mai vista l'ombra...).
Windows e Linux hanno circa lo stesso numero di vulnerabilita' (come e' ovvio). L'unica differenza e'
che linux e' open source quindi le vulnerabilita' ve le potete scovare anche da voi, nel bene e nel male,
come sta succedendo in questo periodo con la distro
Gentoo dove ne vengono rilevate e corrette parecchie
giornalmente.
Sotto Windows molte vulnerabilita' vengono scoperte dopo che si e' diffuso il relativo virus,e, peggio che
mai, ci sono componenti di windows (aggiornamenti automatici...) che "a vostra insaputa" si collegano ai
servers di mamma Microsoft,non oso pensare a come un
hacker/virus writer potrebbe trarre vantaggio da questo, visto che basta cambiare il file hosts per farvi connettere dove vuole lui, ogni volta che accendete il pc.

Tralasciando questo, pinguino ed Xp possono tranquillamente coesistere, magari usando Xp offline ed il pinguinozzo per andare in rete.........

Motosauro
14-10-2004, 12:00
quoto in pieno
(fossi riuscito a far andare la scheda wireless usb sulla SUSE... 2 ore di tentativi :( )

Mad Penguin
14-10-2004, 12:01
Originariamente inviato da Onda Vagabonda
Credo che update di oggi risolverà la maggior parte dei problemi, richiede anche il riavvio.
Per quanto riguarda mac... considerato il livello di "personalizzazione" che permette, potrette essere un sistema in futuro più instabile, delle patch potrebbero risolvere i problemi di alcuni ma non risolvere quelli di altri... cosa ne pensate?
mmm mah è un discorso controverso...(forse no ho capito bene cosa intendi)
dipende tutto da chi sviluppa i programmi, cmq è innegabile che avendo meno falle gravi, non facendoti loggare come automaticamente come "root" è intrinsecamente + stabile.

Motosauro
14-10-2004, 12:03
1) Win update non si connette ogni volta che vuole: basta dirgli di connettersi solo a comando e così fa
2) A onor del vero finora quasi tutti i virus e porcherie varie hanno sfruttato falle venute a galla DOPO che microzozz aveva buttato fuori la patch per chiuderle

Spyto
14-10-2004, 12:09
Ogni volta che si trova una falla in Windows ecco che ci sono persone per buttano malelingue su detto sistema. Io non capisco sappiamo tutti i difetti che ha Windows, sappiamo tutti che Linux/Mac non sono esenti da detti difetti ma ne hanno in minima parte.
Se non vi va bene Windows passate su altri SO.

DevilsAdvocate
14-10-2004, 12:22
Ahahahahahahahahahahahahahahhahahahahahhahahaah

Prendi un firewall decente e goditi tutti i tentativi
di accesso a v5stats.xxxx e v5update.xxxxxx
E se provi a impostare su manuale il servizio aggiornamenti automatici poi non ti funziona piu' il
windowsupdate, devi tenerlo su automatico.
Ovviamente io sto parlando di SP2, senza crack ne hack
(ma con xp-antispy funzionante ed usato al 100%)

Mad Penguin
14-10-2004, 12:23
Originariamente inviato da Spyto
Ogni volta che si trova una falla in Windows ecco che ci sono persone per buttano malelingue su detto sistema. Io non capisco sappiamo tutti i difetti che ha Windows, sappiamo tutti che Linux/Mac non sono esenti da detti difetti ma ne hanno in minima parte.
Se non vi va bene Windows passate su altri SO.

io lo ho già fatto

ma cmq non è cosi semplice:
linux è ancora troppo acerbo, troppe distro in circolazione, troppe cose da ricompilare, poco user friendly
mac... beh per me è bellissimo, solo l'hardware consente poca espandibilità, e poi non è a prezzi popolari( ciò non toglie che io comprerò sempre e solo mac, il pc in sign è già passato a linux da un po')

ciao :)

DevilsAdvocate
14-10-2004, 12:24
Windows e' facile da usare, questo non lo mette in dubbio nessuno.Per gli utenti alle prime armi e' scelta
obbligata.

Mad Penguin
14-10-2004, 12:35
beh per un utente alle prime armi allora osx è ancora + facile...

zoboliluca
14-10-2004, 12:37
Originariamente inviato da dnarod
...con altri os in una miriade di casi i problemi non sono risolvibili (vedi supporto e drv hw non ancora scritti, quindi hw non utilizzabile) e nei casi fortunati devi "solo" ricompilare i sorgenti di qualcosa scritta da qualcuno che non sai chi è.....


Stai scherzando vero.

Per quanto riguarda di driver hw e' proprio microsoft la prima che non li scrive. Ad ogni passaggio di sistema operativo da Win98-Me-XP e anche da NT3.5-NT3.52.NT4.0-W2000 tutti (noi utenti) siamo stati costretti a buttare hw in quanto i driver non esistono o non funzionano. Vedi il mio scanner HP3300C che mi funziona solo sotto Win98 perche' i driver WinXP non vanno. Oppure una scheda SCSI storica i cui driver per NT3.5 piantavano di brutto NT4.0 (e ovviamente non esistevano i driver aggiornati).
Io ricordo ancora OS2 sul quale potevi caricare i driver di uno scanner per Dos 2.30 e lo scanner andava. IBM a mia memoria e' sempre stata l'unica societa' a tenere in considerazione il parco hw installato. Quando OS2 3.0 Warp e' uscito nella stessa confezione era presente un intero CD di Driver e comunque nel 99% dei casi i vecchi driver per dos andavano comunque bene (forse non al massimo ma andavano).

Quest'ultimo esempio e la mia esperienza di programmatore (anche se non mi occupo di driver) mi porta ad affermare con una discreta sicurezza che la retro-compatibilita dei driver (vecchi driver su nuovi so) e' assolutamente possibile e la non realizzazione e' solo una questione di volonta' politica (e non di costo).

Ti lamenti perche quando esce un nuovo hw devi ricompilare dei sorgenti?
Perche quando compri del nuovo hw devi controllare se sono supportati dal s.o che vuoi utilizzare?
O perche' devi aspettare a comprare finche' non sono stati preparati i driver (questo comunque anche con M$)?

Beh, io mi lamento perche' la Microsoft ogni 3-4 anni mi obbliga a buttare delle periferiche funzionanti che sto utilizzando con soddisfazione, costingendomi a spedere altri soldi per comprarne altre che tra 3-4 anni dovro' nuovamente buttare.

In conclusione IO PREFERISCO avere dei limiti di scelta nell'acquisto del hw che essere costretto a comprare nuovi modelli di hw che ho gia'.

Scusa se ne ho approffittato per sfogarmi, non ce l'ho con te ma con la M$ sia per lo scanner di cui sopra, sia per tutti i problemi di compatibilita' di driver sui quali ho sbattuto il naso sul lavoro.

CIAO

PS. Accetto scommesse.
Quanto hw dovremo buttare all'arrivo di LongHorn?

Spyto
14-10-2004, 12:38
@Mad Penguin
Lo sappiamo tutti che Linux non è facile per prima cosa, poi che sia acerbo non ci sono dubbi, ma come fanno molti con Linux si può andare tranquillamente su internet, usare Office...
Bisogna capire che Linux nasce per i programmatori, che risolvono da loro i problemi del S.O. e una volta avviato correttamente non ci ritornano sopra.

Se si intende giocare e avere amplia scelta di giochi ce sempre Windows. Tantissimi programmi vengono compilati solo per Win e quindi lo capisco che tante persone che vorrebbero cambiare sistema si sentono frenare. Quindi conviene comprare un buon firewall e antivirus e tirare avanti con i bug :rolleyes:

Tutto questo mio discorso logicamente e fatto per SO che vengono utilizzati a casa. Per lavoro se ci sono i programmi adatti è consigliabile solo Linux/Mac.

Mad Penguin
14-10-2004, 12:46
beh ma dai se è un discorso di giochini meglio farsi uma console... :)

raptus
14-10-2004, 12:54
... Anche io usavo WARP, ma credimi: i driver per il vecchio DOS non sono compatibili: sono scritti per la modalità virtuale, qui non si lavora che in modalità protetta (MENOMALE aggiungo!) Inoltre driver aggiornati ti danno molta più performance.
Inoltre i driver dovrebbero essere un problema per chi fa l'HW, non il SW! In atre parole non posso certo prendermi 'onere di fare driver per tutto ciò che gira nel globo! altro che DVD DL servirebbero !!!
Io me la prenderei con HP piuttosto, ma vedrai che anche loro abranno la sua ... Eppoi se non sbaglio danno driver solo per 5 anni, ma non è detto ...
Credimi: meglio così o piuttosto la possibilità di poterli scrivere più semplicemente. Io ho provato a vedere la difficoltà di scrivere un driver MS. Ci ho rinunciato subito!!!

DioBrando
14-10-2004, 12:56
Originariamente inviato da Mad Penguin
beh ma dai se è un discorso di giochini meglio farsi uma console... :)

alè così dai soliti discorsi "il mio OS è meglio del tuo" passiamo anche a quelli del "ma quanto sei scemo a spendere per giocare col pc tanto c'è l'Xbox e la PS2 che rullano molto di +"


Euuiua Euuiua :D

Motosauro
14-10-2004, 12:58
Originariamente inviato da DevilsAdvocate
Ahahahahahahahahahahahahahahhahahahahahhahahaah

Prendi un firewall decente e goditi tutti i tentativi
di accesso a v5stats.xxxx e v5update.xxxxxx
E se provi a impostare su manuale il servizio aggiornamenti automatici poi non ti funziona piu' il
windowsupdate, devi tenerlo su automatico.
Ovviamente io sto parlando di SP2, senza crack ne hack
(ma con xp-antispy funzionante ed usato al 100%)


Andrò a spulciarmi meglio i log del sygate....:confused:
Comunque in manuale il winupdate funzia senza problemi
E la mia chiave di Xp l'ho comprata e pagata ;)

È cmq vero che ogni tanto i comunicati di M$ riguardo alle falle che trova fanno salire gli occhi al cielo; più per la forma che per la sostanza :(

Spyto
14-10-2004, 13:01
Originariamente inviato da Mad Penguin
beh ma dai se è un discorso di giochini meglio farsi uma console... :)
Non è un discorso di giochi, la colpa e mi che forse mi sono espresso male, ma è un discorso per cosa usi un computer.
Io a casa il computer lo uso un per tutto e molti programmi che uso non ci sono per Linux, nessun problema utiliziamo Win. Alla fine io leggo molti commenti di persone che decantano Linux-Mac-Win (ogniuno il suo), senza capire che il SO migliore è quello che serve per le nostre esigenze.

Ganesh74
14-10-2004, 13:05
ragazzi non capisco perche' non riesco a passare questi 3 aggiornamenti gli altri me li ha installati correttamente ma questi 3 proprio non vanno:
Download di Aggiornamento della protezione per Windows XP (KB840987)
Download di Pacchetto cumulativo di aggiornamenti della protezione per Internet Explorer 6 Service Pack 1 (KB834707)
Download di Strumento di rilevamentodi Microsoft gdi+(KB873374)

qualcuno mi puo' aiutare????

grazieee

Mad Penguin
14-10-2004, 13:09
ma infatti... io manco c'è l' ho la console...
solo che se uno prende il pc per giocare... bah

liberissimi comunque, non era mia intenzione fare polemica, forse mi sono espresso un po' male anche io scusate.

DevilsAdvocate
14-10-2004, 13:12
di sygate non so dirti molto, anche se mi pare che con un istallazione pulita si noti tranquillamente (su un OEM,quindi regolarmente pagato) un accesso da svchost
a v5stats.micro****.com ogni volta che ti colleghi in rete.
Con Outpost pro 2.1 oppure 8signs firewall e' visibile
e andare sotto risorse del computer->proprieta'->aggiornamenti automatici->Disattiva
(aggioranmenti automatici) per effettuare solo aggiornamento manuale non risolve il problema,
SP2 chiama casa lo stesso e chi usa il firewall integrato non se ne accorge nemmeno.
(P.S.: con outpost 2.5 non metterei la mano sul fuoco
che il problema si noti, visto che e' stato programmato in collaborazione con Micro****.

Ganesh74
14-10-2004, 13:13
mi sono dimenticato di dirvi che sto provando con windows update e che sembra come se non riuscisse a connetrsi alla fine mi dice ..
I seguenti aggiornamenti non sono stati installati:
Aggiornamento della protezione per Windows XP (KB840987)
Pacchetto cumulativo di aggiornamenti della protezione per Internet Explorer 6 Service Pack 1 (KB834707)
Strumento di rilevamento Microsoft GDI+ (KB873374)

ContiF
14-10-2004, 13:13
... mi contatti x favore

Chiedo scusa a tutti gli altri x l'OT
[/OT]

DjMix
14-10-2004, 13:27
Originariamente inviato da Spyto
Lo sappiamo tutti che Linux non è facile per prima cosa

Oddio... mia sorella e altri miei amici (assolutamente NON programmatori o affini) non lo sanno.. e così lo usano

Originariamente inviato da Spyto
poi che sia acerbo non ci sono dubbi

Permettimi di averne qualcuno

Originariamente inviato da Spyto
ma come fanno molti con Linux si può andare tranquillamente su internet, usare Office...

Verissimo

Originariamente inviato da Spyto
Bisogna capire che Linux nasce per i programmatori

Bisogna capire che questa è una emerita stupidaggine...

Originariamente inviato da Spyto
che risolvono da loro i problemi del S.O.

Beh non è che con windows i "programmatori" non si risolvano le rogne eh! Ma tanto per mettere i puntini sulle i, ne con win ne con lin un normale utente si risolve i problemi: và dall'amico che ne sa di più, in ogni caso.

Originariamente inviato da Spyto
Se si intende giocare e avere amplia scelta di giochi ce sempre Windows. Tantissimi programmi vengono compilati solo per Win e quindi lo capisco che tante persone che vorrebbero cambiare sistema si sentono frenare. Quindi conviene comprare un buon firewall e antivirus e tirare avanti con i bug

Vero, ci son più giochi per win che lin. Si spera che la situazione cambi.. cmq un dualboot è un'ottima soluzione, a mio parere

Originariamente inviato da Spyto
Tutto questo mio discorso logicamente e fatto per SO che vengono utilizzati a casa. Per lavoro se ci sono i programmi adatti è consigliabile solo Linux/Mac.
Anche il mio discorso è fatto per SO da casa, infatti i miei amici lo usano sul loro pc, e gli va benissimo. Tra parentesi: hanno windows in dual boot, quindi non sono affatto costretti a linux; se lo usano, hanno i loro motivi.

Non ce l'ho con te, ma con sta idea del "programmatore" e del "windows facile" che sono veramente delle balle mostruose, ma pochi se ne rendono conto, quasi sempre perchè non conoscendo niente oltre che windows, non possono valutare. Ti consiglio di nutrire dubbi su quanto hai detto, perchè molte persone ormai si son accorte che la chimera "windows facile e user friendly" si sta sgretolando inesorabilmente.

Duncan
14-10-2004, 13:45
Originariamente inviato da dnarod
tra parentesi: a parte il solito discorso trito e ritrito sul fatto che win è usato piu (quindi si scoprono piu buchi), ma ms rilascia patch che risolvono i problemi......con altri os in una miriade di casi i problemi non sono risolvibili (vedi supporto e drv hw non ancora scritti, quindi hw non utilizzabile) e nei casi fortunati devi "solo" ricompilare i sorgenti di qualcosa scritta da qualcuno che non sai chi è.....
da qualche giorno uso indistintamente linux (debian sarge) e winxp e mi trovo benissimo con ciascuno: solo che con debian non (non) posso fare una marea di cose e i problemi spuntano giornalmente, mentre con win ho il problema della sicurezza; anche se in molti casi con linux i problemi si possono risolvere, devo dire che con win i problemi non si presentano proprio! ma perche non tacere ogni tanto e provare ad usare in base alle esigenze/stimoli? ripeto, io uso xp e debian e non mi sento di declassare nessuno dei due: xp è stabile, affidabile e semplice, mentre debian è configurabile, potente, gratis
cmq se fossi un mod io eviterei i reply ad ogni news di questo genere, tanto per andare sul sicuro ;-)

Discorso vero... però può essere anche che Linux lo conosci meno di windows e i problemi li hai per questo...


Anche perchè, per fare un esempio, c'è gente che telefona in ufficio per problemi e alla domanda che browser us non sanno rispondere... ed ho detto tutto :D

Spectrum7glr
14-10-2004, 13:49
Originariamente inviato da DjMix

Non ce l'ho con te, ma con sta idea del "programmatore" e del "windows facile" che sono veramente delle balle mostruose, ma pochi se ne rendono conto, quasi sempre perchè non conoscendo niente oltre che windows, non possono valutare. Ti consiglio di nutrire dubbi su quanto hai detto, perchè molte persone ormai si son accorte che la chimera "windows facile e user friendly" si sta sgretolando inesorabilmente.

permettimi di dissentire sulla "chimera del windows facile ed userfriendly": windows è davvero facile ed userfriendly...siceramente io non ho mai avuto problemi a configurare alcunchè e non capisco tutta quest'avversione per Window ed i miliardi di (fantomatici) problemi che di volta in volta vengono denunciati...wifi, modem, lan etc: nel 99% dei casi colleghi il nuovo componente e tutto fila liscio senza problemi di sorta (esperienza personale della mia lan casalinga dietro router/firewall: collego un PC ed automaticamente è visto senza nessun problema) e quell'1% lo tengo buono solo perchè un giorno potrei trovare il componente X che mi farà impazzire...ma per ora non è mai successo...forse sono fortunato :confused:
Che poi anche Linux possa essere facile non discuto, ma negare la facilità di windows mi sembra un po' esagerato: ha dei difetti ma la semplicità non è tra questi.

Spectrum7glr
14-10-2004, 13:52
Originariamente inviato da Duncan



Anche perchè, per fare un esempio, c'è gente che telefona in ufficio per problemi e alla domanda che browser us non sanno rispondere... ed ho detto tutto :D

bè a me questo sembra tutto tranne che un limite di windows...detto questo un minimo di cultura aiuterebbe sicuramente ed eviterebbe telefonate per quelle che nel 99% dei casi sono delle cavolate.

Ioo direi che Linux ha meno problemi anche perchè chi lo usa è normalmente una persona con maggiori conoscenze...e che molto probabilmente non avrebbe problemi a far funzionare windows altrettanto bene (visto il maggior bagaglio di conoscenze)

fek
14-10-2004, 14:06
Originariamente inviato da DjMix
Vero, ci son più giochi per win che lin. Si spera che la situazione cambi.. cmq un dualboot è un'ottima soluzione, a mio parere

Direi che ci sono giochi solo per Windows. Il rapporto di copie vendute di giochi sotto Linux e sotto Windows e' nel rapporto di 1 a qualcosa tipo 100.000. Si puo' tranquillamente affermare che non esiste un mercato di giochi per Linux.
E difficilmente, molto difficilmente, la situazione cambiera'.


Originariamente inviato da Spectrum7glr
permettimi di dissentire sulla "chimera del windows facile ed userfriendly": windows è davvero facile ed userfriendly...siceramente io non ho mai avuto problemi a configurare alcunchè e non capisco tutta quest'avversione per Window ed i miliardi di (fantomatici) problemi che di volta in volta vengono denunciati...wifi, modem, lan etc: nel 99% dei casi colleghi il nuovo componente e tutto fila liscio senza problemi di sorta (esperienza personale della mia lan casalinga dietro router/firewall: collego un PC ed automaticamente è visto senza nessun problema) e quell'1% lo tengo buono solo perchè un giorno potrei trovare il componente X che mi farà impazzire...ma per ora non è mai successo...forse sono fortunato :confused:
Che poi anche Linux possa essere facile non discuto, ma negare la facilità di windows mi sembra un po' esagerato: ha dei difetti ma la semplicità non è tra questi.

Piu' o meno anch'io ho la tua stessa esperienza. Mai avuto grossi problemi con l'hw sotto Windows, ho sempre avuto enormi problemi a ottimizzarlo, farlo andare velocemente, ma mai nessun problema a farlo andare e basta.
Il grosso limite (credo voluto) di Windows e' il fatto che non ci si possa mettere troppo le mani dentro: se va bene, se non va, farlo andare e' un grosso problema. Per fortuna la maggior parte delle volte va.

Con Linux invece, beh, dopo una settimana a combattere per installare una Suse in modalita' testo e farla andare per quello che mi serviva, ho abbandonato tristemente. Si', sono totalmente incapace a usare Linux, un completo niubbo, ma questo non vuol dire che il S.O. debba essermi precluso oppure che debba spendere una marea di tempo per impararlo per poi poterlo usare.

Il che mi fa arrivare alla conclusione che Linux e' gratis per quelli il cui tempo non vale nulla.

Ogni S.O. ha il suo scopo e i suoi ambiti di utilizzo in cui eccelle. Linux per sistemi server e' spesso una scelta ideale, per sistemi home no.

Mad Penguin
14-10-2004, 14:10
x DjMix
beh dai non esageriamo con le crociate, win è tutto furchè difficile da usare.
poi va beh secondo me osx è + intuitivo(sopprattutto per uno che non ha mai usato nient' altro prima), cmq da quel punto di vista xp va abba bene dai!

Duncan
14-10-2004, 14:12
Originariamente inviato da Spectrum7glr
bè a me questo sembra tutto tranne che un limite di windows...detto questo un minimo di cultura aiuterebbe sicuramente ed eviterebbe telefonate per quelle che nel 99% dei casi sono delle cavolate.

Ioo direi che Linux ha meno problemi anche perchè chi lo usa è normalmente una persona con maggiori conoscenze...e che molto probabilmente non avrebbe problemi a far funzionare windows altrettanto bene (visto il maggior bagaglio di conoscenze)

Beh questo è vero...

però le cose sono cambiate... vedi cosa è successo a Monaco o ad esempio Novel che che passa totalmente i propi sistemi su Linux, Linux è maturo sicuramente per essere usato in ufficio... ed anche a casa :)

LucaTortuga
14-10-2004, 14:57
Sarebbe anche ora di smetterla con il concetto per cui la diffusione di Win dovrebbe essere considerata indice di facilità e gradimento.. Il 95% delle persone che usano Win non lo ha scelto, se lo è trovato installato sul Pc, senza aver la minima idea del fatto che esistano alternative. L'unica cosa veramente buona che ha fatto M$ è stata stringere accordi con i produttori di PC (IMB x prima) perchè vendessero le loro macchine con Win preinstallato.. e tac! ecco piantato il seme del monopolio. Il resto è storia. Il fatto che, bene o male, negli anni, un po' tutti volenti o nolenti abbiano dovuto acquisire una certa dimestichezza con Win, non vuol affatto dire che sia un S.O. migliore o più facile da usare di altri..
Mi sembra un dato di fatto.

Ganesh74
14-10-2004, 15:05
scusate ma nessuno mi sa dare un consiglio??

DevilsAdvocate
14-10-2004, 15:27
Beh, in un confronto Windows vs Linux (anche a causa della maggior diffusione) e' INNEGABILE che si ottengano
piu' facilmente aiuti per configurare windows, etc.etc.
Allo stato attuale Windows e' preferibile dai neofiti,
almeno finche' il nuovo palladium e/o le altre strategie
microsoft non ci impediranno di usare il software gratuito (quello senza spyware) tuttora circolante ma
messo "a rischio" (palladium, brevetti e quant'altro per far si che un utente medio sia costretto ad usare/comprare winzip e soci invece di usare TugZip o IZArc tanto per fare un esempio)......

dnarod
14-10-2004, 15:41
x zoboliluca

da programmatore, per prima cosa dovresti sapere che non è microsoft a "fare" i driver, sono le case che producono l hw a pagare i programmatori che sviluppino driver per il loro hw......e visto che linux non è neanche contemplato (sta cominciando adesso e spero per lui che si ampli, viva la concorrenza) per le masse, li pagano anche per farlo solo per win (nella stragrande maggioranza dei casi); questo produce la seguente situazione: per win bene o male trovi sempre driver, per linux se li hanno scritti gli "appassionati" (tipo gli enthusiast dell hw, o chi fa progetti con linux o chi ci lavora.....cmq non la maggior parte, poco ma sicuro) o non ci sono proprio.....se sono scritti magari non sono compilati e te li devi ricompilare tu; se sono compilati 90 su 100 non sono per il tuo kernel o non vanno bene con la distro che stai usando; personalmente mi è capitato piu volte di trovare quelli giusti ma non funzionavano lo stesso; la scusa dell hw vecchio poi non regge assolutamente: non che scanner tu abbia ma se è vecchio di 3-4-5 anni con 50 euro al 14/10/2004 vai in un qualunque supermercato e comperi uno scanner migliore del tuo; vabbe che non vuoi cambiarlo, ma chi è che va avanti con un p100 e un masterizzatore 2* ? e ti da soddisfazioni? scusa se dubito ma mi sembra una scusa messa li per gettar fango su ms, tanto piu che, ribadisco, non è lei la responsabile dei driver del tuo scanner, al massimo dell incompatibilita fra i vari win (e qui ne do atto, anche se non vedo il problema);

x fek
ti amo! quoto cio che hai detto: linux è perfetto per chi ha tempo da perderci dietro, giacche non è ancora abbastanza sviluppato da poter velocizzare tutta una serie di rogne che per forza di cose l utilizzatore si deve prendere.......credeteci pure tutti se non volete credere a me, fek e uno che di computer qualcosa (tanto) ne sa visto il lavoro che fa, e se anche lui ha avuto il mio stesso problema (ovvero le palle smerigliate ripetutamente da odisse infinite nella configurazione/settaggio di linux [a volte pure con cattivo esito]), qualcosa vorra pur dire... pero devo dire una cosa fek; ora sto runnando debian grazie alla buona volonta di chi ha voluto aiutarmi fino al midollo (giacche avevo qualche giorno libero, senno non mi sarei mai messo) e devo dire che con mooooooooooolta fatica si riesce ad arrivare a risultati piu che soddisfacenti e come prestazioni e come praticita (ovviamente win è piu immediato e sviluppato, ma c e sempre il discorso della natura gratuita di linux, che bilancia lo sbattone che ti devi fare, pagando in fatica, per settare tutto)

sheijtan
14-10-2004, 16:04
Originariamente inviato da fek
Il che mi fa arrivare alla conclusione che Linux e' gratis per quelli il cui tempo non vale nulla.


Bravo, bella conclusione!
A molti sfugge che linux è un clone di UNIX (l' altra metà del cielo...) e in quanto tale non è propriamente un giocattolo. Ergo, puoi lavorarci ed essere produttivo in campi piuttosto cazzuti (almeno per i miei gusti). Uno di questi è il calcolo scientifico.
es: 2 PC, ( un pentiumIII 800 e un athlon thund. 900, con 394Mb ciascuno )
i due PC sono obsoleti, sono da buttare...mh, che fare?
1- ci metti sopra linux (gratis),
2- compili e installi GAMESS (licenza d' uso gratuita per usi accademici) su ciascuno dei due,
3- fai girare il programma in **parallelo** sui due PC tramite socket, praticamente stai usando un biprocessore con 2*396Mb di ram
risultato:
1- hai imparato a far funzionare un piccolo cluster
2- fai i calcoli necessari a completare la tesi e a pubblicare un paio d' articoli su riviste scientifiche specializzate
3- non hai buttato i computer e li fai lavorare giorno e notte

insomma, ti pare che imparare ad usare linux sia stato tempo sprecato?
P.S: come si fa a fare quello che ho fatto con linux con windowsXP?
io non saprei dove mettere le mani...strano, no?
ciao!

Milosevik
14-10-2004, 16:17
Bhà , io tutti questi problemi con windows , non li ho mai avuti , aggiorno con windows update e uso norton antivirus , e per adesso me la sono sempre cavata.
Del computer ne faccio un uso casalingo , internet , giochi , fotoritocco p2p e ripping , e per me xp è più completo di linux e molto più semplice da usare. Però devo dire che la mia unica prova di installazione è stata con mandrake e non ho molta voce in capitolo, datoche non sono riuscito neanche ad usare internet :) .
Ho provato per 2 giorni a far riconoscere il modem adsl pci e non ci sono riuscito , ho provato a chiedere aiuto a leggermi i manuali online ma niente da fare , sicuramente perchè sono un vero utonto , però i problemi con windows bene o male sono sempre riuscito a risolverli , il primo problema che ho avuto con mandrake appena installato , mi ha bloccato senza venirne a capo.

Apple80
14-10-2004, 16:19
a mè non sembra tanto una novità. :asd:

è come il postino ke mi porta la posta ogni giorno. :D

dnarod
14-10-2004, 16:19
infatti, non sapresti dove mettere le mani, no non si puo fare....a parte questo non credo che a fek sfugga il fatto che linux sia un "clone" di unix (cosa che ti garantisco essere vera solo in parte, volendo essere precisi)

---------
insomma, ti pare che imparare ad usare linux sia stato tempo sprecato?
--------
scusa se prendo le sue difese, ma non ha detto che è tempo sprecato, sostiene (come me, ecco quindi il mio intervento) che ci vada troppo sbattone per farlo andare, quando su piazza puoi fare molto piu comodamente.....win non sara linux ma ti sbatto 100 volte meno per avere alla fine le stesse cose (anzi se giochi hai di piu).....ovvio che per certi usi specifici linux è un obbligo e necessita irrinunciabile, ma a parte quei casi (cioe i casi in cui il 90 per cento dell utenza non rientra) la cosa è molto diversa....

pietse
14-10-2004, 16:42
Visto che si deve finire sempre a parlare di Lin vs Win: difendo gnu/linux.
Chi ha messo in giro la favola che linux non ha così tanti bug perchè è meno usato? Linux è il più usato dove serve sicurezza, tutti scemi i sistemisti? Anzi se ne trovano molti solo che sono subito risolti.
Esistono anche i virus, solo che non fanno danni, visto che chi lo usa (che ha quelle poche, misere, stupide conoscenze che molti chiamano "difficoltà di linux" tipo partizionare e usare gli utenti) non installerebbe mai un virus.
Perchè su win sono i produttori di hw a sviluppare i driver e per linux la comunità? Penso che anche chi usa linux paghi l'hw allo stesso prezzo. La comunità però si accolla anche questo compito.
La situazione è semplice, siamo ADDESTRATI a usare win e non abbiamo voglia di imparare ad imparare.
Poi a ognuno il SO che più gli piace, bella anche la critica, ma purchè si sappia di cosa si sta parlando.

fek
14-10-2004, 16:58
Originariamente inviato da sheijtan
insomma, ti pare che imparare ad usare linux sia stato tempo sprecato?

Per me si'. Mi sarebbe bastato solo vederlo funzionare, per quello che mi serviva fare.
Per chi configura server ovviamente no.

sheijtan
14-10-2004, 17:03
Originariamente inviato da fek
Per me si'. Mi sarebbe bastato solo vederlo funzionare, per quello che mi serviva fare.

Ecco! ci sei! PER TE è tempo sprecato...
io invece ci lavoro (e guadagno, pure...)
bye!

Vik Viper
14-10-2004, 17:07
Già, perchè non tacere?
Diamine! volevo esprimere di nuovo il mio parere, ma invece mi limito a mettere una nota polemica.
Mi sto impoverendo: chiedo scusa.

Ikitt_Claw
14-10-2004, 17:11
Originariamente inviato da Spectrum7glr
permettimi di dissentire sulla "chimera del windows facile ed userfriendly": windows è davvero facile ed userfriendly...

La prossima volta che un mio amico/conoscente mi chiama per configurare una rete locale o l'accesso a internet ti faro` un fischio; comunque, mi sta sorgendo il dubbio di essere io che porto sfiga.

(esperienza personale della mia lan casalinga dietro router/firewall: collego un PC ed automaticamente è visto senza nessun problema)

Idem con linux, per la cronaca.

PS: siamo OT.

Ikitt_Claw
14-10-2004, 17:12
Originariamente inviato da fek
Il che mi fa arrivare alla conclusione che Linux e' gratis per quelli il cui tempo non vale nulla.

Oppure per quelli che hanno gia` uno o piu` admin in casa. (o in azienda)

Vik Viper
14-10-2004, 17:14
Se non mi va bene windows, visto che l'ho pagato, protesto col "costruttore" e premo perchè faccia le cose come si deve!! Eccheccazz!!
E poi, giusto per puntualizzare, rivendico il mio diritto ad esprimere pubblicamente la mia disapprovazione per la politica della MS.
Col permesso di Corsini e della costituzione e con buona pace di quelli che ancora non hanno capito che fintanto windows sarà impostato in maniera così pietosa dal punto di vista sicurezza è inevitabile che ogni venti buchi scoperti la gente imposta messaggi di disapprovazione e si lamenti.
Amen

Vik Viper
14-10-2004, 17:16
mi risparmio il fegato e risparmio a voi di leggere le mie c@%%@te. Non ce la faccio a leggere oltre gli interventi..
Scusatemi per avervi tediato ancora

Milosevik
14-10-2004, 17:22
Rilassati Vik Viper e che è , inc@zzarsi per così poco è ridicolo , dai fai un respiro profondo e di oooooommmmmmmmmmmmm.

fek
14-10-2004, 17:26
Originariamente inviato da sheijtan
Ecco! ci sei! PER TE è tempo sprecato...
io invece ci lavoro (e guadagno, pure...)
bye!

E infatti io che ho detto? E' gratis per quelli il cui tempo non vale nulla :p

A parte gli scherzi. Per me no, per te si', abbiamo esigenze diverse, usiamo strumenti diversi. Mi fa solo un po' ridacchiare chi spera di vederci mai molti dev svilupparci giochi sopra. Linux non e' fatto per quello, ma per altro. Ad ognuno il suo strumento.

ReLupo
14-10-2004, 17:35
... alla fine il mio vecchio AMD K7 700 boxato ad installazione pulita macina decentemente, alla fine di tutto il windows update ranca come una capra di montagna quando viene infilata in un deserto. GHGHGH!!!
Per fortuna che lo tengo scollegato da Internet e lo uso esclusivamente per contenere dati personali...
Non è propriamente un update efficace ed indolore: raqfforzi la sicurezza e mi appesantisci l'hw???

joe4th
14-10-2004, 17:57
Originariamente inviato da DevilsAdvocate
Non capisco perche' tirare in ballo Linux per la n-esima
volta. A parte il discorso Debian l'unico problema che
si puo' imputare al pinguino e' la ATI che non sembra
minimamente intenzionata a fare uscire drivers binari
per Xorg (purtroppo per le schede video di sorgenti non
se ne e' mai vista l'ombra...).


Non e' esatto. Avere i drivers ATI binari, come
quelli di NVidia, mette una toppa (un driver
binario e proprietario e meglio che nessun driver),
ma non e' la soluzione del problema. Significa che
per un breve periodo li potrete usare sotto Linux,
ma non appena aggiungono qualche nuova
feature al kernel, o a XFree, etc.; si ricomincia da capo
e si aspettano altri sei mesi prima che
il vendor, notoriamente indietro sulle
distribuzioni Linux di un'anno o due, metta a posto
la situazione. Nei casi peggiori, poi il driver
finisce in modalita' abadonware (e' il caso
dei modem ESS per i portatili).

Purtroppo la maggior parte degli utenti
provenienti da Windows che tentano l'approccio
con Linux, lo fanno utilizzando lo stesso approccio
che avrebbero con Windows, che parafrasando Cartesio
potrebbe essere: scarico (tutto quello che
trovo su internet), installo, ergo sum (sono un
grande esperto di informatica). E pensano
che in una distribuzione Linux ci si debba essere
esattamente cosi'; poi magari siccome non ha
funzionato una volta, abbandonano definitivamente
con Linux, sfogando magari le loro frustazioni nei forum.

In Linux il supporto dell'hardware nuovo deve provenire
dalla distribuzione stessa, non pluggando dei file binari
scaricati qua e la o dal sito del venditore. Se l'hardware non
e' supportato, si sceglie quello supportato con i driver
OpenSource, consultando i siti e i forum Linux prima di acquistarlo.
Per esempio per ATI le schede fino alla 9200 sono supportate
dai driver OpenSource anche per il 3D (attraverso
DRI+mesa): faro' in modo di acquistare solo queste schede.
Quando DRI supportera' anche le 9600 e le 9800 allora
prendero' queste.
In questo modo avrete il vostro hardware sempre supportato e
nel contempo potrete avere installata una distribuzione Linux
senza fatica, e tenerla sempre aggiornata con altrettanta facilita'
e senza la minima fatica, tramite apt-get, urpmi, u2pdate, etc.

I produttori di hardware piu' lungimiranti
(3ware, Adaptec, etc.) hanno capito
che rilasciando i driver opensource, faticano la
meta', perche' basta rilasciarlo una volta
e la comunita' glielo manterra' indefinitamente
(approccio del "Cuculo") e funzionera' ovunque.
Altri (NVIdia, ATI, etc.) invece pensano che cosi' perderebbero
sia il controllo che la proprieta' intellettuale e i loro
segreti (come se gli ingegneri concorrenti non saprebbero
disassemblare un driver binario per vedere come e' fatto...).


Windows e Linux hanno circa lo stesso numero di vulnerabilita' (come e' ovvio).


Non mi risulta che abbiano lo stesso numero di vulnerabilita'. Le
vulnerabilita' di security del kernel di Linux, si e no c'e' ne
una ogni 4 o 5 mesi. Certo in una distribuzione
Linux ci sono almeno 6000 applicazioni differenti GNU
da GIMP, a OpenOffice, a mozilla,
etc.; ma allora se dobbiamo fare un paragone,
dovremmo sommare le vulnerabilita' di Windows e di
tutte le sue applicazioni, comprese quelle non Microsoft.


L'unica differenza e'
che linux e' open source quindi le vulnerabilita' ve le potete scovare anche da voi, nel bene e nel male,
come sta succedendo in questo periodo con la distro
Gentoo dove ne vengono rilevate e corrette parecchie
giornalmente.


Secondo te avere una delle 6 o 10000 applicazioni
che compongono la distribuzione Gentoo abbia un baco,
che in determinate condizioni possa essere sfruttato
da un utente locale per acquisire fraudolentemente
i privilegi di root, oppure per cancellare un file in /tmp/
e' lo stesso che vedersi la propria
macchina Windows con installato un trojan, dopo che si e' visto un file JPEG?


Tralasciando questo, pinguino ed Xp possono tranquillamente coesistere, magari usando Xp offline ed il pinguinozzo per andare in rete.........

Windows coesisterebbe molto meglio all'interno di una
virtual machine dentro Linux... (chiaramente
pero' le Virtual Machine non possono supportare piu' hardware
di quello supportato dal Linux nativo..., quindi niente giochi).

fek
14-10-2004, 18:13
Originariamente inviato da joe4th
Altri (NVIdia, ATI, etc.) invece pensano che cosi' perderebbero
sia il controllo che la proprieta' intellettuale e i loro
segreti (come se gli ingegneri concorrenti non saprebbero
disassemblare un driver binario per vedere come e' fatto...).

Con chip della complessita' di un NV40? Ci metterebbero meno a progettare una propria gpu da zero.

Ikitt_Claw
14-10-2004, 18:18
Originariamente inviato da fek
Con chip della complessita' di un NV40? Ci metterebbero meno a progettare una propria gpu da zero.

OT per OT, facendo una stima spannometrica, secondo te quanto potrebbe capire dell'architettura interna di una GPU nvidia un'ingegnere ati che legge il codice del relativo driver?

fek
14-10-2004, 18:25
Originariamente inviato da Ikitt_Claw
OT per OT, facendo una stima spannometrica, secondo te quanto potrebbe capire dell'architettura interna di una GPU nvidia un'ingegnere ati che legge il codice del relativo driver?

Con lo spannometro? :)

Tu fai conto che se io gli chiedo di darmi accesso ai counter interni al chip che mi dicano quanti pixel sono stati renderizzati, mi fanno orecchie da mercante. Solo ultimamente stanno iniziando a mollare un po' e fornire a noi sviluppatori un po' di informazioni sull'architettura interna, ma dietro a NDA da fucilazione.

Ho provato l'altro giorno a chiedere a Richard Huddy di ATI, non il codice del driver (mai sia), ma i simboli del driver per il profiling. Mi ha risposto con un sorriso :)

Non rilasceranno i sorgenti dei driver neppure se salvasse il pianeta da una guerra termonucleare.

Ikitt_Claw
14-10-2004, 18:28
Originariamente inviato da fek
[...]
Non rilasceranno i sorgenti dei driver neppure se salvasse il pianeta da una guerra termonucleare.

E forse neppure dopo il fallimento (della ditta produttrice). Su questo non avevo dubbi, ma mi piaceva cercare di capire se era pura paranoia 100% doc (e punto qui per ora, onestamente) o se c'era qualche altro motivo dietro. :)

fek
14-10-2004, 18:31
Originariamente inviato da Ikitt_Claw
E forse neppure dopo il fallimento (della ditta produttrice). Su questo non avevo dubbi, ma mi piaceva cercare di capire se era pura paranoia 100% doc (e punto qui per ora, onestamente) o se c'era qualche altro motivo dietro. :)

Credo che per chi ne capisce di hardware (non me), con un po' di informazioni possa risalire abbastanza facilmente a dettagli importanti su parti specifiche dell'architettura.

DjMix
14-10-2004, 18:58
Originariamente inviato da Mad Penguin
beh dai non esageriamo con le crociate, win è tutto furchè difficile da usare.
poi va beh secondo me osx è + intuitivo(sopprattutto per uno che non ha mai usato nient' altro prima), cmq da quel punto di vista xp va abba bene dai!

*Nessun* sistema è facile da usare. Solo quello che si conosce è _facile_. Chi usa windows da una vita, si trova sempre le stesse cose con piccole variazioni (colori diversi, più che altro...), per cui ci metterà un attimo a orientarsi. Nemmeno mac os x è facile se prima non ci hai preso mano. Nemmeno linux, per gli stessi motivi. Certo che quando impari a conoscerlo (= saper dove cliccare), diventa facile tutto.

Per il discorso driver: tutto quel che linux conosce, ovvero ha driver LIBERI, è di una banalità disarmante da installare. Tanto per capirci, l'altro giorno sono passato da una mother board con chipset SIS a una con VIA. Non ho toccato una virgola al sistema, ho solo acceso il pc e lui si è caricato i nuovi driver, mi son rimesso ad usarlo come se niente fosse. Con windows devi reinstallare.

X Fek: un pc non configurato è una perdita di tempo per chiunque, a prescindere dal sistema.

fek
14-10-2004, 19:07
Originariamente inviato da DjMix
*Nessun* sistema è facile da usare. Solo quello che si conosce è _facile_. Chi usa windows da una vita, si trova sempre le stesse cose con piccole variazioni (colori diversi, più che altro...), per cui ci metterà un attimo a orientarsi. Nemmeno mac os x è facile se prima non ci hai preso mano. Nemmeno linux, per gli stessi motivi. Certo che quando impari a conoscerlo (= saper dove cliccare), diventa facile tutto.


Questo e' palesemente falso, perche' esistono metriche ben precise per valutare l'ergonomicita' di un qualunque prodotto.

Un'interfaccia a riga di comando (un esempio, non sto dicendo che Linux e' a riga di comando) e' intrinsecamente meno ergonomica di un'interfaccia punta e clicca. Che poi ci sia il mago che lo usa a 300 all'ora non cambia la sostanza.

Originariamente inviato da DjMix
X Fek: un pc non configurato è una perdita di tempo per chiunque, a prescindere dal sistema.

Il WinXP al lavoro e' configurato. Come il mio Tablet PC.

afterburner
14-10-2004, 19:36
Originariamente inviato da sheijtan
es: 2 PC, ( un pentiumIII 800 e un athlon thund. 900, con 394Mb ciascuno )
i due PC sono obsoleti, sono da buttare...mh, che fare?
1- ci metti sopra linux (gratis),
2- compili e installi GAMESS (licenza d' uso gratuita per usi accademici) su ciascuno dei due,
3- fai girare il programma in **parallelo** sui due PC tramite socket, praticamente stai usando un biprocessore con 2*396Mb di ram

OT ma io sono specialista dell'OT ..
General Atomic and Molecular Electronic Structure System (GAMESS) ..
Probabilmente per la tua tesi dovevi usare questo ma perche' non hai usato openmosix (http://www.openmosix.org)? Ho installato un cluster openmosix fatto con 3 macchine doppio processore Athlon MP e va abbastanza bene .. ha un po' di rogne con roba basata su java ma con fortran e programmi C che forkano va un gioiellino ..

DjMix
14-10-2004, 20:05
Originariamente inviato da fek
Questo e' palesemente falso, perche' esistono metriche ben precise per valutare l'ergonomicita' di un qualunque prodotto.

Le tue metriche escludono tutti i miei amici allora, dato che continuano a venir da me quando "il computer è rotto" (con windows xp, 2000, 98: la storia è sempre la stessa).

Originariamente inviato da fek
Il WinXP al lavoro e' configurato. Come il mio Tablet PC.
Anche la mandrake che gli ho messo in dual boot a tutti. E per fortuna loro, perchè così quando gli si inchioda windows almeno il computer continuano a usarlo.

fek
14-10-2004, 20:18
Originariamente inviato da DjMix
Le tue metriche escludono tutti i miei amici allora, dato che continuano a venir da me quando "il computer è rotto" (con windows xp, 2000, 98: la storia è sempre la stessa).


Non sono le mie metriche:

http://www.amazon.co.uk/exec/obidos/ASIN/0137219296/qid=1097781320/ref=sr_8_xs_ap_i1_xgl/202-4027200-9583865
http://www.amazon.co.uk/exec/obidos/ASIN/0471118451/qid=1097781360/ref=sr_8_xs_ap_i1_xgl/202-4027200-9583865
http://www.amazon.co.uk/exec/obidos/ASIN/0321269780/qid=1097781388/ref=sr_8_xs_ap_i1_xgl/202-4027200-9583865

http://www.amazon.co.uk/exec/obidos/ASIN/0333773217/ref=pd_sim_b_dp_3/202-4027200-9583865
http://www.amazon.co.uk/exec/obidos/ASIN/0137519753/ref=pd_sim_b_dp_4/202-4027200-9583865

Che dici, non avrebbero scritto cosi' tanto riguardo sull'usabilita' delle interfacce utente e sull'interazione uomo macchine se tutto dipendesse davvero solo dal grado di esperienza come dici. Non sei d'accordo?

Esistono anche esami universitari sull'interazione uomo-macchina, secondo te il professore entra il primo giorno e dice: "Ragazzi, le interfacce sono tutte usabili uguali, basta che facciate esperienza, il corso e' finito, ci vediamo all'esame".

Anche la mandrake che gli ho messo in dual boot a tutti. E per fortuna loro, perchè così quando gli si inchioda windows almeno il computer continuano a usarlo.

Ora configuragli bene anche Windows di modo che non si inchiodi, visto che a me non si inchioda mai ;)

DjMix
14-10-2004, 20:23
Originariamente inviato da fek
Che dici, non avrebbero scritto cosi' tanto riguardo sull'usabilita' delle interfacce utente e sull'interazione uomo macchine se tutto dipendesse davvero solo dal grado di esperienza come dici. Non sei d'accordo?
Daccordissimo, io. I miei amici no ;)

Originariamente inviato da fek
Ora configuragli bene anche Windows di modo che non si inchiodi, visto che a me non si inchioda mai ;)
Siamo in due ;)
Ma credo che io e te non clicchiamo su tutto quel ce ci passa a tiro, e sopratutto, credo che leggiamo quel che sta scritto sullo schermo.. a differenza di un utente normale (spero tu sappia quel che intendo).

][xwilsonx][
14-10-2004, 21:58
Originariamente inviato da zoboliluca
Stai scherzando vero.

Per quanto riguarda di driver hw e' proprio microsoft la prima che non li scrive. Ad ogni passaggio di sistema operativo da Win98-Me-XP e anche da NT3.5-NT3.52.NT4.0-W2000 tutti (noi utenti) siamo stati costretti a buttare hw in quanto i driver non esistono o non funzionano. Vedi il mio scanner HP3300C che mi funziona solo sotto Win98 perche' i driver WinXP non vanno.
Adesso l'hai detta grossa.........:mc: si presuppone che i driver di una periferica nn li debba scrivere MS, ma il produttore dell'hw:rolleyes:
E cmq i driver per il tuo scanner hp3300c per winXP ci sono!!!
eccoti il LINK (http://h10025.www1.hp.com/ewfrf/wc/softwareList?product=58390&lang=it&lc=it&cc=it&dlc=it&os=228)
nn li trovavi??? bhè bastava cercare!!!
scommetto che adesso è colpa della MS vero???

invece di vinire a gettare m***a su MS, potevi bennissimo andarti a cercare i driver......:rolleyes:

Ti lamenti perche quando esce un nuovo hw devi ricompilare dei sorgenti?
Perche quando compri del nuovo hw devi controllare se sono supportati dal s.o che vuoi utilizzare?
O perche' devi aspettare a comprare finche' non sono stati preparati i driver (questo comunque anche con M$)?
E' difficile che i driver nn siano subito disponibili per Win, anzi sn i primi ad uscire!

][xwilsonx][
14-10-2004, 22:13
Originariamente inviato da DjMix
Non ce l'ho con te, ma con sta idea del "programmatore" e del "windows facile" che sono veramente delle balle mostruose, ma pochi se ne rendono conto, quasi sempre perchè non conoscendo niente oltre che windows, non possono valutare.
A dire la verità Windows è abbastanza facile!
Mi sa che una balla mostruosa l'hai detta proprio tu.... te lo dice uno che in passato ha usato linux red hat 6.2, e adesso SUSE 9.1...

Ti consiglio di nutrire dubbi su quanto hai detto, perchè molte persone ormai si son accorte che la chimera "windows facile e user friendly" si sta sgretolando inesorabilmente.
ma ne sei sicuro???? prova a far funzionare un modem adsl usb su win e poi prova su linux....

midian
14-10-2004, 22:20
altre patch
ma allora windows nn ha falle..
ha un fosso intero!!!
:sofico: :sofico: :sofico: :sofico: :sofico: :sofico:

sheijtan
14-10-2004, 22:45
Originariamente inviato da afterburner
OT ma io sono specialista dell'OT ..
General Atomic and Molecular Electronic Structure System (GAMESS) ..
Probabilmente per la tua tesi dovevi usare questo ma perche' non hai usato openmosix (http://www.openmosix.org)? Ho installato un cluster openmosix fatto con 3 macchine doppio processore Athlon MP e va abbastanza bene .. ha un po' di rogne con roba basata su java ma con fortran e programmi C che forkano va un gioiellino ..
Ok, OT per OT cmq è sempre bello beccare qualcuno che condivida le tue passioni :cool:
Ottima idea quella di installare open mosix! in effetti è uno dei miei "progetti nel cassetto"... GAMESS e generalmente i programmi per il calcolo della struttura elettronica hanno bisogno, per funzionare in parallelo, di una qualche implementazione di 'memoria condivisa' , proprio quella cosa che open mosix non può gestire. In particolare GAMESS nella sua versione parallela usa una API chiamata DDI (Distributed Data Interface) e semplicemente ssh (o rsh per chi ama il rischio...;) ) per lanciare i processi remoti.

cdimauro
15-10-2004, 03:51
Originariamente inviato da zoboliluca
Beh, io mi lamento perche' la Microsoft ogni 3-4 anni mi obbliga a buttare delle periferiche funzionanti che sto utilizzando con soddisfazione, costingendomi a spedere altri soldi per comprarne altre che tra 3-4 anni dovro' nuovamente buttare.
I driver non sono di dominio di MS, ma di chi produce l'hardware: è a loro che ti devi rivolgere per ricevere supporto quando si verifica il passaggio a un altro s.o...
Scusa se ne ho approffittato per sfogarmi, non ce l'ho con te ma con la M$ sia per lo scanner di cui sopra, sia per tutti i problemi di compatibilita' di driver sui quali ho sbattuto il naso sul lavoro.
"Ringrazia" il produttore, allora.

PS. Accetto scommesse.
Quanto hw dovremo buttare all'arrivo di LongHorn?
Chiedilo a chi t'ha venduto l'hardware. E comunque, nessuno ti obbliga a passare a LH se la pensi così: con XP si sopravviverà lo stesso...

cdimauro
15-10-2004, 03:59
Originariamente inviato da Spyto
Bisogna capire che Linux nasce per i programmatori,
I programmatori per programmare sentono il bisogno di usare comodi e funzionali ambienti di sviluppo integrati.
Per Linux non esiste niente al livello degli IDE Borland o MS, per cui i casi sono due: o i suoi programmatori sono masochisti o non nasce per i programmatori... :asd:
che risolvono da loro i problemi del S.O. e una volta avviato correttamente non ci ritornano sopra.
Peccato che non basti verificare che il s.o. si avvi per avere la certezza che i problemi siano risolti: il testing (serio) è qualcosa di più del metodo "artigianale" che hai citato... ;)
Tutto questo mio discorso logicamente e fatto per SO che vengono utilizzati a casa. Per lavoro se ci sono i programmi adatti è consigliabile solo Linux/Mac.
Per lavoro uso Windows (per ora), e mi trovo benissimo. Anzi, visto che la mia attività principale è la programmazione, rappresenta la piattaforma ideale... :D

cdimauro
15-10-2004, 04:07
Originariamente inviato da sheijtan
Bravo, bella conclusione!
A molti sfugge che linux è un clone di UNIX (l' altra metà del cielo...)
Più che metà, la definirei "briciola"... ;)
e in quanto tale non è propriamente un giocattolo.
Per quanto mi riguarda, lo stesso vale per Windows: per quale motivo lo riterresti un giocattolo?
Ergo, puoi lavorarci ed essere produttivo in campi piuttosto cazzuti (almeno per i miei gusti). Uno di questi è il calcolo scientifico.
Idem per Windows.
es: 2 PC, ( un pentiumIII 800 e un athlon thund. 900, con 394Mb ciascuno )
i due PC sono obsoleti, sono da buttare...mh, che fare?
1- ci metti sopra linux (gratis),
2- compili e installi GAMESS (licenza d' uso gratuita per usi accademici) su ciascuno dei due,
3- fai girare il programma in **parallelo** sui due PC tramite socket, praticamente stai usando un biprocessore con 2*396Mb di ram
risultato:
1- hai imparato a far funzionare un piccolo cluster
2- fai i calcoli necessari a completare la tesi e a pubblicare un paio d' articoli su riviste scientifiche specializzate
3- non hai buttato i computer e li fai lavorare giorno e notte

insomma, ti pare che imparare ad usare linux sia stato tempo sprecato?
Visto che lo stesso lo si può fare con Windows, probabilmente sì.
P.S: come si fa a fare quello che ho fatto con linux con windowsXP?
io non saprei dove mettere le mani...strano, no?
ciao!
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.
Se poi non sei masochista, puoi benissimo utilizzare uno fra le miriadi di componenti per i vari IDE (Borland Delphi/CBuilder, MS VisualStudio) che ne incapsulano le funzionalità e ti permettono di realizzare applicazioni basate su socket in pochi minuti... :sofico:

cdimauro
15-10-2004, 04:15
Originariamente inviato da pietse
Esistono anche i virus, solo che non fanno danni, visto che chi lo usa (che ha quelle poche, misere, stupide conoscenze che molti chiamano "difficoltà di linux" tipo partizionare e usare gli utenti) non installerebbe mai un virus.
Bisognerebbe essere stupidi a installare un virus volotariamente. ;) Certamente da guest o con privilegi limitati risulta un po' difficile installare un virus, volotariamente o meno, ma questo vale per qualunque s.o., Windows incluso.
Perchè su win sono i produttori di hw a sviluppare i driver e per linux la comunità? Penso che anche chi usa linux paghi l'hw allo stesso prezzo. La comunità però si accolla anche questo compito.
Che ragionamenti sono, scusa? Allora facciamo così: io sviluppo un nuovo s.o. (PorkOS :oink: :D), e poiché ho comprato dell'hardware, pretenderò che le case costruttrici ne sviluppino gli appositi driver.
Domani un altro tizio viene folgorato sulla via di Damasco e sviluppa un altro s.o. (PussyOS :sbav: ), e pretende che anche per questo siano sviluppati i driver.
E così via. Puoi immaginare dove voglio arrivare...
La situazione è semplice, siamo ADDESTRATI a usare win e non abbiamo voglia di imparare ad imparare.
Diciamo che non abbiamo tempo da perdere per imparare a usare un s.o. o delle applicazioni oltre una certa misura.
Poi a ognuno il SO che più gli piace, bella anche la critica, ma purchè si sappia di cosa si sta parlando.
Appunto.

cdimauro
15-10-2004, 04:20
Originariamente inviato da Vik Viper
Se non mi va bene windows, visto che l'ho pagato, protesto col "costruttore" e premo perchè faccia le cose come si deve!!
Nessuno ti obbliga a comprare Windows: puoi sempre decidere di farne a meno.
In ogni caso, e questo lo dovresti già sapere, il software perfetto non esiste.
Eccheccazz!!
E poi, giusto per puntualizzare, rivendico il mio diritto ad esprimere pubblicamente la mia disapprovazione per la politica della MS.
Con ciò vorresti mettere il bavaglio a chi non è d'accordo con la tua opinione e vorrebbe esprimerlo? La costituzione e Corsini valgono anche in questo caso... ;)
Col permesso di Corsini e della costituzione e con buona pace di quelli che ancora non hanno capito che fintanto windows sarà impostato in maniera così pietosa dal punto di vista sicurezza è inevitabile che ogni venti buchi scoperti la gente imposta messaggi di disapprovazione e si lamenti.
Amen
Visto che sei così bravo, puoi sempre farti assumere da zio Bill e "impostare" Windows in un altro modo...

cdimauro
15-10-2004, 04:37
Originariamente inviato da joe4th
Non e' esatto. Avere i drivers ATI binari, come
quelli di NVidia, mette una toppa (un driver
binario e proprietario e meglio che nessun driver),
ma non e' la soluzione del problema. Significa che
per un breve periodo li potrete usare sotto Linux,
ma non appena aggiungono qualche nuova
feature al kernel, o a XFree, etc.; si ricomincia da capo
e si aspettano altri sei mesi prima che
il vendor, notoriamente indietro sulle
distribuzioni Linux di un'anno o due, metta a posto
la situazione. Nei casi peggiori, poi il driver
finisce in modalita' abadonware (e' il caso
dei modem ESS per i portatili).
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).

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.

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".

Windows coesisterebbe molto meglio all'interno di una
virtual machine dentro Linux... (chiaramente
pero' le Virtual Machine non possono supportare piu' hardware
di quello supportato dal Linux nativo..., quindi niente giochi).
E' per questo che in genere è meglio procedere in maniera opposta: Linux che gira dentro una virtual machine... ;)

Ikitt_Claw
15-10-2004, 07:52
Originariamente inviato da cdimauro
la norma per i s.o. e stata quella di avere dei driver binari,

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


La soluzione ideale, IMHO, e 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,

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

hook per richiamare funzioni esterne al kernel, che soltanto gente fanatica e con una limitata visione come Torvalds puo bollare aprioristicamente come "pericolose".
In effetti e` un capolavoro di design, eh? :D
PS: Torvalds fanatico? Da quando?

Ikitt_Claw
15-10-2004, 08:00
Originariamente inviato da fek
Che dici, non avrebbero scritto cosi' tanto riguardo sull'usabilita' delle interfacce utente e sull'interazione uomo macchine se tutto dipendesse davvero solo dal grado di esperienza come dici. Non sei d'accordo?
Lui non lo so, io concordo solo in parte.
Perche` tutto l'ambaradan si basa pesantemente sul discorso di metafore. La metafora, in quanto tale, puo` apparire ovvia ad alcuni, ma non a tutti. Allargando il campo a strumenti general purpose come i SO (che girano in francia come in thailandia) il problema si allarga, considerando le differenze storiiche e culturali dei vari gruppi di utenti (e degli stessi utenti dentro i gruppi!). Altrimenti non si discuterebbe cosi` tanto anche per la sola scelta delle icone.

Se si usasse la metafora ideale (fermi restando i vincoli di interazione 'HW', come tastiera e mouse [non mi risulta sia comodissimo scrivere in cinese con la tastiera PC104, tant'e` che se non erro usano l'alfabeto sillabico/semplificato, qualcuno puo` confermare?]), tutto ovviamente sarebbe davvero "intuitivo" e facile da usare al primo colpo.
Ma non e` cosi`, anche perche` se fosse cosi` non ci sarebbe bisogno di manualoni sul design delle interfacce :)
Basterebbe un booklet di 100 pagine con la ricetta universale, no? :)

Tutto questo per dire: se il SW che si usa, sia SO o programma di fotoritocco usa una metafora imperfetta, per qualsivoglia motivo, allora l'abitudine diventa fondamentale per determinarne la facilita` d'uso.
Il discorso di DjMix non mi pare cosi` assurdo.

"Ragazzi, le interfacce sono tutte usabili uguali, basta che facciate esperienza, il corso e' finito, ci vediamo all'esame".
Credo che dopo X mesi di utilizzo le differenze tendano pericolosamente ad appiattirsi. Quantomeno per le funzioni piu` utilizzate.
Tant'e` che ci sono parecchi utenti che se cavano benone con la CLI, il Demonio dell'usabilita` :D

Ikitt_Claw
15-10-2004, 08:02
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
15-10-2004, 08:19
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
15-10-2004, 08:34
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? :D
:) 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
15-10-2004, 08:39
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
15-10-2004, 09:10
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
15-10-2004, 09:43
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
15-10-2004, 09:59
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
15-10-2004, 10:02
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
15-10-2004, 10:17
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
15-10-2004, 10:28
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/ASIN/0201834545/qid=1097832043/ref=sr_8_xs_ap_i1_xgl/202-4027200-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
15-10-2004, 10:28
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. :D

fek
15-10-2004, 10:37
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. :D

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
15-10-2004, 10:43
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/ASIN/0201834545/qid=1097832043/ref=sr_8_xs_ap_i1_xgl/202-4027200-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
15-10-2004, 10:57
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
15-10-2004, 11:05
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
15-10-2004, 11:15
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
15-10-2004, 11:28
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 :D

ilsensine
15-10-2004, 12:26
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 :D
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...:D

fek
15-10-2004, 12:48
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 :D
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...:D

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][
15-10-2004, 13:12
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;)

DioBrando
15-10-2004, 13:14
Originariamente inviato da fek
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.

in che senso "con ambiente di sviluppo"?

Cioè, a cosa ti riferisci in particolare?


Perchè una distribuzione linux tra le + recenti si installano senza particolari patemi, con la velocità con cui si installa Windows :)

DjMix
15-10-2004, 13:22
Originariamente inviato da ][xwilsonx][
A dire la verità Windows è abbastanza facile!
Mi sa che una balla mostruosa l'hai detta proprio tu.... te lo dice uno che in passato ha usato linux red hat 6.2, e adesso SUSE 9.1...

Ci sei solo abituato, per questo ti viene immediato fare tutto. Non è una sparata mia, è la constatazione di quel che è successo a tanta gente che conosco: cambi da win9x a xp (per esempio) e non si capivano più. Hanno dovuto reimparare dove andar a fare click. E quando si son trovati linux, hanno reimparato a fare click. Questo per dire che _tutti e due_ all'inizio non sono facili. Quando impari ad usarli, lo diventano. Facci caso, d'ora in poi.


ma ne sei sicuro???? prova a far funzionare un modem adsl usb su win e poi prova su linux....
Hai scelto l'esempio peggiore :D quanto mi è arrivata l'adsl mi han dato un alcatel speedtouch ethernet. Non usavo ancora linux (e sinceramente a quei tempi pensavo facesse schifo) e far andare l'adsl con win98 è stato impossibile. Cadeva la connessione di continuo. Mio fratello senza dirmi niente l'ha attaccato al suo pc con linux, non ha dovuto installare 30 mega di driver ma solo 300k, e si è scaricato l'impossibile. A quel tempo ci son rimasto male. Poi ho comprato uno speedtouch USB, e con win98 non sono riuscito a farlo andare (metto dentro il cd, si installa, non và). Con linux ho attaccato il modem, impostato utente e password, fine. Cosè, fortuna? Incapacità mia? Può essere.

DjMix
15-10-2004, 13:27
Originariamente inviato da ][xwilsonx][
Si ma la balla che win nn è facile da usare, proprio nn regge...
E' questo il punto;)
Una cosa è facile quando la conosci. Prima no. Windows lo conosci, quindi PER TE è facile. Io conosco linux, e PER ME è facile. Per chiunque non si interessi di informatica, qualsiasi cosa che abbia un puntatore del mouse e delle icone da cliccare, è FACILE (perchè sono abituati ad una cosa del genere). Dà in mano quello che vuoi a uno di questa ultima categoria e digli di installare una periferica: ti guarderà come per dire "cosè stai scherzando?". Parlo per esperienza, non l'ho letto sui libri.

DjMix
15-10-2004, 13:35
Originariamente inviato da fek
http://www.amazon.co.uk/exec/obidos/ASIN/0137219296/qid=1097781320/ref=sr_8_xs_ap_i1_xgl/202-4027200-9583865
http://www.amazon.co.uk/exec/obidos/ASIN/0471118451/qid=1097781360/ref=sr_8_xs_ap_i1_xgl/202-4027200-9583865
http://www.amazon.co.uk/exec/obidos/ASIN/0321269780/qid=1097781388/ref=sr_8_xs_ap_i1_xgl/202-4027200-9583865

http://www.amazon.co.uk/exec/obidos/ASIN/0333773217/ref=pd_sim_b_dp_3/202-4027200-9583865
http://www.amazon.co.uk/exec/obidos/ASIN/0137519753/ref=pd_sim_b_dp_4/202-4027200-9583865



http://www.amazon.co.uk/exec/obidos...4027200-9583865


Bon. Adesso che abbiamo letto tanti libri, facciamoci un giretto nella realtà. Constaterai con tuo sommo stupore (sgomento?) che fra teoria e pratica c'è una certa differenza. Forse ti conviene non prenderli troppo alla lettera, che dici?

fek
15-10-2004, 13:41
Originariamente inviato da DjMix
Bon. Adesso che abbiamo letto tanti libri, facciamoci un giretto nella realtà. Constaterai con tuo sommo stupore (sgomento?) che fra teoria e pratica c'è una certa differenza. Forse ti conviene non prenderli troppo alla lettera, che dici?

Leggi i libri. Si basano su esperienze pratiche :)

DjMix
15-10-2004, 13:43
Originariamente inviato da fek
Leggi i libri. Si basano su esperienze pratiche :)
Se non si era capito, io ti ho esposto SOLO esperienze pratiche.

fek
15-10-2004, 13:44
Originariamente inviato da DjMix
Se non si era capito, io ti ho esposto SOLO esperienze pratiche.


Allora tu mi stai dicendo che le esperienze dei tuoi amici, valgono piu' di tutta la letteratura sull'argomento interazione uomo-macchina.

Di fronte a tale logica mi arrendo.

ilsensine
15-10-2004, 13:49
Originariamente inviato da fek
Mi fai un po' di generic programming in C? ;)
No grazie, un kernel riesce a vivere senza.


perche' di fatto sta gia' forzando il C a comportarsi da C++ ma senza gli automatismi messi a disposizione dal linguaggio.
Eh no. Vengono usate solo le possibilità previste dal c, senza forzature.
Scrivere un buon programma in c "orientato agli oggetti" non è una forzatura. Non richiede per forza in c++, ma un pò di grano salis in fase di design.


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)
Sarò di legno, ma a meno di non fare lavoro aggiuntivo (nel kernel!) continuo a non esserne convinto. Già il fatto che devi occuparti di definire new/delete adatti, è un lavoro (inutile) in più.
Poi - ti ripeto - in user space non c'è problema, e il c++ è infatti usatissimo. Lo stesso script di configurazione del kernel è scritto - guarda un pò questi fanatici del c - proprio in c++.
Se fosse stato così semplice, e con chissà quali vantaggi, avremmo di sicuro il kernel linux in c++. Mesi di lavoro e di test non sarebbero un problema (figurati, il 2.6 ha richiesto più di un anno), se ci fossero vantaggi effettivi (che io continuo a non vedere).
Giusto qualche giorno fa ho portato una mole di driver di un nostro computer embedded basato su arm dal kernel 2.4 al kernel 2.6; in quest'ultimo è cambiato praticamente tutta l'ira d'Iddio -- metodi aggiunti, driver model cambiato, introduzione della full preemption, introduzione del sysfs e altre amenità -- , ma in mezza giornata mi sono ritrovato i nuovi driver compilati e funzionanti. Quasi tutte le modifiche apportate al core del kernel sono state trasparenti al mio codice (e quelle che non lo erano, si trattava di giuste razionalizzazioni o addirittura semplificazioni -- manutenzione ordinaria, in sintesi), e i miei driver sono comparsi automagicamente in questo sconosciuto sysfs, funzionando come se nulla fosse accaduto e sfruttando appieno le novità introdotte nel 2.6. Mi chiedo cosa ci sia che non va, per te, in una simile architettura.
Riesci a fare tutto questo in c++ -- che ti devo dire, bravo. Ma non mi sembra che sia per forza necessario il c++ per semplificare la vita agli sviluppatori.
Dovresti dargli una occhiata, al kernel linux. Solo per sapere come mai tanti si ostinano ancora a usare un linguaggio - per te - così obsoleto dalla storia.

ilsensine
15-10-2004, 13:54
Originariamente inviato da fek
Non fosse che non c'e' modo di avere accesso alle specifiche interne delle GPU piu' recenti.
<ot> tanto prima o poi glieli buco, i server interni della ATI :muro:

DjMix
15-10-2004, 14:01
Originariamente inviato da fek
Allora tu mi stai dicendo che le esperienze dei tuoi amici, valgono piu' di tutta la letteratura sull'argomento interazione uomo-macchina.

Di fronte a tale logica mi arrendo.
Semmai è la logica che hai usato tu per arrivare a pensare che io abbia detto una cosa del genere, che sfugge a me. Io ti ho detto di non prendere quei libri alla lettera. Non credere una cosa sia facile solo grazie al modo con cui è costruita. È facile tutto quel che si conosce, e difficile tutto il resto. Non riguarda solo OS, ne interfacce: riguarda TUTTO. Mai notato?

Poi, riguardo al discorso C/C++, se ci son persone di un certo livello che han deciso di fare un kernel in un certo modo... oddio si, potrei anche non essere daccordo, ma da qui a dire così alla leggera che non capiscono niente di programmazione C++, io ci penserei due volte sopra, anche con tutti i libri che vuoi.

fek
15-10-2004, 14:11
Originariamente inviato da ilsensine
No grazie, un kernel riesce a vivere senza.

Dici?

Parliamo con esempi concreti, e' cosi' che mi piace dimostrare le mie ragioni.

Esempio banale, un sort. Non dirmi che in un kernel non hai mai bisogno di ordinare elementi, o magari non hai mai bisogno di una coda prioritaria. Si', ne hai bisogno.

E magari hai bisogno di ordinare lo stesso oggetto (un processo? un blocco di memoria? un file?) in base a due diversi criteri. Esempio stupido: voglio ordinare i processi in round roubin in base alla priorita' e poi in base tempo di cpu utilizzato. Diciamo che in un kernel accade una situazione simile.

Ora, come ordini lo stesso oggetto in base a due criteri diversi?

Soluzione 1) Riscrivi la routine di sort due volte, ma nei due diversi casi usi due criteri diversi
Soluzione 2) Scrivi la routine di sort una volta e passi due callback diverse per fare la comparazione in base a due diversi criteri

Non si scappa da qui, puoi fare solo una delle due cose in C (ne puoi fare anche una terza in realta', ma tu sai che non vuoi neppure provare ad impelagarti in un mare di dolori ;)).

La soluzione 1) e' efficiente, ma purtroppo devi mantenere lo stesso codice due volte, devi replicare un'eventuale modifica nella routine di sort due volte e se te ne dimentichi una iniziano i dolori. Nessuno sceglierebbe la soluzione 1.

La soluzione 2) risolve il problema, ma... c'e' una chiamata a funzione che e' una barriera per le ottimizzazioni del compilatore.

In C++ passo un functor per la comparazione, scrivo una sola routine di sort che viene instanziata due volte a tempo di compilazione con due functor diversi e ottimizzata in place. Non c'e' modo che tu in C possa risolvere questo problema in maniera migliore.

Esempio pratico di come un problema frequente in un Kernel possa essere risolto meglio e piu' efficientemente in C++ rispetto al C.

Fammi un esempio del contrario.



Eh no. Vengono usate solo le possibilità previste dal c, senza forzature.
Scrivere un buon programma in c "orientato agli oggetti" non è una forzatura. Non richiede per forza in c++, ma un pò di grano salis in fase di design.


Non mi sono spiegato. Come forzi la "const correctness" in C? Come forzi l'incapsulazione? E l'ereditarieta'? Ed il polimorfismo. Non c'e' modo di esprimere questi concetti in maniera naturale in C, devi emularli. Tutto il C++ puo' essere emulato in C, e' ovvio, ma non con la stessa efficienza di un compilatore nativo. Se hai bisogno di fare dispatching di metodi perche' il tuo problema richiede quella soluzione, puoi emularlo in C, ma per quanto ti sforzi non potrai mai emularlo piu' efficientemente di quello che puo' fare un compilatore C++ che conosce nativamente il concetto di virtual dispatching. Al massimo puoi solo andarci vicino, con notevoli salti mortali, con piu' codice, costringeno i programmatori a seguire convenzioni innaturali che non vengono verificate dal compilatore automaticamente.

Un mondo buio :(


Sarò di legno, ma a meno di non fare lavoro aggiuntivo (nel kernel!) continuo a non esserne convinto. Già il fatto che devi occuparti di definire new/delete adatti, è un lavoro (inutile) in più.

Se scrivi un gestore di memoria dedicato in C stai gia' facendo quel lavoro, ma solo sotto un nome diverso e senza il supporto del compilatore. Ti basi sul fatto che i programmatori che usano quegli oggetti che prevedono il gestore alternativo seguano la convenzione.

Esempio pratico: voglio un gestore di memoria particolare (magari un fixed size) per allocare e deallocare un thread. E' una situazione assolutamente possibile in un Kernel. In C ho la mia struttura Thread e magari due funzioni AllocateThread e DestroyThread. Per convenzione tutti i thread devono essere allocati con queste due funzioni e se invece io uso una malloc? Nulla nel linguaggio me lo impedisce, e nulla controlla (devi scrivere tu il codice per controllare che io stia seguendo la convenzione) e il kernel esplode meravigliosamente dopo il mio check in.
In C++ fai l'overload degli operatori new e delete della classe Thread ed io non ho nessun modo, neppure pregando, di usare un altro allocatore che non sia quello che vuoi tu per la classe Thread (in realta' si', posso ancora farcela, ma devo scrivere un sacco di codice e per farlo devo essere perfettamente conscio di voler circumnavigare dei limiti imposti dal compilatore).
E poi un fixed allocator magari e' uguale per i Thread e per i Process, ed in C lo devi scrivere due volte, o usare call back, ooops, Generic Programming di nuovo ;)


e i miei driver sono comparsi automagicamente in questo sconosciuto sysfs, funzionando come se nulla fosse accaduto e sfruttando appieno le novità introdotte nel 2.6. Mi chiedo cosa ci sia che non va, per te, in una simile architettura.

Non ho nulla contro l'architettura del kernel Linux. Va benissimo.

Riesci a fare tutto questo in c++ -- che ti devo dire, bravo. Ma non mi sembra che sia per forza necessario il c++ per semplificare la vita agli sviluppatori.
Dovresti dargli una occhiata, al kernel linux. Solo per sapere come mai tanti si ostinano ancora a usare un linguaggio - per te - così obsoleto dalla storia.

E' questo il punto: il C++ esprime concetti in uso in un kernel in maniera piu' concisa, efficiente e verificabile di quanto possa fare il C, quindi semplifica la vita agli sviluppatori (se lo conosci, se non lo conosci lo eviti come Linus :p). E' uno strumento piu' espressivo del C.

fek
15-10-2004, 14:12
Originariamente inviato da ilsensine
<ot> tanto prima o poi glieli buco, i server interni della ATI :muro:

(Sending link to Richard Huddy :D)

fek
15-10-2004, 14:15
Originariamente inviato da DjMix
Semmai è la logica che hai usato tu per arrivare a pensare che io abbia detto una cosa del genere, che sfugge a me. Io ti ho detto di non prendere quei libri alla lettera. Non credere una cosa sia facile solo grazie al modo con cui è costruita. È facile tutto quel che si conosce, e difficile tutto il resto. Non riguarda solo OS, ne interfacce: riguarda TUTTO. Mai notato?

E io ti dico di non prendere l'esperienza di qualche tuo amico alla lettera.


Poi, riguardo al discorso C/C++, se ci son persone di un certo livello che han deciso di fare un kernel in un certo modo... oddio si, potrei anche non essere daccordo, ma da qui a dire così alla leggera che non capiscono niente di programmazione C++, io ci penserei due volte sopra, anche con tutti i libri che vuoi.

Lo ripeto. Puoi essere anche Dio sceso in terra, il miglior programmatore di C dell'Universo conosciuto e di buona parte di quello sconosciuto, puoi chiamarti Linus Torvald o come ti pare, ma se dici che in C++ non puoi usare gestori di memoria custom, allora non conosci il linguaggio e non sai di che cosa stai parlando.

E' come se io andassi da un programmatore Java e gli dicessi che Java fa schifo perche' ha l'Ereditarieta' Multipla: lui mi ride in faccia, perche' Java non ha Ereditarieta' Multipla.

DjMix
15-10-2004, 14:23
Originariamente inviato da fek
E io ti dico di non prendere l'esperienza di qualche tuo amico alla lettera.

Se l'avessi presa alla lettera, ti avrei detto che quei libri raccontano solo fandonie. Invece, ti ho solo chiesto di ragionarci su senza prenderli per oro colato. Io ci vedo una bella differenza :rolleyes:

Originariamente inviato da fek
Lo ripeto. Puoi essere anche Dio sceso in terra, il miglior programmatore di C dell'Universo conosciuto e di buona parte di quello sconosciuto, puoi chiamarti Linus Torvald o come ti pare, ma se dici che in C++ non puoi usare gestori di memoria custom, allora non conosci il linguaggio e non sai di che cosa stai parlando.
Guarda, questa questione la puoi risolvere in modo estremamente rapido. Basta che ti fai un giretto su lkml.org, ti raccogli un pò di indirizzi email, fra cui anche quella di Torvalds, e gli spieghi le tue ragioni.

ilsensine
15-10-2004, 14:31
Originariamente inviato da fek
Esempio banale, un sort.
Risposta banale: non farlo. Sort nel kernel? no grazie.
Se proprio hai necessità di gestire una lista in maniera ordinata, creala ordinata e mantienila ordinata. E sì, linux ha primitive generali per la gestione di liste. E non sono state riscritte per tutte le strutture che le usano, ma una volta sola. V. ad es. include/linux/list.h e tutti gli usi dell'oggetto list_head nelle strutture del kernel.

Più in generale: definire un "template" può essere pericoloso. Immagina una funzione template che, nel suo interno, alloca memoria, oppure blocca un semaforo, oppure richiede un modulo dallo user space, oppure attende dati su una wait queue: usa questo bel template, che tanta fatica ti ha fatto risparmiare, in un kernel thread e dentro un timer. Boom: uno dei due esplode. E come mai, che differenca c'è nel gestire un timeout o un kernel thread?
E no, i teorici della General Programming non sapranno spiegarti in maniera esauriente perché il modello non funziona.

fek
15-10-2004, 14:34
Originariamente inviato da DjMix
Guarda, questa questione la puoi risolvere in modo estremamente rapido. Basta che ti fai un giretto su lkml.org, ti raccogli un pò di indirizzi email, fra cui anche quella di Torvalds, e gli spieghi le tue ragioni.

E perche' mai dovrei?

fek
15-10-2004, 14:41
Originariamente inviato da ilsensine
Risposta banale: non farlo. Sort nel kernel? no grazie.
Se proprio hai necessità di gestire una lista in maniera ordinata, creala ordinata e mantienila ordinata. E sì, linux ha primitive generali per la gestione di liste. E non sono state riscritte per tutte le strutture che le usano, ma una volta sola. V. ad es. include/linux/list.h e tutti gli usi dell'oggetto list_head nelle strutture del kernel.

Non hai mai bisogno di ordinare oggetti in un kernel? Dai, non ci credi neppure tu che la scrivi a questa :)

E poi, una lista gia' ordinata non e' cache friendly come un vettore perche' gli elementi possono essere in zone di memoria random.
Per un problema come questo, un vettore da ordinare all'occorrenza e' molto piu' efficiente di una lista preordinata all'inserimento (anche se poi dipende fortemente dai pattern d'uso).
In genere, se vuoi andare veloce, eviti le liste come la peste. Ooops ;)

Poi, immagino che list_head abbia al suo interno un bel void* al quale attacco qualunque oggetto, giusto? Doppia indirezione, va ancora piu' piano di una lista intrusiva, non c'e' controllo sul tipo. In un inner loop questa soluzione ti ucciderebbe, in C++ chiunque lo puo' scrivere un ordine di grandezza piu' veloce e type safe. Scusami, ma se volevi farmi un esempio di come il Kernel debba andare veloce, l'hai scelto sbagliatissimo.


Più in generale: definire un "template" può essere pericoloso. Immagina una funzione template che, nel suo interno, alloca memoria, oppure blocca un semaforo, oppure richiede un modulo dallo user space, oppure attende dati su una wait queue: usa questo bel template, che tanta fatica ti ha fatto risparmiare, in un kernel thread e dentro un timer. Boom: uno dei due esplode. E come mai, che differenca c'è nel gestire un timeout o un kernel thread?

Bingo. E' uno strumento piu' espressivo, quindi piu' difficile da usare. In una situazione del genere non usi un template. Mai usare una feature del linguaggio solo per usarla, senza una reale motivazione.
Se posso esprimere un concetto con un template in maniera piu' efficiente lo faccio (esempio di Thread e Processi), altrimenti no.


E no, i teorici della General Programming non sapranno spiegarti in maniera esauriente perché il modello non funziona.

Funziona, non per tutto, ma quando serve funziona. In C ci devi girare attorno in maniera meno efficiente.

Mi fai un esempio di un problema che in C si puo' risolvere piu' efficientemente che in C++?
Me ne basta uno solo per dichiarare la resa incondizionata :)

DjMix
15-10-2004, 14:49
Originariamente inviato da fek
E perche' mai dovrei?
Argh... ma non stai andando avanti da 3 pagine chiedendo motivi per non usare C++ nel kernel? E chi meglio di loro può darteli????

fek
15-10-2004, 14:54
Originariamente inviato da DjMix
Argh... ma non stai andando avanti da 3 pagine chiedendo motivi per non usare C++ nel kernel? E chi meglio di loro può darteli????

Veramente sto andando avanti 3 pagine a ridacchiare sui motivi che mi sono stati portati. No grazie, non ho bisogno di farmeli ripetere anche da loro.

DjMix
15-10-2004, 15:01
Ah beh.. allora sono proprio degli incompetenti... altro che un kernel, dovrebbero andare a coltivar patate, insomma!

ilsensine
15-10-2004, 15:02
Originariamente inviato da fek
Non hai mai bisogno di ordinare oggetti in un kernel? Dai, non ci credi neppure tu che la scrivi a questa :)
Se ne hai bisogno, è un design sbagliato. Una regola del kernel linux è "non fare nel kernel ciò che puoi fare in user space".


Poi, immagino che list_head abbia al suo interno un bel void* al quale attacco qualunque oggetto, giusto?
[giancarlo@chimera linux]$ cat list.h |grep "void \*"
#define LIST_POISON1 ((void *) 0x00100100)
#define LIST_POISON2 ((void *) 0x00200200)
Nessun altro "void *" in quel file...


E poi, una lista gia' ordinata non e' cache friendly come un vettore perche' gli elementi possono essere in zone di memoria random.
Non mi sono mai capitati casi nel kernel di un vettore da ordinare. Liste dove gli elementi interni possono essere creati e distrutti invece sì.


Bingo. E' uno strumento piu' espressivo, quindi piu' difficile da usare. In una situazione del genere non usi un template. Mai usare una feature del linguaggio solo per usarla, senza una reale motivazione.
Se posso esprimere un concetto con un template in maniera piu' efficiente lo faccio (esempio di Thread e Processi), altrimenti no.
Bingo. Template per kernel thread e user thread? Boom. Hanno un paio di piccole differenza difficilmente "teorizzabili", ma praticamente molto importanti.
Altra "eccezione".


Mi fai un esempio di un problema che in C si puo' risolvere piu' efficientemente che in C++?
Me ne basta uno solo per dichiarare la resa incondizionata :)
A me l'idea delle list_head piace. L'ho usate anche in un programma in c++ una volta. Ma sono gusti, sicuramente la STL offre strumenti più potenti ;)

fek
15-10-2004, 15:12
Originariamente inviato da ilsensine
Se ne hai bisogno, è un design sbagliato. Una regola del kernel linux è "non fare nel kernel ciò che puoi fare in user space".


Ordinare un vettore e' un design sbagliato? Mi risulta difficile crederlo.

Non mi sono mai capitati casi nel kernel di un vettore da ordinare. Liste dove gli elementi interni possono essere creati e distrutti invece sì.

Male.
Un vettore ordinato sarebbe stato piu' efficiente e avrebbe localizzato meglio gli accessi. Ho il sospetto che questa sia una limitazione imposta dal dover usare per forza il C e quella struttura dati.


Bingo. Template per kernel thread e user thread? Boom. Hanno un paio di piccole differenza difficilmente "teorizzabili", ma praticamente molto importanti.
Altra "eccezione".


Ma che discorso e'? Non puoi usare template per trattare un database relazionale ed un motore 3d come la stessa entita', quindi i template non servono a nulla. Stai un po' forzando la mano ;)

In C++ puoi usare i template quando ti servono e se ti servono. In C no, sei costretto a soluzione meno efficienti, altra dimostrazione che al massimo il C e' intrinsecamente meno efficiente del C++ non certo il contrario.


A me l'idea delle list_head piace. L'ho usate anche in un programma in c++ una volta. Ma sono gusti, sicuramente la STL offre strumenti più potenti ;)

Non sono gusti qui, e' una questione di efficienza. Se in un inner loop scorri una lista invece di un vettore, in generale aspettati di andare come minimo dieci volte piu' piano, mica bruscolini. Sei tu che mi ha parlato del fatto che l'efficienza era uno dei parametri per i quali scegliere il C nel kernel, ed ora si scopre che nel kernel di Linux si sceglie volutamente di usare liste quando un array sarebbe stato piu' efficiente e piu' compatto. Capirai che c'e' qualcosa che non va nel tuo ragionamento qui.
Vuoi andare veloce oppure no?

A scanso di equivoci, un array non e' sempre piu' efficiente di una lista, dipende dai pattern di accesso, di inserimento e cancellazione. Se inserisci poco e usi molto, come ad esempio i thread vengono usati molto piu' spesso di quanto vengano creati/distrutti, un array e' una struttura dati piu' efficiente e compatta. E voi usate liste ;)

Mi porti un esempio di un problema che in C puo' essere risolto piu' efficientemente che in C++?

ilsensine
15-10-2004, 15:25
Originariamente inviato da fek
Ordinare un vettore e' un design sbagliato? Mi risulta difficile crederlo.
Ordinare un vettore in kernel space è un design sbagliato.


Male.
Un vettore ordinato sarebbe stato piu' efficiente e avrebbe localizzato meglio gli accessi. Ho il sospetto che questa sia una limitazione imposta dal dover usare per forza il C e quella struttura dati.
Se hai bisogno di un vettore, usa un vettore diamine! Certo che linux li usa!
Ripeto però che non ho mai visto la necessità di ordinare un vettore nel kernel.


In C++ puoi usare i template quando ti servono e se ti servono. In C no, sei costretto a soluzione meno efficienti, altra dimostrazione che al massimo il C e' intrinsecamente meno efficiente del C++ non certo il contrario.
In c++ puoi usare i template quanto ti servono previa dimostrazione che tutte le instanze siano fatte in punti leciti. Facile da fare in user space, un pò meno nel kernel.


Mi porti un esempio di un problema che in C puo' essere risolto piu' efficientemente che in C++?
Non mi prendere in giro dai, sai bene che il c++ supporta praticamente tutti i costrutti c. E' sulla necessità di tutto il resto che sto discutendo.
Che senso ha avere a disposizione i template per poi venire a scoprire che esistono punti "difficilmente teorizzabili" dove un particolare template non funziona e un altro sì?


Ma da piccolo ti hanno fatto una overdose di c che proprio non lo puoi vedere? :D

fek
15-10-2004, 15:31
Originariamente inviato da ilsensine
Ordinare un vettore in kernel space è un design sbagliato.


E perche' mai??????????
Spero ti renda conto dell'enormita' di questa sparata. Gli algoritmi di ordinamento sono la base dell'informatica e mi sta dicendo che sono un design sbagliato in un kernel.
Scusa, ma e' follia pura.
Cioe', in un kernel non hai mai bisogno di ordinare nulla. Piuttosto usi una lista meno efficiente pur di ordinare un vettore perche' la tua religione te lo vieta.
Follia.


In c++ puoi usare i template quanto ti servono previa dimostrazione che tutte le instanze siano fatte in punti leciti. Facile da fare in user space, un pò meno nel kernel.

Ti ho fatto un esempio chiaro come il sole di un esempio che puo' essere risolto piu' efficientemente usando template piuttosto che callback. Non mi hai ancora spiegato che differenza c'e' fra scrivere a mano il codice due volte ed usare un template, perche' il primo va bene in kernel space e il secondo no.
Io sto parlando per esempi specifici.


Non mi prendere in giro dai, sai bene che il c++ supporta praticamente tutti i costrutti c. E' sulla necessità di tutto il resto che sto discutendo.
Che senso ha avere a disposizione i template per poi venire a scoprire che esistono punti "difficilmente teorizzabili" dove un particolare template non funziona e un altro sì?

Mi spieghi bene questo discorso di "punti difficilmente teorizzabili dove un particolare template non funziona"? Non vorrei sembrare brusco, ma non ha alcun senso.


Ma da piccolo ti hanno fatto una overdose di c che proprio non lo puoi vedere? :D

Da piccolo programmavo in C poi mi sono evoluto :)
Esistono strumenti piu' potenti e andrebbero usati, e' come arare un campo con l'aratro invece che con una macchina moderna, adducendo motivazioni assurde per dire che tanto non ti serve.
Si', se arare il campo meglio ti serve, se vuoi scrivere un kernel migliore lo scrivi in C++.

ilsensine
15-10-2004, 15:59
Originariamente inviato da fek
E perche' mai??????????
Spero ti renda conto dell'enormita' di questa sparata. Gli algoritmi di ordinamento sono la base dell'informatica e mi sta dicendo che sono un design sbagliato in un kernel.
Scusa, ma e' follia pura.
Sì lo so siamo folli.
Sarà per questa follia che abbiamo uno scheduler con complessità costante nel numero dei processi, da far invidia agli unix più sofisticati ;)

Un ordinamento da dati casuali (quindi ex-novo) non soddisfa i requisiti di scalabilità richiesti da un kernel. Mi sembra ovvio.

fek
15-10-2004, 16:10
Originariamente inviato da ilsensine
Sì lo so siamo folli.
Sarà per questa follia che abbiamo uno scheduler con complessità costante nel numero dei processi, da far invidia agli unix più sofisticati ;)

Un ordinamento da dati casuali (quindi ex-novo) non soddisfa i requisiti di scalabilità richiesti da un kernel. Mi sembra ovvio.

Non mi sono spiegato: immagina di aver bisogno di ordinare i thread in base al tempo CPU occupato (un problema teoricamente possibile in un kernel, non significa che Linux e' implementato cosi' o dovrebbe esserlo, e' un esempio). Tu mi consigli di usare una lista e di ordinare ad ogni nuovo thread inserito, io consiglio di usare un vettore ed ordinarlo ogni volta che viene modificato.

Per come la giri, usare un vettore e ordinarlo in C++ e' piu' efficiente che usare una lista e cercare di mantenerla ordinata ad ogni inserimento. Non si scappa.

Mi fai un esempio di qualcosa che in C puo' essere scritto piu' efficientemente che in C++?
E' l'unico modo che hai per giustificare l'uso del C invece del C++.
Se in C++ posso fare tutto quello che faccio in C in maniera piu' efficiente ed usare anche feature che mi semplificano la vita, non c'e' alcuna ragione tecnica per non preferirlo, ovvero, la tua prima affermazione dal quale e' nato il discorso e' falsa.

ilsensine
15-10-2004, 16:53
Originariamente inviato da fek
Non mi sono spiegato: immagina di aver bisogno di ordinare i thread in base al tempo CPU occupato (un problema teoricamente possibile in un kernel, non significa che Linux e' implementato cosi' o dovrebbe esserlo, e' un esempio). Tu mi consigli di usare una lista e di ordinare ad ogni nuovo thread inserito, io consiglio di usare un vettore ed ordinarlo ogni volta che viene modificato.
Regola di scalabilità: non usare vettori per oggetti di numero variabile. Se hai pochi oggetti, il sistema non è efficiente. Inoltre limiti il numero di oggetti che il tuo sistema può gestire.
Linux non ordina in base al tempo di cpu occupato, ma in base a fattori di priorità dinamici. Usa una struttura a liste circolari collegate (orrore? :D ) per accorpare i processi con simile priorità. La struttura è alquanto complicata (soprattutto in ambiente smp, dove esistono varie runqueue per i diversi processori, e dove bisogna decidere "quando/se/perché spostare un task da una runqueue all'altra"), ma garantisce un accesso O(1) al nuovo task da mandare in esecuzione.
Il risultato è che ho davanti una applicazione che non so quanti thread può creare, in quanto dopo i primi 4000 finiscono gli indirizzi virtuali a disposizione degli stack. Due istanze (8000 thread) producono un utilizzo di processore <30% a regime, su un computer normalissimo.
Vatti a ordinare 8000 elementi ogni volta...solo per scegliere il nuovo processo da mandare in esecuzione? _Questa_ è follia.


Per come la giri, usare un vettore e ordinarlo in C++ e' piu' efficiente che usare una lista e cercare di mantenerla ordinata ad ogni inserimento. Non si scappa.
A un kernel non serve questo. Come non servono tante altre cose del c++.
O dovrei usare il c++ "per forza", per poi usarlo come il c, così sei contento? ;)

(uè se ci scrivi qualche driver 3d te la faccio io una interfaccia c++, anche in java se vuoi :D )

fek
15-10-2004, 17:26
Originariamente inviato da ilsensine
Regola di scalabilità: non usare vettori per oggetti di numero variabile. Se hai pochi oggetti, il sistema non è efficiente. Inoltre limiti il numero di oggetti che il tuo sistema può gestire.

Regola di buon senso. I vettori possono essere ridimensionati a runtime, se fai molti piu' accessi che inserimenti, i vettori ridimensionaibili sono ottimi, compatti, e veloci.
Inserimento in coda e' O(1) [ammortizzato]
Rimozione e' O(N)
Accesso e' O(1)
Ordinamento e' O(N log N).

Per rimozioni saltuarie batte sempre e comunque una lista.
Scrivilo sulla mailing list ufficiale che magari non lo sanno ;)

Se in Linux non si ridimensionano i vettori e si preferisce usare le liste siamo ridotti davvero cosi' male.


Linux non ordina in base al tempo di cpu occupato, ma in base a fattori di priorità dinamici. Usa una struttura a liste circolari collegate (orrore? :D ) per accorpare i processi con simile priorità. La struttura è alquanto complicata (soprattutto in ambiente smp, dove esistono varie runqueue per i diversi processori, e dove bisogna decidere "quando/se/perché spostare un task da una runqueue all'altra"), ma garantisce un accesso O(1) al nuovo task da mandare in esecuzione.


Ripeto per l'ennesima volta e magari lo scrivo in grassetto, ho fatto un esempio di un algoritmo che puo' servire in un Kernel, non ho mai detto che Linux e' implementato cosi' oppure dovrebbe essere implementato cosi'.
Stai cercando di cambiare discorso perche' non hai modo di rispondere alla mia obiezione: trovami un modo piu' efficiente di risolvere un problema tipico in un Kernel di un SO in C.
Non puoi. Non lo troverai mai, per questo cerchi di cambiare discorso.

Vatti a ordinare 8000 elementi ogni volta...solo per scegliere il nuovo processo da mandare in esecuzione? _Questa_ è follia.

Qualcuno ha parlato di ordinarli ogni volta? Leggi bene quello che ho detto, ordinamento dopo l'inserimento e la rimozione.

Se proprio voglio scrivere uno scheduler che ordina in maniera sofisticata in base ad uno o piu' criteri (se conosci la teoria della schedulazione sai che e' un algoritmo possibile, non necessariamente il migliore in tutte le condizioni ma e' possibile) i thread in un determinato basket in round robin allora non puoi scriverlo piu' veloce in C. Non c'e' modo.


A un kernel non serve questo. Come non servono tante altre cose del c++.
O dovrei usare il c++ "per forza", per poi usarlo come il c, così sei contento? ;)


Devi usare le caratteristiche del C++ quando servono e quando risolvono meglio il problema, perche' non c'e' nulla che in C possa essere scritto meglio che in C++. Mi hai detto tu che il Kernel di Linux e' gia' scritto ad oggetti, tanto vale usare un linguaggio ad oggetti che e' intrinsecamente piu' veloce.
Tanto e' vero che hai bellamente sempre glissato su queste domande:


Mi quoto:

- Come forzi la "const correctness" in C?
- Come forzi l'incapsulazione?
- E l'ereditarieta'?
- Ed il polimorfismo.

Non c'e' modo di esprimere questi concetti in maniera naturale in C, devi emularli. Tutto il C++ puo' essere emulato in C, e' ovvio, ma non con la stessa efficienza di un compilatore nativo. Se hai bisogno di fare dispatching di metodi perche' il tuo problema richiede quella soluzione, puoi emularlo in C, ma per quanto ti sforzi non potrai mai emularlo piu' efficientemente di quello che puo' fare un compilatore C++ che conosce nativamente il concetto di virtual dispatching. Al massimo puoi solo andarci vicino, con notevoli salti mortali, con piu' codice, costringeno i programmatori a seguire convenzioni innaturali che non vengono verificate dal compilatore automaticamente.


Sono tre pagine che svicoli queste domande e non rispondi e, soprattutto, non rispondi a questo:

Mi fai un esempio di un problema che puo' essere risolto piu' efficientemente in C che in C++?

You can run but you can't hide ;)

fek
15-10-2004, 17:36
Vorrei arrivare finalmente ad una benedetta conclusione.
Da questa discussione abbiamo scoperto che:

1) Non c'e' alcun problema che possa essere risolto in C piu' efficientemente che in C++ (a meno che non arrivi finalmente un esempio contrario)

2) Esistono classi di problemi (quali l'ordinamento di un vettore con criteri multipli) che possono essere risolti piu' efficientemente in C++ che in C

3) Al limite, il C++ puo' essere usato esattamente come il C e non introduce alcuna inefficienza intrinseca, al limite e' uguale

4) Implementare concetti OOP in C pone problemi di inefficienza rispetto al C++ ed il compilatore non e' in grado di verificarne la correttezza automaticamente

Direi che questi quattro punti sono fatti inequivocabili (a meno che non arrivi una tardiva dimostrazione del contrario).

Ora, il problema iniziale era:
"Esistono motivazioni tecniche che non permettono di implementare il Kernel Linux in C++"

Alla luce di questi quattro punti direi che l'affermazione e' falsa. E' vero invece il contrario: un'implementazione in C++ sarebbe piu' efficiente dell'implementazione in C, al limite sarebbe uguale offrendo pero' un modo piu' naturale di esprimere i concetti OOP del Kernel Linux in un linguaggio che li supporta nativamente.

3v1l
15-10-2004, 17:56
qui ci vorrebbe repne scasb :D :D

RaouL_BennetH
15-10-2004, 18:02
Con la premessa che di programmazione la cosa migliore che io abbia mai fatto è stata "hello world" su più righe, però penso:

Se il kernel di linux e di altri sistemi operativi vengono scritti in C, una dannata ragione ci dovrà pur essere? perchè non posso pensare che, ai livelli di chi scrive cose di quell'importanza, si preferisca un linguaggio al posto di un altro solo per "religione". Cioè, credo che vengano fatte valutazioni davvero importanti per decidere cosa sia meglio e il perchè. Personalmente, del bellissimo dialogo tra fek e ilsensine, posso solo ammirarne le passioni dell'uno e dell'altro perchè tecnicamente, non ci capisco un beneamato...:(

fek
15-10-2004, 18:06
Originariamente inviato da RaouL_BennetH
Con la premessa che di programmazione la cosa migliore che io abbia mai fatto è stata "hello world" su più righe, però penso:

Se il kernel di linux e di altri sistemi operativi vengono scritti in C, una dannata ragione ci dovrà pur essere? perchè non posso pensare che, ai livelli di chi scrive cose di quell'importanza, si preferisca un linguaggio al posto di un altro solo per "religione". Cioè, credo che vengano fatte valutazioni davvero importanti per decidere cosa sia meglio e il perchè. Personalmente, del bellissimo dialogo tra fek e ilsensine, posso solo ammirarne le passioni dell'uno e dell'altro perchè tecnicamente, non ci capisco un beneamato...:(

La ragione esiste ed e' ottima. Sarebbe un suicidio buttare tutto il codice del Kernel ora e ripartire daccapo scrivendolo in C++. Rallenterebbe troppo lo sviluppo di nuove feature ed e' qualcosa che Linux non puo' sicuramente permettersi ora.
Quando Linux fu scritto 12 anni fa esisteva un'ottima ragione per non usare il C++: non era un linguaggio maturo come lo e' oggi.

Non esistono al contrario ragioni tecniche che lo impedirebbero: il Kernel in C++ riscritto da zero (da gente che lo sa fare) sarebbe molto probabilmente un prodotto migliore.

Il Kernel di WinNT (e XP) e' scritto in C, tutta l'API e' in C, e' un errore che ancora si paga.

DioBrando
15-10-2004, 18:10
Originariamente inviato da 3v1l
qui ci vorrebbe repne scasb :D :D

MedioMaaan pensaci tuuu :D


cmq sarebbe un altro interlocutore stimolante nella già interessante discussione :)

Ikitt_Claw
15-10-2004, 18:22
Originariamente inviato da fek
La ragione esiste ed e' ottima. Sarebbe un suicidio buttare tutto il codice del Kernel ora e ripartire daccapo scrivendolo in C++. Rallenterebbe troppo lo sviluppo di nuove feature ed e' qualcosa che Linux non puo' sicuramente permettersi ora.
Quando Linux fu scritto 12 anni fa esisteva un'ottima ragione per non usare il C++: non era un linguaggio maturo come lo e' oggi.
Esattamente questo il punto. Ma se lo sapevi, qualche maligno potrebbe pensare che hai alimentato le braci e basta, sinora ;)


Il Kernel di WinNT (e XP) e' scritto in C, tutta l'API e' in C, e' un errore che ancora si paga.
Coraggio, coraggio, il prossimo sara` in .NET e il mondo sara` migliore :sofico:

Ikitt_Claw
15-10-2004, 18:26
Originariamente inviato da ][xwilsonx][
Si ma la balla che win nn è facile da usare, proprio nn regge...
E' questo il punto;)
Windows (la GUI di) non adotta una metafora perfetta. Non e` intuitivo, nel senso che uno che non ha mai visto un PC prima non riesce a far tutto al primo colpo. Questo non e` affatto sorprendente e` noto anche a MS stessa, che non a caso continua a modificare la sua UI.
Una non trascurabile parte della "facilita` d'uso" di windows deriva dall'abitudine alla sua interfaccia, e alcuni iniziano (finalmente) a riconoscerlo. E` questo il punto.

Ikitt_Claw
15-10-2004, 18:28
Originariamente inviato da fek
In C++ puoi usare i template quando ti servono e se ti servono.

Fermi restandi i limiti del compilatore g++. In g++ i template introducevano un certo bloat che non era molto ben visto ai tempi. E anche adesso la situazione non so se e quanto e` migliorata. E no, cambiate compilatore non e` una strada percorribile a noi sfigati ;)

fek
15-10-2004, 18:29
Originariamente inviato da Ikitt_Claw
Esattamente questo il punto. Ma se lo sapevi, qualche maligno potrebbe pensare che hai alimentato le braci e basta, sinora ;)


Credo ci sia stato un malinteso :P

Ho detto quasi all'inizio che io non avrei mai pensato di riscrivere il Kernel in C++ ora, ma si stava discutendo se fosse tecnicamente possibile scrivere il Kernel in C++ in maniera almeno altrettanto efficiente.
Direi che e' tecnicamente possibile.

Coraggio, coraggio, il prossimo sara` in .NET e il mondo sara` migliore :sofico:

Sono combattuto. Il .NET mi piace, se fosse possibile ci scriverei un intero gioco, ma probabilmente non il motore 3d, figuriamoci un kernel. Non so, non ho un'idea precisa sull'argomento. Sulla carta l'idea e' ottima. Dai un'occhiata al libro di Don Box sul .NET.

DioBrando
15-10-2004, 18:33
Originariamente inviato da Ikitt_Claw

Coraggio, coraggio, il prossimo sara` in .NET e il mondo sara` migliore :sofico:

oddio se il kernel è rapido nell'esecuzione così come lo è il compilatore Studio.Net....che Dio ci scampi :D

fek
15-10-2004, 18:34
Originariamente inviato da Ikitt_Claw
Fermi restandi i limiti del compilatore g++. In g++ i template introducevano un certo bloat che non era molto ben visto ai tempi. E anche adesso la situazione non so se e quanto e` migliorata. E no, cambiate compilatore non e` una strada percorribile a noi sfigati ;)

Non conosco con precisione l'implementazione dei template nel g++, in genere il code bloat non e' un problema del compilatore o dei template, ma di come vengono usati.

Abusa dei template e ti trovi tempi di compilazione enormi e codice sproporzionato. Usati con giudizio e sapendo che cosa si sta facendo, arrivano anche a ridurre le dimensioni del codice in molti casi.
Ma usare i template in maniera considerata e' piu' facile a dirsi che a farsi, io ad esempio mi fido poco e tendo ad evitarli quando possibile.

Ikitt_Claw
15-10-2004, 18:47
Originariamente inviato da fek
ma si stava discutendo se fosse tecnicamente possibile scrivere il Kernel in C++ in maniera almeno altrettanto efficiente.
Direi che e' tecnicamente possibile.
Quasi sicuramente e` cosi`, per quel che mi suggeriscono le mie conoscenze
E` altrettanto vero che al tempo scrivere Linux in C++ tendeva alla follia (e si, per quel che mi risulta anche per limitazioni di g++ e scarsa conoscienza dei principali autori), cosi` come riscriverlo, adesso, in prossimita` della versione 2.6.9 sarebbe una mossa alquanto folle ;)


Sono combattuto. Il .NET mi piace, se fosse possibile ci scriverei un intero gioco, ma probabilmente non il motore 3d, figuriamoci un kernel. Non so, non ho un'idea precisa sull'argomento. Sulla carta l'idea e' ottima. Dai un'occhiata al libro di Don Box sul .NET.
Purtroppo la fifo (con priorita`) dei libri da leggere e` gia` abbastanza lunga, ma prima o poi un'occhiata a mono ( :D ) la do di certo ;)

corretto il tiro sulla fattibilita`, troppa sicumera e poca esperienza sono fonte di guai...

Ikitt_Claw
15-10-2004, 18:49
Originariamente inviato da fek
Non conosco con precisione l'implementazione dei template nel g++, in genere il code bloat non e' un problema del compilatore o dei template, ma di come vengono usati.[/b]
Ci furono discussioni abbastanza infiammate sulla scena ai tempi, sopratutto, di gcc 2.95. Adesso probabilmente la situazione e` migliorata, ma non seguo molto la scena C++ per cui non so essere piu` preciso.
Comunque, non mi risulta che g++ supporti ancora export, cosi` in template devono essere tutti "espansi in linea".

Ma usare i template in maniera considerata e' piu' facile a dirsi che a farsi, io ad esempio mi fido poco e tendo ad evitarli quando possibile.
Centro, ancora una volta...

cdimauro
16-10-2004, 08:04
Originariamente inviato da joe4th
Vogliamo parlare dei driver conexant o adesso di quelli
ECI per i modem ADSL USB, per i quali sono venute fuori battaglie legali?
Cosa vorresti dire (mi riferisco in merito al pezzo che mi hai quotato)?
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),
Sono riuscito a stento a finire di leggere l'introduzione a "Codice Libero": poi mi sono rifiutato di continuare...
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.
Allora spiegami: che senso ha lavorare a OSDL? Tanto vale lasciare le cose come stanno...
Dei driver binari di nVidia, comunque, non mi pare di aver letto tante lamentele, anzi. E sono binari, appunto.
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.
Se dei driver binari non funzionano bene, non vuol dire che tutti si comportino allo stesso modo.
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.
Non è obbligatorio utilizzare quelli 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.
Ai tempi del DOS e della coesistenza con Windows, ci fu un progetto di questo tipo per le schede video: penso che sia morto per strada, anche se si trattava di un'ottima idea.
Visto che quello che verrebbe emulato e' piu' stabile del sistema nativo che starebbe fuori, direi proprio di no.
XP lo trovo stabile. E comunque meglio usare XP come base se l'obiettivo è quello di poter anche giocare col PC, no? ;)

cdimauro
16-10-2004, 08:16
Originariamente inviato da Ikitt_Claw
pero` driver e SO (quantomeno nei macrokernel) dovrebbero seguire la stessa filosofia di sviluppo, e cosi`...
Con BeOS, che è un s.o. closed-source, erano disponibili più driver open source che closed.
Per me sono due cose completamente slegate.
Uh, beh, in effetti si intuisce vagamente ;)
Parlo da studioso di s.o., comunque. ;)
Da utente, lavorando con BeOS non mi sono mai lamentato del fatto che sotto ci fosse un kernel POSIX-compliant e che aprendo il terminale mi ritrovavo la bash... :D
Nel 1994 o quand'era, considerando la situazione di g++, non aveva proprio tutti i torti...
Allora forse non si sa spiegare bene. Perché normalmente uno che mi scrive che "C++ s*ks" lo etichetto come un lamer che spala letame per nascondere la sua ignoranza.

Una persona intelligente avrebbe scritto: "quando, nel 1994, abbiamo provato il compilatore g++, era bacato e abbiamo avuto problemi".

Comunque, da allora sono passi DIECI anni: una persona altrettanto intelligente, che riconosce nel C++ uno strumento di lavoro, magari si sarebbe documento e/o avrebbe fatto qualche prova prima di lasciarsi andare a un simile commento.

Infatti in quel forum è stato letteralmente sbranato per queste assurdità da persone che sanno che il fatto loro.
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...
Non lo metto in dubbio. Ma ciò non toglie che non si possa fare una lotta ideologica contro i driver binari, soltanto per il s.o. è open source: sono due distinte e separate, che vanno trattate in modo diverso.

cdimauro
16-10-2004, 08:23
Originariamente inviato da ilsensine
Ha perfettamente ragione, ho commentato la cosa fino alla nausea nella sez. linux. Ci sono ragioni tecnico/legali legati a quella vicenda.
Ho letto con interesse quel thread.
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ò.
E perché no? Sono degli strumenti molto utili, per chi sa usarli...
Se ci sono delle questioni legali (perché di problemi tecnici non ne vedo), si può sempre trovare il modo di risolverli.
nb visto che sei così informato sul kernel linux,
Non tanto: mi limito a seguire la tua sezione, ogni tanto, e leggere qualche thread che reputo interessante... ;)
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 ;)
Non lo sapevo: la cosa mi fa piacere, perché gli utenti continueranno ad essere supportati.
A me però interessa solamente il lato tecnico della faccenda... ;)
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++.
Mi spiace, ma sono state tutte smontate da fek, di cui quoto parola per parola; mi spiace di non poter essere intervenuto prima, ma pur avendo una connessione 24h/24 ho avuto altro da fare...

fek comunque non è certo stato il primo, anzi: in quel thread l'argomento è stato sviscerato e l'infelice uscita di Linus fatta letteramente a pezzi con le medesime argomentazioni.

cdimauro
16-10-2004, 08:27
Originariamente inviato da sheijtan
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? ;)
Certo. :D Sulla perdita di tempo ho già disquisito molto tempo addietro nel forum... ;)
(scherzo, eh...non ti arrabbiare che se no inondi il forum di post...)
Ormai mi conosci... ;)
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.
Anche Windows si può fare lo stesso...
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.
Anche qui fek mi ha anticipato... :p
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 questo ringrazio Xerox, non Bill... ;)
Però è contrario al MIO gusto e finché potrò cercherò di farne a meno... (mannaggia per half life 2, eh...)
ciao!
OK. Sui gusti non ho mai fatto obiezione (ci mancherebbe!). ;)

DjMix
16-10-2004, 08:40
Originariamente inviato da cdimauro
Dei driver binari di nVidia, comunque, non mi pare di aver letto tante lamentele, anzi. E sono binari, appunto.

Allora hai letto poco. Molto poco. Oltre al fatto che sono binari, e che per supportare nuove versioni di kernel si fa prima ad arrangiarsi sulla parte di codice open piuttosto che aspettare nvidia, ci son bachi disarmanti presenti da MESI che non sono ancora stai corretti (uno a caso: corruzzione del framebuffer). Senza contare l'assoluta instabilità in sistemi smp. Se poi ci aggiungiamo che il tvout viene supportato solo dai binari in schede con chip conexant, e che il dual-head segue la stessa strada, allora siamo a posto... era così impossibile fornire le specifiche del tv-out? del dual-head? Sarebbero andati così in fallimento? Ai posteri l'ardua sentenza. Sta di fatto che di rogne ne danno un macello. Per avere conferma basta che vai su www.nvidia.com e ti spulci il forum, è _pieno_ di gente che ha rogne. P.S: i driver ATI son messi peggio....

Ikitt_Claw
16-10-2004, 09:04
Originariamente inviato da cdimauro
Mi spiace, ma sono state tutte smontate da fek, di cui quoto parola per parola; mi spiace di non poter essere intervenuto prima, ma pur avendo una connessione 24h/24 ho avuto altro da fare...
Acqua. Fek ha controbattuto (con successo) l'asserzione secondo la cui non si puo` realizzare un generico kernel in C++.
Per Linux e` stato diverso. E ci sono state motivazioni precise per cui e` stato diverso, non un mero "Si fa cosi` perche` si" di Torvalds (perche` da questo si e` partiti).

fek comunque non è certo stato il primo, anzi: in quel thread l'argomento è stato sviscerato e l'infelice uscita di Linus fatta letteramente a pezzi con le medesime argomentazioni.
L'infelice uscita di Linussi colloca attorno al 1994, circa 10 anni fa e circa 4 prima dello standard C++, non dimentichiamolo.
Che poi resti infelice puo` darsi benissimo, ma verifichiamolo col metro del 1994/95, non del 2004/2005...

Ikitt_Claw
16-10-2004, 09:10
Originariamente inviato da cdimauro
Con BeOS, che è un s.o. closed-source, erano disponibili più driver open source che closed.
Ancora ci giriamo intorno: BeOS e` closed source, puo` accettare benissimo driver open-source (ci mancherebbe).

Per me sono due cose completamente slegate.

I device driver fanno parte del kernel? Se no, sono slegate :)
Se si, dovrebbero idealmente seguire lo stesso percorso di sviluppo del kernel, abbastanza ovviamente :)
I tizi di kernel.org pensano che dovrebbero far parte del kernel, e cercano di seguire (e far seguire) questa strada con tutti i loro mezzi. E` nel loro diritto ;)


Allora forse non si sa spiegare bene. Perché normalmente uno che mi scrive che "C++ s*ks" lo etichetto come un lamer che spala letame per nascondere la sua ignoranza.

Per quanto Torvalds abbia talvolta uscite di tal fatta, questa devo dire mi mancava :)


Comunque, da allora sono passi DIECI anni: una persona altrettanto intelligente, che riconosce nel C++ uno strumento di lavoro, magari si sarebbe documento e/o avrebbe fatto qualche prova prima di lasciarsi andare a un simile commento.
Si ma _quale_ commento, che a questo punto mi sa che mi son perso qualcosa?

cdimauro
16-10-2004, 12:36
Originariamente inviato da DjMix
Allora hai letto poco. Molto poco.
E' possibile: Linux non è il mio s.o. "primario"... ;)
Oltre al fatto che sono binari, e che per supportare nuove versioni di kernel si fa prima ad arrangiarsi sulla parte di codice open piuttosto che aspettare nvidia,
Questo è normale: nVidia non può certo mettere a disposizione le stesse risorse che riserva all'utenza Windows...
ci son bachi disarmanti presenti da MESI che non sono ancora stai corretti (uno a caso: corruzzione del framebuffer). Senza contare l'assoluta instabilità in sistemi smp. Se poi ci aggiungiamo che il tvout viene supportato solo dai binari in schede con chip conexant, e che il dual-head segue la stessa strada, allora siamo a posto...
Vedi sopra: è normale, visto le limitate risorse che mette a disposizione...
era così impossibile fornire le specifiche del tv-out? del dual-head? Sarebbero andati così in fallimento? Ai posteri l'ardua sentenza.
Qui lo sai bene che entrano in gioco dei notevoli interessi: nel campo delle schede video e delle GPU c'è una guerra con Ati, e nessuno può permettersi il lusso di giocare a carte scoperte.
Sta di fatto che di rogne ne danno un macello. Per avere conferma basta che vai su www.nvidia.com e ti spulci il forum, è _pieno_ di gente che ha rogne. P.S: i driver ATI son messi peggio....
Per questi ultimi lo so: ho letto qualche thread nell'area Linux, e mi sembrava che i commenti a proposito di quelli nVidia fossero esaltati, addirittura anche da parte de ilsensine... :D
Indubbiamente seguendo un solo forum mi sarò fatto un'idea sbagliata...

cdimauro
16-10-2004, 12:40
Originariamente inviato da Ikitt_Claw
Acqua. Fek ha controbattuto (con successo) l'asserzione secondo la cui non si puo` realizzare un generico kernel in C++.
Le affermazioni di fek, a mio avviso, si possono benissimo estendere a qualunque s.o. e/o applicazione.
Per Linux e` stato diverso. E ci sono state motivazioni precise per cui e` stato diverso, non un mero "Si fa cosi` perche` si" di Torvalds (perche` da questo si e` partiti).
Motivazione smentite. E fek si riferiva anche a Linux.
L'infelice uscita di Linussi colloca attorno al 1994, circa 10 anni fa e circa 4 prima dello standard C++, non dimentichiamolo.
Che poi resti infelice puo` darsi benissimo, ma verifichiamolo col metro del 1994/95, non del 2004/2005...
Il problema è che quell'affermazione l'ha ripetuta di recente... E comunque, ripeto: ha scelto il modo sbagliato per esprimere le sue opinioni...

RaouL_BennetH
16-10-2004, 12:46
per avere una risposta dal diretto interessato, ho mandato una mail a Linus in persona, con la speranza che risponda ovviamente :) . Gli ho semplicemente chiesto se ci sono ragioni tecniche valide per preferire il C al C++ per il kernel e, se casomai dovesse rispondermi, incollerò qui il contenuto della risposta, dato che io non sono assolutamente in grado di capirne gli eventuali contenuti. Che dire, speriamo che risponda.

cdimauro
16-10-2004, 12:46
Originariamente inviato da Ikitt_Claw
Ancora ci giriamo intorno: BeOS e` closed source, puo` accettare benissimo driver open-source (ci mancherebbe).
Quindi per te il problema si pone esclusivamente per un s.o. open source: dovrebbe per forza di cose accettare esclusivamente driver open source...
I device driver fanno parte del kernel? Se no, sono slegate :)
Dipende dai punti di vista: generalmente quando si studiano i s.o. nella "cipolla" il kernel sta al centro, nello strato successivo ci sono i driver. Quindi sono separati: d'altra parte hanno funzioni diverse.
Poi si può anche discutere se debbano girare nel kernel space o nello user space, ma questo è un altro discorso.
Se si, dovrebbero idealmente seguire lo stesso percorso di sviluppo del kernel, abbastanza ovviamente :)
I tizi di kernel.org pensano che dovrebbero far parte del kernel, e cercano di seguire (e far seguire) questa strada con tutti i loro mezzi. E` nel loro diritto ;)
Indubbiamente. Ciò non toglie che mi posso permettere di criticare questa strada... ;)
Per quanto Torvalds abbia talvolta uscite di tal fatta, questa devo dire mi mancava :)

Si ma _quale_ commento, che a questo punto mi sa che mi son perso qualcosa?
Evidentemente sì. Purtroppo ho perso ben più di un'ora a cercare nei meandri di questo forum, ma non sono riuscito a risalire alla discussione in cui ne ne parlava: sfortunamente le ricerche sono limitate nel tempo. E anche Google non m'è stato d'aiuto.

Comunque, si tratta di dichiarazioni di un po' di mesi addietro, certamente non risalenti al (ben) lontano 1994.

DioBrando
16-10-2004, 12:47
Originariamente inviato da cdimauro
Le affermazioni di fek, a mio avviso, si possono benissimo estendere a qualunque s.o. e/o applicazione.

Motivazione smentite. E fek si riferiva anche a Linux.

Il problema è che quell'affermazione l'ha ripetuta di recente... E comunque, ripeto: ha scelto il modo sbagliato per esprimere le sue opinioni...

per onestà intellettuale avrebbe potuto dire che al gg d'oggi quelle convinzioni possono essere cambiate, in questo Torvalds ha sbagliato.

Ma quando 10 anni fà i mezzi non erano quelli attuali ( io cmq mi ricordavo che Linux fosse datato 91-92 :D) non gli si può dar torto di quella scelta.

Ed è una reprimenda come ha detto bene fek in precedenza si portano dietro + o - tutti gli SO, dato che sn basati sul C...ma purtroppo la riprogettazione da 0 costa uno sproposito di tempo-denaro e solo grandi gruppi con alle spalle liquidità in abbondanza ( tipo MS), possono permettersi questi cambiamenti IMHO.


Quindi, a mio parere, giusto "censurare" gli sproloqui di Linus sul C++, ma giusto anche datare quelle scelte in un determinato periodo storico, nel quale i compilatori di una volta non possono minimamente essere paragonati agli Studio o Builder di adesso :)

cdimauro
16-10-2004, 12:49
Originariamente inviato da RaouL_BennetH
per avere una risposta dal diretto interessato, ho mandato una mail a Linus in persona, con la speranza che risponda ovviamente :) . Gli ho semplicemente chiesto se ci sono ragioni tecniche valide per preferire il C al C++ per il kernel e, se casomai dovesse rispondermi, incollerò qui il contenuto della risposta, dato che io non sono assolutamente in grado di capirne gli eventuali contenuti. Che dire, speriamo che risponda.
Ha già risposto nel thread che ho citato, ma che non sono riuscito a recuperare. Ed è stato letteralmente sbranato.
Comunque, sentiamo cos'altro avrà da dire eventialmente: magari la lezione gli sarà servita, e sarà rinsavito nel frattempo... ;)

cdimauro
16-10-2004, 12:53
Originariamente inviato da DioBrando
per onestà intellettuale avrebbe potuto dire che al gg d'oggi quelle convinzioni possono essere cambiate, in questo Torvalds ha sbagliato.
E per questo, appunto è stato criticato.
Ma quando 10 anni fà i mezzi non erano quelli attuali ( io cmq mi ricordavo che Linux fosse datato 91-92 :D) non gli si può dar torto di quella scelta.
Della scelta no. Ma che almeno dica le cose come stanno: la colpa non è del linguaggio, ma del compilatore. E di chi non sa programmare correttamente in C++...
Ed è una reprimenda come ha detto bene fek in precedenza si portano dietro + o - tutti gli SO, dato che sn basati sul C...ma purtroppo la riprogettazione da 0 costa uno sproposito di tempo-denaro e solo grandi gruppi con alle spalle liquidità in abbondanza ( tipo MS), possono permettersi questi cambiamenti IMHO.
Ampiamente d'accordo.
Quindi, a mio parere, giusto "censurare" gli sproloqui di Linus sul C++, ma giusto anche datare quelle scelte in un determinato periodo storico, nel quale i compilatori di una volta non possono minimamente essere paragonati agli Studio o Builder di adesso :)
D'accordo, ma vedi sopra: le "esternazioni" di Linus non erano certe legate al periodo storico, ma si prestavano ad assurde generalizzazioni. Il peso alle cose bisogna saperlo dare, come giustamente dici, in base al periodo storico, ma non si posso affermare delle cose palesemente false a prescindere da esso.

RaouL_BennetH
16-10-2004, 13:18
Originariamente inviato da cdimauro
Ha già risposto nel thread che ho citato, ma che non sono riuscito a recuperare. Ed è stato letteralmente sbranato.
Comunque, sentiamo cos'altro avrà da dire eventialmente: magari la lezione gli sarà servita, e sarà rinsavito nel frattempo... ;)

Dai, fai uno sforzo, spremi le search al massimo!! sarei curioso di leggere quel thread che dici.

Poi, un'altra piccola cosa ma che secondo me non è ininfluente:

Dire che: se si sviluppa un kernel qualsiasi in c++ può funzionare meglio, essere più efficiente etc.., ha un senso solo ipotetico, perchè credo che anche le grosse case si facciano e pongano certe domande, ma, almeno fino ad oggi, è evidente che nessuno abbia percorso questa strada (salvo l'esempio citato prima da fek). Mi chiedo quale possa essere il motivo :confused: . Cioè, se tu, come fek e come qualcun altro, dite che questa cosa sia possibile e fattibile, credo che non siate gli unici a pensarlo ma sicuramente ci saranno altre persone che la pensano come voi. Ora, un conto però è il concetto ed il pensiero, un conto invece è mettersi a scrivere un kernel da soli e vederne e testarne il risultato. Cioè, e mi perdonerete la carenza di "tecnicità" nell'esporre qualche pensiero, se io conosco a fondo un linguaggio, ma con quel linguaggio non ho mai scritto un kernel, chi mi può dire che, facendolo, il risultato possa essere migliore? e mi rispondo: non può dirmelo nessuno finchè non lo faccio.

Oltre questo poi, una piccola lamentela concedetemela:

Mi scuserete e mi scuso in anticipo se questa cosa può sembrare un'offesa (ma non lo è) se anche voi non fornite esempi concreti e reali di cose che funzionano meglio perchè fatte in un certo modo, alla fine, si rischia che nonostante tutto sempre di punti di vista si tratta. Prima qualcuno già aveva fatto la provocazione del tipo: allora se in c++ si può fare un kernel migliore, perchè non lo fate?

E imho la risposta non può essere perchè "un lavoro già lo ho" oppure non mi interessa, perchè non posso credere che oltre a fek, al mondo non esista un altro programmatore in grado di pensare di fare un kernel in c++, è palesemente impossibile questa cosa. E quindi, di nuovo mi chiedo: se tante persone si mangiano linus a colazione reputandolo un ignorante, un lamer o qualsiasi altro epiteto possibile, perchè invece di insultarlo non gli dimostrano a suon di codice che ha torto?

repne scasb
16-10-2004, 13:35

RaouL_BennetH
16-10-2004, 13:35
in rete ho trovato questa risposta, ma non so di chi sia:

"My personal view is that C++ has its merits, and makes object-oriented programming easier. However, it is a more complex language and is less mature than C. The greatest danger with C++ is in fact its power. It seduces the programmer, making it much easier to write bloatware. The kernel is a critical piece of code, and must be lean and fast. We cannot afford bloat. I think it is fair to say that it takes more skill to write efficient C++ code than C code. Not every contributer to the linux kernel is an uber-guru, and thus will not know the various tricks and traps for producing efficient C++ code."

RaouL_BennetH
16-10-2004, 13:40
Originariamente inviato da repne scasb
Dovresti definire esattamente cosa intendi per efficienza, altrimenti la mia risposta potrebbe avere poco senso.
Personalmente computo 11 modelli generali d'efficienza, per esemplificare riporto almeno le due distinzioni sommarie principali:

1) Efficienza assoluta. E' pari alla quantita' P/Rl dove con P si identificano le prestazioni assolute, e con Rl le "risorse locali".
2) Efficienza complessiva. E' pari alla quantita' P/Rg dove con P si identificano le prestazioni assolute, e con Rg le "risorse globali".

Per "prestazioni assolute" intendo a parita di scopo e di mezzo il tempo necessario per risolvere un problema (minore e' il tempo piu' alte sono le prestazioni assolute).
Per "mezzo" intendo l'hardware su cui sviluppo (CPU, RAM, MMU.....).
Per "scopo" intendo il raggiungimento della soluzione al problema che mi sono posta.
Le "risorse locali" dipendono esclusivamente dal mezzo (RAM occupata, modalita' d'accesso, uso ottimale della CPU....)
Le "risolse globali" dipendono dalle "risorse locali" piu' le "risorse collaterali" che sono state necessarie per raggiungere lo scopo.
Le "risorse collaterali" dipendono dal tempo, dal personale, dal denaro, da esigenze specifiche insite nel raggiungimento dello scopo.

In definitiva, l'efficienza assoluta dipende solo dallo scopo e dal mezzo, l'efficienza complesiva dipende dallo scopo, dal mezzo e dal "modo" in cui interagiamo con scopo e mezzo (e' interessante notare la natura non lineare dell'efficienza complessiva).

Si vuol far notare che in termini di prestazioni assolute un'alta efficienza complessiva non e' necessariamente sinonimo di alte prestazioni assolute.

(NOTA: Mi scuso per la "rozzezza" del modello ma non vorrei scrivere un papiro, spero che il modello si esemplificante rispetto al quesito porposto da fek).

In temini di efficienza complessiva il C++ (a mio giudizio) non ammette deroghe. E' in effetti quanto di "migliore" (dal punto di vista dell'efficienza complessiva) si possa avere.

-----------------------------------------------------------------------------------

Da cio' dovremmo dedurre che ilsensine o chi sviluppa il kernel di Linux sia un sprovveduto che sta errando clamorosamente: a mio giudizio non mi sembra.
Credo che il modello di sviluppo di Linux sia basato su un modello d'efficienza assoluta che prediliga le prestazioni assolute al posto di prediligere le risore collaterali.
Da cio' si evincerebbe che la prestazione assoluta di un codice c e' maggiore della prestazione assoluta di un codice "analogo" in C++.

E qui ritorniamo al quesito di fek: A mio modo di vedere non esiste alcun problema che in c abbia nella risoluzione, un'efficienza complessiva maggiore di un analogo software in c++ (semmai e' il contrario), a mio modo di vedere "in generale" il c ha un'efficienza assoluta maggiore del c++.

Una dimostrazione esautiva di cio' che ho appena detto, credo non sia facilmente realizzabile, ma poiche' fek non ha chiarito il suo concetto d'efficienza ed in piu' chiede almeno un "problema", ecco una possibile soluzione:

Il sistema di controlli di un "citofono", per esempio, non e' dissimile da un "piccolo" kernel (alcune volte e' diviso persino in layer fisici).
Riporto qui in questa sede il codice assembly per 80186 generato dal compilatore EPSD sia per linguaggio c che per linguaggio c++, per una richiesta da kernel di mappaggio e lettura di un registro MMIO:

Trasformazione codice c da parte del compilatore EPSD:


push bp
mov bp,sp
mov ax,[_memphyhiR]
push ax
mov ax,[bp+4h]
push ax
call _memphymapR
add sp,4h
pop bp
ret


Trasformazione codice c++ da parte del compilatore EPSD:


push bp
mov bp,sp
push 0040
mov ax,[bp+4h]
push ax
call ios::memphyhiR
add sp,4h
push ax
mov ax,[bp+4h]
push ax
call _memphymapR
add bp,4h
pop bp
ret


Cosa si evince da questo unico esempio:

E' visibile nel secondo codice un overhead generato dal compilatore c++ (sia in temini di stack, memoria occupata e prestazioni). Perche' accade questo? Perche' il compilatore sembra mostrare di richiedere piu' risorse rispetto ad un analogo codice in c?

Vi sono varie motivazioni, ma la piu' plausibile e sostenibile e' che una generica CPU (in questo caso un intel 80186), non "comprende" cosa sia la programmazione per oggetti. Una CPU non sa cosa sia la programmazione strutturata. Una CPU in generale esegue del codice analogamente a come un Commodore64 esegue un programma in BASIC.
Da scrittrice di compilatori ho piu' volte ribadito in varie sedi che: ogni volta che si introduce in un linguaggi di alto livello (non linguaggi token da ML), una "sovrastruttura" (sarebbe da chiarire) non elementarmente esprimibile in un linguaggio CPU token (assembly, ML, mCod), si introduce un "layer" che deve "essere" tradotto dal compilatore, e questa traduzione costa sia in termini di prestazioni assolute sia in termini di risorse locali.
Da cio' si evince "FACILMENTE" perche' programmare in assembly ha la maggiore efficienza assoluta possibile e la minore efficienza complessiva possibile.

Tutto cio' mi permette di comprendere perche' il kernel di Linux e' scritto in C, ma anche perche' il kernel di Beos e' scritto in C++ (non lo sapevo), e ritenere entrambi le soluzioni come valide e non escludenti l'un l'altra.

(Nota a margine: l'overhead "tipico" del c++ puo' essere "notevolmente" minimizzato con un oculata ed attenta programmazione (tranne in casi speciali (la funzione di Read_MMIO analizzata piu' in alto chiamata 1 milione di volte)), ed in generale il c++ rimane l'ideale se dobbiamo raggiungere un certo risultato in un certo tempo (a mio avviso).


:eek: non ho capito niente ma concordo !!! :D :D

Scherzi a parte qualcuno richiedeva il tuo intervento, come sempre scientifico e perfetto :)

Ikitt_Claw
16-10-2004, 13:47
Originariamente inviato da cdimauro
Motivazione smentite. E fek si riferiva anche a Linux.
Le motivazioni principali a me note sono:
1) g++ nel 1994 faceva onco.
2) la maggior parte dei kernel hacker se la cavava benone in C mentre in C++ ripartiva da zero.
Quelli enunciati da ilsensine sono corollari a quanto sopra.
Sempre a quanto mi risulta, beninteso.

Mi sembra che nessuno le abbia smentite, e che siano motivi piu` che sufficienti per giustificare lo stato di cose.

Il problema è che quell'affermazione l'ha ripetuta di recente... E comunque, ripeto: ha scelto il modo sbagliato per esprimere le sue opinioni...
Di certo qui nel forum noi non possiamo insegnare granche` da questo punto di vista, la fiammata facile c'e` per tutti :D

Ikitt_Claw
16-10-2004, 13:49
Originariamente inviato da DioBrando
Ma quando 10 anni fà i mezzi non erano quelli attuali ( io cmq mi ricordavo che Linux fosse datato 91-92 :D) non gli si può dar torto di quella scelta.

Torvalds inizia a scrivere Linux nel 1991, e la release 0.0.1 e` all'incirca di quel periodo. La versione 0.99/1.0, attorno alla quale si parlava di una riscrittura in C++, e` all'incirca del 1994.

DioBrando
16-10-2004, 13:55
Originariamente inviato da Ikitt_Claw
Torvalds inizia a scrivere Linux nel 1991, e la release 0.0.1 e` all'incirca di quel periodo. La versione 0.99/1.0, attorno alla quale si parlava di una riscrittura in C++, e` all'incirca del 1994.

ahhh k io mi riferivo alla nascita del progetto mentre giustamente fate partire il tutto dalla prima final.

Thx per la precisazione :)

Ikitt_Claw
16-10-2004, 13:56
Originariamente inviato da cdimauro
Quindi per te il problema si pone esclusivamente per un s.o. open source: dovrebbe per forza di cose accettare esclusivamente driver open source...
No.
Puo` accettare anche closed source o quel che si vuole, ma e` piu` naturale uno schema open-source. E` un'"espressione idiomatica", e` (dovrebbe essere) quello che e` naturale fare. O almeno io ho quest'impressione.
Cosi` come si programmano applicazioni GUI o pesantemente interagenti con interruzioni verrebbe piu` naturale (almeno a me) programmare usando un modello event-driven, cosi` in un macrokernel open source mi verrebbe naturale pensare che anche i device driver dovrebbero essere open source.
Ovviamente funziona anche con driver closed source, ma complica le cose.

Dipende dai punti di vista: generalmente quando si studiano i s.o. nella "cipolla" il kernel sta al centro, nello strato successivo ci sono i driver. Quindi sono separati: d'altra parte hanno funzioni diverse.

Gia`, ma generalmente in un macrokernel (e questo e` Linux), i device driver )il codice che interagisce col ferro) se ne sta in kernel-space ;)
In linux i device driver fan parte del kernel, c'e` poco da sindacare. :)

cdimauro
16-10-2004, 21:01
Originariamente inviato da RaouL_BennetH
Dai, fai uno sforzo, spremi le search al massimo!! sarei curioso di leggere quel thread che dici.
Ho già perso anche troppo tempo: quando i server di HWUpgrade si sposteranno sulla nuove macchine, sarà riabilitata la ricerca su tutta la base messaggi. Non vedo l'ora!
Dire che: se si sviluppa un kernel qualsiasi in c++ può funzionare meglio, essere più efficiente etc.., ha un senso solo ipotetico, perchè credo che anche le grosse case si facciano e pongano certe domande, ma, almeno fino ad oggi, è evidente che nessuno abbia percorso questa strada (salvo l'esempio citato prima da fek).
E già questo non ti basta, scusa? Non è una prova valida?
Mi chiedo quale possa essere il motivo :confused: . Cioè, se tu, come fek e come qualcun altro, dite che questa cosa sia possibile e fattibile, credo che non siate gli unici a pensarlo ma sicuramente ci saranno altre persone che la pensano come voi. Ora, un conto però è il concetto ed il pensiero, un conto invece è mettersi a scrivere un kernel da soli e vederne e testarne il risultato.
Non ti basta il fatto che fek abbia contribuito allo sviluppo di OpenBeOS, che è scritto in C++?
Cioè, e mi perdonerete la carenza di "tecnicità" nell'esporre qualche pensiero, se io conosco a fondo un linguaggio, ma con quel linguaggio non ho mai scritto un kernel, chi mi può dire che, facendolo, il risultato possa essere migliore? e mi rispondo: non può dirmelo nessuno finchè non lo faccio.
Intanto se conosci veramente il linguaggio parti col piede giusto. Poi, in base ai problemi che incontri, scegli in che modo utilizzarlo, e quali sue caratteristiche ti permettono di risolverli nel migliore dei modi.
Oltre questo poi, una piccola lamentela concedetemela:

Mi scuserete e mi scuso in anticipo se questa cosa può sembrare un'offesa (ma non lo è) se anche voi non fornite esempi concreti e reali di cose che funzionano meglio perchè fatte in un certo modo, alla fine, si rischia che nonostante tutto sempre di punti di vista si tratta.
Veramente fek ha già ampiamente esposto degli esempi perfettamente tangibili.
Prima qualcuno già aveva fatto la provocazione del tipo: allora se in c++ si può fare un kernel migliore, perchè non lo fate?
Innazitutto ti faccio notare che argomentazione è debole.
Poi, ripeto: fek ha lavorato allo sviluppo di OpenBeOS.
Infine, sarà che magari che non c'interessa o abbiamo altro a cui pensare?
Tutto ciò nulla toglie a quanto è già stato scritto.
E imho la risposta non può essere perchè "un lavoro già lo ho" oppure non mi interessa,
E perché no? Nella mia vita faccio quel che devo (lavorare), e il resto del tempo decido io in che modo spenderlo, no?
perchè non posso credere che oltre a fek, al mondo non esista un altro programmatore in grado di pensare di fare un kernel in c++, è palesemente impossibile questa cosa.
Di fatti c'è gente che sviluppa kernel anche in Object Pascal... ;)
Non è questo il punto: il nocciolo (kernel :D) è che possibile scriverlo in C++, e offre dei vantaggi rispetto al C.
E quindi, di nuovo mi chiedo: se tante persone si mangiano linus a colazione reputandolo un ignorante, un lamer o qualsiasi altro epiteto possibile,
Io le persone le giudico dai fatti: se sparano cazzate, chiunque esso sia, mi permetto di criticarlo.
perchè invece di insultarlo non gli dimostrano a suon di codice che ha torto?
Da quando in qua per dimostrare qualcosa è necessario tirare fuori del codice? Le argomentazioni esposte sono più che valide, e già bastano: il codice è un surplus non necessario, per lo meno in questo caso.

eraser
16-10-2004, 21:05
Originariamente inviato da repne scasb
Dovresti definire esattamente cosa intendi per efficienza, altrimenti la mia risposta potrebbe avere poco senso.
Personalmente computo 11 modelli generali d'efficienza, per esemplificare riporto almeno le due distinzioni sommarie principali:

1) Efficienza assoluta. E' pari alla quantita' P/Rl dove con P si identificano le prestazioni assolute, e con Rl le "risorse locali".
2) Efficienza complessiva. E' pari alla quantita' P/Rg dove con P si identificano le prestazioni assolute, e con Rg le "risorse globali".

Per "prestazioni assolute" intendo a parita di scopo e di mezzo il tempo necessario per risolvere un problema (minore e' il tempo piu' alte sono le prestazioni assolute).
Per "mezzo" intendo l'hardware su cui sviluppo (CPU, RAM, MMU.....).
Per "scopo" intendo il raggiungimento della soluzione al problema che mi sono posta.
Le "risorse locali" dipendono esclusivamente dal mezzo (RAM occupata, modalita' d'accesso, uso ottimale della CPU....)
Le "risolse globali" dipendono dalle "risorse locali" piu' le "risorse collaterali" che sono state necessarie per raggiungere lo scopo.
Le "risorse collaterali" dipendono dal tempo, dal personale, dal denaro, da esigenze specifiche insite nel raggiungimento dello scopo.

In definitiva, l'efficienza assoluta dipende solo dallo scopo e dal mezzo, l'efficienza complesiva dipende dallo scopo, dal mezzo e dal "modo" in cui interagiamo con scopo e mezzo (e' interessante notare la natura non lineare dell'efficienza complessiva).

Si vuol far notare che in termini di prestazioni assolute un'alta efficienza complessiva non e' necessariamente sinonimo di alte prestazioni assolute.

(NOTA: Mi scuso per la "rozzezza" del modello ma non vorrei scrivere un papiro, spero che il modello si esemplificante rispetto al quesito porposto da fek).

In temini di efficienza complessiva il C++ (a mio giudizio) non ammette deroghe. E' in effetti quanto di "migliore" (dal punto di vista dell'efficienza complessiva) si possa avere.

-----------------------------------------------------------------------------------

Da cio' dovremmo dedurre che ilsensine o chi sviluppa il kernel di Linux sia un sprovveduto che sta errando clamorosamente: a mio giudizio non mi sembra.
Credo che il modello di sviluppo di Linux sia basato su un modello d'efficienza assoluta che prediliga le prestazioni assolute al posto di prediligere le risore collaterali.
Da cio' si evincerebbe che la prestazione assoluta di un codice c e' maggiore della prestazione assoluta di un codice "analogo" in C++.

E qui ritorniamo al quesito di fek: A mio modo di vedere non esiste alcun problema che in c abbia nella risoluzione, un'efficienza complessiva maggiore di un analogo software in c++ (semmai e' il contrario), a mio modo di vedere "in generale" il c ha un'efficienza assoluta maggiore del c++.

Una dimostrazione esautiva di cio' che ho appena detto, credo non sia facilmente realizzabile, ma poiche' fek non ha chiarito il suo concetto d'efficienza ed in piu' chiede almeno un "problema", ecco una possibile soluzione:

Il sistema di controlli di un "citofono", per esempio, non e' dissimile da un "piccolo" kernel (alcune volte e' diviso persino in layer fisici).
Riporto qui in questa sede il codice assembly per 80186 generato dal compilatore EPSD sia per linguaggio c che per linguaggio c++, per una richiesta da kernel di mappaggio e lettura di un registro MMIO:

Trasformazione codice c da parte del compilatore EPSD:


push bp
mov bp,sp
mov ax,[_memphyhiR]
push ax
mov ax,[bp+4h]
push ax
call _memphymapR
add sp,4h
pop bp
ret


Trasformazione codice c++ da parte del compilatore EPSD:


push bp
mov bp,sp
push 0040
mov ax,[bp+4h]
push ax
call ios::memphyhiR
add sp,4h
push ax
mov ax,[bp+4h]
push ax
call _memphymapR
add bp,4h
pop bp
ret


Cosa si evince da questo unico esempio:

E' visibile nel secondo codice un overhead generato dal compilatore c++ (sia in temini di stack, memoria occupata e prestazioni). Perche' accade questo? Perche' il compilatore sembra mostrare di richiedere piu' risorse rispetto ad un analogo codice in c?

Vi sono varie motivazioni, ma la piu' plausibile e sostenibile e' che una generica CPU (in questo caso un intel 80186), non "comprende" cosa sia la programmazione per oggetti. Una CPU non sa cosa sia la programmazione strutturata. Una CPU in generale esegue del codice analogamente a come un Commodore64 esegue un programma in BASIC.
Da scrittrice di compilatori ho piu' volte ribadito in varie sedi che: ogni volta che si introduce in un linguaggi di alto livello (non linguaggi token da ML), una "sovrastruttura" (sarebbe da chiarire) non elementarmente esprimibile in un linguaggio CPU token (assembly, ML, mCod), si introduce un "layer" che deve "essere" tradotto dal compilatore, e questa traduzione costa sia in termini di prestazioni assolute sia in termini di risorse locali.
Da cio' si evince "FACILMENTE" perche' programmare in assembly ha la maggiore efficienza assoluta possibile e la minore efficienza complessiva possibile.

Tutto cio' mi permette di comprendere perche' il kernel di Linux e' scritto in C, ma anche perche' il kernel di Beos e' scritto in C++ (non lo sapevo), e ritenere entrambi le soluzioni come valide e non escludenti l'un l'altra.

(Nota a margine: l'overhead "tipico" del c++ puo' essere "notevolmente" minimizzato con un oculata ed attenta programmazione (tranne in casi speciali (la funzione di Read_MMIO analizzata piu' in alto chiamata 1 milione di volte)), ed in generale il c++ rimane l'ideale se dobbiamo raggiungere un certo risultato in un certo tempo (a mio avviso).

un applauso....precisa e tecnica come sempre ;) :)

RaouL_BennetH
16-10-2004, 21:14
Originariamente inviato da cdimauro

E già questo non ti basta, scusa? Non è una prova valida?


No, perchè sono soltanto pensieri e chiacchiere, mentre invece, avrai sicuramente letto l'esempio "matematico" di repne scasb, quello si che è rispondere in maniera tecnica.


Non ti basta il fatto che fek abbia contribuito allo sviluppo di OpenBeOS, che è scritto in C++?

Sono contento per fek, e mi auguro che continui e vada avanti, ma gli altri??


Intanto se conosci veramente il linguaggio parti col piede giusto. Poi, in base ai problemi che incontri, scegli in che modo utilizzarlo, e quali sue caratteristiche ti permettono di risolverli nel migliore dei modi.

anche qui, sono sempre e solo parole, che non bastano secondo come argomentazioni, ma ci vogliono esempi alla repne scasb (e due).


Veramente fek ha già ampiamente esposto degli esempi perfettamente tangibili.

appunto, sempre fek e sono sempre contento, ma non è che quello che dice fek, con tutto il rispetto, è legge. Intendo che come esempi da una parte e dall'altra, dovreste postare un pò di codice e provare e confrontare i risultati. Es. : in C faccio questa cosa, in C++ faccio la stessa cosa e poi si confrontano i risultati.


Infine, sarà che magari che non c'interessa o abbiamo altro a cui pensare?

Appunto, credo che siamo in tanti ad essere curiosi di sapere a quali progetti lavorate, perchè, e non fraintendermi, spesso da come tu quoti i messaggi degli altri, lasci intendere che tutti brancoliamo nel buio. Perchè non ci fai un esempio di un progetto o di un qualsiasi sft, kernel, driver, grafica, da te fatto? (semprechè non intacchi il riservo professionale beninteso).



E perché no? Nella mia vita faccio quel che devo (lavorare), e il resto del tempo decido io in che modo spenderlo, no?

certo.


Di fatti c'è gente che sviluppa kernel anche in Object Pascal... ;)
Non è questo il punto: il nocciolo (kernel :D) è che possibile scriverlo in C++, e offre dei vantaggi rispetto al C.


Mi elencheresti tu in dettaglio quali sono?


Io le persone le giudico dai fatti: se sparano cazzate, chiunque esso sia, mi permetto di criticarlo.

una critica è una cosa, ma dare del lamer ad uno del livello di linus, mi sembra comunque un'esagerazione.


Da quando in qua per dimostrare qualcosa è necessario tirare fuori del codice? Le argomentazioni esposte sono più che valide, e già bastano: il codice è un surplus non necessario, per lo meno in questo caso.

Forse perchè si parla di programmazione dove magari la validità di un codice vale più di tante parole?

cdimauro
16-10-2004, 21:25
Originariamente inviato da repne scasb
Da cio' dovremmo dedurre che ilsensine o chi sviluppa il kernel di Linux sia un sprovveduto che sta errando clamorosamente: a mio giudizio non mi sembra.
Credo che il modello di sviluppo di Linux sia basato su un modello d'efficienza assoluta che prediliga le prestazioni assolute al posto di prediligere le risore collaterali.
Da cio' si evincerebbe che la prestazione assoluta di un codice c e' maggiore della prestazione assoluta di un codice "analogo" in C++.
Non sono d'accordo. La differenza fra i due linguaggi la possono fare i cattivi programmatori (che li usano impropriamente) e i cattivi compilatori (che non ottimizzano il codice correttamente).
E qui ritorniamo al quesito di fek: A mio modo di vedere non esiste alcun problema che in c abbia nella risoluzione, un'efficienza complessiva maggiore di un analogo software in c++ (semmai e' il contrario), a mio modo di vedere "in generale" il c ha un'efficienza assoluta maggiore del c++.
Vedi sopra: nel caso peggiore si potrebbe usare il compilatore C++ dandogli in pasto puro codice C. Se il compilatore genera in output un codice diverso da quel che farebbe un compilatore C, le cause non vanno certo ricercate nel linguaggio.
Una dimostrazione esautiva di cio' che ho appena detto, credo non sia facilmente realizzabile, ma poiche' fek non ha chiarito il suo concetto d'efficienza ed in piu' chiede almeno un "problema", ecco una possibile soluzione:
Da quanto ho scritto sopra penso è banale la dimostrazione che il C++ risulta efficiente almeno quanto il C.
Il sistema di controlli di un "citofono", per esempio, non e' dissimile da un "piccolo" kernel (alcune volte e' diviso persino in layer fisici).
Riporto qui in questa sede il codice assembly per 80186 generato dal compilatore EPSD sia per linguaggio c che per linguaggio c++, per una richiesta da kernel di mappaggio e lettura di un registro MMIO:
Debbo supporre che il sorgente compilato sia identico.
Vi sono varie motivazioni, ma la piu' plausibile e sostenibile e' che una generica CPU (in questo caso un intel 80186), non "comprende" cosa sia la programmazione per oggetti. Una CPU non sa cosa sia la programmazione strutturata. Una CPU in generale esegue del codice analogamente a come un Commodore64 esegue un programma in BASIC.
Da scrittrice di compilatori ho piu' volte ribadito in varie sedi che: ogni volta che si introduce in un linguaggi di alto livello (non linguaggi token da ML), una "sovrastruttura" (sarebbe da chiarire) non elementarmente esprimibile in un linguaggio CPU token (assembly, ML, mCod), si introduce un "layer" che deve "essere" tradotto dal compilatore, e questa traduzione costa sia in termini di prestazioni assolute sia in termini di risorse locali.
Da cio' si evince "FACILMENTE" perche' programmare in assembly ha la maggiore efficienza assoluta possibile e la minore efficienza complessiva possibile.
Non sono d'accordo. Le prime versioni del compilatore C++ sviluppato nei laboratori Bell di AT&T dallo staff di Stroustrup altri non era che un preprocessore che generava codice C: se non venivano usate caratteristiche proprie del C++, non veniva generato alcun codice aggiuntivo.
Comunque è sempre compito del compilatore analizzare il sorgente, individuare le risorse/caratteristiche realmente utilizzate, e generare in output un eseguibile "ottimizzato".
Ad esempio, se scrivo:
x = x + 1;
x += 1;
x++;
++x;
mi aspetto che il compilatore generi in output sempre il medesimo eseguibile, perché non esistono differenze sostanziali, se non dal punto di vista meramente sintattico.
Allo stesso modo, se utilizzo // per i commenti, operator o function overloading, funzioni inline anziché macro, o utilizzo classi allocate staticamente e senza metodi virtuali, mi aspetto che l'output generato sia efficiente almeno tanto quando un equivalente codice C, perché non esiste alcun motivo per trattare diversamente questi costrutti sintattici.
Per le cose più complicate mi aspetto che il compilatore faccia un ottimo lavoro, specialmente avendo a che fare con classi allocate dinamicamente e con metodi virtuali.
Tutto cio' mi permette di comprendere perche' il kernel di Linux e' scritto in C, ma anche perche' il kernel di Beos e' scritto in C++ (non lo sapevo), e ritenere entrambi le soluzioni come valide e non escludenti l'un l'altra.
Per me l'unico motivo per cui si continua a usare il C per Linux, è che richiederebbe troppo tempo il suo "porting" verso il C++, e troppa gente ne verrebbe tagliata fuori. Per il resto penso che esistano soltanto dei benefici nel suo utilizzo. Al più le persone meno capaci lo potrebbero utilizzare come farebbero col C, imparando magari a sfruttare le agevolazioni più semplici e che possono essere recepite velocemente.
(Nota a margine: l'overhead "tipico" del c++ puo' essere "notevolmente" minimizzato con un oculata ed attenta programmazione (tranne in casi speciali (la funzione di Read_MMIO analizzata piu' in alto chiamata 1 milione di volte)),
Per me è colpa del compilatore.
ed in generale il c++ rimane l'ideale se dobbiamo raggiungere un certo risultato in un certo tempo (a mio avviso).
Quoto. E' un linguaggio che bisogna imparare bene a padroneggiare. Come per tutto, del resto... ;)

cdimauro
16-10-2004, 21:30
Originariamente inviato da RaouL_BennetH
in rete ho trovato questa risposta, ma non so di chi sia:

"My personal view is that C++ has its merits, and makes object-oriented programming easier. However, it is a more complex language and is less mature than C.
Non sono d'accordo: è un linguaggio che ha raggiunto la sua maturità da un pezzo.
The greatest danger with C++ is in fact its power. It seduces the programmer, making it much easier to write bloatware.
Questa mi sembra un'assurdità bella e buona: si scaricano sul linguaggio i problemi dovuti all'incapacità dei programmatori...
The kernel is a critical piece of code, and must be lean and fast. We cannot afford bloat.
D'accordo. Ma questo non c'entra nulla col linguaggio!
I think it is fair to say that it takes more skill to write efficient C++ code than C code.
Indubbiamente.
Not every contributer to the linux kernel is an uber-guru, and thus will not know the various tricks and traps for producing efficient C++ code."
"Colpa d'Alfredo, che coi suoi discorsi seri e inopportuni mi fa sciupare tutte le occasioni... Io primo poi lo uccido. Lo uccido..." :D

cdimauro
16-10-2004, 21:35
Originariamente inviato da Ikitt_Claw
Le motivazioni principali a me note sono:
1) g++ nel 1994 faceva onco.
D'accordo.
2) la maggior parte dei kernel hacker se la cavava benone in C mentre in C++ ripartiva da zero.
Potevano cominciare a usarlo come C. E poi imparare ad apprezzarne le caratteristiche innovative.
Quelli enunciati da ilsensine sono corollari a quanto sopra.
Sempre a quanto mi risulta, beninteso.

Mi sembra che nessuno le abbia smentite, e che siano motivi piu` che sufficienti per giustificare lo stato di cose.
Se restringiamo effettivamente il tutto a questi due punti che hai elencato, sono d'accordo anch'io, e possiamo anche chiudere qui la discussione. ;)
Di certo qui nel forum noi non possiamo insegnare granche` da questo punto di vista, la fiammata facile c'e` per tutti :D
Non posso che darti ragione. ;)

cdimauro
16-10-2004, 21:43
Originariamente inviato da Ikitt_Claw
No.
Puo` accettare anche closed source o quel che si vuole, ma e` piu` naturale uno schema open-source. E` un'"espressione idiomatica", e` (dovrebbe essere) quello che e` naturale fare. O almeno io ho quest'impressione.
Cosi` come si programmano applicazioni GUI o pesantemente interagenti con interruzioni verrebbe piu` naturale (almeno a me) programmare usando un modello event-driven, cosi` in un macrokernel open source mi verrebbe naturale pensare che anche i device driver dovrebbero essere open source.
Ovviamente funziona anche con driver closed source, ma complica le cose.
Per me si tratta di due cose completamente diverse. Se devo scrivere un driver, a me interessano soltanto le specifiche del s.o. in merito: il fatto che sia open o closed source non ha alcuna rilevanza sul lavoro che sto facendo.
Gia`, ma generalmente in un macrokernel (e questo e` Linux), i device driver )il codice che interagisce col ferro) se ne sta in kernel-space ;)
Hai detto bene: generalmente. Ma c'è pure della gente che vorrebbe che stessero in user-space, per limitare al minimo eventuale danni.
In linux i device driver fan parte del kernel, c'e` poco da sindacare. :)
Se vogliamo mettere tutto in un calderone sì, ma ciò non toglie che nella "cipolla" stanno nel secondo strato. ;)
Se lavoro del kernel non me frega niente dei driver. Se lavoro sui driver non me ne frega niente del kernel. L'unica cosa che interessa in entrambi i casi sono le specifiche che "uniscono i due mondi".
D'altra parte la suddivisione del software in layer completamente separati, uniti solanto dalle specifiche d'interfacciamento, è una della metodologie più importanti dell'Ingegneria del Software e del Codice Scritto Bene.
Ma forse questo è un argomento tabù in questo contesto, visto i precedenti... :D

cdimauro
16-10-2004, 22:05
Originariamente inviato da RaouL_BennetH
No, perchè sono soltanto pensieri e chiacchiere, mentre invece, avrai sicuramente letto l'esempio "matematico" di repne scasb, quello si che è rispondere in maniera tecnica.
Pensieri e chiacchiere per te forse: a me sembrano delle vere e proprie dimostrazioni. Non saprei come classificare altrimenti uno degli ultimi messaggi di fek, in cui faceva il punto della situazione.
Comunque, leggiti il mio messaggio a repne scasb.
Sono contento per fek, e mi auguro che continui e vada avanti, ma gli altri??
Ne resterà soltanto uno (fek). :D
Gli altri si adeguano, o continuano per la loro strada: non vedo dove vuoi arrivare.
anche qui, sono sempre e solo parole, che non bastano secondo come argomentazioni, ma ci vogliono esempi alla repne scasb (e due).
Ma non eri tu quello che non capisce molto di programmazione & co.? Se non riesci a seguire il discorso, passa tu dalle parole ai fatti: fai esperienza in merito. Ma evita di dire agli altri, che di esperienza ne hanno da vendere, che dicono soltanto chiacchiere. :rolleyes:
appunto, sempre fek e sono sempre contento, ma non è che quello che dice fek, con tutto il rispetto, è legge.
E chi l'ha mai detto? Certamente se per un dato problema porta una dimostrazione (vedi i punti che ha elencato sulla discussione, ad esempio), ci sarà ben poco da dire.
Intendo che come esempi da una parte e dall'altra, dovreste postare un pò di codice e provare e confrontare i risultati. Es. : in C faccio questa cosa, in C++ faccio la stessa cosa e poi si confrontano i risultati.
Ripeto: da quando in qua per parlare di qualcosa bisogna per forza postare del codice? L'esempio di fek sui vettori è PIU' CHE CHIARO, e passare dalla parole al codice è soltanto un banale esercizio che NULLA toglie alla validità delle parole
Le parole, ti ricordo, sono le stesse che vengono utilizzate quando si scrive dello pseudo-codice, o si fa una dimostrazione formale. Anche a queste vorresti togliere la legittimazione che meritano, soltanto perché manca il codice? L'informatica non sarebbe certo arrivata ai livelli attuali seguendo il tuo ragionamento... :muro:
Appunto, credo che siamo in tanti ad essere curiosi di sapere a quali progetti lavorate, perchè, e non fraintendermi, spesso da come tu quoti i messaggi degli altri, lasci intendere che tutti brancoliamo nel buio.
Certo, e questo punto perché non lo tiriamo fuori e magari ce lo misuriamo? Perché altrimenti è ovvio che senza il "tocco papale" non si può avere la dimostrazione che siamo dei veri uomini...

Ma che ragionamenti sono, scusa? E scommetto che giudicheresti le capacità di una persona soltanto dal suo libretto universatario: poi poco importa se è incapace di scrivere un banalissimo programmino per suddividere un file in due parti (m'è successo con una mia collega universitaria).
:mc:
Perchè non ci fai un esempio di un progetto o di un qualsiasi sft, kernel, driver, grafica, da te fatto? (semprechè non intacchi il riservo professionale beninteso).
Vedi sopra. Preferisco non risponderti.
Mi elencheresti tu in dettaglio quali sono?
Rileggiti il thread: lo scoprirai da solo... :rolleyes:
una critica è una cosa, ma dare del lamer ad uno del livello di linus, mi sembra comunque un'esagerazione.
Se spara cazzate, il lamer lo do a chiunque: sia esso linus o il padreeterno. Io non giudico le persone dalla "nomina", ma dai fatti.
Forse perchè si parla di programmazione dove magari la validità di un codice vale più di tante parole?
Se me lo dimostri, lo faccio. :rolleyes:

Comunque ciò dimostra la tua assoluta inesperienza in materia di programmazione: se per te essere programmatori equivale a scrivere soltanto del codice, possiamo buttare fuori a calci in culo gente come Babbage, Turing, Goedel, ecc., che l'informatica l'ha fondata, e non ha scritto una sola riga di codice per dimostrare la maggior parte, se non tutte, delle loro idee/teoremi. :muro:

repne scasb
16-10-2004, 22:09

RaouL_BennetH
16-10-2004, 22:37
Originariamente inviato da cdimauro
Pensieri e chiacchiere per te forse: a me sembrano delle vere e proprie dimostrazioni. Non saprei come classificare altrimenti uno degli ultimi messaggi di fek, in cui faceva il punto della situazione.
Comunque, leggiti il mio messaggio a repne scasb.


il messaggio l'ho letto, e già assomiglia di più a quelle che io intendo come argomentazioni "tecniche", intendevo discorsi volti su questo piano praticamente.




Ne resterà soltanto uno (fek). :D
Gli altri si adeguano, o continuano per la loro strada: non vedo dove vuoi arrivare.

intendo che mi meraviglia il fatto che non ci siano in molti che lo fanno, oppure, se ci sono, non si fanno avanti, ne più ne meno.


Ma non eri tu quello che non capisce molto di programmazione & co.? Se non riesci a seguire il discorso, passa tu dalle parole ai fatti: fai esperienza in merito. Ma evita di dire agli altri, che di esperienza ne hanno da vendere, che dicono soltanto chiacchiere. :rolleyes:


proprio perchè io non sono un programmatore ma un semplice utente, credo di essere meno "coinvolto" da discorsi di "fedi informatiche o varie", e mi piacerebbe che i vostri discorsi mirino ad un piano più tecnico, a differenza invece di come potrei farlo io, mi spiace che tu non abbia colto questa cosa.


Ripeto: da quando in qua per parlare di qualcosa bisogna per forza postare del codice? L'esempio di fek sui vettori è PIU' CHE CHIARO, e passare dalla parole al codice è soltanto un banale esercizio che NULLA toglie alla validità delle parole

Ok, ho capito ma per esprimermi brutalmente allora dico:

Fek ha fatto l'esempio sui vettori, benissimo e, ancora una volta complimenti (senza nessuna forma di sarcasmo) ma:

Si usi il C++ per fare l'operazione X
Si usi il C per fare la stessa operazione
Si usi il Basic per fare la stessa operazione
Si usi Carta e Penna per fare la stessa operazione

Quale risulta la migliore per il contesto e lo scopo a cui deve servire?

E' questo che io intendo con il portare codice, esempi, e non "parole", così, chiunque, anche un normale utente come me, può fare la prova e verificare.


Le parole, ti ricordo, sono le stesse che vengono utilizzate quando si scrive dello pseudo-codice, o si fa una dimostrazione formale. Anche a queste vorresti togliere la legittimazione che meritano, soltanto perché manca il codice? L'informatica non sarebbe certo arrivata ai livelli attuali seguendo il tuo ragionamento... :muro:


qui il :muro: lo metto io adesso :D. Dato che la discussione stupenda che stavano facendo ilsensine e fek, è rivolta al mondo della programmazione, mi sembra più che logico che ognuno cerchi di motivare le parole che scrive con degli esempi in codice, possibile che sia tanto difficile da accettare? E' come se ad un raduno di matematici, il teorico di turno, comincia a spiegare la sua teoria, ne parla, ne parla e ne straparla, ma non fornisce nessun esempio, teorema, tabellina del due, tre, etc... Certo, le parole saranno legittime e ammirevoli, ma qualcuno si potrebbe chiedere: "Ma se tutto quel che dici è vero, perchè non lo dimostri?"



Certo, e questo punto perché non lo tiriamo fuori e magari ce lo misuriamo? Perché altrimenti è ovvio che senza il "tocco papale" non si può avere la dimostrazione che siamo dei veri uomini...
Ma che ragionamenti sono, scusa? E scommetto che giudicheresti le capacità di una persona soltanto dal suo libretto universatario: poi poco importa se è incapace di scrivere un banalissimo programmino per suddividere un file in due parti (m'è successo con una mia collega universitaria).
:mc:

Vedi sopra. Preferisco non risponderti.


Qui non capisco perchè ti infervori così tanto per una semplice richiesta motivata da una semplice curiosità. Comunque, fa niente.


Rileggiti il thread: lo scoprirai da solo... :rolleyes:


In media un 3d che mi interessa lo rileggo spesso, però, sinceramente avrei qualcos'altro da obiettarti, ma mi sembra che in qualche modo ti abbia offeso (anche se non capisco perchè), e ti sento come dire "un pò nervoso", quindi, rimando.


Se spara cazzate, il lamer lo do a chiunque: sia esso linus o il padreeterno. Io non giudico le persone dalla "nomina", ma dai fatti.


qui sono io che al momento non ti rispondo, perchè questa risposta tirerebbe fuori anche a me una fiammata non proprio garbata, perchè non è una risposta intelligente come da "cdimauro" ci si aspetterebbe.


Se me lo dimostri, lo faccio. :rolleyes:

Comunque ciò dimostra la tua assoluta inesperienza in materia di programmazione: se per te essere programmatori equivale a scrivere soltanto del codice, possiamo buttare fuori a calci in culo gente come Babbage, Turing, Goedel, ecc., che l'informatica l'ha fondata, e non ha scritto una sola riga di codice per dimostrare la maggior parte, se non tutte, delle loro idee/teoremi. :muro:


Io infatti non mi sono mai presentato come un esperto o come un programmatore, e questa tua risposta non la prendo neanche come un'offesa perchè semplicemente non mi tocca in niente.

Ho sintetizzato prima il perchè molte volte anche in altre sezioni, spesso su discorsi che potrebbero interessare anche un utente normale, si perdano o sembra che si perdano solo in direzioni di "fede" relativa al C o al C++ o linux o windows etc... che per me sono assolute str.....te (intese come argomenti da farne una guerra).

xeal
17-10-2004, 02:28
Originariamente inviato da repne scasb
Domanda sulle prestazioni assolute: Si supponga di avere un linguaggio di cui si stimi avere una prestazione assoluta di alto livello. Una volta compilato tale sorgente in tale llinguaggio ci si renda conto che a causa del compilatore il codice macchina generato non ha le prestazioni che ci aspettavamo. Possiamo ancora dire che il linguaggio che abbiamo compilato e' da prestazioni asolute?

Mi permetto di fare un piccolo appunto: credo che, affinchè il problema sia ben posto, bisognerebbe presupporre di avere a disposizione il miglior compilatore possibile per quel linguaggio (fissate le specifiche sulla sintassi, gli operatori, l'interfaccia delle funzioni di libreria e la loro relativa implementazione). Diversamente, ogni valutazione, specie in un confronto tra più linguaggi, risulterebbe parziale e relativa al preciso momento "storico" in cui viene effettuata e ai mezzi (compilatori) usati, poichè non si potrebbe stabilire se le minori performance prodotte dal codice compilato siano legate alle caratteristiche intrinseche del linguaggio oppure al grado di ottimizzazione del compilatore.

Di conseguenza, dal basso della mia poca esperienza/conoscenza in questo campo specifico, credo che, se vogliamo paragonare l'efficienza di due linguaggi, sia meglio considerarli come non connessi ai relativi compilatori, in modo da poter confrontare le caratteristiche di ciascuno e come meglio si adattino a determinati problemi (mi è parso di capire che l'oggetto della discussione tre fek e ilsensine fosse proprio questo). Ad esempio, credo che abbia più senso giudicare la scelta di implementare la visibilità di variabili e procedure in Pascal mediante uno stack, oppure i pro e i contro dell'uso di variabili globali o della ricorsione, e di conseguenza dei lingaggi che consentano tale uso, piuttosto che confrontare le prestazioni del codice compilato, a meno che non si riesca a trovare un criterio per rapportare il grado di ottimizzazione del codice prodotto da compilatori relativi a differenti linguaggi, in modo da pesare le prestazioni del codice prodotto e avere una qualche stima dei risultati ottenibili con il "compilatore ideale".

D'altra parte, nella scelta del linguaggio da utilizzare per una certa applicazione può essere importante anche valutare l'efficienza ottenibile con gli strumenti a disposizione, ovvero con il miglior compilatore disponibile (e non il migliore possibile), tuttavia, dato il livello mediamente buono ed equivalente dei compilatori attuali e la disponibilità di risorse, ciò potrebbe avere un senso per particolari sezioni di codice e/o applicazioni "critiche", nelle quali prevalga la necessità di prestazioni assolute contestualizzate al codice ottenibile (quindi, alla connessione tra il linguaggio e il compilatore). In tal caso, ad ogni modo, potrebbe essere preferibile l'intervento di un programmatore esperto dei linguaggi "token" per affinare il prodotto di un compilatore, e in tal caso la differenza tra le prestazioni assolute dei linguaggi connessi inciderebbe poco, se non in termini del tempo e della manutenzione necessaria, ma così passiamo a valutare le prestazioni complessive. Queste ultime ritengo che forniscano un metro di valutazione assoluto, in quanto un linguaggio di alto livello nasce proprio per ottenere una efficienza migliore sotto tutti i punti di vista (mi rendo conto che sto usando un'espressione poco felice sul piano del formalismo), mediando tra le varie esigenze, e quindi ha lo scopo di produrre codice che abbia la migliore efficienza complessiva, di conseguenza, per compiere una valutazione assoluta sulla validità di un linguaggio credo che sia opportuno prendere in considerazione le prestazioni complessive e quelle assolute in un contesto (in particolare per queste ultime) di non connessione tra il linguaggio e il compilatore, mentre per una valutazione contingente, legata ad ambiti particolari e ad esigenze prestazionali specifiche, si possa inserire nella valutazione anche la misura delle prestazioni assolute pesate sull'efficienza del compilatore.

Ad onor del vero, credo che, in questo caso specifico, un confronto tra compilatori si potrebbe tentare. Azzardo un'ipotesi, basandomi su due considerazioni:
1) C e C++ per certi versi sono molto simili, tanto che in origine il C++ veniva tradotto in C prima della compilazione, quindi un buon compilatore C++ dovrebbe produrre codice con un grado di ottimizzazione molto vicino a quello generato da un buon compilatore C;
2) si era partiti da osservazioni su di un kernel scritto in C ma con costrutti (oggetti) molto vicini alle strutture native del C++ (ragion per cui non credo che si possa attribuire la presunta o reale maggior efficienza assoluta del C alla minore astrazione).

Partendo da queste osservazioni e supponendo di disporre dei migliori compilatori (allo stato dell'arte) per ciascun linguaggio, si potrebbe "calibrare" un test partendo da un qualche algoritmo implementato sia in C, sia in C++. La versione basata sulle strutture del C si dovrebbe tradurre con entrambi i compilatori, in modo da confrontare le prestazioni assolute con dette strutture, quindi si dovrebbe ripetere l'operazione con l'implementazione propria del C++, previa una traduzione in C per consentire l'uso del compilatore relativo (e ad uso e consumo del solo compilatore C); una media pesata (in qualche modo) tra i due raffronti potrebbe dare una misura dello scarto relativo all'efficienza dei relativi compilatori, e di conseguenza anche delle potenzialità dei due linguaggi. Quindi, si potrebbe risolvere un problema (possibilmente diverso da quello usato per calibrare il test) e implementare l'algoritmo relativo con le strutture [/i]più idonee[/i] per ciascun linguaggio, per confrontare il codice prodotto in termini di prestazioni assolute (e di efficienza assoluta) in riferimento allo "scarto" tra i compilatori. Sarebbe comunque un confronto poco preciso e relativo al problema in esame, ma darebbe pur sempre qualche indicazione per rispondere alle domande che hai posto ("Possiamo ancora dire che il linguaggio che abbiamo compilato e' da prestazioni asolute? Come misuriamo le prestazioni assolute di un linguaggio se non con la velocita' del codice macchina che produce un compilatore. Ancora. Se il compilatore nonostante si pensi che il linguaggio sia da prestazioni assolute generi codice non da prestazioni assolute, possiamo sostenere che sono degli incapaci i signori che producono il compilatore?").

In particolare, senza una qualche valutazione sull'efficienza del compilatore (intesa come capacità di produrre codice veloce e poco "famelico" di risorse locali) non credo che si possano stimare le potenzialità di un linguaggio in relazione al codice macchina prodotto in seguito alla compilazione, ne si possa valutare se la differenza tra le previsioni e il risultato siano da attribuirsi a imperizia (o necessità di ulteriore lavoro) da parte dei "signori" che hanno prodotto il compilatore, oppure a limiti intrinseci al linguaggio e alla sua astrazione dalle strutture "naturali" per la macchina, specialmente laddove lo si voglia confrontare con un linguaggio di per sè meno astratto (se non sbaglio il C è stato definito come il linguaggio di più basso livello tra i linguaggi di alto livello) ma usato in modo da costruire strutture simili (ovvero le stesse strutture diversamente implementate).

Detto questo, torno a ripetere che non ho sufficienti competenze in merito a questioni come queste, quindi non pretendo certo di avere ragione, anzi, son ben conscio della possibilità di averne sparata qualcuna (o di non averne azzeccata nessuna) :p

cdimauro
17-10-2004, 05:59
Originariamente inviato da repne scasb
Non posso dire ne di essere in accordo ne di essere in disaccordo con te. Devi definire cosa intendi per efficienza, altrimenti non e' possibile continuare a interloquire. "In funzione di come definisci l'efficienza e' "DIVERSA" l'enucleazione del problema".
Definiamo le prestazioni assolute come efficienza: d'altra parte è proprio di questo che si parlava, no?
A ciò mi permetto di aggiungere che il C++ permette di scrivere del codice che è più leggibile e mantenibile secondo i canoni dell'ingegneria del software, senza per questo andare a intaccare l'efficienza (vedi, ad esempio, l'uso dell'overloading).
Nonostante cio' (devi definire la "TUA" efficienza), posso inoltrarmi comunque in un necessario preambolo:

Punto 1) Compatibilita' a ritroso nell'evoluzione dei linguaggi di programmazione:

"Se scrivi un codice in C e lo salvi con il nome "PROVA.CPP" e quindi prendi il tuo compilatore C++ e lo compili in che linguaggio hai scritto il sorgente?"

"In un sorgente in C posso immettere del codice ASM in-line (estensione alla retrocompatibilita' con linguaggio di basso livello). Supponi di fare un intero software C con tutto codice ASM in-line, e' ancora C quello che ho scritto?"
Sì se il linguaggio lo permette, ma a questo punto togliamo pure di mezzo il linguaggio e passiamo a lavorare direttamente in assembly, no? D'altra parte anche Pascal, Basic, ecc. mi permettono di scrivere codice assembly in linea.
Mettiamo da parte l'assembly e concentriamoci sulle caratteristiche proprie del linguaggio, senza ricorrere a un altro linguaggio "accessorio".
Punto 2) Connessione linguaggio-compilatore:

E' possibile dialogare in diversi spazi delle fasi nel sistema linguaggio di programmazione:compilatore. a) Il linguaggio e il compilatore sono connessi. b) Il linguaggio e il compilatore sono disconnessi. Il sistema b) implica che il codice non verra' mai compilato, ed il linguaggio e' pensato "solo" per la risoluzione "teorica" di problemi (per esempio) inesprimibili in altri linguaggi. Nel caso a) Il linguaggio "esiste" come compilato ed esiste come codice "macchina" per l'esecuzione su una CPU.
Chiaramente opto per il punto a).
Domanda sulle prestazioni assolute: Si supponga di avere un linguaggio di cui si stimi avere una prestazione assoluta di alto livello. Una volta compilato tale sorgente in tale llinguaggio ci si renda conto che a causa del compilatore il codice macchina generato non ha le prestazioni che ci aspettavamo. Possiamo ancora dire che il linguaggio che abbiamo compilato e' da prestazioni asolute? Come misuriamo le prestazioni assolute di un linguaggio se non con la velocita' del codice macchina che produce un compilatore. Ancora. Se il compilatore nonostante si pensi che il linguaggio sia da prestazioni assolute generi codice non da prestazioni assolute, possiamo sostenere che sono degli incapaci i signori che producono il compilatore?
Sì. T'è mai capitato di ottenere risultati diversi in base a come scrivi il codice? Se per calcolare il massimo fra due numeri, utilizzo questo codice:

if (a > b)
max = a;
else
max = b;

o questo:

max = a > b ? a : b;

e il compilatore si comporta diversamente, allora c'è qualcosa che non va. A me è successo con un compilatore per VLIW LX, che utilizzava le istruzioni MAX (e MIN) esclusivamente nella seconda forma.
L'errore è chiaramente di chi ha scritto il compilatore.
Nota: E' chiaro che: se mi parli di efficienza complessiva, e di sconnessione tra linguaggio e compilatore, sono certamente d'accordo con te. Ossia nello spazio delle fasi efficienza-risorse-connessione "TU" dove ti collochi? Se non so dove stai non posso ne essere in accordo ne in disaccordo con te.
T'ho risposto sopra: la teoria senza pratica serve a ben poco. Ciò non toglie che nella pratica si possa sbagliare, ma questo non deve permettere di dare dei giudizi affrettati.

Per il resto, anche procedendo come esposto da xeal, di cui condivido lo spirito, rimango sempre dell'idea che gli errori di chi scrive un compilatore non possano ricadere sul linguaggio...

cdimauro
17-10-2004, 06:50
Che dire: un mostro! Valentino Rossi campione del mondo MotoGP, dopo una gara al cardiopalma: rimarrà nella storia... :winner:

Avevo dimenticato di questione aperta: al punto a) e b) dovremmo aggiungere un punto c). Cosa ne pensi del fatto che un compilatore C++ produca codice C?

Ikitt_Claw
17-10-2004, 07:44
Originariamente inviato da cdimauro
Hai detto bene: generalmente. Ma c'è pure della gente che vorrebbe che stessero in user-space, per limitare al minimo eventuale danni.
In L4 we trust

Se vogliamo mettere tutto in un calderone sì, ma ciò non toglie che nella "cipolla" stanno nel secondo strato. ;)
Vada per il calderone, considerando pero` che
1) in un design a macrokernel, non vedo molte altre strade per far funzionare le cose
2) dipende dalla cipolla con cui si fa la zuppa, perche` il driver e` il pezzo di codice piu` a stretto contatto col ferro, cui si appoggi anche tutto il resto per fare l'HAL.

Se lavoro del kernel non me frega niente dei driver.
Frega frega. In un design a macrokernel frega inevitabilmente, perche` il codice va a girare tutto nello stesso spazio di indirizzamento. Per quanto pulite possano essere le interfacce, non si puo` impedire a chiunque di fare qualunque cosa. Del resto e` cosi` che funzionano i LKM maligni.
Se lavoro sui driver non me ne frega niente del kernel.
Frega frega. E se uso un BigKernelLock nel mio bel driver closed source?

D'altra parte la suddivisione del software in layer completamente separati, uniti solanto dalle specifiche d'interfacciamento, è una della metodologie più importanti dell'Ingegneria del Software e del Codice Scritto Bene.
Ma forse questo è un argomento tabù in questo contesto, visto i precedenti... :D
E` un'abbozzo di flame? Spiacente, ho sepolto l'ascia di guerra... ;)

cdimauro
17-10-2004, 07:59
Originariamente inviato da RaouL_BennetH
il messaggio l'ho letto, e già assomiglia di più a quelle che io intendo come argomentazioni "tecniche", intendevo discorsi volti su questo piano praticamente.
Francamente non vedo molte differenze sul piano meramente tecnico, rispetto a quanto si era già scritto.
intendo che mi meraviglia il fatto che non ci siano in molti che lo fanno, oppure, se ci sono, non si fanno avanti, ne più ne meno.
Questo non è importante. D'altra parte il C è nato con Unix, e ha un notevole bacino d'utenza, mentre il C++ è un linguaggio più recente, e più complesso da digerire: col tempo è destinato a sostituire il C, a mio avviso (visto che comunque può essere usato come il C).
proprio perchè io non sono un programmatore ma un semplice utente, credo di essere meno "coinvolto" da discorsi di "fedi informatiche o varie", e mi piacerebbe che i vostri discorsi mirino ad un piano più tecnico, a differenza invece di come potrei farlo io, mi spiace che tu non abbia colto questa cosa.
A me spiace che tu no ne riesca a cogliere le motivazioni prettamente tecniche a supporto delle nostre idee.
Ok, ho capito ma per esprimermi brutalmente allora dico:

Fek ha fatto l'esempio sui vettori, benissimo e, ancora una volta complimenti (senza nessuna forma di sarcasmo) ma:

Si usi il C++ per fare l'operazione X
Si usi il C per fare la stessa operazione
Si usi il Basic per fare la stessa operazione
Si usi Carta e Penna per fare la stessa operazione

Quale risulta la migliore per il contesto e lo scopo a cui deve servire?

E' questo che io intendo con il portare codice, esempi, e non "parole", così, chiunque, anche un normale utente come me, può fare la prova e verificare.
Metti in pratica l'esempio di fek. Tutto qui.
qui il :muro: lo metto io adesso :D. Dato che la discussione stupenda che stavano facendo ilsensine e fek, è rivolta al mondo della programmazione, mi sembra più che logico che ognuno cerchi di motivare le parole che scrive con degli esempi in codice, possibile che sia tanto difficile da accettare? E' come se ad un raduno di matematici, il teorico di turno, comincia a spiegare la sua teoria, ne parla, ne parla e ne straparla, ma non fornisce nessun esempio, teorema, tabellina del due, tre, etc... Certo, le parole saranno legittime e ammirevoli, ma qualcuno si potrebbe chiedere: "Ma se tutto quel che dici è vero, perchè non lo dimostri?"
Perché è già stato fatto! Se c'è una cosa che non mancano, sono proprio le dimostrazioni. Prendi il messaggio "riassuntivo" di fek, e dimmi se le cose non stanno così...
Qui non capisco perchè ti infervori così tanto per una semplice richiesta motivata da una semplice curiosità. Comunque, fa niente.

In media un 3d che mi interessa lo rileggo spesso, però, sinceramente avrei qualcos'altro da obiettarti, ma mi sembra che in qualche modo ti abbia offeso (anche se non capisco perchè), e ti sento come dire "un pò nervoso", quindi, rimando.
Mi sono un po' arrabbiato perché hai etichettato ciò che abbiamo scritto io e fek come chiacchiere: proprio tu che hai ammesso che non ne capisci di programmazione.
Prima di definirle chiacchiere dovresti quanto meno capire quello che è stato scritto da ambo le parti: t'è bastato, invece, vedere qualche riga di codice per far pendere inesorabilmente la bilancia da una parte. Ammettendo fra le righe, tra l'altro, di non averci capito niente (del messaggio di repne scasb).
Capisci bene che a me è sembrata una presa in giro: se non hai le competenze per discernere ciò di cui si discute, almeno astieniti da giudizi sommari e lapidari.
Posso capire che le argomentazioni di repne scasb ti facciano piacere, perché supportano la "causa" di Linux, ma non è così che puoi portare un contributo alla discussione, già di per sé abbastanza "pepata".
qui sono io che al momento non ti rispondo, perchè questa risposta tirerebbe fuori anche a me una fiammata non proprio garbata, perchè non è una risposta intelligente come da "cdimauro" ci si aspetterebbe.
E perché mai? Se vai da un paniettere e pretendi spavaldamente di insegnargli come si fa il pane, non avendo tra l'altro adeguate conoscenze in materia, come dovrei etichettarti? Dimmelo un po' tu.
Io infatti non mi sono mai presentato come un esperto o come un programmatore, e questa tua risposta non la prendo neanche come un'offesa perchè semplicemente non mi tocca in niente.
Come ho già detto, a me hanno toccato le tue risposte, invece.
Ho sintetizzato prima il perchè molte volte anche in altre sezioni, spesso su discorsi che potrebbero interessare anche un utente normale, si perdano o sembra che si perdano solo in direzioni di "fede" relativa al C o al C++ o linux o windows etc... che per me sono assolute str.....te (intese come argomenti da farne una guerra).
Bene. Proprio per questo dovresti cercare di rimanere in un contesto meramente tecnico. Se poi non hai adeguate conoscenze, quanto meno cerca di capire quello che scrivono gli altri prima di arrivare a giudizi affrettati e lesivi dell'intelligenza di chi scrive.

Ciao

cdimauro
17-10-2004, 08:10
Originariamente inviato da Ikitt_Claw
In L4 we trust
:confused:
Vada per il calderone, considerando pero` che
1) in un design a macrokernel, non vedo molte altre strade per far funzionare le cose
2) dipende dalla cipolla con cui si fa la zuppa, perche` il driver e` il pezzo di codice piu` a stretto contatto col ferro, cui si appoggi anche tutto il resto per fare l'HAL.
Questo comporta soltanto di fare maggior attenzione, a mio avviso, tenendo sempre in primo piano le specifiche del s.o. e i requisiti a cui debbono sottostare i driver.
Frega frega. In un design a macrokernel frega inevitabilmente, perche` il codice va a girare tutto nello stesso spazio di indirizzamento.
Questa è una scelta implementativa: in futuro chi spinge per spostare tutto nello user-space potrebbe riuscire nell'impresa. ;)
Per quanto pulite possano essere le interfacce, non si puo` impedire a chiunque di fare qualunque cosa. Del resto e` cosi` che funzionano i LKM maligni.
E' colpa del design? Non credo.
Frega frega. E se uso un BigKernelLock nel mio bel driver closed source?
Non dovrebbe far parte delle specifiche? Scrivi il driver tenendo in considerazione questo vincolo. ;)
E` un'abbozzo di flame? Spiacente, ho sepolto l'ascia di guerra... ;)
Lo ammetto: c'ho provato. :p

Comunque secondo te la "cipolla" perché è stata tirata fuori? Per bontà dello spirito divino, o perché si tratta di un design razionale e consistente, che per pura coincidenza :) è anche uno dei cardini dell'ingegneria del software?

Per me si tratta anche di una cosa abbastanza naturale stratificare il software...

repne scasb
17-10-2004, 10:51

repne scasb
17-10-2004, 11:35

fek
17-10-2004, 15:05
Originariamente inviato da RaouL_BennetH
:eek: non ho capito niente ma concordo !!! :D :D

Scherzi a parte qualcuno richiedeva il tuo intervento, come sempre scientifico e perfetto :)

Non cosi' scientifico visto che ha dimenticato di mostrare il codice sorgente ;)

Se io prendo la stessa funzione (ricordiamo che C++ e' un superset del C e compila qualunque codice a parte trascurabili differenze) e i due compilatori traducono in codice diverso, il problema non e' del linguaggio ma del compilatore che non e' ottimale.
Molto semplicemente, quel compilatore e' un cattivo compilatore C++.

Oltretutto l'esempio e' capzioso perche' dimentica che i compilatori C++ hanno goduto di maggiore ricerca e sono piu' avanzati oggi dei compilatori C, quindi in genere producono codice migliore.

Infine, se quella funzione viene eseguita 1 milione di volte e rappresenta un collo di bottiglia identificabile in un sistema che deve essere efficiente, la soluzione non e' scriverla in C, ma scriverla direttamente in assembly.

fek
17-10-2004, 15:11
Originariamente inviato da cdimauro Per me è colpa del compilatore.

E' certamente colpa del compilatore, ma per esserne sicuri vorrei vedere il sorgente e capire se e' lo stesso codice oppure codice diverso (in tal caso la colpa e' del programmatore).

E' assolutamente impossibile che un compilatore C++ decente generi un codice diverso da quello che genera un compilatore C per lo stesso costrutto. E' per questo che ho chiesto quale problema puo' essere risolto piu' efficientemente in C, perche' e' matematico che la risposta sia nessuno :)
Qualunque soluzione in C puo' essere "ricompilata" con un compilatore C++ almeno con la stessa efficienza, non e' vero il contrario.

RaouL_BennetH
17-10-2004, 15:19
Originariamente inviato da fek
E' certamente colpa del compilatore, ma per esserne sicuri vorrei vedere il sorgente e capire se e' lo stesso codice oppure codice diverso (in tal caso la colpa e' del programmatore).

E' assolutamente impossibile che un compilatore C++ decente generi un codice diverso da quello che genera un compilatore C per lo stesso costrutto. E' per questo che ho chiesto quale problema puo' essere risolto piu' efficientemente in C, perche' e' matematico che la risposta sia nessuno :)
Qualunque soluzione in C puo' essere "ricompilata" con un compilatore C++ almeno con la stessa efficienza, non e' vero il contrario.

Ma se si usassero compilatori diversi, il risultato potrebbe cambiare oppure restare invariato?

fek
17-10-2004, 15:21
Originariamente inviato da repne scasb
Cosa voglio dimostrare: vorrei dimostrare (empricamente) che esistono dei casi in cui scrivere un kernel puo' risultare piu conveniente in C che in C++ (ATTENZIONE: dal punto di vista delle massime prestazioni ottenibili) (e' inutile nascondersi dietro un dito so bene che "sarebbe" preferibile scrivere in C++ per altri motivi (facilita' di modifica, leggibilita'..)).


E non lo stai dimostrando :)
Stai solo dimostrando che quel particolare compilatore C++ e' un cattivo compilatore, ma nulla che possa essere conclusivo in merito alla questione.

Parliamo di efficienza prestazionale qui, anche per te, mi porti l'esempio di un problema (o di un algoritmo) che possa essere risolto (o implementato) in maniera piu' efficiente in C?

12pippopluto34
17-10-2004, 15:31
Originariamente inviato da cdimauro
Che dire: un mostro! Valentino Rossi campione del mondo MotoGP, dopo una gara al cardiopalma: rimarrà nella storia... :winner:
[cut]


Non so se hai seguito i commenti di poco fa sulla RAI del dott. Costa: ha dichiarato ''la bravitu' di Rossi''!
:rotfl:

Ma come si fa a non essere ottimisti!

PS: per gli appassionati di sproloqui, http://www.magnaromagna.it/umorismo/sport/calcio.php

repne scasb
17-10-2004, 17:20

xeal
18-10-2004, 03:42
Originariamente inviato da repne scasb
2) Poiche' si parla di prestazioni massime assolute il linguaggio e' connesso al compilatore, altrimenti con cosa misuriamo le prestazioni massime assolute (a meno che xeal non sia in grado di formulare una metodologia di misurazione delle prestazioni massime di un linguaggio che sia indipendente dal compilatore (c'e' chi di ha provato in verita')).


Ammetto di non avere nè le conoscenze, nè tantomeno l'esperienza necessaria a formulare metodologie di analisi sulle prestazioni di un linguaggio. Tuttavia, nel parlare di prestazioni massime di un linguaggio non connesso al compilatore partivo dalla tuo (ti do del tu per l'ennesima volta, spero non ti dispiaccia, in tal caso ti prego di farmelo notare) prologo alla domanda conclusiva di quel post:
"Domanda sulle prestazioni assolute: Si supponga di avere un linguaggio di cui si stimi avere una prestazione assoluta di alto livello..."

Ora, se pressupponi che la stima si possa fare solo a posteriori, questa ipotesi ha senso solo se vuoi dimostrare la tua tesi per assurdo (e avresti potuto dirlo :p, ma era evidente). Oppure, se vuoi contestare con i fatti (il codice compilato) stime teoriche che supponi realmente compiute da qualcuno, allora bisogna presupporre che una metodologia si possa formulare. Io ho provato a considerare possibile questa ipotesi e a trarne qualche conclusione. Mi scuso preventivamente per la mancanza di rigore; personalmente ritengo possibile una valutazione aprioristica nella misura in cui si cerchi di stimare se le strutture del linguaggio siano adeguate a risolvere determinate problematiche e se le sovrastrutture indotte sulle strutture base del linguaggio macchina (ovvero dei linguaggi token immediatamente traducibili) siano così complicate da tradurre al punto di incidere sensibilmente sull'efficienza del compilatore (a prescindere da un compilatore specifico, se possibile). Es: mi rifaccio all'esempio portato da fek (non vorrei entrare nel merito della tua protesta nei suoi confronti e sulle ragioni, poichè ciò a cui mi riferisco non ha nulla a che vedere con l'offesa che ritieni di aver ricevuto) sui template e le call back: dal basso della mia inesperienza penso che il grado di ottimizzazione ottenibile sia teorizzabile a priori (potrei anche essere in errore).

Tornando alle considerazioni sulle sovrastrutture, mi piacerebbe capire meglio come sia possibile che un compilatore C++ derivato da uno C produca codice diverso laddove siano presenti solo costrutti del C e non del C++.

Sui tuoi test: il compilatore C produce un codice più "leggero", rapportato al codice C++, al più dello 0,76% circa (compilazione per 486SL ottimizzata per prestazioni) e più veloce al più dello 0,44% (80186, dimensione); il codice eseguibile C++ è più leggero, rapportato al C, al più dello 0,5% (68008, prestazioni) e più veloce (considerando i risultati da te normalizzati) dello 0,3% (68008, dimensione). Ora ti chiedo: queste differenze sono così significative da giustificare la scelta di un linguaggio? Se si, non sarebbe meglio optare per l'ottimizzazione in assembly del codice prodotto da uno dei due compilatori? E in tal caso, la scelta farebbe molta differenza?

Ancora: con tutto il rispetto per te e per tutti gli altri sviluppatori/utilizzatori di quel compilatore, un test esaustivo presupporrebbe un confronto tra più compilatori :O (qui mi aspetto di ricevere un bel "vaffa"... :D)

In ogni caso, posso essere d'accordo che per particolari problemi le "sovrastrutture" del C++ possano non essere particolarmente indicate (dal pungo di vista delle prestazioni assolute del codice relativo), però in tal caso, per porzioni di codice "critiche" si potrebbe usare codice C in un compilatore C++, ottenendo a mio avviso risultati molto vicini all'uso di un compilatore C, oppure, se non bastasse, si potrebbe inserire codice assembly inline. Comunque, sarei curioso di vedere il risultato di un confronto con oggetti implementati nei sorgenti sia per il C++, sia per il C, dato che, stando alle parole di ilsensine, il kernel di linux è object oriented, con tanto di polimorfismo ed ereditarietà. Se la maggiore velocità del C fosse dovuta alle strutture (native) più difficili da tradurre in linguaggio macchina, possibile che "emulando" in C le stesse strutture non si manifestino gli stessi "difetti"?

Sull'esempio di cdimauro: do per scontato che una struttura if-else non sia indicata per ottenere prestazioni assolute (ma in generale, specialmente per costrutti più complessi, dal punto di vista delle prestazioni complessive togliere i salti condizionati da un programma credo che sarebbe un suicidio). Però non capisco come giustifichi il problema riscontrato da Cesare: il costrutto if-else e l'operatore ?: non dovrebbero avere la stessa funzione ed essere tradotti dal compilatore con lo stesso codice? Se il compilatore non lo fa, in cosa consiste la colpa di un programmatore che sceglie la "forma" if-else invece dell'operatore ?:, o viceversa?

cdimauro
18-10-2004, 04:37
x repne scasb.
Mi spiace, ma questa volta le nostre idee divergono, e non posso che concordare con fek: la causa delle prestazioni diverse (non dico né inferiori né superiori) è da imputare per forza di cose al compilatore.

Te l'avevo già scritto: si tratta del punto c) che volevo aggiungere a quanto avevi riportato nei tuoi precedenti post. Se dai in pasto a un compilatore C++ un sorgente C (che quindi utilizza le medesime strutture) e genera un codice diverso, c'è qualcosa che non va in chi l'ha realizzato; ovviamente parlo di compilatori C e C++ scritti dalla stessa mano.

L'assoluto che cercavi, quindi, esiste. La dimostrazione di ciò è banale, e te la riporto nuovamente: un compilatore C++ che converte il sorgente processato in un altro sorgente, ma stavolta in C e che lo dà poi in pasto a un compilatore C, per forza di cose non può che generare lo stesso codice se non viene utilizzata alcuna caratteristica propria del C++. A meno che non introduca intenzionalmente del codice in più.


Per quanto riguarda gli esempi del max/min, mi spiace ma hai preso un granchio. :) L'esempio era voluto, e difatti ho parlato di un problema dovuto al compilatore C/C++ per VLIW LX di fronte a quel codice.
LX è un VLIW (con bundle di 4 istruzioni a 32 bit) che offre delle istruzioni per il calcolo di minimo e massimo (neppure i CISC hanno istruzioni come queste :D), per cui non esistono problemi di salti, e di conseguente stallo della pipeline.

Per utilizzare correttamente queste istruzioni, il compilatore deve cercare di riconoscere un pattern nel codice sorgente che gli permetta di capire che si trova di fronte a un problema di calcolo del minimo o massimo, in modo da permettere al back-end di generare gli opcode relativi, con un notevole risparmio di spazio e soprattutto una maggior velocità di esecuzione.

Il codice che hai scritto ucciderebbe letteralmente le sue prestazioni, perché sarebbero necessari due bundle per portarla a termine, a cui si aggiungerebbe anche la latenza introdotta dall'esecuzione della moltiplicazione (per cui il risultato sarebbe disponibile soltanto dopo 2 o 3 cicli di clock; adesso non ricordo bene). Tutto ciò quando normalmente occuperebbe una sola istruzione.
Di fatti col tuo codice il compilatore non potrebbe mai capire che si trova davanti a un problema di calcolo del minimo o massimo, e quindi non potrebbe sfruttare questa caratteristica dell'LX.

Comunque, non voglio certo disquisire sul modo migliore per calcolare il minimo o massimo: è chiaro che tutto dipende dall'architettura target per il quale si dovrà generare il codice.
Per LX è chiaramente inefficiente, sia per il numero di istruzioni necessarie, sia per il mancato utilizzo di quelle specifiche; per un VLIW come quello a cui penso ti sia riferita, con una sezione MAC, certamente può rappresentare lo stato dell'arte in termini di efficienza; su Itanium magari basterebbe utilizzare un registro di predicazione per contenere il risultato del confronto e usarlo in seguito per caricare il valore corretto, mentre su un RISC si potrebbe far uso di un'istruzione condizionale e su un x86 di una CMOV; ovviamente in questi ultimi casi sfruttando i pattern di codice che ho riportato.

cdimauro
18-10-2004, 04:44
x RaouL_BennetH: ovviamente potrebbero cambiare. ;)

x 12pippopluto34: io non posso essere ottimista. A ogni gara rischio un infarto! :eek: :D

x xeal: difatti è proprio un problema di compilatore. E' assurdo che si comporti in questo modo.

zoboliluca
18-10-2004, 08:18
Che i driver dedicati sono piu performanti lo avevo detto anche io nel primo post, ma per il resto non sono d'accordo.

E' vero che M$ e altri hanno scaricato il problema della creazione dei driver sui produttori hw ma che ad ogni versione o semi-versione del sistema operativo i programmatori della M$ debbano ristrutturare tutta la gestione dei driver, mi sembra una stupidata.

Oggi nell'era della riusabilita del software continuano a riscrivere le routine di gestione e a renderle incompatibili con le versioni precedenti. E oltre tutto non lasciano nemmeno implementata nel s.o. le vecchie routine per lasciare un minimo di compatibilita'. NO per evitare problemi (seguendo la filosofia del "se non ce, non si rompe") ti obbligano a cambiare hw.

Inoltre. Se non ricordo male nel campo degli scanner esistevano i driver TWAIN con i quali e' stato possibile utilizzare una intera generazione di scanner compatibili anche di marche diverse. Ora so benissimo che le stampanti di fascia bassa utilizzano la CPU per l'elaborazione della stampa (in quanto privi di un processore on board) e che quindi su questi modelli non e' possibile la creazione di un driver standard. Ma per i restanti modelli e periferiche? Tu, credi veramente che dopo 10-15 anni di sviluppo driver non sia stato possibile creare uno standard che a fronte di un piccolo calo prestazionale? Credi veramente che a fronte di una situazione stabile sul fronte dei s.o. i produttori hw non sceglierebbero di implementare un piccolo chip sull'hw (o una routine software o che cacchio ne so io) per mantenere la compatibilita dei driver passati presenti e futuri? Pensi veramente che ogni 3 anni si rendano conto che le nuove stampanti richiedono cosi tanti e nuovi e strutturalmente diversi codici di controllo da richiedere una nuova gestione dei driver?

Tutto questo e' forse (e ripeto forse) vero nella ricerca delle prestazioni massime (e solo con alcune periferiche, vedi schede video). MA QUANDO LE PRESTAZIONI non sono il fattore principale, o quando comunque l'hw limita le stesse (scanner e stampanti) nulla mi toglie dalla testa che possano essere utilizzate delle interfacce standard.
Un esempio nel campo delle stampanti? il Postcript o (andando molto molto indietro) le vecchie emulazioni IBM Proprinter e Epson FX80 le prime DeskJet e LaserJet che erano diventate uno standard di fatto, in quanto quasi tutte le stampanti potevano emulare l'una o l'altra.

Ma l'esempio piu ovvio e palese della mancanza di volonta politica e' nel campo dei WordProcessor (che a mio avviso e' strettamente collegato alle stampanti :-) ).
Dove da anni esiste un formato Adobe il PDF le cui prime versioni sono tuttora perfettamente leggibili e parzialmente compatibili anche all'indietro. Mentre ad ogni versione di Office i documenti Word diventano illeggibili. Ovviamente sai che HTML, PDF, XML e tanti altri sono semplicemente figli del SGML inventato negli anni 60 e che rimane tutt'ora lo stato dell'arte nel campo delle impaginazioni tipografiche.
Quindi perche' i formati Word continuano a cambiare e ad essere inconpatibili?

Basta la chiudo qui perche sto esagerando.
Chiedo scusa a tutti.

CIAO

ilsensine
18-10-2004, 09:32
Mamma, non posso mancare un paio di giorni che si scatena il putiferio :D
(Non ho ancora letto tutti i commenti)
Originariamente inviato da fek
<...>
(Guarda, il fatto che te parli tranquillamente di "ridimensionare array" dentro al kernel indica che forse non hai le idee molto chiare del fatto che un kernel ha esigenze un pò diverse rispetto applicazioni user space. Comunque, non è detto che ci siano casi in cui è necessario --- personalmente, non ho mai visto nessun pazzo che si mette a ridimensionare array dentro al kernel).

Tornando al discorso nostro (che è tutt'altro che finito) ti faccio un pò di esempi di cose che, scritte "alla c++", possono dare dei problemi (o per lo meno delle inutili complicazioni) dentro a un kernel.
Prendi questa classe ad esempio:

class c {
public:
void *operator new (size_t sz) {
return malloc(sz); // emula una allocazione custom della memoria
}
void *operator delete(void *self) { free(self) };
public:
// Mettiamo qualcosa nella vtable...
virtual void ciao() {}
};


(ok l'operatore "new" dovrebbe avere qualche altro parametro, per poter indicare che tipo di allocazione devo effettuare...è banale e non includo questo dettaglio)
La classe così com'è funziona perfettamente in user space. In kernel space ho qualche problema a compilarla, in quanto il gcc cerca il simbolo "__cxxabiv1::__class_type_info", presente nelle librerie stdc++ (che sono librerie user space). Dovrei capire di che si tratta e trovare un workaround...vabbè non è divertente, già un lavoro inutile che dovrei fare...
Andiamo avanti. Simuliamo una situazione di OOM: sostituiamo "return malloc(..." con "return NULL".
Faccio un programma di test che utilizza questa classe (chiama semplicemente "new" e poi "delete"). Compilo & eseguo il programma -> segmentation fault. Come mai? Il compilatore ha aggiunto del codice (che io non ho scritto!!) al programma: la copia della vtable dopo la "new". Oh cavolo, questa proprio non è una bella cosa. Vabbè, posso dichiarare la new come "throw()" in modo da far sì che la vtable non sia copiata se l'operatore new restituisce NULL. Ma che controllo viene fatto dopo la new? Viene controllato che il valore di ritorno sia "NULL". E chi ha detto che è NULL l'indirizzo "non valido"? L'allocazione tramite mmap ad esempio restituisce (~0) se la mappatura fallisce! Conosco almeno un paio di programmi dove NULL è un valore di memoria valido!

Altro esempio: "static virtual" vietato (forse).
Quasi tutti i device driver (e non solo) in linux definiscono una struttura "file operations", che contiene i puntatori alle funzioni di interfaccia del driver (open, close, read/write, ioctl, mmap...). E' una delle strutture più usate all'interno del kernel. Una interfaccia standard, che ben si presterebbe ad essere definita tramite classi polimorfe. Così è definita ad es. nel kernel 2.6 (alcuni membri):

struct file_operations {
struct module *owner;
loff_t (*llseek) (struct file *, loff_t, int);
ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
ssize_t (*aio_read) (struct kiocb *, char __user *, size_t, loff_t);
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
ssize_t (*aio_write) (struct kiocb *, const char __user *, size_t, loff_t);
int (*readdir) (struct file *, void *, filldir_t);
(...altri metodi per un totale di 23...)

Come vedi i parametri delle funzioni definite non contengono un reference alla struttura file_operations stessa, ma altri parametri (gli oggetti interessati all'operazione). Questo vuol dire che, volendole includere in una classe, e volendo evitare che ognuna di queste funzioni si ritrovi ad avere un parametro in più ("this"), dovrei dichiararle "static". Almeno il g++, però, non consente di dichiarare "static" una funzione "virtual" (non so se è previsto dallo standard). Ok, codice in più generato dal compilatore, e minore ottimizzazione (i primi 3 parametri di una funzione sono passati per registro, poi si comincia ad usare lo stack).


Altro esempio problematico: hook di debug non intrusivo. Supponi che devi fare un modulo che misura la latenza di una ioctl di un driver block device specificato al modulo. Un esempio tutt'altro che astratto. Con la struttura attuale del kernel è abbastanza facile: ottengo un reference al block device di interesse, considero la struttura contenente le "file operations", sostituisco la ioctl con una mia funzione ioctl, che non fa altro che chiamare la funzione originaria misurando però il timestamp prima e dopo la chiamata. Se le file operations fossero funzioni virtuali, non potrei fare una cosa così semplice.


... e ora mi metto a leggere tutti i commenti...come al solito cdimauro non ha avuto pietà...:p

ilsensine
18-10-2004, 09:48
Originariamente inviato da cdimauro
Per questi ultimi lo so: ho letto qualche thread nell'area Linux, e mi sembrava che i commenti a proposito di quelli nVidia fossero esaltati, addirittura anche da parte de ilsensine... :D

Ehi ehi piano, questa è diffamazione a mezzo stampa :D
Quello che dico è che "se non hai problemi a utilizzare driver proprietari (e io li ho), butta la tua ATI e compra una nvidia. Hanno driver fra i migliori nel mondo closed source, e (soprattutto) un atteggiamento cristallino e rispettoso nei confronti della comunità libera".
Questo non vuol dire che le nvidia non hanno problemi: li hanno, ma molto meno di altri (e con un supporto alla risoluzione dei problemi migliore).

ilsensine
18-10-2004, 09:59
Originariamente inviato da Ikitt_Claw
In linux i device driver fan parte del kernel, c'e` poco da sindacare. :)
Non sempre, ci sono molti esempi di driver "user space". A parte i famosi "usermode" per modem usb, cito i driver video: la parte kernel si occupa dello sharing delle risorse, del caricamento del microcode, gestione di dma, irq, agp ecc. Insomma, fanno quello che in user space non si può fare; il resto è gestito dal driver in user space, che si occupa del "grosso" del lavoro.
C'è da dire che tempo fa gli sviluppatori delle Mesa (che utilizzano i driver accelerati user space, se disponibili, e forniscono fallback software per ciò che il driver non implementa) hanno discusso su una possibile riscrittura in c++ delle librerie. Mi sembrava ci fosse stato un buon consenso, anche se ad oggi ancora non è stato fatto nulla (non seguo molto lo sviluppo delle Mesa cmq).

fek
18-10-2004, 10:04
Originariamente inviato da repne scasb
Come utilizzatrice di tale compilatore e co-autrice di alcuni plug-in mi ritengo personalmente offesa da queste gratuite attribuzioni di responsabilita'.
Denigrare il lavoro altrui, in quanto, non collidente con le proprie convinzioni, non ti fa onore.

Mi scuso con gli altri utilizzatori del forum, per questa "secca" presa di posizione pubblica, ma mi aspetto delle pubbliche scuse da parte di fek.

Mi spiace se ti senti offesa, ma non c'era alcuna intenzione di offendere nessuno nel mio post.

Hai portato due pezzi di asm prodotti da un non meglio specificato sorgente, compilato con due compilatori differenti che avrebbero, secondo ogni logica, dovuto produrre lo stesso risultato. Hai usato questa conclusione per dimostrare che due compilatori differenti su una piattaforma differente (Linux) condividono lo stesso comportamento. Come puoi facilmente immaginare, questo passaggio e' del tutto fuorviante perche' non c'e' alcuna correlazione fra le due situazioni e la tua conclusione e' del tutto errata.

L'unica cosa che hai dimostrato e' che due compilatori che dovrebbero produrre lo stesso risultato, producono risultati diversi. Chiama questa situazione come vuoi (io la chiamo cattivo compilatore), ma questo e' un dato di fatto che scaturisce dal tuo esempio.

Scegli un esempio migliore la prossima volta.

fek
18-10-2004, 10:09
Originariamente inviato da xeal
In ogni caso, posso essere d'accordo che per particolari problemi le "sovrastrutture" del C++ possano non essere particolarmente indicate (dal pungo di vista delle prestazioni assolute del codice relativo), però in tal caso, per porzioni di codice "critiche" si potrebbe usare codice C in un compilatore C++, ottenendo a mio avviso risultati molto vicini all'uso di un compilatore C, oppure, se non bastasse, si potrebbe inserire codice assembly inline. Comunque, sarei curioso di vedere il risultato di un confronto con oggetti implementati nei sorgenti sia per il C++, sia per il C, dato che, stando alle parole di ilsensine, il kernel di linux è object oriented, con tanto di polimorfismo ed ereditarietà. Se la maggiore velocità del C fosse dovuta alle strutture (native) più difficili da tradurre in linguaggio macchina, possibile che "emulando" in C le stesse strutture non si manifestino gli stessi "difetti"?


Questo e' un punto a mio avviso molto interessante. Concetti come l'ereditarieta', il dispatching dei metodi virtuali (ovvero scegliere un'azione durante l'esecuzione in base al tipo di oggetto che deve compiere l'azione), possono ovviamente essere emulati in C, ma non con l'efficienza esecutiva con la quale un compilatore C++ nativo, che conosce quei concetti, puo' produrre il codice relativo.

Un esempio semplice: voglio implementare un'azione che distrugge un oggetto in base al suo tipo; il compilatore C++ conosce nativamente questo concetto e conosce la dimensione dell'oggetto da distruggere, un concetto interno al compilatore. Un eventuale codice C che deve riprodurre questa soluzione, sarebbe costretto, non conoscendo nativamente questi concetti, ad esempio a portarsi dietro in qualche modo la dimensione dell'oggetto da distruggere per un'efficiente disallocazione (il tipo di oggetto non e' conosciuto a tempo di compilazione ma solo a tempo di esecuzione), introducendo un overhead, ovvero un'inefficienza.

fek
18-10-2004, 10:27
Originariamente inviato da ilsensine
Mamma, non posso mancare un paio di giorni che si scatena il putiferio :D
(Non ho ancora letto tutti i commenti)

(Guarda, il fatto che te parli tranquillamente di "ridimensionare array" dentro al kernel indica che forse non hai le idee molto chiare del fatto che un kernel ha esigenze un pò diverse rispetto applicazioni user space. Comunque, non è detto che ci siano casi in cui è necessario --- personalmente, non ho mai visto nessun pazzo che si mette a ridimensionare array dentro al kernel).

(ok l'operatore "new" dovrebbe avere qualche altro parametro, per poter indicare che tipo di allocazione devo effettuare...è banale e non includo questo dettaglio)


No, derivi (o fai composizione) da oggetti diversi se vuoi diversi tipo di allocazione :)


La classe così com'è funziona perfettamente in user space. In kernel space ho qualche problema a compilarla, in quanto il gcc cerca il simbolo "__cxxabiv1::__class_type_info", presente nelle librerie stdc++ (che sono librerie user space). Dovrei capire di che si tratta e trovare un workaround...vabbè non è divertente, già un lavoro inutile che dovrei fare...


Prova a disabilitare l'RTTI e vedrai che non cerca quel simbolo, ci vuole un secondo ;)
Se continua a cercarlo, il problema e' del compilatore, non del linguaggio.


Andiamo avanti. Simuliamo una situazione di OOM: sostituiamo "return malloc(..." con "return NULL".
Faccio un programma di test che utilizza questa classe (chiama semplicemente "new" e poi "delete"). Compilo & eseguo il programma -> segmentation fault. Come mai? Il compilatore ha aggiunto del codice (che io non ho scritto!!) al programma: la copia della vtable dopo la "new". Oh cavolo, questa proprio non è una bella cosa. Vabbè, posso dichiarare la new come "throw()" in modo da far sì che la vtable non sia copiata se l'operatore new restituisce NULL. Ma che controllo viene fatto dopo la new? Viene controllato che il valore di ritorno sia "NULL". E chi ha detto che è NULL l'indirizzo "non valido"? L'allocazione tramite mmap ad esempio restituisce (~0) se la mappatura fallisce! Conosco almeno un paio di programmi dove NULL è un valore di memoria valido!


Null Object pattern e la vita ti sorride. Non devi mai controllare che il valore dell'oggetto restituito sia NULL. Ovvero, un tipico pattern OOP risulta piu' veloce della tua soluzione in C puro.
E' un tipico esempio di come tu stia cercando di forzare il C++ a comportarsi come C in un'architettura C e da qui ne escono le inottimizzazioni. Il problema qui non e' nel linguaggio, ma in chi lo usa: cambiando architettura e design (e' tutto qui il punto), implementando i NULL object ed un factory pattern, ovvero l'allocazione dell'oggetto viene gestita da una factory class che restituisce Null object, secondo il ben noto pattern, ottieni una soluzione piu' efficiente e robusta: non devi mai testare un oggetto NULL e sei sempre garantito che non vada in segmentation fault.

Grazie dell'esempio, mi hai dato la possibilita' di mostrare come queste presunte inefficienze siano colpa di come il linguaggio e' usato, non del linguaggio.



Altro esempio: "static virtual" vietato (forse).
Quasi tutti i device driver (e non solo) in linux definiscono una struttura "file operations", che contiene i puntatori alle funzioni di interfaccia del driver (open, close, read/write, ioctl, mmap...). E' una delle strutture più usate all'interno del kernel. Una interfaccia standard, che ben si presterebbe ad essere definita tramite classi polimorfe. Così è definita ad es. nel kernel 2.6 (alcuni membri):
[code]
... snip...
Come vedi i parametri delle funzioni definite non contengono un reference alla struttura file_operations stessa, ma altri parametri (gli oggetti interessati all'operazione). Questo vuol dire che, volendole includere in una classe, e volendo evitare che ognuna di queste funzioni si ritrovi ad avere un parametro in più ("this"), dovrei dichiararle "static". Almeno il g++, però, non consente di dichiarare "static" una funzione "virtual" (non so se è previsto dallo standard). Ok, codice in più generato dal compilatore, e minore ottimizzazione (i primi 3 parametri di una funzione sono passati per registro, poi si comincia ad usare lo stack).


Functor :)
Tipico esempio di Command pattern. Il kernel si puo' limitare a dichiarare un Command template che accetta Functor in ingresso per ognuna di queste operazioni.
Il driver puo' dichiarare un Functor come una funzione o come una classe che fa overload dell'operatore (), e passa il Functor che rappresenta il comando al kernel. Se, in alcune condizioni, l'operazione e' conosciuta a tempo di compilazione, il Functor puo' essere inline, non viene eseguita neppure la chiamata a funzione ed il compilatore puo' ottimizzare saltando la barriera del salto: il risultato netto e' un aumento di prestazioni rispetto alla soluzione C.

Si tratta solo di cambiare il design in un design piu' moderno.



Altro esempio problematico: hook di debug non intrusivo. Supponi che devi fare un modulo che misura la latenza di una ioctl di un driver block device specificato al modulo. Un esempio tutt'altro che astratto. Con la struttura attuale del kernel è abbastanza facile: ottengo un reference al block device di interesse, considero la struttura contenente le "file operations", sostituisco la ioctl con una mia funzione ioctl, che non fa altro che chiamare la funzione originaria misurando però il timestamp prima e dopo la chiamata. Se le file operations fossero funzioni virtuali, non potrei fare una cosa così semplice.


Visitor pattern :)
Il debug si registra come un visitor al kernel passando un Functor. Il Kernel richiama i visitor in successione, se il visitor e' conosciuto a tempo di compilazione, la chiamata viene fatta inline ed eliminata.

In sintesi: hai cercato di risolvere questi problemi senza usare l'espressivita' che il C++ ti permette in confronto al C, che porta a soluzioni piu' efficienti. Il problema non e' in linguaggio, ma il programmatore qui.

Interessante effetto collaterale: ti ho riportato il nome dei Design Pattern coinvolti nella soluzione di ogni problema, i Design Pattern sono soluzioni gia' provate e ben documentate. Come effetto collaterale dell'uso del C++ c'e' il fatto di avere gia' a disposizione una libreria' di soluzioni della potenza e dell'eficacia dei design pattern.

repne scasb
18-10-2004, 10:31

fek
18-10-2004, 10:50
Originariamente inviato da repne scasb
Ora e' chiaro che se utilizzate il plug-in C++ per compilare codice C, avrete un eseguibile leggermente piu' grande e leggermente piu' lento.


Ovvero, il problema e' del compilatore che fa quelle assunzioni, non del linguaggio.
CVD


Per non incorrere in quest'inconveniente, e' sufficiente che il programmatore che scrive in C utilizzi il plug-in per C, e se scrive in C++ utilizzi il plug-in per C++ (Lyane, mi sfugge ancora il motivo del perche' se uno scrive codice C lo deve compilare con il compilatore C++, mi rispieghi la faccenda). Per risolvere noi, automaticamente la faccenda, dovremmo processare l'ipotetico codice C/C++, capire se e' C puro o C++, ed inviarlo al plug-in oppurtuno, tutto questo allungando le fasi di compilazione. Perche' mai dovremmo fare una simile cosa. Perche' mai un programmatore che scrive in C dovrebbe utilizzare il plug-in C++.


Semplice, per sfruttare l'espressivita' del linguaggio che gli permette prestazioni migliori su molte classi di problemi.

"Io non voglio dimostrare che in "GENERALE" il C ha prestazione assolute migliori del C++."

"Io voglio dimostrare che in casi "PARTICOLARI" il C ha prestazione assolute migliori del C++".


Ed hai dimostrato che con quel particolare compilatore su quella particolare architettura hai quel profilo prestazionale. Da questo, non puoi concludere nulla su Linux (cosa che hai fatto, ed e' l'unica cosa che ho contestato).

repne scasb
18-10-2004, 10:55

fek
18-10-2004, 11:05
Originariamente inviato da repne scasb
Ho risposto a xeal su questo punto (vedi la risposta dello sviluppatore capo di EPSD riportata nella risposta di Xeal). In sostanza, volevo dimostrare (e dalla tua risposta intuisco, che sono stata fraintesa), che per esigenza "PARTICOLARI" un sorgente C, compilato da un compilatore C e da un compilatore C++, puo' essere diverso senza che ve ne sia colpa in chi ha sviluppato il compilatore (vedi risposta a xeal di Adrian Bennet). E qui ribadisco che sostenere che un compilatore e' malfatto esclusivamente in base al fatto che genera codice macchina diverso, senza conoscere le ragioni che hanno spinto gli sviluppatori a prendere una simile decisione e' offensivo del lavoro degli sviluppatori stessi (e se permetti avendone fatto parte m'irrito alquanto).


Ti ripeto che non c'era alcuna connotazione offensiva nelle mie parole, non mi sembra il caso di battere ancora su questo punto.
Mi sono limitato a commentare un fatto chiaro: se quel compilatore C++ non produce lo stesso codice del compilatore C, la "colpa" (senza alcuna connotazione negativa, puoi usare la parola "causa" se urta di meno la tua sensibilita') e' del compilatore e delle sue scelte, non del linguaggio.

repne scasb
18-10-2004, 11:14

ilsensine
18-10-2004, 11:20
Originariamente inviato da fek
Prova a disabilitare l'RTTI e vedrai che non cerca quel simbolo, ci vuole un secondo ;)
Se continua a cercarlo, il problema e' del compilatore, non del linguaggio.

Disabilitato, ora vuole __gxx_personality_v0.
Ok sarà un problema del compilatore...


Null Object pattern e la vita ti sorride. Non devi mai controllare che il valore dell'oggetto restituito sia NULL.

Ehm...non ho controllato io il valore NULL, ma il codice automagicamente inserito dal compilatore ha fatto questo controllo.
Se puoi farmi un esempio alternativo... (almeno da tutta 'sta storia imparo qualcosa, anche se dubito che mi servirà nel kernel)
ovvero l'allocazione dell'oggetto viene gestita da una factory class che restituisce Null object, secondo il ben noto pattern, ottieni una soluzione piu' efficiente e robusta: non devi mai testare un oggetto NULL e sei sempre garantito che non vada in segmentation fault.
Ben poche cose sono più efficienti (e semplici da leggere) di una semplice if(!(obj=kmalloc(sz, GFP_ATOMIC))) {...}


No, derivi (o fai composizione) da oggetti diversi se vuoi diversi tipo di allocazione :)
...
Functor :)
...
Tipico esempio di Command pattern. Il kernel si puo' limitare a dichiarare un Command template che accetta Functor in ingresso per ognuna di queste operazioni.
....
Visitor pattern :)
...

Qualche altro trucco per complicarsi le cose più banali? ;)

Stai dentro a un kernel, dannazione! Smetti di fare la qsort e ridimensionare array, e pensa a far funzionare quel dannato controller DMA! Si tratta di scrivere un paio di stupide funzioni! :oink:

fek
18-10-2004, 11:31
Originariamente inviato da repne scasb
Ci sono ancora due cose su cui differiamo concettualemente:

1) Tu chiami questa differenza nel compilato "cattivo compilatore", io la chiamo "esigenza del compilatore" (vedi risposta dello sviluppatore del compilatore data nella mia risposta a xeal).


Esigenze del compilatore su quella piattaforma, o forse anche scelte architetturali del compilatore. Si', siamo d'accordo.


2) Questa seconda differenza nasce necessariamente dalla prima, poiche' ritieni il "compilatore cattivo", non accetti chiaramente il passaggio logico: se succede su EPSD perche' non puo succedere su Linux?


Perche' non c'e' alcuna correlazione fra le due cose, per me questo passaggio logico e' errato.
Altrimenti: il compilatore C++ Microsoft fa "instrumented profiling" che porta a miglioramenti prestazionali medi del 10%. Non c'e' alcun compilatore C che faccia cio', secondo il tuo ragionamento, se succede in Win32 su quel compilatore, perche' non puo' succedere anche su Linux?
Perche' non c'e' alcuna correlazione.


Comprendo ora dal tuo punto di vista il tuo ragionamento (potrei pero' ancora sbagliarmi), e dal tuo punto di vista lo ritengo accettabile, anche se non mi ci trovo d'accordo.

L'unica cosa e' la modalita' con cui esprimi il tuo pensiero: mi sarebbe piaciuta una forma piu' pacata del tipo (comprendo pero' che non posso pretendere di importi nulla): "Forse c'e' qualcosa che non funziona nel compilatore", oppure: "Non ho capito perche' i due compilati sono diversi, ti puoi spiegare meglio?". Una frase del tipo (non cito le paroli testuali, ma cito quello che il mio cervello ha colto sul momento): "O il compilatore e' fatto male o il programmatore non sa programmare", non mia hanno fatto un granche piacere.

Mi spiace che sia stata interpretata in quella maniera, non c'era davvero alcun intendo denigratorio nelle mie parole :)

repne scasb
18-10-2004, 11:33

fek
18-10-2004, 11:36
Originariamente inviato da ilsensine
Ehm...non ho controllato io il valore NULL, ma il codice automagicamente inserito dal compilatore ha fatto questo controllo.
Se puoi farmi un esempio alternativo... (almeno da tutta 'sta storia imparo qualcosa, anche se dubito che mi servirà nel kernel)


Un esempio di uso del Null Object Paradigm?


Ben poche cose sono più efficienti (e semplici da leggere) di una semplice if(!(obj=kmalloc(sz, GFP_ATOMIC))) {...}


O si che ci sono.


obj = ObjectFactory::Create(/*opzioni*/);
obj->Action();


Nessun branch, ricordiamo che le cpu non gradiscono i branch, molto meglio una chiamata indiretta, perche' le cpu sono costruite per digerire le indirezioni.

La chiamata "obj->Action()" e' garantita essere possibile, perche' ::Create torna un Null Object in caso di errore e il NullObject implementa un Action() valida.

Piu' leggibile, piu' efficiente.
Che c'e' di meglio? :)


Qualche altro trucco per complicarsi le cose più banali? ;)

Stai dentro a un kernel, dannazione! Smetti di fare la qsort e ridimensionare array, e pensa a far funzionare quel dannato controller DMA! Si tratta di scrivere un paio di stupide funzioni! :oink:

Usare un Design Pattern non e' un trucco, semplifica la vita, perche' qualcun altro ha gia' implementato la soluzione al tuo problema ed e' garantita funzionare.

repne scasb
18-10-2004, 11:40

ilsensine
18-10-2004, 11:41
Originariamente inviato da fek
O si che ci sono.


obj = ObjectFactory::Create(/*opzioni*/);
obj->Action();


Nessun branch, ricordiamo che le cpu non gradiscono i branch, molto meglio una chiamata indiretta, perche' le cpu sono costruite per digerire le indirezioni.

La chiamata "obj->Action()" e' garantita essere possibile, perche' ::Create torna un Null Object in caso di errore e il NullObject implementa un Action() valida.

Piu' leggibile, piu' efficiente.
Che c'e' di meglio? :)

Più efficiente!? Ma stiamo scherzando? Se l'allocazione fallisce sono nei guai. Sono in GROSSI guai. Soprattutto in contesto di irq. Non posso far finta di nulla e andare avanti, "tanto c'è il null object che non mi va in segfault"...devo sapere subito cosa è successo, e prendere provvedimenti (spesso non ovvi) che dipendono dal punto in cui ho tentato l'allocazione.
Ricorda che sei in un kernel, e se fallisce una allocazione in contesto di irq non è affatto divertente. E può succedere, anche se c'è memoria di sistema libera/liberabile.

Duncan
18-10-2004, 11:54
Originariamente inviato da ilsensine
Più efficiente!? Ma stiamo scherzando? Se l'allocazione fallisce sono nei guai. Sono in GROSSI guai. Soprattutto in contesto di irq. Non posso far finta di nulla e andare avanti, "tanto c'è il null object che non mi va in segfault"...devo sapere subito cosa è successo, e prendere provvedimenti (spesso non ovvi) che dipendono dal punto in cui ho tentato l'allocazione.
Ricorda che sei in un kernel, e se fallisce una allocazione in contesto di irq non è affatto divertente. E può succedere, anche se c'è memoria di sistema libera/liberabile.


Nella Action() del null object non è implementato il codice per gestire l'evento? (se ho capito bene come funziona :O )

fek
18-10-2004, 11:54
Originariamente inviato da ilsensine
Più efficiente!? Ma stiamo scherzando? Se l'allocazione fallisce sono nei guai. Sono in GROSSI guai. Soprattutto in contesto di irq. Non posso far finta di nulla e andare avanti, "tanto c'è il null object che non mi va in segfault"...devo sapere subito cosa è successo, e prendere provvedimenti (spesso non ovvi) che dipendono dal punto in cui ho tentato l'allocazione.
Ricorda che sei in un kernel, e se fallisce una allocazione in contesto di irq non è affatto divertente. E può succedere, anche se c'è memoria di sistema libera/liberabile.

Esattamente lo scopo del NullObject.

::Create() ti puo' restituire un NullObject in caso di mancata allocazione, ma vuoi andare sul sottile?
Allora restituiamo un HandleMemoryExceptionObject la cui azione e' fare esattamente tutto il necessario per non crashare il sistema e gestire il problema.

La gestione del problema diventa compito dell'oggetto che deve gestirla e non del codice cliente, che sa solo che deve chiamare il metodo Action(), ma non e' interessato nel come l'azione viene eseguita.
Puoi anche passare a ::Create dei parametri che ti descrivano la situazione e il contesto nel quale la creazione dell'oggetto e' richiesta, di modo da restituire l'oggetto che gestisce la situazione d'errore al meglio.

Con questo semplice pattern ottieni:
- un design piu' chiaro che separa la gestione dell'errore e il codice cliente, diminuendo coupling e complessita' del sistema
- un design piu' efficiente perche' l'indirezione e' piu' veloce del branching
- un codice piu' leggibile perche' non sei costretto a "sporcare" il codice con la gestione degli errori

Triple win.

fek
18-10-2004, 12:00
TORVALDS: "la semplicità richiede notevoli capacità di design"

Amen :)

ilsensine
18-10-2004, 12:02
Originariamente inviato da fek
Esattamente lo scopo del NullObject.

::Create() ti puo' restituire un NullObject in caso di mancata allocazione, ma vuoi andare sul sottile?
Dovrei quindi controllare il valore di ritorno? Allora non è più efficiente di una normale kmalloc.

Allora restituiamo un HandleMemoryExceptionObject la cui azione e' fare esattamente tutto il necessario per non crashare il sistema e gestire il problema.
"...fa esattamente tutto il necessario..."...in quale contesto? Dentro uno spinlock? Sblocca lo spinlock e si inventa qualcosa, possibilmente tirando a indovinare qual'è lo spinlock bloccato? Dentro un bottom-half? dentro un irq? E cosa fa, si tratta di un irq di un disco (sveglio kswapd e rischedulo la transazione per il futuro, non so bene in quale maniera visto che solo chi ha chiamato l'allocazione lo sa) oppure di una scheda di rete? (enomem? dati persi -- sorry)
Vuoi capire che _nessuno_ tranne il chiamante sa cosa fare in quel punto?


- un codice piu' leggibile perche' non sei costretto a "sporcare" il codice con la gestione degli errori
Immagino quanti "scheduling while atomic" dovrai debuggare, usando il tuo pulitissimo codice ;)

fek
18-10-2004, 12:20
Originariamente inviato da ilsensine
Dovrei quindi controllare il valore di ritorno? Allora non è più efficiente di una normale kmalloc.


No. E' questo il punto, Action() e' polimorfica ed il codice eseguito dipende dal tipo di oggetto tornato.


"...fa esattamente tutto il necessario..."...in quale contesto? Dentro uno spinlock? Sblocca lo spinlock e si inventa qualcosa, possibilmente tirando a indovinare qual'è lo spinlock bloccato?


Ho gia' risposto a questo argomento: puoi passare a Create una descrizione del contesto d'esecuzione (compresi gli spinlock, i semafori in uso, la situazione, qualunque cosa ti venga in mente), di modo che l'handler conosca il contesto e svolga l'operazione adatta in caso di errore.
Semplice e lineare. Molto meglio di tanti if in cascata.


Dentro un bottom-half? dentro un irq? E cosa fa, si tratta di un irq di un disco (sveglio kswapd e rischedulo la transazione per il futuro, non so bene in quale maniera visto che solo chi ha chiamato l'allocazione lo sa) oppure di una scheda di rete? (enomem? dati persi -- sorry)
Vuoi capire che _nessuno_ tranne il chiamante sa cosa fare in quel punto?


Mi sa che sei tu che non stai capendo qui.
Il chiamante passa il suo contesto, l'handler gestisce.
Il principio e' "ogni entita' ha una sola responsabilita'": il chiamante ha la responsabilita' di richiedere l'esecuzione dell'azione, non ha la responsabilita' di gestire l'errore, che e' delegata all'entita' che meglio e' in grado di effettuare questa gestione. L'entita' e' scelta in base al contesto del chiamante.


Immagino quanti "scheduling while atomic" dovrai debuggare, usando il tuo pulitissimo codice ;)

Non e' certo usando termini tecnici che puoi uscire da un argomento chiaramente perdente.

Riassumendo, la mia soluzione e':
- piu' efficiente
- piu' leggibile
- piu' semplice da mantenere, visto che ogni entita' ha una sola responsabilita', il decoupling e' minimizzato, il codice e' piu' leggibile, il design piu' chiaro

Nella mia soluzione, molto probabilmente non ci sarebbero "scheduling while atomic" da debuggare.

repne scasb
18-10-2004, 13:04

fek
18-10-2004, 13:31
Originariamente inviato da repne scasb

2) Chi ha dato motivazioni storiche al fatto che il kernel di Linux sia stato scritto in C, non spiega come mai, oggi, nessuna parte del kernel di Linux e' scritta in C++. Ossia se 10 anni orsono i compilatori C++ erano quello che erano e quindi fu scelto lo sviluppo in C, perche' oggi che i compilatori C++ sono migliorati non ci ritroviamo "almeno" con un kernel "misto C/C++"?


Sono pienamente d'accordo con te. Ne parlo dopo.

La domanda che mi sento di fare a fek e':

Supponiamo che sia possibile riscrivere il kernel di Linux in C++, in maniera piu' efficiente che in C (la questione ve le dirimete tu e ilsensine dando il significato che volete al vocabolo "efficiente"), come puoi escludere che, in funzione del compilatore "reale" e non "perfetto" utilizzato e delle svariate architetture su cui dovrebbe girare il kernel, nonostante il codice in C++ possa sembrarti "migliore", poi alla resa dei conti si dimostrasse meno efficiente?

La domanda e' interessantissima. E' difficile dare una risposta. Sicuramente 12 anni fa preferire il C era una scelta anche prestazionalmente non azzardata.
Oggi, al contrario, la maggior parte della ricerca in materia di compilatori si svolge sui compilatori C++ che, come tendenza generale, progrediscono piu' velocemente di quelli C che vengono progressivamente abbandonati. E' una tendenza generale.
Ad esempio, abbiamo oggi compilatori C++ che sono in grado di ottimizzare il codice in base a statistiche raccolte sull'esecuzione del codice stesso (profiling instrumented optimization).
Direi che sicuramente sara' possibile trovare un ambiente nel quale il compilatore C puo' (per svariati motivi) produrre codice piu' efficiente, ma altrettanto sicuramente queste sono sempre piu' eccezioni: ti rivolgo la domanda, tu penalizzeresti la maggior parte dei sistemi dove, come tendenza, il codice C++ sara' piu' veloce per poche eccezioni dove avviene il contrario?

Al che si arriva alla tua prima domanda: perche' non iniziare a ridisegnare parti del kernel in maniera piu' moderna in C++? Per arrivare ad un modello misto e via via ad un kernel completamente in C++. Secondo me, non lo fanno perche' non tutti i membri del progetto hanno grande dimestichezza col C++ e non vogliono abbandonare la via vecchia per quella nuova che non conoscono. Ma a parte queste speculazioni, io seguirei esattamente questa strada.
Sarebbe possibile iniziare a ridisegnare lo strato di interfaccia fra il Kernel e l'esterno e implementarla in C++, e mantenere un'interfaccia "legacy" in C, magari wrappando il substrato C++, per motivi di compatibilita'. Poi si comunica agli sviluppatori di accedere al Kernel in futuro per via dell'interfaccia C++ nativa, piu' organica ed efficiente, e pian piano deprecare l'interfaccia C.

Una volta arrivati ad un'interfaccia totalmente C++ con l'esterno, si puo' proseguire passo per passo a ridisegnare gli strati interni del Kernel.

Il risultato di questo enorme refactoring che durerebbe anni sarebbe:
- un miglior design, piu' stabile, coerente e moderno
- miglior efficienza dettata dall'uso di implementazioni migliori
- migliori tempi di sviluppo successivo e minori costi di mantenimento per via di un design "migliore"

ilsensine
18-10-2004, 13:38
Originariamente inviato da fek
No. E' questo il punto, Action() e' polimorfica ed il codice eseguito dipende dal tipo di oggetto tornato.

Ho gia' risposto a questo argomento: puoi passare a Create una descrizione del contesto d'esecuzione (compresi gli spinlock, i semafori in uso, la situazione, qualunque cosa ti venga in mente), di modo che l'handler conosca il contesto e svolga l'operazione adatta in caso di errore.
Semplice e lineare. Molto meglio di tanti if in cascata.
Scusa ma non è né semplice né lineare. Molto peggio di un _unico_ if, che esegue sotto i tuoi occhi il codice critico, conoscendo perfettamente il proprio contesto.


Non e' certo usando termini tecnici che puoi uscire da un argomento chiaramente perdente.
Tu puoi usare (giustamente) termini tecnici di c++ in quanto si sta parlando c++, e io non posso usare termini tecnici di un kernel (tra l'altro autoesplicativi) visto che si sta parlando di un kernel?

fek
18-10-2004, 13:48
Originariamente inviato da ilsensine
Scusa ma non è né semplice né lineare. Molto peggio di un _unico_ if, che esegue sotto i tuoi occhi il codice critico, conoscendo perfettamente il proprio contesto.


Ok, se pensi che due istruzioni in sequenza siano meno lineari di un if non commentato, non c'e' spazio per ulteriore discussione. Dimostri semplicemente che cosa vuol dire non poter programmare in C++ in maniera efficiente perche' non si conosce i paradigmi dietro al linguaggio.


Tu puoi usare (giustamente) termini tecnici di c++ in quanto si sta parlando c++, e io non posso usare termini tecnici di un kernel (tra l'altro autoesplicativi) visto che si sta parlando di un kernel?

Qualunque programmatore che si rispetti e' tenuto a conoscere il nome e il significato dei Design Pattern, e' come l'ABC, andrebbero recitati a memoria (non sono specifici del C++).

Non tutti i programmatori sono tenuti a conoscere i termini tecnici specifici del Kernel Linux.


Chiunque voglia imparare a programmare, deve avere questo come Bibbia:
Design patterns : elements of reusable object-oriented software
(http://www.amazon.co.uk/exec/obidos/ASIN/0201633612/qid=1098103668/ref=sr_8_xs_ap_i1_xgl/202-4027200-9583865)

ilsensine
18-10-2004, 13:55
Originariamente inviato da fek
Ok, se pensi che due istruzioni in sequenza siano meno lineari di un if non commentato, non c'e' spazio per ulteriore discussione. Dimostri semplicemente che cosa vuol dire non poter programmare in C++ in maniera efficiente perche' non si conosce i paradigmi dietro al linguaggio.
Il tuo esempio non è composto solo da "due istruzioni in sequenza". Il codice di cleanup (e di gestione dell'errore!) c'è, è da un'altra parte dello stesso modulo (no, non ci pensare minimamente a scrivere un handler universale per tutti). E visto che accenni a passare a questo codice:

puoi passare a Create una descrizione del contesto d'esecuzione (compresi gli spinlock, i semafori in uso, la situazione, qualunque cosa ti venga in mente), di modo che l'handler conosca il contesto e svolga l'operazione adatta in caso di errore.
è plausibile che debba contenete più if a cascata di una soluzione diretta.

Non tutti i programmatori sono tenuti a conoscere i termini tecnici specifici del Kernel Linux.
Schedulare (cambiare contesto) in una regione atomica (non interrompibile) non è un concetto specifico di un kernel particolare.

fek
18-10-2004, 14:17
Originariamente inviato da ilsensine
Il tuo esempio non è composto solo da "due istruzioni in sequenza". Il codice di cleanup (e di gestione dell'errore!) c'è, è da un'altra parte dello stesso modulo (no, non ci pensare minimamente a scrivere un handler universale per tutti). E visto che accenni a passare a questo codice:

Anche il tuo solo IF non ha tutta il codice di startup e cleanup. La differenza e' che nel mio codice la gestione dell'errore e' da un'altra parte, perche' chi legge quel codice non ha bisogno di conoscere che succede in caso di errore, ma vuole conoscere la logica del problema.
Quindi e' piu' leggibile.

Chi e' interessato alla gestione dell'errore andra' a leggere le entita' che si occupano di queste responsabilita'.

Mi spiace, ma ogni buon manuale di programmazione e design insegna il concetto che un'entita' debba avere una sola responsabilita' e che la gestione degli errori deve essere separata dalla logica, per rendere il codice leggibile e robusto. Stai sostenendo un argomento perso.


è plausibile che debba contenete più if a cascata di una soluzione diretta.

E non e' buon codice se contiene serie di if a cascata perche' offusca la logica dell'entita' in mezzo a codice che "logicamente", non fa parte del dominio del problema. La gestione degli errore deve essere separata.

Leggi Design Patterns e ti dira' altri dieci motivi per il quale il Null Object pattern e' preferibile a cascate di if.


Schedulare (cambiare contesto) in una regione atomica (non interrompibile) non è un concetto specifico di un kernel particolare.

Schedulare non e' un concetto specifico del kernel, la sequela di altri termini lo sono: hai cercato di vincere un argomento perso sparando una sequenza di termini incomprensibili ai piu'. E' un vecchio trucco, niente di nuovo.

RaouL_BennetH
18-10-2004, 16:42
Originariamente inviato da fek
La domanda e' interessantissima. E' difficile dare una risposta. Sicuramente 12 anni fa preferire il C era una scelta anche prestazionalmente non azzardata.
Oggi, al contrario, la maggior parte della ricerca in materia di compilatori si svolge sui compilatori C++ che, come tendenza generale, progrediscono piu' velocemente di quelli C che vengono progressivamente abbandonati. E' una tendenza generale.
Ad esempio, abbiamo oggi compilatori C++ che sono in grado di ottimizzare il codice in base a statistiche raccolte sull'esecuzione del codice stesso (profiling instrumented optimization).
Direi che sicuramente sara' possibile trovare un ambiente nel quale il compilatore C puo' (per svariati motivi) produrre codice piu' efficiente, ma altrettanto sicuramente queste sono sempre piu' eccezioni: ti rivolgo la domanda, tu penalizzeresti la maggior parte dei sistemi dove, come tendenza, il codice C++ sara' piu' veloce per poche eccezioni dove avviene il contrario?

Al che si arriva alla tua prima domanda: perche' non iniziare a ridisegnare parti del kernel in maniera piu' moderna in C++? Per arrivare ad un modello misto e via via ad un kernel completamente in C++. Secondo me, non lo fanno perche' non tutti i membri del progetto hanno grande dimestichezza col C++ e non vogliono abbandonare la via vecchia per quella nuova che non conoscono. Ma a parte queste speculazioni, io seguirei esattamente questa strada.
Sarebbe possibile iniziare a ridisegnare lo strato di interfaccia fra il Kernel e l'esterno e implementarla in C++, e mantenere un'interfaccia "legacy" in C, magari wrappando il substrato C++, per motivi di compatibilita'. Poi si comunica agli sviluppatori di accedere al Kernel in futuro per via dell'interfaccia C++ nativa, piu' organica ed efficiente, e pian piano deprecare l'interfaccia C.

Una volta arrivati ad un'interfaccia totalmente C++ con l'esterno, si puo' proseguire passo per passo a ridisegnare gli strati interni del Kernel.

Il risultato di questo enorme refactoring che durerebbe anni sarebbe:
- un miglior design, piu' stabile, coerente e moderno
- miglior efficienza dettata dall'uso di implementazioni migliori
- migliori tempi di sviluppo successivo e minori costi di mantenimento per via di un design "migliore"


Quindi, se per ipotesi dal c++ negli anni a venire, venisse "fuori" un altro tipo di linguaggio, derivato dal c++, ma ancora più flessibile, chiamiamolo ipoteticamente "e++", dopo altri vent'anni di kernel (in generale questa volta) in c++, si potrebbe ragionevolmente presumere di incorrere negli stessi ragionamenti di oggi? Ovvero, una moltitudine di programmatori che mostrerà tutte le meraviglie e l'efficienza del c++(perchè ci ha sbattuto il cranio per un ventennio), ed un futuro di altri programmatori, che invece, ragionerà sul linguaggio del "momento" più innovativo (l'ipotetico e++) ?

E forse è corretto allora poter "pensare":

Si preferisce ancora oggi un kernel in C perchè il C++, essendo un linguaggio relativamente nuovo, e visto il cammino verso l'ottimizzazione di alcuni compilatori, e, visto che non ci sono ancora "molti" programmatori con la preparazione dei relativi in C, potrebbe magari risultare più un problema che una soluzione?

Ikitt_Claw
18-10-2004, 16:53
Originariamente inviato da fek
Sarebbe possibile iniziare a ridisegnare lo strato di interfaccia fra il Kernel e l'esterno e implementarla in C++, e mantenere un'interfaccia "legacy" in C, magari wrappando il substrato C++, per motivi di compatibilita'.
Poi si comunica agli sviluppatori di accedere al Kernel in futuro per via dell'interfaccia C++ nativa, piu' organica ed efficiente, e pian piano deprecare l'interfaccia C.
Non si puo` deprecare l'interfaccia C: siamo sotto *nix, il C e` di casa e c'e` una base di codice (non necessariamente open source) notevolissima che si appoggia a quello.

Una volta arrivati ad un'interfaccia totalmente C++ con l'esterno, si puo' proseguire passo per passo a ridisegnare gli strati interni del Kernel.
Ammetto che il meccanismo delle syscall non mi e` di una chiarezza cristallina, oltre a questo non mi e` chiaro come possa essere implementato (in modo pulito, ovviamente, e non C-like) una syscall, ovvero fondamentalmente un'interrupt software decorato (no?). Nel senso, mi sembra che alla fin fine la cosa piu` naturale sia una chiamata a funzione.
Mi verrebbe da pensare anche ad un meccanismo *tipo* CORBA o RMI in java, e anche qui faccio ammenda per la mia conoscienza superficiale, ma non mi pare che in questo caso possa calzare come capolavoro di pulizia, anche rispetto alla situazione attuale.

A parte questo, gia` adesso a quanto mi risulta una ricchissima parte dell'userspace accede ai servigi del kernel via libc/libdevmapper/libalsa/libqualcosa, non mi pare ci sia necessita` cosi` pressante di esportare una nuova interfaccia C++ ("basta" cambiare quella delle librerie, prevedendo un'altra cascata di problemi per il cambio di API), anche per un'eventuale (molto) ipotetico refactoring.


Il risultato di questo enorme refactoring che durerebbe anni sarebbe:
- un miglior design, piu' stabile, coerente e moderno
- miglior efficienza dettata dall'uso di implementazioni migliori
- migliori tempi di sviluppo successivo e minori costi di mantenimento per via di un design "migliore"
Potrebbe esser ganzo vederlo girare :)
Quasi quasi scarico il CVS di Haiku/OpenBeos, giusto per vedere Lo Stato dell'Arte (A 'sto punto mi aspetto mirabilie allucinanti...)

il kernel attuale di Haiku pare essere quello di newos, che a sua volta e` scritto ancora in C (orrore & raccapriccio!)

fek
18-10-2004, 18:12
Originariamente inviato da RaouL_BennetH
Quindi, se per ipotesi dal c++ negli anni a venire, venisse "fuori" un altro tipo di linguaggio, derivato dal c++, ma ancora più flessibile, chiamiamolo ipoteticamente "e++", dopo altri vent'anni di kernel (in generale questa volta) in c++, si potrebbe ragionevolmente presumere di incorrere negli stessi ragionamenti di oggi? Ovvero, una moltitudine di programmatori che mostrerà tutte le meraviglie e l'efficienza del c++(perchè ci ha sbattuto il cranio per un ventennio), ed un futuro di altri programmatori, che invece, ragionerà sul linguaggio del "momento" più innovativo (l'ipotetico e++) ?

E forse è corretto allora poter "pensare":


E' tutto un problema di strumenti.
Se esiste uno strumento migliore, che ti garantisce piu' produttivita' dello strumento che stai usando adesso, e' provato essere migliore da svariati casi d'uso, perche' non usarlo?

Perche' magari non lo si conosce: e' arrivato il momento di imparare qualcosa di nuovo. Un programmatore che non impara costantemente qualcosa di nuovo non e' un buon programmatore in una disciplina in costante evoluzione.

Le regole dell'Ingegneria del Software di dieci anni fa sono state superate, ad esempio.

fek
18-10-2004, 18:16
Originariamente inviato da Ikitt_Claw
A parte questo, gia` adesso a quanto mi risulta una ricchissima parte dell'userspace accede ai servigi del kernel via libc/libdevmapper/libalsa/libqualcosa, non mi pare ci sia necessita` cosi` pressante di esportare una nuova interfaccia C++ ("basta" cambiare quella delle librerie, prevedendo un'altra cascata di problemi per il cambio di API), anche per un'eventuale (molto) ipotetico refactoring.


Ti rispondo con le parole di Fowler: "Non si dovrebbe mai aver paura di fare refactoring: il tempo usato oggi, verra' risparmiato in larga parte domani".

Deprecare l'interfaccia C poco per volta in anni secondo me non sarebbe un grave problema. Il nuovo software scritto si adegua alla nuova interfaccia, il vecchio software diverra' sempre piu' obsoleto e verra' via via abbandonato naturalmente e riscritto, salvo continuare a girare perfettamente su vecchie versioni del kernel.

A meno che qui non si pensi che il codice si scrive una volta e non si tocca piu' per l'eternita'. Vero che nessuno lo pensa? E' vero? ;)

RaouL_BennetH
18-10-2004, 18:16
Originariamente inviato da fek
E' tutto un problema di strumenti.
Se esiste uno strumento migliore, che ti garantisce piu' produttivita' dello strumento che stai usando adesso, e' provato essere migliore da svariati casi d'uso, perche' non usarlo?

Perche' magari non lo si conosce: e' arrivato il momento di imparare qualcosa di nuovo. Un programmatore che non impara costantemente qualcosa di nuovo non e' un buon programmatore in una disciplina in costante evoluzione.

Le regole dell'Ingegneria del Software di dieci anni fa sono state superate, ad esempio.

potremo anche pensare che "lo strumento migliore" potrebbe non semper essere il più maturo?

Proprio per quello che dici, se corrisponde a realtà, allora prima di veder "rivoluzionati", anzi, forse meglio e meno fragoroso dire, revisionati gli svariati kernel dei sistemi operativi, potrebbe volerci ancora molto tempo.

fek
18-10-2004, 18:18
Originariamente inviato da RaouL_BennetH
potremo anche pensare che "lo strumento migliore" potrebbe non semper essere il più maturo?

Proprio per quello che dici, se corrisponde a realtà, allora prima di veder "rivoluzionati", anzi, forse meglio e meno fragoroso dire, revisionati gli svariati kernel dei sistemi operativi, potrebbe volerci ancora molto tempo.

Sicuramente ci vuole tempo, nessuno dice di farlo dall'oggi al domani. Ma quella e' la strada se vogliono migliorare il Kernel di Linux nei prossimi anni. Altrimenti si puo' sempre continuare a fare i calcoli con carta e penna. Mentre tutti gli altri usano i computer.
Si chiama progresso.

Ikitt_Claw
18-10-2004, 18:23
Originariamente inviato da fek
Ti rispondo con le parole di Fowler: "Non si dovrebbe mai aver paura di fare refactoring: il tempo usato oggi, verra' risparmiato in larga parte domani".
In Linux lo fanno (beh, neanche si preoccupano troppo di cambiare l'API, se serve), restando pero` fedeli al C.

Deprecare l'interfaccia C poco per volta in anni secondo me non sarebbe un grave problema.
Oddio, la mia limitatissima esperienza mi fa pensar male, spero sia per colpa della sua limitatezza.

A meno che qui non si pensi che il codice si scrive una volta e non si tocca piu' per l'eternita'. Vero che nessuno lo pensa? E' vero? ;)
Io posso anche pensarlo, tutto sta nel vedere qual che ne pensa il resto del mucchio, c'e` una buona (sicuramente non trascurabile) fetta di gente che usa software vecchio anche di vari lustri...

RaouL_BennetH
18-10-2004, 18:25
Uhm, sta cosa mi lascia un pò perplesso perchè non riesco a capire perchè ti riferisci solo a linux, leggevo che la stragrande maggioranza dei sistemi operativi, windows e mac compreso, sono scritti ancora in C, allora forse ho trovato solo vecchie documentazioni oppure negli altri casi già c'è un "misto" C/C++ ?!? E in questo caso perchè li riportano come scritti solo in C? (ammesso che abbia trovato delle documentazioni ancora valide)

fek
18-10-2004, 18:27
Originariamente inviato da RaouL_BennetH
Uhm, sta cosa mi lascia un pò perplesso perchè non riesco a capire perchè ti riferisci solo a linux, leggevo che la stragrande maggioranza dei sistemi operativi, windows e mac compreso, sono scritti ancora in C, allora forse ho trovato solo vecchie documentazioni oppure negli altri casi già c'è un "misto" C/C++ ?!? E in questo caso perchè li riportano come scritti solo in C? (ammesso che abbia trovato delle documentazioni ancora valide)

Perche' stiamo parlando di Linux, ma lo stesso discorso vale per il Kernel di WinNT e Mac.

L'API Win32, ad esempio, verra' deprecata da Longhorn per favorire un'api che si basa sul framework .NET e poi verra totalmente rimossa (magari immagino con un modulo che la emuli) con il S.O. successivo. Si parla di 6/7 anni.

afterburner
18-10-2004, 18:28
Perdonatemi se non ho letto le risposte di tutti .. Sono troppe ed oggi decisamente non ho tempo.
Pure sua maesta' REPNZ SCASB si e' scomodata!! OT Repne, ma qual e' il byte che continui a ricercare nella stringa? :D

Io ho letto qui (http://www.tux.org/lkml/#s15-3).

Senza offesa per fek o altri che sostengono la possibilita' di usare C++ nel kernel di linux, dico solo che Torvalds ha progettato un sistema operativo che IBM installa anche su macchine oltre i 100mila euro .. non penso Tolvalds sia uno sprovveduto :D

fek
18-10-2004, 18:30
Originariamente inviato da afterburner
Senza offesa per fek o altri che sostengono la possibilita' di usare C++ nel kernel di linux, dico solo che Torvalds ha progettato un sistema operativo che IBM installa anche su macchine oltre i 100mila euro .. non penso Tolvalds sia uno sprovveduto :D

Sicuramente non e' uno sprovveduto, ma come ho detto puoi essere Dio sceso in terra, ma se affermi che non si puo' usare il C++ per problemi tecnici quali l'impossibilita' di avere allocatori custom, stai affermando una scemenza.

Poi puoi anche aver scritto il miglior software di questo pianeta, non cambia le cose.

RaouL_BennetH
18-10-2004, 18:31
Originariamente inviato da afterburner
Perdonatemi se non ho letto le risposte di tutti .. Sono troppe ed oggi decisamente non ho tempo.
Pure sua maesta' REPNZ SCASB si e' scomodata!! OT Repne, ma qual e' il byte che continui a ricercare nella stringa? :D

Io ho letto qui (http://www.tux.org/lkml/#s15-3).

Senza offesa per fek o altri che sostengono la possibilita' di usare C++ nel kernel di linux, dico solo che Torvalds ha progettato un sistema operativo che IBM installa anche su macchine oltre i 100mila euro .. non penso Tolvalds sia uno sprovveduto :D

Credo, dopo tanti post, e io invece li ho seguiti e letti tutti tutti :D che nemmeno fek e cdmauro intendano che sia uno sprovveduto, ma solo che forse, e sottolineo il forse, non è un programmatore di c++, ne risulterebbe che non "pensa" in c++ e, di conseguenza, non ha e non lavora al kernel in c++.

afterburner
18-10-2004, 18:40
In general, I'd say that anybody who designs his kernel modules for C++ is either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.

La (b) penso sia la cosa piu' esatta. Puoi scrivere un modulo in C++ ma poi se sei un programmatore smart ti accorgi che cio' che hai scritto altro non e' che C.

fek
18-10-2004, 18:45
Originariamente inviato da afterburner
In general, I'd say that anybody who designs his kernel modules for C++ is either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.

La (b) penso sia la cosa piu' esatta. Puoi scrivere un modulo in C++ ma poi se sei un programmatore smart ti accorgi che cio' che hai scritto altro non e' che C.

L'ho letto. Mettiamola cosi', Linus avrebbe potuto tirare fuori argomenti piu' convincenti. Se avesse saputo di che cosa stava parlando. E' chiaro che non lo sapeva:

(b) a C++ bigot that can't see what he is writing is really just C anyway

Si', se non sai programmare in C++.

fek
18-10-2004, 18:57
Sto leggendo con molto interesse:


(REG) Admittedly, all those goto's do look a bit ugly. However, they are usually limited to error paths, and are used to reduce the amount of code required to perform cleanup operations. Replacing these with Politically Correct if-then-else blocks would required duplication of cleanup code. So switching to if-then-else blocks might be good Computer Science theory, but using goto's is good Engineering. Since the Linux kernel is one designed to be used, rather than to demonstrate theory, sound engineering principles take priority.

Magari mettere l codice di cleanup in una funzione e richiamando quella, in una bella clausola __finally sarebbe un Engineering principle ancora migliore?

Non e' teoria: e' dimostrato scientificamente che il numero di difetti in un codice e' proporzionale al numero di goto.

Ikitt_Claw
18-10-2004, 19:01
Originariamente inviato da fek
Non e' teoria: e' dimostrato scientificamente che il numero di difetti in un codice e' proporzionale al numero di goto.
link/pointer grazie, mi sarebbe mooooolto utile in un paio di discussioni che ho presente io...

fek
18-10-2004, 19:04
Originariamente inviato da Ikitt_Claw
link/pointer grazie, mi sarebbe mooooolto utile in un paio di discussioni che ho presente io...

http://www.amazon.co.uk/exec/obidos/ASIN/0735619670/qid=1098122604/ref=sr_8_xs_ap_i1_xgl/202-4027200-9583865

Ho il libro a casa e non ti posso dare i rimandi esatti agli studi citati, perche' non li conosco a memoria.

afterburner
18-10-2004, 19:04
Originariamente inviato da fek
L'ho letto. Mettiamola cosi', Linus avrebbe potuto tirare fuori argomenti piu' convincenti. Se avesse saputo di che cosa stava parlando. E' chiaro che non lo sapeva:

(b) a C++ bigot that can't see what he is writing is really just C anyway

Si', se non sai programmare in C++.

Tolvalds non saprebbe programmare in C++?!?!?! Questa e' la migliore della giornata :sbonk: :sbonk: :sbonk:

Ikitt_Claw
18-10-2004, 19:07
Originariamente inviato da afterburner
Tolvalds non saprebbe programmare in C++?!?!?! Questa e' la migliore della giornata :sbonk: :sbonk: :sbonk:

Di certo non e` granche` famoso per le sue opere in C++...

afterburner
18-10-2004, 19:10
Originariamente inviato da fek
Sto leggendo con molto interesse:

....

Magari mettere l codice di cleanup in una funzione e richiamando quella, in una bella clausola __finally sarebbe un Engineering principle ancora migliore?

Non e' teoria: e' dimostrato scientificamente che il numero di difetti in un codice e' proporzionale al numero di goto.

Ma porca puzzola!! Lo capisci che questo e' kernel?!? Non importa se tu riesci a eliminare 500 goto in un modulo con un codice di cleanup!! Stai SOLTANTO rendendo bello, grazioso e armonico il codice .. quando questo diventa linguaggio macchina, non ci frega nulla se il codice di partenza aveva i fiocchetti!!

fek
18-10-2004, 19:10
Originariamente inviato da afterburner
Tolvalds non saprebbe programmare in C++?!?!?! Questa e' la migliore della giornata :sbonk: :sbonk: :sbonk:

Stando a quello che scrive, si direbbe proprio di si'.

Praticamente le ragioni che usano per "dimostrare" che il Kernel di Linux puo' essere scritto solo in C in quelle FAQ sono:

- "non abbiamo il tempo di imparare nuove tecniche" (evabbe' ndFEK)
- "perche' abbiamo sempre fatto cosi'" (ma si' ndFEK)
- "perche' Linus ha detto che si fa cosi'" (ovvio ndFEK)

Sono sempre piu' convinto che cidimauro abbia ragione su tutta la linea.

fek
18-10-2004, 19:12
Originariamente inviato da afterburner
Ma porca puzzola!! Lo capisci che questo e' kernel?!? Non importa se tu riesci a eliminare 500 goto in un modulo con un codice di cleanup!! Stai SOLTANTO rendendo bello, grazioso e armonico il codice .. quando questo diventa linguaggio macchina, non ci frega nulla se il codice di partenza aveva i fiocchetti!!

E allora scrivi tutto in codice macchina a 1 e 0.

La cosa piu' importante e' il codice di partenza, perche' una volta che hai scritto il codice, devi anche mantenerlo, correggerlo, aggiornarlo. Se e' pieno di goto e programmato con i piedi, ci vuole piu' tempo per mantenerlo (e' scientificamente provato), e' piu' probabile che ci siano difetti (e' scientificamente provato), e' piu' difficile da correggere (e' scientificamente provato).

Sono 3 milioni e mezzo di righe di codice da mantenere. E scritte con i piedi (a quanto dicono loro stessi).

afterburner
18-10-2004, 19:14
Originariamente inviato da Ikitt_Claw
Di certo non e` granche` famoso per le sue opere in C++...

Qui non stiamo parlando di mastro geppetto :D
Tolvalds come si e' imparato il C ed ha scritto il primo kernel da zero, cosi' si e' imparato il C++, ha provato ad usarlo circa 10 anni fa, ha visto che appesantiva ed e' tornato al C.

Ikitt_Claw
18-10-2004, 19:14
Originariamente inviato da fek
- "non abbiamo il tempo di imparare nuove tecniche" (evabbe' ndFEK)

Considerando come vanno le cose sulla lkml, non e` cosi` assurdo come motivo.
Quantomeno e` credibile.

- "perche' abbiamo sempre fatto cosi'" (ma si' ndFEK)
- "perche' Linus ha detto che si fa cosi'" (ovvio ndFEK)

- perche` non abbiamo (ancora?) le risorse per fare il refactoring di 4 e piu` milioni di righe di codice

Sono sempre piu' convinto che cidimauro abbia ragione su tutta la linea.
A malincuore, ma noi GNUcchi sopravviveremo. ;)

fek
18-10-2004, 19:15
Originariamente inviato da afterburner
Qui non stiamo parlando di mastro geppetto :D
Tolvalds come si e' imparato il C ed ha scritto il primo kernel da zero, cosi' si e' imparato il C++, ha provato ad usarlo circa 10 anni fa, ha visto che appesantiva ed e' tornato al C.

Lo impari meglio.

Ikitt_Claw
18-10-2004, 19:15
Originariamente inviato da fek
Sono 3 milioni e mezzo di righe di codice da mantenere. E scritte con i piedi (a quanto dicono loro stessi).
Azz,
flamecounter++

Peccato, questa volta ci avevo sperato.

fek
18-10-2004, 19:16
Originariamente inviato da Ikitt_Claw
E via a ruota libera con le flame?

E' scritto sulla FAQ che moltissimo di quel codice e' scritto male e lo tengono cosi' perche' non hanno il tempo di fare alcun refactoring. Non lo dico io :)

Non c'e' nulla su cui far partire un flame.

afterburner
18-10-2004, 19:18
Originariamente inviato da fek
Sono sempre piu' convinto che cidimauro abbia ragione su tutta la linea.

Di Mauro non ha mai ragione Punto E' un assioma Punto

Ikitt_Claw
18-10-2004, 19:20
Originariamente inviato da fek
E' scritto sulla FAQ che moltissimo di quel codice e' scritto male e lo tengono cosi' perche' non hanno il tempo di fare alcun refactoring. Non lo dico io :)
Non c'e' nulla su cui far partire un flame.

Consentimi di avere dei dubbi su entrambe le affermazioni.
Poi, beninteso, puo` darsi che mi sbagli io, eh. ;)

[edit] corretto orrore ortografico [/quote]

fek
18-10-2004, 19:21
Originariamente inviato da Ikitt_Claw
Consentimi di avere dei dubbi su entrambe le affermazioni.
Poi, beninteso, puo` darsi che mi sbaglio io, eh. ;)

E' scritto nella FAQ, prenditela con loro.

Ma leggi qui:


The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

- the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
- any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

Detto nel 2004 da Linus (ipse dixit). 3 su 3, sono semplicemente 3 affermazioni false. Ora, o pensiamo che lui voglia prendere per i fondelli la gente affermando cose palesemente false, oppure pensiamo che non sappia programmare in C++.
Scegliete voi, io mi ritiro a vita privata :)

Ikitt_Claw
18-10-2004, 19:24
Originariamente inviato da fek
E' scritto nella FAQ, prenditela con loro.

E` proprio da una rilettura che sono nati i dubbi. ;)

Detto nel 2004 da Linus (ipse dixit). 3 su 3, sono semplicemente 3 affermazioni false. Ora, o pensiamo che lui voglia prendere per i fondelli la gente affermando cose palesemente false, oppure pensiamo che non sappia programmare in C++.
Scegliete voi, io mi ritiro a vita privata :)
Concludo (e non e` una novita` per me) che Linus non sa programmare in C++.
Il che non implica che non sappia programmare, ne che non sappia scrivere un buon kernel :D

Buon ritiro, ti verro` a trovare, forse, quando i ciliegi saranno di nuovo in fiore ;)